I7: Both Poet and Auda, kiss Iris

What’s a practical and effective way to implement virtually simultaneous action requests to multiple actors using Inform 7? For example, suppose we want to allow the player all of the following ways of formulating a valid command:

[code]Whiz, Poet, and Iris, north. [= Actor called Whiz and actor called Poet and actor called Iris: each of you ought try going north]

All robots, dance. [= All actors of the kind understood as robot: each of you ought try dancing]

Both Sensa and Waldo, move Fred. [= Actor called Sensa and actor called Waldo: each of you ought try the action of pushing something (in this case, pushing Fred)][/code]

Presumably effecting such a command would involve breaking it down into separate requests for each actor to try the requested action. A perusal of the Standard Rules reveals only that requesting a persuasion attempt is a function handed off to ominously-titled I6 thingies (to which latter I am allergic and have been cautioned by my doctor not to interact with in any way :confused: ).

Any guidance is much appreciated.

If anyone would like a small sample game with which to ponder the question rather than forumulating their own example:

[Objective: a game where the player-character is inert, and interacts with the world solely through a band of variously sense-impaired avatars]

A robot is a kind of person.  Understand "robot" as a robot.  Understand "robots" as the plural of a robot.

Auda is a robot.
Iris is a robot.
Sensa is a robot.

Waldo is a robot.
Whiz is a robot.
Poet is a robot.

The present-robot is a person that varies.  The present-robot is usually Iris.

A persuasion rule: persuasion succeeds.

Before asking someone to try doing anything:
	change the present-robot to the person asked.

The report robot activity rule is listed before the check stage rule in the specific action-processing rules.

This is the report robot activity rule:
	now the player is the present-robot.

After deciding the scope of the player:
	repeat with avatar running through on-stage robots:
		place avatar in scope.

Unsuccessful attempt by an actor doing anything:
	try looking.


[may seem redundant given the "report robot activity rule," but is nonetheless necessary on several counts:]

Every turn:
	now the player is the present-robot.

When play begins:
	now the right hand status line is "[printed name of the player]".

The Command Center is a room.

Auda, Iris, Sensa, Waldo, Whiz, and Poet are in the command center.

The player is Iris.

A marble is in the command center.

A room called the Weather Monitors is west of the command center.

A room called the Transit Monitors is south of the command center.

A room called the Hydroponics Monitors is east of the command center.

[The avatar transference process is not quite seamless here; for one thing, some standard check action rules report failure with (for example) "You can't go that way" rather than "[Printed name of the player] can't go that way," and need to be individually reformulated.  Obviously, this example is only a very rudimentary implementation.]

Thanks

Endosphere

The hardest part of this is parsing multiple actors at the beginning of the line (“X, Y, go north”). You’ll have to do some tap-dancing there, and get the list recorded somewhere. You’ll also have to record the same sort of list for a “tell X, Y to go north” if you want to support that.

Handling the simultaneous actions is merely a nuisance. At the beginning of the action, you check for a custom result – that is, a situation where “X, Y, go north” has a joint result different from the separate actions. (An activity rulebook is good for this sort of decision tree.) If so, perform it and stop the action. If not, let it continue to performing separate actions.

You’re going to have to muck around in I6 regardless, though.

Is this some adult version of Suspended you’re working up here?

“Both Poet and Auda, kiss Iris” (while such and such watches)

Except Iris is the only one who can see. Consarnit!

@ zarf

Thanks. I suspected as much, but hoped otherwise. In any case, I consider my question answered.

@severedhand

Nah, just a bid for attention to my posting through lurid labelling. I haven’t visited the forum here in quite some time, and am pleased to see that activity has increased considerably since I last visited-- which also means the first page of recent only shows the last two or three days (as opposed to the last week or two).

So I was thinking about whether this could be done with a two-part thing, where you create a special agent (here called “folks”) that you can ask to do things, but when you say “folks, jump” the game asks you who you want to jump; you then enter some agents and they do what you asked. But I’m running into something weird at the very first step.

[code]A robot is a kind of person. Understand “robot” as a robot. Understand “robots” as the plural of a robot.

Auda is a robot.
Iris is a robot.
Sensa is a robot.

Waldo is a robot.
Whiz is a robot.
Poet is a robot.

Dummybackdrop is a backdrop. Dummybackdrop is everywhere. A robot called folks is part of dummybackdrop.

A persuasion rule: persuasion succeeds.

Folks-action is a stored action that varies.
Instead of asking folks to try doing something:
let boogle be the current action;
say “[Folks-action].” [this is where I’ll have something incredibly clever, I know not what, allowing you to input the list of commandees]

After deciding the scope of the player:
repeat with avatar running through on-stage robots:
place avatar in scope;
place folks in scope.

Unsuccessful attempt by an actor doing anything:
try looking.

Every turn: say “Current action: [the current action].”

When play begins:
now the right hand status line is “[printed name of the player]”.

The Command Center is a room.

Auda, Iris, Sensa, Waldo, Whiz, and Poet are in the command center.

The player is Iris.

A marble is in the command center.

A room called the Weather Monitors is west of the command center.

A room called the Transit Monitors is south of the command center.

A room called the Hydroponics Monitors is east of the command center.

Test me with “rules/actions/folks, kiss auda/folks, jump/auda, kiss folks”.[/code]

As you can see, “auda, kiss folks” gets parsed as asking auda to try kissing folks, “folks, jump” gets parsed as asking folks to try jumping, but “folks, kiss auda” gets parsed as answering folks that kiss auda. Anyone know why?

Interesting idea, Endosphere. I do think this might be easier as an i6 parser hack, but since my i6 is minimal, I wanted to try working it from as pure an I7 angle as possible. Unfortunately, I’ve run into a snag. When narrowed down, it appears to be a bug in the template code (i6), which I will post on a separate thread for confirmation later. Don’t lose hope however; I’m convinced I have a workaround that will satisfy your original parameters. That is if someone doesn’t beat me to the punch. (Keep working on your idea, Matt – mine’s totally different. Both will probably be useful to someone in their own way.)

That suggests that the game doesn’t understand the “kiss auda” instruction, or at least Inform converts “unrecognized conversation” to the answering someone that action (Parser Template §18).
I have no clue why that instruction would not be understood, though,

I’m going to guess that scope for actors that are parts of backdrops is all messed up. However, this does not work:

A rule for reaching outside dummybackdrop: allow access.

UPDATE: Aha! It was simply that I needed to write a scope rule for folks:

After deciding the scope of folks: repeat with avatar running through on-stage robots: [should probably be everything that the player can see, or that the robots can see] place avatar in scope.

Now I need to figure out how to make sure everything else we want to be in scope is, extract the action we’ve asked folks to do, get some actors from the player, and have those actors do what we asked folks to do.

OK, if I can extract the action name, noun, and second noun from the current action, is there anyway I can reassemble that into an action that I can have actors try? Section 12.20 suggests that the only way to make a stored action is to type it in or to copy the current action, which could mean I can’t do what I’d like to (which is store the action we asked folks to do, find out who’s supposed to do it, and have those people try that stored action).

Take a look at the Standard Rules, specifically the “convert to request” phrases, the most salient of which is:

To convert to request of (X - object) to perform (AN - action name) with (Y - object) and (Z - object): (- TryAction(true, {X}, {AN}, {Y}, {Z}); rtrue; -).

It would probably work just fine to write your own version that didn’t require a second noun (untested):

To convert to request of (X - object) to perform (AN - action name) with (Y - object): (- TryAction(true, {X}, {AN}, {Y}); rtrue; -).

You might want to look at the TryAction and related routines in the I6 template file/Appendix B to see whether there are any refinements.

–Erik

EDIT: I went ahead and tested that second one; it seems to work just fine. Here’s a sample game that effectively turns the PC into the player’s voodoo doll for controlling the dog:

[code]Place is a room. There is a gun and a sponge in the place. The dog is a person in the place.

Instead of doing anything:
let x be the action name part of the current action;
let y be the noun part of the current action;
convert to request of the dog to perform x with y.

To convert to request of (X - object) to perform (AN - action name) with (Y - object):
(- TryAction(true, {X}, {AN}, {Y}); rtrue; -).

Persuasion rule: persuasion succeeds.[/code]

Superb, Erik, thanks! It looks as though I can just use the unmodified convert to request – if the action-name requires only one noun and the second noun is nothing (as it should be), then it seems to go through fine. And I want this to cover requests to put things on things, without having to worry about writing a bunch of special cases depending on how many nouns there are, so that’s a relief.

Right now I can’t figure out how to do anything with topics, so I’ll just hope that no one wants to command a whole squadron to set their phasers to kill.

…also I can’t seem to make a lot of the report rules fire, at least not the way I’m doing it. Well, more delving is required.

As an alternative to folks, you might consider requiring the player to do some scheduling:

I think that could be done without delving into I6, although you might end up using lists and stored actions, and that could get ugly too.

@matt w, Felix

Regarding “answering it that,” the the stipulation of that action is “answer [someone] that [some text].” As no thing in your game-world was understood as a thing called “kiss auda,” the parser presumed you were answering someone about a topic/text rather than referring to a “tangible” thing or requesting an action.

@matt w

Regarding your minor trouble with constructing a “rule for reaching,” as far as I know rules for reaching inside/outside only affect reaching inside/outside rooms, containers, and supporters (as you likely realized by your switch to a rule regarding scope). Regarding the latter notion of scope, it’s a good idea (though not shown in my original example) to add in this case:

     place [whatever] in scope, but not its contents.

Adding an actor as part of a backdrop is a good, solid idea, and the sort of thinking that ought always be encouraged.

The drawback of such an approach, however, is that the solution is fairly complex “[this is where I’ll have something incredibly clever, I know not what, allowing you to input the list of commandees].” The question, then, would be whether having a generic “interpreter” actor as you’ve proposed would be more or less complex than the parsing/activities approach suggested by zarf (which was also my own approach, though I didn’t mention it initially to avoid prejudicing the discussion as it only fits the “effective” but not the “practical” part of my criteria).

Yet another approach that hasn’t been mentioned yet might be to have only one “robot-actor” rather than six; this single actor would have six lists of possessions, six variables for stored locations, six nicknames referenced in reading a command, etc. I’ve often found that whether “something exists” in the game world is irrelevant; all that matters is whether it seamlessly seems to exist for the player.

As you’ve seen, part of the trouble, as ektemple elaborated, is of course that “the current action” will always be “the action of requesting (someone)to try (something)” rather than “try (something)” in the sort of scenario I’ve outlined. Ektemple’s addition on this point is quite interesting and relevant, though the I6 factor has clearly come into play with his approach.

In any case, your contribution is a valuable one, and I’m interested in hearing anything else you come up with using the approach you’ve so far examined.

@Skinny Mike

I’d definitely be quite interested in hearing anything you’ve come up with on the subject, as your contribution to difficult questions I’ve posed in the past has always been both relevant and effective.


My own tinkering and experimentation showed that the very simplest sort of the the three commands I proposed initially is “all robots, (try something).” Writing a brief replacement and redirect action to implement this action’s result with an activity to repeat through all qualifying robots is quick and easy, particularly if we make a note to the player to omit phrasing his command to all robots with a comma (otherwise, a smidge of parsing is necessary).

For example:

[code]Multireporting is an action applying to nothing. Understand “all robots report” as multireporting.

Report multireporting:
repeat with avatar running through on-stage robots:
say "FC Interrupt-- [avatar];
try avatar looking.[/code]

The “Both (actor1) and (actor2), (try something)” could be fairly simple as well, if we invoke observance of hallowed Infocom tradition as an excuse for laziness/lack of rigour. In Suspended, this request doesn’t actually require two distinct actors; it’s perfectly understood and carried out to say “Both Poet and Poet, move Fred,” for example. This means, with a bit of work, we can modify the exising actions to accept the new form of input merely by notionally adding “Understand [someone] and [someone] north” as dualgoingnorth.

The very most troublesome is the remaining case (the first I originally mentioned), wherein we’d like to issue commands in the form “Iris, Auda, and Whiz, go to Sub Supply Room.” Very notionally, the original approach seemed to be:

After reading a command:
[Parse for signs of a phrase including instructions to multiple actors; pull out the text corresponding to the name of each actor, and store it in a list; assign the object of the requested action as a variable]
[Call an activity to repeat through the afore-mentioned list, trying the object of the action request with each actor on the list].

These sorts of things give me headaches; since I only fool around with Inform to entertain myself rather than output releasable games, though I know how to do such things I’d much rather allow my wandering attention to move on to some other subject.

@matt w

You mentioned some trouble writing report rules in the general framework of the example you constructed; depending upon how far you’ve gone, one thing about the original example I proposed was that it interferes quite messily with the turn sequence rules; after posting I later refined it considerably, but to give an idea of the jury-rigging still involved in my own efforts I’ll just note that most of the actions in that environment now end explicitly in “rule fails”-- surely an ominous development, although it is fairly entertaining regardless to see the original game recreated (if only in a rudimentary manner until I add all the things, resolve this “robot-command” problem satisfactorily, and determine some method of scoring the “death toll” on the planet above). Depending on how closely you’ve used some of the conventions I originally posted, the turn sequence may be a problem in your own example as well.

@capmikee

I just noticed your post as I was making my own. Scheduling would indeed be yet another general approach to the matter; its merit is that it avoids any recourse to I6, which is important to me because I don’t understand I6. The downside is that such an approach might interfere with the pacing of the game, turning it into something with more of a “strategic” focus than a “tactical” focus. On your other note, in general I don’t find either lists or stored actions to ever be much difficulty; it’s building my own parser that I haven’t the resolve to effect. :slight_smile:

Thanks again to all who responded.

Endosphere

Actually, I’m pretty sure because (in my test code, before trying to add the multi-agent capability) I was converting the requests to folks to requests to Iris, and Iris was the PC. When i convert the requests to Auda instead, the reporting seems to work. Durrrr. [EDIT: For what it’s worth, I’d commented out the parts of your code that messed with the turn sequence.]

Anyway, I don’t have time to do a lot on this now, but I hope to get back to it – it seems like a neat programming puzzle at least. Maybe some day we’ll be able to implement that one command from “Bowl Drop Toy Sleep Play,” whose transcript I unfortunately can’t find anymore, not even through the Internet Archive.

I really don’t like the way the parser handles commas, and I want to make it possible to parse them in I7. You’ve given me more motivation, and some ideas, for my big hypothetical parser rewrite extension. Which is good, because I’m going to need a lot before I get started on it…

I’ve got a start on my two-stage command method – I6-free! Lots of hitches, though. New topic about that here.

For posterity’s sake, bumping to say that we (Draconis, mostly) have made an enormous amount of progress on this here.

I don’t suppose you could do something like the “folks” thing and make a a dummy person attached to one of them that is only accessible when they are both present that responds to the name “auda and iris” then write that single character as a response by both.

That could work, but you’d need a new dummy for each possible combination of robots.