[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Where do I begin?
On Wednesday 09 January 2002 10:39 pm, you wrote:
> 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
Shameless Steve, Shameless.
> > 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.
Ahhh, but, you need to type stuff for that, and if it's only a quick thing
(like, I want to turn off the sound for this bit), you prolly don't want to
have to quit the entire program, add a switch, reload all the data etc etc.
> However, with modern GUI builders, you can throw together a simple menu
> scheme in pretty short order.
Another plus for using shared objects. You can design the interface in Kylix,
or some other crap that like, then just call the game engine from there...
> > 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.
I'm writing the manual for VectorC, an optimizing C compiler (Linux version
due out in April). I like to squeeze every ounce of CPU performance I can,
which means nothing wasted on scripting languages. But, that's just me.
> > 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.
Well, this is even more important because it is his first ever game. If he
dives straight in without thinking about how the whoel structure of the game
is going to work, he's going to come unstuck very quickly. It doesn't need to
be 100% copmlete, documenting every single function he's gonna define, but
some simple pseudo-code would help, like this...
Game state = MainGame
Else If MainGame
Game state = Scores
Else If Scores
I do that (but in much, much more detail) for any serious project I'm working
on. It doesn't take long, and if you prefix all the commands with "//", you
have all your comments there for you too (just fill the in the code at the
Even for a first project, thinking about the structure of the thing IS
required, and even pro tech. specs. don't get finished until after the
project is complete.... (Have a look at the Operation Flashpoint postmortem
on GamaSutra, they didn't even have a design document)
> > 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
Man, even the "pros" have problems with that stuff. If I had time to tell you
some stories, you'd be shocked...
> > 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!
And someday, I'll get round to finishing my second game :) (commercial titles
not included) (To be completely honest, I did write 4 versions of Spong, so
it's not all bad. One day, I'll get to updating it).
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