ecs: type safety & message passing systems exploration #381

Merged

emidoots merged 9 commits from sg/ecs-type-safety into main

2022-07-04 16:12:19 +00:00

emidoots commented

2022-06-30 15:42:25 +00:00

(Migrated from github.com)

Best reviewed with whitespace hidden.

This PR causes our ECS to be type-safe (the type safety here is mostly fully baked), and begin exploring message passing (this part is super early stages.)

Type safety

This implements the type safety described in https://github.com/hexops/mach/pull/349 where you define head of time as part of an ECS module what components you are defining. Then you may add/remove those components, or components from any other ECS module, to entities in the world at your choosing. The ECS world has a complete picture of all potential component types that will be used, and can thus enforce you are using the right type at comptime.

Message passing

This is exploratory, the thought process is that message passing between systems could be both a nice way of allowing systems to communicate with each-other (you'll have to use your imagination for why that would be useful) as well as scheduling when systems run.

The engine could send a tick message to all systems per frame (your classical system run schedule); you could ask the engine to send an event at a specific schedule (systems that run faster/slower than the frame rate); the engine could send user input events as messages (so you can have systems that only run when user input events become available); etc

sending a message is just directly calling the system currently (so literally a function call with a tagged union.) General thinking is the closer to that we remain the better, as it'd be good to avoid any overhead of storing messages. But multi-threading is a really important aspect here, I will potentially explore introducing async into the mix

I also haven't thought out how to namespace messages yet, there is clearly a need for some global messages (tick etc.) and namespaced messages

Observability

the nice thing w.r.t. observability (assuming you can get deterministic messaging) is you could record all messages and then you have a clear linear path of execution for every action in the ECS, rather than what appear to be disjointed systems across multiple ticks talking to eachother via messages shuffled into the ECS data as components

Networking

one aspect I haven't really thought of, but believe is true, is how message passing could potentially enable some quite nice networking code. An ECS system talking to a server could literally be just one system (e.g. player controller) sending messages to another system (the client system or something)

State of messaging

my plan is to explore it more, merge now and continue iterating on it, but not commit to it fully yet (i.e. if it turns out to be bad for multithreading systems, we may have to rip it out)

By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.

Best reviewed [with whitespace hidden](https://github.com/hexops/mach/pull/381/files?diff=unified&w=1). This PR causes our ECS to be type-safe (the type safety here is mostly fully baked), and begin exploring message passing (this part is super early stages.) ## Type safety This implements the type safety described in https://github.com/hexops/mach/pull/349 where you define head of time as part of an ECS _module_ what components you are defining. Then you may add/remove those components, or components from any other ECS module, to entities in the world at your choosing. The ECS world has a complete picture of all potential component types that will be used, and can thus enforce you are using the right type at comptime. ## Message passing This is exploratory, the thought process is that message passing between systems could be both a nice way of allowing systems to communicate with each-other (you'll have to use your imagination for why that would be useful) as well as scheduling when systems run. The engine could send a tick message to all systems per frame (your classical system run schedule); you could ask the engine to send an event at a specific schedule (systems that run faster/slower than the frame rate); the engine could send user input events as messages (so you can have systems that only run when user input events become available); etc sending a message is just directly calling the system currently (so literally a function call with a tagged union.) General thinking is the closer to that we remain the better, as it'd be good to avoid any overhead of storing messages. But multi-threading is a really important aspect here, I will potentially explore introducing async into the mix I also haven't thought out how to namespace messages yet, there is clearly a need for some global messages (tick etc.) and namespaced messages ### Observability the nice thing w.r.t. observability (assuming you can get deterministic messaging) is you could record all messages and then you have a clear linear path of execution for every action in the ECS, rather than what appear to be disjointed systems across multiple ticks talking to eachother via messages shuffled into the ECS data as components ### Networking one aspect I haven't really thought of, but believe is true, is how message passing could potentially enable some quite nice networking code. An ECS system talking to a server could literally be just one system (e.g. player controller) sending messages to another system (the client system or something) ### State of messaging my plan is to explore it more, merge now and continue iterating on it, but not commit to it fully yet (i.e. if it turns out to be bad for multithreading systems, we may have to rip it out) - [x] By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.