[MUD-Dev] A new combat system

adam at treyarch.com adam at treyarch.com
Wed Jul 12 14:46:40 CEST 2000


On Mon, 10 Jul 2000 Dragat123 at aol.com wrote:
>     I have been reading through Jarulfs Guide to Diablo, which includes the 
> formulas that are used in the game.  My eyes settled mainly on the parts 
> about battle, and I think it would be possible to model something similar in 
> a MUD.  Basically I am gonna throw the idea out, and if anyone has any input 
> on it, please send it.  I am toying with the idea of making a server based on 
> these ideas, so I really need your ideas as well...
> 
>     In Diablo, every 0.05 seconds an update event occurs, this is similar to 
> a 'turn'.  During this update the order goes Player, Monsters, Magical 
> effects, such as arrows.

This, actually, is how most real-time combat systems work.  In fact, it
is this principle that *all* real-time simulations on a computer work:
simulate a "moment" in time during an update loop which hits all of the
entities and their processes in question, and then display what happened
to the user.  Turn-based systems are exactly like this but have longer
timeslices and pause inbetween the "moments" being simulated.

MUDs actually use this as well, but they tend to use very crude timeslices
(eg, combat rounds spaced several seconds apart) and are frequently not
internally consistent.  Stock dikumuds have an input/output timeslice of
0.1 seconds, a combat timeslice of 2 seconds, an NPC AI timeslice of 5 (?)
seconds, and so forth, and there's no interaction whatsoever between the
timeslices used for one type of action (say, combat swings) and another
(say, spellcasting).

>     Each living thing exists in one of several states.  These include 
> walking, standing, attacking, casting spells, doing hit recovery and being 
> stoned.

(I'll refrain from the way-too-obvious drug reference right here.)

Again, I think most muds have this, but the state is not internally
consistent.  You have position stored in one place, character affects
(paralyzed, stoned, etc) in another, current combat action in another,
current spell in another...and so forth.

> One must finish their current action before they may start a new 
> one, unless they get hit.

You have to be a little careful with this.  For example, what about
the "recovery" action, that is, the time it takes to recover from delivering
a blow?  Some systems don't have a seperate recovery action, but instead
cause the attack to be delivered at a certain point in the sequence, with
the tail end of the animation representing the moment of recovery.  (I
suspect that most coin-op character fighting games work this way.)

If I can be knocked out of recovery, this is a problem.  Other incapacitiating
actions (such as choking on poison gas or falling down a hole) should also
be uninterruptable.  My system uses a priority system: most player-executed
tasks are priority=minimal, combat tasks (attacking and defending) are
priority=life_or_death, and recovery-type tasks (choking on gas etc) are
priority=must.

>     Combat is divided into the following steps
> 
> Pre-hit- checks to make sure it is a valid target
> To-hit- Check to see if a hit is done
> Blocking- Check to see if opponent blocked
> Damage- calculate the damage
> hit consequences- life and mana stealing, death so on
> 
> Hit consequences include loss of durability etc.
> 
> Basically each weapon would have a base time.   Each character would have a 
> multiplier.  That is how long it takes to 'swing' the weapon.  So for 
> instance I could swing my sword more times than you could swing your big axe, 
> because mine has a faster base time...  This would make it interesting...  
> Any ideas on how to make it better, i.e adding spells and the such...

Yes, this is how ANY real-time game or simulation should handle combat,
IMO.  The system described here, in its general form, is what I would
consider to be a cornerstone of game design (and programming).

And, FWIW, the combat system on my mud works pretty much this way.  Actually,
it extends beyond the combat system - all player actions of any sort work
in precisely the same way.  (Do an archive search for my description of
"tasks".)

As I'm currently rewriting my combat system, I'm considering releasing
the source to the current implementation.  It's nothing special, being
basically an extended version of the Diablo system you descibe above, but
that still places it far above the typical action-timing systems found
in the vast majority of existing codebases.

Or better yet: can anyone point to a currently available mud codebase that
has a good system for handling character actions?

I never thought about it before, but perhaps this should go in the FAQ.
This falls into the category of "why doesn't everyone know this?" - and
perhaps the answer is that there's few (no?) resources which say,
"here's how real-time games usually work".

Adam





_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list