Re: Limitations of Inform and TADS?


9 Nov 1995 09:17:05 GMT

In article <47l81q$3hnu@trout.ab.umd.edu>,
David Leary <dleary@trout.ab.umd.edu> wrote:

>It's probably possible to make the tools work on lower-end machines, or
>just fake more stuff (see below).

To a certain extent, you can squeak more cycles out of a machine by coding
in assembly. But obviously there are limits, otherwise all machines could
do everything, which is clearly ludicrous.

I doubt it would be possible to optimize TADS, even by hand-coding it, to
the extent that _Legend_ could figure out, with no visible delay on a 286,
which hint is the best one to print out when the player types "hint".
There are many other real-world IF problems which don't require
particularly fancy algorithms or programming, but which nevertheless take a
decent number of steps to solve.

Could you fake _Legend_'s hint system? Sure, but it would require you to
write many more lines of code (*), and would be correspondingly more buggy,
and take that many more weeks of playtesting to get the bugs out. And you
might *never* find all the bugs. As programming goes, IF is especially
fiendish, because it offers the player a huge state space to explore --- so
huge that your playtesters (or even your players) could never visit (test)
every state. That's why I think it's worth spending cycles on elegant,
robust solutions that require more time versus ad hoc solutions that are
cheap but very error-prone.

(*) Actually, in this *particular* case, that might not be true, but
*only* because I had to rewrite the hint system in the most
hideous manner to get it to fit under real mode DOS. GEE, I
HAD TO WRITE CRAPPY CODE JUST TO SUPPORT AN OLD MACHINE --- WHAT A
FREAKING COINCIDENCE!

>YOU DON'T NEED TO SIMULATE INTELLIGENCE! While this might be a neat
>compsci problem, it's completely uninteresting to me.

Well, personally I no longer think you can fake intelligent NPC's well
enough to even bother with them. It takes about 30 seconds to exhaust the
NPC fakery in adventure games. There's no simple faking you can do to make
this significantly better. If you want NPC's to interact with the player
intelligently, they have to be intelligent.

>I'm a crappy programmer. I want to write a game that's interesting to
>play, and if I have to fake realistic NPCs to do it, then that's fine, as
>long as the player doesn't notice.

What do you mean, "as long as the player doesn't notice?" Nobody thinks
they're really talking to anything but a midless automaton when they
"interact" with an IF NPC. Perhaps briefly the player will suspend
disbelief, but this is hardly true throughout the entire game.

>Weren't you just criticizing me for drawing a line at the TRS-80? How
>come you're so willing to draw a line between 486's and Pentiums on the
>other end?

I think I'm having deja vu here. Let's see, "...rubber...glue..." It's
hazy but, yes, I'm sure I've been here before... Wait! It's a maze of
twisty non sequiturs, all alike! :)

My point throughout this discussion is simple: I perceive significant
opposition among IF fans to IF works that *require* modern hardware to run
on. *I* never really wanted to draw lines in the sand here, but the whole
"monetary investment in IF" argument came up, and to address that I argued
that a 486 motherboard, in particular, is not what I'd consider a steep
investment *relative to the investments one must make in other arts*.

I *don't care* what systems authors require for their games. I worry about
the sentiment that ten-year-old hardware *must* be supported, otherwise
something's wrong, "because after all, these are only all-text games." I
believe that notion does limit what authors are willing to try. That is
all.

>Of course! And as you say yourself, this is because it's
>graphics-intensive! There's a limit to how much faking you can do here.

I agree that graphics and sound tend to eat CPU cycles readily. What I
disagree with is the idea that they are the only things that *should*.

I cited a bunch of graphics examples to address your comments about
companies like Origin. You say they're sloppy and lazy. While this may be
true to a certain extent (I'm not a big Origin fan myself), I think it's a
mistake to blame increasing hardware requirements on either of these ills.
Only the very latest hardware can run certain kinds of games. So when
companies write these kinds of games, for the people who want them, they
must require said hardware. Simple. The point is that there are things
you can do with this year's hardware that you couldn't on last year's, even
if you *do* write lots of assembly code. Our game wouldn't run on a Sega
Genesis (the previous generation console hardware) if GOD HIMSELF wrote the
code.

But I also cited Common Lisp, which has nothing to do with graphics. It's
a language and a development system. By C standards, it is dog slow. But
since we have 200Mhz SGI's, that doesn't matter. Common Lisp makes us much
more productive than C. So we depend on our fast SGI's not because our end
product requires one to run, but because our fancy, productivity-enhancing
development system is acceptably fast on them, but wouldn't be on, say, a
286. Or a Pentium, probably.

Of course, we don't write the end product in Common Lisp. But we do write
tools that aren't a part of the game itself, but are essential to
development, in Common Lisp. Which saves us a lot of time.

>Innovation doesn't have to mean more computational resources, ESPECIALLY
>in IF. It can simply mean an original story and a better game.

You're right, it doesn't *have* to. But *may* it? If so, then mandatory
support for n-MIPS machines (you fill in the n) is a bad policy.

>>It is your choice to support or ignore companies that assume state of the
>>art hardware. But there are people who *want* the latest thing and are
>>willing to pay for it
>
>This is the Origin attitude in a nutshell.

Right, but you seem to think the attitude sucks, and I still don't really
understand *why*.

>>Bringing this back to all-text IF, I see the potential for tools that
>>vastly improve IF programmers' productivity. I see IF going in radically
>>new directions --- very little has changed since Adventure, really.
>
>I agree with both statements here. Neither event requires better
>hardware.

Can I not convince you that even if GOD HIMSELF is your programmer, your
machine is not capable of running every programming language and
environment we could ever conceive of, some of which might make us more
productive IF authors?

>"Artist as Mother Theresa." I'm not buying it. If that's your motive, I
>suspect you're more or less alone among artists.

How do you know what motivated Kafka? What about Robert Johnson? Was he
writing blues tunes to make money, so the world would remember him, or just
because *that was what he did?* And what about Thag the cave painter?

>I suspect my theory about "writing to pick up babes" is a lot closer to the
>truth.

There are other writers on Earth besides Kundera...

>Well, okay, you got me here. But then again, I faked as much stuff as I
>could.

Ah, you *think* you did. But in fact you could have simply made your
program a massive table mapping input string and game state number to
output string and new game state number. No explicit code required! This
would run *really damn fast*. But it would be a bit of a memory hog.

>The matchbook was a notable exception.

Yes, well what about "put axe in bucket"? :)

Nobody is perfect, of course, and no programming language prevents you from
making *any* mistakes. But many of the kinds of bugs we get writing in
these somewhat low-level C-like languages would all but disappear if we
used more powerful systems.

I guess I should point out that I'm not trying to diminish what Mike and
Graham have done with their development systems. Together they have
brought IF into a new era --- the age of the amateur IF author who produces
professional-quality IF. The number and quality of IF releases in the past
few years is ample evidence of this.

TADS and Inform are both low-level because they needed to be so when they
were written. (TADS because it was begun five years ago or so, and Inform
because it compiles down into Z-Machine code.)

>Let's start up that old "monkeys can/cannot learn language" argument again!

I was hoping against hope that Nim Chimpsky would finish his adventure game
in time for the contest this year, but --- alas --- he still can't get a
grip on this whole "tree structure" thing...

Dave Baggett
__
dmb@ai.mit.edu
"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)