[MUD-Dev] Combat Systems

[J C Lawrence]

On Tue, 18 Jul 2000 19:07:39 -0400 
Ben  <bjchambers at phoenixdsl.com> wrote:

> The threads are engineered in such a way that there is a universal
> command qeue...

There has been considerable discussion of threading models for MUD
servers here on the list.  You might want to hit the archives for
some background.

> The primary thread of execution is the server thread, where the
> commands are actually executed.  The player thread waits for input
> then preprocesses it, by filtering it, parsing it, etcetera, then
> adds it to the command qeue.

While abstracting command processing from the main server execution
has a certain sense to it, why not also abstract actual event
execution from the base job of running the server (the select loop,
backing store maintenance, automation routines, etc)?

> The server thread allows everything to happen in realtime relative
> to each other.  The way the command qeue works is it is an array,
> say 60 units long, of pointers.  Then each unit is a linked list.
> Each linked list contains all things that are supposed to happen
> in that ammount of rounds from now.  For example it executes all
> things that are in array 1, then shifts it down, moving 2 to 1
> etc, but instead just changing the pointers.  But then for things
> that take longer than 60 rounds to complete, they also have a
> cycle attribute, for example if it is 1, and it is in array one it
> would execute, if it is 2 and the item is in array one, it would
> subtract one from the attribute and shift it over to 60, in this
> way all the events are just appended to the command qeue, so for
> thread locking you just lock the pointers in the command qeue...

What happens if Bubba starts an event that will execute in N rounds,
but before that time expires he moves or otherwise state changes
such that the sceduled event is now either impossible, or has an
effect different than initially intended?

eg:

  > l
  Boffo is standing to the north of you.
  > cast fireball north
  You start casting the spell.
  > w
  You go west.
  > l
  Bernie is standing to the north of you.
  You cast the fireball!  Bernie is fried!

This is a simple (and very crude variation) on the basic problems of 
extended run commands -- ie events which have long in-game execution 
times.  The canonical example used here was digging the panama
canal, a task one might presume would take consider time.

What happens if Bubba starts digging the panama canal and then
starts to do something else in the middle?  Is attacked in the
middle?  Gets hungry?  Has his shoevel break?

Search for "panama & canal" in the list archives for some good
threads on this area.
  
> Has anyone documented a combat system similar to this?  

Yep, there are the several varations that have been discussed here:
mine, Orion Henry's, Adam Wiggins', and Jon Lambert's (indirectly
discussed here as a part of his general event model in contrast to
my C&C model).

> Anyone have any ideas about ways to improve this?  Any thoughts
> about whether this is actually possible?

I suspect you'll have a more gain looking for the areas where your
model breaks down.  Historically it has been the corner cases (you
know your players will seek out, find, and then exploit them) which
have proven most valuable in developing modesl in this area.  The
extended execution events mentioned above are just one such corner
case.

NB You might also want to look into my design for combat scripts.
Its actually a pretty horrible and unwieldy idea that I'd recommend
running away from, but the discussion and analysis I recall it
sparking was quite good.

--
J C Lawrence                                 Home: claw at kanga.nu
---------(*)                               Other: coder at kanga.nu
http://www.kanga/nu/~claw/        Keys etc: finger claw at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


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