What is an IF authoring system anyway?
David Betz
thinking about what makes a system good for writing IF. When I first
designed AdvSys, I was looking for a system that was portable across a
number of different platforms and that included built in support for data
structures that were useful in constructing IF. I also wanted a system with
a built in parser so that the IF author didn't have to reinvent the parser
with each game. A persistant store is also necessary for setting up the
initial game state as well as saving positions within a game.
So, what makes an IF authoring system?
1) flexible data structures (objects?)
2) parser
3) persistant object store
4) portable
What else? Do we really need specialized languages for writing IF these
days? Couldn't Java with a few custom classes do just as well as an IF
language? It has the advantage of having a defined virtual machine that can
be implemented on most any modern platform. It might be a bit heavy weight
for palmtops though.
I'm sure I'm out of touch with the current state of the art in IF authoring.
What other facilities do these modern IF authoring systems offer that aren't
available in more traditional languages?
Thoughts?
Andrew Plotkin
> So, what makes an IF authoring system?
> 1) flexible data structures (objects?)
> 2) parser
> 3) persistant object store
> 4) portable
Interface.
> What else? Do we really need specialized languages for writing IF these
> days?
Are you confusing the authoring language with the target platform (which
may be a VM or not)?
> Couldn't Java with a few custom classes do just as well as an IF
> language? It has the advantage of having a defined virtual machine that can
> be implemented on most any modern platform. It might be a bit heavy weight
> for palmtops though.
Also, interface.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Tina
David Betz <db...@xlisper.mv.com> wrote:
>
>1) flexible data structures (objects?)
>2) parser
>3) persistant object store
>4) portable
>
>What else? Do we really need specialized languages for writing IF these
>days? Couldn't Java with a few custom classes do just as well as an IF
>language?
Maybe I'm missing something, but once you're done creating the classes to
handle objects and the parser, haven't you just authored a new
specialized IF creation environment? I'm not sure where the difference is
between that and, say, Inform, other than maybe slightly more familiarity
to current Java coders.
David Betz
> handle objects and the parser, haven't you just authored a new
> specialized IF creation environment? I'm not sure where the difference is
> between that and, say, Inform, other than maybe slightly more familiarity
> to current Java coders.
Yes, you are correct. The main advantage would be that a mainstream language
is more likely to be familiar to programmers. Of course, the vast majority
of IF authors may not even be programmers so that may not be much of an
advantage. It's usually much easier to find books to teach one to program in
mainstream languages as well. Of course, I believe that Inform is quite well
documented so that may not be much of an advantage either. I guess I'm
really looking for a general idea of what current IF authors expect to find
in an authoring system. My guess is that it is mostly library functionality
and UI including a powerful parser.
Magnus Olsson
Yay! An old favourite!
I read about AdvSys in Byte back in '86, and thought it was just about
the best thing since sliced bread: not only was it the first time
I saw a language for writing IF (I had thought about the possibility
of an adventure system, but hadn't realized that the way to go was
to make it a "real" programming language), it was also my first
exposure to OOP - and IF is a very good textbook application of OO.
>So, what makes an IF authoring system?
>
>1) flexible data structures (objects?)
>2) parser
>3) persistant object store
>4) portable
Since you mention the parser (which shows you're really thinking of
IF systems, not just IF languages, right?), I think you shouldn't
forget the world model. Inform without the world model provided with
the Library would have been just another programming language.
As for language features: mostly syntactic sugar to save on typing,
like Inform's auto-printing strings,
grammar-productions-as-part-of-the-language and
<< Action Noun Object >>.
But that's just syntactic sugar; it's nice, but not really essential.
I can think of one important feature that's semantically important, and
that's the ability to override base class behaviour when instantiating
a class. In Inform, you can have a class definition:
class foo
with
value 15,
do_someting [ ; "Hello world!"; ]
;
and then create an object
foo bar
with
value 16,
new_value 17,
do_something [ ; "Goodbye!"; ]
;
whereas in, say, C++, you'd have to create an explicit class to be able
to add the new member new_value and override the do_something method,
and add a constructor to this class to override the value of value.
This may not sound like a big deal, but think of it: most objects
in an IF game really are singletons; it's relatively rare that you
have several objects that are identical except for the values of
attributes. In a C++ adventure with 123 objects you'd have to have
perhaps 120 classes, each with just one instance. That's awfully
inconvenient.
>What else? Do we really need specialized languages for writing IF these
>days? Couldn't Java with a few custom classes do just as well as an IF
>language?
See above.
>It has the advantage of having a defined virtual machine that can
>be implemented on most any modern platform. It might be a bit heavy weight
>for palmtops though.
Targeting an existing VM is a big advantage, yes. Note that Inform had
this advantage, since people had been writing portable, open-source
Z-code interpreters ever since the heyday of Infocom.
But I'm not sure that the Java VM is sufficiently widespread for IF (this
has been discussed before on this group, and I think the consensus
reached was that targeting the Java VM wasn't really preferable to
designing a new VM. One result of that discussionwas Glulx.)
>I'm sure I'm out of touch with the current state of the art in IF authoring.
>What other facilities do these modern IF authoring systems offer that aren't
>available in more traditional languages?
I think the important thing is the world model and the class library
that implements it. Everything else about Inform or TADS pales in
comparison to the enormous power of the Inform and TADS libraries.
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Susan Davis
>
> I've been dusting off my old AdvSys authoring system
Cue the singing dolls from that Disney ride... I've been porting
all of my old AdvSys code to Kawa, with thoughts of writing a
compiler for a Kawa subset to the Z-machine. (Which is requiring
some fairly significant changes, since Scheme won't really support
AdvSys' "(newclass superclass ...)" syntax.)
> Do we really need specialized languages for writing IF these
> days? Couldn't Java with a few custom classes do just as well as
> an IF language?
Well, Kawa could easily qualify as "Java with a few custom classes,"
depending on your perspective. And what I'm doing can be described
as "Kawa with a few custom modules."
-- Sue --
(do keep me (no pun intended) informed if you do anything with AdvSys,
though)
--
Susan Davis <s...@secant.com>
Secant Technologies * 4853 Galaxy Pkwy, Ste. S * Cleveland, OH 44128
CLSC 1999 -- "Many Paths to the Stars"
Kevin Russell
>
> David Betz wrote:
> >
> > I've been dusting off my old AdvSys authoring system
>
> Cue the singing dolls from that Disney ride... I've been porting
> all of my old AdvSys code to Kawa, with thoughts of writing a
> compiler for a Kawa subset to the Z-machine. (Which is requiring
> some fairly significant changes, since Scheme won't really support
> AdvSys' "(newclass superclass ...)" syntax.)
You can't even do it with macros? Of course, I can't actually
remember what exactly Scheme macros do for more than ten minutes at
a time. But if some sick hacker can twist them to support infix
math, how much less possible would it be to have one slightly
infixed special form?
Anyway, I'm intrigued by the whole idea of translating AdvSys to
Kawa to Z-machine. Do tell more.
(It figures that the week I finally unsubscribe from the Kawa
mailing list is the week somebody actually starts talking about
using it to do something interesting. This universe is too warped,
how do I emigrate?)
If David were going to resurrect AdvSys, I'm pretty sure the way
to go would be to piggy-back as a very rich library on one of the
excellent already existing implementations of Scheme -- make
somebody else do all the grunt-work for maintaining the
infrastructure and the cross-platform portability :-). You're
obviously very familiar with Kawa; I'm more partial to PLT's
MzScheme myself; I'd imagine David is awfully fond of XLisp. Any
one of them would be better than trying to maintain old C code
that tries to re-implement Scheme yet again. (Though I suppose the
XLisp option kind of defeats the whole point of making somebody
other than David do all the hard work...)
> (do keep me (no pun intended) informed if you do anything with AdvSys,
> though)
Add me to the list too, though just as an idle bystander.
-- Kevin
Adam J. Thornton
>David Betz wrote:
>> I've been dusting off my old AdvSys authoring system
>Cue the singing dolls from that Disney ride... I've been porting
>all of my old AdvSys code to Kawa, with thoughts of writing a
>compiler for a Kawa subset to the Z-machine. (Which is requiring
>some fairly significant changes, since Scheme won't really support
>AdvSys' "(newclass superclass ...)" syntax.)
I'm moving all of my work to Kava. It makes your lips numb, and then
your legs stop working and then you fall down.
It's a lot like Visual Basic, except that it anesthetizes you too.
Adam
--
ad...@princeton.edu
"My eyes say their prayers to her / Sailors ring her bell / Like a moth
mistakes a light bulb / For the moon and goes to hell." -- Tom Waits
Chris Sargent
but surely it's more logical to work with a higher level of abstraction?
Java - like all other development languages - is a generic tool. For any
application (except perhaps libraries / tools to be used by other
programmers) it is almost always better to create some system that abstracts
the underlying programming language.
IMHO the ideal IF development system would consist of:
i) dev environment
- either a compiler, an IDE/compiler or, even better, an IDE/compiler with a
built-in runtime/tester.
- a set 'building-blocks' for IF (locations, objects, verbs, syntax, etc)
- a nice big set of libraries to support common functionality (doors, basic
NPCs, containers, etc)
- a simple but extensible language for writing the more complex and
interactive parts of IF
ii) runtime environment
- Java-based for cross-platform ability
- parser
- game engine
On a different note, the multi-platform capability of Java does make it
excellent as a runtime environment for IF.
Also, most VM's are also quite lightweight since the bulk of the
functionality (i.e. library classes/packages) are generally loaded on demand.
David Betz
"Kevin Russell" <krus...@home.com> wrote in message
news:39AF3DEC...@home.com...
> If David were going to resurrect AdvSys, I'm pretty sure the way
> to go would be to piggy-back as a very rich library on one of the
> excellent already existing implementations of Scheme -- make
> somebody else do all the grunt-work for maintaining the
> infrastructure and the cross-platform portability :-). You're
> obviously very familiar with Kawa; I'm more partial to PLT's
> MzScheme myself; I'd imagine David is awfully fond of XLisp. Any
> one of them would be better than trying to maintain old C code
> that tries to re-implement Scheme yet again. (Though I suppose the
> XLisp option kind of defeats the whole point of making somebody
> other than David do all the hard work...)
Actually, the reason I started trying to resurrect AdvSys is that my son
expressed an interest in writing an adventure game. I basically took AdvSys
and replaced the compiler with something that parses an infix language since
he intends to move into C and C++ eventually. I know I should probably just
have him use Inform or TADS but I kind of want a language whose
implementation I understand so I can explain to him how the language itself
works. Also, AdvSys is a much smaller system than any of the modern ones.
BTW, AdvSys was never really trying to be like Scheme in the first place. It
was trying to be like ZIL, the language Infocom used to write their games.
This discussion of converting AdvSys games to Kawa or some other version of
Scheme interests me. I didn't know there were many AdvSys games to convert.
The only one I'm really aware of is Gary McGath's "Columbus". Other than
that, I think there was one about elves. Are there others?
As a side note, can someone tell me where to download a printable copy of
the Z-Machine specification? I've found a browsable version online but I'd
really like to be able to print it out.
kar...@fermi2.chem.yale.edu
[snip]
> What else? Do we really need specialized languages for writing IF these
> days? Couldn't Java with a few custom classes do just as well as an IF
> language? It has the advantage of having a defined virtual machine that can
> be implemented on most any modern platform. It might be a bit heavy weight
> for palmtops though.
Mention of the new Python IF-writing language in 10...9...8...
-Amir
ps Point is, yes, it looks like it can be done.
Magnus Olsson
<kar...@fermi2.chem.yale.edu> wrote:
>Mention of the new Python IF-writing language in 10...9...8...
>
>-Amir
>ps Point is, yes, it looks like it can be done.
It's been done: there is a Python class library for writing adventure
games. I've forgotten what it's called though. Perhaps it should be
uploaded to the IF archive?
Susan Davis
> Kevin Russell:
> > I'm pretty sure the way
> > to go would be to piggy-back as a very rich library on one of the
> > excellent already existing implementations of Scheme
Yup. That's exactly what I'm up to. I started writing AdvSys code
back before Inform, when TADS 1.x was a non-free commercial product,
and AdvSys was the only free system I could find that didn't suck,
and that gave me source code that I could hack.
There were a bunch of features in TADS that were missing from AdvSys
(most notably the limits of the AdvSys parser); my original goal was
to hack AdvSys to match or exceed the functionality that TADS
provided. Many of the features I wanted, though, looked like
they were implementable as library code, so I started writing a
WorldClass-ish library, and things sort of snowballed from there.
> > You're
> > obviously very familiar with Kawa; I'm more partial to PLT's
> > MzScheme myself
I was actually using MzScheme at one point. But Kawa has the
advantage that it compiles to a VM that everyone (or just about
everyone) already has, without the need to download another
runtime.
> AdvSys was never really trying to be like Scheme in the first place.
> It was trying to be like ZIL, the language Infocom used to write
> their games.
*nod* That was why I stuck with it so long. And z-machine output
was feature #1 on my wish list of features to hack into a future
version.
> I didn't know there were many AdvSys games to convert.
> The only one I'm really aware of is Gary McGath's "Columbus".
> Other than that, I think there was one about elves. Are there
> others?
"The Sound of One Hand Clapping" was fairly well received; there's
a copy of it at GMD, I believe. None of my stuff ever actually got
released, as I was too busy debugging my library to actually finish
actual games.
I've got a bunch of partially-written AdvSys games lying around in
an archive somewhere: a nearly-complete port of "Colossal Cave,"
with a few tweaks and enhancements (written as a tutorial, and as
a test of the library), "Bleeding Kansas," an unnamed Star Trek game,
and Act I of "Nikolai Grozny." "Colossal Cave" was fairly close to
beta at one point, but I've since hacked my library to pieces, and
have been putting the effort that would've been needed to get "Cave"
out the door into rewriting the library in Kawa instead.
> As a side note, can someone tell me where to download a printable
> copy of the Z-Machine specification? I've found a browsable version
> online but I'd really like to be able to print it out.
I wound up just printing out the HTML; I'm not sure if there's a
PDF anywhere.
-- Sue --
(unlikely to get much recreational hacking time in the next couple
of months, however, due to work pressures)
Kevin Russell
>
> Actually, the reason I started trying to resurrect AdvSys is that my son
> expressed an interest in writing an adventure game. I basically took AdvSys
> and replaced the compiler with something that parses an infix language since
> he intends to move into C and C++ eventually. I know I should probably just
> have him use Inform or TADS but I kind of want a language whose
> implementation I understand so I can explain to him how the language itself
> works. Also, AdvSys is a much smaller system than any of the modern ones.
Good enough reason. There's no good documentation around that teaches
both IF-design and programming simultaneously. A double-newbie can't
really learn programming from the TADS/Inform manuals, and couldn't
apply the material from general programming introductions to IF languages
on their own. If you're effectively going to be the general programming
textbook for your son, it's perfectly reasonable you'd want the IF half
to be a system you're familiar with so you can be as effective a
textbook as possible.
I'm not sure it was really necessary to infix-ize AdvSys just to get
him ready for C/C++. People who take to programming easily will get
along no matter what their first language was. (Hey, *my* first
language was APL, and it obviously didn't do me any permanent damage
... um, maybe you'd better ignore that.) For people who won't take to
programming easily, the choice of first language will have an effect,
but it's impossible to predict ahead of time what the best choice
would be. Maybe 20% of learners (a completely made-up statistic) have
brains that fit the Scheme/Lisp way of doing things perfectly. If
your son turns out to be part of the 20%, you might have wasted your
time revising AdvSys. (On the other hand, I'm not the one who'd be
facing the child-abuse charges if he's part of the other 80%.)
Good luck to your son. Send him over here any time for advice
and/or brainwashing.
> BTW, AdvSys was never really trying to be like Scheme in the first place. It
> was trying to be like ZIL, the language Infocom used to write their games.
I kind of figured that from the "progn" and "setq" constructions.
Horribly unSchemely. I was kind of extrapolating what AdvSys might
turn into given your continued attention. :-)
>
> This discussion of converting AdvSys games to Kawa or some other version of
> Scheme interests me. I didn't know there were many AdvSys games to convert.
> The only one I'm really aware of is Gary McGath's "Columbus". Other than
> that, I think there was one about elves. Are there others?
Baf's Guide lists six! <http://www.wurb.com/if/devsys/12>
-- Kevin
Daniel Barkalow
> Susan Davis wrote:
> > ... (Which is requiring
> > some fairly significant changes, since Scheme won't really support
> > AdvSys' "(newclass superclass ...)" syntax.)
>
> You can't even do it with macros? Of course, I can't actually
> remember what exactly Scheme macros do for more than ten minutes at
> a time.
I'm not entirely sure what that syntax is, but I bet it's possible. The
main thing you can't do with scheme macros is capture variables (so you
can't have it expand so that "self" in a block of code that the macro gets
refers to a variable created by the macro expansion; instead, it will
refer to the "self" in the environment enclosing the macro use).
It may even be possible for "self" to be a special keyword inside that
macro that does the right thing, but I've never gotten this to work.
Scheme macros are damn weird. They work exactly the other way from how
everyone else's macros work.
-Iabervon
*This .sig unintentionally changed*
Kevin Russell
>
> David Betz wrote:
> > Kevin Russell:
> > > I'm pretty sure the way
> > > to go would be to piggy-back as a very rich library on one of the
> > > excellent already existing implementations of Scheme
>
> Yup. That's exactly what I'm up to. I started writing AdvSys code
> back before Inform, when TADS 1.x was a non-free commercial product,
> and AdvSys was the only free system I could find that didn't suck,
> and that gave me source code that I could hack.
>
> There were a bunch of features in TADS that were missing from AdvSys
> (most notably the limits of the AdvSys parser); my original goal was
> to hack AdvSys to match or exceed the functionality that TADS
> provided. Many of the features I wanted, though, looked like
> they were implementable as library code, so I started writing a
> WorldClass-ish library, and things sort of snowballed from there.
Sounds fascinating. Please put me on *your* mailing list.
> > > You're
> > > obviously very familiar with Kawa; I'm more partial to PLT's
> > > MzScheme myself
>
> I was actually using MzScheme at one point. But Kawa has the
> advantage that it compiles to a VM that everyone (or just about
> everyone) already has, without the need to download another
> runtime.
I go through manic/depressive love/hate cycles for anything related
to Java. One year everything's going fabulously. The next year,
the latest JDK version does wonky things on my Windows box, crashes
on my Linux box, doesn't even *exist* for my friend's Mac, Sun's
attitude seems to be "We don't feel like porting anything -- if you
want to run the latest JDK, buy a Sparcstation from us", and they
*still* haven't delivered on workable APIs they promised two years
ago.
This year things seem to be going ok in JVM-land, but after a couple
of cycles like this I'm still kind of leery of putting very many of
my eggs in Sun's basket again.
>
> > AdvSys was never really trying to be like Scheme in the first place.
> > It was trying to be like ZIL, the language Infocom used to write
> > their games.
>
> *nod* That was why I stuck with it so long. And z-machine output
> was feature #1 on my wish list of features to hack into a future
> version.
May you succeed!
Personally, I'd rather play a game on a z-machine than on the JVM.
The Java runtimes I currently have on my computers have memory
footprints bigger than those of brontosauruses and run faster than
a speeding glacier. (My 300Mhz/32meg laptop starts thrashing on
anything more involved than printing "Hello world" to the console.)
On the other hand, the great attraction of using Kawa and the JVM
is that you have vastly more freedom to play around with the interface,
with networking, and so on. There are hundreds of Java-fiends writing
bots and agents, MUD servers, virtual reality systems, and whatnot,
that you could potentially incorporate into your games with much less
work than writing them on your own. Maybe in a couple of years everyone
will have 2 GHz processors, a gig of RAM, we'll actually be able to run
the result. In the meantime, give me something that fits on a Palm
Pilot.
-- Kevin
Unmitigated Galla
>
> I know I should probably just
> have him use Inform or TADS but I kind of want a language whose
> implementation I understand so I can explain to him how the language
> itself works.
UTSL? IIRC, there's a document by Graham Nelson out there somewhere
that walks you through the internals of Inform. More to the point, the
Inform language is strongly tied to the design of the Z-machine; if you
understand the Z-machine, exactly how Inform is going about its work
is very obvious.
-- Sue --
(I can definitely understand if there's a NIH factor, though; it's been
a factor in my perseverence with my AdvSys and Scheme stuff)
--
Susan Davis <s...@sue.net>
Unmitigated Galla
> On Fri, 1 Sep 2000, Kevin Russell wrote:
> > Susan Davis wrote:
> > > ... (Which is requiring
> > > some fairly significant changes, since Scheme won't really support
> >
> > You can't even do it with macros?
>
> main thing you can't do with scheme macros is capture variables
The other thing you can't do is introduce new syntaxes, which is the
problem. Somewhere in
(define-syntax object
(syntax-rules (noun adjective method variable)
( (object newclass) ... )
...
( object ... )))
there needs to be a (define-syntax newclass ...), in order to allow
one to define (newclass newerclass ...), and that can't happen.
--
Susan Davis <s...@sue.net>
Unmitigated Galla
> Daniel:
> > The main thing you can't do with scheme macros is capture variables
>
...by which I mean that you can't cause additional new syntaxes to be
introduced in the containing environment as a side effect of defining
a syntax.
--
Susan Davis <s...@sue.net>
Daniel Barkalow
Ah, okay. I wasn't paying sufficient attention to the intended syntax; I
thought newclass was a literal rather than a variable.
Matthew T. Russotto
David Betz <db...@xlisper.mv.com> wrote:
}A 386 class machine should be more than capable of runnning something far
}more powerful than the Z-Machine.
Hence Glulx.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Jonadab the Unsightly One
> My justification for this (entirely off the top of my head)
> is that the mental state of composing well-written English
> text is nothing like the mental state for doing programming.
> While you're trying to write text, you don't want to be
> dealing with the vagaries of language syntax. I suspect
> that even dealing with ANSI C's multi-line text solution--
> putting quotes around each individual line of the string,
> called "ANSI string concatenation"--is more mental effort
> than it's worth, although it does allow you to insert leading
> spaces in a way that's difficult with Inform.
It's not difficult with Inform. If you want "leading" space
(that is, space at the beginning of each line) then the catch
is that you have to specify the line breaks, as follows...
print "^ * This is a cheap bulleted list.
^ * It contains four points.
^ * All four line up.
^ * There are four spaces to the left of each bullet.";
If you don't want that, just some included spaces, all
you have to do is make sure your spaces don't fall
immediately before or after a (source) line break.
(They can come before or after a ^ with no problem.)
If you need (for difficult-to-imagine reasons) a string
of spaces so long it won't fit on a line, you can always
do this...
print " ",
" ",
" ";
That's a pathological case, and it's not substantially
worse than the gyrations you have to go through in other
languages for the *common* case. The way Inform handles
multiline strings is very much superior to languages like
C and Perl. Mainly, I think, because multiline strings
are something you have to do in IF, a *lot*, so Graham
put some real thought into them. The Inform 5 solution
was decent, far better than the way most languages handle
the matter. The Inform 6 solution is better, and other
languages would do well to copy this feature in particular.
Oh, and if you don't like the way I formated my print
statement above, you can always do something like this...
print "
^ * This is a cheap bulleted list.
^ * It contains four points.
^ * All four line up.
^ * There are four spaces to the left of each bullet.";
This prints exactly the same thing as the one above.
> >I can think of one important feature that's semantically important, and
> >that's the ability to override base class behaviour when instantiating
> >a class.
I concur. In IF you often have a class with several objects,
each of which have their own minor deviations.
> This is at the heart of why IF is different from most programming.
> Most of IF is about constructing what we might otherwise call data.
> Most programs are about working with giant masses of largely identical
> chunks of things, and most programming languages are tuned to supporting
> that notion. C++ certainly has mechanisms for created initialized
> data, but they're nothing like what you want when 95% of your "code"
> is initialized data and exceptions.
Yep, yep, yep. IF tends to have WAY more unique cases
than most other applications. Just think about how
you'd view a programmer who uses a Big Switch Statement
in implementing a database, a spreadsheet, or an image
manipulation app -- verses the fact that most of us here
have used numerous Big Switch Statements in IF code at
one time or another. Why? Because IF just has a lot
of specific cases. Only *this* key opens this door.
Only *this* key opens the jewelry box. Only *this*
NPC knows the solution to this puzzle. Only *this*
object... only *this* puzzle... only *this* character...
only *this* action, and only when *this* has already
happened and *this* hasn't happened yet.
--
Forward all spam to u...@ftc.gov
Jonadab the Unsightly One
> A 386 class machine should be more than capable of runnning something far
> more powerful than the Z-Machine. It may require a DOS extender if you're
> still running MS-DOS or WIN3.1. If you're running WIN95 or better the DOS
> extender is built in.
You have to be inhaling toxic chemicals to even THINK about trying
to run Windows '95 on a typical 386. Now, something far more
potent than the z-machine, sure, no problem; glulx should be no
trouble at all. You could even run Java on a 386. Or X. Probably
not both at once, though, unless you had way more RAM than is
typical for a 386.
All you need to do to see what a 386 can do is set it up
with DOS and buy some VGA-era games. Jazz Jackrabbit is
a good start -- impressive for a game of that era that
will run on that hardware. You can *almost* run Descent
on a 386, although it's going to creep even at low detail
settings unless your 386 is pretty good for a 386.
> Actually, even large memory model native MS-DOS
> programs should be able to do better than the Z-Machine.
Easily. The z-machine will run on the 8088 or even less
powerful units than that. Problem with native MS-DOS
programs is they won't run under NEARLY as many different
architectures as the z-machine. Until relatively recently,
doing things like graphics in a cross-platform way was
pretty much not possible. It's still problematic.
Where, for example, is the Mac port of SVGAlib?
As far as address space, though, the terp can handle
any platform-specific addressing weirdness (such as
EMS/XMS/UMBs/DPMI under DOS; with CWSDPMI being
freely available, that's probably the easy way for
the terp to go to handle this). The VM (like glulx)
just needs to be designed with the assumption that
games may need more than (whatever the z-machine
limit was).