NPC's taking turns (Inform)
Gary Leighton
present in the same location as the player character.
I need them to perform actions that affect the world model, but what
I'm currently wondering is, how often should the NPC's get a turn?
The alternatives seem to be all the NPC's perform their actions after
the player's command is processed, or just one of the NPC's gets an
action and the other NPC's have to wait for their chance after the next
player move.
e.g. we have
> X AXE
You move north. NPC1 takes the axe. NPC2 shouts "wow". NPC3 drops a
brass lantern.
or
> X AXE
You move north. NPC1 takes the axe.
> X NPC1
He is carrying an axe. NPC2 shouts "wow".
The problem with the first approach is that the player can only react
to one of the NPC's actions before they all move again. e.g. If they
all choose to attack the player, the player would probably be dead
before the PC gets another command in. Another issue is what order
should the NPC's move in? How can you make it possible for the first
NPC to act to react to the last NPC to act?
The problem with the second approach is that the player gets a lot more
turns than the NPC's. It's like the player is speeded up in time by
comparison. He would be a kind of super-hero in comparison with the
NPC's.
I suppose one 'solution' to this is to have some kind of real-time
framework, but I really don't want to go down that route.
I realise that the answer to this question depends on the context. Has
anyone analysed this kind of thing already. Can anyone provide some
good links?
Gary
Andrew Plotkin
> The game I'm writing at the moment has multiple NPC's that can all be
> present in the same location as the player character.
>
> I need them to perform actions that affect the world model, but what
> I'm currently wondering is, how often should the NPC's get a turn?
>
> The alternatives seem to be all the NPC's perform their actions after
> the player's command is processed, or just one of the NPC's gets an
> action and the other NPC's have to wait for their chance after the next
> player move.
>
> The problem with the first approach is that the player can only react
> to one of the NPC's actions before they all move again. e.g. If they
> all choose to attack the player, the player would probably be dead
> before the PC gets another command in. Another issue is what order
> should the NPC's move in? How can you make it possible for the first
> NPC to act to react to the last NPC to act?
>
> The problem with the second approach is that the player gets a lot more
> turns than the NPC's. It's like the player is speeded up in time by
> comparison. He would be a kind of super-hero in comparison with the
> NPC's.
This is a general problem in game design -- it's not Inform-specific,
or even IF-specific. It's just as relevant in paper-and-pencil RPGs,
really.
Nearly everybody goes with the first approach. For a start, it's
realistic -- if all the NPCs attack the player at once, they probably
*will* kill him, right? Unless the player is defined to have much
better fighting skills. Which is one of the things you have to decide.
(Realism is not the ultimate goal, but the second approach tends to be
unrealistic in immersion-breaking ways. Not only is the player speeded
up, but he seems to get faster the more people he's fighting. This is
counterintuitive. Although it might be appropriate for a game about a
martial-arts master -- see Jackie Chan / Jet Li movies where the hero
can hold off an entire attacking horde by taking care of them one at a
time!)
Assuming you go with the first idea, the most common model for
sequencing is to give every NPC a "speed" or "initiative" attribute --
a number, perhaps modified by a random factor every turn. NPCs move in
order of initiative, and they can only react to actions of earlier
NPCs.
(If you want, you can give the player an initiative attribute too, and
break for the player's move at the appropriate point in the sequence.
The programming is a little more complicated that way. And it may or
may not make for a playable game -- it's not unreasonable to treat the
player specially.)
If fighting is not involved -- i.e., the NPCs are just moving around
and talking and futzing with objects -- it's less important to be
"fair" to the player. You can have the NPCs take multiple actions per
turn, as long as they don't wind up drowning the screen in a flood of
output.
For this, you could have a system where NPCs watch each other, and a
particular NPC action can queue up responses in other NPCs. (One NPC
drops an egg; another responds by getting a towel to clean it up.)
This is an antsy kind of model to work with. If two NPCs get into a
loop, triggering actions off each other, they'll either overflow your
data structures or hang the interpreter. If you put limits on your
loops to prevent this, they could still wind up repeating the same
actions every turn for the rest of the game. You'd have to either
allow some kind of obsession-breaking behavior, or be careful to
ensure that no response-type action triggered another response-type
action.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
Graham Holden
wrote:
<snip>
>
>The alternatives seem to be all the NPC's perform their actions after
>the player's command is processed, or just one of the NPC's gets an
>action and the other NPC's have to wait for their chance after the next
>player move.
>
<example snipped>
>
One of the main problems I see with the second approach is that a desired,
even essential, NPC reaction is not made because it wasn't their "turn"
when the circumstances were right -- loads of things might never happen
because the player isn't "in sync" with the right NPC.
So, from a practical point of view (as well as being more "realistic") I
think every NPC at least needs to have the _opportunity_ to react every
turn (they may not always do so, but at least the code should allow them
to).
>The problem with the first approach is that the player can only react
>to one of the NPC's actions before they all move again. e.g. If they
>all choose to attack the player, the player would probably be dead
>before the PC gets another command in.
In a sense, the response is "That's what reality is like!" -- if you're
jumped by a gang of thugs, you can hardly expect them to take polite turns
in beating you up!
If there's a legitimate reason for a squad of aggressive NPCs roaming the
game _at_random_, then an almost necessary consequence is that you might,
if you're unlucky, meet all of them at once and get pasted. You _could_
make it so that as soon as one's decided to attack, the others lounge
around polishing their swords, but that'll look very artificial (IMHO).
A better alternative is just make sure -- through some mechanism or other
-- that the "_at_random_" bit above _isn't_ at random... by some subtle
tweaking of NPC's movement code, there's never more than one or two in the
room with you.
> Another issue is what order
>should the NPC's move in? How can you make it possible for the first
>NPC to act to react to the last NPC to act?
Would probably need to keep going round them all in a "while" loop; you
need to make sure they all have a chance to react initially; also, if one
of them _does_ react, you need to keep going until the "one before" so that
they all have a chance to react to that reaction.
I haven't got time to think through the psuedo-code to demonstrate what I
mean now; I'll post tomorrow if nobody's given a better example.
>The problem with the second approach is that the player gets a lot more
>turns than the NPC's. It's like the player is speeded up in time by
>comparison. He would be a kind of super-hero in comparison with the
>NPC's.
>
>I suppose one 'solution' to this is to have some kind of real-time
>framework, but I really don't want to go down that route.
>
>I realise that the answer to this question depends on the context. Has
>anyone analysed this kind of thing already. Can anyone provide some
>good links?
>
>Gary
Regards,
Graham Holden (g-holden AT dircon DOT co DOT uk)
--
There are 10 types of people in the world;
those that understand binary and those that don't.
Gary Leighton
Andrew Plotkin wrote:
> Nearly everybody goes with the first approach. For a start, it's
> realistic -- if all the NPCs attack the player at once, they probably
> *will* kill him, right? Unless the player is defined to have much
> better fighting skills. Which is one of the things you have to decide.
I think I chose a bad example. A better one might be if NPC1 drops an
object, and NPC2 picks it up before the player gets a chance to enter a
command. The player has missed an opportunity (to pick up the object
himself) that really should have been available in real life.
>
> (Realism is not the ultimate goal, but the second approach tends to be
> unrealistic in immersion-breaking ways. Not only is the player speeded
> up, but he seems to get faster the more people he's fighting. This is
> counterintuitive. Although it might be appropriate for a game about a
> martial-arts master -- see Jackie Chan / Jet Li movies where the hero
> can hold off an entire attacking horde by taking care of them one at a
> time!)
I think I have to agree with you; the second option isn't as good. But
I still worry about issues of the type above (i.e. the dropped object).
I don't see a solution yet.
>
> Assuming you go with the first idea, the most common model for
> sequencing is to give every NPC a "speed" or "initiative" attribute --
> a number, perhaps modified by a random factor every turn. NPCs move in
> order of initiative, and they can only react to actions of earlier
> NPCs.
Seems reasonable.
> For this, you could have a system where NPCs watch each other, and a
> particular NPC action can queue up responses in other NPCs. (One NPC
> drops an egg; another responds by getting a towel to clean it up.)
I like this idea. I guess I could even prioritise actions in the queue
and allow some to be performed in a later turn. Maybe this solves the
problem with the dropped object; all I need to do is somehow recognise
actions that the player might want to respond to, and queue up the
other NPC actions. Sounds a bit complicated though.
This brings me to a related subject which is the idea of interuptable
actions. What I have in mind is physical actions (e.g. Dwarf throws axe
at player) that could be interupted by the player or an NPC. In this
example, the player might duck or try to catch the axe, and so the
result of the throwing action will not be known until after the
player's turn. I'm imagining an action type that can be split into
parts; a start-throw and an end-throw.
Has this sort of thing be done before? Is it easy to do in Inform?
David Fisher
news:1117663853....@o13g2000cwo.googlegroups.com...
>
> I think I chose a bad example. A better one might be if NPC1
> drops an object, and NPC2 picks it up before the player gets
> a chance to enter a command. The player has missed an
> opportunity (to pick up the object himself) that really should
> have been available in real life.
It sounds you need to model simultaneous turns rather than sequential ones
... the order of events would be something like this:
(1) Player enters a command (the PC's "intention")
(2) Determine each NPC's intention
(3) Check for conflicts between intentions & decide on the outcome (who
succeeds at their goals and who fails, and what happens if they fail) and
display the results of all conflicts
(4) For each actor not involved in a conflict (PC + NPCs), perform their
intended action [at this point, the order of actions doesn't matter, since
there are guaranteed to be no conflicts]
To give the player a chance to respond, the NPC actions might sometimes be
"half actions" (as you mention later in your post), eg. "Fred and Jake both
reach for the Golden Goblet". Sometimes the PC might not have a chance to
act, though - "Fred reaches for the Golden Goblet, but Jake is quicker and
snatches it into his chest."
The PC can have "half actions" as well (ie. the NPC can tell what the PC is
intending to do) - this can be made to happen by giving the NPCs in step 2
knowledge of the PC's intention from step 1.
> Has this sort of thing be done before? Is it easy to do in Inform?
I have no idea ;-) but it's fun to think about ...
David Fisher