>Surely you'd agree that it's possible to optimize TADS (even with the stuff
>you've done) to make Legend run on a 286 - if you had an extra year to
>spare. :)
It would be possible, but probably at the expense of portability. The real
charm of these languages is that they produce machine independent
executables, and that the interpreters are easily portable. Perhaps I
could write an assembly version of TADS that would run Legend with no delay
between commands on a 286. But the code would only be useful for 286's and
8086's. Is it better to spend time on such nonportable code, or to improve
the portable tools we already have?
>Ahah! Here we see glimpses into Dave's "the artist is divorced from his
>audience" mentality - aka "the audience doesn't really matter." While
>it's true he gives a nod to "feedback" he clearly feels how the audience
>reacts to his work is more or less meaningless...
I think it's a mistake to ignore one's target audience entirely. It's
also, I think, a mistake to cater to the audience, because it's not a
single entity with one mindset. If you listen to every comment you get
about your work, you'll end up chasing your tail.
>Leaving aside the obvious comment that the TRS-80 predates the Amiga and
>the 286 by a few years, the fact is that a text adventure - in ANY
>incarnation - should not need to draw on as many CPU-intensive processes
>as a real-time, graphics-intensive game of ANY sort. If it does,
>something's amiss.
1) If there were any doubt about my legitimacy in citing widespread
*philosophical* opposition to the notion that IF can and should use
whatever CPU resources are avaible, I hope this thread has finally put
them to rest. :)
2) 286 vs. TRS-80 vs. Timex-Sinclair is not the issue. The issue is that
the decision to label a 286 "necessary to support" and a TRS-80 "too
outdated to bother with" is arbitrary. The set of machines it makes
sense to support is a sliding window. I believe that 286's are well
outside that window. Further, I think that having that big a window
limits what IF authors can (or are willing to) try.
3) The claim that graphics and sound games are somehow entitled to
more CPU cycles than all-text games rests on a narrow view of
all-text games. Do you honestly believe there is no good use
one could put more than 1 MIPS to in an all-text game?
There are many problems relevant to IF that are nontrivial. The
algorithms people have used in IF to date are trivial from a
computational complexity standpoint. This seems to have had the
unfortunate result of misleading people into thinking that
all-text = trivial, which is certainly not the case.
Even apart from higher-abstraction tools that would reduce IF
development times at the expense of efficiency, there are innumerable
problems that deal with text-only inputs, that are relevant to IF,
and that appear to require more CPU cycles to solve than we have
had so far in the history of the universe.
IF is all about creating the illusion of interaction with intelligent
agents and a believable world. We're not even close to knowing
how to solve these problems given any imaginable computational
resources. Even gross approximations of intelligence and learning
seem terribly difficult (and certainly costly). To say that IF
doesn't need more CPU cycles is to deny the ideal that IF is
founded on!
>>First of all, you can probably get a used 386 motherboard for about $25 at
>>a flea market or hardware swap fest. Though I haven't checked mail order
>>prices recently, I bet that by now a 486 motherboard would be less than
>>what you paid for net access this year.
>
>Ah, the attitude which makes the industry what it is today! Change "486"
>to "Pentium" in the above paragraph, and Dave could work at Origin!
But I didn't say "Pentium," and that makes a big difference. A Pentium
motherboard costs upwards of $500. I checked a several-month-old Computer
Shopper and found that Cyrix 486 motherboards sell for around $80 *new*.
That's just slightly more than what a graphics and sound game costs. I
don't think it's unreasonable to ask that kind of financial commitment from
one with serious interest in a medium. That would get you into 3 to 5 LA
Philharmonic performances. It would buy you two dozen paperbacks.
You should also realize that if game authors assumed a 286 target platform,
you wouldn't have most of the interesting games that have come out in the
past five years, DOOM (which you mentioned was nifty) included. The game
I'm working on for my "real job" would be infeasible without the latest
hardware, not just because we crucially rely on this hardware's improved
performance, but also because we could never meet our deadlines without
development hardware like SGI's that make it possible for us to work
interactively with models composed of hundreds of thousands of polygons,
and to use productivity-enhancing tools like Common Lisp. Writing such a
game in assembly on a 286 would take considerably longer than the 18 month
window we have.
In short, gamers (naturally) want new gaming experiences. Innovation
requires better development hardware, and innovative games require more
computational resources. You are always free to save your money and stick
with an Atari 800. (I play games on mine all the time.) But is it
reasonable to ask game developers to *not* do what's necessary to innovate
(and yes, that includes not writing entire games in assembly, at the
expense of efficiency), just for the sake of supporting the hardware of 3
or 5 years ago?
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
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. But I
expect these things to come at the cost of efficiency, and not because
programmers are sloppy, but because their greatest enemy is development
time, and now that some games are actually starting to involve
compute-intensive algorithms (3D graphics games are the obvious example),
programmers must use higher level languages and tools in order to keep
reasonable schedules. The same is true of IF --- the algorithms will not
always be so simple if the medium evolves towards its ultimate goal.
>>Should I *really* be overly concerned about supporting the fair-weather
>>friends --- the ones who will play my stuff as long as it costs them
>>nothing and doesn't require them to go to any trouble? Been there, done
>>that. I wrote *Atari* software for 5 years.
>
>What about the pure artistic satisfaction of your work? This doesn't
>seem to fit with your stated reason for writing IF. See above.
My attitudes about art may change, but I think they are generally
self-consistent at any given time; you seem to think I'm confused. I get
satisfaction primarily from *creating* works, not from knowing that a
zillion people read them. If I release a work and you read it, I view it
as an act of kindness on my part, not yours. I gain nothing, while you
gain a certain invasion of my private thoughts.
This may seem paradoxical in light of our earlier discussion about what
constitues art --- I argued that an important criterion for a work of art
is that it communicate something. So why wouldn't I care if no one's on
the receiving end of this communication?
Well, I've never been of two minds about it: if a tree falls in the forest,
and no one's there to here it, it certainly does still make a sound. And
likewise, a beautiful thing is no less beautiful if one person sees than if
a million see it.
And from a practical standpoint, there will always be people who will
appreciate, somehow, what you have done, if you chose to make it available
to an audience and if it has merit.
>I would assert the following: games should be optimized to death, written
>for the lowest possible CPU they can run on, and written efficiently.
They you'll admit that your own games are an abomination? They're easily
100 times slower than they would be if you'd hand-coded them in assembly
for your target architectures.
The irony of this is that you're a real beneficiary of the very "sloppy
programer" philosophy you're trying to bury. Had you only been given
access to tools that would allow you to produce optimized-to-death games,
you'd never have finished even a fraction of an IF game. You and I both
know it would have been just too much of a pain, and would have taken far
too long.
I feel the same way about the present crop of IF tools. While they're fine
tools, impressive accomplishments, and worlds better than what we had 7
years ago, they're beginning to look a bit sorry alongside hypothetical
systems (which would run nicely on state-of-the-art machines) like Carl's
constraint management system, or, as I've said before, simply overall
better languages like Scheme.
>Maybe. D'ya think Neb might have finished UU3 if he'd had a higher-level
>language?
Let's not get absurd. (Sorry Neb!) :)
>The big drag on my games was always story/plot issues rather than coding
>issues. Once I knew where I was going, I could bang out stuff pretty
>fast.
How soon we forget things like THE MATCHBOOK. You spent, what, 2 weeks on
that? With a suitable language you could have coded it in under 5 minutes.
We are nowhere near maximal productivity yet, if there even is such a
thing.
I spent *weeks* writing that infernal Attachable class for WorldClass. And
I bet there are *still* bugs. It shouldn't be that hard.
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)