Web Assembly ECS Interface

[robertlong]

Web Assembly ECS Interface

Web Assembly is a perfect runtime environment for sandboxing User Generated Content (UGC) scripts for interactive virtual worlds. It is portable with mature runtime libraries being written in a number of different languages. It is battle-tested, in web browsers, internet-scale web infrastructure, and many more production environments. And it has near-native performance which is incredibly important for realtime games.

The Entity Component System (ECS) pattern has been in use in AAA games for some time now and has in recent years made it's way into publicly available game engines. In it's most basic form, ECS consists of Entities, Components, and Systems. Entities are identifiers that represent unique objects in a simulation, Components store data associated with an entity, and Systems iteratively process entities and their components usually through queries which keep track of entities with or without a set of components.

I'd like to propose the development of a standard Web Assembly ECS interface. I believe that the data-oriented design pattern from ECS can avoid performance costs in the interface layer and mitigate potential security issues by relying on simple shared-memory patterns and few function definitions, rather than a huge set of interface functions.

Requirements

The interface design should meet the following requirements:

1. Runtime Defined Entity / Component Read/Write Permissions
2. Extensible Component Data Layout
3. Entity / Component Add/Remove API
4. System Registration / Scheduling API
5. Entity / Component Querying API

Security

These WebAssembly scripts will be untrusted UGC. The interface and runtime requirements must be defined to prevent against malicious script authors.

Possible security issues include:

1. Leaking user data through lack of process isolation and speculative execution attacks
2. Reading/writing simulation state outside of the permitted entities/components that the script should have access to.
3. Reading/writing simulation state by exploiting side effects of other systems. Ex. Using a raycaster to scan the surrounding environment when the script was not given explicit permission to do so.

Performance

UGC scripts whether malicious or not can be expensive and use up valuable system resources needed for the rest of the simulation. Efforts must be made to isolate scripts to different threads and avoid blocking the main simulation threads. System execution time and memory resources can also be limited and shut down if exceeded.

Possible Design Considerations

Memory Access

WebAssembly modules may expose their heap to the runtime and expose simple functions for running systems that mutate that memory. The component data can then be copied from this heap into the runtime's component storage or vice versa. A set of read/write bitmasks can be used to determine if the memory should be copied into/out of the WebAssembly heap.

Runtime Functions

While ECS implementations do not have many functions themselves, outside of adding/removing entities/components, they often use functions in Systems with access to IO, graphics apis, networking, etc. Ideally the WebAssembly ECS Interface can avoid these functions entirely and expose functionality purely through component data, however this method of defining APIs is asynchronous. There may be synchronous APIs that need to be exposed to make writing systems simple and efficient. Identifying these functions and determining if there are extensible methods for exposing new functions will be an important design decison.

Next Steps

I'd like to start by experimenting with this concept inside Third Room. If you are interested in working on this project, inside of Third Room or as a more general library, please respond below. I'm looking for help drafting the API spec, thinking through design/security decisions, and implementing a prototype.

[NateTheGreatt]

needless to say i'm down! where should we start?

[robertlong]

Awesome! I'd like to get some basics implemented in a small prototype app. Like creating/deleting entities, adding/removing components, querying, scheduling a system, and reading the mutated data.

[robertlong]

Saw this on Twitter today. Could be an interesting way to simplify implementations.
https://twitter.com/rsms/status/1444767430572609536

[robertlong]

This work is now happening in the omi-wasm-group. If you'd like to get involved, go there to get our current meeting times and participate in the GitHub discussions!