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:

Image for post
Image for post

but is instead something where we get at least the core game mechanics to run, like this:

Image for post
Image for post
Football Drama mechanics.

Now, you may not be satisfied with this example. Is this below (an evolution of the above) better?

Image for post
Image for post
Football Drama almost alpha.

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) :-)

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.


For the confusion between prototype and alpha that can lead to production problems, see this wonderful post What you should know about game prototypes by Laurent Victorino.

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.

Written by

I design/develop/teach HTML5 & game design & unity3d in 2D :-) -

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store