[MUD-Dev] Command Qeues - Was "Combat Systems"

Eli Stevens wickedgrey at wickedgrey.com
Wed Jul 26 11:58:43 New Zealand Standard Time 2000


Sorry this reply came late, but I have been on vacation and the original
post came halfway down the 280-message deep pile I had waiting in my MUD-Dev
folder.  :)

----- Original Message -----
From: "Ben" <bjchambers at phoenixdsl.com>
To: "Post" <mud-dev at kanga.nu>
Sent: Friday, July 21, 2000 11:58 AM
Subject: [MUD-Dev] Command Qeues - Was "Combat Systems"


>     The way commands work in real life is that each person knows what he
or
> she is doing, and then nature decides the effect of that.  I have decided
> that the best way to implement a similar system would be to have each
player
> keep track of their commands, then the server thread reads them at the
> appropriate time... for instance the server command queue knows that the
> player Boffo entered a command to dig panama canal, that is set to go in x
> rounds.  During that time Boffo changes his mind, so when the server
> executes it, it checks and sees that Boffo is no longer doing that action,
> and so doesn't execute it...  I know this isn't the best way, but it is
the
> only way I could think of.  I did it this way because it limits cross
thread
> communication, the server thread handles all the output...  Any ideas as
to
> how to handle the command queue in a better way? Please respond, thanks.

Have you considered storing pending actions directly on the player object
and only forwarding them to the server command queue when they have ripened?
While I don't know your threading model (and even if I did, I would not be
able to comment much on it :), I think this would work (at least) in a
single threaded model.

Whenever any of the following happens, perform any pending, ready-to-fire
actions, check the character's state for inconsistecies (like HP at -3, but
still living, have a dig canal AND a sleep command pending, etc.), etc.:

- The player enters a command
- The character is the target of something else (spell, attack, tell)
- The character object has notified the server that it would like to be
updated at a specified time (most likely a command ripens into an action
then)
- The server thinks that the player needs one (gone link dead?)

Since the number of commands/pending actions that a character may have will
almost always be several orders of magnitude smaller than the pending action
set of the MUD entire, you can apply brute force approaches that you could
not when working with the larger set.  For instance, if a character tries to
read a sign (action type: moderate mental, visual, little to no motion, no
physical) then dig that canal (action type: heavy physical, motion, visual)
you can check and see that the character is trying to do two incompatabele
things at once.  If the character was reading a sign, then was paralyzed
(action type: no motion), then the character could keep reading because the
new state does not conflict with the old action.

Ok, so the use of "action type" is not refiened enough to actually work, but
I think my point was clear enough.  :)  I hate to think what all this
discussion is doing to the game world, all these half-dug waterways
everywhere...  :P

<//> Silence is golden           RUIN, v.  To destroy.            <\\>
 ||  Eli                         Specifically, to destroy a maid's ||
 ||  wickedgrey at wickedgrey.com   belief in the virtue of maids.    ||
<\\> www.wickedgrey.com            -- Ambrose Bierce              <//>






_______________________________________________
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