Re: Where do I begin?

[Bakemono <bakemono@scurvypenguin.net>]

I tend to wait on step 1, 2, 3, and 4, and use things like spheres and 
single giant polygons to represent the player and the landscape and such 
(you might not need anything for the player if it's a FPS).  Keeping 
your priorities straight is possibly THE most important thing when it 
comes to large projects.

-Bakemono


Steve Baker wrote:

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