Message-ID: <3AE9BB3F.B61D81B9@csi.com>
Date: Fri, 27 Apr 2001 14:32:31 -0400
From: John Colagioia <JColagioia@csi.com>
Organization: No Conspiracy Here...
X-Mailer: Mozilla 4.77 [en] (Win98; U)
X-Accept-Language: en,fr,ru,es,it,ga,de,ja,gd,eu
MIME-Version: 1.0
Newsgroups: rec.arts.int-fiction
Subject: Re: Sycamora Tree: "Inform is outdated"
References: <lve8etcbql4ccn6uj5flmeo0i52bdb0con@4ax.com> <3AE57D0B.80C9618A@csi.com> <3AE6E26E.10AF1F88@csi.com> <0uXF6.17733$9f2.1489600@ruti.visi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 208.34.37.104
X-Original-NNTP-Posting-Host: 208.34.37.104
X-Trace: excalibur.gbmtech.net 988396356 208.34.37.104 (27 Apr 2001 14:32:36 EST)
Lines: 127
X-Authenticated-User: jnc
X-Original-NNTP-Posting-Host: 127.0.0.1
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!feed2.onemain.com!feed1.onemain.com!uunet!dca.uu.net!nyc.uu.net!excalibur.gbmtech.net
Xref: news.duke.edu rec.arts.int-fiction:86074

David Thornley wrote:

> In article <3AE6E26E.10AF1F88@csi.com>,
> John Colagioia  <JColagioia@csi.com> wrote:
> >
> >Yes, the ZPlet applet would be less extensible than "a typical
> >Z-Machine," because it requires the overhead of the JVM to go with it.
> >Just like the Z-Machine encoded in the Z-Machine encoded in the
> >Z-Machine...etc. would be less extensible due to the additional layers
> >of overhead.
> Is overhead a problem?  In general, a platform that will support a JVM
> will do so well.  Any fixed amount of overhead will either prevent
> running something altogether or be relatively minor in a few years.

Yes, overhead is a problem.

First, it limits your minimum installation.  While this is not a problem for
you or I, there are many people that technology has not yet caught up with.
Also, every few years, a new batch of devices arise with smaller
specifications.  They grow, yes, but that still leaves a large number of
people with older technology.

However, that's not the part that rubs me wrong.  That's the fact that the
overhead is "wasted," in that it supplies little more functionality for all
the bulk.  Consider that I once had an experimental version of the GEM
operating system for...I think it was the Atari, at that point in my life,
which did most of what MacOS does today (call it an "extended subset") at
about the same speed, except it fit on a single floppy disk.  Consider what
that same techniques could do on modern hardware.  Any such system could blow
modern software out of the water.

Of course, yes, I've seen what becomes of those projects...


> >That is, they're (probably) equivalent in computational ability (in the
> >Turing Machine sense, and assuming infinite storage space), but the
> >Z-Machine has the edge in that it can do more with less space and
> >power.  It's more of a matter of efficient use of resources than it is
> >a matter of "computational power."
> Except that efficient use of resources is somewhat different.  I'm
> at a platform right now that runs W2K (a fairly good attempt at an
> industrial-strength operating system) and Microsoft Office efficiently,
> in the sense that I'm not impeded by resource limitations but rather
> the general design.  The fact that this machine has to be immensely
> more powerful than the supercomputers around when I learned programming
> to do this is irrelevant, because such powerful machines are not all
> that expensive nowadays.

No-no.  Modern software uses the hardware economically.  And "efficiently
enough" based on economics.  The increase in the cost of hardware is
significantly less than the increased cost of software development would be to
make it fit on older systems.

Honestly?  My equipment spends a heck of a lot of time idle, except when I
need the extra speed.  Then you can read by the hard drive light as it pages
memory in and out.  This is not good.


> At least one place where the Z-machine fails is size, and (IIRC) this
> is one of the reasons for Glulx (good thing I've a lot of practice in
> pronouncing Lovecraftian names/common Russian words).  I assume that
> the JVM has limited size, but a lot less limited than .z8.  These
> size limits are becoming significant, as authors have been running
> into them.

As I said (or meant to say), I'm not advocating abandoning anything built
after 1985, by any means.  That would be completely insane.  Instead, I'm
simply stating that, for a given platform, technology built on the Z-Machine
specification (assuming you allowed it to somehow fill up the available space)
will be capable of far more functionality, because less space and time is
taken up by overhead.


> However, this doesn't mean that Inform is obsolete, or even
> obsolescent.  We've got incredible amounts of computer power available
> by any standard more than a few years old, and this has been true
> for decades.  What are we going to do with it?  That's been the
> problem.  We can run multimedia games at high resolution and frame
> rate, but that's not what IF is about.

There's that point, as well.  IF is heavily based on what the player will do.
And there are only so many things that the game can take care of before the
player starts to get edged out.  Remember that the player is unlikely to
perform more than one action per second, while a "well-fed" processor is
capable of several million actions.

AI and simulation algorithms, though, would certainly be a good use of
processing power and space allocation.


> Be careful about casually improving the parser by throwing resources
> at it.  The important thing about the parser is that it is understandable,

> that the player knows how to accomplish something with it.  The player,
> being human, can adapt to such restrictions if they are clear enough to
> be internalized.

Although superior natural language processing (if better algorithms were
available) could certainly go a long way towards decreasing the learning curve
for new players.  I know several people who would like to be able to say, "try
it again," or "keep going," or other semi-idiomatic expression.


> Simulation and grammar are things that we simply don't know how to
> do well.  In addition, we'd have to be sure that these don't cause
> undue problems for the author.  I've seen complaints about the
> difficulty of using the TADS simulationist library Worldclass.

I suspect that, when you get right down to it, simulation capabilities are
only useful to a certain class of games, regardless of whether or not they're
available.  I mean, I certainly don't think Zork would be a better game if,
for example, I could burn the house down to start my dungeoning.  But in cases
where it would be effective...


> The big advantage of the standard design concepts is that they are
> known to work, and work well.  They provide a consistent tone and
> allow people to write IF in understandable ways.  Inform and TADS
> and Hugo aren't in any way perfect, but I really don't know how
> to make them all that much better while keeping their advantages.
>
> If somebody else does know how to make a better IF system, great.
> I'm not holding my breath.

Exactly right.


