Alright, my problem is fairly simple, thankfully, but I’m not entirely sure how to resolve it, I’ve set up a simple example.
+alien1: Actor 'Grey Alien'
"A little grey friend."
beforeAction()
{
if(gAction != Jump)
{
nestedActorAction(self, Jump); //basically jump if nobody else is jumping
}
}
;
+alien2: Actor 'Gray Alien'
"A little 'gray' friend?"
beforeAction()
{
if(gAction == Jump)
{
nestedActorAction(self, Jump); //jump in response to someone jumping
}
}
;
due to the way command and turn processing works, nestedActorActions don’t seem to trigger beforeAction nor afterAction, I believe since they don’t actually count as their own ‘turn/command’ this isn’t an issue typically as most NPC actions are revolving around the player, but in the case you want an NPC to react to another NPC, I’m not quite sure what you can do. Maybe something with the signals or sensory extensions?
I’d say your analysis is sound. Probably the easiest way to do what you want is to make use of the sensory extension and have whatever actions you want your NPCs to react to trigger SightEvents which other NPCs can then react to.
very interesting idea, Eric (y’know, I have to deal with two very major NPC…) my take (I have still to tackle this major coding work) is to note the action in the before* part of the action cycle, marking for reaction in the after* part. (people will remember that I asked here if my breakdown of the action cycle is correct )
I don’t know how much of this kind of thing you’re dealing with, but in the game I’m working on I’ve got a lot of reactive NPC behaviors. So the approach I’ve been using is to add NPC actions via the normal command execution cycle instead of by directly executing them via things like nestedActorAction().
That involves, for example, building a command string, tokenizing it, and then calling execCommand() with the NPC as the executing actor instead of the player. This drops new actions into the NPC’s pending command queue, so they’ll get executed as part of the normal scheduler event loop.
That’s a much more heavyweight approach to the problem, but it means that the same logic that would make an NPC react to a player action will work for an action by another NPC.
It also can have the side effect to spreading out NPC reactions over additional turns, which could be either positive or negative depending on the effect you’re going for. Like Alice and Bob having a conversation back and forth playing out with one block of dialog per turn instead of being all part of a single turn, for example. In general I want NPCs to play “fairly” and so not be able to take multiple actions in less time than it would take the player to do the same actions, so that’s not a big deal. But if you’re trying to stack NPC interactions “cinematically” directly triggering each NPC’s scripting probably works better.
)