Re: Where do I begin?

[Mark Collins <me@thisisnurgle.org.uk>]

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.

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

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

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.

If you've designed your engine well, this shouldn't be too hard, and you can 
re-use alot of the code to convert the level-displaying code into object 
displaying code (inc. animation type crap).

Next step, in my opinion, is to do the game logic (AI and physics). This is 
another lil' self-reward thing, because now you actually have something you 
can playtest, and it will help you see if the concept works without getting 
too deep into the project. If it's not what you like, things are still quite 
small so you can (in theory) redesign without changing too much.

This also has other benifits: You can use screenshots to gain more developers 
(if it's that sort of project), and, if you're lucky enough to find some 
artists, they have something to plug their work into (remember the frontend?) 
and see it in action.

All that remains at this point is adding sound support, and finishing off the 
in-game assets. Improved graphics are prolly a good idea too.

Now, Steve mentioned using Python for the ingame logic in his list of 
suggestions. This is where I have a different opinion. My choice would be a 
generic shared object with a clearly defined interface (entry points, exit 
points, and functions the SO can call to manipulate the environment). This 
has several advantages: 1) You have more flexibility over the language used 
to code the logic. 2)  MODS! MODS! MODS! 3) Performance boosts. I'm not sure 
how fast Python is, but I doubt it's as fast as standard compiled code. 4) 
You can change a small part of the project without having to recompile 
everything.. 5) It allows semi-independant development. If you have one 
"team" working on the engine, and another working on the logic, you don't 
need as much beaurocracy once you get the basic stuff done. This is a Good 
Thing (tm), 'cos in my experience, having to nag other members of the team 
about checking a file in to the source control so you can test something is a 
pain in the ass. 

You don't have that much autononomy with pure scripting languages, as you may 
need to add functionailty to the main code for something to work.

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. It's 
also important if you're the only coder on the project, because it means you 
can spend more time coding and less time thinking about coding once the 
project is in full swing.

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.

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.

===
Mark 'Nurgle' Collins
Lead Author - Linux Game Programming (Premiere Press)
Author - Advanced AI Game Development (WordWare)
Email: me@thisisnurgle.org.uk	Phone: +44 7761 774 152
Email: nurgle@isyourgod.net	Spam: spam@thisisnurgle.org.uk