Re: Where do I begin?

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

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
> learn</shameless-plug>

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

========
Entry Point
    Init Graphics
    Main Loop
        If MainMenu
            WaitForKey
            Game state = MainGame
        Else If MainGame
            Read Input
            Process Input
            Update AI
            Draw Stuff
            If GameOver
                Game state = Scores
            End If
        Else If Scores
            Display Score
        End If
    End Loop
    Shutdown Graphics
End Program
========

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

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
> explosion".

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: me@thisisnurgle.org.uk	Phone: +44 7761 774 152
Email: nurgle@isyourgod.net	Spam: spam@thisisnurgle.org.uk