Re: Where do I begin?

[Steve Baker <sjbaker1@airmail.net>]

Mark Collins wrote:
> 
> On Wednesday 09 January 2002  3:09 pm, you wrote:
> <snip>
> 
> The list steve so gravially provided assumes you have a basic 3D engine
> going, or are using a 3rd party scenegraph API to do everything. Some of us
> like a challenge, and code this stuff ourselves.

Yes...but he already said he was going to use CrystalSpace - so that's a given.
<shameless-plug>Although he'd find PLIB easier to learn</shameless-plug>

> The first thing I tend to do is get a basic app going, which includes startup
> code, basic graphics stuff (such as displaying a 3D model), simple user input
> and an interface for getting various bits of details (i.e. framerate, polys
> in the scene, displaying surface normals, turning texturing/lighting on/off,
> and general stuff to help debugging in the future).

Yep.
 
> Once I have this, I start working on a basic frontend interface. Experience
> has taught me this is a good thing to do early for 2 reasons: 1) Once you get
> it out of the way, you don't have to worry about it and 2) It can make your
> life so much easier (for example, loading games from a menu, settings options
> from another menu etc etc).

Well, yes - but I tend to make this *very* basic and non-glitzy to start with.
Typically a command-line parameter to specify the model to load and some simple
keyboard commands to change levels, etc.

However, with modern GUI builders, you can throw together a simple menu
scheme in pretty short order.
 
> At this point, I start building up the game itself (everything up to here has
> been pretty generic). I find having a basic level is the best thing to do
> first, as it gives you a lil' reward to see something decent on the screen.

Yes - exactly.
 
> 3) Performance boosts. I'm not sure
> how fast Python is, but I doubt it's as fast as standard compiled code.

I estimate it's about 50x slower than C++ - but you aren't generally
running much code for AI (although some of the support functions like
line-of-sight testing, route planning and collision detection will be
slow - you can keep those in C++).  The additional flexibility is worth
the extra couple of percent of CPU time IMHO.

> One of the most important things, however, is to have a very detailed
> technical design from the start.  This covers everything from function
> parameters to file formats. If you don't, and have mroe than one developer
> working on the project, you will most likely run into serious problems.

This is where I disagree.  I mean you are right that this is "A Good Thing"
for an experienced game programmer approaching a huge project - but we are
talking to a guy who is writing his first ever game.  He won't *know* what
things to put into his plan or what is good or bad until he'd gotten his
hands dirty messing inside the code.

> On the subject of multiplayer, I find it's better to think about this at the
> start. If you aim for a client/server model from the start, migrating the
> codebase from single-player to multiplayer is a piace of piss, esp. if you
> use the Quake III-esque system of always assuming multiplayer, and just
> running a server for some form of IPC.

I agree - but again, only for people with lots of experience.  This first game
is (realistically) not going to be **great** - and some of the nastier issues
of multiplayer (well - networked multiplayer at least) are best left out of
a first project.  All of the ugly problems of latency, simultanaity, cheat-protection
are really something you need to tackle once you've got past the basics of
"How do I move the player" and "How do I render an explosion".
 
> As someone who once added multiplayer support to a commercial product that
> wasn't designed with multiplayer in mind, I can tell you it's not an easy job
> if you have to navigate a codebase and find the best way to do things.

Yes - but remember I said "Plan to throw the first version away".  That's
because adding things like multiplayer will likely be the kinds of things
that force that rewrite in the light of practical experience.

What Mark says isn't wrong - it's just directed at someone who is writing
his *second* game!
 
----------------------------- Steve Baker -------------------------------
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