I am working on opensource GPL3 game.
http://opendungeons.sourceforge.net/ , new coders would be welcome.
Now there's design question regarding Event System:
We want
to improve the game logic, that is program a new event system. I will just repost what's settled up already on http://forum.freegamedev.net/viewtopic.php?f=45&t=3033.
From the discussion came the idea of the Publisher / Subscriber pattern + "domains":
My current idea is
to use the subscirbers / publishers model.
Its similar
to Observable pattern, but instead
one subscribes
to Events types, not Object's Events.
For each Event would like
to have both static and dynamic type.
Static that is its's type would be resolved by belonging
to the proper inherited class from Event.
That is from Event we would have EventTile, EventCreature, EvenMapLoader, EventGameMap etc.
From that there are of course subtypes like EventCreature would be EventKobold, EventKnight, EventTentacle etc.
The listeners would collect the event from publishers, and send them subcribers , each of them would be a global singleton.
The Listeners type hierachy would exactly mirror the type hierarchy of Events.
In each constructor of Event type, the created instance would notify the proper listeners. That is when calling EventKnight the proper ctor would notify the Listeners : EventListener, CreatureLisener and KnightListener.
The default action for an listner would be
to notify all subscribers, but there would be some exceptions , like EventAttack would notify AttackListener which would dispatch event by the dynamic part ( that is the Creature pointer or hash).
Any comments ?
#include <vector>
class Subscriber;
class SubscriberAttack;
class Event{
private:
int foo;
int bar;
protected:
// static std::vector<Publisher*> publishersList;
static std::vector<Subscriber*> subscribersList;
static std::vector<Event*> eventQueue;
public:
Event(){
eventQueue.push_back(this);
}
static int subscribe(Subscriber* ss);
static int unsubscribe(Subscriber* ss);
//static int reg_publisher(Publisher* pp);
//static int unreg_publisher(Publisher* pp);
};
// class Publisher{
// };
class Subscriber{
public:
int (*newEvent) (Event* ee);
Subscriber( ){
Event::subscribe(this);
}
Subscriber( int (*fp) (Event* ee) ):newEvent(fp){
Subscriber();
}
~Subscriber(){
Event::unsubscribe(this);
}
};
class EventAttack: Event{
private:
int foo;
int bar;
protected:
// static std::vector<Publisher*> publishersList;
static std::vector<SubscriberAttack*> subscribersList;
static std::vector<EventAttack*> eventQueue;
public:
EventAttack(){
eventQueue.push_back(this);
}
static int subscribe(SubscriberAttack* ss);
static int unsubscribe(SubscriberAttack* ss);
//static int reg_publisher(Publisher* pp);
//static int unreg_publisher(Publisher* pp);
};
class AttackSubscriber :Subscriber{
public:
int (*newEvent) (EventAttack* ee);
AttackSubscriber( ){
EventAttack::subscribe(this);
}
AttackSubscriber( int (*fp) (EventAttack* ee) ):newEventAttack(fp){
AttackSubscriber();
}
~AttackSubscriber(){
EventAttack::unsubscribe(this);
}
};
From that point, others wanted the Subject-Observer pattern, that is
one would subscribe
to all event types produced by particular object. That way it came out
to add the domain system :
Huh,
to meet the ability
to listen
to particular game's object events, I though of introducing entity domains .
Domains are trees, which nodes are labeled by unique names for each level. ( like the www addresses ).
Each Entity wanting
to participate in our event system ( that is be able
to publish / produce events ) should at least now its domain name.
That would end up in Player1/Room/Treasury/#24 or Player1/Creature/Kobold/#3 producing events.
The subscriber picks some part of a tree. For example by specifiing subtree with the root in
one of the nodes like Player1/Room/* ,would subscribe us
to all Players1's room's event,
and Player1/Creature/Kobold/#3 would subscribe
to Players' third kobold's event.
Does such event system make sense
to you ?
I have many implementation details
to ask as well, but first let's start some general discussion.
Note1: Notice that in the case of a fight between two creatues fight , the creature being attacked would have
to throw an event, becuase it is HE/SHE/IT who have its domain address.
So that would be BeingAttackedEvent() etc.
I will edit that post if some other reflections on this would come out.
Note2: the existing class hierarchy might be used
to get the domains addresses being build in constructor . In a ctor you would just add + ."className"
to domain address.
If you are in a class'es hierarchy leaf constructor
one might use nextID , hash or any other charactteristic, just
to make the addresses distinguishable .
Note3:subscribing
to all entity's Events would require knowledge of all possible events produced by this entity . This could be done in
one function call, but information on E produced would have
to be handled for every Entity.
SmartNote4 : Finding proper subscribers in a tree would be easy.
One would start in particular Leaf for example Player1/Creature/Kobold/#3 and go up
one parent a time , notifiying each Subscriber in a Node ie. : Player1/Creature/Kobold/* , Player1/Creature/* , Player1/* etc, , up
to a root that is /* .<<<<
Note5: The Event system was needed
to have some way of incorporating Angelscript code into application. So the Event dispatcher was
to be a gate
to A-script functions. But it came out
to this
one.
