Movement speed
Joel
I have been wondering how should I implement movement speed into my
current project. I have searched groups.google.com and found some
articles about movement speed. It seems that most people use some sort
of priority queue. I'm not sure if I understood how it should work (or
how should I implement it).
I've been trying to code up some sort of movement system but I just
can't get it quite right. How have you implemented it? I am aiming at
something very simple here because this is my first "proper" project and
I don't want to make awfully complex and advanced game yet :)
The movement speed is one of the last few features I am going to add
before my game engine is "complete". Hopefully I can start adding
content soon and maybe release the game (not a pure roguelike actually
but a very simple RPG).
Thanks in advance,
Joel
The Sheep
> Greetings!
>
> I have been wondering how should I implement movement speed into my
> current project. I have searched groups.google.com and found some
> articles about movement speed. It seems that most people use some sort
> of priority queue. I'm not sure if I understood how it should work (or
> how should I implement it).
I don't rhink most people really use it. It has been discussed a lot,
that's a fact, but then again... nevermind.
The priority queue is like a queue in your uni's buffet -- theoretically
it's first in -- first out, but in practice there are some individuals
that have priority over others.
In normal, round-based system, you've got normal queue. The creatures
wait for their turn, act, and go to the end of queue. Simple.
Then, with priority queue, the creature that just ected doesn't always
go to the end of the queue -- depending on it's priority, it may go
somewhere in the middle, or even at the beginning. Offcourse it also
depends on the priorities of all other creatures in the queue.
How to set priorities? Just make it the time when the creature is
supposed to act, in some units, like clicks.
You procede as folllows:
- take a creature from the beginning of the queue
- make it act
- add a number of clicks the action took to the creature's priority
- put the creature back into queue, at the place it belongs to
according to it's current priority, the creatures with the smallest
one goes first.
- repeat
You can easily find some algorithm for efficient priority queue
implementation, or use any of the libraries with implemented and
ready-to-use algorithm.
> I've been trying to code up some sort of movement system but I just
> can't get it quite right. How have you implemented it? I am aiming at
> something very simple here because this is my first "proper" project and
> I don't want to make awfully complex and advanced game yet :)
Then make it `double speed' and `half speed' thingies -- the first making
a creature act twice a turn, the second making it act once every other
turn.
You can apply those bonuses to any action, or to movement actions only
if you like.
Note, that for a simple roguelike, the player character has always normal
speed, and all the speed bonuses and penalties apply only to the monsters.
So you can have things that are hard to control for the player, but not
for the AI -- like one movement and one non-movement action at the same
turn. Or two shooting actions, etc.
> The movement speed is one of the last few features I am going to add
> before my game engine is "complete". Hopefully I can start adding
> content soon and maybe release the game (not a pure roguelike actually
> but a very simple RPG).
Yay! Looking forward to seeing your game.
--
Radomir `The Sheep' Dopieralski
You only need pen and paper to do philosophy.
To do mathematics you need pen, paper and a trash can.
Brent Ross
Joel <jo...@none.nowhere> wrote:
// Greetings!
//
// I have been wondering how should I implement movement speed into my
// current project. I have searched groups.google.com and found some
// articles about movement speed. It seems that most people use some sort
// of priority queue. I'm not sure if I understood how it should work (or
// how should I implement it).
Actually, most people probably use an time/energy system. Basically,
you either give each monster a fixed amount of time each turn and have
movement cost different amounts... or you do the inverse and give the
monster a weighted amount of energy each turn and have movement cost a
fixed amount. In either case you need to scale the amount of time/energy
to the speed (time taken) of the PC (assuming the PC can move at different
rates). You then get the choice of having each monster spend all of
their energy all at once (each monster moves uninterupted by others),
or repeatedly looping through the monsters giving them the opportunity
to spend until no monster has enough energy left (monsters take turns
making one move each). Also at issue is the order in which you go
through the monsters... if it's a simple loop through indexes, then
a snail that's getting a single move this round might go first blocking
a bat that's getting 3 moves (and independantly would have been expected
to get in front of the snail first).
It's a very simple system, but it can be prone to distortions if you're
not careful. Most notably are durational effects, which if done as
simple turn counters, you have to be mindful as to how long they are
taking with respect to the relative PC and monster speeds.
For example, consider a monster with a durational effect on it and the PC
speeds up (and let's say the implementation gives the monster less energy
to compensate for the PC actions take less time). The monster might now
get to move after every player action now... but are the duration counters
in the implementation being reduced when the monster gets a move or when
the monster gets a chance to move (ie once per player move you run all the
monster durations, regardless of whether they get 3 moves or 1 every two)?
Consider this from the perspective of the monster... if the former then
the effect will last the same number of "monster moves" as it did before,
but if the later then it will appear to the monster to run out quicker.
Also consider what happens here if the PC slows down (and the monster
gets more energy, and can afford multiple actions to the PCs one),
what does this mean for the duration counters in the implementation?
If it's done on the chance to move (once for however many multiple
moves the monster might be getting) then the durational effect will
seem to take longer for the monster now. So it seems like you
want to have the counter reduced on each monster action, right?
But, you also need to consider the different speeds of different monsters
and compare the durations with respect to a constant speed player...
does a durational effect of the same length take different amounts of
time for a bat and a snail (in the absolute timeframe of an independant
constant speed observer)? Let's consider a duration that would last 5
turns, and we're reducing on each monster move. On a bat (3x speed),
that would be over and done with in 2 turns of our observer, while the
same effect on a snail (0.5x speed) would not finish until 10 turns
have past. If the reduction was done on the chance to move, they'd both
be equally long to the independant observer (the bat would lose a point
each flurry of 3 moves, and the snail would lose a counter even on the
turns when it can't move). So now it appears that what you want is
to have such counters reduced on each chance of monster actions.
This is the type of potential distortion you need to look out for...
one system here has problems with respect to the change in PC speed,
and the other has problems with respect to different monster speeds.
For some people, it's as easy to resolve as saying "poison (and such)
runs it's coarse faster on faster monsters (higher metabolism)", and
accept the later system. This is perfectly acceptible (the designer knows
what's happening and has made it a feature... which is far better than
not knowing and expecting something different is happening). However,
it does give up control (you can't have a high metabolism monster
that moves slowly, some durational effects might also not be as easily
explained, etc).
Fortunately, you don't have to accept such a situation. This is where
the concept of tracking absolute time comes in. The problem with
the implementations above is that they're always relative to the time
frame of a particular being (either the monster (1 per monster move) or
the player (1 per player move)). If you, instead track the passage of
time independantly, you can get around these problems. Basically, when
the player makes a move, increment the absolute clock by the amount of
time it took... the monsters get their time/energy allotment as before,
but now the the durational effects are decremented based solely on the
absolute clock (for example, 1 per 100 ticks you run a function that
applies/decrements the effects). Anything that wants to guarantee how
much time its taking can just reference this clock and know that it's
independant of PC/monster time frames. It does have some slight oddities
of granularity however, since the increment is tied to the amount of
time of a PC action, the effects only go off after such... this can be
a bit odd if it causes multiple decrements to happen all at the same
time: something like "PC move, effect, effect" instead of "PC starts
move, effect, PC ends move, effect". Still, that's quite acceptible...
and if it wasn't, you could change it so the clock was incremented one
tick at a time... then checking to see if it was time to do anything (like
allowing the player to make a move (thus removing the player-centricity),
move a monster, decrement a counter, etc).
This leads us to priority queues. Priority queues take this one step
further. They say, "most of the clock ticks we don't have anything to do
which means that we can skip all the way to the next scheduled action".
And that's what a priority queue does... it keeps a queue, where the
item at the front is always the next action to be done (and the time
it will occur at). When an action is completed, you just have to grab
the next action, advance the absolute clock to that time and perform
the action. Whenever something causes an action to happen in the future
(ie the player makes a move causes the player's next move to happen a
certain amount of time in the future)... then you simply place the new
action in the queue at the correct point (ie between the items that
go before and go after it). Everything is nice an independant... you
don't have to worry about durations, monster order (bats will race in
front of snails except when the snail has initiative from not moving
too recently), or player-centric clock effects... and things scheduled
for 200 ticks go off exactly between 199 and 201. It's a nice little
abstraction, but it's not something you should feel compelled to have to
do (it's probably overkill if you're not confortable with the priority
queues... I'd suggest going with at least a concept of absolute time,
even if it is player-centric since that's got minor issues and is still
very controlable). What you should do is take a look at how time flows
in whatever design you choose and see if you find things acceptible.
Brent Ross
Cyrus Dolph
> I have been wondering how should I implement movement speed into my
> current project. I have searched groups.google.com and found some
> articles about movement speed. It seems that most people use some sort
> of priority queue. I'm not sure if I understood how it should work (or
> how should I implement it).
I strongly recommend against using a priority queue. I used one for a
while in ZapM and it was a big headache to maintain all the scheduled
events (serializing for saving/loading, eliminating events associated
with a dead monster, readjusting events when a creature's speed
changes, etc.). Also, the queue encourages you to measure variables
in units of time instead of in units speed of speed - I believe it is
much easier for the player and designer to think in terms of speed.
The Angband style energy system is superior, I believe. You can read
about it here:
http://www.thangorodrim.net/TANG/#time
Cyrus
Brent Ross
Cyrus Dolph <cy...@zapm.org> wrote:
// In article <ckqtpm$mha$1...@phys-news1.kolumbus.fi>, Joel wrote:
//
// > I have been wondering how should I implement movement speed into my
// > current project. I have searched groups.google.com and found some
// > articles about movement speed. It seems that most people use some sort
// > of priority queue. I'm not sure if I understood how it should work (or
// > how should I implement it).
//
// I strongly recommend against using a priority queue. I used one for a
// while in ZapM and it was a big headache to maintain all the scheduled
// events
Sounds like you're going for overkill...
// (serializing for saving/loading,
I've never had any problems... front to back it's a nice static image of
the current shape of time. There is the issue of cross referencing, but
that shouldn't really be a problem as there are plenty of other things in
serialiation that require such, so you typically have handles for things
like monsters and items already (and queue items isn't much harder to
add if you want to store references to them in monsters, for example).
// eliminating events associated with a dead monster,
You don't have to do this if you don't want to... just validate
the items on the queue as they come up and discard the ones that
no longer apply.
// readjusting events when a creature's speed changes
Typically easy to do... in a lot of systems there's only one event that
needs to be changed: the one that gives the monster its next action (of
which there should always be just one of these at a time). You could
simple allow the distortion of just accepting that there will always be
one action at the old speed if you want to... or just change it (it's
not so hard to scale a delta time and reprioritize the item). Using a
priority queue is typically a sign that you don't want your durational
effects tied to monster speed at all, so this could easily be all that
needs doing (ie you'd change the speed of a durational effect only when
it's directly targeted... eg a Slow Poison spell... again, if you
chain these (each one scheduling the next as part of it's action) then
you never have to worry about doing more than one at a time (which
makes it easy to add the event to a structure)).
Even if you did have multiple different effects that you want to change
with a change in speed it's not difficult. Walk the queue and everytime
you find one of that monsters items, check to see if it's time effected
and reprioritize them. If all changes to monster speed are forced
through the same function, then it's three lines of code that you can
guarantee to always work.
// Also, the queue encourages you to measure variables
// in units of time instead of in units speed of speed - I believe it is
// much easier for the player and designer to think in terms of speed.
They're inverses of each other (ie speed 2.0x equals time 0.5x), and
as someone who's done quite a bit of roguelike design, I can tell you
that both formats are very useful (but for different things... typically
speed makes more sense for monsters (although it's often easier to compare
things between two monsters in terms of time), but time makes more sense
for durations) and converting between them in your head becomes second
nature. In fact, it would be nothing to implement an function to do the
inverse operation in your game so that you could use either format freely.
// The Angband style energy system is superior, I believe.
I has some issues... among them is the fact that the energy curve allows
for slower monsters to sometimes get double moves. One of the things
I liked about CthAngband was that it inverted the energy system into
a time one and thus broke up the attack flurry effect (which combined
with the damage system was pretty silly... you get things like the PC
fighter hitting 6 times in a row for (small dice) + 1000 pts of damage
before a monster with 4 attacks can attack once, then that monster gets
all 4 of its attacks in standard I-GO-U-GO fashion).
Brent Ross
Ray Dillinger
> I strongly recommend against using a priority queue. I used one for a
> while in ZapM and it was a big headache <snip>
My first priority queue implementation was also a massive headache.
It took some different abstractions for working with it before it
got easy. It's no longer a strict priority queue; now it's an
array of linked lists, which is easier to work with in several ways.
it still has priority-queue functionality, but it's also got some
good random-access things going for it now that make it easier to
work with.
Basic algorithm... Different actions take different numbers of pulses.
Thus, for example, firing a bow always takes longer than swinging a
sword (2.5 pulses versus 1.5 to 1.2 depending on the size of the sword).
And each monster gets a different number of pulses per game minute
depending on its speed (snails get a speed of 1 to 1.2, turtles 1.7
to 2, Normal humans and most monsters get around 10, player
characters are usually between 12 and 17, quicklings get 22 to 28,
etc).
So, basically, if you decide to walk one square (1 pulse) and you
have a speed of 12.2 (12.2 pulses per game minute) you'll use up
1/12.2 of a minute doing it. Your "next action" time is set back
a bit less than five seconds, and into the priority queue you go,
sorted by your time of next action.
Then you ask the priority queue - who's next? Which monster has
the earliest next-action? And you process that monster's action
and set him back in the queue, etc.
> to maintain all the scheduled events
> (serializing for saving/loading,
Serialization of the priority queue is not an issue. If you save
all the monsters, you're saving their next-action times. Rebuild
the priority queue when restoring the game.
> eliminating events associated with a dead monster,
I initially had a problem removing dead monsters from the
priority queue before their turn came up, because I needed
to coordinate references between the priority queue and the
map. Then I realized there was no need to do that. Now
dead monsters are simply displayed as corpses until their
turn comes around. And then, noting that the creature is
dead, the system reassigns it a much lower speed (I think
corpses are all speed 0.01). The "action" for a corpse is
to increment the rot counter.
> readjusting events when a creature's speed changes,
Why? When the creature's speed changes, it's subsequent
actions will take longer or shorter amounts of time. You
do "latent actions" like healing, taking poison/bleeding
damage, etc, every time its turn comes around based on
the number of pulses it's using. No other events require
adjustment.
> Also, the queue encourages you to measure variables
> in units of time instead of in units speed of speed - I believe it is
> much easier for the player and designer to think in terms of speed.
In fact, there are two different measures of speed that are
worthwhile to think about. The first is pulses; is it unbalancing,
for example, for firing a bow to take twice as long as attacking
with a dagger? And the second is monster speed; can the tortoise
be an interesting addition to the game despite being 1/6 or less
as fast as the player character? Conversely, are quicklings with
ranged weapons too heinous? I rarely think of game time in
minutes and seconds.
Bear
Glen Wheeler
"Ray Dillinger" <be...@sonic.net> wrote in message
news:zPjcd.17512$54.2...@typhoon.sonic.net...
This is all well-and-good, however without absolute time (as Brent
suggests) I think it will be dififcult to display persistent effects
consistently.
Currently, since my project is so immature, I have no persistent effects
and am using a system identical to the above (replace ``pulse'' with
``energy''). However I think things will have to change when I want a
*real* stinking cloud spell (NOT stinking grenade).
What is your solution? No persistent effects?
--
Glen
L:Pyt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-
W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+
Ray Dillinger
> This is all well-and-good, however without absolute time (as Brent
> suggests) I think it will be dififcult to display persistent effects
> consistently.
> Currently, since my project is so immature, I have no persistent effects
> and am using a system identical to the above (replace ``pulse'' with
> ``energy''). However I think things will have to change when I want a
> *real* stinking cloud spell (NOT stinking grenade).
> What is your solution? No persistent effects?
My solution is that the stinking cloud itself becomes a "monster"
temporarily. Casting it is handled by the same code as, eg,
summoning an imp. It's just a really simple-minded monster. It
hangs out where it is, does damage in an area effect whenever
its next turn comes around, and then eventually
expires/dies/dissipates.
Bear
Brent Ross
// "Ray Dillinger" <be...@sonic.net> wrote in message
// > Basic algorithm... Different actions take different numbers of pulses.
// > Thus, for example, firing a bow always takes longer than swinging a
// > sword (2.5 pulses versus 1.5 to 1.2 depending on the size of the sword).
// > And each monster gets a different number of pulses per game minute
// > depending on its speed (snails get a speed of 1 to 1.2, turtles 1.7
// > to 2, Normal humans and most monsters get around 10, player
// > characters are usually between 12 and 17, quicklings get 22 to 28,
// > etc).
//
// This is all well-and-good, however without absolute time (as Brent
// suggests) I think it will be dififcult to display persistent effects
// consistently.
Actually, the essence of absolute time is there. In a given amount
of absolute time, each entity is getting their alloted amount
of pulses/energy to spend on constant cost actions. The question
would really be: How accessible is that notion of absolute time to a
persistent effect? I think it's probably pretty trivial, since his
queue knows about the passage of minutes (pulse/energy is converted to
time for queueing)... he should be able to easily queue an event to say
"make this stinking cloud go away after 1 minute" without any problems.
Brent Ross
Joel
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
Pfhoenix
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
Jeff Lait
> 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?
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)
Graeme Dice
> Joel <jo...@none.nowhere> wrote in message news:<ckqtpm$mha$1...@phys-news1.kolumbus.fi>...
>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.
You can't have played many Roguelikes with a speed system then. You
could go play ADOM, where the difference between a speed of 95 and 100
is very noticeable when to try and run away from the village carpenter.
> To make a long story short: Start working on your content already.
> That is infinitely more important than the engine.
Content only exists in the context of the engine. Without the engine,
you are simply throwing ideas out there that have no implementation.
--
"If at first you don't succeed, you are running about average."
-- M.H. Alderson
David Damerell
>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.
Attacks of opportunity could limit the most egregious abuses of double
moves.
>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?
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 <dame...@chiark.greenend.org.uk> Distortion Field!
The Sheep
> Joel <jo...@none.nowhere> wrote in message 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?
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.
Brent Ross
Jeff Lait <torespon...@hotmail.com> wrote:
// Joel <jo...@none.nowhere> wrote in message
// 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
Jeff Lait
> In article <774acfb8.04102...@posting.google.com>,
> Jeff Lait <torespon...@hotmail.com> wrote:
> // Joel <jo...@none.nowhere> wrote in message
> // 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.
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 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.
> // 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. 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.
> // 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.
> // 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.
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.
> // 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.
> 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.
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.
Brent Ross
Jeff Lait <torespon...@hotmail.com> wrote:
// bwr...@csclub.uwaterloo.ca (Brent Ross) wrote in message
// > Jeff Lait <torespon...@hotmail.com> wrote:
// > // Joel <jo...@none.nowhere> wrote in message
// > // > Greetings!
// > // >
// > // 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 prepared" system.
//
// Again, you seem to be thinking I'm arguing for the need to be able to
// switch spells tactically.
Not at all... you just were putting up the case in a "I can't see why"[1]
fashion. Obviously, you were asking why things would be done with
multi-turn actions... so I responded that they're a valid option in
perfectly good designs.
// 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.
Sure there are... but using multiturn actions also works quite well.
And as pointed out above, it has some granularity and tradeoff that's
easily understood (takes a certain number of actions to complete) and that
can make it quasi-tactical. The thing about using multi-turn actions is
that they can fit in with the simulation in a natural way... it's less
arbitrary to say that taking off a piece of armour takes 3 steps (costing
one action each) than it is to say that armour cannot suddenly not be
taken off because the game doesn't allow it... people naturally understand
that getting dressed, especially in metal gear, takes time and effort
(what the might not understand is that it's actually implemented... but
that's acceptible). More natural limitations tend to work better, are
more easily understood[2] and remembered, and allow for better roleplaying.
Brent Ross
[1] See lines like: "Thus, why not allow them at Critcial Moments?"
[2] Especially if its quaint or subtle... but never underestimate the
densitiy of the players, the universe keeps making more dense ones
every day... subtle to some is a sledge hammer up the side of the head
to others.
SZDev - Slash
news:O5lcd.17516$54.2...@typhoon.sonic.net...
I handle this differently, the stinking cloud is something related directly
to the World, so the World has to handle it; what I mean is that an Actor
may choose through a CastSpell Action to start a StinkingCloud of a definite
size in certain point of the map; now, the stinking cloud is handled by the
World itself, as no actor has control over it, through an AbstractActor
called the WindGuardian, which takes all lighterThanAir things in the worlds
and moves them according to a pattern.
I have currently used this successfully for explotions and fires.
> Bear
>
>
>
>
>
--
SZDev - Slash
Slashing, the Outcast Dragon of the -={UDIC}=-
Weblog: http://www.livejournal.com/users/szdev
Website: http://szdev.cjb.net
R. Dan Henry
Lait) wrote:
>bwr...@csclub.uwaterloo.ca (Brent Ross) wrote in message news:<cl660i$fjm$1...@rumours.uwaterloo.ca>...
>> In article <774acfb8.04102...@posting.google.com>,
>> Jeff Lait <torespon...@hotmail.com> wrote:
>> // Joel <jo...@none.nowhere> wrote in message
>> // 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.
>
>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.
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.
>Didn't we have this argument just recently? If you don't want
>switching platemail in battle, prohibit switching platemail in battle.
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
danh...@inreach.com
Martin Read
Here's a nice simple definition:
"in battle"="currently exposed to attack". So, a melee-capable monster
next to you (or in a position to close down the range), or a missile-
capable monster in line of sight, or recently attacked by an
imperceptible monster.
--
Martin Read - my opinions are my own. share them if you wish.
Brent Ross
Martin Read <mpr...@chiark.greenend.org.uk> wrote:
// R. Dan Henry <danh...@inreach.com> wrote:
// >On 20 Oct 2004 20:52:25 -0700, torespon...@hotmail.com (Jeff
// >Lait) wrote:
// >>Didn't we have this argument just recently? If you don't want
// >>switching platemail in battle, prohibit switching platemail in battle.
// >
// >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.
//
// Here's a nice simple definition:
//
// "in battle"="currently exposed to attack". So, a melee-capable monster
// next to you (or in a position to close down the range), or a missile-
// capable monster in line of sight, or recently attacked by an
// imperceptible monster.
That last condition is the start of the problem. How recent? Can I
shoot a monster with a wand of make invisible to do this (and if not,
can I count on monsters not to do that for me)? Can I temporarily
remove my own ability to see invisibile or completely blind myself
for a quick swap, then restore my sight? What about mimic monsters
(these can easily cross over into the realm of unknowable (to the game)
player knowledge... how can we judge the player's own capability to judge
such a position as tactical, we don't have read access to their brains)?
Why is it possible that a blind, ignorant character is capable of doing
something normally impossible?
Using tactic situations as a restriction absolutely is messy. In this
case the rule is that changing armour just isn't possible in the
time frame of a tactical situation... but since the character might
not be aware (even if the player may be) of a monster in the area
you end up doing one of two things:
(a) Potentially giving the player information they shouldn't have by
not allowing the character to change armour with no apparent threat.
or
(b) Allowing less capable characters to do what's technically impossible.
For example, an elf (with see invisible) wouldn't be able to change
armour in the same room as a human (without see invisible), simply
because they perceive a threat. The ignorant human would not only be
capable of changing, but because the restriction is absolute (yes/no)
and not balanced in turns... they can do it remarkably quickly in a
tactical situation (simply because they're ignorant of the threat, they
become hyperefficient at armour swaps). It's simply an unfair situation
that penalizes characters simply for being more capable.
Brent Ross