Re: Where do I begin?

[Steve Baker <sjbaker1@airmail.net>]

When I write a game, I usually work in this order:

  * Build some basic scenery for one level.

  * Figure out how to load that into my budding program.

  * Build a basic (not necessarily animated) character
    for the player. (This may be just a gun or something
    in an FPS).

  * Figure out hot to load that into the game.

  * Add simple routines to move the player around with
    the joystick/keyboard/mouse (whichever you prefer)
    in a simple 2D plane.

  * Add the camera motion (this may be the same thing
    as the player motion in an FPS).

  * Now you can move around your basic level - you can
    worry about collision with objects in the game world,
    making the player stick to the ground - jump, etc.
    This is quite hard to get right.

  * Get a feel for how much detail you can model and still
    get a good frame rate.

Once you have gotten to this point, it matters less what
order you do things in - and this would also be a good point
to start bringing in other developers if that's what you
want to do.

The basic 'look' of the game is established so people know
what they are signing up to - and it should already be
impressive enough to look like it might one day be a game.

Continuing:

  * At this point, I like to get my sound engine built -
    add sound effects, music, etc.

  * Add a mechanism to change levels - reloading the
    scenery from disk - whatever.

  * Add cheat modes to allow you to change levels easily
    and to move the character with collision detection off
    at any speed so you can quickly get to anyplace in the
    game.  This is suprisingly important.

  * Other game characters...figure out how to load them,
    collision-detect/ground hug them, etc.

  * AI for other game characters.  This is something I
    find *VERY* difficult to do well - and something
    for which the available literature is pretty much
    useless.  Consider adding a scripting language for
    this - get something off-the-shelf like Python.

  * Shooting (or whatever form of combat/scoring you have).

  * Startup screens, high score tables...all that annoying
    junk that you have to have.

At about this point, you have "A Game".

  * Pretty everything up - better graphics, more levels,
    fancy lighting, particle systems for nicer explosions,
    dust from moving objects...eye candy basically.

  * Add networking and multi-player.  In terms of coding,
    this isn't really all that hard - it can be conceptually
    rather tricky though.  I don't think you should worry
    too much about it while you are in the early stages of
    development.

I strongly advise you to "Get Something Going Quickly" - that
provides the strongest motivation for you.  Don't over-plan
this stage - you'll end up getting totally bogged down in
that process.

Once you have written a couple of games this way, you may
have enough experience to lay out a complete and nicely
structured design on day one - but you won't succeed if
you try to do that while you are learning because you are
planning something you have no expertise in.

Expect to throw the first version game away - so don't
invest too much effort in making the code pretty or elegant
or documenting it.

------------------------------------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net