Location management/Revisiting locations

17 views
Skip to first unread message

Nicholas Shore

unread,
Jan 14, 2000, 3:00:00 AM1/14/00
to
I stepped on this interactive fiction business by chance a few days ago, so
I'm a total newcomer to the genre. Basically my attitude was very positive
from the start, but somehow that changed a bit when I started playing some
of the games from last years competition package. (Winter Wonderland, Four
seconds)What irritated me most (and gave me headaches) was the way of
travelling from one location to the next in most of the games. Especially
when re-visiting locations I found it very hard to remember the routes I had
travelled and retracing my steps. Why does noone put a location jump into
the game for already visited location, so you could for example type <go to
the kitchen> to revisit the kitchen you visited earlier? To me that neither
seems technically impossible nor inadvisable from a gameplay point of view.
(I don't know the interpreters of course, so I don't know how difficult it
would be to program, but even with my limited knowledge of Turbo Pascal and
Basic it doesn't seem impossible.)

Jonathan Blask

unread,
Jan 14, 2000, 3:00:00 AM1/14/00
to
I know that some of the Magnetic Scrolls games offered this >GO TO
LOCATION kind of thing, and while they aren't commercially available
anymore, if you dig around the 'net, you probably could find some.
I don't think it's a necessarily easy thing to do, though.
Depends on the game's layout and what not, and I just think that most
authors just don't think it's worth the extra effort.
-jon
"If I got stranded on a desert island (with electricity)/
And I could bring one record and my hi-fi/
I'd bring that ocean surf cd (Relaxing Sound of Ocean Surf)/
So I could enjoy the irony." - Dylan Hicks


Volker Lanz

unread,
Jan 14, 2000, 3:00:00 AM1/14/00
to

It's not a question of technical implementation (that would be really easy to
do), it's a matter of design. Only two things that come to my mind right now
about this:

1) Doors. If a door to a room already visited, say the kitchen, has been locked
in the meantime, what do you tell the player? "You can't do that now." Not very
good. "The door to the kitchen is locked." Hmm, how does he know when he's not
there? Or put him in front of the locked door? And what happens with two doors,
one locked, one open, but the room on the other side of the open door hasn't
been visited so far? Is the player allowed to "fly" through that room? And so on
and so on...

2) NPCs. Realistic NPCs aren't allowed to "jump" from one location to another.
So why should the player? And, imagine a mystery where you have to follow a
suspect -- the ability to jump to a distant location would give you an unfair
advantage over the suspect.

So it seems to me that in most games this way of movement wouldn't really make
sense. Maybe in really small games -- but there it would be unnecessary anyway.


-- v


Steven Jones

unread,
Jan 15, 2000, 3:00:00 AM1/15/00
to
The game 'Titanic - Adventure out of time' offers this feature BUT it is
switched off during the sinking and you cannot do it if you are too far
below decks.
The feature is included mostly for convenience - Titanic was the largest
ocean liner of its time so finding one's way around it is quite a
challenge and would be distracting during most of the game.


Nick Montfort

unread,
Jan 15, 2000, 3:00:00 AM1/15/00
to
In article <85nno2$bsf$1...@infosun2.rus.uni-stuttgart.de>,
"Nicholas Shore" <nds.bl...@gmx.de> wrote:

>Especially when re-visiting locations I found it very hard to
>remember the routes I had travelled and retracing my steps. Why does
>noone put a location jump into the game for already visited location,
>so you could for example type <go to the kitchen> to revisit the
>kitchen you visited earlier?

For a known location like the main character's house or office, it
seems inexcusable to omit this capability. It would be useful in other
contexts, too, even if it is more excusably absent from confusing
underground tunnels or cityscapes where there may be multiple routes.
It might matter whether you take the bridge or the tunnel, because
something might be happening in one of them...

In Suspended you can order the robots to go to different locations, of
course, and they do this on their own. So there's no problem with
doing this for some setting layouts.

-Nick M.


Sent via Deja.com http://www.deja.com/
Before you buy.

Daniel Barkalow

unread,
Jan 16, 2000, 3:00:00 AM1/16/00
to
On Fri, 14 Jan 2000, Volker Lanz wrote:

> It's not a question of technical implementation (that would be really
> easy to do), it's a matter of design. Only two things that come to my
> mind right now about this:

You could have multiple turns pass while you go from place to place, with
NPCs able to move, turns elapse, clocks advance, etc. You could also have
the character stop upon reaching a point where there's a problem. This is
what Suspended did, and it works well. The main point is that you can do
something different with a different robot while the first one is walking
somewhere, but it also means that you don't have to think about the
details of moving from place to place unless there's something important
there.

-Iabervon
*This .sig unintentionally changed*


ma...@bioware.com

unread,
Jan 17, 2000, 3:00:00 AM1/17/00
to

Nicholas Shore wrote:

> I stepped on this interactive fiction business by chance a few days ago, so
> I'm a total newcomer to the genre. Basically my attitude was very positive
> from the start, but somehow that changed a bit when I started playing some
> of the games from last years competition package. (Winter Wonderland, Four
> seconds)What irritated me most (and gave me headaches) was the way of

> travelling from one location to the next in most of the games. Especially


> when re-visiting locations I found it very hard to remember the routes I had
> travelled and retracing my steps. Why does noone put a location jump into
> the game for already visited location, so you could for example type <go to

> the kitchen> to revisit the kitchen you visited earlier? To me that neither
> seems technically impossible nor inadvisable from a gameplay point of view.
> (I don't know the interpreters of course, so I don't know how difficult it
> would be to program, but even with my limited knowledge of Turbo Pascal and
> Basic it doesn't seem impossible.)

Another reason to dis-allow teleport; areas change while you are away. If you
breeze through the environment you might miss updates to rooms or npc's.

Nicholas Shore

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to

<ma...@bioware.com> schrieb im Newsbeitrag
news:38834A95...@bioware.com...

>
> Another reason to dis-allow teleport; areas change while you are away. If
you
> breeze through the environment you might miss updates to rooms or npc's.
>
Of course there are always many reasons not to do something, but there are
always intelligent ways of getting around problems like that. One would be a
route finder which simply automatically walks the normal route the player
would normally walk manually. It could stop if something happened or if a
location on the way has changed. I just think that although die-hard
adventurists might think map-painting is an integral part of every IF
andventure, there are other groups of people who might think they would like
to play some IF now and then and simply have fun doing so. After all this is
playing we are talking about, not some way of boosting our egos by winning
the game.

Kevin Forchione

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
"Nicholas Shore" <nds.bl...@gmx.de> wrote in message
news:861hct$30b$1...@infosun2.rus.uni-stuttgart.de...

>
> <ma...@bioware.com> schrieb im Newsbeitrag
> news:38834A95...@bioware.com...
> >
> > Another reason to dis-allow teleport; areas change while you are away.
If
> you
> > breeze through the environment you might miss updates to rooms or npc's.
> >
> Of course there are always many reasons not to do something, but there are
> always intelligent ways of getting around problems like that. One would be
a
> route finder which simply automatically walks the normal route the player
> would normally walk manually.

Unless your route is highly restricted there is no *normal* route in most
games. You could, of course, keep a list of locations built up as the player
visits them and travel back up the list stopping at the first occurrence
(the last visitation) of a room. In games with wandering NPCs and character
changes each NPC could keep track of its journey this way. But the lists are
going to get rather long. And suppose you do change characters. Do you have
access to anyplace they've visited or known about, or places you've visited
and known about, or only those you've accessed as that character.

> It could stop if something happened or if a
> location on the way has changed.

This is trickier than it sounds. Are we talking location state-change? Or
just a significant happening flag? With inform.t, for example, a wait can be
interrupted by a stopWaiting() request. But these are generated in *game*
time, which means that daemons/fuses are executing. Infocom's Sherlock
allows you to travel about the map in a cab, but you miss anything that
might be going on outside.

--Kevin

kar...@fermi2.chem.yale.edu

unread,
Jan 18, 2000, 3:00:00 AM1/18/00
to
Nicholas Shore <nds.bl...@gmx.de> wrote:

> <ma...@bioware.com> schrieb im Newsbeitrag
> news:38834A95...@bioware.com...
>>

> Of course there are always many reasons not to do something, but there are
> always intelligent ways of getting around problems like that.

Always?

> One would be a route finder which simply automatically walks the normal

> route the player would normally walk manually. It could stop if something


> happened or if a location on the way has changed.

I'll add to Kevin's note. This could be fiendishly complicated. Obviously
you need to keep track of the text you get when you enter the room. But
what about a room which has different text depending on where you enter it
from? If you are in the kitchen and want to go to the pipe room, you'll
need to store the text you get throughout the traversal (for each pair of
rooms), and try moving the player that way, capture the text, and see if
it's the same. Of course, many times you won't ever have traveled that
route before. And the actors need to be in the same positions too...

Also, if you've got four rooms in a square, do you go e then n or n then e
to get from one corner to the other? The consequences may be totally
different, and you wouldn't want the computer to choose which route you
take!

An idea like this (and GUI IF writing, as long as we're on the subject)
works just fine if your game uses no fancy code. If all you have are n
rooms with m objects with a straightforward map whose paths don't change,
and you don't have NPCs or daemons fouling things up, then it works just
fine. It *might* have worked for Scott Adams adventures, but I'm not even
sure about that. Nowadays, I think, most IF is just too complicated for
that. As I said in the GUI IF thread, even trying to code my first simple
puzzle, I had to delve into some (what seemed to me to be) TADS esoterics.

Instead, lots of people come up with clever ways to help this problem. One
is making an intelligent game map in the first place, that won't have lots
and lots of repeated walking. Another is to have you find an elevator if
you solve a certain puzzle, so you don't have to take staircases any more.
Magic words, special keys, maze shortcuts,whatever.

> I just think that although die-hard adventurists might think map-painting
> is an integral part of every IF andventure, there are other groups of
> people who might think they would like to play some IF now and then and
> simply have fun doing so. After all this is playing we are talking about,
> not some way of boosting our egos by winning the game.

And *I* just think that sometimes people look too hard for things that
aren't there. I don't think it's a SPAG conspiracy. Yes, some of us enjoy
mapping, but almost all the RAIF readership, I suspect, would approve of
ways to save keystrokes in IF. We've all done the
> N.E.N.W.GET RED PIPE
> E.S.W.S.DROP RED PIPE
> N.E.N.W.GET GREEN PIPE
> E.S.W.S.DROP GREEN PIPE
enough times (zero is probably enough times) to want to save unnecessary
repetition. That stuff doesn't add either to the I or the F aspect of IF,
so it's not something we like. OTOH, any fix to this problem had better not
mess up the game!

-Amir

Mike Arnautov

unread,
Jan 23, 2000, 3:00:00 AM1/23/00
to
kar...@fermi2.chem.yale.edu wrote:

>An idea like this (and GUI IF writing, as long as we're on the subject)
>works just fine if your game uses no fancy code. If all you have are n
>rooms with m objects with a straightforward map whose paths don't change,
>and you don't have NPCs or daemons fouling things up, then it works just
>fine. It *might* have worked for Scott Adams adventures, but I'm not even
>sure about that. Nowadays, I think, most IF is just too complicated for
>that. As I said in the GUI IF thread, even trying to code my first simple
>puzzle, I had to delve into some (what seemed to me to be) TADS esoterics.

While I agree about the GUI aspect of it, the game mechanics
difficulties you describe are problematic only in so far as the IF
engine is entrusted with the running of your world.

To my mind, there are two very distinct strands to IF. One strand almost
attempts to go the way of Doom-like games in allowing the author to set
up the world and then let the engine handle reasonably realistically
anything the player might wish to do, while embroidering a plot on top
of that. Hence the discussions about throwing shoes at lights enclosed
in glass cabinets. :-) In the *very* long term, this may well be the
correct direction, but to be really effective it needs to be underpinned
by one heck of a lot of AI, which at present simply doesn't exist.

The other strand is less concerned with world creation and gives the
author a maximal degree of control, but also the responsibility for
anticipating what the player may or may not do. It is more about giving
the player a feeling of indirectly interacting with the author -- more
in the way of traditional oral story-telling.

Personally, I prefer the latter -- it is closer to what I understand by
Interactive Fiction. However, it would seem to me that the main IF-
authoring systems have developed more towards supporting the world-
creation strand of IF, than towards promoting the author's dialogue with
the player.

IMHO, YMMV etc...

--
Mike Arnautov | From the heart
http://www.mipmip.demon.co.uk/mipmip.html | of the sweet peony,
mailto:m...@mipmip.demon.co-antispam-uk | a drunken bee.
Replace -antispam- with a single dot. | Basho

Kevin Forchione

unread,
Jan 24, 2000, 3:00:00 AM1/24/00
to
"Mike Arnautov" <m...@mipmip.demon-co-antispam-uk> wrote in message
news:UgG$vOASh3...@mipmip.demon.co.uk...

> While I agree about the GUI aspect of it, the game mechanics
> difficulties you describe are problematic only in so far as the IF
> engine is entrusted with the running of your world.

Because the basic means of interaction is the command line, the basic
function of an IF engine is two-fold: (a) parse the command into game
objects; (b) process the command. By decoupling the running of the world
from the IF engine you are simply moving it into the game source itself and
particularizing it. That's how many of the current IF systems started out,
as games whose generalized features were extrapolated into libraries.

> To my mind, there are two very distinct strands to IF. One strand almost
> attempts to go the way of Doom-like games in allowing the author to set
> up the world and then let the engine handle reasonably realistically
> anything the player might wish to do, while embroidering a plot on top
> of that. Hence the discussions about throwing shoes at lights enclosed
> in glass cabinets. :-) In the *very* long term, this may well be the
> correct direction, but to be really effective it needs to be underpinned
> by one heck of a lot of AI, which at present simply doesn't exist.

Well, I wouldn't go that far. What Inform and WorldClass achieve, as well as
TADS ADV.T with some library assistance, is an object accessibility
validation based on actor scope that revolves around simple definitons of
containment. This has followed logically from and in conjunction with the
"smartening" of the parser. But the systems do not attempt to employ a
realistic physics model. Since IF has moved into an object-oriented approach
it is only natural to speak of object behaviours and object modelling.

> The other strand is less concerned with world creation and gives the
> author a maximal degree of control, but also the responsibility for
> anticipating what the player may or may not do.

The simple solution to this is to remove the #include of the library modules
provided with the system. After all, the library is merely a collection of
objects and routines that provide a service for the author so that they
don't have to concentrate on reinventing the wheel. But this does not remove
the author's responsibility for anticipating what the player might do.

There is nothing inherent in the systems to prevent an author from following
down any path they wish, even with the more sophisticated systems, such as
TADS or Inform. And these systems has striven for the maximum in power and
flexibility for the author and is perhaps the reason why they are so
popular. You can, if you wish, modify the behaviour of an object, a class of
objects, or even the global functioning of the system.

>It is more about giving
> the player a feeling of indirectly interacting with the author -- more
> in the way of traditional oral story-telling.

I can't speak to traditional oral story-telling. The roots of IF don't
appear to have come from that perspective, but on a desire for the computer
to *simulate* a physical environment. Hence the very early games are mostly
cave crawls and treasure hunts. After the world model became sufficiently
sophisticated then we began to see more avant garde works, and a general
de-skilling of the user group. The same thing has happened with the PC in
general.

As for any feeling of indirect interaction with the author one might have,
this is born out only through the quality of the author's writing and its
ability to evoke an emotional response -- and has nothing to do with system
development, whether it be a gui front-end or a physics world model. Any
feeling of interaction you obtain through a graphics game must come from an
evocation of emotional response.

> Personally, I prefer the latter -- it is closer to what I understand by
> Interactive Fiction. However, it would seem to me that the main IF-
> authoring systems have developed more towards supporting the world-
> creation strand of IF, than towards promoting the author's dialogue with
> the player.

I suppose I am still puzzled by what you mean by this. However, I would be
very surprised if one the major systems could not support what you'd like to
achieve. (I'm assuming that by "what I understand by Interactive Fiction"
you are refering to existing games, and not a redefinition of the genre.)

--Kevin

Mike Arnautov

unread,
Jan 30, 2000, 3:00:00 AM1/30/00
to
Sorry... I've been off the net for a variety of reasons...

Kevin Forchione <Lys...@email.msn.com> wrote:

>> While I agree about the GUI aspect of it, the game mechanics
>> difficulties you describe are problematic only in so far as the IF
>> engine is entrusted with the running of your world.
>
>Because the basic means of interaction is the command line, the basic
>function of an IF engine is two-fold: (a) parse the command into game
>objects; (b) process the command. By decoupling the running of the world
>from the IF engine you are simply moving it into the game source itself and
>particularizing it.

Sure. Except that I'd use the word "personalising" rather than
"particularizing". Depending on what one aims at, this can be seen as
either desirable or undesirable. Hence my remarks about two directions
in which IF can potentially develop.

>That's how many of the current IF systems started out,
>as games whose generalized features were extrapolated into libraries.

And others didn't. E.g. Dave Platt's engine for adv550 went the other
way -- offering the author greater freedom and ease in striving for the
personalised effect.

>> To my mind, there are two very distinct strands to IF. One strand almost
>> attempts to go the way of Doom-like games in allowing the author to set
>> up the world and then let the engine handle reasonably realistically
>> anything the player might wish to do, while embroidering a plot on top
>> of that. Hence the discussions about throwing shoes at lights enclosed
>> in glass cabinets. :-) In the *very* long term, this may well be the
>> correct direction, but to be really effective it needs to be underpinned
>> by one heck of a lot of AI, which at present simply doesn't exist.
>
>Well, I wouldn't go that far. What Inform and WorldClass achieve, as well as
>TADS ADV.T with some library assistance, is an object accessibility
>validation based on actor scope that revolves around simple definitons of
>containment. This has followed logically from and in conjunction with the
>"smartening" of the parser. But the systems do not attempt to employ a
>realistic physics model. Since IF has moved into an object-oriented approach
>it is only natural to speak of object behaviours and object modelling.

Depends on what you consider effective -- for them objects to behave
realistically, the afore-mentioned AI is required. Otherwise you get the
situations like "the shoe bounces off with a thud...", "the axe bounces
off with a thud...", "the sock bounces off with a thud..." -- oops! My
point is that to be at all convincing at running the world, the engine
needs to know one heck of a lot about the world and to have some heft AI
to boot. For me, such small lapses spoil the game, because I know that
the author's attention lapsed and it is the engine I am really
communicating with.

>> The other strand is less concerned with world creation and gives the
>> author a maximal degree of control, but also the responsibility for
>> anticipating what the player may or may not do.

[....]


>There is nothing inherent in the systems to prevent an author from following
>down any path they wish, even with the more sophisticated systems, such as
>TADS or Inform. And these systems has striven for the maximum in power and
>flexibility for the author and is perhaps the reason why they are so
>popular. You can, if you wish, modify the behaviour of an object, a class of
>objects, or even the global functioning of the system.

Sure, one can ignore the world-modelling abilities of the engine. But
where's the *positive* support for the personalised style of writing?
E.g. I was amazed to discover that Inform doesn't support variable text
even though Dave Platt's A-code had rudimentary text switches back in
early 80s! What seems to be the case is that because these engines offer
world-modelling facilities, they are implicitly pushing IF into the
world-modelling direction.

>>It is more about giving
>> the player a feeling of indirectly interacting with the author -- more
>> in the way of traditional oral story-telling.
>
>I can't speak to traditional oral story-telling. The roots of IF don't
>appear to have come from that perspective, but on a desire for the computer
>to *simulate* a physical environment.

In which case text-based IF is doomed, because Doom-like graphical
engines are damn sight better at it, for very obvious reasons: it is
easier to *show* the behaviour of the world, than to describe it. But I
disagree, anyway -- the desire was to *involve* the player in a
fictional environment. The amazing thing was that it turned out to be
possible to do so using language -- and so IF was born.

>As for any feeling of indirect interaction with the author one might have,
>this is born out only through the quality of the author's writing and its
>ability to evoke an emotional response -- and has nothing to do with system
>development, whether it be a gui front-end or a physics world model. Any
>feeling of interaction you obtain through a graphics game must come from an
>evocation of emotional response.

I see we'll have to differ on this. While a picture may be worth a
thousand words, the problem is that is liable to be a different thousand
for every one of us. Using text, gives you are much greater precision in
communicating with the player *provided* that is what your aim is. If
all you want to do is model a world, then you are right, of course. But
then -- why do it using text?

>> Personally, I prefer the latter -- it is closer to what I understand by
>> Interactive Fiction. However, it would seem to me that the main IF-
>> authoring systems have developed more towards supporting the world-
>> creation strand of IF, than towards promoting the author's dialogue with
>> the player.
>
>I suppose I am still puzzled by what you mean by this.

Perhaps I should give you an example. One of the high-points of my life
was reading one of the logs of adv660 (in its gamma-test phase I went
through many hundreds of player logs and kept tweaking the game
accordingly). The player in question had an ingenious idea about doing
something -- the something in question being of the sort that a world-
driving engine could take care of and give a stock response; instead the
player got a very specific reply on the lines "you didn't really expect
this to work, now did you?", to which his response was to type instead
of the next command: "You bastard Arnautov!". Yes, I know this can
happen in any style of an IF game, but given the world-modelling
capabilities of Inform et al., authors are much more likely to be
worrying about NPCs moving through their world, which mostly is of no
interest to the player at all.

>However, I would be
>very surprised if one the major systems could not support what you'd like to
>achieve.

OK, name a system (other than A-code) which positively supports texts
(including descriptions of places/objects) which automatically morph
themselves according to the context. To give a specific example,
consider the crystal sculpture of adv550/660, which keeps changing shape
when the player isn't looking. It has something like 20 states (I could
be wrong on the exact number): a tiger, a mule, a pig, an emu, an
ibex... One could have 20 different objects and keep shuffling them
about, sure. But what I'd like to be able to do is, in a self
explanatory extension of the A-code notation, something like this:

(NB: curly braces indicate text nesting, square brackets are a text
array with elements separated by slashes; UNSTABLE switch indicates that
the state of the object is incremented by one when it is first picked
up; the compiler/translator ignores 'a', 'an', 'the' in the vocabulary)

TEXT ANIMALS
a [/pig/tiger/n emu/mule/n ibex]

OBJECT SCULPTURE
VOCABULARY {ANIMALS}
UNSTABLE
INVENTORY
A crystal sculpture of {ANIMALS}
IS_HERE
[A/There is a] crystal sculpture of {ANIMALS} [sits in an icy
niche/is here].
[....]

And at run-time, the only thing that the program does is the occasional

RANDOMISE SCULPTURE

There are probably other ways to support this style of IF, which I
haven't even thought of yet. Trouble is, nobody else has either. :-)

If I ever get around to doing version 11 of A-code, I'll go further.
E.g. have text switches which automatically self-randomise, as well as
text switches which automatically increment their state every time they
are used. The goal, for me anyway, is to get away as much as possible
from the player getting a stock response -- to anything. I want the
player to feel *my* presence -- not that of the engine!

I am not saying that the two styles are incompatible. But the bias of
the authoring system will be reflected in the approach most authors will
take. I would like to see some counter-weight to the world-modelling
bias.

Dan Shiovitz

unread,
Feb 1, 2000, 3:00:00 AM2/1/00
to
In article <7b0EBGAG...@mipmip.demon.co.uk>,

Mike Arnautov <m...@mipmip.demon-co-antispam-uk> wrote:
>Sorry... I've been off the net for a variety of reasons...
>
>Kevin Forchione <Lys...@email.msn.com> wrote:
>
[..]

>
>Sure, one can ignore the world-modelling abilities of the engine. But
>where's the *positive* support for the personalised style of writing?
>E.g. I was amazed to discover that Inform doesn't support variable text
>even though Dave Platt's A-code had rudimentary text switches back in
>early 80s! What seems to be the case is that because these engines offer
>world-modelling facilities, they are implicitly pushing IF into the
>world-modelling direction.

I think you're being misled by the fact that it doesn't special-case
for variable text into thinking that it can't support it. The example
you mention below with the statue that changes its description to one
of a list of different animals is simple in TADS or Inform. For
instance, in TADS you could do
statue: fixeditem
animals = ['fish' 'dog' 'bird']
ldesc = "It looks like a statue of a
<<self.animals[rand(length(self.animals))]"

and get a new description every time you looked at it. Or you could
write code to switch the description every three turns or whatever.
People often seem to think their own favorite language is the best,
and of course it has a lot to do with personal preference, but it's a
big mistake to underestimate the value added by the literally years of
testing by dozens of people that the major languages have.

>>>It is more about giving
>>> the player a feeling of indirectly interacting with the author -- more
>>> in the way of traditional oral story-telling.
>>
>>I can't speak to traditional oral story-telling. The roots of IF don't
>>appear to have come from that perspective, but on a desire for the computer
>>to *simulate* a physical environment.
>
>In which case text-based IF is doomed, because Doom-like graphical
>engines are damn sight better at it, for very obvious reasons: it is
>easier to *show* the behaviour of the world, than to describe it. But I
>disagree, anyway -- the desire was to *involve* the player in a
>fictional environment. The amazing thing was that it turned out to be
>possible to do so using language -- and so IF was born.

I agree that involvement is important but not that simulation is
necessarily better done graphically. There are some things that it's
always going to be easier to display textually -- people's thoughts
and feelings, for instance.

[..]


>If I ever get around to doing version 11 of A-code, I'll go further.
>E.g. have text switches which automatically self-randomise, as well as
>text switches which automatically increment their state every time they
>are used. The goal, for me anyway, is to get away as much as possible
>from the player getting a stock response -- to anything. I want the
>player to feel *my* presence -- not that of the engine!

I don't think you're correct in thinking people want to simulate the
world as an end in itself. People want to simulate the world so they
can have a place to put their stories. If I didn't have to worry about
objects at all -- if I could just say "Give me a room with a chair in
it and a fireplace and a rug under which is a trapdoor. Now put some
bric-a-brac and a loaded pistol on the mantlepiece" and have all those
things behave realistically without me doing any coding, think how
much effort I could put into the NPCs that live in the room! Surely
the player would feel the authorial presence in a game like that, even
if all the chairs in the room were identical copies of the Ideal Chair.

>Mike Arnautov | From the heart

--
Dan Shiovitz :: d...@cs.wisc.edu :: http://www.drizzle.com/~dans
"He settled down to dictate a letter to the Consolidated Nailfile and
Eyebrow Tweezer Corporation of Scranton, Pa., which would make them
realize that life is stern and earnest and Nailfile and Eyebrow Tweezer
Corporations are not put in this world for pleasure alone." -PGW


Mike Arnautov

unread,
Feb 2, 2000, 3:00:00 AM2/2/00
to
Dan Shiovitz <d...@cs.wisc.edu> wrote:

>I think you're being misled by the fact that it doesn't special-case
>for variable text into thinking that it can't support it.

Not guilty your honour. It quite feasible to do OO programming in some
variants of Fortran IV, but that didn't mean that the language makes it
easy, let alone encourages you to do so.

> The example
>you mention below with the statue that changes its description to one
>of a list of different animals is simple in TADS or Inform. For
>instance, in TADS you could do
> statue: fixeditem
> animals = ['fish' 'dog' 'bird']
> ldesc = "It looks like a statue of a
> <<self.animals[rand(length(self.animals))]"
>
>and get a new description every time you looked at it.

Which in no way achieves what my example was showing. There the text
morphing was in one swoop extended to the vocabulary, so that the
sculpture in its ibex shape could not be referred to as a pig, for
example. Similarly, in that example *any* textual reference to the
sculpture would be automatically morphed without being in any way
instrumented to do so -- and that applies to indirect references too.
E.g. a DROP ALL command will reference it correctly in reporting
player's actions.

And how do you tackle

It looks like a statue of {ANIMALS} to me. Now, don't ask me
why anybody would sculpt {ANIMALS} from crystal, but there you are!

without being inconsistent due to randomising? You'd have to assign the
relevant array element to a string first, and then use it twice in the
description. Text morphing does it all for me, without me. I can even
say

It looks like a statue of {ANIMALS} to me.[ Now, don't ask me
why anybody would sculpt a pig from crystal, but there you are!/]

With the effect that the "don't ask me" aside only occurs if the
sculpture is examined in the state in which it is originally found.
(Text switches do the sensible thing with "out of bounds" values!)

I'd say that in fact your example shows to what extend TADS does *not*
support text morphing.

> Or you could
>write code to switch the description every three turns or whatever.

Exactly. All very specific particular things that one would have to do -
above all, to write code. A-code text morphing does not require you to
*do* anything, other than declare things and then reference the
sculpture in no way differently from any other objects. All the doing is
done automatically. There is no special code involved.

>People often seem to think their own favorite language is the best,
>and of course it has a lot to do with personal preference, but it's a
>big mistake to underestimate the value added by the literally years of
>testing by dozens of people that the major languages have.

And people often seem to think that the features they haven't met and
don't fully understand, cannot have much of a value. :-) Text morphing
was, AFAIK, invented by Dave Platt and the A-code engine was widely
distributed with adv550. It is a mystery to me that nobody seems to have
noticed the potential of this innovation. I can only assume that the
push was all towards world modelling -- which is where we have started,
isn't it?

>>In which case text-based IF is doomed, because Doom-like graphical
>>engines are damn sight better at it, for very obvious reasons: it is
>>easier to *show* the behaviour of the world, than to describe it. But I
>>disagree, anyway -- the desire was to *involve* the player in a
>>fictional environment. The amazing thing was that it turned out to be
>>possible to do so using language -- and so IF was born.
>

>I agree that involvement is important but not that simulation is
>necessarily better done graphically. There are some things that it's
>always going to be easier to display textually -- people's thoughts
>and feelings, for instance.

You forget... We were talking about entrusting the engine with the
running of the world. Do you entrust textual display of people's
thoughts and feeling to an engine too? I hope you are going to invite me
to that Nobel presentation! :-)

>I don't think you're correct in thinking people want to simulate the
>world as an end in itself. People want to simulate the world so they
>can have a place to put their stories.

Fine. So which features of IF languages support the non-world modelling
aspects of IF? And by that I don't mean NPCs "leading independent
lives", that's still world modelling (and only too often singularly
pointless). What features are there to help the author to provide a
richer text experience to the player?

E.g. what really irritates me in IF is when you do something, and get a
special message. And you do it again -- and get the same special
message. And again, and again... E.g. you cross a crystal bridge and
"the air is filled with unearthly harmonies which take your breath
away". So far so good, but... every time??? Surely not. On second
crossing, the message should forget about taking your breath away, and
on third and subsequent it should probably simply say something like
"You tinkle your way across the crystal bridge." With text morphing you
just have to put the three messages into one text switch and declare the
whole text to be self-incrementing. And that's it. Or you can get clever
and save space by using a number of smaller switches instead of one
large one -- all in the same text. (to be honest, self-incrementing
texts are not in A-code yet -- I increment explicitly, but it would be
easy to do; and if I ever get around to version 11, it'll go in first
thing!)

> If I didn't have to worry about
>objects at all -- if I could just say "Give me a room with a chair in
>it and a fireplace and a rug under which is a trapdoor. Now put some
>bric-a-brac and a loaded pistol on the mantlepiece" and have all those
>things behave realistically without me doing any coding, think how
>much effort I could put into the NPCs that live in the room! Surely
>the player would feel the authorial presence in a game like that, even
>if all the chairs in the room were identical copies of the Ideal Chair.

Sorry... Count me out. It is a matter of taste, sure, but count me out.
I wouldn't think much about a novel in which the world is described in
stock phrases, just so that the author can concentrate on his characters
(or v.v. for that matter). Why should I like it any more in IF?

My wife has just pointed out to me a review of Toy Story 2 in the
Independent today, which is quite remarkably relevant (it may well be
viewable on their web site -- I am writing this off-line, so don't
know). The reviewer singles out as *the* feature which elevates the film
to the status of an artistic creation the fact that "wherever you look
on screen, you find that an attentive eye has gone before you". Which is
*exactly* what I mean by an IF work being a communication between the
author and the player, rather than a world model being run by an engine.
Interestingly enough, the review goes on to say "It is, in some
respects, as purely literary an effect as the cinema can offer."

Hear, hear! *That* is what for me text fiction is all about. *That* is a
direction in which I would like to see (some) IF works to strive for.
And it is something for which the existing IF-support languages appear
to offer no actual support.

R. Alan Monroe

unread,
Feb 5, 2000, 3:00:00 AM2/5/00
to
In article <s9i5hj...@corp.supernews.com>, d...@cs.wisc.edu (Dan Shiovitz) wrote:
>I think the TADS/Inform situation is much more comparable to lego not
>having any specialized castle-building pieces, but that doesn't mean
>you can't use them to build quite an elaborate structure.

Pity Lego seems to be ONLY specialized pieces anymore.

Have fun
Alan

TenthStone

unread,
Feb 5, 2000, 3:00:00 AM2/5/00
to
On Sat, 05 Feb 2000 05:33:15 GMT, amo...@earth1.net (R. Alan Monroe)
wrote:

By the way, Lego had specialized castle-building pieces way back,
little segments of wall five tall and five wide with a window in the
middle and a little surface on top especially meant for rafters.
Also, corner pieces. These have been around at least ten, fifteen
years.

----------------
The Imperturbable TenthStone
tenth...@hotmail.com mcc...@gsgis.k12.va.us

Mike Arnautov

unread,
Feb 6, 2000, 3:00:00 AM2/6/00
to
Dan Shiovitz <d...@cs.wisc.edu> wrote:

>>Which in no way achieves what my example was showing. There the text
>

>This seems a little harsh. I was showing the four-line proof of
>concept. The whole example you presented is absolutely doable in TADS
>and Inform and Hugo (and presumably ALAN also), including vocabulary
>changing, short description changing, mentioning the term twice in the
>same block of text and so on.

How does it go? I am forthright, you are harsh, he/she/it is
gratuitously abusive. :-) Perhaps I should chide you that you are
ignoring the potential of C++ as a language for IF-authoring, because
everything TADS can do, can be done in C++. :-)

But let's not have this exchange degenerate into "my language is better
than yours". TADS and others do things A-code was never designed to do,
but could be made to do. And v.v. That's hardly a great revelation. The
point I am trying to make is not about languages, though it can be
*illustrated* by languages.

>You showed
>an example of doing something when it's set to the original
>description -- can you have extra text printed when it's set to any
>given description? Can you specify a specific order to cycle through
>in? Can you change that order mid-game, or switch over to using an
>entirely new list?

Yes to all of that, actually. A-code does automatic de-referencing and
will accept pointers to texts where text names are expected. And the
order can be fully controlled, if one wishes it controlled. But again...
It is not my intention to discuss technical details, even though I get
seduced into doing just that. :-) It *is* my intention to discuss what I
see as divergent, or at least separate, strands of IF.

>Coding up your example in TADS or whatever takes a
>little while, but once you've done it there are a million variations
>that take only seconds to do. And of course I can put this code in a
>class and put it on gmd so only one person has to write it.

I have no doubt you are right. None of which gets away from the fact
that nearly twenty years after Dave Platt invented text switches, they
have not been taken up by other languages. More than that, when I
describe the idea of text morphing, your response (which is fairly
typical) is on the lines "oh we could do it, but what's the point?"
Which frankly is my response to the complex considerations of world-
modelling techniques, which seem to be seen as more important.

And isn't that where we have started? In the absence of a complex AI
which might be able to merge the two approaches, I see two distinct
directions for IF (or co-ordinate axis, if you wish, because the actual
live data points don't have to lie on either of them :-). One I would be
inclined to term Interactive Fiction as Literature (IFL for short?), and
the other Interactive Fiction as Modelling (IFM?). Rather to my
surprise, IFM has come to dominate the scene, by the looks of it, and I
wish to point out the existence of an alternative.

>>I'd say that in fact your example shows to what extend TADS does *not*
>>support text morphing.
>

>I agree it doesn't support it any more than it supports, say,
>elevators. But does that mean MJR should add a special elevator()
>function into the code? Of course not! Because I can build elevators
>with what's already available.

There is a not-so-slight difference between text morphing and elevators.
The former is a general purpose tool, the latter is a specific feature.
One might as well say that C++ doesn't support any given feature of
Inform or TADS, any more than it supports elevators -- which doesn't
matter because special code could be added to code for either.

I can't work out whether you *really* can't see the distinction between
text morphing and elevators, or whether you are just intent on playing
the devil's advocate. Most likely a bit of both. From your responses so
far, I see you as being firmly of the IFM school. That's fine -- I am
not saying it is wrong. I am just pointing out that there is an
alternative.

>If you look at the development of Inform and TADS it's been obvious
>that hard-coding unnecessarily is a mistake. TADS had the parser coded
>into the interpreter, unlike Inform, and the result is dozens of hooks
>have had to be added, creating a snarly mess. Much simpler, if you
>want that kind of control -- and you always, always will -- to expose
>all the code to the end programmer.

I mostly agree. That's why the A-code kernel is minimal and most of the
stuff is actually written in A-code itself, so that the programmer can
tailor things as desired (it is a simple enough language, not requiring
the author to be a C++ programmer :-). And there is a general purpose
hook for adding arbitrary C code as well. But text morphing is such a
generic and fundamental feature that I make no apologies for it being
implemented in the kernel. It is very simple and can be further
generalised (on the lines I already noted) equally simply, with no extra
hooks or any mess.

>>Exactly. All very specific particular things that one would have to do -
>>above all, to write code. A-code text morphing does not require you to
>>*do* anything, other than declare things and then reference the
>>sculpture in no way differently from any other objects. All the doing is
>>done automatically. There is no special code involved.
>

>Which is fine, until you want to make a slight change.

Pardon? You can make any change you like. The text switch declarations
are entirely under the author's control, as are the values which dictate
which part of the switch gets actually displayed. So much so that
generalisations I have in mind are aimed at allowing the author to
delegate the control, e.g. by declaring a text to be auto-incrementing.
He could still override or reset the relevant values, or point at
another text switch on the fly or whatever. Forget your idea that text
morphing is some sort of a hard-wired feature. You are just not familiar
with the concepts of text morphing.

>>You forget... We were talking about entrusting the engine with the
>>running of the world. Do you entrust textual display of people's
>>thoughts and feeling to an engine too? I hope you are going to invite me
>>to that Nobel presentation! :-)
>

>The idea being if I let the engine simulate the easy stuff, I can
>focus on the hard stuff.

Appropriate for IF as modelling, not appropriate for IF as literature.
It's like a writer saying: I'll do the interesting, hard stuff in my
next masterpiece and let a ghost writer do the easy, boring stuff. (Come
to think of it, the more recent A.C.Clarke books seem to be a good
example! :-) Of course, if IFM is all you want to do, you'll see it
differently.

>>>much effort I could put into the NPCs that live in the room! Surely
>>>the player would feel the authorial presence in a game like that, even
>>>if all the chairs in the room were identical copies of the Ideal Chair.
>>
>>Sorry... Count me out. It is a matter of taste, sure, but count me out.
>>I wouldn't think much about a novel in which the world is described in
>>stock phrases, just so that the author can concentrate on his characters
>>(or v.v. for that matter). Why should I like it any more in IF?
>

>But at the same time, when an author mentions that the protagonist
>walks down the streets past a dozen cars, do you really expect her to
>describe each car individually? Isn't it rather the case that you
>assume each car to be a "typical car" and not worth looking at, unless
>it becomes relevant to the story?

You are still thinking in terms of modelling, and in those terms you are
right. But in terms of IF as literature, you are dead wrong. In IFL I
wouldn't assume anything of the sort. I would tell the player not to
bother with the cars, giving some reason specific to the game or the
situation (using text switches to tailor the message to the situation,
if there distinct such situations; and varying the response too if it is
to be used again). In IFL, it is up to the author to regulate the amount
of detailed interaction available to the player. In IFM it is easier to
have the amount of detail uniform, and let the engine handle the ones
it.

>>My wife has just pointed out to me a review of Toy Story 2 in the
>>Independent today, which is quite remarkably relevant (it may well be
>>viewable on their web site -- I am writing this off-line, so don't
>>know). The reviewer singles out as *the* feature which elevates the film
>>to the status of an artistic creation the fact that "wherever you look
>>on screen, you find that an attentive eye has gone before you". Which is
>>*exactly* what I mean by an IF work being a communication between the
>>author and the player, rather than a world model being run by an engine.
>>Interestingly enough, the review goes on to say "It is, in some
>>respects, as purely literary an effect as the cinema can offer."
>

>Yeah. And how many people worked on Toy Story, exactly? The thing
>about infinite detail is it's not scalable. I'd like to have all my
>games be hand-crafted down to the atomic level, but I'd also like to
>release games with more than one room in them.

You've missed the point the review was making and the reason I quoted it
-- the very reference to hand-crafting games down to the atomic level
shows it quite conclusively. Why do you think did the review call it "as
purely literary an effect as cinema can offer"? Surely not because of
the mind-boggling amount of detail a single screen-shot of TS2 can pack,
which as you rightly say, literature of any sort cannot possibly match.
No, the author was referring to the fact that everything he saw was
*intended*, the way everything a writer writes is of necessity intended
(let's ignore politicians and celebrities having their books hosted --
that ain't literature! :-). This intendedness is quite independent of
the level of detail on offer.

>Basically -- and I realize you probably disagree -- the details aren't
>where I'd like to spend my time. I'd like to do a few perfect details
>and set up the game so that's what the player focuses on.

No, I don't *disagree*. I am simply saying that this is one possible
approach, while IF as Literature is another. Neither is "wrong" or
"right". They are different.

>Again, this is probably a matter of taste, but text changing in the
>way you describe just isn't that big a deal to me.

That's a shame. you are depriving yourself of a very powerful tool. Then
again, I suppose in your chosen mode of IF there probably isn't much
call for it. But then, quite seriously, why not go for a Doom-like
engine combined with IF-style interactions? The original Ultima
Underworld seemed to be heading that way, but rather lost its direction
afterwards.

>Are there other
>features you'd like to see in a language that don't exist?

As I already indicated, anything which supports IF as Literature, as
opposed to IF as Modelling. (Though I have no problems with a language
which would offer the support for both. :-) Now which features would
support IFL, other than text morphing? Hmmm... Good question. I am not
an innovator. My strength is in picking up innovations tossed off by
others and making the most of them. Dave Platt invented text switches. I
built on that. So I find it hard to answer your question. A few generic
thoughts, though...

I think an IFL author would be helped by tools assisting him in
navigating through and restricting the (potentially humongous) space of
all possible combinations that can arise. IFM's answer is to build the
model and let the engine to get on with it. This has its own problems
(c.f. the difficulties you listed in response to another poster, all of
which were rooted in that generic solution). An IFL author, however,
needs to carve out of this space of all possibilities a subspace of all
those things he has allowed for, and ensure that the boundaries are also
guarded too. E.g. that instead of allowing the player to examine cars
parked along the street, all the relevant subspace of possibilities is
shut-off with a quip or a series of quips.

The issue of IFL conversations is also a thorny one. They could be done
on the lines of the early Ultima series games, basing on keywords, or
they could be done by multiple-choice methods (like the magnificent chat
with the three pirates in Monkey Island 2 -- the best example I've even
seen!). Either way, tools to map out the conversational network, assign
responses to nodes and create code out of that, would be useful.

And how about a library of verbal "textures"? These would be useful in
either style of IF authoring. E.g. in you example of a dining room with
a table and four chairs, instead of having a platonic chair, you could
choose out of a hierarchical library of objects a very specific chair,
assigning it uniformly to all four, or individually, as you wish. And
perhaps tweak the properties slightly, if necessary. That's where OO
comes into its own!

But frankly, I don't know. Once again, I am simply struck by the fact
that IF languages seem to be providing lots of support for IFM, and
hardly any for IFL -- which probably leads to a kind of Darwinian
runaway evolution. That which is supported, gets used and that which
gets used gets supported. Ultimately though, I see no point in trying to
model the world in words without a powerful AI. Visual modelling is much
more appropriate, if modelling is what one is after. Just accept that it
jars on some of us, in ways I already explained in previous posts.

OTOH I am fascinated by the possibilities offered by IFL, and perplexed
that it is (apparently) not being explored. Of course, this may be just
down to my ignorance. If so, please point me at the people and/or games
in tune with my preconceptions on the subject.

Neil K.

unread,
Feb 6, 2000, 3:00:00 AM2/6/00
to
Mike Arnautov <m...@mipmip.demon-co-antispam-uk> wrote:

> I have no doubt you are right. None of which gets away from the fact
> that nearly twenty years after Dave Platt invented text switches, they
> have not been taken up by other languages. More than that, when I
> describe the idea of text morphing, your response (which is fairly
> typical) is on the lines "oh we could do it, but what's the point?"

Okay, I'm afraid I don't understand your point either. Why is the ability
to change object names and the like such a big deal? Why does it have to
be supported at some language level? (through intrinsic functions,
presumably)

I mean, in my game code I've got a couple two-line functions that alter
object names and so on when necessary. Sometimes it's a useful feature;
sometimes it's not. When it is I just call a function. I guess such a
feature could be built into the language, but I don't really see any need,
which I think is Dan's point. Am I missing something of great import here?

- Neil K.

--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca

meni...@pixi.com

unread,
Feb 7, 2000, 3:00:00 AM2/7/00
to
Mike Arnautov <m...@mipmip.demon-co-antispam-uk> wrote:

[LOTS of verbage snipped]

Here's how you can prove to everyone that your methods are superior:

1. Write all the required tools (compiler, interpreter, etc.) Make sure
the source code is written in a widely available language (such as C)
and make the source code freely available. :-)

2. Write a game using those tools that will make everyone sit up and
take notice. :-)

Until then, I'll just have to go on using the "inferior" tools I have
at my disposal. :-)

Gunther Schmidl

unread,
Feb 7, 2000, 3:00:00 AM2/7/00
to
"Mike Arnautov" <m...@mipmip.demon-co-antispam-uk> wrote:

> I mostly agree. That's why the A-code kernel is minimal and most of the
> stuff is actually written in A-code itself, so that the programmer can
> tailor things as desired (it is a simple enough language, not requiring
> the author to be a C++ programmer :-).

Sorry, but A-Code must be the most non-intuitive language I've seen since the
original Phoenix Adventure Language that the Phoenix games were written in.
Looks more like assembler than anything else. Definitely not something I'd want
to program a game in.

I've not written a single line of C++ code and could figure out Inform, TADS
and Hugo pretty well.

--
+-----------------+---------------+------------------------------+
| Gunther Schmidl | ICQ: 22447430 | IF: http://gschmidl.cjb.net/ |
|-----------------+----------+----+------------------------------|
| gschmidl (at) gmx (dot) at | please remove the "xxx." to reply |
+----------------------------+-----------------------------------+


Sean T Barrett

unread,
Feb 7, 2000, 3:00:00 AM2/7/00
to
Neil K. <fake...@anti-spam.address> wrote:

>Mike Arnautov <m...@mipmip.demon-co-antispam-uk> wrote:
>> I have no doubt you are right. None of which gets away from the fact
>> that nearly twenty years after Dave Platt invented text switches, they
>> have not been taken up by other languages. More than that, when I
>> describe the idea of text morphing, your response (which is fairly
>> typical) is on the lines "oh we could do it, but what's the point?"
>
> Okay, I'm afraid I don't understand your point either. Why is the ability
>to change object names and the like such a big deal? Why does it have to
>be supported at some language level? (through intrinsic functions,
>presumably)
>
> I mean, in my game code I've got a couple two-line functions that alter
>object names and so on when necessary. Sometimes it's a useful feature;
>sometimes it's not. When it is I just call a function. I guess such a
>feature could be built into the language, but I don't really see any need,
>which I think is Dan's point. Am I missing something of great import here?

One big deal is really that people write big blocks of text
in which they tend to hardcode details rather than connecting
them up to print the appropriate computed strings from the
simulation.

There are times when the level of convenience required for
a task can be pushed past a certain point where it increases
people's willingness to do that sort of thing.

Inform, for example, has an incredibly concise method for
printing a message and returning because it's so common.
So I have a fair amount of sympathy to the idea of a language
which would allow a much shorter syntax than the norm for
substituting strings automatically. Actually, in truth,
typing the string
", (name) foo, "
isn't too bad, but then, names of objects don't change that
often anyway, and that syntax doesn't generalize.

Speaking as the author and only user of an Inform compiler extension
that allows serially varying strings without code effort--an effect
that would take a substantial amount of code to do write hand--there
is no doubt I am making far more use of the effect than I
would have if I had had to do it the hard way. But unless
somebody who's a faster or more prolific author than I wants
to try their hands at it, it'll be a while before anyone
sees it in action and finds out whether it's worth it, and
even then it'll be filtered through a lot of other unrelated
issues in the work.

SeanB

okbl...@my-deja.com

unread,
Feb 8, 2000, 3:00:00 AM2/8/00
to
In article <b408JCAN...@mipmip.demon.co.uk>,
Mike Arnautov <m...@mipmip.demon-co-antispam-uk> wrote:
[a while back]

"To my mind, there are two very distinct strands to IF. One strand
almost attempts to go the way of Doom-like games in allowing the author
to set up the world and then let the engine handle reasonably
realistically anything the player might wish to do, while embroidering a
plot on top of that. [snip]

The other strand is less concerned with world creation and gives the
author a maximal degree of control, but also the responsibility for

anticipating what the player may or may not do. It is more about giving


the player a feeling of indirectly interacting with the author -- more
in the way of traditional oral story-telling."

[then later added]


"And isn't that where we have started? In the absence of a complex AI
which might be able to merge the two approaches, I see two distinct
directions for IF (or co-ordinate axis, if you wish, because the
actual live data points don't have to lie on either of them :-). One I
would be inclined to term Interactive Fiction as Literature (IFL for
short?), and the other Interactive Fiction as Modelling (IFM?). Rather
to my surprise, IFM has come to dominate the scene, by the looks of it,
and I wish to point out the existence of an alternative."

For the sake of this post, I shall refer to what you call "IFL" as just
"IF" and what you call IFM as "simulation".

I can't say I see what you're seeing at all. There's a lot of talk
about simulation on the board here, but very little that would go so far
as to justify your definition of IFM. In particular, that part of the
definition that has to do with limiting authorial freedom.

Most IF frameworks that people use today offer very little in terms of
world simulation. Cardinal direction handling, a few concepts like
"surface", "hidden", and, uh, doors. Oh, and inventory management. Some
of the nifty add-ons do things like sense-passing.

Your two strands don't actually exist, although you're not the first to
suggest that they do. If I strive for what you call the "literary"
strand, my system is less "concerned with world creation"--which means
that *I* have to be concerned with it, as I try to anticipate every
little thing the reader might do, in order to give that feeling of
interaction.

Ironically, I spend more time making doors open and shut than I do
writing anything that might actually communicate to the reader.

We have doors that open and shut and inventory commands that work
(though I believe we had examples of doors and inventory failing in the
comp). Why can't we have other things that just work without being any
less literary? Is it really important to the work that I, personally,
code the opening and closing of doors? Or can I just put in the text
that I want for the door opening and closing? Isn't *that* the literary
aspect?

I think that as long as the character and story development isn't
simulated, you still have IF. When you start having elements randomly
combine to produce new (essentially arbitrary) stories, then you have
DOOM. Er, "The Sims", I guess.
--
[ok]

Iain Merrick

unread,
Feb 8, 2000, 3:00:00 AM2/8/00
to
Mike Arnautov wrote:
[...]

> Which in no way achieves what my example was showing. There the text
> morphing was in one swoop extended to the vocabulary, so that the
> sculpture in its ibex shape could not be referred to as a pig, for
> example. Similarly, in that example *any* textual reference to the
> sculpture would be automatically morphed without being in any way
> instrumented to do so -- and that applies to indirect references too.
> E.g. a DROP ALL command will reference it correctly in reporting
> player's actions.
>
> And how do you tackle
>
> It looks like a statue of {ANIMALS} to me. Now, don't ask me
> why anybody would sculpt {ANIMALS} from crystal, but there you are!
>
> without being inconsistent due to randomising? You'd have to assign the
> relevant array element to a string first, and then use it twice in the
> description. Text morphing does it all for me, without me. I can even
> say
>
> It looks like a statue of {ANIMALS} to me.[ Now, don't ask me
> why anybody would sculpt a pig from crystal, but there you are!/]
>
> With the effect that the "don't ask me" aside only occurs if the
> sculpture is examined in the state in which it is originally found.
> (Text switches do the sensible thing with "out of bounds" values!)

You've deliberately misunderstood Dan Shiovitz; he wasn't trying to
provide a perfect solution, just show roughly how you'd go about doing
it.

For what it's worth, your example could be written in TADS like this:

animals: fixeditem
varNoun = ['pig' 'tiger' 'mule' 'ibex']
noun = 'statue'
sdesc = "statue of a <<currentNoun>>"
ldesc =
{
// Let's change the statue when the
// player looks at it.

changeNoun ;

// Now print out the description.

"It's a beautiful crystal sculpture of
a <<currentNoun>>. Hang on -- you're not
certain it was a <<currentNoun>> a moment
ago. Strange." ;
}
;

"What's varNoun?" I hear you cry. "And where did currentNoun and
changeNoun() come from?" Well, they're magic -- but _good_ magic.

All you need to know is that I could write a few functions to support
them in ten minutes or so. (Via the preinit hook, if you must know.)
Correct me if I'm wrong, but this completely solves your sample problem.
The other possibilities you mention can also be done.

> I'd say that in fact your example shows to what extend TADS does *not*
> support text morphing.

As Dan pointed out, it's completely unreasonable to draw that
conclusion. Unreasonable and just plain wrong.

[...]


> My wife has just pointed out to me a review of Toy Story 2 in the
> Independent today, which is quite remarkably relevant (it may well be
> viewable on their web site -- I am writing this off-line, so don't
> know). The reviewer singles out as *the* feature which elevates the film
> to the status of an artistic creation the fact that "wherever you look
> on screen, you find that an attentive eye has gone before you". Which is
> *exactly* what I mean by an IF work being a communication between the
> author and the player, rather than a world model being run by an engine.
> Interestingly enough, the review goes on to say "It is, in some
> respects, as purely literary an effect as the cinema can offer."
>
> Hear, hear! *That* is what for me text fiction is all about. *That* is a
> direction in which I would like to see (some) IF works to strive for.
> And it is something for which the existing IF-support languages appear
> to offer no actual support.

I actually agree with this, and this is the effect I'm going for in one
of my WIPs [1]. But I don't think special language support for 'text
morphing' is particularly helpful in writing 'non-simulationist' IF. I'm
using TADS, and it works fine for me; I'm not using adv.t, but the
language itself and the parser are still very useful.

The _only_ thing an IF language needs, I think, is special support for
SAVE/RESTORE and preferably UNDO. Other than that, you just want a good
general-purpose language, ideally one in which it's easy to manipulate
text. A parser and standard library are helpful, of course, but these
features should _not_ be hard-coded. They should be highly extensible
(as in the TADS parser) or better still written in VM code (as in
Inform).

You can do 'text morphing' in TADS code already, so we don't need
special support for it.


[1] I'm not anywhere near finished it, of course, since this approach is
bloody hard work. [2]

[2] But not because of the language! It's just hard work, full stop.

--
Iain Merrick
i...@cs.york.ac.uk

Iain Merrick

unread,
Feb 8, 2000, 3:00:00 AM2/8/00
to
Iain Merrick wrote:
[...]

> For what it's worth, your example could be written in TADS like this:
>
> animals: fixeditem
> varNoun = ['pig' 'tiger' 'mule' 'ibex']
> noun = 'statue'
> sdesc = "statue of a <<currentNoun>>"

Errr, obviously you might end up with a 'statue of a ibex' here. I guess
you'd want to use, say, "statue of <<aCurrentNoun>>" instead, and have
aCurrentNoun check for an initial vowel.

Now, if this bug were hard-coded, you wouldn't be able to fix it at all!
So my stupidity just proves my point again. :)

--
Iain Merrick
i...@cs.york.ac.uk

Mike Arnautov

unread,
Feb 8, 2000, 3:00:00 AM2/8/00
to
Sean T Barrett <buz...@world.std.com> wrote:

>So I have a fair amount of sympathy to the idea of a language
>which would allow a much shorter syntax than the norm for
>substituting strings automatically.

Thank you. I though I was going to wind up in the minority of one. Mot
that it would shut me up, of course. :-)

> Actually, in truth,
>typing the string
> ", (name) foo, "
>isn't too bad, but then, names of objects don't change that
>often anyway, and that syntax doesn't generalize.

Names are a bit of red herring in that it is not a frequent requirement
(though Adventure had the oyster/clam switch and had to have two
separate objects to do so :-). I was just trying to demonstrate the
various uses of text morphing. More to the point is the morphing of
messages and descriptions.

Taking another classic example, take the slit location in adv440. It
originally has a five-inch slit (as per adv350), which subsequently
becomes a five-foot gap.

Which is simpler:

a) having two otherwise identical locations and deciding dynamically
which one the player is entering?

b) when printing the description, deciding whether to insert "inch" or
"foot", depending on the state of the game?

c) declaring the description to say "a five-[inch slit/foot gap] in the
rock and incrementing the state of the location when the end-game is
entered (thereby causing a change in the description)?

I think it is (c), because typically, other things will depend on the
state of the location anyway (e.g. whether or not you can enter the
gap), so the state of the location has to be maintained. But now it is
used directly to alter the description, instead of the programmer having
to write code to have it happen.

This becomes very significant if you have a long text in which several
separate small bits need to be dynamic. Option (c) handles all of those
in one fell swoop. Option (b) requires the programmer to ensure the
appropriate separate changes and their mutual consistency. Option (a)
requires an almost exact repetition of a large block of text (and
changing/correcting that text becomes a problem).

>Speaking as the author and only user of an Inform compiler extension
>that allows serially varying strings without code effort--an effect
>that would take a substantial amount of code to do write hand--there
>is no doubt I am making far more use of the effect than I
>would have if I had had to do it the hard way.

My experience exactly. The more I used morphing, the more I appreciated
it. By now, I can't think how anybody manages without!

Morphers of the text, unite! :-)

Mike Arnautov

unread,
Feb 8, 2000, 3:00:00 AM2/8/00
to
Aha... We are finally getting a proper discussion. :-) Sorry folks... I
can't answer *everybody* at once. But I'll do my best to answer
everybody eventually.

Neil K. <fake...@anti-spam.address> wrote:
> Mike Arnautov <m...@mipmip.demon-co-antispam-uk> wrote:
>

>> I have no doubt you are right. None of which gets away from the fact
>> that nearly twenty years after Dave Platt invented text switches, they
>> have not been taken up by other languages. More than that, when I
>> describe the idea of text morphing, your response (which is fairly
>> typical) is on the lines "oh we could do it, but what's the point?"
>

> Okay, I'm afraid I don't understand your point either. Why is the ability
>to change object names and the like such a big deal? Why does it have to
>be supported at some language level? (through intrinsic functions,
>presumably)

No. Not through an intrinsic function. Not one you would call, anyway --
though internally, there is of course a function which deals with the
morphing, but that's hidden from you.

And not (just) change object names. The example of text morphing I gave
included name change alongside change in all descriptions of the object.
This is just an example. The technique "merely" consists of a convention
for defining generically texts which have the capability of changing
either in whole or in part, or in a number of parts, either by an
explicit choice of the author, or implicitly through the changing state
of the object or place the text is associated with, if it is associated
with one. (A pause to catch my breath. :-) This morphing of the text
occurs *not* through any intrinsic function, but automatically in any
reference to the text, because the kernel routes all such references
through a single piece of code, which does the morphing, if the text is
polymorphic.

> I mean, in my game code I've got a couple two-line functions that alter
>object names and so on when necessary. Sometimes it's a useful feature;
>sometimes it's not. When it is I just call a function. I guess such a
>feature could be built into the language, but I don't really see any need,
>which I think is Dan's point. Am I missing something of great import here?

I think you do miss something of *some* import. Whether it is of *great*
import, probably depends on your personal preferences. For me, it is
exceedingly useful that having declared a polymorhically described (and
more rarely, named) object or place, I no longer need to worry about it.
Any code I write which triggers the relevant description will
automatically morph itself. I.e. the code I write differs in NO WAY AT
ALL on whether or not the entity in question has a polymorphic
description. All of that is taken care of in the declaration.

This is just as useful as for example having the kernel to support
objects which either exist in more than one place, or which are linked
in such a way that their state is always identical -- e.g. doors. And
for exactly the same reason. Having declared a door, you don't need to
worry about opening/closing/locking/unlocking it so that its state
remains consistent when viewed from different location.

Mike Arnautov

unread,
Feb 8, 2000, 3:00:00 AM2/8/00
to
meni...@pixi.com wrote:

>Here's how you can prove to everyone that your methods are superior:

I never claimed "my methods" to be superior. I am simply pointing out
that amongst "my methods" is one feature which I find very powerful and
which is, to my surprise, missing from mainstream IF languages.

>1. Write all the required tools (compiler, interpreter, etc.) Make sure
>the source code is written in a widely available language (such as C)
>and make the source code freely available. :-)

I did, actually. Except that my choice was to chuck the
compiler/interpreter approach. Instead I have a translator, written in
ANSI C, which translates A-code source (created by Dave Platt and
developed by yours truly) into ANSI C source and a data file. The
resulting source can be compiled by any ANSI C compiler. All relevant
code is freely available on my site.

Good enough? :-)

>2. Write a game using those tools that will make everyone sit up and
>take notice. :-)

I did, actually. I used those tools to merge adv440 with adv550 (plus
further wrinkles of my own), thereby creating adv660. Which has been
publicly available for years and is still clocking over 1000 downloads
per year from the IF archive (in addition to being offered by a number
of other sites). (And which is now available as a Java servlet, thanks
to Jon Skeet's efforts in porting my translator to Java and making it
emit Java code instead of C code -- I really must get around to posting
the relevant URL!)

Will that do? :-)

>Until then, I'll just have to go on using the "inferior" tools I have
>at my disposal. :-)

If they satisfy your needs, why not?

Mike Arnautov

unread,
Feb 8, 2000, 3:00:00 AM2/8/00
to
Gunther Schmidl <gsch...@xxx.gmx.at> wrote:

>> I mostly agree. That's why the A-code kernel is minimal and most of the
>> stuff is actually written in A-code itself, so that the programmer can
>> tailor things as desired (it is a simple enough language, not requiring
>> the author to be a C++ programmer :-).
>

>Sorry, but A-Code must be the most non-intuitive language I've seen since the
>original Phoenix Adventure Language that the Phoenix games were written in.
>Looks more like assembler than anything else.

You mean it has no brackets, or braces? :-) Or are you referring to the
five primitives it has, which sound assembler-like? These are BIT, BIS,
BIC, LDA and EVAL. I did consider adding synonyms of, respectively,
IF_FLAG, SET_FLAG, CLEAR_FLAG, POINT_TO and EVALUATE -- but there seemed
little point. :-)

But you are making the mistake of judging how simple a language is, by
its appearance, which would seem to disagree with you. The simplicity is
actually in the use and particularly in the use of changing the default
behaviour of the system.

> Definitely not something I'd want
>to program a game in.

'SOK -- I'd be the last to try forcing you!

>I've not written a single line of C++ code and could figure out Inform, TADS
>and Hugo pretty well.

If you use them out-of-box, sure (though you still need to count your
brackets and braces! :-), but once you want to tailor things...

Michael Brazier

unread,
Feb 8, 2000, 3:00:00 AM2/8/00
to
Mike Arnautov wrote:
>
> Neil K. <fake...@anti-spam.address> wrote:
> > Mike Arnautov <m...@mipmip.demon-co-antispam-uk> wrote:
> >
> >> I have no doubt you are right. None of which gets away from the fact
> >> that nearly twenty years after Dave Platt invented text switches, they
> >> have not been taken up by other languages. More than that, when I
> >> describe the idea of text morphing, your response (which is fairly
> >> typical) is on the lines "oh we could do it, but what's the point?"
> >
> > Okay, I'm afraid I don't understand your point either. Why is the ability
> >to change object names and the like such a big deal? Why does it have to
> >be supported at some language level? (through intrinsic functions,
> >presumably)
>
> No. Not through an intrinsic function. Not one you would call, anyway --
> though internally, there is of course a function which deals with the
> morphing, but that's hidden from you.
>
> And not (just) change object names. The example of text morphing I gave
> included name change alongside change in all descriptions of the object.
> This is just an example. The technique "merely" consists of a convention
> for defining generically texts which have the capability of changing
> either in whole or in part, or in a number of parts, either by an
> explicit choice of the author, or implicitly through the changing state
> of the object or place the text is associated with, if it is associated
> with one.

But isn't this merely a notational convenience? Both Inform and TADS
allow the programmer to put arbitrarily complex expressions into game
text. Writing text that changes according to the state of an object is
very easy; a special notation for certain common cases of variable text
seems like overkill.

> This is just as useful as for example having the kernel to support
> objects which either exist in more than one place, or which are linked
> in such a way that their state is always identical -- e.g. doors. And
> for exactly the same reason. Having declared a door, you don't need to
> worry about opening/closing/locking/unlocking it so that its state
> remains consistent when viewed from different location.

Straightforward object-oriented programming; it's nothing novel.

--
Michael Brazier But what are all these vanities to me
Whose thoughts are full of indices and surds?
X^2 + 7X + 53 = 11/3
-- Lewis Carroll

Iain Merrick

unread,
Feb 9, 2000, 3:00:00 AM2/9/00
to
Mike Arnautov wrote:

> Gunther Schmidl <gsch...@xxx.gmx.at> wrote:
[...]


> >Sorry, but A-Code must be the most non-intuitive language I've seen since the
> >original Phoenix Adventure Language that the Phoenix games were written in.
> >Looks more like assembler than anything else.
>
> You mean it has no brackets, or braces? :-) Or are you referring to the
> five primitives it has, which sound assembler-like? These are BIT, BIS,
> BIC, LDA and EVAL. I did consider adding synonyms of, respectively,
> IF_FLAG, SET_FLAG, CLEAR_FLAG, POINT_TO and EVALUATE -- but there seemed
> little point. :-)

Not knowing much about the language, the only problem I have with the
syntax is all those CAPITAL LETTERS. It looks a bit 70's, if you see
what I mean. Are they required, or can you use lower-case keywords too?

--
Iain Merrick
i...@cs.york.ac.uk

Sean T Barrett

unread,
Feb 9, 2000, 3:00:00 AM2/9/00
to
Michael Brazier <mbra...@argusinc.spamaway.com> wrote:
>But isn't this merely a notational convenience? Both Inform and TADS
>allow the programmer to put arbitrarily complex expressions into game
>text.

This is incorrect. Inform does not allow you to put complex expressions
into strings, only in code. Since there are certain limitations to the
use of code, this could probably make some things painful, although I
haven't yet run into anything bad (I just make sure all of my own code
uses PrintOrRun too).

SeanB

Sean T Barrett

unread,
Feb 9, 2000, 3:00:00 AM2/9/00
to
Mike Arnautov <m...@mipmip.demon-co-antispam-uk> wrote:
>Sean T Barrett <buz...@world.std.com> wrote:
>> Actually, in truth,
>>typing the string
>> ", (name) foo, "
>>isn't too bad, but then, names of objects don't change that
>>often anyway, and that syntax doesn't generalize.
>
>Names are a bit of red herring in that it is not a frequent requirement
[snip]

>Which is simpler:
>
>a) having two otherwise identical locations and deciding dynamically
>which one the player is entering?
>
>b) when printing the description, deciding whether to insert "inch" or
>"foot", depending on the state of the game?
>
>c) declaring the description to say "a five-[inch slit/foot gap] in the
>rock and incrementing the state of the location when the end-game is
>entered (thereby causing a change in the description)?
>
>I think it is (c), because typically, other things will depend on the
>state of the location anyway (e.g. whether or not you can enter the
>gap), so the state of the location has to be maintained. But now it is
>used directly to alter the description, instead of the programmer having
>to write code to have it happen.

Sure, but this is where I think it's a straw man. First of all,
the programmer IS writing code to have it happen: [inch slit/foot gap]
is code using a very concise language, reminiscent of C's "a ? b : c"
syntax, in fact. Morever, "Incrementing the state of the location"?
What happens when I want multiple independent states for the location?
As I wrote in the documentation for my Inform extension, I didn't extend
it to generalized switchable text, because the moment you want it to
depend on some piece state visible to the rest of the game, that state has
to have a name, at which point you're better off writing Inform code.
(Ok, you CAN have unnamed pieces of state, such as your one per location,
but any programmer will tell you that in the long run you're always
better off giving it an explicit name for the sake of maintainability.)

In Inform, that description would be:
print "A five-"; if (gap_flag) print "foot gap"; else print "inch slit";

Yes, this is longer. A lot longer. It would be nice if it could be
abbreviated to
print "A five-", (gap_flag?"foot gap":"inch slit");

But how important is it to abbreviate beyond that? The difference
between (gap_flag?"foot gap":"inch slit") and a hypothetical
A-code-like "[gap_flag?foot gap:inch slit]" is pretty minimal.

SeanB
PS:
I find it unnerving that you bitch about the use of brackets and
braces in TADS and Inform but proudly talk about how much more
convenient it is to have one-character symbols [ / ] in strings.

As a professional programmer, C/C++ style symbology is an
incredible notational convenience--not to save typing, but
to allow you to easily visually see what's going on. IF
programming involves so much more text that there's definitely
the need for deviation in syntax, but I don't think making
the programming side of the languages more verbose does much
good.

John Elliott

unread,
Feb 9, 2000, 3:00:00 AM2/9/00
to
buz...@world.std.com (Sean T Barrett) wrote:
>In Inform, that description would be:
> print "A five-"; if (gap_flag) print "foot gap"; else print "inch slit";

You could do something like this (based on the Designer's Manual,
chapter 10, exercise 8 solution):

Lowstring slit_str "inch slit";
Lowstring gap_str "foot gap";

[ OpenSlit; String 0 gap_str; ];
[ CloseSlit; String 0 slit_str; ];

...
print "The water flows into a 5-@0."

------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)

Kevin Forchione

unread,
Feb 9, 2000, 3:00:00 AM2/9/00
to
"Sean T Barrett" <buz...@world.std.com> wrote in message
news:Fpo9t...@world.std.com...

> Yes, this is longer. A lot longer. It would be nice if it could be
> abbreviated to
> print "A five-", (gap_flag?"foot gap":"inch slit");

This style notation is similar to TADS:

"A five-<<gap_flag ? "foot gap" : "inch slit">>";

--Kevin

Joe Mason

unread,
Feb 9, 2000, 3:00:00 AM2/9/00
to
John Elliott <j...@seasip.demon.co.uk> wrote:
>buz...@world.std.com (Sean T Barrett) wrote:
>>In Inform, that description would be:
>> print "A five-"; if (gap_flag) print "foot gap"; else print "inch slit";
>
> You could do something like this (based on the Designer's Manual,
>chapter 10, exercise 8 solution):
>
>Lowstring slit_str "inch slit";
>Lowstring gap_str "foot gap";
>
>[ OpenSlit; String 0 gap_str; ];
>[ CloseSlit; String 0 slit_str; ];
>
>...
> print "The water flows into a 5-@0."

Yes, that's so much clearer. And more succinct, too!

Joe
"

Mike Arnautov

unread,
Feb 11, 2000, 3:00:00 AM2/11/00
to
Oh dear... I am falling further and further back with my replies. All
through circumstances outside my control. Do bear with me folks...

Iain Merrick <i...@cs.york.ac.uk> wrote:

>You've deliberately misunderstood Dan Shiovitz; he wasn't trying to
>provide a perfect solution, just show roughly how you'd go about doing
>it.

You got it the wrong way round. He (and you) keep misunderstanding me. I
repeat: I have no doubt that by adding specific code here and there,
TADS can be made to do the equivalent of any particular effect of text
morphing. Following that logic, you could say that there is no need to
have accessibility filters either, because it is perfectly possible to
add a bit of code in any specific case, which would do the job.

Isn't one generic solution, which hard-wires nothing specific,
preferable to an ad-hoc bits of hard-wired code?

>For what it's worth, your example could be written in TADS like this:

(See my other post replying to your P.S.)

>"What's varNoun?" I hear you cry. "And where did currentNoun and
>changeNoun() come from?" Well, they're magic -- but _good_ magic.

And so is text morphing, except that it is better magic because it is
MORE GENERIC.

>All you need to know is that I could write a few functions to support
>them in ten minutes or so. (Via the preinit hook, if you must know.)
>Correct me if I'm wrong, but this completely solves your sample problem.
>The other possibilities you mention can also be done.

Exactly. Thank you. ten minutes here, a bit of special code here, a bit
of special code there and, viola! we have done what could have been done
generically, without the author writing any code, or even knowing how to
write any code.

>> I'd say that in fact your example shows to what extend TADS does *not*
>> support text morphing.
>

>As Dan pointed out, it's completely unreasonable to draw that
>conclusion. Unreasonable and just plain wrong.

I beg to differ. You have just provided another demonstration of the
truth of my statement. Please stop confusing "feature X can be coded in
language Y" with "language Y supports feature X". Otherwise it is
logical to claim that assembler supports all features of TADS, so why
bother with TADS?

>I actually agree with this, and this is the effect I'm going for in one
>of my WIPs [1]. But I don't think special language support for 'text
>morphing' is particularly helpful in writing 'non-simulationist' IF. I'm
>using TADS, and it works fine for me; I'm not using adv.t, but the
>language itself and the parser are still very useful.

[Shrug] I have no intention of dictating to anybody what they should or
should not be using. If TADS works for you -- fine. But do contemplate
as a hypothetical possibility that if it were available to you, you
would find it rather more useful than you expect.

E.g. I already noted that in many circumstances it is inappropriate
(from the literary, rather than simulation PoV) to keep repeating the
same message in response to the same action triggering the same action.
Using a self-incrementing text with embedded text-switch (or switches),
you can construct the sequence of responses and then forget about it.
The desired effect will happen automatically. And if later you discover
that the effect in question can be triggered by some other means, you
can display the same response, without having to remember that there is
anything special about it.

Yes, I know -- you *could* construct a text array, and keep an offset
into it, and remember to increment the offset whenever and wherever the
text array gets referred to. But text morphing does all this house-
keeping transparently for you.

And yes, it can maintain two or more independent such pointers too. The
offsets are per text message, not per switch and with text embedding it
is trivial to have a multiplicity of them. NB -- still without the
author writing a line of code, only declarations of text.

>The _only_ thing an IF language needs, I think, is special support for
>SAVE/RESTORE and preferably UNDO. Other than that, you just want a good
>general-purpose language, ideally one in which it's easy to manipulate
>text.

Rather a radical view. :-) I take it you are a programmer. Do you assume
that every aspiring |IF author must be a programmer too?

> A parser and standard library are helpful, of course, but these
>features should _not_ be hard-coded. They should be highly extensible
>(as in the TADS parser) or better still written in VM code (as in
>Inform).

I disagree utterly about VM, but that's a separate argument. :-)

>You can do 'text morphing' in TADS code already, so we don't need
>special support for it.

No you can't. You can emulate every individual effect of it. Not the
same thing. Of course, if you prefer to bash out code, I can at least
appreciate the logic of your position.

>[1] I'm not anywhere near finished it, of course, since this approach is
>bloody hard work. [2]
>
>[2] But not because of the language! It's just hard work, full stop.

But the language can help, by taking care of the little chores.
Particularly since it *is* hard work. I agree there. And I am looking
forward to the result.

Mike Arnautov

unread,
Feb 11, 2000, 3:00:00 AM2/11/00
to
Iain Merrick <i...@cs.york.ac.uk> wrote:
>Iain Merrick wrote:
>[...]

>> For what it's worth, your example could be written in TADS like this:
>>
>> animals: fixeditem
>> varNoun = ['pig' 'tiger' 'mule' 'ibex']
>> noun = 'statue'
>> sdesc = "statue of a <<currentNoun>>"
>
>Errr, obviously you might end up with a 'statue of a ibex' here. I guess
>you'd want to use, say, "statue of <<aCurrentNoun>>" instead, and have
>aCurrentNoun check for an initial vowel.
>
>Now, if this bug were hard-coded, you wouldn't be able to fix it at all!
>So my stupidity just proves my point again. :)

Only because you insist on imagining that I suggesting hard-coding
anything. My example was: a[ pig/ tiger/ mule/n ibex] -- and the use of
this switch does not on any explicit procedures such as currentNoun or
aCurrentNoun. And as you point out, you have to write into aCurrentNoun
a specific check. OTOH, I don't have to write *any* code at all.

(NB you hard-coded the assumption that that the description must be that
of the "current noun" -- it needn't be; e.g. my switch would work just
as well if describing a mirror in which the statue is being reflected,
so you need to fiddle with "current noun" while describing the mirror.)

Once again, if you are a programmer and if you are willing to write
code, then yes, TADS can do ad hoc emulation of any specific example of
the us of text morphing. And you can do it in C and even in Fortran. The
whole point is that text morphing is a very general tool.

Stephen Granade

unread,
Feb 11, 2000, 3:00:00 AM2/11/00
to
Mike Arnautov <m...@mipmip.demon-co-antispam-uk> writes:

> Iain Merrick <i...@cs.york.ac.uk> wrote:
>
> >> I'd say that in fact your example shows to what extend TADS does *not*
> >> support text morphing.
> >
> >As Dan pointed out, it's completely unreasonable to draw that
> >conclusion. Unreasonable and just plain wrong.
>
> I beg to differ. You have just provided another demonstration of the
> truth of my statement. Please stop confusing "feature X can be coded in
> language Y" with "language Y supports feature X". Otherwise it is
> logical to claim that assembler supports all features of TADS, so why
> bother with TADS?

The distinction in this case is small enough to be negligible. You
could spend a short amount of time to write something which will let
you do text morphing generically in TADS in the way you describe. That
code can then be made available to everyone, making transparent text
morphing accessible to authors who don't want to code specific
situations. The same is true of [insert IF language here].

Now, were it very difficult to add such an ability generically to one
of these languages, then you would have a point. At that point the
difference between "can be coded in" and "is supported by" becomes
large, as with your assembler/TADS example.

If you want to argue that text morphing provides something that IF
authors should take advantage of, great. That has the potential to be
a good discussion. If you want to say that having text morphing
transparently available to an author is a good thing, okay. Again,
that's potentially a good discussion. If you want to say that no
language other than SooperSpiftyLanguage supports text morphing, don't
be surprised to hear people say that you are wrong.

Stephen

--
Stephen Granade | Interested in adventure games?
sgra...@phy.duke.edu | Visit About.com's IF Page
Duke University, Physics Dept | http://interactfiction.about.com

Mike Arnautov

unread,
Feb 11, 2000, 3:00:00 AM2/11/00
to
Iain Merrick <i...@cs.york.ac.uk> wrote:

>Not knowing much about the language, the only problem I have with the
>syntax is all those CAPITAL LETTERS. It looks a bit 70's, if you see
>what I mean. Are they required, or can you use lower-case keywords too?

Yes. Except in texts, A-code is case insensitive. The upper case is a
convention I picked up from Dave Platt's code.

Mike Arnautov

unread,
Feb 11, 2000, 3:00:00 AM2/11/00
to
Joe Mason <jcm...@uwaterloo.ca> wrote:
>John Elliott <j...@seasip.demon.co.uk> wrote:
>>buz...@world.std.com (Sean T Barrett) wrote:
>>>In Inform, that description would be:
>>> print "A five-"; if (gap_flag) print "foot gap"; else print "inch slit";

I am baffled... Don't they teach them *anything* about the distinction
between declarative and procedural styles and the advantages of the
latter? :-)

>> You could do something like this (based on the Designer's Manual,
>>chapter 10, exercise 8 solution):
>>
>>Lowstring slit_str "inch slit";
>>Lowstring gap_str "foot gap";
>>
>>[ OpenSlit; String 0 gap_str; ];
>>[ CloseSlit; String 0 slit_str; ];
>>
>>...
>> print "The water flows into a 5-@0."

>Yes, that's so much clearer. And more succinct, too!

Isn't it just? And if the '...' in between signifies enough lines, also
ever so easy to read. :-)

Seriously, all replies I've had so far simply demonstrate that one
almost always can write code to do something which is best done
declaratively.

The problem would seem to lie in the unquestioning assumption that an IF
writer must be a competent programmer. You are all happy to add a
special-purpose procedure here or there to do this or that, but I can
tell you exactly what a non-programmer says to all these examples how
easily things can be achieved without any special language support etc.
I quote verbatim: "Eh?"

Now, come on... Don't shoot the messenger! :-) The declarative style
*is* easier for non-programmers. And if a generic declarative notation
can achieve things which require bits of ad-hoc procedural coding to
achieve the same without it, it is a Good Thing.

Mike Arnautov

unread,
Feb 11, 2000, 3:00:00 AM2/11/00
to
Sean T Barrett <buz...@world.std.com> wrote:

>Sure, but this is where I think it's a straw man. First of all,
>the programmer IS writing code to have it happen: [inch slit/foot gap]
>is code using a very concise language, reminiscent of C's "a ? b : c"
>syntax, in fact.

Firstly, terminological trouble: by "code" I mean non-declaration.
Something that gets executed, rather than declared. Secondly, yes, I am
happy to accept "A ? b : c" as an equivalent of a two-element text
switch. But it doesn't generalise. What's the analogue of
[a/b/c/d/e/f/g]? A case statement? Quite...

> Morever, "Incrementing the state of the location"?
>What happens when I want multiple independent states for the location?

A-code maintains one for you automatically and uses it by default. But
you can maintain any number of other in parallel, if that's what tickles
your fancy. The one maintained by A-code will be used by default in

SAY somePlace

but you can override it explicitly by any value you care, constant or
variable

SAY somePlace someValue

>As I wrote in the documentation for my Inform extension, I didn't extend
>it to generalized switchable text, because the moment you want it to
>depend on some piece state visible to the rest of the game, that state has
>to have a name, at which point you're better off writing Inform code.

In A-code it is entirely up to you which you use, as shown above.

>(Ok, you CAN have unnamed pieces of state, such as your one per location,
>but any programmer will tell you that in the long run you're always
>better off giving it an explicit name for the sake of maintainability.)

It is not nameless. It has a name, to wit the name of the location. This
is convenient because the meaning is unambiguously (and intuitively)
given by the use of the name of the location. But, of course, if you
don't like these implied values -- just ignore them. They get
initialised to zeros and will stay like that harmlessly enough if you
are determined to maintain your own.

>In Inform, that description would be:
> print "A five-"; if (gap_flag) print "foot gap"; else print "inch slit";

Quite apart from the declarative/procedural angle, this again *hard-
wires* stuff in a particular place and circumstances. A text switch gets
declared once and can then be used anywhere in the procedural code. Your
answer is, presumably, to write a sub-procedure instead. I.e.
programming, where for me a declaration will do.

I don't understand why you are so keen to avoid a generic switch
notation in declarations, preferring to write code instead. Do you
dislike structures either?

>I find it unnerving that you bitch about the use of brackets and
>braces in TADS and Inform but proudly talk about how much more
>convenient it is to have one-character symbols [ / ] in strings.

I never bitch. :-) Occasionally I resort to a mild sarcasm. Occasionally
this gets missed.

>As a professional programmer, C/C++ style symbology is an
>incredible notational convenience--not to save typing, but
>to allow you to easily visually see what's going on.

Spoken like a programmer, indeed. It follows that to write IF one should
learn C/C++? Believe me, to a non-programmers its syntax and notation is
anything *but* convenient.

> IF
>programming involves so much more text that there's definitely
>the need for deviation in syntax, but I don't think making
>the programming side of the languages more verbose does much
>good.

Pardon? Verbose? Where? The text switch declarative notation
*simplifies* the programming side. Otherwise what would be the point of
it?

Mike Arnautov

unread,
Feb 11, 2000, 3:00:00 AM2/11/00
to
Michael Brazier <mbra...@argusinc.com> wrote:

>> This is just as useful as for example having the kernel to support
>> objects which either exist in more than one place, or which are linked
>> in such a way that their state is always identical -- e.g. doors. And
>> for exactly the same reason. Having declared a door, you don't need to
>> worry about opening/closing/locking/unlocking it so that its state
>> remains consistent when viewed from different location.
>
>Straightforward object-oriented programming; it's nothing novel.

Exactly. But why is it OK to apply it to "objects" in the game, but when
I suggest that a similar technique is applicable to texts, everybody
starts telling me how easy it is to do this or that by writing bits of
code, and that hence nothing of the sort is required?

Michael Brazier

unread,
Feb 11, 2000, 3:00:00 AM2/11/00
to
Mike Arnautov wrote:
>
> Michael Brazier <mbra...@argusinc.com> wrote:
>
> >> This is just as useful as for example having the kernel to support
> >> objects which either exist in more than one place, or which are linked
> >> in such a way that their state is always identical -- e.g. doors. And
> >> for exactly the same reason. Having declared a door, you don't need to
> >> worry about opening/closing/locking/unlocking it so that its state
> >> remains consistent when viewed from different location.
> >
> >Straightforward object-oriented programming; it's nothing novel.
>
> Exactly. But why is it OK to apply it to "objects" in the game, but when
> I suggest that a similar technique is applicable to texts, everybody
> starts telling me how easy it is to do this or that by writing bits of
> code, and that hence nothing of the sort is required?

As I said before: "Both Inform and TADS allow the programmer to put
arbitrarily complex expressions into game text. Writing text that


changes according to the state of an object is very easy; a special
notation for certain common cases of variable text seems like overkill."

Let's take your morphing crystal statue and code it in a psuedo-Inform
style.

Object crystalStatue with
animals = ["a pig" "an elk" "a wombat" "a snark"]
currentAnimal = 0
description = [
print "The statue depicts ", animals[currentAnimal],
" after the manner of Arnautov."
]
after = [Examine: [currentAnimal = random(4)]
]

Now, what would be gained by having a special syntax for "pick one
string at random from this list"? The object definition would look
simpler -- no need for the "animals", "currentAnimal", or "after"
properties, just stick the special syntax into the "print" instruction
where the array reference is now.

But what would be lost by it? Well, what if you want the statue's
description to change in a cyclic progression? What if you don't want
to morph every time the statue is examined? What if you want a morph
whenever the statue is carried past an Oriental carpet instead? What if
the shape chosen has to depend on _which_ Oriental carpet it was carried
past?

In the usual IF languages you can do things like that just by recoding
the right properties -- and you can duplicate all your "text morphing"
examples, too. The kinds of problems your special syntax would solve
are already easy to solve in Inform or TADS. It doesn't add anything,
in either power or convenience.

Aquarius

unread,
Feb 12, 2000, 3:00:00 AM2/12/00
to
Mike Arnautov spoo'd forth:

> Iain Merrick <i...@cs.york.ac.uk> wrote:
>>Iain Merrick wrote:
>>[...]
>>> For what it's worth, your example could be written in TADS like this:
>>>
>>> animals: fixeditem
>>> varNoun = ['pig' 'tiger' 'mule' 'ibex']
>>> noun = 'statue'
>>> sdesc = "statue of a <<currentNoun>>"
>>
>>Errr, obviously you might end up with a 'statue of a ibex' here. I guess
>>you'd want to use, say, "statue of <<aCurrentNoun>>" instead, and have
>>aCurrentNoun check for an initial vowel.
>>
>>Now, if this bug were hard-coded, you wouldn't be able to fix it at all!
>>So my stupidity just proves my point again. :)

> Only because you insist on imagining that I suggesting hard-coding
> anything. My example was: a[ pig/ tiger/ mule/n ibex] -- and the use of
> this switch does not on any explicit procedures such as currentNoun or
> aCurrentNoun. And as you point out, you have to write into aCurrentNoun
> a specific check. OTOH, I don't have to write *any* code at all.

I'm missing something here. Are you suggesting that the code might look
something like
ldesc = "A finely wrought [marble/iron/Wensleydale] statue of
a[ pig/ tiger/ mule/n ibex]."
If so, then the code for your mirror would have to also have the same
"text morphs" in, surely (so you need the [ pig/ tiger...] bit again in
the mirror description), which means that you have to code it twice? If
you store the text morph somewhere else (in a variable, say), then what's
the difference between doing it a "text morphing" way and using varNoun
as Iain did? If the mirror merely picks up the ldesc of the object, then
that would just as easily be done in TADS without necessarily having a
particular text morph method.

I suppose you could do
ldesc = "A finely wrought statue of a << ['pig','mule'](rand(2)) >>.",
but I'm not sure it would work :)

Aquarius

--
Well *done*, Aquarius -- a phrase we love typing because it makes us feel
like the boss-character from a 1980s Glen A Larson action series...
NTK, http://www.ntk.net/index.cgi?back=archive99/now0618.txt&line=292#l

Mike Arnautov

unread,
Feb 13, 2000, 3:00:00 AM2/13/00
to
Stephen Granade <sgra...@login1.phy.duke.edu> wrote:

>If you want to argue that text morphing provides something that IF
>authors should take advantage of, great. That has the potential to be
>a good discussion. If you want to say that having text morphing
>transparently available to an author is a good thing, okay. Again,
>that's potentially a good discussion. If you want to say that no
>language other than SooperSpiftyLanguage supports text morphing, don't
>be surprised to hear people say that you are wrong.

You are right of course. In an earlier post I stated that it was not my
intention to have a My-Language-Is-Better-Than-Yours argument. Well
guess what? I got seduced to arguing language specifics anyway... :-)

So, for the record, I retract, repent and rescind any statement which
could, may or might be interpreted in such a manner. Specifically:

1. As my write-up on A-code (available on my site given in my sig) says,
as a programming language A-code is pretty primitive. I have absolutely
no doubt that other IF systems beat it hollow generically speaking.
Furthermore, I have no intention of suggesting to anybody that they stop
using their favourite language and rush to learn A-code -- I would be
daft and they would be daft. :-) Personally I am sticking to A-code
because (a) it serves my purpose and (b) I am lazy and A-code is
something I know already.

2. I further make no claim that the way A-code implements text morphing
is the best imaginable way of implementing such a feature. I do think it
is a good way, but there may well be better ones.

3. Given the sophistication of other IF-systems, it astonishes me that
they do not offer explicit support to the "literary" approach to IF,
text morphing being to my mind the simplest features offering such
support.

I do want to argue that:

a) Text morphing is a technique which is rather considerably more useful
than seems to be generally believed, particularly if sufficiently
generalised and supported by the engine uniformly in different contexts.

b) Major IF-systems should explicitly support it. Which, they don't.
Sorry if I tread on any toes, but demonstrating that ad-hoc bits of code
or procedures can be written to perform this or that specific text-
morph, does not amount to demonstrating support for text morphing.

c) Text morphing should be performed automatically by the engine, if the
text in question is declared in a suitable way (e.g. using A-code
text switches). In other words, that the author should be able to deal
with the morphing features in a declarative, rather than procedural
manner -- at least for the default morphs. Procedural overrides can also
be of great use.

Responses so far range from "Why are your A-code snippets in upper case?
-- looks very 70s!", through "I'd rather write ad hoc code" and
"Language X supports morphing too -- 'cause I can write ad hoc code", to
"I'd rather write simulations".

Let's phrase it somewhat differently -- which perhaps might help. All
popular IF systems offer direct support for handling things/NPCs in an
IF programs, reducing the amount of house-keeping required from the
author. All I am really suggesting is that *text* is by definition of
great importance in IF and hence that features reducing house-keeping
requirements for handling texts, should also be supported.

IF (and IF-system) authors motivated primarily by the simulation aspect
of IF, see no need for any such support, because in their approach there
is no text-related house-keeping required anyway. However, where the
literary approach to IF is taken seriously, the house-keeping tasks do
arise, but because they have to be handled explicitly, authors tend to
keep them to the barest minimum (as I did, before it occurs to me to
generalise Dave Platt's text switches). Once such support does exist, my
experience is that one starts using text morphing more and more, because
it becomes easier to do so.

In short, by offering explicit, built-in text morphing support, and IF
authoring system promotes the literary style of IF. Which I think is a
Good Thing.

Mike Arnautov

unread,
Feb 13, 2000, 3:00:00 AM2/13/00
to
Michael Brazier <mbra...@argusinc.com> wrote:

>As I said before: "Both Inform and TADS allow the programmer to put
>arbitrarily complex expressions into game text. Writing text that
>changes according to the state of an object is very easy; a special
>notation for certain common cases of variable text seems like overkill."

And as I tried to explain, it doesn't to me.

Once again, your example deals with a specific case of morphing. What is
lost is the fact that it only deals with examining the sculpture. In
order to emulate text morphing properly, you would need to instrument
with 'animals [currentAnimal]' every possible reference to the statue.
(And it isn't clear to me how your code deals with the statue not being
referable to as one animal, when it has the shape of another -- but that
could be my ignorance of Inform; is it?).

Fully supported text morphing automatically affects any non-instrumented
reference to that text. In other words, instead of having to remember to
refer to 'animals [currentAnimal]' when one wishes to refer to the
sculpture, one simply refers to the sculpture -- the engine morphs is
appropriately. Even if later on you (or somebody else) amends your
program to fix something locally and the fix includes a text reference
to the sculpture, the morphing will occur, without the fixer even
realising that there is anything special about the object.

It also means that where you have to process objects in a loop (e.g. in
confirming to the player the effect of his 'some-verb all' command), the
objects can be named uniformly, instead of having to make a special case
for the morphed ones. Sure, you could (and should!) have a sub-procedure
to handle any such naming occurring in a loop, and that could make the
explicit check. But why bother? It only complicates the code and
scatters references to the morphed nature of a particular object,
instead of keeping it tightly where it belongs.

Once you start using morphing on a large scale, all of this is not
something to be sneezed at, believe me!

>Now, what would be gained by having a special syntax for "pick one
>string at random from this list"? The object definition would look
>simpler -- no need for the "animals", "currentAnimal", or "after"
>properties, just stick the special syntax into the "print" instruction
>where the array reference is now.
>
>But what would be lost by it? Well, what if you want the statue's
>description to change in a cyclic progression? What if you don't want
>to morph every time the statue is examined? What if you want a morph
>whenever the statue is carried past an Oriental carpet instead? What if
>the shape chosen has to depend on _which_ Oriental carpet it was carried
>past?

You misread my posts. This was exactly what morphing I use does allow me
to do. If it were merely random, it would be of as limited a use as you
suggest, of course. But it isn't, so it ain't. :-)

>In the usual IF languages you can do things like that just by recoding
>the right properties -- and you can duplicate all your "text morphing"
>examples, too. The kinds of problems your special syntax would solve
>are already easy to solve in Inform or TADS. It doesn't add anything,
>in either power or convenience.

We'll just have to differ on this. I would much rather have a unified
notation which supports morphing on the declarative level, than writing
ad hoc bits of code, or instrumenting text references all over the place

Mike Arnautov

unread,
Feb 13, 2000, 3:00:00 AM2/13/00
to
okbl...@my-deja.com wrote:
[also a while back]

>I can't say I see what you're seeing at all. There's a lot of talk
>about simulation on the board here, but very little that would go so far
>as to justify your definition of IFM. In particular, that part of the
>definition that has to do with limiting authorial freedom.

Well, there I was simply responding to Dan's (I think) post, which was
explaining to somebody else that doing so-and-so would be difficult
because (e.g.) you would have to take into the account the autonomous
wanderings of NPCs through your world and their interactions. To which
my response is, yes, but only if you delegate all of that to the engine.

>Most IF frameworks that people use today offer very little in terms of
>world simulation. Cardinal direction handling, a few concepts like
>"surface", "hidden", and, uh, doors. Oh, and inventory management. Some
>of the nifty add-ons do things like sense-passing.

And NPCs. But let's take doors, or accessibility filters, for that
matter. Do you think handling doors is a good idea? I do. It saves
house-keeping. So why is it not a good idea to offer similar support for
(e.g.) providing different responses to repeats of the same action?

Besides, Dan was giving a very good impression of somebody who is
strongly motivated towards modelling and can't see the point of (e.g.)
varying ones responses in a systematic manner.

It is attitudes I am largely referring to. That's necessarily so,
because, as I already said, without very powerful AI, modelling IF is
not going to get very far.

>Your two strands don't actually exist, although you're not the first to
>suggest that they do.

Which might suggest that there is something in the idea that they do?
:-) But you are right, of course. I deliberately referred to IFL and IFM
as co-rdinate axis, rather than as an actual categorisation of IF. And
of course, I omitted the third dimension -- IF as Puzzles. It is
probably the case that most IF output clusters along that axis anyway.

>We have doors that open and shut and inventory commands that work
>(though I believe we had examples of doors and inventory failing in the
>comp). Why can't we have other things that just work without being any
>less literary?

No reason whatsoever. But invert your question... Why not offer explicit
support for doing things with text rather than with objects? The very
idea that text is something you could *do* things with (other than just
display), does not seem to be very common! Offering support for such
things (as opposed to letting the author to do his own coding to achieve
them) would encourage the literary approach, which is what I am after.

>I think that as long as the character and story development isn't
>simulated, you still have IF. When you start having elements randomly
>combine to produce new (essentially arbitrary) stories, then you have
>DOOM. Er, "The Sims", I guess.

You are being unfair to the simulation approach here. I can see the
attraction of describing the world and then letting the engine run it
and interact with the player as an "object" in that world. The
attraction is that if you define the "physics" (in a generalised meaning
of the word) correctly, then the player can do *anything* -- even things
not anticipated by the author, and not be told "you can't". The price is
that such interaction is no longer intended in its entirety, and hence
not fully literary.

Kevin Forchione

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
"Mike Arnautov" <m...@mipmip.demon-co-antispam-uk> wrote in message
news:5XZESNAB...@mipmip.demon.co.uk...

> It is attitudes I am largely referring to. That's necessarily so,
> because, as I already said, without very powerful AI, modelling IF is
> not going to get very far.

Perhaps not. But even with text morphing the development of the world model
would continue. After all, text switches may provide alternative responses
to the library's default response, but behaviours are still going to have to
be determined through some rules-based mechanism. A door that twitters away
5, 50, or 500 morphed responses is still going to be expected to behave like
a door.

Don't get me wrong. Text morphing is just another widget to me, just like
the ? : statement or anything else. What I'm interested in is the model
world. Text morphing is reather like lights on the Christmas tree, very
pretty to look at, but most will still want the underpinnings of trunk,
needle, and limb.

I don't expect the world model to advance very far or very fast. I don't
expect a powerful AI engine to come along any time soon. Development in IF,
like everything else in computer programming, is as much a matter of need as
marketting. So I suspect that development of model worlds will continue as
long as there is a demand for it, and I suspect that text morphing will find
a niche as long as there is someone to preach the gospel.

I, for one, think we've done enough throwing of shoes at lights. It's time
to talk about walls, ceilings, and floors...

--Kevin


okbl...@my-deja.com

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
In article <5XZESNAB...@mipmip.demon.co.uk>,

Mike Arnautov <m...@mipmip.demon-co-antispam-uk> wrote:
>
> Well, there I was simply responding to Dan's (I think) post, which was
> explaining to somebody else that doing so-and-so would be difficult
> because (e.g.) you would have to take into the account the autonomous
> wanderings of NPCs through your world and their interactions. To which
> my response is, yes, but only if you delegate all of that to the
engine.

I believe that the ideal IF system is the one that handles every detail
the author doesn't wish to handle, or simply *cannot* handle due to the
limitations of time and space.

> And NPCs.

NPC support is underwhelming, I think. But then, the whole approach to
NPC modelling is limiting.

> But let's take doors, or accessibility filters, for that
> matter. Do you think handling doors is a good idea? I do. It saves
> house-keeping. So why is it not a good idea to offer similar support
for
> (e.g.) providing different responses to repeats of the same action?

Handling doors is just fine, as long as the author can intervene at any
point and handle a paraticular door or set of doors differently.

Try as I might, I haven't been able to get a grasp on what it is you're
offering. It's all gotten very abstract. As a result, I'm having as
difficult a time as others figuring out what it is you're offering.
Different responses to repeats of the same action is not necessarily a
good thing.

I don't personally care for the way TADS or Inform or Alan or Hugo
handles text, in that I think the text should be maintained separately
from the code. But I suspect that having the text in the code allows the
author to feel more "literary". That is, the more text that is right in
front of the author, the easier it is to create the desired literary
effect.

But I'm having a very difficult time understand how text morphing--in
any form--is different from, say, any given language's string formatting
routine, except that you don't *have* to use FormatStr if you don't
want to.

> Besides, Dan was giving a very good impression of somebody who is
> strongly motivated towards modelling and can't see the point of (e.g.)
> varying ones responses in a systematic manner.

This is the part that's confusing me: The most obviously literary
approach to IF is a series of switches that output blocks of text. The
more you get into putting out "arbitrarily" assembled varieties of
strings, the further you get away from literary qualities such as
rhythm. In other words, it seems to me that text morphing is more
opposed to the "literary" and more aligned with the "simulationist".

I hope that clarifies.

> It is attitudes I am largely referring to. That's necessarily so,
> because, as I already said, without very powerful AI, modelling IF is
> not going to get very far.

The evidence of that being, I suppose, that it hasn't gotten very far to
this point. Then again, a very powerful AI running a simulated world
would hardly be literary at all. I don't see any big push there.

I really do believe the goal is a world simulated to the extent that the
author can concentrate on the literary aspects. In such an environment
(ideally, anyway), the reader would ignore those things that the author
did not specifically direct him to, having grown tired of burning down
houses and smashing vases.

> Which might suggest that there is something in the idea that they do?

Or merely illustrate the trite reality that there is a strong desire to
divide the world into US and THEM. :-)

> :-) But you are right, of course. I deliberately referred to IFL and
IFM
> as co-rdinate axis, rather than as an actual categorisation of IF. And
> of course, I omitted the third dimension -- IF as Puzzles. It is
> probably the case that most IF output clusters along that axis anyway.

I would consider puzzles simulations. Sub-simulations, if you like.

> No reason whatsoever. But invert your question... Why not offer
explicit
> support for doing things with text rather than with objects? The very
> idea that text is something you could *do* things with (other than
just
> display), does not seem to be very common! Offering support for such
> things (as opposed to letting the author to do his own coding to
achieve
> them) would encourage the literary approach, which is what I am after.

Interesting. I think I understand what you're getting at. The
fundamental truth is that any given session with IF is what the reader
perceives it as. Therefore, if the game prints out "The cat is on fire"
then the cat *is* on fire.

But how, without objects, do you propose the author keep track of the
game state? If the author allows text to be printed that indicates the
cat is on fire, there must also be code which recognizes the effect of
pouring a bucket of water on the cat.

The instant you set the cat on fire, you need an object. How long does
the cat burn and how brightly? What modelling attempts to do, then, is
make other things in the world realize that the cat is on fire.

You can't do that just by morphing text. And, in practice, the morphing
of the text is a relatively minor consideration compared to the state of
the flaming cat.

> You are being unfair to the simulation approach here. I can see the
> attraction of describing the world and then letting the engine run it
> and interact with the player as an "object" in that world. The
> attraction is that if you define the "physics" (in a generalised
meaning
> of the word) correctly, then the player can do *anything* -- even
things
> not anticipated by the author, and not be told "you can't". The price
is
> that such interaction is no longer intended in its entirety, and hence
> not fully literary.

I don't see how I'm being unfair: I can see the attraction to this as
well, just as I can enjoy a game of Quake III or SimCity. When the
point ceases to be the telling of a specific story, however, you don't
have some other kind of IF: you don't have IF at all.
--
[ok]


Sent via Deja.com http://www.deja.com/
Before you buy.

Gunther Schmidl

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
"Mike Arnautov" <m...@mipmip.demon-co-antispam-uk> wrote:

> Once you start using morphing on a large scale, all of this is not
> something to be sneezed at, believe me!

[...]

I have to ask this now, because I was in a similar discussion some time ago
where two people, including me, tried to get palette rotation included into
Blorb or a possible successor.

The main questions pitted against us were "What for?" and "How often is it
going to be used?"

So, well, I needed it, and I was going to use it. Once.

And that didn't justify adding it. Sure, I was pissed, but I didn't really need
it.

The same questions apply here: How often is morphing going to be used in one
single game? Of course it's possible to write a game just to prove the point
you do need it, but look at all the available games out there and count how
many of them use morphing.

(And actually, I do use morphing in my WiP, but I find Inform's "@00" to be
quite good enough for my purposes.)

--
+-----------------+---------------+------------------------------+
| Gunther Schmidl | ICQ: 22447430 | IF: http://gschmidl.cjb.net/ |
|-----------------+----------+----+------------------------------|
| gschmidl (at) gmx (dot) at | please remove the "xxx." to reply |
+----------------------------+-----------------------------------+

Gunther Schmidl

unread,
Feb 14, 2000, 3:00:00 AM2/14/00
to
"Mike Arnautov" <m...@mipmip.demon-co-antispam-uk> wrote:

> b) Major IF-systems should explicitly support it. Which, they don't.
> Sorry if I tread on any toes, but demonstrating that ad-hoc bits of code
> or procedures can be written to perform this or that specific text-
> morph, does not amount to demonstrating support for text morphing.

Inform:

Lowstring green "green";
Lowstring red "red";

String 0 green;
print "A @00 apple is here"; ! prints "A green apple is here"
String 0 red;
print "A @00 apple is here"; ! prints "A red apple is here"

or:

Object apple
with
name 'green' 'apple'
description "A green apple.";

apple.&name-->1 = "red"; ! undoubtedly wrong somehow.
apple.description = "A red apple.";

Similar stuff can be done in TADS, but I'm not sure how right now.

Personally, I use the first method. It's appropriate enough and specifically
used for this sort of things, e. g. reversing the entire game map. See the
Inform Designer's Manual for more information.

I know that you're not going to start using Inform, because you already know
A-Code. I know that I'm not going to start using A-Code, becau