Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[prock]

Many of you heard me ranting about this last week.  I'm thinking about starting on a trigger system and am putting some thought into it's design.  First I'd like to get some input from you guys.  In order to design a trigger system we have to agree on the definition of a trigger.  What comes to mind for me is something like this:   A trigger is something that waits for a particular event or set of conditions to be met and reports it to the system.  By "reports it to the system" I'm referring to the active listeners that are listening for the trigger to report (yes we should probably conform to our current observer pattern standards).

This of course is a pretty broad definition of a trigger compared to what I was thinking before.  Initially I was thinking a trigger could only listen for particular instance/cell interactions, like when an instance enters/exits a cell.  Now I think by keeping a broader definition of a trigger in mind it might keep the design a bit more flexible.

Here are some ideas I have for requirements of the trigger system:

• Conform to the observer pattern
• Allow client definable triggers/trigger types
• System can be disabled (save on a bit of overhead if they are not required)
• Trigger type that reacts to a instance+cell interaction messages
• A single trigger can watch an arbitrary set of cells
• A single trigger can watch an area of cells
• Cell interaction triggers can move (perhaps be attached to an instance/object and move along with it)
• Trigger type that reacts to an instance being changed (moved, removed from layer, etc etc)

Thats all I have for now.  Thoughts?

[vdaras]

My two cents is that the observer pattern in this situation would be a little bit cumbersome. As a client, especially if I used fife through python, I would like a function callback mechanism instead. We can also support this in C++ clients as well, since most major compilers now support lambda expressions. If C++11x usage is any issue, we could use one of these http://stackoverflow.com/questions/1526912/fast-c-delegates.

[prock]

hmm yeah I thought of that, however I dismissed the idea because we don't make use of them elsewhere.  I wanted to try and remain somewhat consistent with what we do in other areas of the engine.  The model I'm looking at might quickly become unmanageable with all the listeners it'll have to manage.  I'll have to do some experimenting perhaps.

[prock]

I created a new branch called triggers to start work.  I haven't completely solved all my issues yet but I'm going to start experimenting with them in that branch.  Currently I have a few questions that need answering:

• Are triggers unique?  per game? per map? per layer?
• How should triggers be identified?  by name?  by id?
• Should triggers be controlled by the object itself?  e.g.  layer->addTrigger(trigger, rect).  Or should the trigger be managed by a controller of some sort?  e.g. map->getTriggerManager()->addTrigger(trigger, layer, rect)
• How do triggers get represented in the map file?

I'm sure a few more questions will pop up as I work on it.