So your actual problem is the architecture of a script interpreter on top of an ECS. What kind of scripts?
- High-performance because you run them for many objects very often (e.g. BulletML)? In this case scripts are probably part of the operation of imporyant systems and there should be no need and no way to “grab” arbitrary components.
- Sparse, general and possibly complex (e.g. for special level features like reacting to events and spawning actors)? In this case the mapping between names and classes can probably be hardcoded: you are designing a closed set of language primitives and component types with carefully selected semantics, not a generic and open-ended system in which anything could happen.
- Invasively modifying and controlling the whole game state and the systems that update it, or limited to a restricted context like a single entity?
karlmar said:
at least the idea of building a System to play a fart sound on 1 item in the entire game world seems very over the top.
Why over the top? What do you mean by “building a system”? To play even a single fart sound in the whole game you need to implement a sound effects mixer and the related component and resource types.
It isn't the large investment it might appear to be: the difficult and performance-critical aspects of playing sound are covered by libraries, and if you can implement graphics sound is normally simpler.
karlmar said:
I imagine you would have a BehaviourSystem that ticks behaviour (script) components that implement unique behaviours that interact with the data components used internally by the engine etc.
This is probably where you forget types: the same BehaviourSystem is used for every entity, doesn't know what entity it's operating on, and expects the script to know type information.
How would you restrict the commands in a script by entity type (e.g. query the temperature of a vehicle's engine, but not of a piece of scenery)?
