I feel like I'm repeating myself, but I'll try once more - I'm not
disagreeing with this general statement, and I'm not advocating assembly.
>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.
Hmm. Well, once again we're talking about trade-offs. But please
continue...
>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.
Well, my solution would be to just not use such a hint system. This is
once again a trade-off: supporting more low-end machines vs. a specific
feature in your game. I personally am most interested in a game that
squeezes the most out of its minimum system (which actually, I think
Legend does, so you should stop using it as an example), but that's a
matter of personal philosophy.
And does the typical IF game have a bigger state space than, say,
Civilization? I think not!
>(*) 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!
Hey, but it worked, right? And on a 286, no less...the typical gamer
doesn't care that your code is hideous.
I wrote:
>>YOU DON'T NEED TO SIMULATE INTELLIGENCE! While this might be a neat
>>compsci problem, it's completely uninteresting to me.
And Dave asserts:
>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.
Well, if that's what trips your triggers, so be it. I'm not sure you
need intelligent NPC's if your text is interesting enough. I think the
height of IF is a novel with choices, and you think it's a simulation of
the real world. Probably both are valid approaches.
We continued...
>>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.
Probably most players don't think about it all that much. I'm not sure
there's a greater suspension of disbelief when they're watching some nice
full-motion video or when they're talking to Floyd in Planetfall.
Suspension of disbelief is more about mood, setting, and character than
whether your NPC's can pass the Turing test. If you want to write a game
with NPC's that are smarter than you are, have at it. I'd rather spend
time on the plot and descriptions.
And more back n' forth...
>>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! :)
Yes, we've been here before, but you neatly side-stepped my point. Why
shouldn't an IF game be written only for Pentiums?
>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*.
No, it's not, but then they'll need a CD-ROM drive, then a better CD-ROM
drive, then SVGA, then Super-SVGA, then a Gameblaster, then a Pentium...
The upgrading treadmill never stops - or even slows down. You want them
to buy 486's today. You'll want them to buy Pentiums to run "Legend 2:
Duhdha's Omlet" (with full-motion video and "EggSmell" (TM) technology)
tomorrow.
Part of IF's charm, for me, is that the best DESIGNERS can make the best
games, not the guys that spend many thousands on their systems.
>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.
This is not my argument. See above.
<Snippity-snip snip>
>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.
Is Myst more fun than Planetfall?
>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.
How about the end game? I couldn't care less how powerful your
development system is...
>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.
That's fine with me, and I never said otherwise.
More back n' forth...
>>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.
Read my previous message again. I wasn't arguing for mandatory support
for any machine.
(Origin attitude discussion snipped.)
As someone else pointed out on this newsgroup, there's quite possibly a
lot of lurkers out there with low-end machines. In my family, I know two
people with 386's, and two more with 286's. They have no interest in
upgrading. Their computers do everything they need to do. And I think
it would be nice if, now and then, they could buy a new game to play.
For Origin (or any other company) to completely ignore said customers is,
IMHO, a mistake.
>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?
Sure. Write the IF game that requires a Pentium and delivers a serious
increase in play value and fun beyond Planetfall, and I'll be suitably
impressed. As I said, I haven't seen it yet.
Art discussion follows...
>>"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?
A lot of different things can motivate artists. Money, immortality,
religious fever, you name it. But even Thag didn't draw his horsies in a
vacuum. He was working for an audience, even if it was just his
flea-scratchin' wife.
Remind me sometime to loan you this book I've been reading about Easter
Island...it has something to contribute to this discussion...
>>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...
Name me one who was willing to paint his pictures in a closet and NEVER
SHOW THEM TO ANYONE. Hmm...well, such souls may exist, but WE'VE SURE
NEVER HEARD OF THEM!
Is their work art? Not without an audience, chucko...
>>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.
That's not fakery, that's programming genius - and well beyond my meager
capabilities.
>>The matchbook was a notable exception.
>
>Yes, well what about "put axe in bucket"? :)
That was a different problem - I didn't understand a quirk of TADS.
>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.
At what price?
>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.
Amateur meaning "not a programmer." Something about this definition
bothers me.
>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...
You didn't happen to see Nature a couple of weeks ago, did you? They had
a chimp on that understood commands such as "put the apple in the
refrigerator" and "take the vacuum outside." That's about as
sophisticated as any IF parser has gotten...
-----
Dave Leary
(Nope, my views don't represent UMAB...good thing, huh?)
"I've been of thousand devils caught,
And thrust into that horrid place,
Where reign dismay, despair, disgrace." -- George Crabbe