How to Model Object Interactions
Daryl McCullough
enough about TADS to say one way or the other) is the model for object
interaction.
The original Inform (up to and including Inform 6) had a "phase"
structure, in which things took place in phases, and objects have
the opportunity to alter the course of events at various points.
If I remember correctly, it works something like this: Every time
there is an action attempted, the following things happen:
1. The room's "before" routine is checked.
2. For each object in the room, the "react_before" routine is checked.
3. For the first noun mentioned in the action, the "before" routine
is checked.
4. The Library's response is checked.
5. The first noun's "after" routine is checked.
6. Every other object's "react_after" routine is checked.
7. I can't remember whether the room itself has an "after" routine.
This sequence is complicated enough, but it becomes even more complicated
in certain cases:
8. If the action is something like "Eat", and the first noun is not in
the possession of the player, then an implicit "Take" action is tried
first.
9. Some actions, such as "Throw" can generate other "fake" actions,
such as "ThrownAt" (I think the use of fake actions is discouraged
these days).
10. Messages to the player can be printed at any stage.
This structure worked fine for most normal cases, but it was
*extremely* hard to get everything right in more complicated
cases. Maybe I'm just slow-witted, but my games were always
having bugs in which things happen in the wrong order. Impossible
actions would take place because the "check" happened too late.
Or an implicit Take would succeed even though the action that
generated it didn't make sense in context.
Inform 7 tries to impose a little more order on this mess, but
I'm not convinced that it actually succeeds. There are still
confusing distinctions (Instead, Check, Report, Carryout, etc.)
I'm not exactly sure what model of interaction would be better,
but I would like to start a thread to discuss possibilities.
One model that occurs to me is something like a queue of events.
This queue can be added to by player actions, or by demons, or
timers, or whatever. For each item in the queue, there would
be some notion of "subscribers" which are objects that are
interested in knowing about that item. The subscribers would
be allowed to remove events, add events, or substitute new
events, and would be allowed to change their own state based
on the events that they see. Sending output to the player might
itself be an event.
There is a certain sense in which this approach has all the
messiness of the original system, but maybe it could be made
so that it is *uniform* messiness.
--
Daryl McCullough
Ithaca, NY
Jim Aikin
knowledgeable than I about this level of system design.
> 8. If the action is something like "Eat", and the first noun is not in
> the possession of the player, then an implicit "Take" action is tried
> first.
> 9. Some actions, such as "Throw" can generate other "fake" actions,
> such as "ThrownAt" (I think the use of fake actions is discouraged
> these days).
> 10. Messages to the player can be printed at any stage.
...and at many points along the way, the programmer can abort or start a new
action.
> This structure worked fine for most normal cases, but it was
> *extremely* hard to get everything right in more complicated
> cases. Maybe I'm just slow-witted, but my games were always
> having bugs in which things happen in the wrong order. Impossible
> actions would take place because the "check" happened too late.
> Or an implicit Take would succeed even though the action that
> generated it didn't make sense in context.
I have the vague impression that most programmers sit with a pot of glue
beside their keyboard, for gluing back the tufts of hair they've pulled out
while chasing down bugs of this sort. I certainly do. So no, I wouldn't say
you're slow-witted, but I would say that the notion of a model world as it
exists in IF is inherently complex and inherently messy. It may be expecting
too much to hope for a system that will iron out all of the potential snags.
> I'm not exactly sure what model of interaction would be better,
> but I would like to start a thread to discuss possibilities.
> One model that occurs to me is something like a queue of events.
> This queue can be added to by player actions, or by demons, or
> timers, or whatever. For each item in the queue, there would
> be some notion of "subscribers" which are objects that are
> interested in knowing about that item. The subscribers would
> be allowed to remove events, add events, or substitute new
> events, and would be allowed to change their own state based
> on the events that they see. Sending output to the player might
> itself be an event.
This may be an interesting or fruitful model, but it strikes me that
normally there's only one user-generated action in the queue, that being the
result of the current input command. It doesn't stay in the queue very long,
because it's processed immediately. I think the list of "subscribers" is
already handled in I6 and T2/3 -- it's the object (and second object, if
any) of the command, plus everything that's in scope.
The I6 and T3 libraries do more or less what you're talking about: They
proceed through the list of subscribers (which is automatically generated),
asking each in turn whether it would like to interfere with or respond to
the event.
The one thing that, if I recall correctly, I6 doesn't do (and I'll bet T3
does, because I have yet to find anything it won't do) is allow you to
specify the order in which react_before is called for the various objects in
scope. You didn't mention that in your sketch, but it would be a logical
idea ... though of limited utility, of course. Maybe one game in 20 would
need such a feature, and that in only one particular room in response to one
particular action.
With respect to adding daemon actions to such a queue, I guess I'm curious
about how and when that would be useful, in your view. Most of my daemons
are pretty self-contained little critters. They operate strictly within the
domain of their own object (moving an NPC from place to place being the
obvious example).
Can you be more specific about your idea? What problems are you encountering
that an alternate approach would solve?
--Jim Aikin
Daryl McCullough
>> I'm not exactly sure what model of interaction would be better,
>> but I would like to start a thread to discuss possibilities.
>> One model that occurs to me is something like a queue of events.
>> This queue can be added to by player actions, or by demons, or
>> timers, or whatever. For each item in the queue, there would
>> be some notion of "subscribers" which are objects that are
>> interested in knowing about that item. The subscribers would
>> be allowed to remove events, add events, or substitute new
>> events, and would be allowed to change their own state based
>> on the events that they see. Sending output to the player might
>> itself be an event.
>
>This may be an interesting or fruitful model, but it strikes me that
>normally there's only one user-generated action in the queue, that being the
>result of the current input command.
Yes, sort of. But if the command involves implicit subactions
(for example, Eat implies Take) then those subactions would be
in the queue, as well.
>It doesn't stay in the queue very long,
>because it's processed immediately. I think the list of "subscribers" is
>already handled in I6 and T2/3 -- it's the object (and second object, if
>any) of the command, plus everything that's in scope.
Yes, the subscribers is a way of looking at what Inform does
already.
>The I6 and T3 libraries do more or less what you're talking about: They
>proceed through the list of subscribers (which is automatically generated),
>asking each in turn whether it would like to interfere with or respond to
>the event.
But only at the particular entry points mentioned. The queue idea
would allow things to be inserted more flexibly.
>The one thing that, if I recall correctly, I6 doesn't do (and I'll bet T3
>does, because I have yet to find anything it won't do) is allow you to
>specify the order in which react_before is called for the various objects in
>scope. You didn't mention that in your sketch, but it would be a logical
>idea ... though of limited utility, of course. Maybe one game in 20 would
>need such a feature, and that in only one particular room in response to one
>particular action.
I think that bugs of the type I'm talking about show up in almost every
game. Maybe there is a finite list of types of cases that could be solved
once and for all, and then everybody could just use those solutions.
>With respect to adding daemon actions to such a queue, I guess I'm curious
>about how and when that would be useful, in your view. Most of my daemons
>are pretty self-contained little critters. They operate strictly within the
>domain of their own object (moving an NPC from place to place being the
>obvious example).
Okay, take that example. What if the room has a "before" routine governing
people entering and leaving the room? Then there would be an interaction
between your demon and the room. Such interactions could become more
complicated.
One kind of demon that I've worked on is the movement of animals, such
as birds. Each turn, the bird would land, or take, or whatever, and these
actions would interact with actions taken by the player (such as when
the player tries to feed the bird, or throws a rock at it, or something).
So the normal way things are done, some of the same kind of "logic" has
to be split between "before/after/react_before/react_after" routines and
"each_turn" routine. I'd rather just specify how the bird reacts to
the current situation, and not worry about whether that should go into
"before" or "each_turn" (or a demon, or a timer).
Basically, I'd like to have a unified way of talking about
player actions, before, react_before, after, react_after, each_turn,
timers, demons, etc.
Jim Aikin
news:erpst...@drn.newsguy.com...
>>
>>This may be an interesting or fruitful model, but it strikes me that
>>normally there's only one user-generated action in the queue, that being
>>the
>>result of the current input command.
>
> Yes, sort of. But if the command involves implicit subactions
> (for example, Eat implies Take) then those subactions would be
> in the queue, as well.
That's true, but I guess it's not clear to me exactly how that would make
programming easier.
To be sure, you only posited the action queue as one example of alternate
possibilities for handling actions. The thing that I'm wondering is, exactly
what problem are you trying to solve?
A computer is an incredibly stupid box of metal and plastic. Absolutely
_everything_ that it does has to be specified, in absolute detail, by some
human somewhere along the line. I have the vague impression that you're
hoping a different algorithm for handling player commands will relieve you
of the burden of having to think through the precise steps that will
transpire when the library attempts to interpret the command. Maybe I'm not
doing justice to your vision ... but if that's what you're hoping for, I
suspect you're destined to be disappointed.
At least, at the point where you want to do anything nonstandard in the
model world you'll be disappointed. A good library can, in theory, handle a
lot of stuff for you, relieving you of the burden, but a library can only do
meat-and-potatoes stuff. Once you try to add anything tricksy to your game,
you're back in the land of squashing bugs.
>>The I6 and T3 libraries do more or less what you're talking about: They
>>proceed through the list of subscribers (which is automatically
>>generated),
>>asking each in turn whether it would like to interfere with or respond to
>>the event.
>
> But only at the particular entry points mentioned. The queue idea
> would allow things to be inserted more flexibly.
Ermm.... Can you give a couple of examples of flexible insertion? TADS 3
goes through about ten steps in interpreting standard actions, starting with
the room's beforeAction routine and proceeding through, among other steps,
any preconditions, verification, checking, and finally action for both the
direct object and the indirect object. In the case where things are being
moved from place to place, notifyRemove is called on the old container, then
notifyInsert on the new container. Where exactly would you like to be able
to insert an additional entry point?
> I think that bugs of the type I'm talking about show up in almost every
> game. Maybe there is a finite list of types of cases that could be solved
> once and for all, and then everybody could just use those solutions.
Maybe. I'm skeptical.
> Okay, take that example. What if the room has a "before" routine governing
> people entering and leaving the room? Then there would be an interaction
> between your demon and the room. Such interactions could become more
> complicated.
I'd have to look through the T3 library to find out exactly what method is
used in this situation, but of course there's bound to be one, quite
possibly the room-specific version of notifyInsert. Both Rooms and
TravelConnectors can specify conditions in which travel is allowed, or not.
It's up to the programmer to use the llibrary routines, but they're there.
> One kind of demon that I've worked on is the movement of animals, such
> as birds. Each turn, the bird would land, or take, or whatever, and these
> actions would interact with actions taken by the player (such as when
> the player tries to feed the bird, or throws a rock at it, or something).
> So the normal way things are done, some of the same kind of "logic" has
> to be split between "before/after/react_before/react_after" routines and
> "each_turn" routine. I'd rather just specify how the bird reacts to
> the current situation, and not worry about whether that should go into
> "before" or "each_turn" (or a demon, or a timer).
But you'll ALWAYS have to worry about that. No matter how the library sets
it up (react_before and then each_turn, or each_turn followed by
react_before), something will come first and something else will come after
that, and the order in which those steps are taken may turn out to be wrong
in any specific game situation you're trying to set up.
> Basically, I'd like to have a unified way of talking about
> player actions, before, react_before, after, react_after, each_turn,
> timers, demons, etc.
I can see that that might be useful. But "unified" is a big, puffy concept.
An action might involve as many as five or six game objects. For instance,
"throw the rock-hard bagel at the troll" of necessity involves the player
character (whose arms might be tied), the bagel, the troll, the breadbox in
which the bagel currently resides, and the room in which the bagel might
land after bouncing harmlessly off of the troll -- plus the thieving raven
perched on the jewel chest, who might snatch the bagel in mid-air, and the
jewel chest itself, which happens to have a spring-loaded lid that pops up
when the raven takes flight, thereby releasing the giant styrofoam snake
coiled inside, which frightens the raven, who lets go of the bagel, which
drops straight into the bottomless chasm....
Even if the library were to provide a unified method of handling the raven's
ravenousness (sorry...) when flying foods present themselves, we still would
need to program by hand the question of whether the raven takes flight and
snags the bagel before or after the troll sneers at the player's feeble
attack and whacks off the player's hand with his axe. Spending three hours
alpha-testing and bugfixing this one action is not unreasonable, and
probably not avoidable. TANSTAAFL.
(Gotta use that scene in a game sometime.)
--JA
Daryl McCullough
>A computer is an incredibly stupid box of metal and plastic. Absolutely
>_everything_ that it does has to be specified, in absolute detail, by some
>human somewhere along the line...
Yes. I want *more* control in the way these things happen. But
the way I would like to be able to do it is by describing, for
each object, how that object reacts to its surroundings, rather
than thinking in terms of phases.
>> One kind of demon that I've worked on is the movement of animals, such
>> as birds. Each turn, the bird would land, or take, or whatever, and these
>> actions would interact with actions taken by the player (such as when
>> the player tries to feed the bird, or throws a rock at it, or something).
>> So the normal way things are done, some of the same kind of "logic" has
>> to be split between "before/after/react_before/react_after" routines and
>> "each_turn" routine. I'd rather just specify how the bird reacts to
>> the current situation, and not worry about whether that should go into
>> "before" or "each_turn" (or a demon, or a timer).
>
>But you'll ALWAYS have to worry about that.
Why do you say that?
>No matter how the library sets it up (react_before and then each_turn,
>or each_turn followed by react_before), something will come first and
>something else will come after that, and the order in which those
>steps are taken may turn out to be wrong in any specific game
>situation you're trying to set up.
That's why I want *more* control over such orderings. I want the
ordering to be controlled by properties of objects, rather than by
a fixed phase structure.
>> Basically, I'd like to have a unified way of talking about
>> player actions, before, react_before, after, react_after, each_turn,
>> timers, demons, etc.
>
>I can see that that might be useful. But "unified" is a big, puffy concept.
>An action might involve as many as five or six game objects. For instance,
>"throw the rock-hard bagel at the troll" of necessity involves the player
>character (whose arms might be tied), the bagel, the troll, the breadbox in
>which the bagel currently resides, and the room in which the bagel might
>land after bouncing harmlessly off of the troll -- plus the thieving raven
>perched on the jewel chest, who might snatch the bagel in mid-air, and the
>jewel chest itself, which happens to have a spring-loaded lid that pops up
>when the raven takes flight, thereby releasing the giant styrofoam snake
>coiled inside, which frightens the raven, who lets go of the bagel, which
>drops straight into the bottomless chasm....
And?
>Even if the library were to provide a unified method of handling the raven's
>ravenousness (sorry...) when flying foods present themselves, we still would
>need to program by hand the question of whether the raven takes flight and
>snags the bagel before or after the troll sneers at the player's feeble
>attack and whacks off the player's hand with his axe. Spending three hours
>alpha-testing and bugfixing this one action is not unreasonable, and
>probably not avoidable. TANSTAAFL.
I think somehow you got exactly the wrong impression. I want *more*
control over object interactions, not less.
Andrew Plotkin
>
> That's why I want *more* control over such orderings. I want the
> ordering to be controlled by properties of objects, rather than by
> a fixed phase structure.
This is more or less where I came in, although I don't have any strong
desire to use properties of objects. (Not model-world objects, I
mean.)
I still think that some grouping model will free you from the need to
specify every ordering detail in the common case. That is, you will
want to talk about *groups* of effects -- all the library code, all
the implicit actions, all actions applying to liquids, all the actions
in the dark, etc etc. And that will let you get most of you want in a
few (powerful) declarations, with smaller adjustments as needed.
If I had some demonstration of this model, I'd feel a lot better about
it...
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because you're innocent.
Jim Aikin
> Yes. I want *more* control in the way these things happen. But
> the way I would like to be able to do it is by describing, for
> each object, how that object reacts to its surroundings, rather
> than thinking in terms of phases.
The only sensible way to think about programming, it seems to me, is in
terms of which functions get executed when. As a game author, you have to
understand that process. Whether it's conceptualized in phases like
react_before and each_turn or in some other manner is one of the fundamental
things a library designer has to grapple with.
What I've been trying, in my usual ham-handed way, to suggest is that if
there are five objects in a room, writing code for each object that will
determine how it reacts to its surroundings leaves you with the problem of
which object will get the first shot at the queue. It also, now that I think
of it, smushes together the finely articulated model used in most current IF
libraries, which is that each object has SEVERAL opportunities to react to
anything going on in the vicinity.
I don't think it would be a good idea at all to try to slam all of those
opportunities (react_before, before, each_turn, daemon, etc.) into one code
block. That sounds to me like a recipe for worse confusion.
>>> One kind of demon that I've worked on is the movement of animals, such
>>> as birds. Each turn, the bird would land, or take, or whatever, and
>>> these
>>> actions would interact with actions taken by the player (such as when
>>> the player tries to feed the bird, or throws a rock at it, or
>>> something).
>>> So the normal way things are done, some of the same kind of "logic" has
>>> to be split between "before/after/react_before/react_after" routines and
>>> "each_turn" routine. I'd rather just specify how the bird reacts to
>>> the current situation, and not worry about whether that should go into
>>> "before" or "each_turn" (or a demon, or a timer).
>>
>>But you'll ALWAYS have to worry about that.
>
> Why do you say that?
Because, as noted in an earlier post, a computer is an incredibly stupid
object. You have to specify _everything_ that it will do, in minute detail.
Putting something in an action queue rather than in a before or each_turn
block will not eliminate the need to think about the order of execution.
> That's why I want *more* control over such orderings. I want the
> ordering to be controlled by properties of objects, rather than by
> a fixed phase structure.
Okay, this makes sense. What I think perhaps you're envisioning is, for
instance, something like this: Each object has a react_before_weight, which
has a default of, let's say, 100. But the author can set this value to a
higher or lower number, as needed. When it's time for the library to iterate
through the objects in scope, asking each of them whether it wants to
react_before a given action, it (the library) begins by creating a list of
the objects whose react_before functions are to be called, and then juggles
the list into an ordered list based on the values of those objects'
react_before_weight values. This would allow the game author to insure that
an important react_before was called FIRST.
Is that what you're envisioning?
It still requires you to think in phases, because the after functions won't
be called until everything else has been handled. Another way to do it would
be to give each object a response_weight property. The library would build a
list of the objects in scope, order the list based on the values of this
property, and then call ALL of the functions of the object that had the
highest value for its response_weight. But I don't think I like that idea.
It seems to open the door for many more programming errors. The raven wants
to snatch the flying bagel before it hits the troll -- but the troll has a
higher response_weight, so it gets to react to the throwing of the bagel
before the raven.
Rather than trying to pack all of this functionality into a response_weight
property, I think it's probably better to do it by hand.
Or, you could write your own library for Inform or TADS. Go for it!
--JA
Daryl McCullough
>"Daryl McCullough" <stevend...@yahoo.com> wrote in message
>news:erqvh...@drn.newsguy.com...
>
>> Yes. I want *more* control in the way these things happen. But
>> the way I would like to be able to do it is by describing, for
>> each object, how that object reacts to its surroundings, rather
>> than thinking in terms of phases.
>
>The only sensible way to think about programming, it seems to me, is in
>terms of which functions get executed when.
I guess I'm disputing exactly that claim. As I said, if I'm programming
the behavior of a bird, then it seems to me that what I need to keep
track of is (1) what events can affect the bird, (2) what the bird's
responses to those events should be, and (3) what events the bird can
generate.
>What I've been trying, in my usual ham-handed way, to suggest is that if
>there are five objects in a room, writing code for each object that will
>determine how it reacts to its surroundings leaves you with the problem of
>which object will get the first shot at the queue.
I'm thinking that perhaps there should be a method like ChooseObjects
that acts as an arbiter if there is more than one object that is capable
of going next.
>Because, as noted in an earlier post, a computer is an incredibly stupid
>object. You have to specify _everything_ that it will do, in minute detail.
You only have to specify the details where you require a particular
outcome. In many cases you don't (whether the bird eats the bagel
before the troll gets to it may not be important).
Jim Aikin
>>object. You have to specify _everything_ that it will do, in minute
>>detail.
>
> You only have to specify the details where you require a particular
> outcome. In many cases you don't (whether the bird eats the bagel
> before the troll gets to it may not be important).
Ah, but in each and every case you still have to decide whether or not you
require some particular non-default outcome, or whether you're satisfied to
let the library use its default methodology.
Or rather, as a practical matter, when writing a game, you slap down some
code and then quite likely discover that the library isn't doing what you
expected or hoped for, which means you have to read the manual to figure out
what it's doing and how to fix it.
--JA
Andrew Plotkin
> >>Because, as noted in an earlier post, a computer is an incredibly stupid
> >>object. You have to specify _everything_ that it will do, in minute
> >>detail.
> >
> > You only have to specify the details where you require a particular
> > outcome. In many cases you don't (whether the bird eats the bagel
> > before the troll gets to it may not be important).
>
> Ah, but in each and every case you still have to decide whether or not you
> require some particular non-default outcome, or whether you're satisfied to
> let the library use its default methodology.
If you only have to make one such decision per case (piece of code you
slapped down), you've got a really excellent system. In my experience,
existing IF systems fall far short of this. You have to make
order-of-N-squared such decisions: every piece of code you slap into a
particular area can interfere with the library *or* all your other
pieces of code there.
I believe the excellent system is achievable.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
When Bush says "Stay the course," what he means is "I don't know what to
do next." He's been saying this for years now.
-
> Here, Jim Aikin <edi...@musicwords.net> wrote:
>>>> Because, as noted in an earlier post, a computer is an incredibly stupid
>>>> object. You have to specify _everything_ that it will do, in minute
>>>> detail.
>>> You only have to specify the details where you require a particular
>>> outcome. In many cases you don't (whether the bird eats the bagel
>>> before the troll gets to it may not be important).
>> Ah, but in each and every case you still have to decide whether or not you
>> require some particular non-default outcome, or whether you're satisfied to
>> let the library use its default methodology.
>
> If you only have to make one such decision per case (piece of code you
> slapped down), you've got a really excellent system. In my experience,
> existing IF systems fall far short of this. You have to make
> order-of-N-squared such decisions: every piece of code you slap into a
> particular area can interfere with the library *or* all your other
> pieces of code there.
>
> I believe the excellent system is achievable.
>
> --Z
>
Daryl McCullough
>Ah, but in each and every case you still have to decide whether or not you
>require some particular non-default outcome, or whether you're satisfied to
>let the library use its default methodology.
>
>Or rather, as a practical matter, when writing a game, you slap down some
>code and then quite likely discover that the library isn't doing what you
>expected or hoped for, which means you have to read the manual to figure out
>what it's doing and how to fix it.
Well, what I'm hoping for is a more direct connection between the symptoms
(the undesirable behavior) and the fix.
Anonymus
> The original Inform (up to and including Inform 6) had a "phase"
> structure, in which things took place in phases, and objects have
> the opportunity to alter the course of events at various points.
What about a system where every action has a number. The room's before
routine is 100, the react before routine of the objects in the room is 200
and so on. Low numbers happens first. If you don't specify a number when you
code, everything happens as normal. If you specify a number (for a before
routine for instance) then that number determines when that action happens.
And so that you could always put a number between two others you could allow
for 150,5 for instance.
Also it would be nice if you could have before routines that stopped you
from giving orders to NPC's.