The recommended steps for gamedev?

Hi,

Let me suggest a simple method for planning:

1- write out your game idea like you feel it: what is the game goal, a few drawings of screen outputs.

2- organize this into a simple design document using the following topics:
.a- introduction: quick description of the game, who is the target player
.b- scenario: what is the context of the game, who are the contenders, what is the aim, ...
.c- rules of the game
.d- look and feel: how will look each step of the game (menu display, in game display, graphic features, music used at each state of the game, sound effects to play, etc ...)
.e- target platform: detail what is the target computer for your game.
This document is easy to write since it is your idea: it helps to narrow down to the last detail what you want the game to be.

3- Using your previous document, write out the program specifications using the following topics:
.a- interfaces: list and describe all interfaces needed to be developped (load/save game format, level format, ...)
.b- data representation: list and describe each object data (global architecture, unit class, map class, scenario class...)
.c- interaction: for each game state, describe how each previously described object interact, how the player interaction is detected, etc...
.d- planning: list and describe each step necessary in your development. Order these steps in function of their dependancies (e.g.: create first the main window, then develop the texture manager, then develop the splash screen state, ...)
.e- deployment and maintenance: describe how the finished game will be provided to the target customer (list libraries needed to be shipped) and describe how you will take care of ulterior game evolution.

4- Now you can start coding following the program specifications and refering to the design document to check you respect the look and feel.

There exist more complete document models (I use some of them for my daytime job) which add more information and more complexity. However these steps are simple enough to get you started and interesting to add in a portfolio if you wish to enter the industry.

Ghostly yours,
Red.

Here are some notes I took in my SE class this evening. It's a description of the waterfall model and may be more relevant to game development then other models:

[Analysis]	-Needs of the customer/business	-Feasibility (staff, technology, practicality, resources)	-Documentation: Requirements/specifications document	-Project Planning: Estimation of resources/planning[Architectural Design]	-High level design	-Creating a blue print of the system	-Large scale partitioning (break things out)	-Deliverable: design model/blue print	-Project Planning[Functional Design]	-Low level design, down to function calls and data structures	-Every function is documented with its call arguments and return types	-Business rules and behaviors	-Deliverable: Functional Specification - an API document	-Think of this as "programming contracts". Any proficient coder should be able to use the functions effectively.[Coding]	-Creation of the software	-Programming: C/C++, PHP, MySQL, Web forms, java, ASM, etc.	-Create user/operation documentation, help, training	-Test to the functional specification[Integration and Testing]	-Combining parts of the system and testing emergent properties	-Deliverable: Bug fixes, faults that need to be fixed[Deployment]	-To put into "production", migration from current systems	-Support and operational tools available for usage

The general idea is that you've planned everything out in so much detail before you write the first line of code that the coding process is a mechanical exercise. When you code little parts of the game and design as you go, you're setting yourself up for headache at best, complete failure at worst. I remember trying to write a chess game like this. The underlying structure of my code design was short-sighted and didn't consider how I would incorporate an AI player. If I wanted AI, I would have to scrap just about everything and start all over.

Also, when you detail out the exact mechanics of how stuff works in your game (algorithms, game play mechanics, data structures, etc) you force yourself to understand how something works before trying to code it. It's a much better and more sane approach then to try to code your way into a solution for a problem you don't quite understand. Design first, have 100% understanding, THEN code. :) 90-95% understanding may not be good enough.