Thanks for all the replies! You have been very helpful. It seems that I
will have to think a bit which system I am going to use.

Currently I have a simple priority queue (using the priority_queue class
from C++'s STL). In my game every action takes the same amount of time
(I'm keeping everything very simple) but different monsters (and the
player) have different speeds. Still there are a few issues with the
system as I just got it to work :)

By the way, maybe some of the articles should be posted to
roguelikedevelopment.org? Especially Brent's article seemed to cover
different techniques quite thoroughly.

-- Joel

Adeo's turn system works as such :

Whenever the player performs an action that takes time (to include using a
computer, i.e. entering commands and such, if there's another entity on the
same computer system/network, such as a security AI or anti-intrusion/tracer
module), the following happens :

* all loaded maps are checked to see if any entity on them is flagged as
Important (players are flagged as Important, as will be, later on down the
line, special or story important NPCs)
* all entities on the check-passed maps are given the chance to decide what
they want to do within the given time frame (however long it takes the
player to perform his/her action)
* a list is made of all entities that have a pending action, ordered by how
long it takes them to perform their action
* sequentially, each entity performs their action. As an entity acts, it
gets the chance to decide if it wants to act again, and if it decides to act
again (given that it has enough time left to act in), it gets re-sorted into
the list
* once all entities have acted, power sources process any drain on them (for
handling batteries or other power sources with depletable charge or fuel)
* all entities that died during the course of action processing now get
deleted

Now, this method always places the player last, but allows entities that can
do more than one thing in the time it takes the player to, say, move one
square.

As far as hard numbers go, Pawns (any class of entity that has stats,
usually NPCs and players) have 6 ordinary stats (strength, dexterity,
wisdom, intelligence, constitution, perception) and 12 core skills (hand to
hand, melee, small guns, heavy guns, physics (knowledge of), electronics
(knowledge of and experience in), piloting (ability to), barter (ability
to), speech (effectiveness in communicating), minerology (knowledge of and
ability to extract from ore), metallurgy (knowledge of, ability to extract
from ore, and ability to work with), and manufacturing (knowledge of methods
and ability in manufacturing of materials). Stats range from 1 to 20 and
skills range from 1 to 100 (with no possibility of even temporarily boosting
beyond the max).

A pawn's movement speed is 100 / Dexterity.

A pawn's ability to hack an electronic lock is : Lock.Complexity <=
Electronics.Level to trigger the emergency override, but Lock::Complexity <=
Electronics.Level + Pawn.Intelligence + Pawn.Wisdom if the pawn wants to
rewrite the keyID the lock is expecting (so that hackers can make a lock
accept a keycard with a known keyID).

--
 - Pfhoenix
http://pfhoenix.com/adeo

I don't have any help here, except to present a contrarian view.

Why have a movement speed system?

Roguelikes are about tactical combat.  Tactical combat requires
control, on the part of the player, of the mechanisms of combat.  Fine
grained movement systems (such as priority queues, etc), are difficult
to understand.  One cannot predict double attacks, etc.  Thus, double
attacks cannot become part of the player's strategies.

I contend that movement systems should be as simple as possible.  So
long as attacks are discrete (you don't do damage over time) and
movement is discrete (you move one square at atime), it seems silly to
try to make time continuous.

POWDER uses the simplest level of movement speeds I could think of.  I
believe it is very close (or matches) the old Nethack system.

There are three binary, independent, speed related intrinsics.  You
can be Fast, Quick, or Slow.  Being Fast or Quick grants you an extra
action phase, being Slow denies you a standard phase.  Fast is
provided through permament intrinsics (like speed boots), Quick
through temporary intrinsics (like wands of speed)

There are a series of phases:
    F N S Q N Speed
N     x x   x 100%
F   x x x   x 133%
Q     x x x x 133%
FQ  x x x x x 166%
S     x     x  67%
FS  x x     x 100%
QS    x   x x 100%
FQS x x   x x 133%

Heartbeats occur on N and S moves.  These are where time actually
passes.  Poison damage, health regeneration, etc, is all done in these
phases regardless of the speed of the monster.  Heartbeat phases are
also when all durational effects decrement, wind blows smoke around
the dungeon, etc.

This system is very simple, and, IMHO, very understandable.  The
differences in speed are big enough to be noticeable without ever
being crippling.  There is no player-centrism to affect any global
sense of time.  While players can time their double moves, I don't see
this as a deficiency.  Chess manages to be an interesting game despite
always knowing how many moves the other player will get to take.

I personally think priority queue and energy based speed systems are
one of the siren calls of roguelike development.  IMO, they do nothing
but add static between the player and the gamespace.  One could likely
emulate most complex speed systems by just randomizing the turn order
everytime you iterate through the creatures.  To the player, it will
be just as relevant.

Speed based systems also result in inanities like "Diagonal movement
costs 1.4 times straight movement."  Again, I believe the player
should have control over the flow of time.  This only occurs if the
player can predict the time cost of any action.  The best way to do
that is to have every action cost one, and only one, action phase.  I
don't care how unrealistic taking off platemail in a single move may
be!

My favorite portion of roguelikes is the Critical Moment.  This is
where your character is about to die and it is up to you to rescue
him.  You have one move.  What do you do?  In my ideal roguelike,
there is always something I could have done that I realize *after* I
get my Do You Want Your Possessions Identified?  This Critical Moment
can never include multi-turn actions.  Furthermore, multi-turn actions
are usually merely performed in a safe area, and, by game design, not
be required at Critical Moments.  Thus, why not allow them at Critcial
Momements?

In POWDER, you may with three turns forget a spell, learn the Cure
Poison Spell you had been neglecting, and then cast it.  This means
with three turns to death from deadly poison you have a way of getting
out.  Traditional roguelikes would have you die of the poison before
you could learn the spell.

To make a long story short: Start working on your content already.
That is infinitely more important than the engine.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)

Attacks of opportunity could limit the most egregious abuses of double
moves.

Sometimes critical moments are produced by the fact that actions are
multi-turn. NetHack encourages the player to remove armour in various
situations, and sometimes forces armour removal. This means you can get
caught with your pants down; but that is only the case because
re-equipping even the most vital items may take longer than you have,
forcing a more ingenious solution.

I agree that many more actions could be single-turn. I can't see much of a
case for multi-turn eating, for example; and the slew of bugs and special
cases that come with it are impressive.
--
David Damerell <damer...@chiark.greenend.org.uk> Distortion Field!

Dnia 20 Oct 2004 05:24:53 -0700, Jeff Lait napisal(a):

Heh, I'm designing a simlar dodge, but only related to h2h combat.

You know, all the `double action' and the like things are the most
imprtant when you fight.  So I just introduced a new state `engaged
in combat', in which you take turns in a different manner than usual.

I think it's pretty silly that you and your opponent hack at each
other in turns.  I'd prefer the `Dungeons and Trolls' kind of game,
where you don't count separate hits, but a total damage inflicted
during some time of combat.
But you still have to allow the player to decide what to do.
So it goes like this:

1) When you're not engaged in h2h combat, you move as usual -- that
is you movement speed gives you additional moves.
2) Shooting is considered to be done at the same time as walking, so
the above `extra action' doesn't spoil ranged combat too much.
3) When you attack or are attacked, you become `engaged in combat',
and so the timing system changes.
4) You no longer take turns according to your movement speed, instead
your speed is an average of all creatures in that combat group -- that
is all creatures in this combat group move at the same speed.
This reflects the fact that you have to dodge blows and look for an
opportunity to score a hit, and so you've got to synchronize your
movement with the movement of your opponents.  If your speed differs
a lot from that of your opponents, however, you get combat bonuses or
penalties (for ToHit, ToDodge, etc.), and sometime can even score an
additional hit (but then it's two hits with one action, not two actions).
All creatures in the combat group are considered to act at the same
moment.
5) When you're engaged in comabat, you fight regardless of what other
action you have selected.  So if you press `wait', you fight with
the opponents. If you press `drink a healing potion', you drink a
healing potion WHILE fighting with the opponents (offcourse you get
a penalty for that round) and when you try to move, you test against
the skills of all other combatants, and if you pass, you move whole
combat group with you.  You need a separate command to break from
combat.  Offcourse, if you fail a movement test, some other creature
from the combat group may win it, so you get moved against your will.
It's `I had to move there or he would smash me with his blow'.
6) When you surprise an enemy, or stun him, or anything like that,
he cannot act this combat round.

I know it's not very roguelike-ish, and it will readuce the use of
tactics, but I'm writing a zombie game, so the h2h combat is supposed
to be pretty rare, and you usually are in big trouble if you let those
bastartds get near enough.

--
Radomir `The Sheep' Dopieralski
        You only need pen and paper to do philosophy.
        To do mathematics you need pen, paper and a trash can.

In article <774acfb8.0410200424.1d09a...@posting.google.com>,
// <news:ckqtpm$mha$1@phys-news1.kolumbus.fi>...
// > Greetings!
// >
// > I have been wondering how should I implement movement speed into my
// > current project.
//
// I don't have any help here, except to present a contrarian view.
//
// Why have a movement speed system?

Under my definition of such you simply cannot avoid having one.
Dirt simple I-go-U-go is such a system.  You need to handle moves and
time in some fashion and that's a system...  what's really important
(more than anything else) is that the designer actually understand what
they've done.  It's far too easy to jump in, create a system, and assume
things are working without thinking further about it... time and speed
systems are extra deceptive this way (part of the problem is that the
actual time passage in a RL is surreal to the player... real time vs
game time snaps back and forth freely because every move is followed by
a pause).

// Roguelikes are about tactical combat.  Tactical combat requires
// control, on the part of the player, of the mechanisms of combat.  Fine
// grained movement systems (such as priority queues, etc), are difficult
// to understand.  One cannot predict double attacks, etc.  Thus, double
// attacks cannot become part of the player's strategies.

That depends on the system.  If you're using a priority queue with float
times adjusted by a normal distribution, you can't predict accurately
enough... and if you're using a funky curve table like Angband, then
that makes it difficult to predict in advance.  If the system is fairly
simple, it's at least learnable (Angband is learnable by experiment...
monsters don't use the full granularity which makes things simple).
I've had no trouble predicting things like double attacks with a little
experimentation in many games... it's typically a simple modula effect.

// I contend that movement systems should be as simple as possible.

Simple systems are very good.  Easy to understand, easy to get working
properly.  Not weighted down with a lot of small factors which almost
never mean anything.

// it seems silly to try to make time continuous.

It's not really about making time continuous... you certainly don't need
to do that if you don't want to.  It's more about avoiding distortions
that will confuse the designer and player in my books.  

// POWDER uses the simplest level of movement speeds I could think of.  I
// believe it is very close (or matches) the old Nethack system.

The simplest is straight I-go-U-go.  It works very well, but most people
aren't happy to leave it that way.  Phase systems like yours also work
pretty well... they can break up the flurry effect in a reliable way in
the same way that tracking energy can.

// I personally think priority queue and energy based speed systems are
// one of the siren calls of roguelike development.  IMO, they do nothing
// but add static between the player and the gamespace.  

Depends on what you're doing with them.  If you're regularly stiring the
internal state with different movement costs, then you're increasing
the perceived entropy.  If everything costs the same amount, but only
the monster speeds vary then it's highly predictable (ie this monster
hits me every 5th turn when I run away from it, thus it has a 6:5 ratio
against my constant player speed).  It's all in how you use them...
they don't have to do that (the problem is that most people abuse
them when simplicity is better).

// My favorite portion of roguelikes is the Critical Moment.  This is
// where your character is about to die and it is up to you to rescue
// him.  You have one move.  What do you do?  In my ideal roguelike,
// there is always something I could have done that I realize *after* I
// get my Do You Want Your Possessions Identified?  This Critical Moment
// can never include multi-turn actions.  Furthermore, multi-turn actions
// are usually merely performed in a safe area, and, by game design, not
// be required at Critical Moments.  Thus, why not allow them at Critcial
// Momements?

Why?  Because you don't want to give the player that option as a design
decision.  Plain and simple.  If you've chosen to have some actions
be nontactic multiturn actions that should be done in safe areas, then
that's what they are.  Simple, sometimes you just don't want things to be
an option... it's reasonable to not want the player to be able to switch
out of platemail in the middle of combat, if they could it might break
other features.  For example, you might have platemail being incredibly
good (and thus highly desirable) protection... and then balance that by
having it strongly effect to-hit unless properly fitted back in town
and then trained in.  If the player was able to quickly swap it off
whenever they ran into agile opponents then you'd still not be balancing
it at all... you'd have a non-cost.  Similarly, you might just want to
limit the number of swapable equipment slots, or simply make the slots
behave differently (ie poison resistance on a ring can easily be swapped
in and out freely which makes it more practical than the platemail of
poison resistance (which isn't convenient for that, but is convenient
in that it provides gobs of AC as well)).  

In short, the reason not to allow an action to be tactical is because
it's being used as part of the game balance.  You can, of course, balance
things in different ways and freely allow all actions to be tactical as
a design decision...  the key is that the entire system works together,
not just each separate corner.

// In POWDER, you may with three turns forget a spell, learn the Cure
// Poison Spell you had been neglecting, and then cast it.  This means
// with three turns to death from deadly poison you have a way of getting
// out.  Traditional roguelikes would have you die of the poison before
// you could learn the spell.

Depends on the game.  In Moria/Angband it only takes 2, since you don't
have to a spell (but do need to keep a slot around for emergencies).
Again, this is a design choice... it might not be desirable to the
designer to have the player capabable of swapping Cure Poison in and out
every time they need it.  If they want those slots to be sacrosanct and
the player to have to plan in advance and live with their decisions then
it's completely reasonable to disallow this type of play.  The player
should have either used a form of poison resistance, carried the correct
potions, or learnt the spell previously (esp. if they didn't have those
items) in such a "Be prepared" system.

Brent Ross

I'm glad you brought in your definition in order to make my statement
trivially false.  That certainly contributes a lot more than trying to
understand the point I was getting at.

You are, of course, correct that any turn based system has some method
of determining turn order.  And that system is thus a movement speed
system.

It is about making time continuous.  In a pure-phase based approach,
time moves in discrete intervals.  Your poison-effect time, for
example, occurs on certain phases, rather than as a continuous damage
over time.

My goal isn't for breaking up the flurry effect.  I was quite happy
with the one-turn-per-mob approach.  (I do not like the I-go-U-go
terminology as it is highly player centric)  It was instead to allow
the player to develop differences in speed.

Which would be why I call them a siren call.  People can't leave well
enough alone and start adding tonnes of static to the system thinking
they are increasing depth.

Didn't we have this argument just recently?  If you don't want
switching platemail in battle, prohibit switching platemail in battle.
 I'm all for such design decisions.

You should not try and hammer the players behaviour through the use of
movement penalties.  It'll just result in abuse, YASDs, and cries for
"Do you want to continue..." prompts.

That is not desireable in POWDER, and is not possible in POWDER
either.  Spellbooks are a finite resource, so one will not casually
swap in and out spells.

Again, you seem to be thinking I'm arguing for the need to be able to
switch spells tactically.  I'm instead arguing *against* using time as
a method to prevent such things.  If you don't want spell switching,
there are other approaches.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)

In article <774acfb8.0410201952.6860...@posting.google.com>,
// bwr...@csclub.uwaterloo.ca (Brent Ross) wrote in message
// > Jeff Lait <torespondisfut...@hotmail.com> wrote:
// > // Joel <j...@none.nowhere> wrote in message
// > // > Greetings!
// > // >
// > // > I have been wondering how should I implement movement speed into my
// > // > current project.
// > //
// > // I don't have any help here, except to present a contrarian view.
// > //
// > // Why have a movement speed system?
// >
// > Under my definition of such you simply cannot avoid having one.
// > Dirt simple I-go-U-go is such a system.  
//
// I'm glad you brought in your definition in order to make my statement
// trivially false.  That certainly contributes a lot more than trying to
// understand the point I was getting at.

Oh, I got your system... it's quite good (I'm not disagreeing with it
at all).  My point was mostly that you seemed to be being overly glib
here... trying to set yourself up as something completely opposite, when
you've just got something different.  I can't really see how your system
doesn't qualify as a speed system... it's even more so than I-go-U-go.

// You are, of course, correct that any turn based system has some method
// of determining turn order.  And that system is thus a movement speed
// system.

More than just turn order...  you do speed as well (being can act on
different numbers of phases in the cycle).  It's very much a speed system.

// > // it seems silly to try to make time continuous.
// >
// > It's not really about making time continuous... you certainly don't need
// > to do that if you don't want to.  It's more about avoiding distortions
// > that will confuse the designer and player in my books.  
//
// It is about making time continuous.  In a pure-phase based approach,
// time moves in discrete intervals.  Your poison-effect time, for
// example, occurs on certain phases, rather than as a continuous damage
// over time.

You missed the point here, too.  I was merely saying that making time
continuous wasn't a necessary goal.  I certainly wasn't taking about
poison effects in my post, since they weren't important to what I was
saying... however, make them continuous or not if you want to, it's a
design decision and can be do if you choose to (continuous would be too
much trouble for me to bother).

// > // POWDER uses the simplest level of movement speeds I could think of.  I
// > // believe it is very close (or matches) the old Nethack system.
// >
// > The simplest is straight I-go-U-go.  It works very well, but most people
// > aren't happy to leave it that way.  Phase systems like yours also work
// > pretty well... they can break up the flurry effect in a reliable way in
// > the same way that tracking energy can.
//
// My goal isn't for breaking up the flurry effect.  

That was a complement... I wasn't saying that you were trying to
do that... only that it does do that and that's good.

// I was quite happy with the one-turn-per-mob approach.  

The flurry effect isn't about mobs.  It's about bunched fast attacks and
happens just as much one-on-one.  It's plain silly to take a 6:4 attack
speed ratio and have it implemented as I get my 6 attacks, then you get
your 4.  If you're going to do that you might as well abstract attacks
out of the picture.

// (I do not like the I-go-U-go
// terminology as it is highly player centric)

What does liking the terminolgy have to do with it?  I-go-U-go isn't
really player-centric originally anyways (as it applies to war games,
where U is also typically a human player).  But in a RL, I-go-U-go is
naturally player-centric... there's no doubt about it, the monsters
always get their turns after the player finally moves.  The fact that
you find the term player centric is too be expected... it pretty much is.

Oh, I wasn't saying yours was I-go-U-go... only that that's the simplest
you can get.  Your system is more complicated than that.

// It was instead to allow the player to develop differences in speed.

I don't see any room for development... you've got a rather simple
table that tells them their phases and that gives them their speed.
Seems to be nice and simple and static to me.

// > // I personally think priority queue and energy based speed systems are
// > // one of the siren calls of roguelike development.  IMO, they do nothing
// > // but add static between the player and the gamespace.  
// >
// > Depends on what you're doing with them.  If you're regularly stiring the
// > internal state with different movement costs, then you're increasing
// > the perceived entropy.  If everything costs the same amount, but only
// > the monster speeds vary then it's highly predictable (ie this monster
// > hits me every 5th turn when I run away from it, thus it has a 6:5 ratio
// > against my constant player speed).  It's all in how you use them...
// > they don't have to do that (the problem is that most people abuse
// > them when simplicity is better).
//
// Which would be why I call them a siren call.  People can't leave well
// enough alone and start adding tonnes of static to the system thinking
// they are increasing depth.

Oh, I was thinking of "siren call" as something that looks good but ends
up being certain doom.  It's clearer now that you meant just potential
threatening doom to the incautious.

// > // My favorite portion of roguelikes is the Critical Moment.  This is
// > // where your character is about to die and it is up to you to rescue
// > // him.  You have one move.  What do you do?  In my ideal roguelike,
// > // there is always something I could have done that I realize *after* I
// > // get my Do You Want Your Possessions Identified?  This Critical Moment
// > // can never include multi-turn actions.  Furthermore, multi-turn actions
// > // are usually merely performed in a safe area, and, by game design, not
// > // be required at Critical Moments.  Thus, why not allow them at Critcial
// > // Momements?
// >
// > Why?  Because you don't want to give the player that option as a design
// > decision.  Plain and simple.  If you've chosen to have some actions
// > be nontactic multiturn actions that should be done in safe areas, then
// > that's what they are.  
//
// Didn't we have this argument just recently?  If you don't want
// switching platemail in battle, prohibit switching platemail in battle.
//  I'm all for such design decisions.

That's a different choice.  Platemail is an extreme case... some armours
might not take quite as long and thus become quasi-tactical choices.
If you remove the ability to swap armour entirely in tactic situations
that's no longer possible... on the other hand, you've removed a
potentially nasty form of typo death.  Not one I've ever slipped into
however... deaths while changing armour seem to come in two flavours from
the reports:  death because the player didn't realise that the character
ended up naked (ie was interupted and stopped putting something on)
and death because the player didn't understand the rules (ie didn't
realise that armour took time to change).

Besides, it's hard for the game to determine tactical situations perfectly
(especially if there are things like deceptive monsters)... it's easier
to leave that task up to the player and not have the program do anything
serious with such modes at all.

// You should not try and hammer the players behaviour through the use of
// movement penalties.  It'll just result in abuse, YASDs, and cries for
// "Do you want to continue..." prompts.

It's a design decision.  One of the things that the original design was
intended to do was to provide a lot more granularity to what sould be done
(advent being a text adventure was naturally very ridgid).  There's a long
standing tradition to giving the player the option to make the character
do any of the actions the character can possibly do...  including ones
that are inherently stupid.  In some ways that adds realism, but if
does increase the role of player discipline in the game (the player is
typcially the most dangerous thing to a high level character).  You're
free to change the balance on that tradeoff in your design... it
just changes the level of abstraction.

// > // In POWDER, you may with three turns forget a spell, learn the Cure
// > // Poison Spell you had been neglecting, and then cast it.  This means
// > // with three turns to death from deadly poison you have a way of getting
// > // out.  Traditional roguelikes would have you die of the poison before
// > // you could learn the spell.
// >
// > Depends on the game.  In Moria/Angband it only takes 2, since you don't
// > have to a spell (but do need to keep a slot around for emergencies).
// > Again, this is a design choice... it might not be desirable to the
// > designer to have the player capabable of swapping Cure Poison in and out
// > every time they need it.  
//
// That is not desireable in POWDER, and is not possible in POWDER
// either.  Spellbooks are a finite resource, so one will not casually
// swap in and out spells.

That works... just pointing out that in some games, that idea will
completely break the system.  Your original post seemed to miss that
this could even be the case and that in some games, having the player die
in that situation is expected.  So the fact that traditional roguelikes
would have you die isn't necessarily a problem (your comment does imply
that there's something wrong with them for doing it this way)... it can
easily be very intentional.

// > If they want those slots to be sacrosanct and
// > the player to have to plan in advance and live with their decisions then
// > it's completely reasonable to disallow this type of play.  The player
// > should have either used a form of poison resistance, carried the correct
// > potions, or learnt the spell previously (esp. if they didn't have those
// > items) in such a "Be ...

read more »

On 20 Oct 2004 20:52:25 -0700, torespondisfut...@hotmail.com (Jeff

While I wouldn't call I-go-U-go a movement speed system, since it
essentially makes speed a non-factor, what you described yourself as
using certainly is. The obvious answer to your question is "because
not everyone and everything take the same amount of time".
Slow-but-tough and quick-but-weak monsters are a genre staple, why
would I want to do without? If you want to be understood, you should
use clearer terminology.

The easiest way to do that is to make switching armor take too much
time to do in battle. It avoids trying to define "in battle" for a
start.

R. Dan Henry
danhe...@inreach.com