This sounds a lot like OOP purists finding out not everything can be solved by inheritance so they rename something that existed already.
A Thought Experiment: Using the ECS Pattern Outside of Game Engines
31–40 of 75 posts
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#32Isn't this usually referred to as the decorator pattern when used this way outside of a game loop?
I think a decorator could be implemented as ECS.
You decorate your entities with components that get updated via a system.
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#33Which ECS? :). Despite "clear" definition from Wikipedia, ECS as a pattern suffers from multiple personality disorder. There are several different goals that all share the same name, and different implementations pick a different goal set, ending up looking not quite the same, and getting different kinds of benefits. So outside games, if you pick "ECS as composition over inheritance", you get something like here, or…
> If you go for "ECS as a performance optimization" - a frequently touted benefit - you'll end up storing a lot of global arrays (perhaps arranged in structures), each packing every instance of a component's property across all entities. This is basically what I am doing in the backend I am writing for an app that I am working on. (Also not a game btw.) No database, no overhead :D You really can fit a lot of data in…
New NVMe drives claim 5GB/s on PCIe 4, is memory mapping something like that not good enough for you already?
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#34Which ECS? :). Despite "clear" definition from Wikipedia, ECS as a pattern suffers from multiple personality disorder. There are several different goals that all share the same name, and different implementations pick a different goal set, ending up looking not quite the same, and getting different kinds of benefits. So outside games, if you pick "ECS as composition over inheritance", you get something like here, or…
I have gone down the exact same line of thinking. I think there is value in creating a simple relational data structure to have simple select and insert functions but not the overhead of sqlite. Many times when I think about it, the state of most programs could use a handful of the same structure and be done.
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#35Earlier quoted context omitted.
Not that different from MVC a couple decades ago, then! :D (just kidding) I love the history of ECS. Scott Bilas' goals with his work in Dugeon Siege, and before that, in Gabriel Knight 3 [1], was to have something close to what you're doing, in order to speed up development. He was storing game logic in text files, as opposite to having it hardcoded, to enable level designers and artists to iterate faster. I guess h…
Didn't know that origin story, thanks! FWIW, what I'm doing is storing all the runtime state in in-memory SQLite, instead of writing my own ECS. Components are rows in tables, entity IDs are used as foreign keys, game logic just does regular SQL SELECTs to query the game state, and then UPDATEs, INSERTs or DELETEs stuff as needed. I came up with this experiment when I was writing yet another implementation of ECS for…
There's a game that already did that, Sword of the Stars 2.
Widely panned at release due to being forced to release old code after VCS failure, though I'd argue the only problem after patches were left was that movement logic change didn't play out well (it was a brave attempt though).
Had some bad performance issues but I never tracked down whether they were related to SQLite or issues in their engine.
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#36Earlier quoted context omitted.
Ecs is more like a database.
ECS is all these things and none of these things. It's several separate concepts under the same name; different applications/games pick different pieces of it. It's kind of meta, really; you can imagine ECS itself as an entity, and different meanings of it as different components that could be included in it.
ECS is meta? Love the recursive definition ;)
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#37Earlier quoted context omitted.
Didn't know that origin story, thanks! FWIW, what I'm doing is storing all the runtime state in in-memory SQLite, instead of writing my own ECS. Components are rows in tables, entity IDs are used as foreign keys, game logic just does regular SQL SELECTs to query the game state, and then UPDATEs, INSERTs or DELETEs stuff as needed. I came up with this experiment when I was writing yet another implementation of ECS for…
There's a game that already did that, Sword of the Stars 2. Widely panned at release due to being forced to release old code after VCS failure, though I'd argue the only problem after patches were left was that movement logic change didn't play out well (it was a brave attempt though). Had some bad performance issues but I never tracked down whether they were related to SQLite or issues in their engine.
Are you referring to the rougelike Sword Of the Stars:Pit or to the base game itself
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#38Earlier quoted context omitted.
Didn't know that origin story, thanks! FWIW, what I'm doing is storing all the runtime state in in-memory SQLite, instead of writing my own ECS. Components are rows in tables, entity IDs are used as foreign keys, game logic just does regular SQL SELECTs to query the game state, and then UPDATEs, INSERTs or DELETEs stuff as needed. I came up with this experiment when I was writing yet another implementation of ECS for…
There's a game that already did that, Sword of the Stars 2. Widely panned at release due to being forced to release old code after VCS failure, though I'd argue the only problem after patches were left was that movement logic change didn't play out well (it was a brave attempt though). Had some bad performance issues but I never tracked down whether they were related to SQLite or issues in their engine.
Well, of course there is. Here I thought I'm doing something somewhat original...
Fortunately, existence of prior art doesn't invalidate any of the goals I had for this experiment, so I'll just carry on with it.
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#39So many of these kinds of OOP modeling complaints and solved by mixins.
I'd earnestly like to hear the responses to this from the down-voters. I had the same thought and suspect there is a good reason not to use mixins.
One problem off the top of my head is run-time changing of components. An entity that inherits from multiple mixins can't inherit from new mixins (or lose existing ones) at runtime.
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#40Earlier quoted context omitted.
The critical differences are memory layout and explicit declaration of logical dependencies: this makes the code parallel by default.
This is just false unless you think the featured article isn't ECS. Rendering is an ordered operation that at the very least shouldn't be considered parallel by default. Simply putting it in an ECS pattern doesn't guarantee anything like that. Its probably better to say it might help you write tighter loops because (ideally) you have a small amount of code looping over a large array of data, instead of a sea of actor…
Is rendering commonly closely coupled to the ECS? Rendering involves a lot of spatial trees, sorting, and indeed dealing with the nontrivial problem of parallelizing the interdependent rendering work items. It would seem to call for more specialized data structures.