we need to decide architecture

[shakdwipeea]

• ECS?
• babylon-like
• threejs-like
• message passing?
• observables?
• events?
• runnable on a server?
• worker/main thread adaptable? or just worker?

[shakdwipeea]

I think it should be message passing based, not entirely sure right now on how it evolves but we can start from there. We can take inspiration from how erlang / elixir do the actor based concurrency things.

[shakdwipeea]

worker/main thread adaptable? or just worker?

The core logic should be independent of where it runs. Kinda like a state machine which runs itself based on messages coming in. It will run in a worker for perf reasons, but that shouldn't be a necessity.

[Heaust-ops]

aight sure, message passing is just an addon. the core engine architecture still needs to be decided.

I'm leaning towards let's try ECS, except let's try to modify the trad tech a bit so we get the perf benefits on the js side too

on top of that this will be built on client-server architecture,

client will only have message passing / return events stuff, server will handle the actual rendering.

upto the user if the wanna run both client-server on the main thread. server on the worker, or server on an actual server somewhere.

this also needs to be extensible. so any1 for example can write their own plugin for uv unwrapping for example.

I'm thinking something that makes the actual algorithms hot swappable. like DI or strategy pattern.

[Heaust-ops]

ofc we're gonna have a heck ton of observables as well

[shakdwipeea]

I'm leaning towards let's try ECS, except let's try to modify the trad tech a bit so we get the perf benefits on the js side too

I like ECS and a good implementation of that would be really great.

on top of that this will be built on client-server architecture,

client will only have message passing / return events stuff, server will handle the actual rendering.

upto the user if the wanna run both client-server on the main thread. server on the worker, or server on an actual server somewhere.

what you are describing is message passing + a state machine, which is actually super popular for designing concurrent systems for web apps.

It could work in our design by having different workers, which setup there own state machine and keep responding to messages.

I'm thinking something that makes the actual algorithms hot swappable. like DI or strategy pattern.

DI would work, rn I think just clean interfaces and boundaries would go a long way. I'm inclined to postpone the decision on this, since once we have implemented more stuff that would give us more insight before taking a decision.

ofc we're gonna have a heck ton of observables as well

can we use a light weight solution before jumping in to observables / again I think this decision should be made after some progress on the core things.

Unrelated to this, I also want to explore implementing a scene graph.

---

I'm excited to see what the future holds.