I`m going to start my blog with a post about one of the most important subjects that comes to mind when I think about game design, which is making prototypes.

Prototyping in game design is validating a gameplay idea prior to the feature`s implementation in the actual game by iterating and finding if it’s FUN.



Don`t worry! It’s actually very simple to decide. Think like this: making a game is like solving a big problem.

Start by figuring out what your game is about. What do I do in the game? Define what’s the gameloop. When I say gameloop I mean the routine the player is going to traverse many times that is FUN and offers a progressive challenge. Always remember: Objective, Challenge and Reward.

After that, start breaking your big problem (objective/gameloop) into small problems (features), to a point where you can actually visualize the features.

As example, here is a typical rookie designer pitch:



Try to visualize which type of questions you would have to ask yourself about your game idea.

Let’s take the I control a knight(…)stop the bad dudeas an example.

Some type of questions I would ask myself about that pitch:

  • What’s the genre of the game? Is it a fighting game, action game, RPG?
  • Do I control one character, do I have a party?
  • The combat is melee, right? Is it fast paced or slow paced?
  • Do I fight multiple enemies at the same time or is it single enemy combat?

Let’s say I decided that it is a fast paced action game where the focus is the melee combat against multiple enemies and I control a character in third person. That gives me the centerpiece elements of my game and I have my “challenge” part of the gameloop.


Now do the same exercise to find the objective and reward of the core gameloop.

Once you have defined it, you have the core of the game. Its soul. The only part of the game that is sacred and therefore it cannot be sacrificed/cut from the game. It should be fun to play and offer a progressive challenge. All the other systems you design are built around it.

Once you have that, start breaking down the core elements. In the end you will have a big list of features which will be scaring, and you make you remember why it takes a lot of dedication to make a good game ☺

With the big list of features, I use the following filters:

  1. How much is that feature important in the gameloop?
  2. Have I ever designed a feature similar to that one in the past?

Always start with the features that are part of the core of the game and that the players will use/interact the most, and that are the risky ones. If two features have the same priority, start with the most risky one.



Choose the platform that your programmer is already experienced with and that it’s fast to code/have results.

Sometimes the chosen platform won’t be the same as the one you intend to develop the game on. That`s ok! Actually, it’s even better because it will not tempt your programmer on reusing the prototyping code in the final game.

If the game target platform doesn’t allow you to prototype as fast as another platform with the same results, go for it.

Some example of prototyping tools:

  • Adobe Flash (Gameplay 2D)
  • Unity (Gameplay 3D)

Prototyping is all about validating a concept and checking if it’s FUN. The code WILL be very bad. It’s the way it should be ☺  If you start caring about the code, you lose the agility of iterative prototyping.



Well, you can. There is no problem in that.

BUT usually it’s good to have at least 2 people doing it: The designer, which will be in charge of planning and validating the iterations, and the programmer, in charge of implementing what is needed for each iteration.

The reason for that is that in prototyping you need to separate the two mindsets required for prototyping: the creative one, which focus on playing/analyzing each iteration to check the fun aspect of it, validating the objective and how does it look from the eyes of the user, and the other mindset: the logical, which will be focused on making sure that the code works and the feature works.

Often when you do the two at the same time, you start mixing them and a feature can end up been validated not because of the fun/cohesive aspect of it, but by simply because it’s done and it’s working.

When selecting your programmer it’s important that the programmer has a Gameplay Oriented background since prototyping goes against every rule a programmer learns about clean code and clear specifications. Remind him that at each iteration the prototype can go to a complete different direction and that his code will only get worse at every iteration.



You don’t necessarily need an artist to prototype. Some features will require art elements, like to prove action combat systems, or feedbacks, but in general you can have placeholder assets that will prove the concept very well. After all, prototyping is about making the best gameplay possible, not best graphics.

Having super polished visuals to your prototype tend to change the mindset of the user playing the prototype as if the prototype assets are part of the final game. That leads to discussions about aesthetics. You don’t want that to happen!

For Prototyping 101 – PART 2 we will be talking about whats the role of designers, programmers and artists when working on the iterations.

Hope you guys liked it!


This article has 1 comments

Leave a Comment

Your email address will not be published.