Planning Your Game

[torleif]

So I have some concept art, half a level in blender and now I want to start some coding.

Usually I dive into it. I'd pick an example that was similar to what I wanted to achieve for my game (like puppy! which was movement demo) and hack it until I had something that worked. This time I want to do things properly.

What should I do now?

What is the right thing to do? UML? pencil and paper and study the API? or even simply prototype and expand? Should I rely on the irrlicht game factory, or rely on my own code?

I have a game plan written, but that doesn't elaborate on the details of code side of things.

All these questions I'd love to hear your opinion on, especially if you're a Irrlicht guru

[jeetee]

You have a gameplan, so let's try and use it to your advantage.

What I usually try to do (mind you that I'm far from a game-guru ):
1. Make up a gamescenario, draw some concept-art.
This is a really chaotic stadium, in which I write down/draw everything that's in my mind, and only filter it afterwards.
2. Once the description of the game is more or less finished, start extracting entities out of it. A possible way to find those are asking questions like: What are interactive parts? and What are the actions this entity(player/npc/item/potion/weapon/...) can do?
Try listing them for all possible entities.
3. See if you can group those entities, and determine how they relate to one another. UML can be of great help here.

Bullets are items that can be stored in a bag or a gun, that can be bought, so they need a price, and that are consumed/used by a gun.

This teaches us that their is an entity 'Bullet' an entity 'Bag', as well as the entities 'Shop', 'Gun', 'Item' (more differentiations can be made)

4. Now make sure you have a clear listing of all your entities (classes) and check the functionality (methods) for each of them.
5. In the meantime, work on some graphics
6. Split your game in seperate parts (milestones) that can be tested. Do not firstly create all enemies/items if you only need part of them in the first level. This way keeps me motivated to continue on a project, for there's relatively fast something playable, something 'real' to see.
7. Investigate what libraries you're going to use (iirLicht for graphics offcourse , but what with sound/phisics/..). Work through their demo-applications and basic tutorials. You do not need to know their complete API's, but you do need a good understanding of when and where you'll have to use them.
8. Time to start your coding. I have the habit of firstly implementing my engine-loaders, then a level-loader, next the player as a static object. Then I start by adding methods to my player (first make sure he moves ok, then make sure if he can pick up items, to do so, first make an item etc...). However, regularily check back to your UML to see if you are implementing the correct relations.

Pfew.. there you are, my basic view on development of a game. I hope it's of some use to you.

[Virion]

that's a pretty detailed one, jeetee. good job.

[disks86]

I like jeetee's methodology.


Normally what I would to with more traditional software development is write a paper describing the functionality of the system in depth. Then go through and underline your nouns and verbs. The nouns will likely be your entities and your verbs will probably be functions.

After you have your entities and a few of your functions identify your actors. And by actors in this context I'm talking about anything that effects your system. It could be for example a process, GM, or the player.

Then go through and define your interfaces with use cases. Interfaces can be a GUI or an API in the case of the actor being a process. Each actor needs it's own set of use cases. A use case being something like player A clicks button B and the system does such and such. It is important to map your fail cases as well. Like if the player types /abcd they should get an invalid command message or the command should be ignored.

Once you have all of your interfaces well defined then you can move on to the guts. For the most part internal stuff is a matter of preference because only your interfaces will be exposed to 3rd parties.

However I have a couple of architectures I rather like. One is to have manager classes. A manager class contains related functionality. Manager classes are initialized in an Application class that is loaded in your main. Manager classes are maintain state and abstract details from calling classes. In some cases manager classes and call more specialized detail classes.

Another one I like is a stateless style. You have service classes for each grouping of functionality each service class is stateless and is initialized by it's caller. In cases where database access is needed there is a data access class for each grouping of functionality. The data access classes are accessed only by service classes. The service class calling the data access is responsible for initializing it. Also in this model there are entity classes that contain no functionality only data structures. These are passed through the service & data access layers. I normally end up creating a collection of utility classes as well. I normally use this style for web applications as state is only maintained for a post. it has to be reconstructed each post.

Happy coding!

[lancer_xjb]

it's a good help.Thank Jeetee.

[CuteAlien]

And don't forget the GUI. It is in many games the part that takes most time programming. Think about which dialogs you need and when they are visible.