liquiddark:
Thanks for the link. The article was not as helpful as I''d hoped, but it was informative. The followup articles spent too much time on his (hypothetical) syntax instead of practical implementation.

liquiddark, RolandofGilead, ddn3, AP:
You present several different methods to attack the problem. The event model, embedding static pointers in the objects (thus creating a node graph), the database model, even custom design for the implementation. This is all good. If anyone else has any other techniques, please contribute.


Each technique seems to focus on single purpose, and can be inefficient for a different one. Triggered events work fine for simple flags, but choke at traversing a node graph. Embedded object pointers work well for traversing a node graph but get tangled with conjunctions. The database model works well for conjunctions, but can get very slow for simple flag checks or node graph traversal.

Since any given Relationship (fact, etc) can be used for several different purposes this creates a problem. Can we develop some robust guidelines for when to use each implementation? Is it better to have a mix, or just focus on one technique?

At some point the game design may change, so the optimum technique may change. Can we write or structure our programs to make it fairly easy to switch from one technique to another? Or is this just a rare occurence?



The second half of the problem, the program flow control, has a similar difficulty. How does the program flow (the functions, procedures, etc) change?

One can perform real time checks (if...then else) in the middle of a function. But this can mean a lot of time spent checking for rare conditions. If the design has a lot of conjunctions (if A and B but not C...else if P and Q...) then this becomes ugly.


Or one can use function pointers and simply follow the current path (doFunction->nextFunction()). This pre-loads the program path whenever an event changes, so no need for the real time checks.

At first glance this doesn''t work well when there is a single decision point with a lot of options because only one of the function pointers will be taken. The indirection can also be slower.

Is there another technique here? And when to use one over another?


JSwing

A visual editor for this kind of thing would do wonders for producing Sensor/Trigger/Effect systems. My system isn''t really event-based, I was just giving that as the example for a communication method between all those concepts. A tree would also kick ass and provide a way to avoid recursion(and it would certainly look like a graph in a visual editor). Speaking of, one could have any method simulated by the editor but it would be really cool to have many techniques available and just pick and choose with the editor which ones to do.

Here''s a random thought, the two examples JSwing gave can also thought to fall into different categories based on the level each operates on. The ogre-room example can be thought more of a method of controlling the engine, while the artifact/graveyard example changes the state of the game.

I think we need more examples and then give ways from various techniques on how to solve them.