Hello, Sorry to create another thread, but I felt this topic was different from my other. I've been reading a few articles about the process of game development, and the various processes being used. These processes included the waterfall method (quite old and problematic-Linear) and the "Rational Unified Process" (a little bit more non-linear, less problematic for big companies). My question is: What method is used by small indie companies? Do most people go about linearly (Idea->Story->Conceptual Art/Scripting->Finalizing Art/Scripting->Programming Engine->Content Creation->Testing etc.) or non-linearly (out of order)? Does someone else have an effective process they would like to share? Any other comments? Thanks! Cheers! -Dyamios

Programming "processes" can be helpful for large, team-driven projects, if only because they help keep everyone working on something useful. You're unlikely to find yourself working on a component that you hadn't realized was obsoleted by your teammate's work, for example. For smaller, one-man projects, they tend to be more overhead than they're worth. It's definitely worth thoroughly thinking through the design of the game before you start, so that you don't find yourself having to rewrite the blasted thing halfway through because of irreconcilable design weaknesses, but once you have a solid design, I'd say just jump on in and get to work!

Though I do have one piece of advice for putting the program together - make certain you can test each element as you build it. For example, if you want to make a 2D sprite-based game, start with a simple program that just initializes your drawing subsystem (OpenGL, DirectX, SDL, etc) and then loops, drawing an image to the screen. Once you have that working, implement the class from your design that will be holding the image, and draw it that way instead. Work from the very simple, hardcoded "example" level to the abstracted, general-purpose "finished" level. This allows you to get visible results early, and to have simple systems to debug if something doesn't work. Definitely don't write 1000 lines of code before testing any of them; that's just asking for marathon debugging sessions, and nobody needs that.

Good ideas Derakon!

Your suggestion is exactly what I have been doing, and its working well! I now have a class for Direct3D, Sound, Music, and am currently creating one for the tiling engine.

Does anyone have any suggestions on how to handle game "states" if you will? I have been adding classes for each "state" (for example, the intro credits would have its own class, and the menu screen would have its own class, etc.), but I was wondering if there is a more effective way of handling this.

Thanks!

Cheers!

-Dyamios

Just as an FYI, these kinds of threads usually show up in Game Programming, not Game Design. :)

Anyway, one suggestion I've seen for that kind of thing is to have a "stack" of game states. When the game first starts up, you push the "main menu" state onto the stack. The the player navigates the menu, and, say, goes to the controller config page; you push that page onto the stack. When they're done with the controllers, you pop that page and return to the main menu. Then you start the game, et cetera, et cetera.

To do this, clearly you'd need some kind of class to insert into the stack; whether or not you want it to do more is up to you. The big win here is that transitions from one state to another are handled cleanly; you don't need each state to be aware of where it came from; it just needs to be able to add more states and dismiss itself.

Component or object based development is defently your friend when it comes to projects. If you can test each component in isolation and its interaction with other components you will save yourself a great deal of time and effort. Especially as you will no doubt end up rewritting many of components during development.

There are a number of different ways you can handle game states but the easiest and most straight forward is seperate classes. Alot depends on what you want to achieve though.

Thanks for the help Derakon and TechnoGoth!

The original point of this thread was for all steps of game development, not just programming, but I think I've got everything figured out.

Cheers!

-Dyamios

Quote:

Original post by Derakon Anyway, one suggestion I've seen for that kind of thing is to have a "stack" of game states........

I found it easier to enable/disable states instead of pushing/poping from the stack. This way I can ensure the order of the gamestates are always the same(start->meny->game->ingame_meny->console instead of start->game->meny->console->ingame_meny) and no dublicates exist.

Handling each state yourself does give you more control in a way, but a correctly-written stack is easier to deal with. The only thing you need to watch out for is that there are no loops possible in the UI. So the "main menu" link on a page that is reached from the main menu is actually a "pop this page off the stack" link.

Ah, I see. I've read about stacking in my books but they dont give any good examples.

I kinda like the idea of stacking. I'll have to try both methods and see which works best.

Off to google I go! =P

Thanks again guys!

Cheers!

-Dyamios

Quote:

Original post by Derakon Just as an FYI, these kinds of threads usually show up in Game Programming, not Game Design. :) Anyway, one suggestion I've seen for that kind of thing is to have a "stack" of game states. When the game first starts up, you push the "main menu" state onto the stack. The the player navigates the menu, and, say, goes to the controller config page; you push that page onto the stack. When they're done with the controllers, you pop that page and return to the main menu. Then you start the game, et cetera, et cetera. To do this, clearly you'd need some kind of class to insert into the stack; whether or not you want it to do more is up to you. The big win here is that transitions from one state to another are handled cleanly; you don't need each state to be aware of where it came from; it just needs to be able to add more states and dismiss itself.

I use this technique and have found that it works wonders (as long as you manage your game stack responsibly). I wouldn't have it any other way frankly. [smile]


Note that the implementation might require different tweaks that are dependent on your game. For example, my mode manager (we call all our stack items "game modes") handles multiple "map mode" implementations at once. This is because the player is likely to return to a map from whence they came and we would rather keep this mode in memory rather than load it all over again. So the most recent map mode on the stack is automatically removed from the stack.

Another case: when we enter "pause mode" we do the same thing every time (save a snapshot of the screen, apply a darkened masked, and display "paused"). However, we don't want the programmer of every game mode always have to check for a pause input event given by the user, so instead the game's input manager handles pause events internally so we never have to worry about them (actually, all the game mode has to worry about is what to do with audio on a pause event: should it pause the music, turn the music volume down, etc. Some specific scenes require audio to be synchronized with the visual action). Also, it doesn't make sense for the user to pause the game from the boot screen (what is there to pause?), so in that case the game's input manager checks the top stack item (which we call the "active game mode", or AGM) and makes sure that pausing makes sense for this AGM.

I could point you to some web-browsable (GPL-ed licensed) code that implements this and some documentation if you wish.



Anyway with regard to the main topic of the thread, I do not believe there to be a most effective indie process (I've been doing this for two years now, so I kinda have some experience to back up my opinion). I think that some of the biggest factors are team size, the collective game design experience of the team, and whether you are a for-profit or non-profit project.