Turn-based combat
Darren Coffin
months as well. I've also been roleplaying for about 14 years. I've
decided that I want to tinker around with a mud in my spare time(what
little I have of it)...
One thing that I'd like to try with the mud is to implement true turn-based
combat, and I wanted to get some opinions on it. In every mud I've played
so far, you type "kill orc" and the program merrily chugs away, making your
character swing and defend automatically. In the midst of all of this, you
can cast spells or perform skills; from a roleplaying point of view, you
can be hacking at the opponent with a two-handed sword while simultaneously
casting a meteor shower. It doesn't make much sense.
My idea is to have the character decide every round what his action will
be. He can attack or cast a spell, but not both at once. He can alter how
aggresive he will be; the more aggressive he is, the better chance of
hitting but also the better chance of being hit in return. Casting times
can be implemented, and a chance of spell failure if hit in the midst of
casting.
Of course, there are problems with this approach. But I think I can
solve/work around most of them by creating a turn timer. If the character
doesn't take an action within something like 10 seconds, then a default
action will be taken. This default action can be defined by the player.
If an action is taken before the 10 seconds are up, the action will take
place and the creature will respond. Then the timer will be reset to 10
seconds for the next round. When multiple players are involved, there will
be a single timer; if all players choose an action before the timer is up,
the results will be determined. Otherwise, once the 10 seconds are up,
those who have chosen will take their chosen actions while those who
haven't chosen will take their default actions.
The timer and default actions should deal with the problems of lag and
losing link in the midst of combat.
Are there any comments on this system? I'm considering coding it in LPC,
as from what I can tell, LPMuds are the most customizable ones out there.
-Darren
Blane Bramble
mixed party of fighters and magic-users, send the fighters in to close
combat and keep the spell-casters out of direct combat) - I think maybe you
should consider a simple way of defining a combat 'script' for players to
define, so they can set a default series of action (parry, attack, withdraw
[preparing for spell]) etc. If you do this you can potentially speed up the
combat (10 seconds could drag fights out), without overwhelming players. Any
combat commands then entered would be scheduled after the current action is
complete, then the script could recommence.
Just an idea.
Blane.
Darren Coffin wrote in message ...
Darren Coffin
>Could be a good idea (and reinforce role-playing - now you need to get a
>mixed party of fighters and magic-users, send the fighters in to close
>combat and keep the spell-casters out of direct combat) - I think maybe you
>should consider a simple way of defining a combat 'script' for players to
>define, so they can set a default series of action (parry, attack, withdraw
>[preparing for spell]) etc. If you do this you can potentially speed up the
>combat (10 seconds could drag fights out), without overwhelming players. Any
>combat commands then entered would be scheduled after the current action is
>complete, then the script could recommence.
I'll consider that. I'm still mulling over the idea of a Bard's Tale-style
distance system, where a monster will be something like 60' away and will
have to advance to get into hand-to-hand...I could have a "max distance"
variable for each room, so you don't have monsters starting 90' away in a
room that's supposed to be 30'x30'. I'm not sure I like it though, I may
stick with the usual starting off in melee. I just remember getting really
annoyed with having to advance 3 or 4 times before being able to melee a
creature in Bard's Tale...this was provoked by your "withdraw to prepare
for a spell" comment.
Perhaps there could be a withdraw skill which might buy some casting time,
if I don't include the distance thing above. The basic spells wouldn't
have casting times (or basically could be cast within one round), while to
have a decent chance at getting a bigger spell off, you'd need a fighter or
summoned creature in front of you...
-Darren
David Kristola
>Hello. I've been mudding for about 4-5 years now, and was an imm for a few
>months as well. I've also been roleplaying for about 14 years. I've
>decided that I want to tinker around with a mud in my spare time(what
>little I have of it)...
Enjoy!
{snip}
>Are there any comments on this system? I'm considering coding it in LPC,
>as from what I can tell, LPMuds are the most customizable ones out there.
The idea of a stance or posture comes to mind. The character
would assume one of many possible stances; defensive, aggressive,
inattentive (for spell casting, perhaps), stunned (not a voluntary
stance), etc. You could then model berserker rage (aggressive,
penalties to defense, bonuses to attacks), to full parry, and
include more sane things in between (like "i'm going to mostly
parry unless i see an opening").
--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Spam: goto....@welovespam.com
Peter Register
would be speed of combat. You'd probably want a relatively deadly combat
system so combats could be resolved quickly in order to keep players engaged.
An alternative, I suppose, would be to have the longer combats that a
turn-based system would tend towards, but reward the players more per combat
(xp/training/what have you).
-peter
Darren Coffin
Good point. I don't intend combat to take as long as on some muds, where
you can go downstairs and grab a snack, return, and your screen is still
scrolling by with all the swings and misses. :) It'll take some
playtesting to adjust, but I'm hoping it'll be relatively quick,
particularly since the players will have way more control as to when they
can flee...no getting pounded 3 or 4 times before you realize that the
opponent is way out of your league.
-Darren
(Unless the opponent has 3 or 4 attacks per round, but that's another story
*grin*)
Darren Coffin
>>as from what I can tell, LPMuds are the most customizable ones out there.
>
>The idea of a stance or posture comes to mind. The character
>would assume one of many possible stances; defensive, aggressive,
>inattentive (for spell casting, perhaps), stunned (not a voluntary
>stance), etc. You could then model berserker rage (aggressive,
>penalties to defense, bonuses to attacks), to full parry, and
>include more sane things in between (like "i'm going to mostly
>parry unless i see an opening").
I'm thinking of having it even more customizable than that; borrowing from
the Rolemaster system of Offensive Bonus(OB) and Defensive Bonus(DB). The
character has a set OB based on skills, stats, magic items, etc. and a set DB.
The player will choose how much of his OB to use in a given attack, the
rest being converted over into DB. Thus, an all-out attack will leave him
almost defenseless while an all-out defense will make his attacks
pathetic...along with all the shades of grey in between. The player would
type something like "a 50" or "a50" to use 50 of his OB for an attack and
convert the rest into DB. I can even have different ratios of how much of
a OB to DB conversion you will get based on class and skills...
In case you haven't noticed from this and my past posts, I'm borrowing bits
and pieces from different systems as well as adding in new things that I've
thought of. But doesn't everyone, who isn't copying one system completely?
:)
-Darren
rric...@lanminds.com
The other thing that you have to consider is what is going on outside
the combat. Let's say, for example, that you are basing your mudtime
on 6-hour days (thus 4 game days to one real day). Then, a battle
that takes 5 minutes in RL time, but which might be over in a minute
game time, will be out of sync with the rest of the game. This may or
may not matter, depending on how important time is in the game. The
main thing I can see it messing up is longterm spells, and possibly
time-triggered events (such as if a portal was only open during a
certain time.) I have thought about this some, and I just can't see a
way to handle the different timescales of parties in combat, those
traveling long distances, and the day-to-day times.
Kira Skydancer
Remove "not" when replying by email
Jp Calderone
>
> On Wed, 18 Aug 1999 13:01:37 GMT, dco...@ivory.trentu.ca (Darren
> Coffin) wrote:
>
>
> The other thing that you have to consider is what is going on outside
> the combat. Let's say, for example, that you are basing your mudtime
> on 6-hour days (thus 4 game days to one real day). Then, a battle
> that takes 5 minutes in RL time, but which might be over in a minute
> game time, will be out of sync with the rest of the game. This may or
> may not matter, depending on how important time is in the game. The
> main thing I can see it messing up is longterm spells, and possibly
> time-triggered events (such as if a portal was only open during a
> certain time.) I have thought about this some, and I just can't see a
> way to handle the different timescales of parties in combat, those
> traveling long distances, and the day-to-day times.
The obvious solution (Which I'm sure most people have seen and dismissed)
is simply to not use a time multiplier in the game, mapping time 1 to 1
with reality. The only reason most muds use them now is because nobody
wanted to break frm D&D. Of course, this may not "mesh" with your game,
but then, do these screwy time dilation problems "mesh"?
> Kira Skydancer
> Remove "not" when replying by email
--
"There is no reason for any individual to have a computer in their
home."
-- Ken Olson, President of DEC, World Future Society
Convention, 1977
Nightshade
>In article <9Zwu3.4491$Qn4.5...@ptah.visi.com>, mur...@visi.com (Peter Register) writes:
>>Turn combat would be interesting. One thing I think important to keep in mind
>>would be speed of combat. You'd probably want a relatively deadly combat
>>system so combats could be resolved quickly in order to keep players engaged.
>>An alternative, I suppose, would be to have the longer combats that a
>>turn-based system would tend towards, but reward the players more per combat
>>(xp/training/what have you).
>
>Good point. I don't intend combat to take as long as on some muds, where
>you can go downstairs and grab a snack, return, and your screen is still
>scrolling by with all the swings and misses. :) It'll take some
>playtesting to adjust, but I'm hoping it'll be relatively quick,
>particularly since the players will have way more control as to when they
>can flee...no getting pounded 3 or 4 times before you realize that the
>opponent is way out of your league.
I suspect this will also help equalize some problems I've heard on
some MUDs with people who tend to win fights more because of their
connection speed and how good a bot they have than anything to do with
actually playing the game. I'm real dubious of RT games over the
Net...
David Kristola
>The other thing that you have to consider is what is going on outside
>the combat. Let's say, for example, that you are basing your mudtime
>on 6-hour days (thus 4 game days to one real day). Then, a battle
>that takes 5 minutes in RL time, but which might be over in a minute
>game time, will be out of sync with the rest of the game. This may or
>may not matter, depending on how important time is in the game. The
>main thing I can see it messing up is longterm spells, and possibly
>time-triggered events (such as if a portal was only open during a
>certain time.) I have thought about this some, and I just can't see a
>way to handle the different timescales of parties in combat, those
>traveling long distances, and the day-to-day times.
Something i have been thinking of doing is plunging the
whole mud into "slow time" when a combat starts anywhere.
If i am smart, i will make it a configuration parameter
(to block or allow the feature) and experiment with it.
In some mud environments this might work fine, in others
it might be horrible.
Jorge Pereira
occur in a non-regular order. That is:
* A attacks B and an attack is issued
* combat rounds begin
and then each combat round, it is unsure who attacks first. Depending on
the order characters were created, the last to appear on the character
list makes the first attack. And this is not very fun, is it? shouldn't
A always make the first hit and B respond? or at least have some way to
control who is attacking and who is responding? :)
Another problem you will experiment is with battles of more then two
characters. You would probably want to make lists of who's fighting who,
without forgetting that one person can fight only one other, but can be
attacked by more then one, so you have sketches such as these:
/ e
/ c A - c
A-b B /
\ d \ d
The problem with this approach is that, using lists to model this, it
requires a number of loops to actually decide who's fighting who.
example:
in char_data:
CHAR_DATA * fighting; // who you're fighting
CHAR_DATA * next_in_fight; // list of people fighting
the same person
and this should be enough. But still, for each character in the game,
you would have to decide in which fight they were, then find out who's
competing with who for initiative, then roll initiative, then order the
list using those rolls, and then finally make the attacks.
But still it would be a mess deciding who would get the first attack.
The problem is a little reduced if you don't want ranged fighting, that
is, if you only allow people to fight in the same room, but that won't
let you have neat effects with ranged weapons and ranged spells! :)
Darren Coffin
>>you can go downstairs and grab a snack, return, and your screen is still
>>scrolling by with all the swings and misses. :) It'll take some
>>playtesting to adjust, but I'm hoping it'll be relatively quick,
>>particularly since the players will have way more control as to when they
>>can flee...no getting pounded 3 or 4 times before you realize that the
>>opponent is way out of your league.
>
>I suspect this will also help equalize some problems I've heard on
>some MUDs with people who tend to win fights more because of their
>connection speed and how good a bot they have than anything to do with
>actually playing the game. I'm real dubious of RT games over the
>Net...
Yes, I'm not a big fan of playerkill on most muds because of the heavy
reliance on intricate triggers and connection speed...especially since for
the first few years of mudding I had a 2400 baud modem :)
-Darren
Darren Coffin
>
>The other thing that you have to consider is what is going on outside
>the combat. Let's say, for example, that you are basing your mudtime
>on 6-hour days (thus 4 game days to one real day). Then, a battle
>that takes 5 minutes in RL time, but which might be over in a minute
>game time, will be out of sync with the rest of the game. This may or
>may not matter, depending on how important time is in the game. The
>main thing I can see it messing up is longterm spells, and possibly
>time-triggered events (such as if a portal was only open during a
>certain time.) I have thought about this some, and I just can't see a
>way to handle the different timescales of parties in combat, those
>traveling long distances, and the day-to-day times.
I hadn't considered this yet. Perhaps I'll put a freeze on the durations
of spells that are cast on players who enter combat. Combats should only
take seconds or minutes of gametime, and there are few spells that would
have shorter durations than this. Or maybe I'll enact a different "speed
of time" for those in combat, where each round is 5 or 10 seconds of game
time or some such. The durations of spells cast on them will freeze as
they enter combat, no longer affected by the passage of real time. Then
every combat round that passes subtracts a certain amount from the timer.
When it comes to portals and travelling distances, I think I might just
have to chalk them up to the usual "mud time-paradoxes" that are bound to
happen.
-Darren
Jon A. Lambert
>>
>>The other thing that you have to consider is what is going on outside
>>the combat. Let's say, for example, that you are basing your mudtime
>>on 6-hour days (thus 4 game days to one real day). Then, a battle
>>that takes 5 minutes in RL time, but which might be over in a minute
>>game time, will be out of sync with the rest of the game. This may or
>>may not matter, depending on how important time is in the game. The
>>main thing I can see it messing up is longterm spells, and possibly
>>time-triggered events (such as if a portal was only open during a
>>certain time.) I have thought about this some, and I just can't see a
>>way to handle the different timescales of parties in combat, those
>>traveling long distances, and the day-to-day times.
>
>I hadn't considered this yet. Perhaps I'll put a freeze on the durations
>of spells that are cast on players who enter combat. Combats should only
>take seconds or minutes of gametime, and there are few spells that would
>have shorter durations than this. Or maybe I'll enact a different "speed
>of time" for those in combat, where each round is 5 or 10 seconds of game
>time or some such. The durations of spells cast on them will freeze as
>they enter combat, no longer affected by the passage of real time. Then
>every combat round that passes subtracts a certain amount from the timer.
>
If Bubba gives Buffy a ticking time bomb set to go off in 30 seconds, at what
point are Bubba and Buffy considered to be in a "state of combat"? Never?
When the bomb goes off? When it is given? When Buffy figures out what it is?
If Buffy slaps Bubba for pinching her bottom, do Bubba and Buffy enter a state
of combat, or are they merely exchanging emotes? If they are doing more than
exchanging emotes, how many slaps does it take to render Bubba
unconscious? Why is combat a state separate and distinct from non-combat?
What triggers this transition and why? How many licks does it take to get
to the center of a tootsie roll pop?
--
J. Lambert
Sterling
>
>Something i have been thinking of doing is plunging the
>whole mud into "slow time" when a combat starts anywhere.
>If i am smart, i will make it a configuration parameter
>(to block or allow the feature) and experiment with it.
>In some mud environments this might work fine, in others
>it might be horrible.
>
This seems very likely to have disastrous consequences. Muds generally run
at an accelerated rate of time anyway, and combat is generally accelerated
even more than the normal rate. Slowing everything down to real time
whenever combat starts and doing a real time combat system would make that
walk to the corner weapon shop take a real long time if you tried to do it
at the wrong time. I this this would be more of a hindrance to the
immersion than a help in most situations.
Sterling @ Wyld Knight
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Wyld Knight - wyld.qx.net 3333
http://wyld.qx.net/~rezo
re...@lords.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Darren Coffin
>>I hadn't considered this yet. Perhaps I'll put a freeze on the durations
>>of spells that are cast on players who enter combat. Combats should only
>>take seconds or minutes of gametime, and there are few spells that would
>>have shorter durations than this. Or maybe I'll enact a different "speed
>>of time" for those in combat, where each round is 5 or 10 seconds of game
>>time or some such. The durations of spells cast on them will freeze as
>>they enter combat, no longer affected by the passage of real time. Then
>>every combat round that passes subtracts a certain amount from the timer.
>>
>If Bubba gives Buffy a ticking time bomb set to go off in 30 seconds, at what
>point are Bubba and Buffy considered to be in a "state of combat"? Never?
>When the bomb goes off? When it is given? When Buffy figures out what it is?
>If Buffy slaps Bubba for pinching her bottom, do Bubba and Buffy enter a state
>of combat, or are they merely exchanging emotes? If they are doing more than
>exchanging emotes, how many slaps does it take to render Bubba
>unconscious? Why is combat a state separate and distinct from non-combat?
>What triggers this transition and why? How many licks does it take to get
>to the center of a tootsie roll pop?
Combat doesn't necessarily have to be a different speed from the rest of
the mud; note how I said "perhaps I'll do this"...I'm still trying to
decide that. My initial reason was because combat should take place in
seconds or minutes of game time as opposed to the hours that can fly by in
accelerated "mud time." But then again, so should most things players do.
Maybe I'll take someone else's suggestion and make a real-time mud.
Whatever time it is locally(for me) would be the standard time for those
playing the game. If a spell lasts for 2 minutes, then it lasts for 2
minutes of real time. But then you run into the travel time problem;
people can travel the world in a matter of minutes, which allows a single
half-hour spell to last them for 10s of combats or more. It bears more
thought...I think there will always be some sort of time paradox, I just
have to pick a way which seems best for playability and enjoyment. :)
-Darren
Jorge Pereira
> One problem you will experiment is that combat rounds in some codebases
> occur in a non-regular order. That is:
> * A attacks B and an attack is issued
> * combat rounds begin
> and then each combat round, it is unsure who attacks first. Depending on
> the order characters were created, the last to appear on the character
> list makes the first attack. And this is not very fun, is it? shouldn't
> A always make the first hit and B respond? or at least have some way to
> control who is attacking and who is responding? :)
> [snip]
Following up to oneself is not polite, I know, but, blah, forget all that
wrote on my previous note. After writing it I just went back to code and
noticed most of the above is BS! <g>
Ok, the issue I'm focusing here is making players fight in different
orders within a round. As most codebases do, after player A attacks player
B, the order in which they exchange attacks is usually undetermined
(although in fact, it's the reverse order in which the characters where
created). I should probably post this on a different thread, but it's
somewhat related...
Anyway, it turned out pretty easy to make initiative rolls. The issue here
is determinating initiatives in each round. It is easy thinking of it as
assigning each fighting character a value, then going through the list in
that order, from higher to lower.
For that, I used the following:
1) in the char_data structure:
CHAR_DATA * next_fighting; // next fighting character
CHAR_DATA * next_fighting_sorted; // explained below
int initiative; // last initiative roll
2) A separate list containing only the characters who are fighting,
eg: fight_list. As global variables we would have:
CHAR_DATA * fight_list.
3) Add/remove characters to/from that list in start_fighting() and
stop_fighting().
4) In violence_update(), cycle through fight_list, assigning initiative
values to each character while creating another list, sorted by that
value (using the next_fighting_sorted field)
5) Still violence_update(), loop through that new list instead of looping
through char_list.
Well, this process is not worse then what's used on merc/envy, cause it
doesn't require a loop through all characters, so that extra loop in step
4 is actually not much of a problem. But I'd still like to make this a
little more efficient. This involves a better way to loop through the list
in order of initiatives. Another aproach to this would be not creating the
sorted list in step 4 and looping through fight_list as many times as
needed,
selecting the character with highest initiative, making its attacks and
flagg it.
Anyone has ideas on this? A sample of the code used is below. Improvements
are welcome! :)
---- code sample ----
// return the list of fighting people sorted by initiative rolls
CHAR_DATA * sort_fight_list()
{
CHAR_DATA * fight_list_sorted = NULL;
CHAR_DATA * ch;
CHAR_DATA ** l;
// for each character fighting, roll its initiative and add it to the
// sorted list
for ( ch = fight_list; ch; ch = ch->next_fighting )
{
ch->initiative = roll_initiative( ch ); // assign initiative value
// figure out the correct place in the list:
for ( l = &fight_list_sorted; *l; l = &(*l)->next_fighting_sorted )
{
if ( (*l)->initiative <= ch->initiative )
break;
}
// add to list
ch->next_in_fight_sorted = *l;
*l = ch;
}
}
void violence_update( void )
{
CHAR_DATA * fight_list_sorted;
CHAR_DATA * ch_next;
fight_list_sorted = sort_fight_list();
for ( ch = fight_list_sorted; ch; ch = ch_next )
{
// destroy the temporary list character-by-character
ch_next = ch->next_fighting_sorted;
ch->next_in_fight_sorted = NULL;
// just to see it working...
act( "$n got a $v on $s initiative roll.", // $v is non-standard:
use a
ch, ch->initiative, NULL, TO_ROOM ); // string buffer and $t
// somewhere in here we would have:
multi_hit( ch, ch->fighting );
}
}
---- end of code sample ----
Well, the above does the trick, and looks fine, but does anyone have ideas
to make it more efficient? :)
And yes, I understand that rolling initiative only once in the beggining of
a fight can also be done and would eliminate the need for all this, but
that
is not the issue <g>. :) It adds a little more fun to combats if you can
use skills to increase your initiative or modify your atitude. Spells
affecting SPEED would also improve the initiative rolls, so they would be
useful within a combat (or DEX, if you don't have a speed ranking)
Jorge Pereira
> CHAR_DATA * sort_fight_list()
> {
> [snip]
return fight_list_sorted;
> }
grin, again sorry... this is the time I follow up to myself and it gets me
frustrated! <g>
Ilya
>
> My idea is to have the character decide every round what his
> action will be. He can attack or cast a spell, but not both
> at once. He can alter how aggresive he will be; the more
> aggressive he is, the better chance of
> hitting but also the better chance of being hit in return.
I'm sure I've seen a reasonably good implementation of this
Was it the isles? I think so. Hmm, somebody will remind us
all I'm sure. Rounds did eventually time out (that is, they
had a fairly long duration, and if you entered no command,
you would eventually be taken to have done nothing in the
next round).
A simple way to handle the "fast connect vs slow connect"
and other lag related problems is to allow for various
defaults to be specified ahead of time, so even if your
very long round times aren't long enough when a particular
person hits a bad lag, okay, the defaults help out a bit.
These defaults could be fairly detailed, I'm sure, or as
simple as you please.
I do love the idea of allowing for closing/withdrawing
and 'range'. This could be implemented as you suggested
later in this thread, with rooms having max sizes for range.
Also consider allowing for range by essentially connecting
rooms with invisible walls -- that is, grouping rooms in
arbitrary ways by defining their connections as essentially
see-through. This allows, I think, for a fairly straightforward
changeover from current room-based thought and extends all
the advantages of range and irregular room "line of sight"
fun.
Just a thought or three,
Ilya
--
Ilya (at) gamecommandos (dot) com a mud list & review site
www.gamecommandos.com for online roleplaying games
Richard Woolcock
>
[snip stuff about calculating initiative each round]
> Anyone has ideas on this? A sample of the code used is below. Improvements
> are welcome! :)
>
> ---- code sample ----
>
> // return the list of fighting people sorted by initiative rolls
> CHAR_DATA * sort_fight_list()
> {
> CHAR_DATA * fight_list_sorted = NULL;
> CHAR_DATA * ch;
> CHAR_DATA ** l;
Why use a pointer to a pointer?
[snip]
> Well, the above does the trick, and looks fine, but does anyone have ideas
> to make it more efficient? :)
You could create an array of pointers to lists indexed by initiative, eg:
CHAR_DATA *init_fight_list[MAX_INITIATIVE];
That would save you the effort of having to sort each fighter - you could
just do something like:
/* Add each person to their appropriate initiative list */
CHAR_DATA * init_fight_list()
{
CHAR_DATA * ch;
int initiative;
for ( initiative = 0; initiative < MAX_INITIATIVE; initiative++ )
{
/* Clear the lists from last round */
init_fight_list[initiative] = NULL;
}
/* Go through every character who is fighting */
for ( ch = fight_list; ch; ch = ch->next_fighting )
{
/* Calculate their initiative and add them to the appropriate list */
initiative = roll_initiative( ch );
ch->next_init_fight = init_fight_list[initiative];
init_fight_list[initiative] = ch;
}
}
> And yes, I understand that rolling initiative only once in the beggining of
>
> a fight can also be done and would eliminate the need for all this, but
> that is not the issue <g>. :) It adds a little more fun to combats if you
> can use skills to increase your initiative or modify your atitude. Spells
> affecting SPEED would also improve the initiative rolls, so they would be
> useful within a combat (or DEX, if you don't have a speed ranking)
I also use initiative, but not in a round-based situation. I let people
hit as fast as their initiative allows (variable speed combat).
KaVir.
Jorge Pereira
> Jorge Pereira wrote:
> >
>
> [snip stuff about calculating initiative each round]
>
> > Anyone has ideas on this? A sample of the code used is below. Improvements
> > are welcome! :)
> >
> > ---- code sample ----
> >
> > // return the list of fighting people sorted by initiative rolls
> > CHAR_DATA * sort_fight_list()
> > {
> > CHAR_DATA * fight_list_sorted = NULL;
> > CHAR_DATA * ch;
> > CHAR_DATA ** l;
>
> Why use a pointer to a pointer?
I use a pointer to a pointer so I can alter the contents of it without actually
making a distinction between the beggining of the list and the rest. All I need
to do is breaking the loop at the propper place. Something like this:
for ( l = fight_list_sorted; l; l = l->next_fighting_sorted )
{
if ( l->initiative <= ch->initiative )
break;
}
wouldn't work then, because in changing "l", I would be modifying a copy of
fight_list if it was empty, and not the variable itself. Also, I would have to
check one element ahead. The alternative would be something like:
if ( !fight_list_sorted || ch->initiative >= fight_list_sorted->initiative)
{
fight_list = ch;
ch->next_fighting_sorted = fight_list;
}
else
for ( l = fight_list_sorted; l->next_fighting_sorted;
l = l->next_fighting_sorted )
{
if ( l->next_fighting_sorted->initiative <= ch->initiative )
{
ch->next_fighting_sorted = l->next_fighting_sorted;
l->next_fighting_sorted = ch;
break;
}
}
There. Difference is that I can write the first in 4 lines and with my eyes
closed, while I need to think and I can actually commit a mistake in making the
second. I need to consider more in the second approach. In the end, it's a
matter of taste, I always do it the first way. Takes less time and I consider it
more readible, but it's a matter of opinion. I found few who agreed this way is
better, but I actually like it. If list_update() was written like this in Envy,
it would take far less code and would contain far less paranoid checks <g>
> You could create an array of pointers to lists indexed by initiative, eg:
>
> CHAR_DATA *init_fight_list[MAX_INITIATIVE];
Nod, perfect. I hadn't considered setting a maximum initiative but it's obvious
one must exist. It's a fine solution.
> I also use initiative, but not in a round-based situation. I let people
> hit as fast as their initiative allows (variable speed combat).
Like 1 person making 1 attack while another makes 1.33 attacks? Like setting a
timer for each attack lower with higher speed? Fun! :)
Darren Coffin
>I'm sure I've seen a reasonably good implementation of this
>Was it the isles? I think so. Hmm, somebody will remind us
>all I'm sure. Rounds did eventually time out (that is, they
>had a fairly long duration, and if you entered no command,
>you would eventually be taken to have done nothing in the
>next round).
I'd be interested in checking out any muds that use turn-based combat.
I'll check around on the mudlists for "Isles", but if anyone knows any
telnet addresses of muds of this style, please let me know. :)
>A simple way to handle the "fast connect vs slow connect"
>and other lag related problems is to allow for various
>defaults to be specified ahead of time, so even if your
>very long round times aren't long enough when a particular
>person hits a bad lag, okay, the defaults help out a bit.
>
>These defaults could be fairly detailed, I'm sure, or as
>simple as you please.
That's a good idea...sort of like having triggers for when you go linkdead.
I had only considered a single default, but perhaps I could make several
defaults; "If I am below X hit points, cast heal" or some such.
>I do love the idea of allowing for closing/withdrawing
>and 'range'. This could be implemented as you suggested
>later in this thread, with rooms having max sizes for range.
>Also consider allowing for range by essentially connecting
>rooms with invisible walls -- that is, grouping rooms in
>arbitrary ways by defining their connections as essentially
>see-through. This allows, I think, for a fairly straightforward
>changeover from current room-based thought and extends all
>the advantages of range and irregular room "line of sight"
>fun.
I'll put more thought into the ranges as well. I was a bit unsure about
it, but it would be another way to set my mud apart from the rest. Of
course, it'll take me a long time to get it anywhere near completion since
it's all still theoretical now. But I bought an old Pentium just for
putting Linux on and fiddling around with LPC. It'll be a fun hobby even
if it never gets put up. :) It would just be me working on it, most
likely; I'd rather just have some fun with it myself, and not have to deal
with conflicting opinions that can happen in teams of imms. Thanks for the
input...
-Darren
mor...@niuhep.physics.niu.edu
>The obvious solution (Which I'm sure most people have seen and dismissed)
Yup :-)
>is simply to not use a time multiplier in the game, mapping time 1 to 1
>with reality. The only reason most muds use them now is because nobody
>wanted to break frm D&D. Of course, this may not "mesh" with your game,
>but then, do these screwy time dilation problems "mesh"?
My reason for dismissing 1 to 1 time is that I want to make time of day
matter. I want day to be day and night to be night. By speeding up
time by 5:1 a person can play for 5 hours and go through an entire
day. Playing 1:1 that person might be stuck in daytime or nighttime
for the entire time, which may be a significant disadvantage depending
on the character.
Robert
Tim Kutz
Jorge Pereira wrote in message <37BC6BAA...@mail.pt>...
>
>Anyway, it turned out pretty easy to make initiative rolls. The issue here
>is determinating initiatives in each round. It is easy thinking of it as
>assigning each fighting character a value, then going through the list in
>that order, from higher to lower.
>
>
[SNIP]
>Well, this process is not worse then what's used on merc/envy, cause it
>doesn't require a loop through all characters, so that extra loop in step
>4 is actually not much of a problem. But I'd still like to make this a
>little more efficient. This involves a better way to loop through the list
>in order of initiatives. Another aproach to this would be not creating the
>sorted list in step 4 and looping through fight_list as many times as
>needed,
>selecting the character with highest initiative, making its attacks and
>flagg it.
>
>Anyone has ideas on this? A sample of the code used is below. Improvements
>are welcome! :)
Well, a question of critical importance here, is how OFTEN are you calling
update_violence()? If, for example, you are calling it every second, and
you want a ten-second lapse between combat rounds for a character, then just
set an integer in each char_data recording the last time someone went. Call
update_violence() with the appropriate number, and only process the fighting
instructions for those with the matching time index. start_fighting() would
set this index appropriately.
To reflect things such as haste spells, weapon speeds, and other time
adjusting criteria, you could make the index a count-down timer, and as you
go through the list, process all those at zero (including setting their
timer for the next action, at the end) and decrement the rest by one.
You only go through the character list once, and for the majority on the
list, you'll merely test a value, and subtract 1 from it, and then move on.
The nicest thing about this, is that if you increase the frequency of the
update_violence() call, to simulate a finer time granularity, you will
probably find fewer characters being processed on each pass, meaning that
there is little efficency loss for doing so.
Tim Kutz
t...@environs.com
David Kristola
>On 19 Aug 1999 06:34:10 GMT, David Kristola <dkri...@see-my.sig> wrote:
>>
>>Something i have been thinking of doing is plunging the
>>whole mud into "slow time" when a combat starts anywhere.
>>If i am smart, i will make it a configuration parameter
>>(to block or allow the feature) and experiment with it.
>>In some mud environments this might work fine, in others
>>it might be horrible.
>>
>
>This seems very likely to have disastrous consequences. Muds generally run
>at an accelerated rate of time anyway, and combat is generally accelerated
>even more than the normal rate. Slowing everything down to real time
>whenever combat starts and doing a real time combat system would make that
>walk to the corner weapon shop take a real long time if you tried to do it
>at the wrong time. I this this would be more of a hindrance to the
>immersion than a help in most situations.
:-) Maybe disastrous in general, but for my particular
needs, "slow time" will probably be just what i am looking
for. You see, my project is designed towards the idea of
running an RPG on-line in a virtual world. All the people
on the mud will be in that game, and either in or near the
combat.
Of course, for a more general use, the configuration
parameter can always be altered to turn off the feature.
Another thought....
AD&D's combat round is defined as being about one minute.
A mud that is running at a 4:1 time ratio could use one
minute combat rounds, ask that players enter their actions,
and still have a deadline of 15 seconds. How long does
it take to type "attack david" or "cast fireball at david"?
Since the idea of a combat round is abstract, each combat
round could represent two minutes instead of one. Time is
fluid in a simulated universe. How fast/slow would you
like it to go?
Dredd
> My reason for dismissing 1 to 1 time is that I want to make time of day
> matter. I want day to be day and night to be night. By speeding up
> time by 5:1 a person can play for 5 hours and go through an entire
> day. Playing 1:1 that person might be stuck in daytime or nighttime
> for the entire time, which may be a significant disadvantage depending
> on the character.
>
> Robert
But, running like that could make for some trully cool characters, like a
nightstalker, or just simply having a different class (type) of people who
rule the night, undead, or undead hunters (the stupid kind). better yet
depending on how much roll playing there is, you could have the
miss-adventures of some late night bar hoppers. just an idea if time is
going to prevelant.
--
"Nobody is innocent; there are merely varying degrees of guilt"
--Dredd
Jon A. Lambert
>
>the mud; note how I said "perhaps I'll do this"...I'm still trying to
>decide that. My initial reason was because combat should take place in
>seconds or minutes of game time as opposed to the hours that can fly by in
>accelerated "mud time." But then again, so should most things players do.
>Maybe I'll take someone else's suggestion and make a real-time mud.
>Whatever time it is locally(for me) would be the standard time for those
>playing the game. If a spell lasts for 2 minutes, then it lasts for 2
>minutes of real time. But then you run into the travel time problem;
>people can travel the world in a matter of minutes, which allows a single
>half-hour spell to last them for 10s of combats or more. It bears more
>thought...I think there will always be some sort of time paradox, I just
>have to pick a way which seems best for playability and enjoyment. :)
Other than the time problems, which are present in most muds
anyhow, there are other problems and paradoxes regarding state
changes. These are either accepted or glossed over and patched.
They are part of what current muds do.
Going from automated round-based to turn-based might cause
one to reflect on the "certainty" of this paradigm.
Why have a combat state separate and distinct from the state of
non-combat? What triggers these transitions and why?
Normal--->Combat
1) typing 'kill or murder'
2) object of 1)
3) object of "offensive" spell
Combat-->Normal
1) death of either combatant(s)
2) flee of either combatant(s)
3) special spell or object ability that ends combat
Note that the absence of these two distinct states does remove the
time problems associated with them. There are reasons to keep the
two states distinct. The most often stated, is the shift from leisurely
activity into pulse-pounding arcade excitement. Perhaps that's over
the top but it captures the essential line of reasoning which boils
down to "fun".
The problems and paradoxes show up in areas where one can
combat another without entering the state of combat. In many
implementations, an observer of the combat can affect parties
to the combat via objects and spells. A healing spell on one
party is just as effective as a fireball on the other party, although
the fireball more often falls under restrictions. Also one can
give another objects that are immediately fatal or temporally
fatal, without entering into combat. It is also possible to
combat another indirectly through controlled third parties or
placed objects. Throw in arbitrary PK restrictions on entering
the combat state and the paradoxes increase.
There is another way to look at how many current muds work.
They are already turn-based. Each turn being being a sweep of
the input timing loop. You either take your turn by having a
command stuffed and ready in the buffer or you forfeit your
turn by not. Of course only bots can keep up with the pace
of these turns. So many implementations have a hardcoded
limit to the number of commands that can be executed for
one in a given timeframe. Often it is only used as a form of
spam protection.
So with all that random stuff in mind, consider that the combat
state might instead be more useful and fun if it is merely another
level of time and action granularity that is voluntarily entered or
exited by anyone anytime. A modal construct without moral
significance. By "moral", I mean the rules or laws of the world
won't suddenly change when switching between modes.
There are a couple of things one can attempt. Translate "time"
instead into an action cost or action points that can be spent at
rates consistent with one's mode. Make use of the limiting the
normal mode turn-rate at x action points per second or pass, while
making the combat mode turn-rate y action points per 5 seconds
or pass. The time (real time) discrepancies are ignored. The
consistency between characters/creatures is also ignored but
is resolved separately within the mode they operate per room.
Thus combat mode characters pace of action has no effect on
delay for normal mode characters while traversing a room.
Certainly a character in combat mode might be more effective
than one choosing to operate in normal mode and that can be
reflected in action point cost. Also I think a higher exhaustion
rate expenditure by combat mode characters might offset this
advantage in other ways.
Now is this "fun" and playable? That is the measuring stick.
I'd say it depends on your playerbase. The twitch or arcade-
style players may prefer automated over the more leisurely
paced turn system. The turned based system might do more
to satisfy those more comfortable with the wargaming or FRPG
style games. Look at multi-player Civilization vs. multi-player
Age of Empires as an example of turn-based vs. time-based.
Just a few random thoughts.
I am doing a turn-based system BTW. :)
--
J. Lambert
Jorge Pereira
> I also use initiative, but not in a round-based situation. I let people
> hit as fast as their initiative allows (variable speed combat).
>
> KaVir.
Nod, changed to that too, and looks a lot better then with initiative. Anyway,
I'm curious, on a "standard diku" diku, do you think this kind of system would
make sense together with "multiple attacks"? I mean... "2nd attack", "3rd
attack", those really seem like speed dependant to me, although some degree of
skill is involved... but if you're attacking more often, doesn't making extra
hits per attack (using speed for their chance too) sound a bit repetitive?
Jorge Pereira
> Jorge Pereira wrote in message <37BC6BAA...@mail.pt>...
>
> Well, a question of critical importance here, is how OFTEN are you calling
> update_violence()? If, for example, you are calling it every second, and
> [snip]
Some other posts suggested similar approaches, and I went on to test it. The
result looks fine, ending up in asynchronous rounds. It's really as simple as
calculating how much "time" will you take to make another attack at the end of
each attack. It looks a lot better then the "initiative" setting I had, mainly
because speed plays a much more important role and is more "visible". It also
opens space for a wider range and effect of things like haste and slow.
Btw, anyone thought of speed modifiers for terrain types, temperatures and
weather conditions? If so, how "visible" do they come up in gameplay?
ps: thanks for the hint :)
Sterling
>Btw, anyone thought of speed modifiers for terrain types, temperatures and
>weather conditions? If so, how "visible" do they come up in gameplay?
The problem is that, outside of ranged combat, those conditions will be
effecting both sides of the combat. And those conditions wouldn't have much
effect on ranged combat (terrain might, but that depends on how complex your
presentation of terrain is).
Jorge Pereira
> On Tue, 24 Aug 1999 02:48:35 +0000, Jorge Pereira <ev...@mail.pt> wrote:
> >Btw, anyone thought of speed modifiers for terrain types, temperatures and
> >weather conditions? If so, how "visible" do they come up in gameplay?
>
> The problem is that, outside of ranged combat, those conditions will be
> effecting both sides of the combat. And those conditions wouldn't have much
> effect on ranged combat (terrain might, but that depends on how complex your
> presentation of terrain is).
Well, it would still be felt. If both sides experienced, for example, a
decrease in speed when fighting in a rough terrain, it would still be felt. On
the other hand, there could be some interesting points in this. For example, if
you associate a given race with a given terrain type, and don't apply the
penalties for them. What I mean is, for examples, wood elves not suffering
penalties in forest, dwarves in the mountain or dark elves underground. Same
sort of thing with temperatures, with for examples, humans in an iceland
getting slower due to cold or lizardmen getting way faster in hot zones.
But I didn't mean to refer only to modifiers in speed. In your opinion, terrain
aspects could change the way a (normal, non-ranged) fight runs?
Nathan Carter (ARTS)
Wow. I'm in the process of doing the exact same thing you're describing.
Even the variable names are similar.
ANyway, here are my thoughts on it:
> For that, I used the following:
>
> 1) in the char_data structure:
> CHAR_DATA * next_fighting; // next fighting character
> CHAR_DATA * next_fighting_sorted; // explained below
> int initiative; // last initiative roll
You only need one more CHAR_DATA pointer. For now, call it next_fighting.
> 2) A separate list containing only the characters who are fighting,
> eg: fight_list. As global variables we would have:
> CHAR_DATA * fight_list.
Nod.
> 3) Add/remove characters to/from that list in start_fighting() and
> stop_fighting().
Unnecessary. See below.
> 4) In violence_update(), cycle through fight_list, assigning initiative
> values to each character while creating another list, sorted by that
> value (using the next_fighting_sorted field)
To create fight_list, walk down the entire char_list from top. When you
encounter someone who should fight in the upcoming round, roll their
initiative and save it in ch->initiative.. THEN, create the fight_list,
inserting characters into it at the appropriate place depending on their
initiative. Basically, walk down the existing fight_list until you either
reach someone with a slower initiative or hit the end of the list (NULL),
then insert the character.
Now you have two lists: char_list, and fight_list. At the end of the
initial walk down char_list, the fight_list is ready to use, already
sorted. (see below)
> 5) Still violence_update(), loop through that new list instead of looping
> through char_list.
As you walk down fight_list, execute your attacks for each character, then
reset their next_fighting to NULL and advance the fight_list pointer to
the next person in the list. In short, remove a person from the top of the
list after they have their chance to fight.
I've thought a lot about the efficiency of this method. The walk down
char_list will be relatively inexpensive. You have to hit every character,
but you only do any calculations for characters who are fighting.
Inserting people into fight_list looks like it would be really intensive,
BUT consider that probably only have a tiny fraction of total characters
are actually fighting. The number of steps to sort fight_list (as it is
created) will be the number of fighting chars, squared, divided by four.
Consider, for every insertion:
The average length of fight_list will be half its final length.
The average walk down fight_list will be half its average length.
The final length of fight_list is equal to the number of fightig chars.
Make sense?
So, even if you have 100 people fighting at once (unlikely, even if you
have 100 characters online), the total number of sorting steps will be
only 2500. A walk down char_list on Avatar approaches the 5-digit mark, so
the sort is relatively short compared to the walk down char_list.
The only difficult part about this is extraction of characters from
fight_list when necessary. If a character is killed before it's his turn
to fight, or if a character manages to quit during combat, or leaves the
room, or whathaveyou. This'll probably require an extra walk down
fight_list when a character is killed, to see if they're in fight_list,
and in extract_char if they manage to leave the game (or for mobs).
- Mega of Avatar mud
avatar.walrus.com 3000
Jorge Pereira
Well, your method also works, of course! :) But I shun at going through
char_list, because it is usually made up of well over 10k characters, when
fight_list has, as you refered, a really lower count (about 20-50 characters on
a 100 PCs game).
> The only difficult part about this is extraction of characters from
> fight_list when necessary. If a character is killed before it's his turn
> to fight, or if a character manages to quit during combat, or leaves the
> room, or whathaveyou. This'll probably require an extra walk down
> fight_list when a character is killed, to see if they're in fight_list,
> and in extract_char if they manage to leave the game (or for mobs).
Well, I added a flag on characters for safety. I call char_to_fight which puts
them in the list and char_from_fight, which removes them from the list and
removes the flag. The flag can be used to test if a character is in a fight,
even if he doesn't have POS_FIGHTING (eg: stunned) or has no ->fighting field.
Anyway, I only call the _from and _to functions in 2 other functions.
char_to_fight is called in set_fighting(), and char_from_fight is called in
stop_fighting(). You don't have to care about character extraction /death
/whatever, this is a bit higher level.
Also, I actually prefer Kavir's solution, with an array index by initiative,
rather than having players in a list.
One way or the other, I gave up on this solution as it wasn't that visible...
that is... unless you post some message to the player stating he gained
initiative, he won't probably notice it. Since I already had speed as a
distinct factor, I moved to independant combat rounds, like someone (think it
was Tim) suggested on another post. It is a lot more realistic too. Actually, I
think Initiative is mostly a way to handle a group of players trying to do
actions simultaneously in a table-RPG, but there are fancier solutions in
gameplay. Initiative can still be interesting, though, when a character attacks
and the other spots him in the act, thus gaining initiative and taking the
first round of attacks. But if there are no rounds, and you base it on speed,
then initiative loses value! :)
Aristotle
>One thing that I'd like to try with the mud is to implement true turn-based
>combat, and I wanted to get some opinions on it. In every mud I've played
>so far, you type "kill orc" and the program merrily chugs away, making your
>character swing and defend automatically. In the midst of all of this, you
>can cast spells or perform skills; from a roleplaying point of view, you
>can be hacking at the opponent with a two-handed sword while simultaneously
>casting a meteor shower. It doesn't make much sense.
The only problem I see with a turn based system is balancing things out as far
as player advancement. If combat only takes a few turns to complete, people
are going to be able to wade through many combats quite quickly. This means
they are going to advance pretty fast. If you adjust exp values so advancement
is the same rate (meaning say, they can gain a level every day or every week,
or whatever your current rate is), people are going to get pretty annoyed
since combat now requires them entering a command every turn.
Now, if your game is mostly an RP game, a turn based combat system might be
totally the way to go. However, a dedicated hack-n-slash/power gamer can play
havoc with a turn based system if it gives out similar exp/battle as a non
turn based system.
-Aristotle@Threshold
--
Threshold was an exhibitor at Dragon*Con '99.
Dragon*Con Pictures: http://www.threshold-rpg.com/dcon/
==============================================================================
VISIT THRESHOLD - Online Fantasy Roleplaying Game. Player run clans, guilds,
legal system, economy, religions, nobility, and more in a mature environment.
http://www.threshold-rpg.com -**- telnet://threshold-rpg.com:23
Darren Coffin
>
>The only problem I see with a turn based system is balancing things out as far
>as player advancement. If combat only takes a few turns to complete, people
>are going to be able to wade through many combats quite quickly. This means
>they are going to advance pretty fast. If you adjust exp values so advancement
>is the same rate (meaning say, they can gain a level every day or every week,
>or whatever your current rate is), people are going to get pretty annoyed
>since combat now requires them entering a command every turn.
>
>Now, if your game is mostly an RP game, a turn based combat system might be
>totally the way to go. However, a dedicated hack-n-slash/power gamer can play
>havoc with a turn based system if it gives out similar exp/battle as a non
>turn based system.
>
>-Aristotle@Threshold
This sort of game balance issue comes up in any game architecture, though.
Games like the old Bard's Tale series, or other such "RPG" games(and I use
the term loosely) used turn-based combat where you had to type something in
every turn for every character in your party before the actions would get
resolved. Yet the games had widespread appeal; some people will certainly
be annoyed by having to enter an action every turn, while some will not. I
get annoyed typing "kill orc" and then sitting there watching the spam go
by...but a lot of people like that method. I don't claim that turn-based
combat would appeal to everyone.
I have yet to see a mud where a powergamer doesn't advance more quickly
than a non-powergamer. Obviously, the exp rewards will have to be played
with to find a proper "average" rate of advancement, but powergamers will
always be faster than the average. I know you've done things like
enforcing a no triggers rule, which probably restricts the powergaming a
bit...I'm sure the "powergamers" on Threshold are still far more advanced
than the non-powergamers, though.
-Darren
Ilya
>
> I dropped multiple hits completely*. You could have "faster
> attacks" as an alternative I suppose. I certainly agree that
> having both multiple attacks AND initiative based combat
> wouldn't work very well.
>
> *Unless you give up your parry, and hit with both hands.
>
> KaVir.
I heartily support this construction! Weapon mass and balance
popped into a formula with weapon skill, strength, and
body balance should be able to give us interesting variations
in speed, and avoid the whole "n attacks per round" syndrome,
and much more elegantly I think.
I
Aristotle
>This sort of game balance issue comes up in any game architecture, though.
>Games like the old Bard's Tale series, or other such "RPG" games(and I use
>the term loosely) used turn-based combat where you had to type something in
>every turn for every character in your party before the actions would get
>resolved.
The difference is that games like Bard's Tale are not competitive. Also, in
games like that, after 50 hours or so of playing time you were enormously
powerful. If you could attain nearly "top level" in a mud in 50 hours, players
would have to restart every few weeks. (of not every other week!).
Rich Allen
you get a disparity between combat time and normal time, but if you fix
that, then you also have to fix skill training time to make that more
realistic too. And that, my friends, would require characters to train
in only one skill at a time (or maybe a couple very similar related
skills) and take several game days at the very least to do it! If you
can ignore the time disparity in skill training, why is the relatively
minor disparity in combat time bothering you so much?
Rich Allen
AG
Jp Calderone <exa...@flashmail.DONT-SPAM.com> wrote in message
news:37BB34B5...@flashmail.DONT-SPAM.com...
> rric...@lanminds.com wrote:
> >
> > On Wed, 18 Aug 1999 13:01:37 GMT, dco...@ivory.trentu.ca (Darren
> > Coffin) wrote:
> >
> > [snip]
> >
> > The other thing that you have to consider is what is going on outside
> > the combat. Let's say, for example, that you are basing your mudtime
> > on 6-hour days (thus 4 game days to one real day). Then, a battle
> > that takes 5 minutes in RL time, but which might be over in a minute
> > game time, will be out of sync with the rest of the game. This may or
> > may not matter, depending on how important time is in the game. The
> > main thing I can see it messing up is longterm spells, and possibly
> > time-triggered events (such as if a portal was only open during a
> > certain time.) I have thought about this some, and I just can't see a
> > way to handle the different timescales of parties in combat, those
> > traveling long distances, and the day-to-day times.
>
> with reality. The only reason most muds use them now is because nobody
> wanted to break frm D&D. Of course, this may not "mesh" with your game,
> but then, do these screwy time dilation problems "mesh"?
>
It also proves biased when you have players from different timezones on your
mud. I don't know about you, but I'd get fed up with a mud where I had to
play in perpetual night, or wait around for a screwy end of my time just to
match up with mud time so I could get to that one shop only open during the
day, that sold an item I desperately needed...
I'd recommend just not using your combat time multipliers with
non-combat-cast spells. Either create a separate list of the spells as
they're cast in combat, or don't apply the multiplier to particular spells.
You are working on combat having a time dilation effect before slipping back
into "normal" mud time? If that's so, I'd just ignore the multiplier.
TerMite
John P. Freeman
Darren Coffin <dco...@ivory.trentu.ca> wrote in message
news:FGMA79.Gn...@news.trentu.ca...
> Hello. I've been mudding for about 4-5 years now, and was an imm for a
few
> months as well. I've also been roleplaying for about 14 years. I've
> decided that I want to tinker around with a mud in my spare time(what
> little I have of it)...
>
> One thing that I'd like to try with the mud is to implement true
turn-based
> combat, and I wanted to get some opinions on it. In every mud I've played
> so far, you type "kill orc" and the program merrily chugs away, making
your
> character swing and defend automatically. In the midst of all of this,
you
> can cast spells or perform skills; from a roleplaying point of view, you
> can be hacking at the opponent with a two-handed sword while
simultaneously
> casting a meteor shower. It doesn't make much sense.
>
> be. He can attack or cast a spell, but not both at once. He can alter
how
> aggresive he will be; the more aggressive he is, the better chance of
> can be implemented, and a chance of spell failure if hit in the midst of
> casting.
>
> Of course, there are problems with this approach. But I think I can
> solve/work around most of them by creating a turn timer. If the character
> doesn't take an action within something like 10 seconds, then a default
> action will be taken. This default action can be defined by the player.
> If an action is taken before the 10 seconds are up, the action will take
> place and the creature will respond. Then the timer will be reset to 10
> seconds for the next round. When multiple players are involved, there
will
> be a single timer; if all players choose an action before the timer is up,
> the results will be determined. Otherwise, once the 10 seconds are up,
> those who have chosen will take their chosen actions while those who
> haven't chosen will take their default actions.
>
> The timer and default actions should deal with the problems of lag and
> losing link in the midst of combat.
>
> Are there any comments on this system? I'm considering coding it in LPC,
> as from what I can tell, LPMuds are the most customizable ones out there.
>
> -Darren
>
Three words for you: Mordor Server Code.
Actually I was lying about only saying 3 words. <g> In the Mordor MUD
server, each command is considered an 'action' that takes a certain amount
of time. The time for any given action is modified by a number of character
attributes including stats and class. (For example, mages can cast spells
faster than other classes.) The user can not perform another action until
the 'action time' has expired. This is all done in real-time and makes all
players stay on their toes. Given all of this, there is no real need for
the concept of turn-based combat or combat rounds. At any given chance, you
may fight, cast, flee or choose whatever actions are available to you at
that time but you absolutely cannot do 2 things at once. It may be
considered primitive in some form because its not based on the traditional
turn-based combat found in DnD but most Mordor players think its more
realistic and more fun this way. If you are interested in the code, the
home page for Mordor Server and its sister MUD, Isengard, can be found at
http://mordor.nazgul.com
Please keep in mind, as one of the main Mordor programmers, I recognize I
have a very biased opinion in this matter <g> and do not wish to start any
flames or religious wars here, just describing a concept in use. The
implementation in the Mordor code is relatively simplistic, could have been
implemented better etc etc. I also don't frequent these newsgroups often
will not likely be back soon enough to reply to any questions. Sorry.
Happy Mudding,
John Freeman
Darren Coffin
>
>Actually I was lying about only saying 3 words. <g> In the Mordor MUD
>server, each command is considered an 'action' that takes a certain amount
>of time. The time for any given action is modified by a number of character
>attributes including stats and class. (For example, mages can cast spells
>faster than other classes.) The user can not perform another action until
>the 'action time' has expired. This is all done in real-time and makes all
>players stay on their toes. Given all of this, there is no real need for
>the concept of turn-based combat or combat rounds. At any given chance, you
>may fight, cast, flee or choose whatever actions are available to you at
>that time but you absolutely cannot do 2 things at once. It may be
>considered primitive in some form because its not based on the traditional
>turn-based combat found in DnD but most Mordor players think its more
>realistic and more fun this way. If you are interested in the code, the
>home page for Mordor Server and its sister MUD, Isengard, can be found at
>http://mordor.nazgul.com
That sounds pretty neat, but it's not exactly what I'm thinking of. It's
similar, and I think I'll definitely check it out...but it sounds like
triggers and response time are still a lot of the Mordor system from what
you describe of it. I guess I'm too much of a roleplayer(tabletop
roleplayer, that is) to fully give up on the concept of a turn. :)
>Please keep in mind, as one of the main Mordor programmers, I recognize I
>have a very biased opinion in this matter <g> and do not wish to start any
>flames or religious wars here, just describing a concept in use. The
>implementation in the Mordor code is relatively simplistic, could have been
>implemented better etc etc. I also don't frequent these newsgroups often
>will not likely be back soon enough to reply to any questions. Sorry.
Understandable. :) I'll check the website and probably the mud itself.
Thanks for your input, in case you do read this. :)
-Darren
Rycochet
> > One thing that I'd like to try with the mud is to implement true
> > turn-based
> > combat, and I wanted to get some opinions on it. In every mud I've played
> > so far, you type "kill orc" and the program merrily chugs away, making
> > your
> > character swing and defend automatically. In the midst of all of this,
> > you
> > can cast spells or perform skills; from a roleplaying point of view, you
> > can be hacking at the opponent with a two-handed sword while
> > simultaneously
> > casting a meteor shower. It doesn't make much sense.
> >
> > My idea is to have the character decide every round what his action will
> > be. He can attack or cast a spell, but not both at once. He can alter
> > how
> > aggresive he will be; the more aggressive he is, the better chance of
> > hitting but also the better chance of being hit in return. Casting times
> > can be implemented, and a chance of spell failure if hit in the midst of
> > casting.
> Three words for you: Mordor Server Code.
>
> Actually I was lying about only saying 3 words. <g> In the Mordor MUD
> server, each command is considered an 'action' that takes a certain amount
> of time. The time for any given action is modified by a number of character
> attributes including stats and class. (For example, mages can cast spells
> faster than other classes.) The user can not perform another action until
> the 'action time' has expired. This is all done in real-time and makes all
> players stay on their toes. Given all of this, there is no real need for
> the concept of turn-based combat or combat rounds. At any given chance, you
> may fight, cast, flee or choose whatever actions are available to you at
> that time but you absolutely cannot do 2 things at once. It may be
> considered primitive in some form because its not based on the traditional
> turn-based combat found in DnD but most Mordor players think its more
> realistic and more fun this way. If you are interested in the code, the
> home page for Mordor Server and its sister MUD, Isengard, can be found at
> http://mordor.nazgul.com
Just my two cents worth, i'm writing a totally new mud codebase, using
the same sort of system as this (recovery time, or whatever you want
to call it), in a fight i am wanting to have it the best of both
worlds:
Each time you can move, it will check if you have sent anything to the
mud, if it's a command it will execute this, then, if your recovery
timer is 0 (no command, or the command took no time (ooc commands
esp)) then it will perform a default action, which will be the next
attack type for your weapon and stance (aggressive goes for big damage
but low protection, defensive might try to block an attack, even if
there is none). this way fights can continue even if there is bad lag,
and players can put as much effort in as they want, the only downside
is that you *have* to stack at least one command, and this can be
detrimental to your health if you're unlucky ;-)
Rycochet