Scripting RFC Disposition

(Fletcher) #1

The Scripting RFC (available here) has languished since October of last year. To my knowledge, only @Moxinilian has done any work on a PoC. Unless someone wants to volunteer to implement a PoC and push it forward, it should be probably be closed and rethought; languishing like this is usually indicative of lack of resources, or trying to put too much into one RFC.

Any takers?

0 Likes

(Khionu Sybiern) #2

I’ll champion it. I’m already championing the usage of Luna as our officially supported Visual Scripting lang. That might go a bit faster if I champion this as well :wink:

0 Likes

(Fletcher) #3

Sold!

(And I dislike this 10 character minimum requirement)

1 Like

(Théo Degioanni) #4

I think Luna deserves a bit more discussion before being confirmed as our final decision. But in the meantime, we can definitely start working on the general scripting system and potentially LuaJIT and Rust.

0 Likes

(Fletcher) #5

Well, a list of requirements for the visual scripting system should be the starting point. Visual scripting is usually targeted towards a different type of user and has different requirements than a more traditional programming language system.

0 Likes

(Théo Degioanni) #6

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).

0 Likes

(Fletcher) #7

I might suggest Avro, or using JSON Schema. Then we can have a schema repository with automatic documentation, which would let people share UEL-defined…thingies…

1 Like

(Khionu Sybiern) #8

I’d rather not have us resume discussion of more fine details, not yet, and not in this thread.

0 Likes