borring some examples from java this problem is easy to solve.

Using the MVC ideals... Things you would like to track would fire events ( small peices of data ). Anything that would like to know about it registers with the firing object and will automaticly recieve it when it happens. So examples...

Calander time could fire a new day event everytime it''s counters registered a new day all triggers that are partialy based on time would register to recieve those events. Or... you could register date/time values with the calendar object and get an event notification only when that time is passed ( much more efficient ).

Location ( entering bar ). The rendering engine could either a) allow events to be bound to specific locations so when he steps on a particualr tile ( the first on in the bar ). It fires an event or b) fires an event when a particuar scene is loaded.

Other events. This should be self explanitory triggers themselves could easly fire events when they occur.

This is better than polling because triggers would be woken up as each event happens and cal lay dorment without eating CPU time. It''s better than if/else/if because only those parts of the code that need the information will ever get it. Think of it like a graph, all points are triggers and all lines represent registration for events. And event will start at one node and travel all nodes registered (lines) at which point each recieving node will process the information and POSSIBLY fire their own events.

Events could be anything you want them to be. In a program I wrote recently everytime a variable changed it fired a property change event and any other object that wanted to know about it would know as it happened.

I hope that made some sense.

You would think that time would be the constant in all this dynamicness, that it would keep ticking at regular intervals to dirive the game. But, wouldn''t it be interesting to make time dynamic as well? You could slow it down at times and speed it up at others. Maybe you could even make it go backwards sometimes. This could get very interesting. Good for making really crazy games.

You could either assosciate this velocity of time change with the plot ("An evil wizard is messing with time flow!!") or it could be for certain effects, like slowing down for a battle or speeding up while you sleep.

Just a thought.

"When i was a child I caught a fleeting glimpse, out of
the corner of my mind. I turned to look, but it was
gone, I cannot put my finger on it now. The child has
grown, the dream has gone." -Pink Floyd

I am not so sure about the timeflow thing, as I am a little too tired to think straight, but anyway here is the trigger mechanism.

Say that we have a 2D Isometric game (for example... And it is set in fantasy time ). On a single tile you have a Trigger pointer that references an EVENT. This can be NULL if there is no Event to trigger. Basically, if it is not null, then when the player crosses this tile, the triggered EVENT will be checked and the whole event tree will be parsed.

Seeing as the EVENT that is being triggered can appear at any point through the whole of the EVENT tree, there needs to be a mechanism for going to the Starting values. This means that it is a double linked list in the fact that your Events need to reference their parent events. I can''t see of any other way of doing it other than this. Basically you check for consistency as you work back through the tree until you determine if the event will be triggered .

More later .

-Chris Bennett of Dwarfsoft - Site:"The Philosophers'' Stone of Programming Alchemy" - IOL
The future of RPGs - Thanks to all the goblins over in our little Game Design Corner niche
          

The way I see it you have objects ( or the c equivelient ). Each tile is firing all sorts of events ( selected, walked on, ... ) but since no one is interested in them they never go anywhere.

You register with the tile to get notification of the evens and your function is put in the list to be called. If you want to time delay, just register for the event and THEN register with the clock/calendar to get the followup event.

Hope that made sense

You''re basically talking about a production system.

EVENT:
conditions
conditions
conditions
--> fires
event +2
event +3
event +1

The above production creates new events which create new conditions which fully develop at timestep +x from now.

So, let''s say now = 8:32 PM.

Let''s say one of the fired events occur at timestep +3 minutes.

So, in 3 minutes, at 8:35 P.M. the conditions created by the fired event become reality.

Every timestep, the condition side of all events are checked with all fully realized existing conditions.

By creating an efficient set of links between existing conditions and conditional checks of potential events, the event check loop shouldn''t take long.

The conditions side of an event may be implicitly connected by AND or explicitly connected by OR.

OK, the events are not necessarily Time Based. They can include a time attribute, but may not.

I am writing up some code at the moment to see how the tree will figure out if an event is triggerd based on the trigger occuring, and the prerequisites being met. It is very messy code at the moment being that the CONDITIONAL, EVENT, and GROUP all have different types and must link to one another and can also link to more than one (like Event3 in the final image of the examples. Check here if you don''t know what I mean). It is working so far, but I need 4 classes to do it, one for each CONDITION, EVENT, and GROUP, and also for the TREE VIEW. Anyway... Enough ranting about ugly code (too many unions for pointers.. Blech! )

Anyway. Once I have that done, I shall see what you think. Damn, just remembered that I have to have another linked list for trigger conditions. D''OH! Anyway... The more code the merrier

-Chris Bennett of Dwarfsoft - Site:"The Philosophers'' Stone of Programming Alchemy" - IOL
The future of RPGs - Thanks to all the goblins over in our little Game Design Corner niche
          

I was thinking that it would be possible to write a tool that could generate the events & triggers then write it to a file that is read into the game. The tool would probably have to be customized to the particular game being made though.

The tool could let you add triggers and events and give them a name and/or ID and cause things to happen because of them. Then you could associate events w/ the name/ID of the trigger then the tool could put everything in a text file in some organized way so that the game could read it in.

You could add the use of or,and,xor etc for the conditionals.

Also, this would allow the potential for the players of the game to create events and plots possibly if the tool is user-friendly enough.

Letting users customize a game can really add popularity to it...games such as Quake and the like are good examples.


"All you touch and all you see is all your life will ever be --Pink Floyd
Quidquid latine dictum sit, altum viditur.
Need help? Well, go FAQ yourself.

Click here to see my current project.


Edited by - Nazrix on November 25, 2000 1:13:25 PM

Ah, like the StarCraft map editor. Only, more advanced.

This is a good idea, I think it would make it easier to design.

"When i was a child I caught a fleeting glimpse, out of
the corner of my mind. I turned to look, but it was
gone, I cannot put my finger on it now. The child has
grown, the dream has gone." -Pink Floyd

We could also add things for the events that could be part of the tool like having the NPCs say something and that could be done through the tool.

It's almost like a scripting language w/out having to do the parsing, and it's all menu-driven.

Then, no matter how many things you changed in the process of using the tool, it's all written to a nice organized text file when you save it.




"All you touch and all you see is all your life will ever be --Pink Floyd
Quidquid latine dictum sit, altum viditur.
Need help? Well, go FAQ yourself.

Click here to see my current project.


Edited by - Nazrix on November 25, 2000 3:28:19 PM

OK Naz, about the XOR, AND, OR, etc CONDITIONAL stuff... You need to see the write up to see that it has already been included that way.

It really is a very diverse system which allows for many things to be modeled with a simple boolean ''triggered'' value. The conditionals make the distinction between what these values mean to a specific event, and the game continues.

I am currently writing up a program/tool that handles this. It is still very much in the beginning LL phase (and I haven''t even made the combining Tree class/structure yet.. Just ''Conditions'', ''Events'' and ''Groups'' ). Anyway, from looking at how I am designing it I am learning a lot as I go...

From the trigger perspective, I have not actually implemented the triggers... The trigger is what I see as being game dependant. The way that the trigger interacts with the game is very much dependant on what the game is and etc. But the trigger can call the event and see if it will be executed and such, and will be able to see the result of the call to execute. From using this as an external library the trigger will determine if the event was successfully called or not, and will modify the game as it sees fit.

The trigger is the abstraction from the game to the tree. The tree itself can be implemented in almost any game that I can think of.

As for the actual tree, I have found some small problems. The tree in the example is converging, but what if you were to place an event trigger on something like ''learn skill 1'' and want the events to branch? Well, this will be implemented in the final tool, and I can see how to do it, but it makes everything a little messy.

Another thing, seeing as the trees do not necessarily have to interrelate with each other, what if seperate trees required events to have different prerequisites? What happens then? Does the event get executed in one tree and not the other (I think not) or does it require a combination of ALL of the prerequisites to be triggered? This is the MAJOR problem that I can see at the moment, and I will be thinking about it as much as possible for a little while... Until I get some more code down, I cant really see a solution.

Anyway - more later

-Chris Bennett of Dwarfsoft - Site:"The Philosophers'' Stone of Programming Alchemy" - IOL
The future of RPGs - Thanks to all the goblins over in our little Game Design Corner niche