Now that we are starting to work on the integration process, one thing left to design is the universal schema language do design resources and components.
The Universal ECS Language (name pending) would describe types and field names for any structure that will be either dynamically or statically generated to be used in the ECS.
An UEL description could work as an Amethyst asset, along with scripts. They should represent important data types and structures, along with other types defined by the user and the engine alike. They should let the user pick a list of fields for the structure they are designing, with a type (and potentially a generic type annotation).
This universal representation would let us parse the structure for multiple purposes:
- Generate Rust code that would act as statically building those structures into Rust structures. This is a relatively slow process, but is the best for deployment build as there would be no cost at all: writing your component in UEL would be just as efficient as writing it in Rust. Note that maybe this could even be used by users using the native Amethyst interface (native opposed to scripting), but this is probably out of scope for the current work.
- Dynamically instanciate types. Upcoming changes in specs will let us have multiple instances of resources of the same Rust type. This could be used to our advantage as it would let us register dynamic component storages that would hold a dynamic representation of our UEL types. This is useful in the case of hot reloading: with such a dynamic generation, we can even swap the component type structure without restarting the game. The components could naively be represented as dynamically types hashmaps (with Box fields, similar to JSValue if you are familiar with V8 programming). This obviously is slower than static types, but has good advantages.
- Generating bindings for scripts. This structure definition should then be parsed by language drivers (or possibly passed with all other engine types on build) so scripts can manipulate them. Apparently, this would work like all the other exposed types.
I would recommend first working on static collapsing of the UEL as this seems to require the less work. Dynamic representations can be a drop in addition.
Regarding the actual way to represent UEL, it could either be a user-facing format, or the result of the importing of another more user friendly asset. TOML could be a good idea if it is user-facing, otherwise JSON might be good as well for an internal representation. I personally would prefer the latter as it gives us more flexibility on user API.
If you have any tiny question, please ask (here seems like a good place).