Mostly Turn-based Multiplayer Timing
Isaac Kuo
I've got an idea for multiplayer timing which is more turn based
than realtime. I'm not sure how surreal time works, so I'm not
sure if this is different or not.
My basic idea is to be strictly turn based except when players are
nearby each other (nothing new). When players are near each other,
it remains essentially turn based as long as all players make moves
quickly enough. However, if a player takes too long to make a move,
he "loses" his turn--the amount of time it takes to "timeout" is
longer depending on how close the player is to other players.
Actually, the player doesn't "lose" a turn, so much as delay it,
since he is given highest priority so he can take his turn at any
time (i.e. without waiting for everyone else to take another turn).
Furthermore, the harmful effects of delaying a turn are mitigated
by the fact that generally monsters attacking the player will
still wait for that player to move before acting. In a game which
disallows player-player attacks, this means a player is generally
safe taking as much time as desired thinking out the next move.
The main disadvantage to this approach is that it's possible to
abuse the system cooperatively. A player which is in trouble
can simply stop moving, allowing another player to come to the
rescue no matter how long it takes. This disadvantage may actually
be an advantage if the desire is to encourage cooperation.
Here's a description of how "MTbMT" works:
Mostly Turn-based Multiplayer Timing (MTbMT)
The sequence of play is handled in sequentially numbered
"turns", which is further subdivided into "phases". In a turn,
one player moves and then a number of monsters may move. A "phase"
is where one creature performs one action. The first phase of a
turn is always the player's move. The subsequent phases of a turn
are monster actions.
The players do not move in a strict order, but instead are
restricted by waiting for other nearby players to move. Whenever
a player moves, a set of timers is started--one for each
nearby player--according to distance:
1 space = 10 secs
2 spaces = 8 secs
3 spaces = 5 secs
4 spaces = 4 secs
5 spaces = 3 secs
6-8 spaces = 2 secs
9-15 spaces = 1 secs
The player must wait until all these timers run down to zero
before moving. Whenever one of those nearby players moves,
the associated timer drops to zero. Thus, a player can always
move immediately after all other nearby players have moved (since
his last move).
The purpose of these timers is to give all nearby players a chance
to react to the player's move before the player may move again.
After a player moves, he sees the word "wait 9" appear on their
screen if he has had to wait for more than one second, until all
of the timers run down to zero. (The wait counter counts down from
9 or whatever down to zero, based on the highest remaining
timer.) When all the timers run down to zero, the wait
message disappears, and the player may move at any time.
Monsters may move after a player moves. A monster will try to
move if any of the following conditions apply:
1. The current player attacked the monster this turn.
2. The monster is chasing/fleeing/attacking the current player.
3. The current player is a closest player to the monster.
If the monster tries to move, it compares the turn number of its
last move to the turn number of the current player's last move.
If the monster's last turn number is less than or equal to
the player's last turn number, the monster will move.
For example, suppose a pair of players Adol and Bahn are taking
turns attacking a Rat. If the Rat starts off moving on Adol's
turn, it can't move on Bahn's turn, and will wait until Adol's
turn again before moving. The turn sequence looks like:
1. Adol, Rat
2. Bahn
3. Adol, Rat
4. Bahn
5. Adol, Rat
What happens if Adol waits too long and Bahn moves twice in a row?
Then, the Rat will be able to move on Bahn's turn.
1. Adol, Rat
2. Bahn
3. Bahn, Rat
4. Adol
5. Bahn, Rat
In this case, it's possible for Adol to be attacked twice
before reacting--but only because Bahn was nearby and Adol's
move timed out. In the case of being attacked by an adjacent
monster with Bahn also next to the monster, it would have
taken at least 8 seconds for his turn to timeout before Bahn
could make a move (thus allowing the monster another turn).
Isaac Kuo
NN
> The players do not move in a strict order, but instead are
> restricted by waiting for other nearby players to move. Whenever
> a player moves, a set of timers is started--one for each
> nearby player--according to distance:
>
> 1 space = 10 secs
> 2 spaces = 8 secs
> 3 spaces = 5 secs
> 4 spaces = 4 secs
> 5 spaces = 3 secs
> 6-8 spaces = 2 secs
> 9-15 spaces = 1 secs
>
You should leave the times configurable. I and a lot of people like nethack
as a thinking game, and only having 10 seconds is too little (of cource I
would have to live with waiting for others). Beeing able to configure, a
game can be set up for fast play, or slow play.
jakub
> restricted by waiting for other nearby players to move. Whenever
> a player moves, a set of timers is started--one for each
> nearby player--according to distance:
>
> 1 space = 10 secs
> 2 spaces = 8 secs
> 3 spaces = 5 secs
> 4 spaces = 4 secs
> 5 spaces = 3 secs
> 6-8 spaces = 2 secs
> 9-15 spaces = 1 secs
Well, using long range weapons would be difficult.
Moreover - this system works only for two players.
Let's say you have h2h combat between two players.
All the world is slowing - 10 secs per their move.
If all the world won't stop, monster could kill wasy them
both (he has 100 runds for fire missiles in their 10 turns
of fighting).
Useless.
regards
Jakub
--
www.xenocide.w.pl - SF roguelike in development
Isaac Kuo
>Isaac Kuo wrote:
Well, obviously someone implementing this idea can set whatever
times he wants. The general idea is to have the time limit be
inversely related to distance.
In any case, the time limits should be set by the game administrator,
not individual players. Presumably, the game administrator has the
source code so at worst he can customize the time curve via modifying
source code.
Isaac Kuo
Isaac Kuo
>>The players do not move in a strict order, but instead are
>>restricted by waiting for other nearby players to move. Whenever
>>a player moves, a set of timers is started--one for each
>>nearby player--according to distance:
>>1 space = 10 secs
>>2 spaces = 8 secs
>>3 spaces = 5 secs
>>4 spaces = 4 secs
>>5 spaces = 3 secs
>>6-8 spaces = 2 secs
>>9-15 spaces = 1 secs
>Well, using long range weapons would be difficult.
Why?
>Moreover - this system works only for two players.
>Let's say you have h2h combat between two players.
>All the world is slowing - 10 secs per their move.
No. The "slowdown" is strictly local. You did not read the
description of how it works. (I've included the desciption
again at the bottom.)
Basically, the only players you wait for are the ones
nearby (and only those who aren't moving quickly enough).
I mainly intend this concept to be used in pure cooperative
play where h2h combat is not allowed, but in a sense this
is even more difficult than h2h because it involves parties
of players staying in close proximity for extended periods
of time.
>If all the world won't stop, monster could kill wasy them
>both (he has 100 runds for fire missiles in their 10 turns
>of fighting).
No, monster movement is mostly tied to movement of the nearest
player (there are exceptions when they themselves are attacked
or they are fighting a player which is not the nearest one).
>Useless.
Actually, even pure strict turn based isn't useless--it's merely
practically restricted to a small number of players.
Regardless, you misunderstand the concept. Here is the description
again:
- - - - - - - 8< - - - - - - - cute here - - - - - - - 8< - - - - - - -
Mostly Turn-based Multiplayer Timing (MTbMT)
The sequence of play is handled in sequentially numbered
"turns", which is further subdivided into "phases". In a turn,
one player moves and then a number of monsters may move. A "phase"
is where one creature performs one action. The first phase of a
turn is always the player's move. The subsequent phases of a turn
are monster actions.
The players do not move in a strict order, but instead are
restricted by waiting for other nearby players to move. Whenever
a player moves, a set of timers is started--one for each
nearby player--according to distance:
1 space = 10 secs
2 spaces = 8 secs
3 spaces = 5 secs
4 spaces = 4 secs
5 spaces = 3 secs
6-8 spaces = 2 secs
9-15 spaces = 1 secs
The player must wait until all these timers run down to zero
ABCGi
news:acc26c07.02101...@posting.google.com:
> Mostly Turn-based Multiplayer Timing
>
> I've got an idea for multiplayer timing which is more turn based
> than realtime. I'm not sure how surreal time works, so I'm not
> sure if this is different or not.
>
> My basic idea is to be strictly turn based except when players are
> nearby each other (nothing new). When players are near each other,
> it remains essentially turn based as long as all players make moves
> quickly enough. However, if a player takes too long to make a move,
> he "loses" his turn--the amount of time it takes to "timeout" is
> longer depending on how close the player is to other players.
>
* SNIP*
>
> Here's a description of how "MTbMT" works:
>
> Mostly Turn-based Multiplayer Timing (MTbMT)
>
> The sequence of play is handled in sequentially numbered
> "turns", which is further subdivided into "phases". In a turn,
> one player moves and then a number of monsters may move. A "phase"
> is where one creature performs one action. The first phase of a
> turn is always the player's move. The subsequent phases of a turn
> are monster actions.
>
> The players do not move in a strict order, but instead are
> restricted by waiting for other nearby players to move. Whenever
> a player moves, a set of timers is started--one for each
> nearby player--according to distance:
>
> 1 space = 10 secs
> 2 spaces = 8 secs
> 3 spaces = 5 secs
> 4 spaces = 4 secs
> 5 spaces = 3 secs
> 6-8 spaces = 2 secs
> 9-15 spaces = 1 secs
>
* SNIP *
> Isaac Kuo
Good one Isaac 8)
I like the descending timer. The most important thing for me is that
once all players have moved then there will be no delay (as with your
design). Experienced players will then be less hampered.
Of course the other concerns to be answered related to this in any multi
player system are;
* Quitting - when may a player quit, or save, and what happens? Pretty
easy that one = not in combat.
* Lag - what to do if a players connection is lagging?
* Drop Outs - what to do if a player drop outs in the middle of h2h PK
combat? It may be unavoidable OR intentional to try to avoid death.
* Player Killing rules and Death rules (a whole other discussion :-)
--
ABCGi (geekcode) ab...@codemonkey.com.au S14 D15 C13 I17 W9 c12
GCS/IT$/L/B$ d+(-) s: a? C++ ULUSU-- P+ L+>++ E- W++$ N+ o+ K--
w+++(--)$ O- !M- V PS++(+) PE-@ Y+(++) PGP>++ t++ 5+ X R(+++) tv
b++(+) DI++++ D+++ G e++>+++ h++(home office!) r++ y++* BAS-----
- http://users.bigpond.net.au/abcgi/ - http://www.geekcode.com -
jakub
>
> Why?
Because player have only one second for aiming
and firing. Ok, it's depends how will you solve
them (f.e. one key for shot at last target).
> >Moreover - this system works only for two players.
> >Let's say you have h2h combat between two players.
> >All the world is slowing - 10 secs per their move.
>
> No. The "slowdown" is strictly local. You did not read the
> description of how it works. (I've included the desciption
> again at the bottom.)
I've read it. I think it won't work well, if players/monsters
can use long range weapons (more than 6-8 spaces/2 secs).
I described you the problem:
"If all the world won't stop, monster could kill easy them
both (he has 100 runds for fire missiles in their 10 turns
of fighting)."
example:
.............
..@k.........
.............
.............
.............
.............
.............
.............
.............
...A.........
.............
@k - h2h combat between @ and k
A - Archer
Using your system: Archer can fire 10 missiles
in one turn of @ and k (1 sec per shot, 10 sec
per their move).
For me it's like a using machine gun on handicapped...
ABCGi
I don't think that's how the design stated would work. Methinks a bit of
misunderstanding is going on :-)
Isaac Kuo
>>Mostly Turn-based Multiplayer Timing (MTbMT)
>>The sequence of play is handled in sequentially numbered
>>"turns", which is further subdivided into "phases". In a turn,
>>one player moves and then a number of monsters may move. A "phase"
>>is where one creature performs one action. The first phase of a
>>turn is always the player's move. The subsequent phases of a turn
>>are monster actions.
>>The players do not move in a strict order, but instead are
>>restricted by waiting for other nearby players to move. Whenever
>>a player moves, a set of timers is started--one for each
>>nearby player--according to distance:
>* SNIP *
>Good one Isaac 8)
Thanks!
>I like the descending timer.
Yes, I felt it was especially needed because the amount of time
delay could vary so much in an instant--from almost no time delay
if your teammate is moving quickly to perhaps a 10 second time
delay as he ponders his next move (or his connection goes
haywire). Without some sort of visible indicator of how long
his maximum wait time could be, it could get frustrating.
>The most important thing for me is that once all players have
>moved then there will be no delay (as with your design).
>Experienced players will then be less hampered.
Yes, this was my highest priority, and my main beef with
"realtime" timing. I do not want to force players to wait
when it wasn't necessary.
However, I'll make an exception for running and resting. If
running is "instant", then a party could be spread across an
entire dungeon level and still "come to the rescue" in moments.
(I assume infinite range interplayer communication--if it's not
built in to the game itself that just means players will use
ICQ or AIM.) If resting is "instant", then it's far too easy
for a party to abuse by setting up "time walls". For example,
Adol, Bahn, and Cercia are in a party and Bahn is low on mana.
They can just stand in a corridor with Bahn in the middle, and
he can literally rest in peace while incoming monsters wait
patiently for Adol or Cercia to move (which they don't until
Bahn has recovered).
Thus, I'll put in maybe a limit of 4-8 moves per second on
running and a limit of maybe 3-5 moves per second on resting.
This still allows for the "come to the rescue" and "time wall"
abuses, but at least it will take longer. This will provide
some small incentive to play "normally".
>Of course the other concerns to be answered related to this
>in any multi player system are;
>* Quitting - when may a player quit, or save, and what happens?
>Pretty easy that one = not in combat.
I think maybe saving can work a little like "Word of Recall".
You can request saving at any time but it doesn't actually
happen until a bit later. Thus, you can't reliably use it to
save your skin in combat.
>* Lag - what to do if a players connection is lagging?
>* Drop Outs - what to do if a player drop outs in the middle of h2h PK
>combat? It may be unavoidable OR intentional to try to avoid death.
My take on lagging is to ignore it. If a player's connection is
so laggy that he doesn't enjoy the game, he should stop playing
(or find a different server or connection). From the server's
point of view, there is no difference between a delay caused by
lag and a delay caused by the player. From the ground up, the
game should be designed to allow for "slow" players who take many
seconds to take a turn, so an extra couple seconds due to lag
shouldn't be an issue in and of itself.
My take on drop-outs is to treat it as a save game request. Of
course, this means that saving the game must be allowed anywhere.
The player character may suffer damage/death before the request
is granted!
>* Player Killing rules and Death rules (a whole other discussion :-)
I haven't really thought out player-player combat issues,
mainly because I have absolutely no interest in putting it in
a roguelike. For me, one of the quintessential features of a
fun roguelike is powering upward endlessly from a helpless
novice to nigh-godliness. I just can't see player-player
combat as being fun with such disparaties in power.
Also, player-player combat isn't very compatible with my
philosophy going into my multiplayer roguelike project
(tentatively named Mulrog). My philosophy is to encourage
cooperative party play, and one way is to encourage specialization.
This means amplifying the strengths/weaknesses of specialist
classes (Warrior, Mage, Priest...) while weakening the all
around classes (Ranger, Rogue, Paladin...). If player-player
combat is allowed, specialists will die too easily from an
unlucky encounter.
In any case, if player-player combat is allowed then the timer
curve needs to be expanded in radius to take this into account.
Otherwise, there are serious ranged combat speed-fest issues.
Isaac Kuo
Isaac Kuo
>>>Well, using long range weapons would be difficult.
>>Why?
>Because player have only one second for aiming
>and firing. Ok, it's depends how will you solve
>them (f.e. one key for shot at last target).
There is never any requirement to move quickly (assuming no
player player combat). The monsters will wait indefinitely.
>>>Moreover - this system works only for two players.
>>>Let's say you have h2h combat between two players.
>>>All the world is slowing - 10 secs per their move.
>>No. The "slowdown" is strictly local. You did not read the
>>description of how it works. (I've included the desciption
>>again at the bottom.)
>I've read it. I think it won't work well, if players/monsters
>can use long range weapons (more than 6-8 spaces/2 secs).
You don't understand it. Players and monsters do NOT use the
same rules. This is because the game caters to the players,
not the monsters. Players sometimes need time to think, while
monsters never do. Players are sometimes impatient, while
monsters never are.
Monsters will wait forever until a player moves (either the
nearest one or the one it is fighting). And even when a monster
is attacked or a nearest player moves it is still restricted.
For example, if 5 players are ganging up on a monster, it will
still only move once per "round" rather than 5 times per "round".
>I described you the problem:
>"If all the world won't stop, monster could kill easy them
>both (he has 100 runds for fire missiles in their 10 turns
>of fighting)."
>example:
>.............
>..@k.........
>.............
>.............
>.............
>.............
>.............
>.............
>.............
>...A.........
>.............
>@k - h2h combat between @ and k
Whether or not they are fighting each other is not relevant
to this issue.
>A - Archer
Is Archer a monster?
>Using your system: Archer can fire 10 missiles
>in one turn of @ and k (1 sec per shot, 10 sec
>per their move).
If Archer is a monster, it will not move until a nearest
player or player it is fighting moves. If both @ and k
are taking their time making moves, then A will wait and
move at the rate of the faster player (i.e. if k moves once
every 5 minutes and @ moves once every 7 minutes, A will move
once every 5 minutes).
If player-player combat is allowed, there can be serious
ranged combat issues that can only truly be addressed by
expanding the timer curve. However, it is worth noting that
@ and k are NOT REQUIRED to wait 10 seconds to move. They
can make moves as quickly as they can type them in. The
10 second wait only applies if one of them is taking too
long to make a move.
Personally, I think player-player combat in a roguelike is a
broken concept for more fundamental reasons than any timing
issues.
Isaac Kuo
ABCGi
I think that answers the multiplayer concerns nicely :-) I get the
feeling there might be a better solution for dealing with abuses that
does not get in the road of playing the game, but I can't think of
anything atm.
So as in traditional RogueLikes a death will be final and a new
character will have to be created? Any resurrections by teammates or
such?
Since the game is co-op how will you deal with scaling-up issues (to
make the game more challenging when there are 8 players together instead
of 2 say)?
Isaac Kuo
>>... If resting is "instant", then it's far too easy
>>for a party to abuse by setting up "time walls". For example,
>>Adol, Bahn, and Cercia are in a party and Bahn is low on mana.
>>They can just stand in a corridor with Bahn in the middle, and
>>he can literally rest in peace while incoming monsters wait
>>patiently for Adol or Cercia to move (which they don't until
>>Bahn has recovered).
>>Thus, I'll put in maybe a limit of 4-8 moves per second on
>>running and a limit of maybe 3-5 moves per second on resting.
>>This still allows for the "come to the rescue" and "time wall"
>>abuses, but at least it will take longer. This will provide
>>some small incentive to play "normally".
It has since occured to me that the "time wall" abuse does not
really require any limit on resting speed. Unless the party
is in a very long corridor, Bahn will have to wait 1+ seconds
per resting turn anyway (assuming Adol and/or Cercia are
purposefully not moving to stop incoming monsters).
In a 9 space corridor segment, they are spaced 4 spaces apart
from each other so Bahn will have to wait 4 seconds per resting
turn (according to the example timer curve I gave). That's
enough of a penalty already! I personally wouldn't have the
patience for it and instead would just play normally (Adol and
Cercia move/rest, to minimize the delay between turns). Thus,
this degerates into the legitimate tactic of guarding a weak
character without any time distortion.
Still, I'd rather resting not be completely instant, and will
limit it to perhaps 5 rounds per second.
[...snipped about "word of recall" style saving and disallowing
player-player combat...]
>I think that answers the multiplayer concerns nicely :-) I get
>the feeling there might be a better solution for dealing with
>abuses that does not get in the road of playing the game, but
>I can't think of anything atm.
Of course, this is getting beyond the scope of "Mostly
Turn-based Timing" and into design concepts specific to
my current project (Mulrog). Different solutions would
apply in a project with different goals, especially one
concentrating on player-player combat.
>So as in traditional RogueLikes a death will be final and a
>new character will have to be created? Any resurrections
>by teammates or such?
I am going to have death be final. I think the risk of
death is a thrill present in roguelikes which is lacking in
most online games (and most modern computer/videogames in
general).
>Since the game is co-op how will you deal with scaling-up
>issues (to make the game more challenging when there are 8
>players together instead of 2 say)?
I'm just going to stick with the traditional principle that
you get better stuff in places that are more dangerous. It's
up to the players to decide how much risk they're willing to
take.
Roughly, the limit depends upon how dangerous is too dangerous,
where too dangerous means that a character risks death from a
single blow. Whether the party has 3 members or 30 members,
they'd be foolish to venture where single blow deaths occur.
(Well, I guess an endless raiding swarm of hundreds of
suicidal level 1 characters could theoretically push their
way pretty far past that through sheer mass and persistence.)
Isaac Kuo
Isaac Kuo
>>Since the game is co-op how will you deal with scaling-up
>>issues (to make the game more challenging when there are 8
>>players together instead of 2 say)?
[...]
>Roughly, the limit depends upon how dangerous is too dangerous,
>where too dangerous means that a character risks death from a
>single blow. Whether the party has 3 members or 30 members,
>they'd be foolish to venture where single blow deaths occur.
>(Well, I guess an endless raiding swarm of hundreds of
>suicidal level 1 characters could theoretically push their
>way pretty far past that through sheer mass and persistence.)
Oh...another thing about large parties is that I'm going to
stick with traditional Moria-style dungeon architectures,
mostly. That means someone has got to be the "point man",
and the only way to swap who's in front a lot of times is to
retreat to a corner and coordinate use of diagonal moves.
I'll probably want some dungeons to have 2 or even 3 wide
corridors, but even with wide corridors a large party will
be unweildy.
What I hope to encourage are small parties of specialists,
which won't have to swap positions often. For example, you
could have a swordsman in front as point man, and a mage
supporting with confuse/sleep monster, and a priest supporting
with healing spells and blessings. You could even have a
stealthy thief scouting out far ahead. A couple more warriors,
like an archer and another swordsman could flank the main party
for fighting in rooms and keeping the party guarded in most
directions when navigating corridors.
I'm going to design the classes from scratch to encourage this
sort of thing. For example, mages have mostly negative spells
to use against monsters, while priests have mostly positive
spells to use on player characters. Neither would make a very
good support character on their own.
I'm also simplifying the interface so that you can only hold one
"weapon" in your hands at a time, which is used by a generic
"fire" keystroke. If you want to use a wand, you've got to weild
it first. You can't just slice a kobold with your claymore,
then shoot his buddy with your longbow, then sweep the rest of the
room of hapless monsters with 3 different wands all in a row! No,
you'll have to take a little time to switch weapons. That will
encourage specialization, by encouraging players to stick with one
or two primary weapons they use most of the time.
Isaac Kuo
Isaac Kuo
a party of 3 consisting of warrior (point man), mage, priest.
Then I went and bloated it into scout, warrior*3, mage, priest.
What I was thinking was that is sort of an upper bound of usable
party size.
Isaac Kuo
ABCGi
Hmmm, that should be interesting :-) I can just see some player
blocking another so that s/he gets killed though! With parties of three
or four the monsters will have to be tougher than the usual RL, or more
numerous. Or maybe just characters weaker...
Sounds like if your playing on your own you would choose a fighter,
there should be some things that make the fighter want to have some
magic teammates as much as they want to have him/her.
I like that it will be insta-death, unless one dies during a drop out
:-(
Isaac Kuo
ABCGi <ab...@codemonkey.com.au> wrote:
>mec...@yahoo.com (Isaac Kuo) wrote in
>news:acc26c07.02102...@posting.google.com:
>> Oh...another thing about large parties is that I'm going to
>> stick with traditional Moria-style dungeon architectures,
>> mostly. That means someone has got to be the "point man",
>> and the only way to swap who's in front a lot of times is to
>> retreat to a corner and coordinate use of diagonal moves.
[...]
>Hmmm, that should be interesting :-) I can just see some player
>blocking another so that s/he gets killed though!
That will probably happen alot! But it goes along with what my
personal feeling of what roguelike dungeons corridors should feel
like. Corridors are so cramped, that those monsters have to wait
single file to attack you, and when they finally come to their
senses at 2 HP and realize the true terror of the "@", they can't
run away because all the other foolish monsters in line won't let
them past! Turnabout is fair play, right?
OTOH, reaching back to the original Tolkien source which still
serves as primary inspiration...you've got corridors which may
be narrow but they're still wide enough for both Gandalf and
Aragorn to take the lead. That's why I think dungeons with 2 wide
corridors may be appropriate.
>With parties of three
>or four the monsters will have to be tougher than the usual RL, or more
>numerous. Or maybe just characters weaker...
I think things will work out by themselves letting players
determine how much risk they're willing to take.
>Sounds like if your playing on your own you would choose a fighter,
>there should be some things that make the fighter want to have some
>magic teammates as much as they want to have him/her.
Well, the fantastic rarity of healing items and area effect magic
items could be a factor.
Still, I'm going to keep mixed classes for those who prefer solo
play or very small parties. They just will take longer to power up.
>I like that it will be insta-death, unless one dies during a drop out
>:-(
This is something which will require tweaking. One way is for monsters
to typically switch who they are attacking to whoever is attacking it
after at most 2 turns. Thus, a player who has dropped out must suffer
at most 2 turns of attacks before the monsters switch their attention
to the other players.
It can be annoying if a party is travelling down a corridor and the
"point man" drops out. This basically blocks them off until
he disappears into game-save limbo. However, he himself is not in much
immediate danger because any monsters beyond him will be frozen also
(being tied to the nearest player's movement). Now, if the supporting
mage goes and blasts the monsters (allowing them to move), then there
may be a problem. The reacting monster will want to attack the mage
but will run into the fighter and attack him instead. However, the
mage will probably be very quickly clued into his friend's connection
problem by the huge 8-10 second wait countdown he has to wait for each
move.
--
_____ Isaac Kuo mec...@yahoo.com
__|_>o<_|__
/___________\ The most important way to defend one's nation
\=\>-----</=/ is to make it worth defending. - a true patriot
David Damerell
>It can be annoying if a party is travelling down a corridor and the
>"point man" drops out. This basically blocks them off until
>he disappears into game-save limbo. However, he himself is not in much
>immediate danger because any monsters beyond him will be frozen also
>(being tied to the nearest player's movement). Now, if the supporting
>mage goes and blasts the monsters (allowing them to move), then there
>may be a problem.
Surely someone who submits no move (because of dropout or whatever) should
at least attack monsters next to them?
[This does assume you have no significant passive-defence monsters, or at
any rate that they are not mobile.]
--
David Damerell <dame...@chiark.greenend.org.uk> flcl?
Isaac Kuo
>Hmmm, that should be interesting :-) I can just see some player
>blocking another so that s/he gets killed though!
Oh, you mean doing this on purpose? That can be a problem. For
that matter, there are generally problems with bullies blocking
building entrances and stuff like that. I'm not sure how best to
deal with it. Phase Door can get you past bullies...after enough
tries. In the meantime, those bullies are laughing their heads off...
Maybe a sort of directional Phase Door? This only works for magic
using classes, though, really.
Perhaps all player characters have the option to push their way past
other players? This would be sort of like a short range teleport
which takes the character directly from his current location to a
location beyond the blocking characters. The way this works is that
movement into another player causes "pushing" (not melee combat).
This causes a ghost cursor to show up where you intend to go (but
can't because there is a player character in the way). You continue
to move this ghost cursor as if it were where your character was,
or you can cancel "pushing" with ESC. When the ghost cursor appears
on a location which is unoccupied by another player character, you
"teleport" to that location by pushing your way past the intervening
characters.
Actually, the ghost cursor movement defines a path, and your
character will always "teleport" to the furthest free spot along
that path. This teleportation happens IMMEDIATELY whenever that
spot becomes free; the only thing which can take priority is
another "pushing" character occupying the free spot first.
Moving the ghost cursor takes a turn just like normal movement,
but the "teleportation" does not take a turn.
Basically, "pushing" means that in a non-combat situation you can
just move around as if other player characters weren't in the way.
Your actual position might lag behind your ghost cursor, but you
can usually ignore the difference.
However, "pushing" should not be unrestricted in dungeons. Perhaps
it can be allowed, but be unreliable. The probability of a successful
"push" could be maybe 15%. The push attempt occurs when any spot
along the push path is open. If unsuccessful, the ghost cursor
resets to the player's position. This success rate is low enough
to prevent it from being a common tactic to switch "point man",
but it's high enough to eventually push past a bully (with 10 second
movement time delays, it really could take a long time, though).
Isaac Kuo
Isaac Kuo
>Isaac Kuo <is...@cox.net> wrote:
>>It can be annoying if a party is travelling down a corridor and the
>>"point man" drops out. This basically blocks them off until
>>he disappears into game-save limbo. However, he himself is not in much
>>immediate danger because any monsters beyond him will be frozen also
>>(being tied to the nearest player's movement). Now, if the supporting
>>mage goes and blasts the monsters (allowing them to move), then there
>>may be a problem.
>Surely someone who submits no move (because of dropout or whatever) should
>at least attack monsters next to them?
My general approach is to try and make it so that someone who
doesn't move doesn't move--and neither do the monsters waiting
to attack him. Rather than have the character make automatic
moves the player doesn't submit, I'm trying to reduce the need
for any such automatic moves in the first place.
One possibility would be for a monster to be strictly forbidden
from attacking a player more than once per target player's move, but
I feel that it's acceptable to allow monsters to sometimes get in
more attacks to mitigate "coming-to-the-rescue" abuses.
For example, the party might consist of a scout far in front behind
which are characters with ranged attacks. I don't want it to be
too easy for them to just send in the scout, and at the first sign
of monsters he just stops moving to let the ranged attackers wipe
them out no matter how long it takes. (Those monsters rush up to
the scout, swipe once, and then can't swipe again due to the
one-attack-per player-move restriction).
I'd rather stick with my original timing proposal, which in this
situation would result in the monsters slashing away at the scout
for every round of incoming ranged attacks.
(Oh, for purposes of this thread I am assuming a basic time model
where all actions take the same amount of time, 1 "turn".)
>[This does assume you have no significant passive-defence monsters, or at
>any rate that they are not mobile.]
Isaac Kuo
ABCGi
> ABCGi <ab...@codemonkey.com.au> wrote in message
> news:<Xns92B0AE4801B11ab...@61.9.128.12>...
>
>>Hmmm, that should be interesting :-) I can just see some player
>>blocking another so that s/he gets killed though!
>
> Oh, you mean doing this on purpose? That can be a problem. For
Yep 8)
> that matter, there are generally problems with bullies blocking
> building entrances and stuff like that. I'm not sure how best to
> deal with it. Phase Door can get you past bullies...after enough
> tries. In the meantime, those bullies are laughing their heads off...
If it's purely CO-OP then a voting system to kick misbehaviors?
Note that you *could* two characters to occupy the same spot as they are
both using a different display, but you may not want to.
Another thing I thought of is that you will have to allow archers and
spell casters to shoot "over" characters in front. But you probably
already thought of that.
Isaac Kuo
ABCGi <ab...@codemonkey.com.au> wrote:
>mec...@yahoo.com (Isaac Kuo) wrote in
>news:acc26c07.02102...@posting.google.com:
>>ABCGi <ab...@codemonkey.com.au> wrote in message
>>news:<Xns92B0AE4801B11ab...@61.9.128.12>...
>>>Hmmm, that should be interesting :-) I can just see some player
>>>blocking another so that s/he gets killed though!
>>Oh, you mean doing this on purpose? That can be a problem. For
>Yep 8)
>>that matter, there are generally problems with bullies blocking
>>building entrances and stuff like that. I'm not sure how best to
>>deal with it. Phase Door can get you past bullies...after enough
>>tries. In the meantime, those bullies are laughing their heads off...
>If it's purely CO-OP then a voting system to kick misbehaviors?
I really don't know. This problem must have been addressed many
times already, with the MMORPG craze of a few years ago. I've
never played any of them (for that matter, the only online game
I've played is Phantasy Star Online).
>>Perhaps all player characters have the option to push their way past
>>other players? This would be sort of like a short range teleport
>>which takes the character directly from his current location to a
>>location beyond the blocking characters.
[...snip complex description of "pushing" mechanism...]
>>However, "pushing" should not be unrestricted in dungeons. Perhaps
>>it can be allowed, but be unreliable. The probability of a successful
>>"push" could be maybe 15%. The push attempt occurs when any spot
>>along the push path is open. If unsuccessful, the ghost cursor
>>resets to the player's position. This success rate is low enough
>>to prevent it from being a common tactic to switch "point man",
>>but it's high enough to eventually push past a bully (with 10 second
>>movement time delays, it really could take a long time, though).
>Note that you *could* two characters to occupy the same spot as they are
>both using a different display, but you may not want to.
The only online game I've played, Phantasy Star Online, allowed player
characters to pass and attack through each other unrestricted. It
allowed for stacking an entire party in a single khali-like "superbeing"
of flailing weapons! I've decided I don't want to allow that in my
roguelike.
Like Moria, I want to restrict the contents of each block to one
terrain, one item type, and one character/monster, unless absolutely
necessary to stack more than one item type. The data structures
will allow for one terrain and unlimited stacking, in case someone
wants to use the code for something different. (The 2D map arrays
have an ASCII bytecode for terrain, and then two byte counts for
the number of items and number of creatures in it; then there's a
list of items w/locations and a list of creatures w/locations.
Theoretically, 255 creatures could stack in a single cell, or an
unlimited amount by altering the map class source code.)
>Another thing I thought of is that you will have to allow archers and
>spell casters to shoot "over" characters in front. But you probably
>already thought of that.
Yes, and my current thought is to not allow it. Any attack which is
blocked by another player isn't even allowed, although area effects
which splash onto other players are allowed (i.e. a stinking cloud
doesn't hurt the player when he's the spellcaster, so it doesn't hurt
any player characters).
Thus, an archer can't really provide fire support in a narrow corridor
(nor should they, IMO), but one could be a decent point man. A mage
or wizard is the best for fire support, with numerous spells which
act at a distance without a "projectile" that would be blocked.
ABCGi
>
>>If it's purely CO-OP then a voting system to kick misbehavior?
>
> I really don't know. This problem must have been addressed many
> times already, with the MMORPG craze of a few years ago. I've
Not very well - different approaches but lots of whining about any game
exploit or weakness in that area. Usually bad for n00b players.
> Like Moria, I want to restrict the contents of each block to one
> terrain, one item type, and one character/monster, unless absolutely
> necessary to stack more than one item type. The data structures
> will allow for one terrain and unlimited stacking, in case someone
> wants to use the code for something different. (The 2D map arrays
> have an ASCII bytecode for terrain, and then two byte counts for
> the number of items and number of creatures in it; then there's a
> list of items w/locations and a list of creatures w/locations.
> Theoretically, 255 creatures could stack in a single cell, or an
> unlimited amount by altering the map class source code.)
Your right stacking would suck.
>
>>Another thing I thought of is that you will have to allow archers and
>>spell casters to shoot "over" characters in front. But you probably
>>already thought of that.
>
> Yes, and my current thought is to not allow it. Any attack which is
> blocked by another player isn't even allowed, although area effects
> which splash onto other players are allowed (i.e. a stinking cloud
> doesn't hurt the player when he's the spellcaster, so it doesn't hurt
> any player characters).
No "friendly fire" in this case :-)
> Thus, an archer can't really provide fire support in a narrow corridor
> (nor should they, IMO), but one could be a decent point man. A mage
> or wizard is the best for fire support, with numerous spells which
> act at a distance without a "projectile" that would be blocked.
Depends on the imaginary height of the corridor IMO;
################
....@..@r..a...
################
The first @ an archer should be able to hit the "a"nt if there is some
space above the characters heads (arcing the projectile), but should not
be able to get a "safe" shot at the "r"at.
If you don't have this there is going to be a bit of the old rushing to
be the first one to attack between warriors/archers if XP goes to the
one killing the monster.
David Damerell
>David Damerell <dame...@chiark.greenend.org.uk>:
>>Surely someone who submits no move (because of dropout or whatever) should
>>at least attack monsters next to them?
>My general approach is to try and make it so that someone who
>doesn't move doesn't move--and neither do the monsters waiting
>to attack him. Rather than have the character make automatic
>moves the player doesn't submit, I'm trying to reduce the need
>for any such automatic moves in the first place.
I see what you mean; but perhaps if the monsters do get those moves
because of incoming ranged fire, the poor trapped guy should get some kind
of response?
One solution might be to have an 'active defence' move that isn't
ordinarily all that useful; it would nearly always be better to attack
back, but if you submitted no moves and somehow got attacked, you would be
considered to be using the active defence move.
Isaac Kuo
ABCGi <ab...@codemonkey.com.au> wrote:
>is...@cox.net (Isaac Kuo) wrote in news:ap7gfk$dqi$1...@deedlit.xephon:
>>>If it's purely CO-OP then a voting system to kick misbehavior?
>>I really don't know. This problem must have been addressed many
>>times already, with the MMORPG craze of a few years ago. I've
>Not very well - different approaches but lots of whining about any game
>exploit or weakness in that area. Usually bad for n00b players.
Well, then I guess I'll have to think about it! I'm going on a
camping trip so I won't be on the newsgroup until next week...maybe
I'll come up with something while canoeing down a river...
>>Thus, an archer can't really provide fire support in a narrow corridor
>>(nor should they, IMO), but one could be a decent point man. A mage
>>or wizard is the best for fire support, with numerous spells which
>>act at a distance without a "projectile" that would be blocked.
>Depends on the imaginary height of the corridor IMO;
>################
>....@..@r..a...
>################
>The first @ an archer should be able to hit the "a"nt if there is some
>space above the characters heads (arcing the projectile), but should not
>be able to get a "safe" shot at the "r"at.
This assumes a corridor is tall enough to do that, which I don't.
Also, arrows don't arc so much as to allow that at such short range.
>If you don't have this there is going to be a bit of the old rushing to
>be the first one to attack between warriors/archers if XP goes to the
>one killing the monster.
I'm not sure how to handle the Exp issue. One possibility is a
proportional system where the Exp is doled out according to who
did how much damage (with a "damage" factor assigned to doing other
harmful things like confusion or sleep). This reduces the "stealing
a kill" factor, but doesn't help out priests who usually don't do
much damage directly.
Perhaps healing can give a certain amount of Exp in its own right,
and any damage done indirectly will also count. For example, if
a priest prays for the warrior to do 20% more damage, he gets some
of the Exp for that 20% extra damage (not all, because it's still
the warrior who is risking his neck in direct combat).
Isaac Kuo
David Damerell <dame...@chiark.greenend.org.uk> wrote:
>Isaac Kuo <mec...@yahoo.com> wrote:
>>David Damerell <dame...@chiark.greenend.org.uk>:
>>>Surely someone who submits no move (because of dropout or whatever) should
>>>at least attack monsters next to them?
>>My general approach is to try and make it so that someone who
>>doesn't move doesn't move--and neither do the monsters waiting
>>to attack him. Rather than have the character make automatic
>>moves the player doesn't submit, I'm trying to reduce the need
>>for any such automatic moves in the first place.
>I see what you mean; but perhaps if the monsters do get those moves
>because of incoming ranged fire, the poor trapped guy should get some kind
>of response?
If he wants to respond, he should do it manually. In order to give
enough time for this, perhaps the timer curve should be expanded
somewhat. It's not like the guy is "trapped" against making moves.
If it's that he's physically trapped--well, that's too bad.
>One solution might be to have an 'active defence' move that isn't
>ordinarily all that useful; it would nearly always be better to attack
>back, but if you submitted no moves and somehow got attacked, you would be
>considered to be using the active defence move.
Well, when a player submits no move it's not that he loses a move,
but rather his move is indefinitely delayed until the moment he
enters a command. If an active defense move is allowed, then either
the player is forced to wait until he can have his next move, or
there is the potential for abuse by waiting just long enough for
the active defense move and then immediately following it up with
his "real" move.
Perhaps the "active defense" move only happens after the player's
move is timed out at least twice, but it still seems inelegant
to me.
ABCGi
>
> Well, then I guess I'll have to think about it! I'm going on a
> camping trip so I won't be on the newsgroup until next week...maybe
> I'll come up with something while canoeing down a river...
>
Have fun!
>>Depends on the imaginary height of the corridor IMO;
>
>>################
>>....@..@r..a...
>>################
>
>>The first @ an archer should be able to hit the "a"nt if there is some
>>space above the characters heads (arcing the projectile), but should
>>not be able to get a "safe" shot at the "r"at.
>
> This assumes a corridor is tall enough to do that, which I don't.
> Also, arrows don't arc so much as to allow that at such short range.
Ok your call :-) Pretty crampy corridors! The first @ is going to get
pretty bored :-( I like the D&D rule where you can do it but you risk
hitting friend instead of foe on a bad roll. Maybe you'll allow it in
rooms...
>>If you don't have this there is going to be a bit of the old rushing
>>to be the first one to attack between warriors/archers if XP goes to
>>the one killing the monster.
>
> I'm not sure how to handle the Exp issue. One possibility is a
> proportional system where the Exp is doled out according to who
> did how much damage (with a "damage" factor assigned to doing other
> harmful things like confusion or sleep). This reduces the "stealing
> a kill" factor, but doesn't help out priests who usually don't do
> much damage directly.
>
> Perhaps healing can give a certain amount of Exp in its own right,
> and any damage done indirectly will also count. For example, if
> a priest prays for the warrior to do 20% more damage, he gets some
> of the Exp for that 20% extra damage (not all, because it's still
> the warrior who is risking his neck in direct combat).
XP for any damage and XP for the kill IMHO.
Isaac Kuo
ABCGi <ab...@codemonkey.com.au> wrote:
>is...@cox.net (Isaac Kuo) wrote in news:apacmg$j0p$1...@deedlit.xephon:
>>This assumes a corridor is tall enough to do that, which I don't.
>>Also, arrows don't arc so much as to allow that at such short range.
>Ok your call :-) Pretty crampy corridors! The first @ is going to get
>pretty bored :-( I like the D&D rule where you can do it but you risk
>hitting friend instead of foe on a bad roll. Maybe you'll allow it in
>rooms...
In rooms, it's very easy to shoot "around" other players. The way
I calculate LOS is that if there is any unobstructed line segment
from any point in the source square to any point in the destination
square, then there is LOS. The upshot of this is that single block
obstacles don't block very much LOS unless you are aligned with
the obstacle in one of the 8 cardinal directions.
>>>If you don't have this there is going to be a bit of the old rushing
>>>to be the first one to attack between warriors/archers if XP goes to
>>>the one killing the monster.
>>I'm not sure how to handle the Exp issue. One possibility is a
>>proportional system where the Exp is doled out according to who
>>did how much damage (with a "damage" factor assigned to doing other
>>harmful things like confusion or sleep). This reduces the "stealing
>>a kill" factor, but doesn't help out priests who usually don't do
>>much damage directly.
>>Perhaps healing can give a certain amount of Exp in its own right,
>>and any damage done indirectly will also count. For example, if
>>a priest prays for the warrior to do 20% more damage, he gets some
>>of the Exp for that 20% extra damage (not all, because it's still
>>the warrior who is risking his neck in direct combat).
>XP for any damage and XP for the kill IMHO.
I won't assign any Exp until a kill, and then the Exp is awarded.
Otherwise, it would be possible to harvest Exp from creatures
allowed to heal up.
ABCGi
>>Ok your call :-) Pretty crampy corridors! The first @ is going to get
>>pretty bored :-( I like the D&D rule where you can do it but you risk
>>hitting friend instead of foe on a bad roll. Maybe you'll allow it in
>>rooms...
>
> In rooms, it's very easy to shoot "around" other players. The way
> I calculate LOS is that if there is any unobstructed line segment
> from any point in the source square to any point in the destination
> square, then there is LOS. The upshot of this is that single block
> obstacles don't block very much LOS unless you are aligned with
> the obstacle in one of the 8 cardinal directions.
>
Well that sounds cool, so a reason to avoid getting stuck in corridors!
>>XP for any damage and XP for the kill IMHO.
>
> I won't assign any Exp until a kill, and then the Exp is awarded.
> Otherwise, it would be possible to harvest Exp from creatures
> allowed to heal up.
Oh I meant when it is dead - whoever did the % of damage gets shares of
the XP.
David Damerell
>David Damerell <dame...@chiark.greenend.org.uk> wrote:
>>I see what you mean; but perhaps if the monsters do get those moves
>>because of incoming ranged fire, the poor trapped guy should get some kind
>>of response?
>If he wants to respond, he should do it manually.
I think a game of this nature needs to be tolerant of lag. It's not like
xpilot where if you get waxed by the lagmonster you just lose 10 points.
>>One solution might be to have an 'active defence' move that isn't
>>ordinarily all that useful; it would nearly always be better to attack
>>back, but if you submitted no moves and somehow got attacked, you would be
>>considered to be using the active defence move.
>Well, when a player submits no move it's not that he loses a move,
>but rather his move is indefinitely delayed until the moment he
>enters a command. If an active defense move is allowed, then either
>the player is forced to wait until he can have his next move, or
>there is the potential for abuse by waiting just long enough for
>the active defense move and then immediately following it up with
>his "real" move.
Perhaps I've misunderstood your proposal (it's way more complex than
Electric Death :-), but I don't see the abuse here. Consider the following
chain of events.
Alice submits a move. The monsters near her also get a move, and pound
her. Alice's connection drops. During the outage, Bob attacks those
monsters with a ranged attack, and so they pound Alice a second time; she
receives the benefit of active defence. Alice now gets her connection
make, and makes a move; now the monsters pound her a third time. She's had
three moves; but so have the monsters.
Isaac Kuo
>Isaac Kuo <is...@cox.net> wrote:
>>David Damerell <dame...@chiark.greenend.org.uk> wrote:
>>>I see what you mean; but perhaps if the monsters do get those moves
>>>because of incoming ranged fire, the poor trapped guy should get some kind
>>>of response?
>>If he wants to respond, he should do it manually.
>I think a game of this nature needs to be tolerant of lag. It's not like
>xpilot where if you get waxed by the lagmonster you just lose 10 points.
Yes, but I think that's built in to the desire to be tolerant
of the player taking his time pondering his move.
>>>One solution might be to have an 'active defence' move that isn't
>>>ordinarily all that useful; it would nearly always be better to attack
>>>back, but if you submitted no moves and somehow got attacked, you would be
>>>considered to be using the active defence move.
>>Well, when a player submits no move it's not that he loses a move,
>>but rather his move is indefinitely delayed until the moment he
>>enters a command. If an active defense move is allowed, then either
>>the player is forced to wait until he can have his next move, or
>>there is the potential for abuse by waiting just long enough for
>>the active defense move and then immediately following it up with
>>his "real" move.
>Perhaps I've misunderstood your proposal (it's way more complex than
>Electric Death :-), but I don't see the abuse here. Consider the following
>chain of events.
>Alice submits a move. The monsters near her also get a move, and pound
>her. Alice's connection drops. During the outage, Bob attacks those
>monsters with a ranged attack, and so they pound Alice a second time; she
>receives the benefit of active defence. Alice now gets her connection
>make, and makes a move; now the monsters pound her a third time. She's had
>three moves; but so have the monsters.
Bob only had one move. If Alice times her "connection drops"
just right, she gets a normal attack and an autoattack for
every normal move Bob gets.
Alternatively, if Alice is required to wait after an
auto-attack before moving, this means she will be forced to
wait to make her manual move. My desired feature is that
a player who has "lost" a move due to timeout can IMMEDIATELY
move at any time. This minimizes how much of the "round" is
actually lost. For example, if there are 5 players and player
3's turn "times out", he can move immediately after player 4
moves while player 5 is thinking about his move rather than
waiting all the way around for player 2 (modifying the de
facto turn order).
Isaac Kuo
David Damerell
[much deletion]
>Bob only had one move. If Alice times her "connection drops"
>just right, she gets a normal attack and an autoattack for
>every normal move Bob gets.
Hm. Couldn't the autoattack (or boosted defence) only kick in after Alice
has completely missed a move and the monsters have got to pound her
regardless for some reason? Then, even if she does get the benefits of 2
moves in rapid succession, she has necessarily lost a move somewhere to
compensate.
Isaac Kuo
David Damerell <dame...@chiark.greenend.org.uk> wrote:
>Isaac Kuo <mec...@yahoo.com> wrote:
>[much deletion]
>>Bob only had one move. If Alice times her "connection drops"
>>just right, she gets a normal attack and an autoattack for
>>every normal move Bob gets.
>Hm. Couldn't the autoattack (or boosted defence) only kick in after Alice
>has completely missed a move and the monsters have got to pound her
>regardless for some reason? Then, even if she does get the benefits of 2
>moves in rapid succession, she has necessarily lost a move somewhere to
>compensate.
Ah, yes, that would work. I'm still philosophically opposed to the
character doing something not specifically commanded to by the
player...but...well, I'll think about it.
David Damerell
>>has completely missed a move and the monsters have got to pound her
>>regardless for some reason? Then, even if she does get the benefits of 2
>>moves in rapid succession, she has necessarily lost a move somewhere to
>>compensate.
>Ah, yes, that would work. I'm still philosophically opposed to the
>character doing something not specifically commanded to by the
>player...but...well, I'll think about it.
... and I'll keep pestering you about it. :-)
Actually, this is probably the last thing; if it's a boosted defence, not
an autoattack, the character wouldn't per se be doing anything; just
taking damage at a slower rate. Not quite the same as finding you've
chopped 3 beasties into bits when the lag's over.