[MUD-Dev] Combat Systems

Hans-Henrik Staerfeldt hhs at cbs.dtu.dk
Wed Jul 19 18:27:09 New Zealand Standard Time 2000


On Wed, 19 Jul 2000, Ben wrote:
>=20
> The way it works is EVERYTHING is used through the command qeue.  Each
> command in the qeue also stores where the person was when they executed=
 and
> their state, before actually executing the command, it checks the state=
 and
> location.  So even if a move, which would obviously execute quicker the=
n the
> panama canal example, when the panama canal thing executes it would rea=
lize
> that it didn't work.  The obvious problem here is that if the canal is =
so
> long that I can return to the same place before it executes, it will st=
ill
> execute, to get over this the canal would be in parts, and would cause
> another event... for example
>
> You have dug a deep hole here, you move on to another area of the canal.
>=20
> In this way nothing would take that long, I know their are obvious prob=
lems
> here... if anyone has any ideas to fix it, please send a reply...


Mathematically, you simply sample the player state over time, and assume=20
no change has happened in between. However, this method require that you=20
sample often enough, (equivalent to subdividing the task into a
gadzillion subtasks) in order to get a fairly accurate idea of, if the=20
player was 'active' in the short period of time since last check, or=20
interrupted somehow.=20

The other obvious way i see, is that for each task you set up, you need a=
=20
'thread' monitoring events that would invalidate/encumber/modify that tas=
k.
This applies to most any task you could imagine; combat, spell casting,
building & creating, even digging the panama canal. Assuming that the gam=
e
is event driven, you should get those events directly, and monitoring the=
m
and modifying the 'panama canal is finished' event would be easy based on
the events you get (shovel break, attack, hungry, sleeping, etc).

the thread needs not do anything than waiting for events and only be acti=
ve
when events occur, and modify the position of the end event in the=20
event queue.

Hans Henrik St=E6rfeldt   |    bombman at diku.dk    | work:  hhs at cbs.dtu.dk=
      |
address:                |___  +45 40383492    __|__       +45 45252425   =
  __|
 Dybendalsvej 74 2. th, | Scientific programmer at Center for Biological =
    |
 2720 Vanl=F8se, Danmark. |  Sequence Analysis, Technical University of D=
enmark|




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



More information about the MUD-Dev mailing list