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.

  • \$\begingroup\$ -1, too vague and doesn't really ask a specific answerable question. \$\endgroup\$
    – Tetrad
    Oct 29, 2010 at 15:49
  • 1
    \$\begingroup\$ i am learning my way to program game, but splitting my code into different files causes me problems to understand, so i need some sort of check list or to do list, so it will give me some clear picture. \$\endgroup\$ Oct 29, 2010 at 16:01

4 Answers 4


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
  • 1
    \$\begingroup\$ Thanks Ari, your answer is more appealing towards my problem. \$\endgroup\$ Oct 29, 2010 at 17:14
  • \$\begingroup\$ @NativeCoder glad I could help. @Ricket Thanks for correcting that mistake :) \$\endgroup\$ Oct 30, 2010 at 0:30

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.

  • \$\begingroup\$ Those units are far too small to call it a spiral model. You're probably wasting a lot of time, or not really doing a spiral (or maybe both). \$\endgroup\$
    – user744
    Oct 30, 2010 at 15:10
  • \$\begingroup\$ +1 for Spiral, But I think you can simplify your process for solo development =) \$\endgroup\$ Oct 30, 2010 at 15:56
  • \$\begingroup\$ @Joe Wreschnig Not sure what you mean. Each spiral is a design-build-test-(internal) release step. I mostly left a lot out to make it fairly easy to understand. The first spiral usually involves a good bit more than opening a window like the game's main menu and overall structure. It also focuses on non programming related tasks like source control and deployment setup. Also as an hobbyist it is very informal and more focusing on doing this or that than strict discipline. \$\endgroup\$
    – stonemetal
    Nov 1, 2010 at 16:55

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..


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.
  • \$\begingroup\$ That second point is a particularly good one! I'm getting caught up in the details of my own 'engine' too, rather than my own game which is far more important! \$\endgroup\$
    – user631
    Oct 30, 2010 at 18:47
  • \$\begingroup\$ I agree entirely there, I suffer from it all the time. And the gamedev.net forums, which I look around, are full of people saying 'I know some C++/Java/C/Whatever, how can I make a game engine?' \$\endgroup\$ Oct 31, 2010 at 9:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .