How to do externally customizable Embers?

[droqen]

My first take on the boat game was made in one big ember using many scripts.
See: https://github.com/droqen/23-08Sturgeon/tree/master/w10_skatemouse/src

As I adjusted to enum-support and broke the project into embers, I found it much harder to make interoperable, re-usable code.
See: https://github.com/droqen/23-08Blue/tree/main/BoatGameBlue/embers
For example, I have an ember named boatblue_selfie_camera_mouse_tilt that spawns a camera that reacts to the mouse. Very nice and convenient. But I'm sorta at a loss for how to expose this for re-use.

I'm going to experiment with using Messages next week, but this seems like a messier way of connecting embers. Is it intended usage? It's taking a while to get my head around Messages as the way for embers to talk to each other as well as the way for client and server to talk to each other, when importing modules and calling functions on those modules is a more 'normal' way to do it in my mind. (Or even defining classes and then instantiating classes, passing data that way.)

~

As of right now it is definitely more convenient for me to just make one big ember full of little script pieces (as in 23-08Sturgeon/w10_skatemouse - the first link given). Build times are shorter, build sizes are smaller. I know that once ember hot switching comes in and is convenient, that new killer feature will make a major difference, and that it will be very important long-term! But, the downsides will certainly remain.

[droqen]

Actually, I take some of that back. This is great:

[dependencies]
selfie_camera = { path = "../../BoatGameBlue/embers/boatblue_selfie_camera_mouse_tilt" }

It's a little black boxy, but an ember with default parameters is nice to have. And adding an optional Message to change the behaviour could be quite cool?

[philpax]

Hmm, interesting idea! My first immediate reaction was to say "this might be complicated because you can instantiate embers at runtime", but then I figured there's nothing stopping us from exposing that, too.

I don't think it'll be in the first merged version of enum-support, but it's possible that it could be added later and work similar to messages in that you define a set of parameters that become globally available to the ember. There's a few design considerations there (UI, how defaults should work, etc) but it's definitely an interesting idea 🤔

@FredrikNoren What do you think about this? We could potentially allow for a degree of customization on the website by letting users reconfigure embers, so that they can spawn in more zombies etc, without actually changing the code.

[droqen]

To clarify, I was not actually requesting/picturing feature here, I think it's already possible to do and I planned to do so - just create an ember and a Message that changes master ember-level settings. Though as I think about it that kind of thing is rather fragile, that Message can only be called once by one ember - if multiple embers try to alter the same setting then it will happen in unpredictable orders...

Not sure what a good way to approach that problem is. Configuration on the website would be super cool. Maybe that's just an afps-console ember level thing?

[FredrikNoren]

Hm overall my hunch is that it's good for us to try to push configuration into the ECS to make it into "data", that other modules can potentially read. I.e. if there's a number_of_zombies configuration, another module could potentially read that to tweak the health of some other enemy. I'm not sure if that covers all cases though.

[philpax]

We talked more about this on the Discord, and there's no definitive solution yet (mostly as multiple embers can share the same ember as a dependency, and thus have conflicting configs). What I suggested was to the ember should spawn an entity and use that as a config with components (i.e. is_config, config_building_count, etc), and ember users can then search for that config and alter it as required.

We could also potentially reify that pattern by adding a specific section in the schema, like

[config]
building_count = { type = "U32", description = "Number of buildings", default = 100 }

and then that would generate a building_count: U32 component that would go under a config namespace, and it would attach that component to the ember's runtime entity representation (#676).

So you could do

let city_spawner = embers::city_spawner::entity();
entity::set_component(city_spawner, embers::city_spawner::config::building_count(), 200);

That should also hopefully convey the idea that the config is a shared resource, and that anybody can write to it.

[philpax]

We've been testing this pattern with the package manager/mod manager and it seems to work pretty well. I think we should go ahead and add formal support for this in the future.