[MUD-Dev] World Event Model
Matt Chatterley
chattemp at ee.port.ac.uk
Thu Aug 3 10:53:13 CEST 2000
I saw a post similar to this a short while ago, and thought I'd post an
event model which I was considering (may still) use in a Roguelike game,
but which applies with equal validity to the rather Muddier world in
which this list lurks.
The server coincidentally uses a number of threads for managing different
aspects of the game, but I'll describe only one element for now - the
event handling and event model.
A central server thread runs continuously to execute a queue of events,
each of which can be either:
a) A single, one-off event (eg, an explosion)
b) A continue event, which is being updated (eg, something burning)
c) A separate sub-queue which is processed at either the same rate or a
differing rate from the main queue (eg, the sub-queue for a
fireball spell may process 4 events at times which are based on
the casters abilities, and might be checked every three ticks by
the main queue).
All game-effect player commands are 'hooks' which enter an event to carry
out the associated action, into the queue. For instance, the 'finger' and
'who' commands are non-game-effect (or 'Out of Character') and do not use
the queue, rather, they execute immediately. The 'fireball' and 'slap'
commands have in-game effects, and queue functions to handle the actual
effects of the commands.
All commands perform two sets of verification to ensure valid targets,
sufficient MPs, and so forth. The first set is checked at command-entry.
For instance, if 'charge bubba' takes 10 ticks, when you type 'charge
bubba' it will check that bubba is still there. If bubba has escaped by
the time that doCharge(bubba) executes, it will fail, with any
consequences. Of course, the player can abort his action if/when he
notices that bubba has escaped - this is not automated, to allow for the
player being confused by spells/tricks which bubba may employ. Of
course, this tests player skills rather than character skills, and could
be automated with skill/stat based failure.
Various game systems also queue events, such as updateWeather() and
doThunderStorm(), and so on - imagination can be applied here.
Players can view their own queues at any time they wish, and may
add/remove things from it, they can also 'cancel <command name>', since a
command 'pid' style system would be in use to make the halting and
aborting of actions as simple as possible.
Using a fully event driven system has some very interesting impacts on
gameplay (I've forgotten quite a bit about my system, now, since I don't
currently have my notes on me - if I find anything major which I missed,
I'll append it in another post).
For instance, if Bubba has a speed of 8, and Babs a speed of 9, and Babs
is chasing bubba, their 'move' commands would execute at different time
intervals - Babs would slowly catch up to, and then overtake poor Bubba.
Combined with a suitable (internally) complex skill system, this could be
very interesting indeed.
-- Matt Chatterley
".. You live for the fight, when its all that you've got .."
Jon Bon Jovi; Livin' on a Prayer, as always.
_______________________________________________
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