froggy

Rust has ways to deal with mutability. Three-rs [1] uses a classic scene graph tree, like ThreeJS. It's based on Froggy [2], which is a general low level primitive for building a "traditional" topology of the classes. [1] https://github.com/three-rs/three [2] https://github.com/kvark/froggy

What I found in practice is that many people start using the ECS for speed, and then draw themselves into a corner of the design space. Now they have to weight every step on "how would it work in ECS?", and dedicate effort to fight the ECS paradigm. For example, a mesh may contain multiple materials. Is each material chunk a separate entity? Or maybe each bone in a skeleton is a separate entity with its own "parent" and "transform" plus other component. One of the different approaches is component graph systems [1]. It lacks the ability to mix and match components, but provides a more natural (and simpler) model to program for. [1] https://github.com/kvark/froggy/wiki/Component-Graph-System

> For games that want this level of complex interaction between components, entity component systems are the way to go. Entity component systems are still in a half-baked state, with everyone rolling their own slightly different conceptual model. They're solving a problem, but not solving it well. One promising direction is getting rid of entities. Components need to link to entities and other components anyway, so one may as well treat entities as zero-size components. Old writeup (not mine): https://github.com/kvark/froggy/wiki/Component-Graph-System

The collections with any connections between elements are not exactly fitting the ECS model, which works best for independent components. When I was thinking about it back in the day, I came up with a Component Graph concept (implemented in [1]), which has the data locality similar to ECS but doesn't have a notion of systems. [1] https://github.com/kvark/froggy