Twelve steps to make games (1/2)

Like in all other scientific field, we need to have a certain methodology. If you start coding directly your game, I can bet your game will be either very small or unplayable/unfinished/etc. To make great games, you need to follow some steps.

1. Searching ideas
If you don't have the idea of the millennium, it doesn't matter. You have different possibility. Either you have an original idea that was never seen before (the first FPS, STR, RPG, or even the first game using skills, upgradeable weapons, achievements, etc), or you played original games and you have idea how to improve the gameplay or in general the user experience. A new concept is relatively hard to find, sometimes it comes during the night (dreams are a powerful idea engine), or by looking at the nature / people / common actions. Look around yourself and analyze each thing in the piece. You have a lamp ? Ho a shadows based game with infiltration... You have a mosaic parquet ? Ho you invented Tetris... etc. Each object in the life could be the main subject of a game. Imagine your computer speakers, you could take them as weapon and shoot wave on poor enemies... The imagination doesn't have any limit !
2. Putting ideas on paper
   When you have a nice idea, you need to test it. If the idea doesn't pass the test, it is useless to continue with it. You need either to modify it or to change. Testing is quite simple, you need to draw some little shapes that represents your concept and try to play them. If it's boring, not fun, annoying etc, the test is not successful. One of the problem of this technique is that it's your idea, and a personal idea is always good for the person itself (in general). My advise is to test with your friends / family / cat. Ask them to be honest, it's some days of work that could be useless if they simply tell you the idea is nice to avoid to hurt you. I prefer a friend tells me my idea is bad than working a week on a stillborn game.
3. Drawing some diagrams
Imagine the interface you would like to have in your final game. Draw some boxes, put names and functions on them like. Using Inkscape this task becomes really easy.



Lo-fi prototype

You must using only simple colors, simples shapes. We call it a Lo-fi prototype for Low Fidelity. The goal is to have a general look for the game interface. When you have all elements you want, go to the next step.
4. Thinking about software architecture
   At this point you shouldn't have written anything. You can look at your interface and distinguish some class of object. For our previous example, you have circle, some purple and one red, three panels, one for game, one for score and one for the life. Try to extract some object concept from your idea. When you have a certain amount of concepts (it's better to have all at once but we are human and we can't think directly in the perfect way), you can draw some links between them. Like the score panels observes the game logic, the enemies circles are linked to the hero circle, etc. You should have a nice starting diagram at this moment. Ideally, no concept is alone, if an object has no link with the other, there is probably an error.
5. Start coding
   Now you have a class diagram, some design concepts and lots of impatience to code all those things no ? Make an ActionScript 3 class for each things, try to show the hierarchy previously found.



Very simple hierarchy

When you have the skeleton of each class, you can finally start coding. The coding part is not as important as we can think initially and must not be an important part. The design (graphical and gameplay), the architecture, etc, must be more important. The code is simply a tool we use to expose our ideas. Keep that in mind. Do no confound code and algorithm. A nice algorithm could "create" gameplay, code doesn't. The importance of the algorithm is out of the goal of this tutorial.
6. Testing each little part incrementally
   You need to understand something that is really important in any development, that is right for game making, computer science in general but also in any other scientific field. We can't advance if you don't have solid basis. Imagine your architect builds your house on a unstable ground... The tests are the things that make your work easier when you have something that grow. If you have a coordinate mapper, test it, because when you use it, you assume it has no bug. Imagine you use it in an other class, but there is a bug with 0 (typically) and when you run a little example, the new class appears to have lots of bugs. But actually it was the coordinate mapper, but before thinking it is that you have perhaps rewrite three times your last class for nothing. Considering the tests with high priority. It's the protection you take against the evil bugs ! When you have tested a class under all angles, you can use it in other projects without problem. You can think about a stable system that hasn't side effect and I can affirm that is a real pleasure to have well-done bricks to build a game.