Rapid Practical Game Design

As promised, I’m going to elaborate on the process of game design we’ve used for our new to create game as part of my experimentation project. I’ve pro-creatively called it Rapid Practical Game Design and what it basically achieves is proper design results in a very short time. It requires very intense collaboration between the programmer,  the game designer and perhaps an artist, to create several prototypes over a certain short period, for instance one prototype each day of the week. The goal in the end is to destillate one or several game designs from the small prototypes by combining (aspects of) them.

The first thing that you should do, is making sure that you know what your restrictions are on the design. These restrictions should be theme related, a single keyword should be enough.  Do’nt use verbs, as they might relate to game mechanics and thus put too much restriction on the design to elaborate upon when creating the prototypes. Note that the restrictions might seem evil, but they actually help you find your way more easily and in the end make sure that you can use a greater number of prototypes to destilate from.

If you have a large team available for initial design, make couples or triples featuring a programmer, a designer and perhaps an artist. Choose an easy platform to develop on, for example Flash, XNA or perhaps Java, or even something like Virtools (which is mainly useful for rapid prototyping, but terribly anoying for anything more comprehensive). If you have a framework ready for any other language, thats cool, but I strongly discourage you to start creating anything from scratch when doing the programming, as  you don’t have that time.

Lets say you manage to get four teams, working for a week, then you’re required to have twenty game designs with prototypes by the end of the week. As designers, you may brainstorm with eachother to create new ideas, and as a team you may share assets to improve on the process of rapid prototyping. Try to push for new ideas rather than proven things that get shot down instantly in the next phase.

In my team for example, we didn’t really get a good idea of the restricions we’re given until late in the week. Some of the first design concepts therefore where rubbish as they didn’t fit in the restrictions we should have set in the first place. These restrictions should have been “City of Utrecht” and “Exploration” (and “Education”, but not really as our main goal). One team for instance made a tower defence clone, which just didn’t fit the profile and was useless to destilate anything from, thats a day thrown away. Another guy made a nice concept of racing on the outside of a tube. However cool that is, it just doesn’t fit the restrictions.

When the week is over, first lay every design concept next to the restrictions initially set. Which of the restrictions does it ‘hit’ and which not. Making an overview of this by counting the total ‘hits’, and the concepts that are your best base for a final design, score high on all restrictions.What you also want to do, is to evaluate the lowest scoring concepts. Try to determine what the positive aspect of that concept is, and write those down before you rule those concepts out. What you then have left most likely, is a large middle category of concepts that have one or several but not all restrictions scoring high. Now the trick is to combine those concepts into new more elaborate designs, and enhance the concepts that came out as your base designs. Finally, take care of designs that look alike. In the end you will have some solid designs that are perhaps innovating, but at least proper.

Thats it for now, I hope it is of any use 😉

Leave a Reply