So basically I will have like 100+ events specified in a very generic way? Then I set up some observer / listener messaging system so that every object only registers for certain events and then respond on it? I must say thinking about this in such an abstract way seems alright but I guess it will be a nightmare to implement in reality :/
This is fairly accurate, although in reality, you probably won't have quite as many events as you fear. Look at the example AllEightUp posted. A trigger area will be useful in lots of places and not just in the spawning of squirrels. Some events will be reused, or used by different components. As an example from my own project, say you hand an event ApplyDamage to an object for combat purposes. The object's Vitals component will listen for ApplyDamage and when it is received, it will apply the specified amount/type of damage to current HP, in turn possibly generating events to send to the owner object (LifeLow, Dead, etc...). However, a FloatingCombatTextQueue component attached to the object ALSO listens for ApplyDamage, and upon receipt will spawn a floating combat text entity to drift above the object indicating the damage received. A CombatLoggingComponent will listen for it and generate a text entry to log in the scrolling combat log ("Orc's incandescent strike hits Jim for 17(Fire). Jim is badly wounded."
If you find yourself writing a whole lot of special case or one-use events, then you might be getting too specific in your design and you might want to step back and see if you can figure out how to use existing events to accomplish your goal. If there is just no way, then go ahead and implement a new event but try to make it as general as you can so that other functionality can listen for it and do different things as well.
I don't know enough about level editors or data driven development to implement something like that. Is it absolutely necessary to script game play behavior or can it be hardcoded?.
You don't necessarily need to script. At some
point within your code, though, certain behaviors are actually going to have to finally be implemented, whether they be in script or otherwise. The goal, though, is to write each component of code with the general-case in mind, rather than coding toward a single specific instance. For example, you don't want there to be in your code somewhere a function called MakeSquirrelSpawnWhenPlayerGetsCloseToTree
. That is getting too coarsely grained with your design, and will be an absolute mess. All of that macro behavior should emerge as a result of the interaction of simpler, more general parts such as AllEightUp's trigger+filter+spawner combo. That same combo, by tweaking the data given to it, could be used to trigger an arrow trap when the player steps on a certain dungeon floor switch, or to start a plot-required dialog or cutscene when the player draws near a waiting NPC. They use the same basic structure (proximity trigger, filter to select player from other objects and ensure the event triggers only for the player, spawner to generate a new object, spell/trap effect, or dialog conversation).
Where an editor would come into play is in providing a visual tool for stringing these pieces together and tweaking the data to feed to them to get the desired behavior.