Location management/Revisiting locations
Nicholas Shore
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
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
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
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
"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
> 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
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
<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.
>
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
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
> <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
>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
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
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
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
>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
>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
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
>>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.
> 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
[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
> 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
>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?"
>
>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
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
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
[...]
> 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
[...]
> 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
>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
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
>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
>> 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
>
> Neil K. <fake...@anti-spam.address> wrote:
> > Mike Arnautov <m...@mipmip.demon-co-antispam-uk> wrote:
> >
> >> 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?"
> >
> >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
> 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
>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
>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
>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
>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
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
>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
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
>Iain Merrick wrote:
>[...]
>> For what it's worth, your example could be written in TADS like this:
>>
>> 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
> 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
>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
>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
>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
>> 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
>
> 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
> 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
>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
>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
[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
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
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
> 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
> 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, because I already know
Inform, Hugo and some TADS. But saying there is no support at all for morphing
is not true.
okbl...@my-deja.com
Mike Arnautov <m...@mipmip.demon-co-antispam-uk> wrote:
>
> 1. As my write-up on A-code (available on my site given in my sig)
Sluggish site though it is....
> 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.
You keep saying this and I keep failing to understand what you mean. I
don't understand how text morphing is more "literary" except that--when
you say it you seem to mean to exclude the administration of game state
information from the equation somehow.
Couldn't you include some pseudocode or something that would clearly
illustrate this? I can shine some light on the benefits of OO in just a
few short pseudocode samples, so how about you do something of that
sort?
> 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.
Then howzabout showing how a snippet of TADS code could be improved if
it had text morphing? Use something that has been presented to you as
an example and recode it as though TADS had text morphing support.
> 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".
It's unfortuntate that you haven't been understood but it's not from
lack of trying, at least on my part.
> 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.
But that's deceptively simplistic. You don't see as much trouble
*changing* text output as you do just keeping track of what needs to be
changed. I think that's why you're seeing such underwhelming interest.
> 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.
This is the sort of a post that's going to get you into trouble, though,
because you're saying that those who disagree with you aren't interested
in the literary aspects of IF, when most of them probably are.
Not to repeat myself, but if a simulation allows me to ignore those
things which are not germane to the story, then I'm going to be able to
focus on actually *telling* the story, hence take more time with the
literary aspects of the story. And we don't need a powerful AI to do
this: Just not having to re-code doors every time I need one helps a
lot.
As we approach increasingly simulation-oriented models, the author will
spend more time making sure the simulation acts as he expects. Like
with the sense-passing toolkits for TADS: You want to make sure that the
onions are detectable when they're on the counter versus in the icebox.
But that makes his job one more of tweaking, versus one of doing massive
amounts of coding just to get the right behavior--and that before even
touching the writing.
Iain Merrick
[...]
> 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.
I'm not sure what you mean here. Doesn't your A-Code example have the
same problem? You couldn't simply put "there is a statue of a horse
here" in the room description, for instance; you'd have to type
something like:
print "There is a statue of a";
print animal_text;
print " here.";
(I'm assuming the room and the statue are distinct objects.) I probably
have the syntax completely wrong, but you see what I mean. I don't see
how this differs from the equivalent code in Inform or TADS.
> (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?).
I can't speak for Inform, but in TADS the 'noun' property controls this
(along with 'adjective'). This is actually one case where 'text
morphing' is a bit fiddly; the vocabulary words are collected into a
lookup table before the game begins, so you can't use methods which
return arbitrary strings.
You can manually adjust an object's vocabulary words with addword() and
delword(), however, and it should be possible to hide this stuff from
the game author in a text-morphing library. For example, at the end of
each command you might scan all the morphable objects and update their
vocabulary words. Inform probably works in a similar way.
> 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.
Unless I'm misunderstanding you, the same applies to TADS and Inform. I
might write the animal statue with explicit text-morphing calls in its
'sdesc' and 'ldesc' properties, for instance. Other parts of the game
will use those properties to print out short or long descriptions of the
object, so they will automatically inherit the text-morphing stuff. If
you pick the statue up, for instance, its 'sdesc' will appear in your
inventory listing.
> 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.
It doesn't necessarily scatter references to any _particular_ object.
Suppose some friendly library hacker writes you a library which contains
a MorphableObject class. You would use this class where appropriate to
use morphable text in your objects.
The library hacker would insert the appropriate parser hooks to check
for morphable objects; this code would not have to refer to any
particular object the game author creates. The game author wouldn't have
to know how it all hangs together, just how the MorphableObject class is
used.
> Once you start using morphing on a large scale, all of this is not
> something to be sneezed at, believe me!
I still don't see it, sorry. Is there code available for some reasonably
substantial game that demonstrates the various uses of text morphing? At
the moment we just have a single hypothetical example.
--
Iain Merrick
i...@cs.york.ac.uk
Andrew Plotkin
> 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.
>
> 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.
> referable to as one animal, when it has the shape of another -- but that
> could be my ignorance of Inform; is it?).
Inform supports this sort of morphing both for printing and reference, and
without scattering code around the game. I'm *sure* this has been
asserted already in this thread.
For example, the final object you acquire in _So Far_. This object changes
as you move it around the game; its name and appearance depend on which
room it's in.
All the code to implement this is in a single object.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Dan Schmidt
| I'd argue that the big failing in inform is that you *can't*
| include procedural elements inside strings (I haven't discerned
| whether you can in Tads).
You can indeed in TADS; just put whatever code you like inside angle
brackets, e.g.:
"The factorial of 6 is <<factorial(6)>>. Isn't that exciting?";
--
Dan Schmidt | http://www.dfan.org
Sean T Barrett
I guess this opens up the question: when is the function
call evaluated? When the string is printed? Is there an
"eval" that allows you to turn a string with procedure
calls into one without? Can there be variable references
inside the function calls? Strings would become closures
in that case, which would be kind of cool, but pretty
complex to have implemented, so I tend to assume not.
Sean
Kevin Forchione
news:FpzFD...@world.std.com...
> Dan Schmidt <df...@thecia.net> wrote:
> >buz...@world.std.com (Sean T Barrett) writes:
> >| I'd argue that the big failing in inform is that you *can't*
> >| include procedural elements inside strings (I haven't discerned
> >| whether you can in Tads).
> >You can indeed in TADS; just put whatever code you like inside angle
> >brackets, e.g.:
> > "The factorial of 6 is <<factorial(6)>>. Isn't that exciting?";
>
> I guess this opens up the question: when is the function
> call evaluated? When the string is printed?
When the string is executed, yes.
>Is there an
> "eval" that allows you to turn a string with procedure
> calls into one without?
I'm not sure I follow you here.
>Can there be variable references
> inside the function calls?
Yes, in fact it is very common to use strings such as:
"You see a candle here, <<self.islit ? "shining brightly" :
self.isburntout ? "blackened and scorched" : "ready for use">>."
It is also perfectly feasible to do (as I have done with Sense.t) the
following:
"the <<self.sdescR>>."
where sdescR is a method. You could, of course, embed a function with
parameters passed from the local environment, etc.
--Kevin
Sean T Barrett
>buz...@world.std.com (Sean T Barrett) writes:
>> I guess this opens up the question: when is the function
>> call evaluated? When the string is printed?
>
>"print this string", with the '' syntax, which defines a string. The
>above is not really a string, but a print-string function being called
>with a constant string argument, and part of that constant string
>argument includes an embedded function call.
Interestingly enough, glulx allows strings with embedded
function calls which are invoked when the string is printed.
I'm not sure how useful it is since all of the parameters
to the function have to be constants, so they can be addresses of
known entities and suchlike, but you couldn't even embed the equivalent
of a C++ 'this' (this is where you'd need closures--if you
return a string from a method for object X, you need to keep
track that that value was associated with X, because when you
print it from object Y you probably want it to be called
on X--although even getting it called on Y would require you
to keep track of 'this' in a global, I think).
SeanB
Mike Arnautov
>Inform supports this sort of morphing both for printing and reference, and
>without scattering code around the game. I'm *sure* this has been
>asserted already in this thread.
We seem to be going around in circles -- probably partly because I am
responding to points being illustrated by examples from different
languages.
Let me try another tack.
a) Sean Barrett wrote
>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.
I find it hard to square this with the assurances that universal text
morphing in Inform is so simple and natural that there is no need to add
any support for it. I think you are responding to my individual
examples, each of which is bound to be more relevant to some languages
than to others. Try instead to consider morphing as something applicable
to all text in a uniform manner. If I understand Sean correctly, his
need was for what I would call (following the terminology of early
Adventure versions) varying "random messages". I note with interest his
comment about making more use of the effect as the result. That's
exactly the distinction I am trying to make between something being
possible and something being supported.
b) In so far as writing pure text IF, what features (aside from the
parser) make it preferable to use Inform rather than C++ (or Perl)?
E.g. I see from example code that Inform supports statements such as
move cloak to player;
give cloak worn;
Why is that preferable to
cloak.location = player;
appendTo (player.inventory, cloak);
cloak.worn = 1;
All of this can be done in any OO language, so why bother to invent
special notation?
I think I don't need to spell out the parallel with our discussion
topic. :-)
Mike Arnautov
>Don't get me wrong. Text morphing is just another widget to me, just like
>the ? : statement or anything else.
Well, yes, it is. I don't quarrel with that. It's just a tad more
useful. :-)
> 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.
But that's where we differ. You speak of rule based behaviour. To my
mind, without a powerful AI behind it, rule-based behaviour has a very
unsatisfactory effect. I am not suggesting that people shouldn't keep
working on it, perish the thought! But I would *also* like to promote
the alternative approach, which does not involve rule based behaviour,
but author's intentionality. That's what interests me. And that's where
text switches do help.
None of which does not mean that I consider what interests you to be
somehow inferior. It's just that our interests differ. As interests tend
to. :-)
Mike Arnautov
>I'm not sure what you mean here. Doesn't your A-Code example have the
>same problem? You couldn't simply put "there is a statue of a horse
>here" in the room description, for instance; you'd have to type
>something like:
>
> print "There is a statue of a";
> print animal_text;
> print " here.";
>
>(I'm assuming the room and the statue are distinct objects.) I probably
>have the syntax completely wrong, but you see what I mean. I don't see
>how this differs from the equivalent code in Inform or TADS.
Don't worry about the syntax... :-) But yes, morphing can take care of
your example, though with the restriction that the statue cannot be
moved away from the room -- otherwise it is just a random object and
should not have its description embedded in the description of the room.
I could write "Some-room-description. There is a statue of {ANIMALS}
here. Some-more-room-description". Where {ANIMALS} signals the inclusion
of a text named ANIMALS, which contains the relevant text switch. In the
current version of A-code, this will work as long as I remember to keep
that state of the statue in step with that of the room. But before you
say "Aha! Gotcha!", please note that this a restriction of
implementation due to laziness on my part, rather than any fundamental
principle.
There are two generalisation of the present implementation, which I'd
like to implement in the future. (1) To allow text switches to be
qualified by lists qualifiers, rather than a single qualifier. (2) To
allow in the declaration of the switch to tie dynamically to the
state/value of a particular entity (place, object, variable...).
If there is no other independent morphing going on in that description,
just (2) above would suffice. When declaring the room description, tie
it to the state of the statue and Bob's your uncle. The other
improvement is only required to handle two or more completely
independent switches within one piece of text. At present I sometimes
have to break a text into two, because of that -- which is a bit
awkward.
>> (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?).
Of A-code you mean? :-) In my original example, I used the same text
switch in naming the sculpture:
OBJECT SCULPTURE
VOCABULARY SCULPTURE, {ANIMALS}
I noted that the example was using "self-explanatory extensions" of the
current A-code implementation. That because I am trying to advocate the
idea of morphing, not push A-code. :-) The above is one of the
extensions which came to me as I typed the example. Vocabulary is also
text and if treated as such (which A-code currently doesn't, but it
should!), this would automatically mean that the sculpture can only be
referred to as "sculpture" or as the appropriate animal (because the
switch ANIMALS will only have a specific state, according to the state
of the entity forming its context -- the sculpture in this case.
There would be no need to add and delete vocabulary words dynamically as
the sculpture morphs itself.
>I can't speak for Inform, but in TADS the 'noun' property controls this
>(along with 'adjective'). This is actually one case where 'text
>morphing' is a bit fiddly; the vocabulary words are collected into a
>lookup table before the game begins, so you can't use methods which
>return arbitrary strings.
That's not a problem. A-code does the same. The lookup table would
simply contain the switch ANIMALS, which expands to a[ pig/n ibis/...]
The table also identify the object being referred to, so all it needs to
do is to evaluate the switch in the context of the relevant object and
decide whether the result matches what the player input. Yes, one would
have to use a more complex search technique than (e.g.) binary chop, but
I really cannot see the speed of parsing lookup as being a limiting
factor.
>You can manually adjust an object's vocabulary words with addword() and
>delword(), however, and it should be possible to hide this stuff from
>the game author in a text-morphing library. For example, at the end of
>each command you might scan all the morphable objects and update their
>vocabulary words. Inform probably works in a similar way.
Indeed. That's the sort of house-keeping text morphing applied
consistently for all text handling could eliminate or at least simplify.
As must be obvious from the above, I am still finding further
generalisations of the idea.
>> 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.
>
>Unless I'm misunderstanding you, the same applies to TADS and Inform. I
>might write the animal statue with explicit text-morphing calls in its
>'sdesc' and 'ldesc' properties, for instance. Other parts of the game
>will use those properties to print out short or long descriptions of the
>object, so they will automatically inherit the text-morphing stuff. If
>you pick the statue up, for instance, its 'sdesc' will appear in your
>inventory listing.
You are still thinking in terms of sdesc, ldesc etc. If you stick to
those, sure. But morphing can be equally used to any random piece of
text. Hence my examples of self-morphing random messages. Also, adding
the ability to tie a random message to a state/value (as discussed
above), makes it feasible to do more. Suppose you have a non-magical
lamp which uses flame rather than electricity to give light. If you tie
to its state (not lit/lit) the message "[You rub the lamp assiduously,
but aside from it getting better polished, nothing happens./Only an
idiot would attempt to rub a lit lamp. Since you are not an idiot you
change decide not to bother.]" Now you can respond to a command to rub
the lamp with that message, without bothering to check the state of the
lamp. That's what I meant by "making a reference" to morphing objects.
>> 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.
>
>It doesn't necessarily scatter references to any _particular_ object.
>Suppose some friendly library hacker writes you a library which contains
>a MorphableObject class. You would use this class where appropriate to
>use morphable text in your objects.
Of course. But it needs writing and the world is short of friendly
hackers -- they are all programming Linux kernel these days. :-) And
wouldn't you be even better off if the said friendly hacker simply
implemented morphing across the board for you?
>I still don't see it, sorry. Is there code available for some reasonably
>substantial game that demonstrates the various uses of text morphing? At
>the moment we just have a single hypothetical example.
Well, I've since ten given several actual example from work in progress.
Also adv660 uses morphing, though not as much as I do these days. It
mostly restricts itself to morphs such as (I quote verbatim)
[/A ball/Balls] of searing flame burst[/s/] out of your magic ring,
rebound[/s/] off of the ground, and vaporize[/s/] the
kni[/fe/ves] before [/it/they] can reach you.
But until adv770 is done, I'd rather not release the A-code source of
it. :-)
Mike Arnautov
>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, because I already know
>Inform, Hugo and some TADS. But saying there is no support at all for morphing
>is not true.
I am sorry to disagree, but your example doesn't show any "support" for
morphing. Merely that morphing can be done in a fairly ad hoc manner. As
I keep saying, all features of Inform (and any other IF language) are
just as much "supported" by C++ (except for the parser, I suppose) -- so
why bother with IF languages?
Andrew Plotkin
>
> b) In so far as writing pure text IF, what features (aside from the
> parser) make it preferable to use Inform rather than C++ (or Perl)?
> E.g. I see from example code that Inform supports statements such as
>
> move cloak to player;
> give cloak worn;
>
> Why is that preferable to
>
> cloak.location = player;
> appendTo (player.inventory, cloak);
> cloak.worn = 1;
It's not.
> All of this can be done in any OO language, so why bother to invent
> special notation?
It's historical legacy from when Inform was barely more than a pretty
assembler for Z-code. And I've considered Inform library rewrites that
would switch over to that notation.
Mike Arnautov
>I don't know what Mike means by it.
[....]
>I think there are very few games that if you looked at a transcript
>from a skilled player playing it for the first time, and not
>setting out to break it (which seems like the best, fairest
>case for judging the quality of the output text), that you
>could believe a human "hand wrote" the responses--*and*, I'd
>argue, this is an ideal at least some people feel we are or
>should be aiming for.
Which is exactly what I mean. Thanks.
>But in the same way the transcript test reflects the degree
>to which there is a human mind generating the text output to
>the player, I find the repetition common to NPC speech to make
>it far too obvious that there's "nobody there at all"
I couldn't agree more. But as you rightly say, it goes well beyond NPC
behaviour.
Mike Arnautov
>If text morphing really
>makes it so much easier to do this thing, you might decide to
>make use of the tool since it's handy. This is certainly the
>argument for why I wrote an Inform compiler extension to provide
>serially-varying strings, because I decided it might make a difference
>for NPC responses. In my experience, once you have it, you *do* tend
>to make use of it.
My experience too.
>(But I agree about the more general kinds of
>morphing, which I think are handled adequately in Inform and well
>in Tads, from what I know of their synataces.)
Not from what I've seen so far. Only if you stick to ldesc/sdesc (and
even that is arguable, I think). Once you start thinking wider, the
difference between descriptions and other sort of text starts getting
vague and morphing opportunities present themselves. Sure you can create
new classes and procedures and such like (which a typical non-programmer
IF author won't, BTW), but why deny yourself the benefit of the uniform
way of doing such things?
David Glasser
> I am sorry to disagree, but your example doesn't show any "support" for
> morphing. Merely that morphing can be done in a fairly ad hoc manner. As
> I keep saying, all features of Inform (and any other IF language) are
> just as much "supported" by C++ (except for the parser, I suppose) -- so
> why bother with IF languages?
OK, I wanted to stay out of this, but I'm getting annoyed. So I'll say
my thing, using TADS as an example.
In TADS, one can do:
ldesc = "The animal seems to be <<ANIMAL>>"
(maybe you need parentheses after ANIMAL, but I don't think so)
In A-Code, I think you can do (I couldn't find a description of morphing
on your website, sorry):
"The animal seems to be {ANIMAL}."
OK, so syntax-wise there isn't much of a difference.
Now, why do I think that what you consider to be 'ad hoc' is superior to
having it wired into the language? Because when I want to 'morph text',
I want it to do it the way *I* want it to do it! I do *not* want to do
it the way the author of A-Code wants me to do it! I want the power to
customize! I don't want to be tied to a chair and have the language's
implementor dangle a feature in front of my eyes, telling me I can use
it but only if I need it in the exact way that he wants me to use it.
(Now, there are of course valid issues here; Inform sucks at handling
strings, and it would be sort of nice though rather hard to implement
and slow if TADS' vocab properties worked the same as all of the other
properties.)
--
David Glasser | gla...@iname.com | http://www.davidglasser.net/
rec.arts.int-fiction FAQ: http://www.davidglasser.net/raiffaq/
"So, is that superior artistry, or the easy way out?"
--TenthStone on white canvases as art, on rec.arts.int-fiction
Mike Arnautov
>> > "The factorial of 6 is <<factorial(6)>>. Isn't that exciting?";
>>
>> I guess this opens up the question: when is the function
>> call evaluated? When the string is printed?
>
>When the string is executed, yes.
Yes, that's handy and there have been some occasions when I wished A-
code could embed procedure calls in strings. Which it can't and it would
be hard to make it possible, give the structure of the language.
I hope you hear the "but" coming. :-) But, this is really only handy if
you are willing to start writing procedures, which in my experience most
people avoid in so far as they can. So your following example is a much
more likely one.
> "You see a candle here, <<self.islit ? "shining brightly" :
>self.isburntout ? "blackened and scorched" : "ready for use">>."
Fine. Now let's apply it to the simple text switch example from adv660,
which I already quoted in another post:
"[/A ball/Balls] of searing flame burst[/s/] out of your magic ring,
rebound[/s/] off of the ground, and vaporize[/s/] the kni[/fe/ves]
before [/it/they] can reach you."
Which would become
"<<knifeCount == 1 ? "A ball" : "Balls">> of searing flame
burst<<"knifeCount == 1 ? "s" : "">> out of your magic ring,
rebound<<knifeCount == 1 ? "s" : "">> off of the ground, and
vaporize<<knifeCount == 1 ? "s" : "">> the kni<<knifeCount == 1 ? "fe" :
"ves">> before <<knifeCount == 1 ? "it" : "they">> can reach you."
Aren't you beginning to see the value of a shorthand notation? :-)
Of course, being faced with something like that, any sensible writer
would shrug his shoulders and do simply
<<knifeCount == 1 ? "A ball of searing flame bursts out of your magic
ring, rebounds off the ground, and vaporizes the knife before it can
reach you." : "Balls of searing flame burst out of your magic ring,
rebound off the ground and vaporize the knives before they can reach
you.">>
Which duplication is fine (provided the author can be bothered) for a
one-off case. But as already noted, I have several hundred, and some of
them rather more complex than the above example. Consequently, I have no
doubt whatever that if your syntax were all that I had, I wouldn't have
bothered with most of the morphs I do actually have.
Which is what I mean by repeating that it being possible to do X in a
language Y, should not be confused with language Y supporting X.
>It is also perfectly feasible to do (as I have done with Sense.t) the
>following:
>
> "the <<self.sdescR>>."
>
>where sdescR is a method. You could, of course, embed a function with
>parameters passed from the local environment, etc.
Well, quite. I have good reasons to believe that most non-programmers
(and a number of programmers too) would find a text switch rather less
bother. No worries about parameters, local environment, embedded
functions, methods etc...
Sean T Barrett
>"Sean T Barrett" <buz...@world.std.com> wrote in message
>news:Fq33z...@world.std.com...
>[snip my description of need for closures in executable strings]
>
>Um. Do you mind putting that into english, professor?
Ok. Let's use C++ syntax here, for clarity, with function
calls inside the strings notated by << >>.
class UglyFoo
{
string my_sdesc;
string short_desc() { return my_sdesc; }
string cap_definite_short() { return "The "+short_desc(); }
string long_desc() { return "<<cap_definite_short>> is pretty ugly."; }
};
UglyFoo bar;
... some other code somewhere in a library ..
{
...
bar.my_sdesc = "bar";
...
desc = bar.long_desc();
print desc;
}
Ok, in english, the above code does the following: the short desc function
just returns the my_sdesc string. (It's a function so it can be overriden
by descendent classes.) cap_definite_short(), at call time, evaluates
short_desc, and concatenates the strings, yielding (in this case), "The bar".
Now, if we want strings that *don't* immediately evaluate their embedded
functions (which, for example, glulx supports), then after calling
bar.long_desc() above, desc should contain "<<cap_definite_short>> is pretty
ugly.", not "The bar is ugly".
Now, if we print desc, we want to evaluate the function 'cap_definite_short'
at print time. But cap_definite_short is a method invocation--it needs to
be called on some particular object. What object? At the time we 'built'
the string (in the long_desc) function, there was a particular context (a
hidden 'this' pointer that we could have used).
Suppose I have two UglyFoos, bar and baz. Now I run:
both_desc = bar.desc() + " " + baz.desc();
If the functions aren't immediately computed, then I end up with the
string "<<cap_definite_short>> is pretty ugly. <<cap_definite_short>> is
pretty ugly.". At this point, there's no way you're going to compute them
correctly.
Ok, now think about this: if we have a class, but not an object, we
have a piece of code, but we can't run it, because we don't really
have a valid 'this' pointer; we don't have an object context to run it
in. The strings above have the same problem; divorced of their implicit
'this' pointer, there's no more context for them.
The closure-style solution is to 'instantiate' the string, in the same
way the class is instantiated as an object; we need a little block of
data that says 'here's the string, and here's the particular context
it was created in that provides context for calling functions'. This
is exactly what closures are, but with functions instead of strings;
I'll explain in a bit. Let me just note that even with that, concatenation
is still going to be problematic; you actually still need to keep track
of the differing contexts for the children.
Ok, now why in the world do I *want* to defer function evaluation in strings.
Well, that post you're replying to was just to point out that while glulx
supported it, I'm not sure that it's that useful without closure-style
behavior, since you'll run into the above sorts of problems. But the reason
I was first thinking about this relates to something I posted about before,
namely the event-propogation in the mud I worked on, where events generated
text differently depending on how far they had propogated, and on who was
observing them. Let's just think about the latter, although this is obviously
more useful for muds (which have multiple viewers). But consider a
Suspended-style game where events which occur in a room with multiple
robots needs to get reported by each of them.
Here's the traditional single-player way of doing it, assuming functions
print strings rather than returning them:
... verb processing code ...
if (all_conditions_are_met) {
object.moveto(container);
print "You put ";
object.definite();
print " in ";
container.definite();
print ".";
}
Now, suppose NPCs use the same verb code as the player; we can't just blindly
say 'You', but need to print the name of the actor, or 'You':
... verb processing code ...
if (all_conditions_are_met) {
object.moveto(container);
actor.Name();
actor.VerbConjugate(" put ", " puts ");
object.definite();
print " in ";
container.definite();
print ".";
}
Ok, now just to shorten it up, let's assume these return strings instead
of printing them (or that this is a shorthand notation for the above):
... verb processing code ...
if (all_conditions_are_met) {
object.moveto(container);
print actor.Name(), actor.VerbConjugate(" put ", " puts "),
object.definite(), " in ", container.definite(), ".";
}
Ok, now we want to introduce multiple other viewpoints. The first problem
is that we need to print more than once. We can explicitly iterate over
everyone who can see the event, but writing out that iteration might be
complex, so putting it in every place that needs to print an event would
be gross; so it may be easier to simply move this print out to its own
function:
print_put_in_container(actor, object, container, viewer)
{
print actor.Name(viewer), actor.VerbConjugate(viewer, " put ", " puts "),
object.definite(viewer), " in ", container.definite(viewer), ".";
}
Since a viewer might be the object being put in the container, or the
container itself, the above allow for appropriate 'you' substitutions.
It also allows Suspended-style robots to have different names for the
same object.
Now, to use that given a function that calls a function with all the
viewers in a given area, we'd do something like this:
... verb processing code ...
if (all_conditions_are_met) {
object.moveto(container);
print_to_all_who_can_see(container, print_put_in_container);
}
Well, except that doesn't quite work, since we need to pass in the
parameters to print_put_in_container. If the language is decent,
you can probably do something like this:
... verb processing code ...
if (all_conditions_are_met) {
object.moveto(container);
list x = (actor, object, container);
print_to_all_who_can_see(container, print_put_in_container, x);
}
Here, conventionally, the 'print_to_all_who_can_see' always appends
the viewer to the end of the list before calling the function. (To
actually do this in C++, we'd have to change print_put_in_container
to take a list of parameters in an array, and change the print function
to reference the array, rather than take an arbitrary number of
parameters.
Unfortunately, I've moved the details of the print away from the
location it's used, and added a lot of extra work to pass around
the needed parameters. It would be nice if the compiler could just
do this for us. If we had the idealized function execution in
strings, I could just replace that whole mess with:
... verb processing code ...
if (all_conditions_are_met) {
object.moveto(container);
print_to_all_who_can_see(container,
"<<actor.Name(viewer)>> <<actor.verbConjugate(viewer, "put", "puts")>>"
" <<object.definite(viewer)>> in <<container.definite(viewer)>>.");
}
But it's hard to see how any language is going to be able to bind 'viewer'
correctly in the above sort of context.
On the other hand, languages that explicitly support closures allow you
to make this explicit; you can on-the-fly create a "new" function that
takes one argument (the viewer), and has the other parameters automatically
bound at execution time. (The parameter doesn't have to be named 'viewer';
the code will just require a function that takes one parameter):
... verb processing code ...
if (all_conditions_are_met) {
object.moveto(container);
func my_print(viewer) =
{
print actor.Name(viewer),actor.verbConjugate(viewer, " put ", " puts "),
object.definite(viewer), " in ", container.definite(viewer), ".";
};
print_to_all_who_can_see(container, my_print);
}
Note that I wouldn't even have to give my_print it's own name; I could
now just write, ok, let me shorten the darn names so this is vaguely
readable:
... verb processing code ...
if (all_conditions_are_met) {
obj.moveto(cont);
print_to_all(cont,
func(v) {
print act.Name(v), act.conj(v, " put ", " puts "),
obj.def(v), " in ", cont.def(v), ".";
}
);
}
I'm not saying in any way that that's *pretty*, but it's a heck of
a lot prettier than the alternatives.
Unfortunately, very few languages support closures, because they're
hard to support performance-wise. Closures should be first-class
data items, so, for example, I should be able to store my_print into
a global variable, and then return from this verb code. At that
point, if object and container were local variables, they'd have
been on the stack and been popped, but my_print would still refer
to them (it's not supposed to have its own copy of the variables,
for various reasons). Thus, the function variable frames can't
be stack allocated, but need to come from a general memory heap.
On the other hand, this sort of performance overhead is perfectly
acceptable for the interpreter performance we get from IF VMs anyway,
so I think it would be interesting to try to add them.
The MUD language I was using didn't support closures either. We
used a system which create dynamic lists on the fly, sort of its
own mini-interpreted language (interpreted by interpreted code,
yuck!); for example, here's a cut & paste of the code we used for
putting an object in a container:
o = new($visClass, list(
list($where, $def, player, " put", $conjug, player, " ",
$you, player, list($def, dobj), list($indef, dobj),
" in ", $you, player, list($def, iobj), list($indef, iobj), "."),
list($actMove, player, dobj, iobj)));
generateDescripton(o, player);
This system was hardcoded with particular parameters; opcodes like
'def' and 'conjug' paid attention to the viewer; things like 'where'
related to the propogation of the even across multiple rooms.
Ok, if anyone tries to read this in detail, here's what's going on.
The top level list contains two things: a list of how to human-print
it, and a list of how NPCs should interpret it (the 'actMove' list).
The human-print list uses the opcode 'where' to print where it's
happening if seen outside the original room (or in or out of a
container); $def will eventually print the definite-article-ified name
of the following object (in this case the player, that is the actor) as
seen by the viewer; $conjug adds an "s" potentially; $you determines if
the viewer is the specified object (in this case the actor), and
chooses one of the following lists to print; if the viewer is the actor,
it prints the definite version of the object, if not, it prints the
indefinite-article-ified version of the object. Similarly for the
destination.
So if I had a pet rat named Bob, and I put him in a barrel while John
is in the room with me and Fred is to the south, it would print:
me: You put Bob in the barrel.
John: Satoria puts Bob in a barrel.
Bob: Satoria puts you in a barrel.
Fred: Far to the north Satoria puts something in something.
Or if the game keeps track of relationships, *the exact same code* could print:
me: You put your pet rat Bob in the barrel.
John: Satoria puts a disgusting rat in a barrel.
Bob: Your owner puts you in your favorite barrel.
Fred: Far to the north Satoria puts something in something.
Please note, by the way, that, as I've said many times, I think this
level of simulation is probably more complexity than it's worth for
IF, especially as the task of 'writing text' gets turned into 'writing
grammar descriptions of text'. However, I think that (a) closures would
have other applicability, and (b) I'm suspicious of the utility of
glulx's strings with deferred-til-print-time function calls, because it
would take a hideous amount of work on the part of a compiler to use them
for anything more complex than the Z-machines global string substitutions
(which glulx already has better ways of doing).
SeanB
PS:
As I mentioned elsewhere, there were a number of ways to move multiple
objects out of a container (e.g. "fill from", "empty into"). Each of
these shared a common core code that decided where each object in
the container went, and then generate a "descripton" for it; however,
since it was common core code, it wanted different to allow different
descriptions depending on the caller, yet it needed to substitute
the object and target location in the description provided by a caller.
The code uses a hack--the caller passes in a description list as above,
but with several dummy values, and the common code searches for the
dummy values and substitutes them before generating the descripton.
With closures, the clients could have just defined a function that
takes three parameters--obj, target, and viewer; then the core code
could define a new function of one parameter, which is just that other
function, but now with obj & target bound:
MoveOut(container, descfunc(obj,target,viewer))
{
objectloop(x in container)
{
... compute y as destination for x ...
func my_func(viewer) = { return descfunc(x,y,viewer); }
generateDescripton(container, my_func);
}
}
I hope this is suggestive of the extensive utility of closures,
even if this is all still examples nobody would want to do in
single-person IF.
David Glasser
> "[/A ball/Balls] of searing flame burst[/s/] out of your magic ring,
> rebound[/s/] off of the ground, and vaporize[/s/] the kni[/fe/ves]
> before [/it/they] can reach you."
>
> Which would become
>
> "<<knifeCount == 1 ? "A ball" : "Balls">> of searing flame
> burst<<"knifeCount == 1 ? "s" : "">> out of your magic ring,
> rebound<<knifeCount == 1 ? "s" : "">> off of the ground, and
> vaporize<<knifeCount == 1 ? "s" : "">> the kni<<knifeCount == 1 ? "fe" :
> "ves">> before <<knifeCount == 1 ? "it" : "they">> can reach you."
>
> Aren't you beginning to see the value of a shorthand notation? :-)
You mean like
"<<m('A ball','Balls')>> of searing flame burst<<m('s',')>> out of your
magic ring, rebound<<m('s','')>> off of the ground, and
vaporize<<m('s',''>> the kni<<m('fe','ves')>> before <<m('it','they')>>
can reach you."
(where m can be anything you want.) And one can look at m's source code
to see what it does instead of guessing in the dark about what the
controlling variable is.
Kevin Forchione
> >self.isburntout ? "blackened and scorched" : "ready for use">>."
>
> Fine. Now let's apply it to the simple text switch example from adv660,
> which I already quoted in another post:
>
> rebound[/s/] off of the ground, and vaporize[/s/] the kni[/fe/ves]
> before [/it/they] can reach you."
The problem that I have with this example is that it does not seem to be
dependent upon an object's state. Unless there is some previous command that
determines what the text string is morphing on, we are simply presented with
a random return whose positional value is kept constant across the string.
Perhaps this is not quite the example you intended. But can you tell me, for
any given instance of execution, exactly what the displayed string will be
or under what conditions I might expect "Balls" rather than "A ball"?
> Which would become
>
> "<<knifeCount == 1 ? "A ball" : "Balls">> of searing flame
> burst<<"knifeCount == 1 ? "s" : "">> out of your magic ring,
> rebound<<knifeCount == 1 ? "s" : "">> off of the ground, and
> vaporize<<knifeCount == 1 ? "s" : "">> the kni<<knifeCount == 1 ? "fe" :
> "ves">> before <<knifeCount == 1 ? "it" : "they">> can reach you."
This would not behave exactly as the text morphing example you cite above.
For one thing, the format depends upon knifeCount which is probably
dependent upon actions that occur in the game. Granted that a more compact
notation would require the implementation of a function.
But I would be quite comfortable with this:
"<<tm('|A ball|Balls')>> of searing flame burst<<tm('s|')>>
out of your magic ring, rebound<<tm('s|')>> off of the ground, and
vaporize<<tm('s|')>> the kni<<tm('fe|ves')>> before
<<tm('it|they')>>
can reach you.\b";
This is the syntax required by the new tmorph.t TADS library extension I
whipped up tonight. The above syntax produces either
"A ball of searing flame burts out of your magic ring, rebounds off of the
ground, and vaporizes the knife before it can reach you."
or
"Balls of searing flame burst out of your magic ring, rebound off of the
ground, and vaporize the knives before they can reach you."
And can be initialised with either a random number corresponding the number
of morphing elements in the string, or with an state-related value, such as
knifeCount, as cited above. For anyone wishing to use it, the library
extension is now available on ftp://ftp.gmd.de/incoming/if-archive/tmorph.t
--Kevin
Kevin Forchione
news:#SlqM1Ff$GA.335@cpmsnbbsa03...
> "Mike Arnautov" <m...@mipmip.demon-co-antispam-uk> wrote in message > >
> "You see a candle here, <<self.islit ? "shining brightly" :
> > >self.isburntout ? "blackened and scorched" : "ready for use">>."
> >
> > Fine. Now let's apply it to the simple text switch example from adv660,
> > which I already quoted in another post:
> >
> > "[/A ball/Balls] of searing flame burst[/s/] out of your magic ring,
> > rebound[/s/] off of the ground, and vaporize[/s/] the kni[/fe/ves]
> > before [/it/they] can reach you."
tmorph20.t syntax, notice that this does not *appear* to be a function call,
nor are there any '' single-quoted strings or embedded commands...
"[|A ball/Balls/An enormous ball] of searing flame burst[s//s] out
of your magic ring, rebound[s//s] off of the ground, and
vaporize[s//s] the kni[fe/ves/fe] before [it/they/it]
can reach you.\b";
This produces a random display. For a sequential display you need to add an
initialiser name and value:
"[ringseq 2|A ball/Balls/An enormous ball] of searing flame
burst[s//s] out
of your magic ring, rebound[s//s] off of the ground, and
vaporize[s//s] the kni[fe/ves/fe] before [it/they/it]
can reach you.\b";
This will then set up a dynamically created object with the noun value
'ringseq' and a val of 2. Each time the initialiser portion of the text
switch is called it will advance the val, cycling to the beginning of the
list when necessary.
tmorph20.t takes advantage of TADS text formatter, so you can turn it on or
off at will. You can also modify the code, delimeters, etc as needed. To
base the display on game-state value you need to remove the initialiser '|'
portion and set the global.randomHold to the value you want:
global.randomHold = global.knifeCount;
"[A ball/Balls/An enormous ball] of searing flame burst[s//s] out
of your magic ring, rebound[s//s] off of the ground, and
vaporize[s//s] the kni[fe/ves/fe] before [it/they/it]
can reach you.\b";
--Kevin
Mike Arnautov
>> b)
I am interested to see that you don't comment on (a) :-)
>> move cloak to player;
>> give cloak worn;
>>
>> Why is that preferable to
>>
>> cloak.location = player;
>> appendTo (player.inventory, cloak);
>> cloak.worn = 1;
>
>It's not.
In such a case we disagree more profoundly than I'd thought. But I'll
return to that in a moment.
>> All of this can be done in any OO language, so why bother to invent
>> special notation?
>
>It's historical legacy from when Inform was barely more than a pretty
>assembler for Z-code. And I've considered Inform library rewrites that
>would switch over to that notation.
OK, let me re-phrase my question then. Assuming you do the rewrite using
that notation, and leaving aside the parser, what would be the advantage
of using Inform rather than just C++?
As for the more concise "wear" code not being preferable... By a
straightforward extension of the notion of the 3rd normal form in
database theory, since the three statements in the C++ idiom would
necessarily always come together, it is a good practice to subsume them
in a single statement, e.g. as
wear (player, cloak);
relieving the author of the need to perform the relevant house-keeping.
In fact I would further argue that to non-programmers the idiom of
player wears cloak;
would be preferable. Either way, the need for it is so ubiquitous that I
am sure you would agree the standard library should provide it. Well,
that's the essence of my argument for the explicit support of text
morphing (including "random messages", OK? :-) -- it reduces the amount
of housekeeping required and once available, is exceedingly handy.
Mike Arnautov
>OK, I wanted to stay out of this,
I am sorry to hear that.
>but I'm getting annoyed.
And even sorrier to hear that. No -- seriously. No irony intended.
Unfortunately I think your annoyance made you miss those of my examples
which I believe (rightly or wrongly) are a bit more problematic in TADS
than the one you have decided to respond to.
> So I'll say
>my thing, using TADS as an example.
>
>In TADS, one can do:
>
> ldesc = "The animal seems to be <<ANIMAL>>"
>(maybe you need parentheses after ANIMAL, but I don't think so)
Yes, I appreciate that. It never occurred to me when giving that very
first example, that everybody would latch on the morphing of object
descriptions, while ignoring the way the same technique can be applied
to all text, including random messages or vocabulary entries, despite
the vocabulary angle being explicitly present in that first example.
>In A-Code, I think you can do (I couldn't find a description of morphing
>on your website, sorry):
> "The animal seems to be {ANIMAL}."
No need to apologise. The description is embedded in the general A-code
document (http://www.mipmip.demon.co.uk/adv/acode.html -- look for
occurrences of the string "switch" -- and sorry, it is not entirely up
to date, you know how such things go :-). When writing it, I had not
appreciated that text morphing was something a bit unusual, which might
require a separate description.
But you seem to miss the point here. Your example as it stands is
nothing to do with text morphing. It is just text nesting, signalled in
A-code by the braces, and I that hardly qualifies as "morphing"! The
text morphing aspect comes in via the text associated with the tag
ANIMAL containing a text switch, which is automatically acted on by A-
code, according to the state of the object. Which gets annoyingly
complex if you try to implement in TADS an equivalent of (e.g.)
"[A ball/Balls] of searing flame burst[s/] out of your magic ring,
rebound[s/] off of the ground, and vaporize[s/] the kni[fe/ves]
before [it/they] can reach you."
How do you suggest this should be handled in TADS? In A-code such a text
would either have a default qualifier governing the actual choice of
text to be displayed, or if there is none (or you wish to override the
default one) you supply one explicitly as <text>,<qualifier> where the
qualifier can be anything delivering a value (which doesn't even have to
be within the bounds of the embedded switches -- they'll coerce the
value appropriately)
In the specific example, the text happens to be a description of the
object KNIFE (dwarves' knives vanish as they hit obstacles, remember?
:-), so the state of the object, which is the count of knives thrown,
acts as the implicit qualifier and the text is used simply as
SAY KNIFE
>OK, so syntax-wise there isn't much of a difference.
Unless I am missing something, there is. It is unclear to me how you
TADS example takes care of the name of the animal changing as the state
of the object changes. Yes, sure, it can be done by writing a procedure
called ANIMAL(), which would return the appropriate string. Or just
putting a complex conditional statement in the TADS description. But
that gets very annoying if there is a number of switches to be embedded
in a message. So, duplicate the whole message with those small
variations? Once you start getting lots of them, that also gets quite
painful.
>Now, why do I think that what you consider to be 'ad hoc' is superior to
>having it wired into the language? Because when I want to 'morph text',
>I want it to do it the way *I* want it to do it! I do *not* want to do
>it the way the author of A-Code wants me to do it! I want the power to
>customize!
Pardon? A-code morphing does not preclude you customising to your
heart's content. You don't *have* to use text switches and if you don't,
all text is just text, for you to manipulate to your heart's content.
What is wired into A-code is simply syntax for you to use or ignore.
What you do with it is entirely up to you. The only restriction it
imposes is that if you want the '[' character in your text, you have to
escape it as '\[' -- and even that could be done otherwise in a
different syntax for morphing.
Besides, I have found text switches to be extremely flexible. These days
I use them in preference to other techniques, which are still embedded
in my A-code sources as a legacy from Dave Platt's code, as well as my
own early A-code source.
> I don't want to be tied to a chair and have the language's
>implementor dangle a feature in front of my eyes, telling me I can use
>it but only if I need it in the exact way that he wants me to use it.
There is no "exact way" to use text switches. It is a general purpose
tool, which you can use in ways simple or complex or not at all. Do you
complain that a hammer only allows you to use it in the one exact way of
holding its handle and hitting things with its head?
You know, your objections remind me of the time assembler programmers
were complaining that 2nd generation languages would cramp their style
something shocking! :-)
Sean T Barrett
>Andrew Plotkin <erky...@eblong.com> wrote:
>>Mike Arnautov <m...@mipmip.demon-co-antispam-uk> wrote:
>>> move cloak to player;
>>> give cloak worn;
>>>
>>> Why is that preferable to
>>>
>>> cloak.location = player;
>>> appendTo (player.inventory, cloak);
>>> cloak.worn = 1;
>>
>>It's not.
>
>straightforward extension of the notion of the 3rd normal form in
>database theory, since the three statements in the C++ idiom would
>necessarily always come together, it is a good practice to subsume them
>in a single statement, e.g. as
>
>wear (player, cloak);
>
>relieving the author of the need to perform the relevant house-keeping.
There are two different things going on in this example; the splitting
of the 'move' into two steps, and the changing of the syntax from a
faux-english one to a C-style one. I imagine Zarf was commenting
just about the latter change, and not the former, given his comments
about changing the library *syntax*. One clearly doesn't
want to write the two instructions for 'move' every time one wants
to move an object, but of course all procedural languages let you
define your own procedures, so it's easy enough to create a
'moveto' procedure that does both steps, and then a wear function
that does all three; easy enough that having to even point it out
seems a bit silly.
Introduction of a faux english syntax like
>player wears cloak
may *seem* easier for beginners, but IMHO it just masks what's
going on under the hood--and will just cause confusion when the
name of an object is pluralized.
SeanB
David Glasser
I think I went a bit over the line. I apologize for getting so
frustrated.
However:
> Which gets annoyingly
> complex if you try to implement in TADS an equivalent of (e.g.)
>
> "[A ball/Balls] of searing flame burst[s/] out of your magic ring,
> rebound[s/] off of the ground, and vaporize[s/] the kni[fe/ves]
> before [it/they] can reach you."
You can always download the new tmorph.t and have (basically) that work,
though...
Mike Arnautov
>> "[/A ball/Balls] of searing flame burst[/s/] out of your magic ring,
>> rebound[/s/] off of the ground, and vaporize[/s/] the kni[/fe/ves]
>> before [/it/they] can reach you."
>
>The problem that I have with this example is that it does not seem to be
>dependent upon an object's state. Unless there is some previous command that
>determines what the text string is morphing on, we are simply presented with
>a random return whose positional value is kept constant across the string.
>Perhaps this is not quite the example you intended. But can you tell me, for
>any given instance of execution, exactly what the displayed string will be
>or under what conditions I might expect "Balls" rather than "A ball"?
Sure I can. I am sticking to generalities to avoid pushing A-code
notation at people, but if specifics of the existing implementation is
what you want, I am game. Please pardon the (optional) uppercase
convention -- it helps to separate code from text. To enhance
readability I'll make declarations a bit more verbose than A-code does
at present, but that's just cosmetics.
The above message can be used in three distinct ways. (I will use
<message> to stand for the message in its entirety.)
1. It can be the description of a dummy object FLAMEBALL (say):
OBJECT FLAMEBALL
HERE_YOU_SEE
<message>
...
RANDOM FLAMEBALL, DWARF
SAY FLAMEBALL
Dwarf is an object describing (via a text switch!) the dwarves
surrounding you -- 1 to 9 of them. Like all A-code objects, used in an
arithmetic context, it delivers the state (value) of the object -- which
in this case is the number of dwarves. The RANDOM directive sets the
state (value) of the object FLAMEBALL (also used in the arithmetical
context!) to a random number from 1 to the dwarf count. The SAY
directive, has FLAMEBALL used in the text context so it delivers a
description (by default the HERE_YOU_SEE one, which is why that was the
one I'd defined). Because this description has a text switch, and
because no explicit qualifier was supplied, the A-code rules state that
the state (value) of the argument is used to resolve the switch -- so
the appropriate message gets printed. (The switches in <message> only
have two states, the value will get coerced to the nearest available
switch element -- i.e. for values 2 and higher, the second element of
every switch gets printed.)
A bit awkward, unless you have other uses for the FLAMEBALL object.
2. You can have FLAMEBALL as a named text instead of a dummy object:
TEXT FLAMEBALL
<message>
...
RANDOM KNIFE.COUNT, DWARF
SAY FLAMEBALL, KNIFE.COUNT
This time the SAY directive has a second argument, which is treated as a
qualifier, whose value will be used to resolve any switches embedded in
the text delivered by the first argument. Of course, in a better
language you would be able to say simply
...
SAY FLAMEBALL (RANDOM DWARF)
and be done -- but as a programming language, A-code is pretty
primitive. :-) Also note that while A-code does not allow in-line text,
that's a matter of philosophical preference, not of a morphing
principle. If in-line text were supported you could replace all of the
above with
SAY <message>, (RANDOM DWARF)
(This is slightly artificial, in that you probably want to keep a
KNIFE.COUNT variable anyway for other purposes and have already probably
pre-computed it.)
3. While the current version of A-code can't handle this third
possibility, it would be quite easy to add it in -- so for the sake of
demonstrating principles, rather than A-code, I include that too:
TEXT FLAMEBALL, KNIFE.COUNT
<message>
...
RANDOM KNIFE.COUNT, DWARF
SAY FLAMEBALL
Now the KNIFE.COUNT variable is declared as the default qualifier to any
use of FLAMEBALL (which does not preclude you from overriding with an
explicit qualifier in any particular use of it). This would be useful if
the dependency is an obvious one and you need to keep a separate
KNIFE.COUNT variable for other purposes.
Does the above help? As you can see, it is too heavily dependent on the
specifics of A-code, which I have no intention to urge on anybody. hence
my preference for using a more abstract way of talking about morphing.
If implemented in another language, its use would have to be adapted to
the language in question.
>> Which would become
>>
>> "<<knifeCount == 1 ? "A ball" : "Balls">> of searing flame
>> burst<<"knifeCount == 1 ? "s" : "">> out of your magic ring,
>> rebound<<knifeCount == 1 ? "s" : "">> off of the ground, and
>> vaporize<<knifeCount == 1 ? "s" : "">> the kni<<knifeCount == 1 ? "fe" :
>> "ves">> before <<knifeCount == 1 ? "it" : "they">> can reach you."
>
>This would not behave exactly as the text morphing example you cite above.
>For one thing, the format depends upon knifeCount which is probably
>dependent upon actions that occur in the game.
I took that to be taken for granted that the code cannot read author's
mind. :-)
> Granted that a more compact
>notation would require the implementation of a function.
Quite so.
>But I would be quite comfortable with this:
>
> "<<tm('|A ball|Balls')>> of searing flame burst<<tm('s|')>>
> out of your magic ring, rebound<<tm('s|')>> off of the ground, and
> vaporize<<tm('s|')>> the kni<<tm('fe|ves')>> before
><<tm('it|they')>>
> can reach you.\b";
>
>This is the syntax required by the new tmorph.t TADS library extension I
>whipped up tonight.
That's fine, though the same applies -- you have to tell your tm()
procedure somehow which part of each switch to use. (Unless it is simply
wired into use by that particular message, of course!)
> The above syntax produces either
[the correctly morphed output]
>And can be initialised with either a random number corresponding the number
>of morphing elements in the string, or with an state-related value, such as
>knifeCount, as cited above.
So in fact you need another call which take the number of knifes thrown
and tells tm() to use that, until told otherwise. Such separation of
functionality can be troublesome, of course -- it makes quite feasible
to forget to make this initialising call, with consequences which may or
may not be obvious depending on the exact value of the previous
initialisation. To my mind, you'd do better to use
tm2 (<message>, knifeCount);
Much simpler! And getting closer to A-code morphing. But it doesn't deal
with implicit (overridable) qualifiers as described above, of course.
Also, can you use it in a vocabulary definition? And again, something
separate needs to be done to use this call if you want auto-incrementing
or randomising the embedded switches... Whereas if handled by the
kernel, the simple text-switch notation can do all of that. And the code
is *far* from complex. (Not to mention the possibility of switches being
parsed in compile/translate time if implemented in the kernel.)
> For anyone wishing to use it, the library
>extension is now available on ftp://ftp.gmd.de/incoming/if-archive/tmorph.t
I would suggest changing it to the simpler tm2() call noted above, with
the accompanying call tmi(<value>,<"method">) for doing implicit
qualifiers. Having done that, you'd bring text morphing to the masses.
(Well, a very near equivalent, anyway -- the vocabulary stuff excepted
:-)
Just one snag... Since it is not described in the language description,
you'll need to do a lot of publicising for it to get used. This has
nothing to do with how useful (or otherwise) the library is -- merely
with the fact that it doesn't get mentioned in the language
documentation.
Mike Arnautov
>tmorph20.t syntax, notice that this does not *appear* to be a function call,
>nor are there any '' single-quoted strings or embedded commands...
>
> "[|A ball/Balls/An enormous ball] of searing flame burst[s//s] out
> of your magic ring, rebound[s//s] off of the ground, and
> vaporize[s//s] the kni[fe/ves/fe] before [it/they/it]
> can reach you.\b";
>
>This produces a random display.
Ah, Much better! I am beginning to approve! :-)
[more examples snipped]
>tmorph20.t takes advantage of TADS text formatter, so you can turn it on or
>off at will. You can also modify the code, delimeters, etc as needed. To
>base the display on game-state value you need to remove the initialiser '|'
>portion and set the global.randomHold to the value you want:
>
> global.randomHold = global.knifeCount;
> "[A ball/Balls/An enormous ball] of searing flame burst[s//s] out
> of your magic ring, rebound[s//s] off of the ground, and
> vaporize[s//s] the kni[fe/ves/fe] before [it/they/it]
> can reach you.\b";
Congratulations! You *have* brought text morphing to the TADS masses.
I don't know enough about TADS -- can the above be used in any context
in which a string can be used? E.g. in descriptions, as part of another
string etc.? If so, A-code is no longer the only IF language having
this very useful feature, and to some extent I can consider my "mission"
accomplished. :-)
My concluding remarks from the previous reply still apply though. Unless
heavily publicised, it won't be used, whether or not it is useful. (Sean
Barrett finds his extension of Inform useful, with zilch interest from
elsewhere.)
Mike Arnautov
Sorry for the delays in replying... I have on-going technical problems.
:-(
David Glasser <gla...@iname.com> wrote:
>> "[/A ball/Balls] of searing flame burst[/s/] out of your magic ring,
>> rebound[/s/] off of the ground, and vaporize[/s/] the kni[/fe/ves]
>> before [/it/they] can reach you."
[....]
>You mean like
>
>"<<m('A ball','Balls')>> of searing flame burst<<m('s',')>> out of your
>magic ring, rebound<<m('s','')>> off of the ground, and
>vaporize<<m('s',''>> the kni<<m('fe','ves')>> before <<m('it','they')>>
>can reach you."
>
>(where m can be anything you want.) And one can look at m's source code
>to see what it does instead of guessing in the dark about what the
>controlling variable is.
Well, firstly, whether there is anything to look up in my approach to
things, is entirely up to the author. He can either tie the message to a
variable in declaring it, and then does not need to mention the variable
when using the message, or he can qualify the message with the variable
when (or whenever) it is used. (In the case of in-line messages, there
is of course no difference between these possibilities.)
Secondly, OK, let's *do* look at the m's source code, 'cause it appears
to be distinctly magical, leaving me guessing in the dark as to what it
might be doing. It somehow knows when to print the first argument and
when to print the second. Since it is unlikely to perform a telepathic
call to the author every time it gets called, I can see essentially
three different options:
1. It is ad hoc code, hardwired into the particular message. In essence
it does "print knifeCount == 1 ? arg1 : arg2". So in essence you have to
look up the controlling variable in the code, instead of in the message
declaration (same difference!), and you have to have a different version
for every message to be morphed by a distinct variable. Not too useful,
so I assume that's not what you had in mind.
2. You forgot to put in the second argument and what you *meant* to post
was "<<m(knifeCount, 'A ball','Balls')>> of searing flame...". Which
strikes me as no improvement on "<<knifeCount ? 'A ball' : Balls>> of
searing flame...". In fact it is worse, because using the m() call you
are left in the dark, guessing at the its functionality. So presumably
that's not what you meant either.
3. So perhaps you just forgot to mention the need to make a call to
another procedure (or the same procedure with other arguments), to
establish the controlling value to be knifeCount for all subsequent
calls of m(), until some other controlling variable gets specified? I.e.
now we have two procedures to look up to be sure what's going on. And,
of course, if anybody else wants to do the same, they have to write
their own two procs.
Still not beginning to see the advantages of a simple universal text
notation to be handled by the kernel? :-)
Gene Wirchenko
>Sean T Barrett <buz...@world.std.com> wrote:
>
>> One clearly doesn't
>>want to write the two instructions for 'move' every time one wants
>>to move an object, but of course all procedural languages let you
>>define your own procedures, so it's easy enough to create a
>>'moveto' procedure that does both steps, and then a wear function
>>that does all three; easy enough that having to even point it out
>>seems a bit silly.
>
>As I keep trying to point out, using that sort of logic leads to the
>conclusion that there is no need for any IF languages -- C++ and a
>parser library will do. All the rest is easy enough to implement by lots
>of little procedures of your own . Which seems a bit silly.
>
>>Introduction of a faux english syntax like
>>
>>>player wears cloak
>>
>>may *seem* easier for beginners, but IMHO it just masks what's
>>going on under the hood--and will just cause confusion when the
>>name of an object is pluralized.
>
>Yes, I remember well assembler programmers saying that about Fortran.
>And then Fortran Programmers (myself included :-) saying that about OO.
>But you know, most people don't care about what's under the hood. They
>just want to drive the car, preferably without having to customize it
>first.
But then most people don't write programs.
There is nothing quite like having invested alot of time and
effort (?and money) into a platform to then find that it can't cope
with <x> where x is something you want badly.
At least with doing it yourself, the quirks are your quirks and
you have a better chance of knowing of them and of being able to deal
with them.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
L. Ross Raszewski
<m...@mipmip.demon-co-antispam-uk> wrote:
>Yes, I remember well assembler programmers saying that about Fortran.
>And then Fortran Programmers (myself included :-) saying that about OO.
>But you know, most people don't care about what's under the hood. They
>just want to drive the car, preferably without having to customize it
>first.
>
>Mike Arnautov | From the heart
I'm nto sure I've ever liked this analogy. _I_ may not want ot know
what's undr the hod; but I'd sure as hell want the person who _built_
the car to know!
--
"Midnight Angel, won't you say you will?" -- Pat Benetar
Sean T Barrett
>Sean T Barrett <buz...@world.std.com> wrote:
>>Introduction of a faux english syntax like
>>
>>>player wears cloak
>>
>>may *seem* easier for beginners, but IMHO it just masks what's
>>going on under the hood--and will just cause confusion when the
>>name of an object is pluralized.
>
>just want to drive the car, preferably without having to customize it first.
Three points:
1) Your comment is irrelevent when something like 'worn' is implemented
in a library, since most people using the library don't have to understand
how the 'move' or 'wear' is implemented; this notion of 'black boxing'
of procedures is central to much of structured programming, e.g. explicitly
in the notion of 'abstract data types' (and hence
'object-oriented programming'). And this is almost entirely irrelevent
anyway since the point here was syntax, not functionality.
2) You ignore my point that 'player wears cloak' vs.
'bees wear cloak' requires your language automatically know how
to conjugate verbs, or else every time you declare a new operation
you have to explicitly conjugate it yourself. If I have a variable
that refers to an object that might be singular and might be plural,
should the syntax be 'variable wear[/s] cloak'?
3) My metaphor had nothing to do with automobiles.
SeanB
TenthStone
<m...@mipmip.demon-co-antispam-uk> wrote:
>Sean T Barrett <buz...@world.std.com> wrote:
>
>> One clearly doesn't
>>want to write the two instructions for 'move' every time one wants
>>to move an object, but of course all procedural languages let you
>>define your own procedures, so it's easy enough to create a
>>'moveto' procedure that does both steps, and then a wear function
>>that does all three; easy enough that having to even point it out
>>seems a bit silly.
>
>As I keep trying to point out, using that sort of logic leads to the
>conclusion that there is no need for any IF languages -- C++ and a
>parser library will do. All the rest is easy enough to implement by lots
>of little procedures of your own . Which seems a bit silly.
Well, that's a fairly accurate sum-up, although I would substitute
Java for C++ there, and also I'd mention that a parser and a decent
world model are large jobs on their own.
One big reason we have IF languages is portability concerns. I
can run the same z-code program on twenty different types of
systems without much trouble. Other systems -- TADS, Alan, Hugo --
are limited (for now) more or less to the major platforms, but the
point is still that C++ won't quite cut it. Unless you write the
purest Java code this side of Sun, Java won't really do either.
----------------
The Imperturbable TenthStone
tenth...@hotmail.com mcc...@gsgis.k12.va.us
TenthStone
<m...@mipmip.demon-co-antispam-uk> wrote:
>David Glasser <gla...@iname.com> wrote:
>>You can always download the new tmorph.t and have (basically) that work,
>>though...
>
>
>In so far as (a) such strings get to be acceptable anywhere that normal
>strings are (and I don't know enough TADS to judge)
Well, you've got a point there. Text morphing (as implemented in
the current tmorph.t) fails with constant strings -- but that's
probably not a particularly common use.
Arnautov Dr ML
Well, my Windows went belly-up a week ago in a really spectacular
fashion. I am now on Linux (and missing Turnpike :-).
TenthStone wrote:
> One big reason we have IF languages is portability concerns. I
> can run the same z-code program on twenty different types of
> systems without much trouble. Other systems -- TADS, Alan, Hugo --
> are limited (for now) more or less to the major platforms, but the
> point is still that C++ won't quite cut it.
That's where I start feeling smug. :-) A-code is implemented as a
translator to stand-alone ANSI C, not as a compiler. So a game written
in A-code is automatically near-universally portable. Last two ports of
adv660 I am aware of were to an HP hand-held and to Psion5. The former
reportedly just compiled and ran. The latter needed a minor fix to allow
for Psion's insistence on 4-byte boundary alignement for *all* objects.
In practice, I reckon that's as portable as they come.
(I'll be honest, though, there's still a cosmetic problem with the Psion
port, apparently.)
--
Mike Arnautov
mailto:m...@mipmip.demon.co.uk
http://www.mipmip.demon.co.uk/mipmip.html
Arnautov Dr ML
> 1) Your comment is irrelevent when something like 'worn' is implemented
> in a library, since most people using the library don't have to understand
> how the 'move' or 'wear' is implemented; this notion of 'black boxing'
> of procedures is central to much of structured programming, e.g. explicitly
> in the notion of 'abstract data types' (and hence
> 'object-oriented programming'). And this is almost entirely irrelevent
> anyway since the point here was syntax, not functionality.
Since I was the one asking the question, it seems reasonable that I
should know what my intended point was. :-) And the point was about
functionality, even if it got diverted to syntax. The intent was to
elicit the answer you have now given: such things should be implemented
in some (generally available, I hope) library. Now I can complete my
question. Why is this obvious for wearing things, but most replies
concerning morphing was (initially anyway) that you can always write a
bit of code to achieve that?
(Problems with attempting a Socratic dialogue technique on USENET cannot
be underestimated. :-)
> 2) You ignore my point that 'player wears cloak' vs.
> 'bees wear cloak' requires your language automatically know how
> to conjugate verbs, or else every time you declare a new operation
> you have to explicitly conjugate it yourself. If I have a variable
> that refers to an object that might be singular and might be plural,
> should the syntax be 'variable wear[/s] cloak'?
I ignored it because it struck me as as having no weight. As a matter of
pragmatic implementation I would make "wear" and "wears" synonymous (or
more precisely allow "wears" to be abbreviated to the minimal unambigous
length), thereby allowing those who insist on being grammatically
correct, to be so.
> 3) My metaphor had nothing to do with automobiles.
References to things "going on under the hood" are car metaphors. I
merely contiued your metaphor. But if you insist, I'll translate: most
people using software prefer not to dig below the immediately available
surface. I speak from extensive experience here. :-)
Arnautov Dr ML
> >Yes, I remember well assembler programmers saying that about Fortran.
> >And then Fortran Programmers (myself included :-) saying that about OO.
> >But you know, most people don't care about what's under the hood. They
> >just want to drive the car, preferably without having to customize it
> >first.
>
> I'm nto sure I've ever liked this analogy. _I_ may not want ot know
> what's undr the hod; but I'd sure as hell want the person who _built_
> the car to know!
Well, I certainly would expect the author of an IF authoring system to
know what is "under the hood". I equally certainly would expect a
majority of its users not wishing to be bothered. That's assuming that
the use of the system in question is not restricted to a small circle of
"real programmers", of course. :-)
Kevin Forchione
news:38C17EE8...@mipmip.demon.co.uk...
> (Problems with attempting a Socratic dialogue technique on USENET cannot
> be underestimated. :-)
Socratic dialogue was only successfully employed by its originator. Most
modern debators using this approach come off as smug and arrogant. It's not
a fault of the USENET, per se, people generally don't take to the idea that
they are being deliberately manipulated toward a conclusion through an
approach that proclaims in all humility to be in search of wisdom, while at
the same time asserting to be issued by the wisest man in all of athens.
Questions should probably be left for knowledge-gathering, not for leading
others to realisations that they "already know."
Crito, we ought to offer a cock to Asclepius. See to it, and don't forget.
--Kevin
Andrew Plotkin
> "Arnautov Dr ML" <m...@mipmip.demon.co.uk> wrote in message
> news:38C17EE8...@mipmip.demon.co.uk...
>> (Problems with attempting a Socratic dialogue technique on USENET cannot
>> be underestimated. :-)
>
> Socratic dialogue was only successfully employed by its originator. Most
> modern debators using this approach come off as smug and arrogant.
Some people would say that the originator was no exception.
Mike Arnautov
> > (Problems with attempting a Socratic dialogue technique on USENET cannot
> > be underestimated. :-)
>
> Socratic dialogue was only successfully employed by its originator.
We don't know that it was, actually. All we have are reports of a
self-confessed admirer.
> Most
> modern debators using this approach come off as smug and arrogant.
I wouldn't presume to speak for most modern debators. :-)
> It's not
> a fault of the USENET, per se, people generally don't take to the idea that
> they are being deliberately manipulated toward a conclusion through an
> approach that proclaims in all humility to be in search of wisdom, while at
> the same time asserting to be issued by the wisest man in all of athens.
Humility? Where? Oh... You've been reading Plato again... Seriously,
though, USENET present a particular challenge in that on the one hand
many responses are fired off quicker than they ought to be (making the
Socratic approach useful), while on the other, the subject drift is very
hard to control (making the approach exceptionally difficult).
> Questions should probably be left for knowledge-gathering, not for leading
> others to realisations that they "already know."
That's only true if you assume that we are all at all times fully aware
of everything that we know or ought to know. Nobody is that perfect.
Magnus Olsson
Andrew Plotkin <erky...@eblong.com> wrote:
>Kevin Forchione <Lys...@email.msn.com> wrote:
>> "Arnautov Dr ML" <m...@mipmip.demon.co.uk> wrote in message
>> news:38C17EE8...@mipmip.demon.co.uk...
>>> be underestimated. :-)
>>
>> modern debators using this approach come off as smug and arrogant.
>
At least to some people. After all, Socrates managed to infuriate
people to the extent that he was sentenced to death - not by a jury,
but by an overwhelming majority of all voters.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
J Walrus
Mike Arnautov <m...@mipmip.demon.co.uk> wrote in message
news:38C29C6B...@mipmip.demon.co.uk...
> Seriously,
> though, USENET present a particular challenge in that on the one hand
> many responses are fired off quicker than they ought to be (making the
> Socratic approach useful)
Ouch! Painfully true.
Jw
(Please tell me I'm not the only one.)
Matthew T. Russotto
Kevin Forchione <Lys...@email.msn.com> wrote:
}"Arnautov Dr ML" <m...@mipmip.demon.co.uk> wrote in message
}news:38C17EE8...@mipmip.demon.co.uk...
}> (Problems with attempting a Socratic dialogue technique on USENET cannot
}> be underestimated. :-)
}
}Socratic dialogue was only successfully employed by its originator.
Who had the advantage of controlling both sides of the dialog.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Matthew T. Russotto
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
}In article <89u67i$n6h$1...@nntp3.atl.mindspring.net>,
}Andrew Plotkin <erky...@eblong.com> wrote:
}>
}>Some people would say that the originator was no exception.
}
}At least to some people. After all, Socrates managed to infuriate
}people to the extent that he was sentenced to death - not by a jury,
}but by an overwhelming majority of all voters.
That's the cover story. Fact is, he just heard one of the Lady
Astor/Winston Churchill quips, and thought it was a good idea.
Lady Astor: "Winston, if you were my husband I'd put poison in your tea"
Churchill: "Lady, if you were my wife, I'd drink it".
Kevin Forchione
news:mMCw4.10269$JQ.6...@monger.newsread.com...
> In article <eO7QmLsh$GA.266@cpmsnbbsa02>,
> Kevin Forchione <Lys...@email.msn.com> wrote:
> }Socratic dialogue was only successfully employed by its originator.
>
> Who had the advantage of controlling both sides of the dialog.
Quite right!
--Kevin
Jon Zeppieri
"Kevin Forchione" <Lys...@email.msn.com> wrote:
> "Matthew T. Russotto" <russ...@wanda.vf.pond.com> wrote in message
> news:mMCw4.10269$JQ.6...@monger.newsread.com...
> > In article <eO7QmLsh$GA.266@cpmsnbbsa02>,
> > Kevin Forchione <Lys...@email.msn.com> wrote:
> > }Socratic dialogue was only successfully employed by its originator.
> >
> > Who had the advantage of controlling both sides of the dialog.
>
> Quite right!
>
> --Kevin
>
>
Quite wrong. Socrates (of course) invented Socratic dialogue. Plato
controlled both sides of *what we know* about the dialogues.
Sent via Deja.com http://www.deja.com/
Before you buy.
Kevin Forchione
news:8a21k2$v2e$1...@nnrp1.deja.com...
>
> Quite wrong. Socrates (of course) invented Socratic dialogue. Plato
> controlled both sides of *what we know* about the dialogues.
Yes, you're right about that. I suppose I should be a little more pedantic
in my answers -- some of us are students of philosophy after all.
--Kevin
edr...@my-deja.com
Arnautov Dr ML <m...@mipmip.demon.co.uk> wrote:
> Sean T Barrett wrote:
>
> > 1) Your comment is irrelevent when something like 'worn' is
> > implemented in a library, since most people using the library don't
> > have to understand how the 'move' or 'wear' is implemented; this
> > notion of 'black boxing' of procedures is central to much of
> > structured programming, e.g. explicitly in the notion of 'abstract
> > data types' (and hence 'object-oriented programming'). And this is
> > almost entirely irrelevent anyway since the point here was syntax,
> > not functionality.
>
> Since I was the one asking the question, it seems reasonable that I
> should know what my intended point was. :-) And the point was about
> functionality, even if it got diverted to syntax. The intent was to
> elicit the answer you have now given: such things should be
> implemented in some (generally available, I hope) library. Now I can
> complete my question. Why is this obvious for wearing things, but
> most replies concerning morphing was (initially anyway) that you can
> always write a bit of code to achieve that?
Most likely because, at one time, it *wasn't* obvious for wearing
things -- until somebody figured out that the answer was to write a
little bit of code for it, then package it in a standard library so
that people can use it without having to worry about all the fiddly
bits inside.
The same could just as easily be done with text-morphing, it seems.
-M.
TenthStone
Correct me if I'm wrong, but this approach seems to require its
end-users (i.e. players) to either 1) have a compiler or 2) find a
pre-compiled version of the distribution for their system, which
is not likely (who wants to recompile 20 different ports each time
they make a minor update?). If it's 1, then any writer is restricting
his audience, since even those who people capable of compiling
don't necessarily enjoy doing it when they don't have to.
John W. Kennedy
>
> "Arnautov Dr ML" <m...@mipmip.demon.co.uk> wrote in message
> news:38C17EE8...@mipmip.demon.co.uk...
> > (Problems with attempting a Socratic dialogue technique on USENET cannot
> > be underestimated. :-)
>
Hmmm.... That's debatable.
> Most
> modern debators using this approach come off as smug and arrogant.
Yup, definitely debatable.
--
-John W. Kennedy
-rri...@ibm.net
Compact is becoming contract
Man only earns and pays. -- Charles Williams