Twelve steps to make games (2/2)

The second part of the tutorial about work flow for game design. This is a possibility, not the only one, don't follow each step strictly, create your own work flow using this example.

7. Assemble the parts together
   Mixing all the previous things together is quite hard if you do that directly. The main problem is the spaghetti effect. You have multiple class and each could have some links with other, so the solution for lots of developer is to put a reference on each class to each other class. Conceptually speaking, it's just horrible. Try to join similar class, to make some "helper", to use composition with precaution and not as the unique solution. You can also implement a system of message communication (I will put an article about that later).
8. Test the gameplay
   Don't think it's the funniest part, it's the hardest actually. Why ? Simply because you have created the gameplay and you must be objective to see some default ! The gameplay must be quasi perfect, it's the thing that allow the user to "play" literally. If your hero moves too fast, the player has not the experience that you wanted. This must be the extension of your concept, not a tool to communicate with the game. Try different games and observe attentively how the objects move, the events appears, the character jumps etc. The gameplay needs to serve the game !
9. Improve the graphics
   Yes, until now, I never speak about the graphical part of the game. It's not without reason. Before this point, your character must be a circle/square and all other things too. If you spend too much time drawing/designing things, you could have some problems when debugging especially. Imagine your character has a sword but when you are near a wall, the sword is "on" the wall, you could think it's a problem of collision but actually it's just that the sprite you use is bigger than what you had planned. One of the problem when you develop alone it's to manage a certain balance between working hard on graphics and trying to find perfect gameplay. My opinion is that we need to endure the graphics to have fun with gameplay, for little flash game of course. If you want to make the next best-seller you need to have some artist in your team.
10. Making little beta
    To have objective feedback, you need to find objective people. Of course, friends are never really objective, either they want to be cool with you or you bother, but having a real objective opinion is quite rare and if so, you need to filter all other. So, the easiest way is to publish on a website like Flash Game License (FGL). Initially it's a site to sell / search sponsor but you can enable the view by other develops and preview players, they will let feedbacks to improve your game. You can also try on little forum to have a dozen of constructive feedbacks. When you have improve the more relevant issues, you can go further.
11. Publish the game
    To publish a game, you have some different possibilities. First is to publish manually to big portals and hope your game is nice and people likes it, in this case, little portals will take the games and you can let the viral distribution working. To have such portals, try the two following lists that I found: 45+ on Mochi, 35+ by Emanuele. The second main possibility is to use Flash Game Distribution (FGD), this site will send your game plus some informations to a very large network of portals. The disadvantage of the second method is that your don't control directly the submission, perhaps you want to submit only one portal per week to spread the success during three months. If your game doesn't have a lot of success, try to find where is the problem. Is it the gameplay ? The idea is not as good as you thought ? Perhaps the execution, graphics are not enough good to support the ideas ?
12. Learn from the experience
    When you have finished a game or any other part of your life actually, take a moment to sum up. Weighs the good and the bad things you did during the period and try to extract some useful informations. Perhaps you loose too much time debugging ? In this case search a new way to test your code, it could increase your efficiency. The goal after an experience is to learn something, even the experience was very bad, you can derive an advantage. 

Don't forget, if you have some games, send them to me, I could publish them and ask reader to make objective feedback, like a little beta.

Last tips: Take pleasure in making games !

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.