Game design primer

From GPWiki

Introduction

Ever thought of a great idea for a game but were unsure on how to go about starting it? I'm sure everyone was there at one point in time. Many articles focus on how to do specific things rather then showing you the whole picture. The whole picture is called the design phase and it is very crucial part of game programming even though you don't write any code. Design can be a hard subject for a new programmer because it requires experience.

Where To Start?

The first thing I usually do when designing a game is think of all the features that the game will have. Lets say I want to make a simple top-view RPG like game (if you don't know what I'm talking about then you might want to Google for “Final Fantasy” 1-6 or “Chrono Trigger” for a good example). I'm just going to list somethings that I want in the game.

Monsters, Talking NPC's, Stores, Dungeons, Battle System, Cut-scenes,

This is a very basic list and it will change depending on your needs. Of course I might want more things than this but for this article it should be enough to give you an idea.

Expanding On The Game Features

Now that you have an idea on the game features you should define what they mean and think of the functionality of each one. I'll give an example of what I am talking about.

Store – A place for the player to buy items, armor and weapons. Functionality: Charge money for objects.

Cut-scene – a non-interactive story telling where NPC's speak and move around. Functionality: To tell the story.

This may not be absolutely necessary but later on it will help determine if something fits in the same category as another and possible feature overlap.

Thinking Of Dependencies

When I say dependencies many of you will think libraries but that not exactly what I mean. What I mean by dependencies is a list of things needed to make each feature work. I'll take the store as an example of dependencies.

Store Dependencies – showing images (graphics), menu selection (input), monetary system (logic), items/armor/weapons (game data).

That shows exactly what a store needs to work and gives you a clearer idea of what you need to do first. I'll do another one so I can explain the next section a little better.

Monster Dependencies – showing images (graphics), fighting AI (logic), reward/items/money (game data/logic).

Combining All dependencies

You might have notice that in the dependencies I hinted at what type of dependency each one was. Right now all I have for graphic dependencies is showing images. This is where your work pays off, once all your dependencies in the last step have been defined then you can group similar things together and start making a structure of some sort. This structure will eventually become your game engine. Here is a quick layout diagram of how the pieces fit together after combining the dependencies.

Noticed how I grouped things. The dependencies that overlaps went off into their own separate object so code duplication is minimized. As you start adding more functionality more things will get moved around and eventually you will have a huge web of things that depend on other things.

Can I Start Coding Now?

Sure you can but your interface to your objects might not be so pretty or standardized. Making your code standardized makes it easier for you to program the main game with. For example: consider things like movement. An NPC and a monster shouldn't have totally different movement functions, they should be the same. It doesn't matter what you decide on, just make sure it's clear to you what you are doing and document it in your code in case you come back to it at a later time and forget. I personally use doxygen (http://www.stack.nl/~dimitri/doxygen/) to generate code diagrams and functionality lists. Take a look the examples at their site to see what I'm talking about if you've never heard of doxygen before.

Here is a sample bit of code to generate documented with doxygen.

/// Moves an NPC
/// @Param x, a float – the horizontal amount to move the NPC
/// @Param y, a float – the vertical amount to move the NPC
Npc::Move(float x, float y);

Not only does this format make it able for doxygen to generate documentation for you but it also is easy to read in the source code itself and fully explains the functions purpose.

Final Thoughts

Designing is a hard time consuming process but even a little bit of design goes a long ways. I don't have all the answers and everyone has their own way of designing games. This is just one of the methods I have used successfully in the past.