[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Where do I begin?
On Wednesday 09 January 2002 3:09 pm, you wrote:
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: email@example.com Phone: +44 7761 774 152
Email: firstname.lastname@example.org Spam: email@example.com