*TECHNICAL POST YOU HAVE BEEN WARNED*
On controlling the flow of Jugg 2:
In order to control the flow of the game without hardcoding behaviors like I did last time, I made the Juggernaut 2 "event-driven."*** When something happens, it sends out a message, and anyone listening to that message gets notified. For instance, when I enter Hart (the first city), "enter;hart" gets sent around. The first part is the main event and the part after the semicolon is additional data. Anyone subscribing to an "enter" event would be sent this, and they have different behaviors based on what the latter data is. Prefix and Suffix.
Maybe when you enter Hart, a notification comes up. Maybe when you enter the next city, a different notification comes up. The events that would get sent out would be "enter;hart" and then "enter;fen1". If the suffix is "hart", then the first notification pops up. If the suffix is "fen1", then the second one pops up. This part is hardcoded, but it has to be--it's about the least amount of hardcoding I have to do.
But when you enter Hart again, "enter;hart" gets sent around again. To avoid having the same notification pop up again (unless I want it to), I have a list of "excluded" suffixes. The first time "enter;hart" comes around, it sends the event and then adds "hart" to the "enter" event's list of excluded suffixes. So the next time that event gets sent out, it checks if the suffix is being excluded for that event; if so, it gets ignored. This is on a per-class basis, one class might only care about the event once while another might be tracking how many times it happens.
Naturally, this got extended into more functionality. I want to fade the screen in and out and someone to disappear after a bit of dialogue ends? Each dialogue object has an optional callback that can be sent out when that dialogue shows up. I send out a "foi" (fade out in) and the id of the person to disappear and bam! Unlocking a new hero after a cutscene, done. Tracking how many enemies you've beaten, easy. Talking to certain NPCs doesn't count for the medals, excluded when the game starts.
For talking to NPCs, a "talkto" plus the NPC id gets sent. But also included is the current dialogue that the NPC is saying, e.g. "talkto;32:1" for the sake of adding more information without requiring a third string. I delimit when necessary to get all the info I need.
It works and it's elegant. What else could you possibly want?
*** I don't use native events because who the fuck would use native events for so many things? I register the event by associating a prefix with a class that has an interface-given function to handle any callbacks with that prefix. It's probably similar to the internals of the flash event system, but I'm passing around 2 strings rather than a whole event object.
Rustygames
Why have you got the event payload in the name of the event? Just have a nice lovely typed object for it?
Are they literally magic strings or are you using constants? Otherwise later I guarantee you'll forget what strings you've made up :)
The excluding bit seems a tad bonkers to me. The problem lies deeper I think. If there is a different outcome for the first time you enter then perhaps it should be a different event. If that isn't what you want then I suppose some sort of internal reasoning within the listener could be okay, but it will be a little bit difficult to keep track of the state with so many "local" decisions being made.
MSGhero
The event prefixes are constants, the suffixes are mainly numbers that I have to write out. I have the event data there because a lot of the commands are strings coming from a json cutscene object. They get parsed into the prefix and suffix that get sent out.
Maybe for entering a city I could use a different event the second time, but talking to an NPC who says the same thing each time, it would be weird to see two events.