This little post is a collection of some early morning Saturday thoughts induced by an interesting tweet by Rami Ismail:
Where do the misunderstandings come from? From the very term “prototype” that is ambiguous. Let’s try an indirect minimal definition: a prototype is not just a mechanic idea, a sketch, like this:
but is instead something where we get at least the core game mechanics to run, like this:
Now, you may not be satisfied with this example. Is this below (an evolution of the above) better?
This is the same mechanics as before but in production, not an alpha yet… a prototype? The ambiguity seems to come to what is the prototype meant to be used for: what problem(s) should the prototype solve?
Some sample cases. It may have to:
A. Test whether the mechanics works consistently, say by generating a feedback loop.
B. Test whether the game will be fun.
C. Test whether the game teaches what we want it to.
D. Convince the producers to produce the game.
The greatest distinction is between
a prototype for the game developers themselves to test the mechanics
the prototype as a pitch to convince others to produce the game.
Now trying again to think by subtraction, we could define a prototype as a game without depth along any dimension (graphics, feel, audio, story, character…) apart from a single mechanics.
The prototype in the first sense shows what you judge as sufficient proof before launching into a game production. Seen this way, spending a lot of type on prototyping may be a very, very wise decision. The term itself leads us to think in term of mechanics, but actually experienced game designers are aware that pre-production exploration should involve other dimensions, like story / characters / potential world building. As an example, explore the research for Hearthstone (2008–2012) :-)
Design and development of Hearthstone
Hearthstone development began in 2008, along with the assembling of Team 5. However, for a long time Team 5 was a very…
So where is the problem?
Why could a prototype be a big deal? It’s not because missing the distinctions above makes that much a difference as long as we are looking at things from within the game design / game development process. The problem as often happen comes when non game designers ask for “not the real game, just bring me a prototype, keep it as simple as possible”.
Now what people do not realize is that what they want is a working mechanics including the graphical concept and drafted assets — i.e. an alpha of the game, not a prototype, which may actually require a majority of the actual effort to produce the game. I sometimes use this metaphor: it’s like asking for a prototype for the Space Shuttle.
We don’t want the actual, finished Space Shuttle, just one rough thing that can safely bring people to space and back.
Well, this is a problem.
Solution? Explain, teach, learn.
Prototypes are also a way to approach the estimation problem which is a big deal in games: see this old post of mine From #NoEstimates to #YesPrototypes.
The sample prototypes are from my game in development, Football Drama.