>Does it really make sense for all TADS games to include the code for
>starvation, for example?
I'd ask the opposite: what does one gain from not including the code for
starvation? Your game file will be smaller, yes, but if your game is large
enough to require special treatment (like _Legend_), the amount you will
save is proportionally small.
The minimal WorldClass game is about 90K. This is a one-time, constant hit
--- i.e., more complex classes do *not* produce bigger instantiated
objects, since all objects *share* their superclasses' code. Pairing that
constant 90K down in a game that is 640K total seems pointless to me.
Optimistically, you're going to save, what, 50K?
There seems to be a widely held misconception here (not saying you, Carl,
hold it): that "bigger means slower". WorldClass games are slower because
the WorldClass algorithms for things like line of sight and contents
listing are significantly more complicated than those in ADV.T. It is
*not* the case that TADS itself is significantly slower with larger game
files --- I've never noticed much difference, myself. Only PC's need to do
any swapping of objects in and out of memory, and even this goes away when
you use the GO32 version of the run-time I built for _Legend_. (Which,
incidently, I assume to be pretty stable, since only one person has
reported any problems with it, and this person's machine doesn't like some
other standard software either.)
For the record, I plan to put some flags into WorldClasss that turn on and
off the costly features. This will give users the option to put the
library into "standard text adventure assumptions mode", in which things
should be pretty speedy.
Finally, if you're planning on writing a replacement for ADV.T, be warned.
It's a colossal time sink!
Dave Baggett
__
dmb@ai.mit.edu ADVENTIONS: Kuul text adventures! Email for a catalog.
"Mr. Price: Please don't try to make things nice! The wrong notes are *right*."
--- Charles Ives (note to copyist on the autograph score of The Fourth of July)