> In article <weu44ft97q.fsf_-_@iasc3.scm.liv.ac.uk>, Bruce Stephens
> <bruce@supr.scm.liv.ac.uk> writes:
>> 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.
In a theoretical sense, I agree (all languages are equal, and all of
that), but I suspect programming in a more dynamic language would
change the way one thought of doing such things. I think the Inform
code would be rather special-case, whereas I can imagine writing
general purpose code in another language for a (very!) limited domain
of knowledge.
>> 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.
Well, the general idea is an obvious one, and I (and the MS person
involved) know that it's been done before. His ideas seemed
interesting at the time, and still do, for that matter, for their
generality. The system would have "forms" or "scripts" (depending on
which AI idea you want to follow) of common things and their
relationships, and would generate instances of them, giving details
generated randomly from suitable criteria. It would remember what it
had generated, and constrain new objects to that, and of course make
sure it kept a consistent description of objects already examined. He
had plans of a similar approach to generating puzzles and stories.
This wouldn't work too well as a replacement for the current set of IF
games, but he was planning for MUDs, where it probably would work.
(He had unified the ordinary command language that players use with
the language that game designers could use, for example, so creating
new things could be done on-the-fly.)
As I say, this was years ago, and he's almost certainly interested in
other things by now.
> 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.
I think so too. Together with the library files, Inform surely makes
writing conventional IF far easier than it would be in (choose a
language here) with no specific support.
> 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.
I think the compactness is my concern. The Z-machine could be speeded
up by moving some of the information that's packed so carefully into
separate bytes which can be operated on more quickly. Of course, this
would probably create larger codes, and so would only be of benefit on
machines (like the Psion) which couldn't really use it for space
reasons.
> What I am working on is a much better-defined and better interpreted
> present state of the Z-machine!
I'd certainly like to see that too. The portable Zip interpreter is
nicely written, but it could do with a little work. It would be nice
for the machine-dependent bits to be separated out more cleanly, with
the functions required more tightly specified.
For example, it's not quite clear what I'd need to do to allow
proportional text; there are all sorts of routines which seem to want
to be able to move to particular character positions on the screen, or
want to be able to overwrite characters with spaces. I'm sure it can
be done, because Bryan Scattergood's ITF ports do it correctly (at
least most of the time), but it's not obvious to me.
One immediate thing I'd suggest is to move the task of splitting lines
out into the machine-dependent bit. I think that's a better place for
it to be, given that many implementations will allow users to change
font or screensize at runtime.
> Graham Nelson
-- Bruce Institute of Advanced Scientific Computation bruce@supr.scm.liv.ac.uk University of Liverpool http://supr.scm.liv.ac.uk/~bruce/