FreeGameDev

I rethinked the previous event proposition.
Now we don't need domains as much , but something to quantify over the Event types.
What I think each Event might be the sum of smaller atomicEvents, each of it holding specific information to its type.
We would use the boolean flags of int_32 or int_64 to mark the Event type, each respectful boolean index representing a type.
like const int SpecialEvent = 0 , const int AttackEvent = 1, const int DefenseEvent = 2 .... 4, 8, ... etc.

We could introduce the operator< on Events such that EventType t1 < EventType t2 iff ( int t1 & int t2) == int t1 ( t1 contains at least all flags from t2).


Now we have subscribers which subscribe to Events types, and each subsribed Entity would be stored as pair in mutlitset<parir<EventType, Entity > .

Also we add queque's or other sequantial container's to collect atomic Events.
There is also a special queue EventTypes queue, which does stores only EventTypes as their come into , call it EventTypeQueue.

Each frame or queue we do like :

1. Trigger part : each producing Event's Entity produces EventType and puts it into EventTypeQueue.
(Note: we must test before whether there are any subscribers for that EventType)
It produces respectful atomicEvents by splitting Event into proper atomicEventsQueues.

2. Dispatch Part: for every EventType in EventTypeQueue :
Find all subscribed Entities to EventType construct Event ee from respectful atomicEventsQueues and puts them to subscribers.
(Note the subscribers are easily find by

{l Code}: {l Select All Code}


operator<=( const int &k, const int&l ){return (k&l) == k; }) and operator<( const int &k, const int&l ){ return  k!=l && k<=l})

STL set and multiset can quickly retrive desired objects by using lower_bound/upper_bound
http://www.cplusplus.com/reference/stl/set/


I think that's quite good way of having diffrent types of Events with the way of quantifiing them .

Do we need to quantify events? I still think we could get away with something much simpler.

Also, I think it's important we make the event pushing/subscription etc. API transparent to the entities, so that whatever the underlying system is, the entities should only have to call a function, and now worry about how the entity handling is implemented.

After having read through this thread and the earlier about an Event System, I think you should read one of my previous suggestion for multi-threading the game. Which touches on similarly issues that will have to be handled for the Event System. My previous suggestion is found here.

My remarks for the Event System. It seems you want the Event System to handle all game logic (or at least processing of AS scripted game logic) along with moving game objects around on the map and stuff like that, so the Event System should be very general, simple and non-specific to any particular game objects. As I see it events should be able to spawn new events, e.g. say we will do the turn for a canon, if it sees a target and shoots at it, a canon-ball is spawned and this will be handled in a new event. Events might also need to depend on other events, e.g. a trap depends on the creatures on its tile, hence it needs access to the events for the creatures on its tiles. Also events will have to be processed eventually, hence deadlines, timestamps and priorities come to mind. Also should Events be distinguished according to their location on the game map? E.g. when a creature moves, it might move onto or away from a trap, hence the trap either needs to be informed about this, or needs to check it self if some creature is now within its weapon range or not, and we of course need to determine this as effective as possible. Also will the Event System handle rendering tasks also? E.g. the coordinates of meshes, velocity and move direction etc.? In that case we cannot use the "turns of the game" to make up deadlines, so we need an actual timer mechanism.

My multi-threading proposal from way back, only deals with game logic computation for each game object, e.g changing the game state. If it also needs to handle other aspects like, rendering etc. it needs modification as it is inherently based on the "turns of the game".

What I have found so far is that we need separate address/dispatch information from the rest of the information in the Event. That comes both the domains and quantifier flags ideas.
If we want to make some general dispatching mechanism we would like to dispatch Events from some pool . Only the fraction of info from each event is relevant to the Dispatcher, like for the trap it's only relevant the new position of Entity and whether it was a Creature, we don't mind Creature type, player owner etc.

From the dispatcher information I see diffrent kinds of it , like :
**Determiners : 1. Static Determiners which match always exactly one Entitiy --- Entitiy ID, Entity pointer , Spawned Creature Number of Player_X etc. Static in a sense the determiner is known since the Entity creation.
2. . Dynamic Determiners which match at last one Entity -- Entity closest to some point( might be qualified by some type like Minion, WoodObject etc., Entity of Player1), Entitiy having max or min property from some set, Entity which last entered some area (e.g Tiles). By Dynamic info I mean we need to get some information from the recent gameplay.

**Quantifiers : Might match any number of Entities again they could be static or dynamic:
1. Static Quantifiers -- by Entitty type ( Creature race etc. )
1. Dynamic Quantifiers - Entities in some Area( in some room, from distance < than R from point etc.), having some property ( from speed from X to Y, Level from W to Z ), having done some Action from last X turns ( or from to ... ? ) . As with Dynamic Determiners we need to "look up " the gameplay history to dispatch the Events.

The natural way would be to composite the quantifiers , with the static info taking precedence when dispatching .


Other question os whether Static Quantifiers should be put into some kind of tree hierarchy E,g, We know that MagicCreature could further be Wizard , Mage, Pixie, but not Knight.


I wanted to pack all the Dispatching information into one machine word, that the dispatching would be quick ( the previous post) .

The real pro blem is how to make diffrent Entities react diffrently to the same Event regarding the game context. The Attack Event is going to hurt usually one creature, but notify the other standing nearby. We might programm the attackCreature method to spawn two events one special and one general.

Second thought is to make each Event when triggered of the form <Subject> <Action><Object>. Like Creature1 Attactks Creature2, Creature1 Entered Sector1 and from that extract what I call dispatcher info.

If the dispatching by Entity position is going to be the most used one, to make dispatching quicker we could keep diffrent spatial trees for diffrent Entities types. As you noticed I implemented Quadtrees for future graphical culling ( files Quadtree.h and Quadtree.cpp) . Note those are not the most optimal http://en.wikipedia.org/wiki/Spatial_index#Spatial_index, e.g. k-d trees are better balanced. Or we could have diffrent subtrees for diffrent Entitiy types. OR we can put one TypeNode and than SpatialNode on the path from root to learf and so forth . Donno if at this point anyone still understands me .

I think we have different ideas of what the event system should do. From what I understand, paul424's proposal is to have most of the game logic happen through events (so basically a form of message passing. I have to admit that I haven't quite grasped the explanation in the first post yet.). For that scenario, a pretty advanced event system makes sense. This means that we are really discussing the threading model here.

Right now the threading model is mostly: "On each turn, spawn x threads which run the mega-function creature::doTurn in parallel (which basically does all the creature AI)." This function does ai calculation, digging of tiles, attacking, resolving damaga, etc. This means having to put locks on everything, as we have several threads potentially interacting with the same objects, which is not ideal.
(Also, the networking is using threads, but that is a separate topic.)
There are several approaches we could use to solve this. Using message passing as proposed by paul424 is one option, svenskmands "producer-consumer model" is another. Both of these would mean a pretty large change in the code-base.

I think most of the CPU time for the AI is spent on visibility calculation and pathfinding. Neither of these need to alter anything but the the result of these calculations are private to the creature object, so each calculation can be done in parallel. This shouldn't require as much work time.

Anyhow, I don't think we should focus on doing these huge changes quite yet. I think we should start by making a very basic event system, for use with map scripting. The original dungeon keeper had very basic scripting capabilities, the only mechanisms that could trigger a part of the map script was when a creature stepped on a set tile, or a timer. http://keeper.lubie.org/dk1_docs/dk_scripting_ref.htm#scrpt_cmd_set_timer, and it was still very playable (also the levels without an AI-controlled enemy keeper). So I think we should start with something really basic like that. That is, make functionality to set trigger points on tiles, or potentially a trigger when a specific creature dies or similar, and have the game call a script function specified in the map file(s) when this happens. I think we should keep the game logic in the code for now, later we can consider making more behaviour be overridden by scripts. I think we should focus on this, and getting a working editor gui first; working towards modularity, high cohesion and loose coupling. We d

We can of course have a discussion on thread models as well, but I think that it should not be the main focus right now.

OpenTTD (another project, one which has the ability to eat any CPU for breakfast, if started with the right map) could benefit from multiple threads. However, early on in development a decision was made for a single thread (multiple cores wasn't a topic at the time).

Once in a while somebody posts asking for multi-core support and the reply mostly comes down to that due to early design decisions, multi-core support would be a too large project and take too long.

Somebody did try, and the result was too unstable. The project was abandoned as a consequence.

Yes, openttd does use a separate thread for saving and (iirc) music. Minor things, not in the core logic.

Bottom line: it's safest to start with multi-threading early on, or not at all. It is very difficult to implement it later on as the entire engine needs to be modified and things need to be coded in such a way to prevent conflicts and inconsistency.

Sorry for the OT comment, but I thought it would be good to post it in this thread.

Also, an event system needn't be very complicated. It could be as simple as a function to send and a function to receive in each game entity.

To make things more thread safe, a global event cache could be handled whose sole purpose it is to pass events around.

To make things a bit more complicated each event could get a callback (to handle bizarre exceptions).

Bottom line: keep it simple and make the event system optional for use. However, if 10.000 creatures are going to do things at the same time, you'd better have something in place to prevent conflicts.

I think xahoo is right, the earlier we get a good thread model the better. As Oln says it will already require allot of time to make the switch now, and it will only be worse later on. So I say we focus on getting a stable and rock solid thread model. While we figure out how the design should be, and nail it in stone, we can make a simple map so people can play the game. But I think a good thread model should be the focus.

Regarding the event system, I have a very difficult time imagine a system that is thread safe while being fully parallel. The problem is that the dependency graph of the events is cyclic, hence we a bound to get eithe deadlocks or a very sequential execution. My proposal is maximally parallel, but it is not a full-fledged event system, but I am not sure we need that.

So I suggest that we start by determining exactly what kind of tasks we want the system to handle. And then we design a fully parallel thread model around it. For that task I suggest that we take a close look at Googles new programing language called Go.

svenskmand {l Wrote}:I think xahoo is right, the earlier we get a good thread model the better. As Oln says it will already require allot of time to make the switch now, and it will only be worse later on. So I say we focus on getting a stable and rock solid thread model. While we figure out how the design should be, and nail it in stone, we can make a simple map so people can play the game. But I think a good thread model should be the focus.

I agree with this. We should first get the really basic events/callbacks, and the editor GUI down, so that people can try to create content. Neither of these should take a huge amount of work, and they won't really derail the progress towards a new threading model. I believe paul424 has been working on cleaning up the game loading a bit, so the editor gui should be simple to implement.

Another idea is to consider is using the Test-driven development model to potentially improve the code quality for new code. It seems to be the buzz now for Object-oriented programming.

I wanted to have skinned radio buttons for Editor mode toolbox, but I know CEGUI to poor to embend the proper images. Maybe I would bitch that out on #CEGUI

Idea is to have hierarchy of Entities, forming a Tree. Abstract Classes with abstract actions in internal nodes and concrerte classes in leafs.
One could throw an event denoting action only from concrete interface ( concrete class and actions ) , in this example "creep" , but one could write listeners for any action inside class concrete or abstract.


Example:


class Root{
do
}
class GameEntity:Root{
do:onCreate
do:onDestroy
do:onMeshUpdate
do:onGeometricTransformation
}

class MovableGameEntity:GameEntity{
do:onGeometricTransformation:onMove
}
class Creature:MovableGameEntity{
//some other stuff
}

class Tentacle:Creature{
do:onGeometricTransformation:onMove:creep
}

Huh there's my new questions regarding Events:

http://gamedev.stackexchange.com/questi ... -of-c-sour

feel free to discuss that ... here or there .