Tuesday, April 27, 2010

The Design Process

Making a game takes planning. In fact it takes a lot more planning than most people expect. Kahootz and Kodu allow people to jump on and start making a game straight away, but unless you've put some thought into it before hand, more often than not you end up with something that isn't very fun.

Don't get me wrong, when you're first learning to make games, jumping in head first may be the best learning tool you've got. You're just playing around, seeing what happens when you do this or that. It's the way I recommend when people ask how to make games. Problem is, once you start to get familiar with the game making tool you're using, and you start to get an idea of the type of game you want to make, it's time to step away from the computer and go back to basics.

And I do mean BASICS. Pen-and-paper is perhaps more important to game design than keyboard-and-mouse. The design process is a set of steps that are meant to maximise your efficiency through design. Basically, the design process means you know exactly what you're doing at each step of making your game and there's no time wasted to confusion.

The Design Process

The Design Process, also known as the Development Cycle, covers five basics stages. The Design Process is an old friend for any designer, and while the names of each stage might change depending on who you ask, their purposes remain the same. I prefer the cycle written as it is above because it better suits a learning environment and provides easily assessable outcomes. This cycle covers everything from start to finish in the game design process, or in any designed or creative endeavour. Keep in mind as we run through each stage that stages 1 and 2 are best done by pen and paper, and you shouldn't even look at a computer until stage 3.

Stage 1: Identify a Problem
Everything starts here, your problem - quite simply - is that you want to play a particular game but you don't have it. It doesn't exist yet, it's just a figment of your imagination.

Here you think about everything you want your game to be. Don't let anything hold you back at this stage, you can be as creative as you want. All too often I'll hear kids in this stage asking questions like "I want to make my character fly, swim, explode, etc. How do you make him do that in Kahootz/Kodu/etc?" I'll invariably tell them that at this point we don't even care about how we make our game work. We're just imagining the end product and writing down what we want it do to. We worry about the hard part of making it all work later in stage 3, otherwise we'd never get our game made because everything would seem too hard, or impossible to make.

At this stage we ask ourselves:
-Who is this game for? (Who is our audience?)
-What does our audience want our game to do? (What is the context?)
-What can I do that is fun and new?

Stage 2: Design a Solution
You've got a problem well thought out now. Let's start drawing! On a piece of paper, draw what your player will see on the computer screen. Draw up how some of your enemies will look, how some of your maps will look. Start writing down in dot points how your enemies act, points of interest in your maps or worlds, how your player interacts with the world.

This Design Stage is much to big to go into great detail at this point, but I will dedicate an entire blog to it in the near future. For the moment, a brief introduction to the entire process will suffice.

At this stage, we ask ourselves:
-How does my player interact with my game?
-What powerups or threats can change the way the player plays our game?
-How do I make my game suit my audience?

Stage 3: Build a Solution
We've made it past pen and paper. It's time to start actually making our game.

Of course, I can't tell you exactly how to make your game. Each one will be your own. However, I can give you advice. Start small and build outwards. This is called bottom-up programming. Divide your entire game into manageable portions. For example, you might want to focus first on getting the player to run and jump around your world. Then once that's done you can look at making the enemies run and jump around. Then, maybe we work out how to get the player to turn invisible, hang off ledges or fly around with parachutes.

Bottom-Up Programming (as opposed to Top-Down Programming) sees your game as blocks in a pyramid. Build the foundation first, the basics of your game, before working on the harder parts. Let your game come together from separate pieces rather than trying to make it all in one go.

Stage 4: Test and Refine the Solution
This stage, I would argue, is the most important stage of them all. If you've rushed through your game and haven't spent any time testing it you could have all sorts of bugs and glitches waiting to ruin the fun for your player. And if your game isn't fun for the player, it isn't a game at all.

You've got a working model of your game at this stage. So show it to your friends and family, watch them as they play around with it. Do they get confused or lost? Do they not know what to do sometimes? Of course everything seems perfectly obvious to you, but you made it. You have to take a step back and ask yourself why your testers are getting confused. Maybe you need to put in more instructions, or a hint or two. Maybe you need to use different colours and sizes to show stronger and weaker enemies of the same type, or maybe you need other visual or audio cues when the player is getting hurt, or when they're winning.

And don't forget to write down each time the game crashes, or does something it isn't supposed to do. This stage can take a long time. Every time you find a bug, you have to go back and fix it and then get your players to test it again and again. Just remind yourself, this is all making your game better.

Stage 5: Evaluate the Solution
The game is done. It's been tested, all the bugs have been ironed out, and the hard work has paid off. It's time to release your game to its intended audience. It's important to watch them play your game, get feedback from them, see what they like and didn't like. There's a reason that the Design Process cycles round back to stage 1. If your audience doesn't like a part of your game, or doesn't understand it we're back at stage 1 with another problem, and hopefully another solution to design.

Now that you've got an introduction to the design process. It's a powerful tool and it's something that all designers use. If there's any part of this blog you'd like more information on, or you'd like to suggest a topic for a future blog please feel free to drop me an email and I'll be happy to accommodate you.

Next we'll start to look at the types of games out there, and the games you'll commonly be making.

Stay tuned!



  1. Such a clearly articulated blogpost. I agree that this design process is the MOST important part of the learning. The end-product is the easiest part to assess yet it is the least important part froma teacher's perspective. If we assess the process well at each step along the way, then the depth of understanding is truly measured and measurable!

  2. but .. from our experience with student designed games in physical education ,,, it is when students play the games designed by others, and identify glitches or more in the case of PE games, rule loopholes, that the real learning takes place -- as the designers have to reconcile this new tweek by either including it, or designing another rule to eliminate it.