Bevy[0] (written in Rust) has a fairly mature ECS implementation. [0] https://bevyengine.org/
It’s good, maybe even the best in the field right now, but it’s not mature.
A Simple Entity Component System (2019)
31–38 of 38 posts
Re: A Simple Entity Component System (2019)
#32IMO, ECS is a better way of doing OO (even on a non-OO language) than OO languages themselves: - Avoid the inheritance vs. composition issue - Entity as a first-class concept (no more Object vs. "Just Value Object", confusion regarding equality of objects, object hash methods) - System as a first-class concept (not just a consequence of a call stack between multiple inter-dependent objects) - It serves much of the sa…
One of the core tenets of OO is encapsulation. ECS rightly treats encapsulation as a bad thing, because data (i.e. entities) should not be encapsulated in the components and systems which operate on them.
I'd say that encapsulation may be problematic because it's essentially hidden mutable state, which makes reasoning about systems hard(er).
An attempt to hide private pieces of data may be counter-productive when an entity system tries to globally optimize the handling of state. A lack of protection though may result in inadvertently depending on parts of data that are a fleeting implementation detail; tight coupling has its own problems.
Re: A Simple Entity Component System (2019)
#33I would love to see some exploration of the ECS pattern being used for web development. A couple years ago I wrote an experiment[0] using ECS with Web Components to make a simple calculator, and... it was actually pretty nice. ECS does a great job of flattening nested structures, and would be really curious if this would improve things like prop drilling in React. 0: https://brochington.github.io/ecstatic-doc-site/do…
Fundamentally, UI is nested. The framework has to reflect this and make UI components composable in a bested way or you’ll drive developers crazy. What I do wonder about is being able to use a data oriented system that does reflect this neat ability. E.g. if the data in an ECS system is viewed as a simplified relational database, what would happen if we replaced it with a simplified graph database?
Isn't a graph of objects a simplified graph database?
Trees are not arbitrary graphs; a tree-based database may have nicer propertied than a web of objects, while allowing to describe nesting in a natural way.
Re: A Simple Entity Component System (2019)
#34IMO, ECS is a better way of doing OO (even on a non-OO language) than OO languages themselves: - Avoid the inheritance vs. composition issue - Entity as a first-class concept (no more Object vs. "Just Value Object", confusion regarding equality of objects, object hash methods) - System as a first-class concept (not just a consequence of a call stack between multiple inter-dependent objects) - It serves much of the sa…
This article makes a convincing argument that ECS is not necessarily as opposed to OOP as some proponents would have you believe:
https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long...
> I've been a long-time ranter in many "ECS" threads on the forum, partly because I don't think it deserves to exist as a term (spoiler: it's just a an ad-hoc version of the relational model), but because almost every single blog, presentation, or article that promotes the "ECS" pattern follows the same structure:
> 1. Show some terrible OOP code, which has a terribly flawed design based on an over-use of inheritance (and incidentally, a design that breaks many OOD rules).
> 2. Show that composition is a better solution than inheritance (and don't mention that OOD actually teaches this same lesson).
> 3. Show that the relational model is a great fit for games (but call it "ECS").
> This structure grinds my gears because:
> (A) it's a straw-man argument.. it's apples to oranges (bad code vs good code)... which just feels dishonest, even if it's unintentional and not actually required to show that your new architecture is good, but more importantly:
> (B) it has the side effect of suppressing knowledge and unintentionally discouraging readers from interacting with half a century of existing research.
Sorry for the lengthy quote, but I reckon this article is a classic.
Re: A Simple Entity Component System (2019)
#35ECS is a one of the possible designs of what we usually call "the gamestate" that is the dynamic structure that holds the game world simulation. But the origin of ECS is Data Oriented Design, also known as DOD, that emerged as a reaction to the bad properties of OOP. DOD is more general and IMHO more interesting than ECS. I have not yet seen a satisfying implementation of ECS, it can be extremely fast compared to OOP…
Do you have good resources on DOD?
Re: A Simple Entity Component System (2019)
#36Earlier quoted context omitted.
Is that really what you get when you put all entity IDs in a set and iterate over those? Sure the component arrays are packed but that's kind of pointless if you're iterating over them in a random order (note that the system proposed here will also gradually destroy the ordering in the packed arrays). Not that I know an easy way to keep a lists of components that ensure that iterating over them is anywhere close to c…
If the system starts ordered and is iterated frequently, and things move (due to deletion) rather less than they are iterated, you can use... bubble sort. It's basically free to do one stripe of bubble sort while iterating, and for games, you'll iterate everything once or more per frame, but introduce and delete things less.
The trick there is to ensure things work nicely if different subsets are iterated one after the other.
Note that merely ordering isn't quite enough, let's say a particular system needs components ABC and component C is rare, then the ideal situation would be to sort A and B such that those entities with component C are close together.
Re: A Simple Entity Component System (2019)
#37Earlier quoted context omitted.
If the system starts ordered and is iterated frequently, and things move (due to deletion) rather less than they are iterated, you can use... bubble sort. It's basically free to do one stripe of bubble sort while iterating, and for games, you'll iterate everything once or more per frame, but introduce and delete things less.
The trick there is to ensure things work nicely if different subsets are iterated one after the other. Note that merely ordering isn't quite enough, let's say a particular system needs components ABC and component C is rare, then the ideal situation would be to sort A and B such that those entities with component C are close together.
The devil is indeed in the details when one sets out to use memory in this Fortran-esque fashion.
Re: A Simple Entity Component System (2019)
#38Might be a misread, but this feels a little similar to relational vs columnar databases. Relational databases store a thing's data together; columnar store a type of data together.
A relational DB can store data however it wants, including columnar formats. The interface presented to the programmer (SQL) just abstracts away the details. ECS are more similar to the relational model than OOP is, and do not necessarily suffer the same 'object–relational impedance mismatch'.
I'm pretty sure a relational DB stores data per-row in a table, whereas columnar databases store data per-column. I don't know how using SQL (or not) affects this.