[MUD-Dev] MUD Design doc - Combat

Jon A. Lambert jlsysinc at ix.netcom.com
Mon Dec 28 02:54:46 CET 1998


On 17 Dec 98, Emil Eifrem wrote:
> At 04:31 AM 12/17/98 , J C Lawrence wrote:
> 
> [timing in combat:]
> >In #1 each player action (eg "bash buffa") takes a preset length of
> >time, and prevents the player character's motions/actions during
> >that time.
> >
> >#2 is a little different.  Players submit the actions that their
> >characters are going to perform in the next "round", where a round
> >is a known and predefined length of time.  At the end of the round
> >all the various actions by the various players are resolved against
> >each other (the action and round resolution logic can be quite
> >complex -- see the combat package threads in the list archives) and
> >the final results computed and reported before the next round starts
> >and the players again submit their intended actions.  It is common
> >with round systems for player characters to operate under a quota
> >system, where each of their proposed actions has a quota value and
> >their total must not exceed some maximum.  See Jon Lambert's posts
> >on his (IIRC) round based combat system for some interesting design
> >notes on this area.
> >
> >#3 is where I've been heading, while mixing in generous dollops of
> >#1 and #2.  Loosely, each character does whatever he can as fast as
> >he can with the limiting factor being the execution time of his
> >various actions and the speed with which he can submit them.
> >Arguments about fairness are of course rife with this approach.
> 
> Ack. Haven't your players heard of tintin?
> 
> Surely you must have some way to delay a player's queing commands while
> they're busy doing something else. For example, say you have a spell that
> causes damage. According to the above, a fight between two people with this
> spell would basically be a fight between their clients and connections --
> whomever gets through most "cast my damagespell" messages would win.
> 
> This doesn't sound feasible, so I assume that you do have individual delays
> after commands. I think that's what you mean with the limiting factor being
> the execution time of various actions. So the execution time for cast
> damagespell would be pretty high and thus not unbalance the game. I don't
> see how that's different from 1?
> 

Here's my take on #2 reprised from earlier posts -

I plan to implement a timed turn-sequenced combat round.  I find the types of 
combat actions that interest me to be complex enough to warrant a turn based 
system.  Selecting default actions and modes of attack seem easy enough as 
well as allowing a time delay for character's orders to be submitted.  Suprise 
is implemented by either removing the time delay for the suprised character or 
by giving a free action points to the supriser.  Initiative can be implemented 
by alternating order of resolution or delay in execution of character actions. 

Combat mode can be entered and exited by any member of a room.  You are 
prompted whether you would like enter combat through any action including many
socials that might cause "a rush of adrenaline".  Thus any action is a
potential combat starter and individual commands are resolved as actions really
occurring.

It also occurs to me that one's character should be allowed to react in a 
strictly defensive manner, rather than a default offensive mode.  Ex.- If 
Bubba the drunken troll throws a tankard of ale across the tavern floor 
striking Boffo, it may be quite inappropriate for Boffo to automatically draw 
his sword and attack.  So I'm thinking more along the line of modal/prompted 
queries.

--example--
  Bubba hurls a tankard at you hitting you square in the forehead.
  Do you wish to engage Bubba? Y/N ....
  > N
  Ok.
  > throw dagger at Bubba's bar stool.
  You throw your dagger.  You miss the stool and the dagger hits 
  Bernie. 
  Do you wish to engage Bernie? Y/N
  > Y
  You have entered combat. You have 6 action points.
  # draw dagger from left boot
  You have 5 action points.
  # charge Bernie
  You have 3 action points.
  # stab Bernie
  You have 0 action points
  # done
  ...
  You draw a dagger from your left boot.  
  You charge towards Bernie.
  Bernie hurls a stool at you sending you crashing to the floor.

  You have 6 action points.
  # stand
  You have 4 action points.
  # say "Bastard!"
  You have 4 action points.
  etc...
--end example--

While in-game combat can be modal, one can always break out of the combat.  
I've always hated how automated combat systems continue until one side or the 
other is dead.  I've also dislike terminating combat by fleeing to another 
room or recalling to base.

A great many wonderful role-play opportunities exist in situations where 
conflict has come to a head.  The objective of combat should not necessarily 
be taking the life of the opponent.  It is to achieve glory and honor. ;)  
However there are generally no opportunities for players to mutually rest, to 
trade witty and provocative reparte between blows, to make called shots like 
cutting the cord holding up your opponents trousers, or calling it a draw and 
retiring for the day.  Sure there's still a good chance for immediate or slow 
death, but there's also ample opportunities for final words or curses, and 
protracted death scenes.  Why should an automated combat system force Sir 
Gawain to strike a blow on an unarmed combatant when he desires to wait for 
the opponent to retrieve the weapon?

Also, there may be a great deal of OOC dialog between the parties before these 
sequences take place and also some OOC coordination during staging of the 
event.  This is especially handy for larger free-for-alls.

My game systems are complex enough to make manually refereeing such an event a 
real pain.  And good gamemasters are hard to find when you are itching to 
settle a score.  Once entering the state where blows are exchanged, players 
have implicitly consented to abide by the rules of the computer referee.  This 
also allows any interested immortals time to respond and join into fray.


--
--*     Jon A. Lambert - TychoMUD       Email:jlsysinc at .ix.netcom.com      *--
--*     Mud Server Developer's Page <http://pw1.netcom.com/~jlsysinc>      *--
--* I am the Dragon of Grindly Grund, but my lunches aren't very much fun, *--
--* For I like my damsels medium rare, And they always come out well done. *--




More information about the mud-dev-archive mailing list