Re: Where do I begin?

["subnet_rx" <aaron@hubfirst.com>]

Nothing but exactly what I wanted.  Thanks Steve.

----- Original Message -----
From: "Steve Baker" <sjbaker1@airmail.net>
To: <linuxgames@sunsite.dk>
Sent: Wednesday, January 09, 2002 9:09 AM
Subject: Re: Where do I begin?


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