@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.
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.
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).
[code]Multireporting is an action applying to nothing. Understand “all robots report” as 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.
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.
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.
Thanks again to all who responded.