Write your own lib : the 3D case

[Bert Peers <rat@larian.com>]

(Sorry about the delays but my ISP is broken, all I
can do is spool email about once a week...)

Ok, can't resist, here's a few cents on the To Lib or
Not To Lib discussion :)  It's long and I'm not sure if it
goes anywhere, read at your own risk ;)


I was surprised to note that obviously experienced
people like Steve and Jorrit vote for a single library, unifiying
whatever exists now, based on the argument that everything offers
the same functionality, and consequently any implementation
of that functionality/interface is a duplicated effort.  I mean, if
anybody, exactly these guys should know that as soon as a
project is started at the scale of a 2D, 3D or even GUI lib,
design tradeoffs have to be made.

Every programmer knows there's not just one way to
store elements; depending on what you want to do, there's
lists, arrays, bintrees, k-d's, etc.  The same goes for 3D; the
problem starts with the storage of mesh files and/or the world :
connected faces, BSP, octree, ... for meshes, BSP, PVS,
octree, ... for the world.  While a good container lib would
probably offer more or less every container type, not forcing
the user into using one or another, a 3D library usually makes
its choice, and from then on every algorithm is fixed for that
particular datastorage.  To some extent I see CS trying to
offer the same choice by splitting up rendering applications into
outdoor and indoor for instance; but there are still too many
decisions to make that will influence how everything works,
from collision detection and physics up to the possibility to
have inverse kinematics, and if so, how to do it (just to name
something).

Basically, I agree with someone who posted that the use of a
particular lib gives a game a particular feel.  All those design
issues made in building the library are visible in the way the
games using that lib look and feel.  For instance, for an
experienced player it is obvious that Half Life is a Quake
engine clone, whereas Klingon: Honour Guard is an Unreal
engine clone.  From the way collision detection works for
instance, you immediately "feel" Quake when you bump into a
wall or an enemy or do your first strafe jump.  As a trivial
example, the fact that a player standing on a rotating brush
doesn't get a rotating viewdirection in Quake is a dead giveaway
for any game that doesn't fix that after licensing.  The same goes
for the look of it : Unreal computes and renders it lightmaps in
a different way than Quake, and again you can see this by the
way the world looks.  And if nothing else, the different particle
systems and procedural textures of  Unreal are again a giveaway.
So yes, what library you use affects how your game looks and feels;
there's always only so much you can parameterize.

The argument that games don't have a C/C++ look and feel
is a moot one.  C and C++ are languages, they're only a medium
in which you can express your own algorithm; they do not place
any restrictions on what you can write.  CS and thelikes on the
other hand *are* the algorithm; they're not a way to express your
collision detection, they *are* the CD.  Consequently, every
tradeoff made in getting the necessary algorithms running is reflected
in every part of the game using that algorithm, unless you rewrite it.

I think it will actually get worse in the future, when it comes to
the proliferation of libraries.  It should, too. I agree here with
Carmack's comments on "The Golden Era of the Triangle" :
up to now hardware was pretty restricted in what it could do,
and consequently every game looks more or less the same.
Am I contradicting what I said two paragraphs back ?  No,
there still were differences : lightmaps, CD, kinematics,
particle systems, etc.  But the basic architecture of any FPS
or racing game always looked the same : restricted polygon
counts basically mean every game takes place in a glorified
empty box.  With cards that'll do millions of polys per second
there'll be a choice again -- or if you want, a new category of
design tradeoffs to be made in building a lib : use the extra
polys for detailed architectured, like Quake 3 ?  Use them for
highly tesselated NPCs, like Messiah ?  Again, I can see how
CS could be extended to facilitate making either choice, but
imho it gives viability to the idea of having multiple 3D libs
each doing their particular thing (which is also what's happening
in the commercial world : Quake3, Unreal, LithTech2, etc)

My point ?  Well, naturally I agree that there is only one good
way to read a joystick, mouse, keyboard, play sound, etc.
But when it comes to anything of some complexity, there will
always be design issues that can be solved in multiple ways --
even if the final functionality/interface/API offers the same
capabilities.

Looking forward to your reactions !  See you next week :)

Bert
--

-=<Short Controlled Bursts>=-