Producer: “I can imagine a situation where the player will expect…”
Engineer: “I can imagine a case where the designer may want a level to…”
Designer: “I can imagine someone getting frustrated when…”
The phrase “I can imagine” comes up with surprisingly frequency during videogame development. I’ve heard it used on teams both large and small, during projects in wildly different genres, from people young and old.
At some point, in a moment of confused weakness, I’ve probably said it too.
But while I am all for imagination, the phrase is intellectually lazy. It is unfocused. It mistakenly treats design as a pile of independent special cases, causing what is most likely to be gradually eclipsed by what is unrealistically specific.
What doesn’t add to the design takes away from it. What doesn’t drive a project forward stalls it. And while it’s generally in a programmer’s interest to find a scaleable solution… well, I’ll just put this here:
And for a second opinion: John Salwitz, one of the 4 original developers for Paperboy in 1984, told me (I’m paraphrasing, this was 2005) that the most common error made by game programmers is trying to make software that does everything, instead of focusing on making software that does what it’s supposed to well.
The issue with using imagination in design arguments is that a healthy mind can imagine quite literally anything – things we can’t even begin to describe in words – regardless of its relevance or the chances of it actually happening. Good design requires coherent vision, selective emphasis, and conscious tradeoffs to produce a curated experience. Chasing unrelated threads in every direction in a futile effort to please every person in every circumstance is the opposite of that – the opposite of good design.
I can imagine a situation coming up tomorrow for which I would want to have a frog costume to wear. But that in itself is not a valid justification to go out and buy a frog costume tonight, in lieu of preparing for and tending to all the other more probable realities.
We have to imagine, of course, in order to consider directions and decisions before we’ve sunk resources into acting upon them. However it is the integrated act of more rigorous consideration that does the work – the artist’s trained judgment or the designer’s application of sound principle – not the raw yield of imagined possibilities.
It’s like an architect delivering a “blueprint” that’s really just random lines all over a page, expecting someone else to do the real work of deciding which to erase, which to rearrange, and which to structure how to arrive at a usable blueprint so that builders can proceed. He or she has a job to do, and doing this isn’t doing it.
It suggests cluelessness about how to spot decisions at the intersection of what has been done and what’s left to be done. Or a lack of clear thinking.
Imagination is how we start a thought, not how we close or present it.
This whole problem goes away with one minor tweak, instantly converting a statement from a useless declaration into one which can be evaluated and, if found true, accepted as grounds for further action:
“It seems likely that…”
The likelihood can then be questioned, and the impact weighed according to that likelihood. If it can’t be phrased that way, because it isn’t likely to be relevant, there’s the answer right there.
Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.
Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!