[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