Page 1 of 2
New class Director/Scenario concept

Posted:
02 May 2012, 09:54
by paul424
Hi , recently I thought about introducing the Director / Scenario model , which would make the whole game more abstract and split into smaller classes large code chunks like ODFrameListener , ODApplication and Gamemap particulary . Each working App would have excatly one Director like on the movie plan , which directs other process , each single playable unit would be called Scenario - having a Goal, Map , List of resources ...maybe additonal rules etc . Director is abstract that one can rewrite the ConcreteDirector as werid as he wants

. Also if we would get univ interface for Resources than we could , reflect what we have already and then load and unload what we need . Here's just the first iteration done with Umbrello UML , I will try other UML modeler in next iteration . Any remarks welcome.
[img]http://forum.freegamedev.net/download/file.php?mode=view&id=2966&sid=b4943180169d17d30fc1841477ad3e67][/img] .XMI format :
http://www.2shared.com/file/xocDX6kS/Director_proposal11.html
Re: New class Director/Scenario concept

Posted:
02 May 2012, 13:02
by paul424
Uhh another iteraction , Suppose we have general wrapper abstract class to handle all the resources :
Also I have some concept for App Modes , they should manage the input events like Modes in VIM or other game console

:
Here's source xmi';s :
http://www.2shared.com/file/69B4JSHi/Director_proposal11.htmlhttp://www.2shared.com/file/8FemRQMQ/Modes_proposal1.html
Re: New class Director/Scenario concept

Posted:
03 May 2012, 11:19
by oln
Seems like mostly what we discussed, I still don't think the modes should be singletons though.
I will make a proper comment once I have a desk again.
Re: New class Director/Scenario concept

Posted:
26 May 2012, 21:53
by paul424
Others on this forum , please make a comment , or propose changes, on less important thread OLV* you were quite active.
*One Letter Variable
Re: New class Director/Scenario concept

Posted:
26 May 2012, 22:11
by paul424
I should draw the UML diagram for an Event System.
There should be some general EventQueue owned ( and created) by the Director.
Those are issues :
Who creates the events ?
Who processes events ?
Does events have any time stamp ?
How do we allow on composition of events ? ( suppose we want to hard to think about something .......... There would be a creature "Vampire" that for each kill it would receive +HP, but say for 4 kills in a short time it would get full regeneration )
Who defines the actions for events ( should they go scriptable with angelscript ? ) like :
Events.angelscript :
Event1 -> function1(Event1)
Event2 ->function2(Event2)
etc/
cheers/
Re: New class Director/Scenario concept

Posted:
27 May 2012, 09:58
by oln
My idea was to try to use the observer pattern. E.g each GameEntity will inherit from an "Observable" class, while each object that want's to process an event will inherit from an observer/listener class, and subscribe to an "observable" object. An observable class will contain a list of classes that observe it. Whenever something happens to the entity, it will send a notification to all it's listeners.
With regards to map scripting, the map file would contain script that can set up trigger points, which would make the application set up listener objects that will react whenever these triggers, which are mapped to events, fire. These listener objects will run an angelscript function specified in the map file/map data when the trigger fires. The same could be used for scripting creature behaviour.
This could also be used for sending data in multiplayer, but there might be other methods that will be less bandwidth-intensive.
Could look at this as an example (from Rigs of Rods, that is also using angelscript):
http://www.rigsofrods.com/wiki/pages/In ... _ScriptingTimeStamps - there should probably be timestamps. For the vampire example, this would be needed if this functionality is implemented using the events.
I am a bit unsure about how detailed events should be, there could end up being a lot of events being fired, however, most of the event processing won't be very complex.
Re: New class Director/Scenario concept

Posted:
27 May 2012, 18:55
by paul424
Back to the Vampire creature, I was thinking whether Attack interaction between creatures should become Event driven.
If that's going to happen than all Creature would become Observable as well as Observer to any other creature , cause every Creature can be subject both of being able to attack and being attacked.
That would in most cases end up producing ||Creatures|| number events spawn every time, when one creature attacks another one.
But there would be required only one event send and received ( from attacking to attackable).
Other examples are easily thought of , such bare mechanism is too awkward.
Re: New class Director/Scenario concept

Posted:
27 May 2012, 21:40
by MCMic
That seems overkill.
A creature that attacks another can easily modify its attributes as it's the same class.
I don't think attack should be done by event.
Re: New class Director/Scenario concept

Posted:
27 May 2012, 21:52
by paul424
How do you model that would support attacks by Fire, Ice, Eletricity, Acid etc.
Towards small, large , of a diffrent aligment creatures , plus resistence by experience, by aligment , by spells , by creature position ( fields etc. ) etc . ?
Afaik there is unit in Starcraft II which is damage only when attacked by small gun callibre, that is , its not touched by any received damage above certain quantity.
Re: New class Director/Scenario concept

Posted:
28 May 2012, 13:05
by paul424
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 ?
Re: New class Director/Scenario concept

Posted:
29 May 2012, 15:20
by paul424
Here's example code of mentioned proposal :
- {l Code}: {l Select All Code}
#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);
}
};
Re: New class Director/Scenario concept

Posted:
29 May 2012, 16:54
by oln
I think subscribing to objects, rather than event types makes more sense in this setting. It depends on the ratio between functionality that relies on doing something with all events of one type, versus functionality that relies on listenint to one specific object, and I think there will be more of the latter. Maybe a hybrid system would make sens for some event types as well.
Also, I don't see why we would need to use function pointers instead of inheritance.
Re: New class Director/Scenario concept

Posted:
29 May 2012, 17:12
by MCMic
paul424 {l Wrote}:How do you model that would support attacks by Fire, Ice, Eletricity, Acid etc.
Towards small, large , of a diffrent aligment creatures , plus resistence by experience, by aligment , by spells , by creature position ( fields etc. ) etc . ?
Afaik there is unit in Starcraft II which is damage only when attacked by small gun callibre, that is , its not touched by any received damage above certain quantity.
a takeDamage function is enough for resistance and that kind of things.
Fire, Ice, etc… could be parameters.
If you prefer, you can use an event class that stores the information, but the attacker should directly send the event to the attacked creature. (Or in somecase the projectile would call the function)
Re: New class Director/Scenario concept

Posted:
29 May 2012, 17:52
by paul424
"Also, I don't see why we would need to use function pointers instead of inheritance."
Yeah it depends whether the subscribing is going to be static or dynamic for the object's life.
That all is a small problem. Worse is the production of events in excecution path would be hardcoded, that is Ep would always produce the same bunch of Events, disregarding to the context ( eg. if they are ever needed ) .
- {l Code}: {l Select All Code}
using namespace std;
void print(int ind, complex<double> x)
{ cout << "x" << ind << " = ";
notify(EventCout());
if (abs(x.imag()) < 1E-6){
cout << x.real() << endl;
notify(EventCout());}
else {cout << x << endl; notify(EventCout());}
}
int main()
{ complex<double> A, B, C, D;
cout << "A = ";
notify(EventCout());
cin >> A;
notify(EventCin());
if (abs(A)<1E-3)
{ cout << "Not a quadratic equation" << endl;
notify(EventCout());
return 1;
}
cout << "B = ";
notify(EventCout());
cin >> B;
notify(EventCout());
cout << "C = ";
notify(EventCout());
cin >> C;
notify(EventCin());
A *= 2;
D = B*B-A*C*2.0;
if (abs(D)<1E-3){
cout << "x = " << (-B/A).real();
notify(EventCout());
}
else
{ print(1, (-B+sqrt(D))/A);
notify(EventPrint());
print(2, (-B-sqrt(D))/A);
notify(EventPrint());
}
return 0;
}
Supoose in some cases due to Performace constraints we want to call notify about EventPrint or EventCout or only about EventCin.
How do we ensure such type of polymorphism ?
Re: New class Director/Scenario concept

Posted:
29 May 2012, 18:54
by oln
paul424 {l Wrote}:"Also, I don't see why we would need to use function pointers instead of inheritance."
Yeah it depends whether the subscribing is going to be static or dynamic for the object's life.
I don't see how that makes a difference.
Objects will simply only create events if there are anything subscribed to them, I don't see how function pointers will make any difference for this point either.
Re: New class Director/Scenario concept

Posted:
29 May 2012, 19:25
by paul424
Hehe looks like we are starting to misunderstood each other due to overuse the word "subscribe/subscriber/subscribing ."
By object's subscribing I mean that it 's pointer was put into static std::vector<Event*> eventQueue ( according to my example).
in my example you could do :
EventTypeSubscriber mysub = new EventTypeSubscriber( fp ); // where is of a type int (*fp) (eventType* ee)
and then change it during execution to
mysub.newEventAttack = fp1 , fp2 .... // etc.
That might be useful

.
Re: New class Director/Scenario concept

Posted:
29 May 2012, 19:54
by oln
You could also just use a if/switch statement in the function receiving the event.
Could you explain why you think subscribing to event type rather than objects is better in this situation
Re: New class Director/Scenario concept

Posted:
29 May 2012, 21:10
by paul424
Yes , suppose the Creature just going to hit jackpot in cassino.
To our caprice it may or might not sign , dance, change color, drunk to lost of conscious etc.
What is better all those re-actions ( functions) might be already assigned to diffrent events.
Re: New class Director/Scenario concept

Posted:
29 May 2012, 21:29
by paul424
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.
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.
Note: 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 .
Note: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.
SmartNote : 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 /* .
Re: New class Director/Scenario concept

Posted:
30 May 2012, 12:38
by oberhamsi
Regarding the first post about Directory/Scenarios.
I do this in any game that gets a bit bigger:
At game start, one director is initialized. The director initializes the display and catches all input (mouse/keyboard), and loads global resources.
The director has a stack of scenes and he sends all input to the top scene, hands it the display to draw on, etc.
A scene is always "activated" by another scene - e.g.: player presses ESC during GamePlayScene so the MenuScene should display - by being pushed on the stack.
I described a simple version of this pattern here:
http://gamejs.org/director-scenehth
Re: New class Director/Scenario concept

Posted:
30 May 2012, 14:13
by paul424
Huh it must be some kind of time loop, I don't see any other explanation of OD's development stall.
Here are some useful discussion on using Event system for gamedevelopment.
I will do a post proposed event system in here, cause what I can do else ?
http://gamedev.stackexchange.com/questi ... ged/events
Re: New class Director/Scenario concept

Posted:
12 Jun 2012, 11:01
by paul424
Re: New class Director/Scenario concept

Posted:
12 Jun 2012, 11:32
by oln
Check your reply there, and try to not make a fool of us.
I would write more about my thoughts on the game structure, but I have a limited capacity right now. So try to be a bit patient.
Re: New class Director/Scenario concept

Posted:
17 Jun 2012, 10:33
by paul424
Re: New class Director/Scenario concept

Posted:
17 Jun 2012, 11:40
by oln
I still think this event system is overly complicated.