Expose growth and planning logic as Events and EventReceivers

[kaen]

I'd like to use DynamicCities as a framework for planning and rasterizing settlements in my own game, but much of the logic is hard coded into the various systems and I'd like to override it with my own. I have some changes prepared that will expose this logic as consumable events and add default event receivers to implement the existing logic. The idea is that user code can just define an event receiver with the same signature and higher priority to use custom logic, then simply consume the event to prevent the default logic from taking place.

Some things I'd like to expose as events:

• Checking whether a site is suitable to become a settlement
• Checking whether a settlement needs a parcel from a given zone
• Checking which building type a particular parcel should become
• Constructing the building as blocks in the world

This is an initial list, and I'm sure I'll discover more use cases as I press on. But I wanted to get your opinion on this suggestion, and whether you'd be interested in such a change.

Here's the WIP branch, with the general idea implemented for some basic logic

[skaldarnar]

Exposing these kinds of events is a good idea, please go ahead and just make a PR for it! A lot of the stuff that is happening in DynamicCities is somewhat hard coded, breaking this up definitely helps to reuse the code and adapt it to other use cases.

@Vizaxo is currently integrating his work on sectors with DynamicCities - maybe you want to have a talk with him to learn about new features/advantages of this approach. Depends a bit on what your goals are in the long run.

[Vizaxo]

Hey :) As mentioned, I'm in the middle of changing some stuff for DC too (the first PR, #30, was just merged). It's using the sectors stuff I've been working on, to convert DC from using the UpdateSubscriberSystem to sectors, which allow for periodic simulation and separating simulation from actual in-game changes (i.e. the blocks only get updated when the player goes near the city and the chunks get loaded).

I agree that exposing these events would be good. One example that @Cervator mentioned the other day was allowing for things like underwater/lake cities; the default DC behaviour is to ignore any areas with water, but a module could choose to handle the events instead and pick underwater areas to build in.

I think my changes are compatible with yours. I've converted the update(), build(), and growSettlement() methods into sector events, but the internals of the methods stay mostly the same, so our changes should be able to fit around each other.

I've been making some other changes too, such as trying to convert the module to directly access the facets instead of using the region entity system. This might be more intrusive, but that would mainly just change how the default event handlers you have implemented work, so I don't think there would be any major conflicts.

Most of my changes are dependent on the v2.0.0 engine branch, so they've been put into a different branch here in DC for now. I'm not sure what the timescale for the v2.0.0 merge is, but I think you're safe to make changes now without worrying about conflicts with mine :)

[skaldarnar]

Hey @kaen, any news on this? Feel free to open a PR for more discussions!