Re: Limitations of Inform and TADS?


Wed, 8 Nov 1995 01:57:45 GMT

In article <47m3i8$blg@life.ai.mit.edu>, David Baggett <dmb@ai.mit.edu> wrote:
>I'm not talking about a single response. Maybe it's just me, but I feel
>like there's a constant barrage of complaints about what machines this or
>that won't run on, how it's criminal that there's no Amiga, Atari Falcon,
>Apple IIGS, etc. version of the TADS run-time, and so on. And almost
>inevitably, the poster will argue that "these are just text adventures ---
>there's no reason I shouldn't be able to run them on my ______."

My main complaint is that TADS, specifically, is allegedly allowed
to be ported to new machines. Allegedly, but apparently not actually so.
I (and presumably the others) would definitely sign a non-disclosure
agreement, and would do the porting _ourselves_. That's why I think the
info in the FAQ posted here frequently is, at the very least, slightly
misleading.

Another of the really good things about the separated game
file vs. interpreter deal is that many of the speed issues you talk about
can be handled on the interpreter end. Obviously the code-to-be-interpreted
can be complex enough that it can't be interpreted fast enough on some machines.
However, from what I hear about TADS, and what I know about the Inform and
Infocom games, the interpreter's speed can be tweaked a lot. (This doesn't
hurt portability either, as there already are different drivers and other
calls specific to each platform.) If the "generic" portable code isn't
fast or feature-rich enough, the person doing the port can improve it in
a platform-specific way. (For example, there are some Amiga-specific calls
in the general ZIP distribution.) Also, Stefan Jokisch has removed
the VM-ish paging of ZIP in modifications he's done. I'm using those
modifications since I have the memory available and the speed increase
will (hopefully) outweigh the increased memory usage.

Basically, I think that the "generic datafile with interpreter"
model is one that should remain, and anyone who wants to should be allowed to
port it to whatever machine under the sun they want to (with obvious
NDAs, etc., for commercial products). Will the different environments get
complex or memory-hogging enough (*) so that slower machines can't run
them? Probably, but as I described above, machines "on the borderline"
can benefit from people who care about the machine and are willing to put the
extra work into optimizing a port of an interpreter that the original
author(s) may not be willing to do.

(*) Actually, with this, some sort of VM-like paging system as a
compile time option would be good. Infocom was clever by using this sort of
system. (Or it could be on by default, and someone else willing to do the
work would have to remove it.)

-- 
unknown@apple.com		Apple II Forever
These opinions are mine, not Apple's.