Event-based MUD server concept
 

Hi everyone. I've been planning out a concept for dealing with the vast majority of actions that will take place in the MUD server I'm writing and I'm interested in any feedback/suggestions people have, or if anybody has done something similar before in a MUD server.

Essentially, every object in the game can create events. When an event is published, it is sent to the subscribers of the object. The subscribers can then react accordingly.

For example, when a player object receives an event from one of its subscriptions, it will format it into a text message and send it to the client at the other end of the socket. Almost everything that happens in game will be an event, here is a little example from my 'proof of concept' implementation.

The following code snippet is the actual event class itself. Every event is derived from Event<T> where T is the type of subject (the subject is the object that creates the event). The use of generics is just to reduce casting everywhere.

As you can see there are two ways to get data out of the event: toMessage() which formats it for players. As well as that, events will also have get...() methods which could be used for NPCs or other objects which are capable of reacting to events.

This is the command which actually publishes chat commands. It's quite simple: it just creates a single string from the command parameters, creates a ChatEvent with the player that issued the command as the subject and publishes it.

The subscribers of a player object are the other objects in the room. So, if there is another player in the room, this method is called when the event is published:

Which will ultimately send the formatted message to the player (if they are online).

The possibilities are almost endless. You could create fairly complex behaviours for special objects/NPCs and not have to write code elsewhere.

For example, imagine that the players are sneaking around in a dark tunnel and nobody can see much (include some NPCs). If a hostile NPC which had poor vision received a ChatEvent, it could then sense that somebody is there and attack them. The corresponding AttackEvent would be received by other NPCs e.g. mice which might run away to other, adjancent rooms, scared due to the violence that is going on. All of this could be done without ever adding anything to the chatting code or attacking code itself.

Back onto the more technical aspect, has anyone got any feedback/ideas or can see any glaring problems with the concept?

Re: Event-based MUD server concept
 

The idea is sound. I've opted for a similar system and find it works very well since the "objects" in any given environment space aren't directly affected by other "objects" except through messaging. It provides for a nice decoupling, so to say. Publisher/Subscriber -- Broadcaster/Listener messaging systems are common patterns used daily by software developers. As a general concept, it's a proven one.

I prefer a "broadcast" type system, where objects broadcast action messages into an environment and objects filter out those they are interested in. My preference is based on the assumption that objects move from location to location and would need to unsubscribe/resubscribe to publishing objects(other objects in the current/next environment space) upon every room change. I didn't want that perceived overhead --- or management duty.

Cheers!

Re: Event-based MUD server concept
 

ArchPrime brings up an important concern, which is scope. Some objects will want to react to local scopes (say, a door). Some might want to react to regional scopes (the city guard maybe), and other things might want global scopes (magical currents, weather patterns, etcetera).

The other important thing to suss out with event publishing/broadcasting is precedence. Who acts first? Which objects have precedence to handle events? Can they change data embedded in the event before another object catches the event?

I think if you can work out rules for scope and precedence, this system can work very well.

Re: Event-based MUD server concept
 

Yeah adding/removing subscribers when you move through rooms could be quite unreliable although the way it works atm it could be used for more than just broadcasting messages through rooms (since every object in the game derives from the MudObject class).

As for precedence, I personally think it is easier not to worry about it and ensure code gets written that doesn't rely on the order... same with modifying events, if the mud object wants to do something else it could always fire off a new event (although that also means being careful for some sort of infinite loops with two events firing each other when handled by an object).

Thanks for your input :).