how to breakdown my game project?

Question

I am a newbie so when ever i start over i get stuck how to organize things (code) or what should be the order of my work. Can you share your experience of project granularity so i can make my mind what should be done first and so on.

Answer 1

Here are the general steps I would go through:

1. Understand what your goal is - Without a clear understanding of what you're trying to achieve, you'll have a hard time completing a project of any scale.
2. Write the rules down on paper - Every system has rules. Take the time to write them down in bullet format. This will get your brain thinking about the logic, and will provide you with a handy reference to use later on.
3. Rewrite the rules to follow the programmatic flow - Keep the rules in bullet format, but reorder and indent them, so they form an outline of the programmatic flow.
4. Write the pseudo-code - Using your outline as reference, write out the pseudo code.
5. Create the classes - Make a list of classes you'll need, based on your pseudo code, and implement them.
6. Replace your pseudo-code with code

The process is a little slow, but it has a number of benefits to someone in your situation:

• Each step creates documentation that can be referenced in future steps
• You have multiple opportunities to catch mistakes in your logic before you ever touch code
• It's very easy to see how logic should breakdown into code

Answer 2

Mostly it sounds like what you need to do is read up on software engineering. The approach I use is called the spiral development model. In this model you repeatedly do the software development cycle(design, code, test, release) on an ever slightly expanding project.

Lets say we were going to apply this to a 2d shooter.

first spiral open a window.

second spiral get player on screen and moving to user input.

third spiral get enemies on screen.

fourth spiral be able to shoot stuff.

5th spiral ad AI to enemy units.

6th spiral polish.

Answer 3

I recall this tutorial being quite helpful in learning to refactor and (re)structure code - while doing something fun (physics engine with opengl visualisation). I especially enjoy the way test-driven development is introduced in a fairly practically way..

Answer 4

Make sure to know what you're doing. Have a definite plan, design document, whatever - you don't want the problem of 'done that, ooh this sounds good-I'll add this. Oh and this and maybe I'll try adding this thing I just though of'.

I cannot remember if this is top down or bottom up. It's one of them. But if you're newbie, a very important point is to get stuff done. I mean:

• Don't spend weeks on a highly generic system.
• Make sure you make your game, not an engine.
• Get stuff on the screen. This is the best way to make sure you stick with it; you'll feel better about having a square moving around shooting red balls than having a 2d sprite animation and component system and not even a window open.