Re: turn processing discussed in PBM Design group (yahoo groups)

From: S.J.Clifford@work.it.out.invalid

Date: Thu, 07 Mar 2002 19:04:18 +0000

samayel <nospam@domain.ext> wrote:
> if you are on a big XYZ grid, (i.e. a multilevel dungeon) you could process
> orders cell by cell... with adjustments made for neighboring cells. for
> example:
>
> The turn engine would process the FIRST order of a persons turn, going cell
> by cell, left to right & top to bottom until it hits a cell containing a
> character.
>

Ooh, this is not a good way to do it.  The number of cells could be
vast, and will always be large compared to the number of players /
monsters.  Far better is to have a list of players and monsters and
iterate through that.

> ...

> If 3 wants to attack x then check the status of x and any other characters
> or monsters within a certain area of effect (maybe determined by line of
> sight). In this example you would also check player 2. If 2 is faster than
> 3, see what his orders are in case they would affect the outcome of 2's
> orders. If they do (i.e. he attacks faster, or he attacks player 3...) then
> execute his orders, and flag him so you dont execute them twice. If all he
> is doing is moving in the other direction, then disregard him and process hi
> s order when it is appropriate.
>

So what you're saying is that the fastest player goes first, regardless
of his situation -- the fastest player's orders are not effected by
other's orders.  I think this gives you a much nicer way of handling the
turn engine: iterate through the players (and monsters if you want) in
descending order of speed (initiative, whatever).  As you process each
player you know that all faster players (and monsters) have already had
their turn, so any effect they've had on the universe has already been
taken care of.  You only process each player once and need store only
information about one player at a time.

>
> Next is player 4. Next to him, and definitely in his area of effect, is
> player 5. They both want to attack x. This would be a conflicting order,
> because there is a chance that 5 might kill x before 4 even swings (if 5 is
> faster) so we compare stats (speed?) and see who actually goes first.
>

Doing it my way this is automatically a solved problem.

> gold, THEN its a conflict so the faster character would get it. and of
>

Again, the slower player's order to take the gold would just fail, since
it's not there any more.

>
> What about monsters, you ask?  Well...  technically they should be processed
> just like the players, except instead of following orders, you would have to
> analyze the environment and then make a determination on how to act. Factors
> to consider would be: anger, fear, hunger, health, intelligence, and speed
> (I'm sure there are others but you get the idea).
>

Yeah.  Have a turn generation phase in which the monsters compute their
orders, based on local information, monster's stats, etc.  Then inject
these orders into the turn processing phase.  The monsters end up
treated the same as the players, except for the provenance of their
orders.

Going back to the order of turns -- it probably wouldn't be too
difficult to allow for simultaneous processing amongst small groups of
characters.  You'd have to keep a working copy of each player's stats
during the turn and then apply all the results at once.  So if players X
and Y are hacking player Z to pieces and by chance all three "roll the
same initiative" (or whatever) the situation plays as: we make copies of
all three player's stats.  Then we go through (in arbitrary order) the
players.  X hits Z for some damage.  Y attacks (an unharmed!) Z and
kills him outright.  Z attacks X and kills him.  Then the results are
applied: X and Z strike each other and topple to the ground, leaving Y
pulling his sword from Z's corpse.

References

turn processing discussed in PBM Design group (yahoo groups)
"samayel" <nospam@domain.ext>
Thu, 07 Mar 2002 18:10:40 +0000

Referenced By

turn processing discussed in PBM Design group (yahoo groups)
"samayel" <nospam@domain.ext>
Thu, 07 Mar 2002 18:10:40 +0000