So, you all know the story, you are playing a game, in its normal environment, just moving the character, when all of a sudden, something happens thats out of the ordinary. An event! So, say a character pops out, gives some little speech, and never shows up again. Or, your in the middle of the battle, and the opponent's hp goes down to just 1%. Then, he transforms!
So, What I want to know how to do, is how (probably in Axe if possible, but any hard coding will be done be me. eg, explain only please) they do events. The only thing I could come up with was to have an interrupt constantly check an index number, and if that number, along with other criteria matches, then the event happens. The problem is, that I don't know how to do that fast. Eg. Check a lot, while still maintaining criteria. I thought about trying to do a fixed size lookup table, but that would be difficult and allow no modifying.
So, how do the pros do it?
Well, generally you have a main loop that's fairly comprehensive, and jumps or calls particular sub-parts of your programs in a stateful event-handling network, such as moving a character and entering a battle, or triggering an NPC speech during a battle. Having an interrupt would be somewhat overkill in my opinion instead of simply checking criteria for a bunch of interruption conditions to occur within each of the places where that interruption might occur, then calling the routine to display or otherwise handle that interaction from each of those places if the condition is met.
perhaps a random number makes the event happen for that save file, and then a value changes indicating that it wont happen again until you start a new game?
qazz42 wrote:
perhaps a random number makes the event happen for that save file, and then a value changes indicating that it wont happen again until you start a new game?
Definitely, but that's a detail of at-most-once triggering rather than the mechanism of the actual trigger->event handling, in my opinion.
KermMartian wrote:
Well, generally you have a main loop that's fairly comprehensive, and jumps or calls particular sub-parts of your programs in a stateful event-handling network, such as moving a character and entering a battle, or triggering an NPC speech during a battle. Having an interrupt would be somewhat overkill in my opinion instead of simply checking criteria for a bunch of interruption conditions to occur within each of the places where that interruption might occur, then calling the routine to display or otherwise handle that interaction from each of those places if the condition is met.
See, I would do that, and I thought of that, but there is one engine for each thing. For example, one battle engine, one map engine and so forth.
qazz42 wrote:
perhaps a random number makes the event happen for that save file, and then a value changes indicating that it wont happen again until you start a new game?
Thats not the point. The events must happen in order. meh, stop ninja'ing me!
KermMartian wrote:
qazz42 wrote:
perhaps a random number makes the event happen for that save file, and then a value changes indicating that it wont happen again until you start a new game?
Definitely, but that's a detail of at-most-once triggering rather than the mechanism of the actual trigger->event handling, in my opinion.
You are correct.
So, like in the battle engine, have a routine check if any one of about 60 events have the same id number as the current one, then check their criteria? Sounds complicated, but I think manageable. Maybe call it once every two loops or something. Or, like in maps, only on a "hotspot", or only when battling certain people.
This is for TAO, btw. This is going to be huge if its ever finished.
graphmastur wrote:
So, like in the battle engine, have a routine check if any one of about 60 events have the same id number as the current one, then check their criteria? Sounds complicated, but I think manageable. Maybe call it once every two loops or something. Or, like in maps, only on a "hotspot", or only when battling certain people.
This is for TAO, btw. This is going to be huge if its ever finished.
Sure it sounds complex, but it's no less complex than what an interrupt would have to do anyway, without all of the dangers of unexpected behavior if the interrupt triggers in an inconvenient place and causes some kind of race condition. I like your beginnings of inklings about how to reduce the cost of checking the criteria.