Speaking as someone who knows how Curses works, I think I'd say
that it runs at best uncomfortably...
> There are other kinds of game that Inform can't do easily. For
> example, a game where the NPCs had proper representation of knowledge,
> where they would remember things that you had told them, and things
> that you had asked them about, and behaved accordingly, perhaps
> maintaining some kind of emotional state.
I don't think this is really a limitation of Inform, as such: the
language is perfectly flexible enough to accommodate as much of this
as you want to implement, and I'm sure the same must go for TADS as
well. Features like this are hard to generalise implementations of,
so it would not really be appropriate to include them in the Library
anyway.
> Another example (one which one of the programmers of the late Magnetic
> Scrolls once played with) is a game in which things are more flexible;
> where the landscape, objects and NPCs don't exist until you come
> across them, at which point they are created, consistently with
> everything that you've already seen.
This is a much older idea, really! Antiquated mainframe maze games
(and their modern inheritor, NetHack) have done this for years. Again,
this is easy enough in Inform if you want to implement it.
> If you want to write using some other language, then by all means do
> so. If it produces a game which is interesting enough, then I'll play
> it (on less portable hardware), but I'm not convinced at present that
> Inform could be made dramatically easier to use by adding any fancier
> features; it looks quite adequate for the kinds of games that it's
> designed for.
Well, thanks! Yes, my present feeling is that Inform's library
implements about the right amount of "world model", and that any
really radical extras ought to be in separate, take-or-leave extra
library files.
> If you write Zork-type games which require a 486, then I'm going to
> wonder why.
>
> I'm all for developing Inform and Z-code, however. I think it would
> be interesting to redesign Z-code with the benefits of hindsight,
> making it quicker to interpret, perhaps (this *is* an issue on some
> machines which people want to use in playing games!), or adding some
> features which are now practical. Or perhaps simply to compress text
> better. But it doesn't seem compelling just at the moment.
This is an argument advanced every few months on the newsgroup. The
answer I always give is somewhat like yours, i.e., that there is little
point in redesigning the Z-machine unless some significant practical
gain would follow (the aim is not to design a "perfect" platform but
to maintain a healthy work-horse).
The Z-machine can be implemented pretty quickly. I can't, offhand,
think of a good way of improving speed by any significant margin,
given the compactness of the format. We probably could soup up the
text compression rate, but (again) that's probably not going to be
needed enough to make it worthwhile.
What I am working on is a much better-defined and better interpreted
present state of the Z-machine!
Graham Nelson