Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > MUD Coding
Click here to Register

Reply
 
Thread Tools
Old 06-14-2010, 02:56 PM   #1
Graham
New Member
 
Join Date: Apr 2009
Posts: 9
Graham is on a distinguished road
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.

Code:
public class ChatEvent extends Event<MudCharacter> {
        
    private final String message;
    
    public ChatEvent(MudCharacter who, String message) {
        super(who);
        this.message = message;
    }
    
    @Override
    public String toMessage() {
        return getSubject().getName() + ": " + message;
    }
    
    public String getMessage() {
        return message;
    }
    
}
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.

Code:
public final class SayCommand extends Command {
    
    public SayCommand() {
        super("say", "s");
    }
    
    @Override
    public void execute(Player player, String alias, String[] parameters) {
        String message = StringUtils.join(parameters, " ");
        
        Event<?> e = new ChatEvent(player, message);
        e.publish();
    }
    
}
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:

Code:
    @Override
    public void handleEvent(Event<?> event) {
        super.handleEvent(event);
        if (session != null) {
            session.send(event.toMessage());
        }
    }
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?
Graham is offline   Reply With Quote
Old 06-14-2010, 11:47 PM   #2
ArchPrime
Member
 
Join Date: Aug 2008
Home MUD: Archons of Avenshar
Posts: 72
ArchPrime is on a distinguished road
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!
ArchPrime is offline   Reply With Quote
Old 06-15-2010, 01:10 AM   #3
Ide
Senior Member
 
Join Date: Feb 2006
Location: Seattle
Posts: 361
Ide will become famous soon enoughIde will become famous soon enough
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.
Ide is offline   Reply With Quote
Old 06-19-2010, 04:05 AM   #4
Graham
New Member
 
Join Date: Apr 2009
Posts: 9
Graham is on a distinguished road
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 .
Graham is offline   Reply With Quote
Reply


Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 03:51 AM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2014