Replies: 1 comment
-
|
What you proposed would be a typical ECS way to organize this data. It only is a leaky abstraction if you consider it to be, from a non-ECS standpoint. Having an editor do queries seems perfectly reasonable when using an ECS as the data model.
This is not just presentation. ECS is a data layout. Each component is being stored in buffers with other components of the same archetype, and more . With |
Beta Was this translation helpful? Give feedback.
-
In web development, it's typical to have a "data model" drive some component which handles presentation, as in the classic MVC pattern, the Elm approach, or from a Rust perspective, something to the effect of egui. However, I'm having trouble finding a way to accomplish this in an ECS system.
Let's say I have a bookshelf with books on it. These books have a title, a genre, and a short name. The genre determines the color of the book on the shelf, and the short name determines what's written on the spine. Logically, this can be modeled out with ECS; a root entity has a bespoke
Bookshelfcomponent which handles positioning, then each book child of the aforementioned entity has aBook(determines position on shelf),Name(title),Mesh2d,MeshMaterial2d(genre), and a child entity with aText2d(short name).However, using this as the model of data tightly couples the model to presentation. What if I want to make an editor for the books? I could query
Books for theirNameandMeshMaterial2d, which is a bit of a leaky abstraction, but not as bad as having to query these books for aText2dchild! I have to assume the presentational structure of the bookshelf in order to access its data model. Surely there has to be a way I can just back the bookshelf with aVec<BookMetadata>and use that as the source of truth, right?Beta Was this translation helpful? Give feedback.
All reactions