Re: Where do I begin?

[Mark D'voo <line72@postmark.net>]

On Thursday 10 January 2002 04:39 am, 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>

Speaking of Crystal Space and PLIB, which is better?  Are there any 
alternatives for Linux gaming besides these two ?

mark

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

-- 
  9:33pm  up  4:15,  1 user,  load average: 0.38, 0.23, 0.08