🚀 go-pugleaf

In article <76626@ut-emx.uucp> baylor@ccwf.cc.utexas.edu (Baylor) writes:
>	I'd love a games library (I assume this is really a sprite 
>library; no hack and no reason to intigrate a good infocom parser).
>Many of you know that i've leached more code from you guys over the 
>past year than anyone else I know. I beg for code from different people
>to do things I quite often can already do.

(Baylor makes some good points here.  I'll use his message as sort of a
jumping off point for some related discussion.)

I suspect the folks who are more interested in a game library for its
educational value are in the minority.  When you use C++ (or Pascal
with Objects, to avoid the current debate), do you really have an urge
to get source for the compiler so you can "learn how to write your own
code?"  If your library were more than just a patchwork of routines why
would you care how the system worked overall, beyond what you needed to
know to get the most out of the system?

The argument that you should be able to subvert all the system's
freatures is parallel to an argument that says you should have source
to your C compiler so you can change the language syntax as you see
fit.  In general this is a bad idea since it's a substantial virtue to
have all people speaking the same dialect.  Suppose there were a
whizbang game development system for PC's: think about how difficult it
would make discussion if everyone had their own customized add-on
routines!  Portability is a good thing not only for porting, but for
cooperation as well.

When I write a program in C, I almost never care what the resulting
assembly looks like; likewise I care *even less* about how the compiler
does its job, *as long as the resulting exectuable works*.  I certainly
wouldn't go and edit the GCC source to change the for loop syntax to better
suit my liking; perhaps that's just me though.

I think the idea that a game library should be educational is simply
provoked by an outdated idea of what a game library (or a game
authoring system in general) should be.  If, when you talk about "a
game library," you're only considering a small, ungeneralized set of
functions for blitting objects around the screen and making some bleeps
and bloops on the console speaker, you're not really talking about a
"game system" at all, IMHO, anymore than you could classify a little
suite of your own favorite file handling utilities as an operating
system's I/O subsytem.

A game system is a massive undertaking, even if it's for a fairly
limited set of game styles.  Mike Roberts has been working on TADS
since 1987 or so, and that's just for text adventures.  The reason that
everyone (as a previous poster mentioned) starts their own game library
but bever finishes is the same reason most people start a *game* and
never finish, or start a *novel* and never finish.  It's a lot of work,
and requires *years* to complete.  As with all things in computer
science, it's easy to talk about but much, much harder to *do*.

Game systems are also geared towards niche markets.  Sure, *you folks*
might give your eyeteeth for a good game system, but how would the
potential sales of such a system compare to word processor sales, or
compiler sales?  And following that up, if writing a game system is as
difficult as writing a word processor or compiiler, why would any
company write a game system instead of a word processor or compiler?
Why would any company put up all the money to finance the development
of such a labor-intensive and (at the same time) risky product?

Not only that, but a top rate game system would have to have as much
documentation as a good compiler, and similarly good technical support,
and believe me, these things are not easy or free.  It's not clear that
the market could even support the kind of game system you're looking
for, even if someone invested the time required to write it in the
first place.

>	That's because I love seeing how other people do things. I've never  
>actually used anyone else's code before - i just print out and highlight
>things that strike me then see if I can rewrite it from memory and quite
>often run it through several reference manuals.

In my opinion, the place for this kind of instruction is textbooks.
There really should be some texts on writing games, even if they're
specific to a particular platform.  The problem is that no game writers
want to write books; they want to write games.

>	The graphics books out there don't really cover anything to useful
>to games programming (except maybe the never-can-find abrash book).

For a real laugh, look up the "animation" section in *any* porpular PC
graphics book.  What a joke!  They'll tell you to use XOR for pete's
sake.  Or "simply erase the old image and draw it in the new location,"
as if you could actually get any decent results without some
approximation of double buffering (page flipping).

(BTW, does *anyone* have a copy of Abrash?  Where can you get it?  I've
tried every big bookstore I know and no one's ever heard of it.)

What the PC-UGLY crew should do is write a book.  I don't think library
design is manageable (as has been evidenced here annually), and
language design by committee is even worse (e.g., Ada), but perhaps a
book would be easier to coordinate.  There's already a lot of
documentation available on the net (including source code) -- a major
part of the task would just be assembling the pieces.

Dave Baggett
dmb@wam.umd.edu