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

From: "samayel" <nospam@domain.ext>

Date: Thu, 07 Mar 2002 20:14:47 +0000

<S.J.Clifford@work.it.out.invalid> wrote in message
news:a68dji$14j$1@beta.qmul.ac.uk...
> 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.
>

good point... and well taken. This is all theory for me, so your comments
are welcome. That makes more sense actually... I wasnt cocerned about
performance initially since its not real time, but I can see where it would
still be way more efficient to do it that way.  so just have an array for
characters and monsters (same array I guess) that contains x, y, z coords,
and other info. such as character or monster, etc?

>
> > 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.

that does make sense, if I go purely by speed (or any one factor)... thats
the way to do it. I just hate the thought of turn processing order going so
rigidly by any one factor... there needs to be a small variance... a little
chaos... not much of course, otherwise the speed factor becomes irrelevant.

>
> >
> > 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.

of course, although I do like the possibility that the slower character
might succeed once in a while.  otherwise if you know you have no chance,
why bother? some type of small randomness would make it more realistic...
perhaps.

> >
> > 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.

yeah, that sounds like a great idea, and makes sense to me. Thats close to
what I had in mind, but I wonder if it makes more sense to do it that way,
or do the monster AI (basically) on the fly... so they can react to changes
in the environment during the turn...  or would that give them an unfair
advantage since the players cannot?

>
> 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.
>
> S.

you've obviously thought about this before.  Discussion like this is the
reason I pitch the PBM Design group whenever I can.. if you aren't a member,
you would certainly be welcome.  Thanks for your comments, they are most
appreciated.

References

turn processing discussed in PBM Design group (yahoo groups)
"samayel" <nospam@domain.ext>
Thu, 07 Mar 2002 18:10:40 +0000
Re: turn processing discussed in PBM Design group (yahoo groups)
S.J.Clifford@work.it.out.invalid
Thu, 07 Mar 2002 19:04:18 +0000

Referenced By

turn processing discussed in PBM Design group (yahoo groups)
"samayel" <nospam@domain.ext>
Thu, 07 Mar 2002 18:10:40 +0000
Re: turn processing discussed in PBM Design group (yahoo groups)
S.J.Clifford@work.it.out.invalid
Thu, 07 Mar 2002 19:04:18 +0000