🚀 go-pugleaf

In article <1992Jul27.190320.57533@cc.usu.edu> sl8nl@cc.usu.edu writes:
>> 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
>
>I dunno.  My text adventure compiler handled everything (it was similar
>to the ADVSYS library), and it took me a couple of weeks.  I could do
>everything Infocom could do and more.  The resulting executable was 18k.

If you wrote it in a couple weeks, believe me, it doesn't handle
anywhere near "everything."  You're falling into the same trap I
mentioned before:  using a totally outdated notion of what a "game
design system" is.  A decent game design system is far more than just a
suite of routines you write for your personal use.  You can do
"everything Infocom could do and more" directly in C, but that's not
what we're talking about here -- a game design system should take care
of all (or at least many) the tedious grungy details for you.  E.g., if
I want to extend the parser in a TADS game, I need only define a new
"deepverb" object.  If I want to add an actor I just have to say,
"foobar: actor" and supply some simple methods.  This is a far cry from
having to write everything directly in C.

It's the same kind of thing as the "sprite library vs. blitting library"
distinction.  A sprite library deals with _sprites_ -- objects that
operate at a higher level that just raw image data.  A sprite should
animate automatically (whether via interrupts or otherwise), should
be able to detect its own collisions and report them to the programmer
on queries, etc.  There's a lot more to this than just moving shapes
around.  Moving shapes around is the boring work that a game programmer
shouldn't have to do -- it's not interesting from a programming standpoint
and has no bearing on the design of the game.

I really feel that a game design system is one that allows the
programmer to spend his/her time on *design* rather than programming.
Some people would rather write every last line of code in assembly, and
for those people a game design system is not attractive.  For people
who just want to write *games* (as opposed to game *code*), a game
design system is better than sliced bread.  IMHO, TADS is such a
system.

>> 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.
>
>Since when did textbooks offer you the advanced info only professionals know?

Well, almost all the time, for most fields.  Even within computer
science it's rare that you *cannot* find documentation that describes
an algorithm or process.  Most CS texts go into a lot more detail than
many professionals would use, in fact.

A good example from game programming is the nifty texture mapping that
Origin and Apogee use for their 3D games.  That technology has been
around for several years (check SIGGRAPH proceedings) and is
well-documented in many places.  Sure, the optimizations that make the
process possible on a 386 are not freely available, but one would hope
that with a firm understanding of the algorithm you could adapt it to
80x86 assembly language yourself.  Specifics like this would be good
topics for the Internet PC Graphics Guide.  1/2 :)

Dave Baggett
dmb@wam.umd.edu