Isn't this usually referred to as the decorator pattern when used this way outside of a game loop?
A Thought Experiment: Using the ECS Pattern Outside of Game Engines
11–20 of 75 posts
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#12That's exactly the idea that I have been toying with recently: using ECS (and even spec crate in particular) to implement an authoritative game server. Haven't yet figured out how to make spec's and tokio's scheduling to play along, though.
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#13Isn't this usually referred to as the decorator pattern when used this way outside of a game loop?
The critical differences are memory layout and explicit declaration of logical dependencies: this makes the code parallel by default.
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#14Isn't this usually referred to as the decorator pattern when used this way outside of a game loop?
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 actors hopping around the heap. Of course, you can make tight loops in a lot of different patterns...
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#15How is an Entity Component System different from Objects and Controls in something like Visual Basic for example?
I wrote a comment on another post where I explain the cache optimization benefits of ECS, https://news.ycombinator.com/item?id=21674818
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#16Which 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 memory, and I think a lot of people tend to forget that.
I so so wish that I get to see the day when memristors become cheap and abundant. It would be so pleasant to program for a system like that I think. No persisting to disk or loading from disk, ever – imagine that!
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#17Isn't this usually referred to as the decorator pattern when used this way outside of a game loop?
Short answer is no. Decorator is an OOP design pattern, ECS is an architectural pattern. In that sense it’s a more abstract concept. One could say decorator is an OOP form of it, but I think the data oriented design crowd would balk at doing so in a mainstream OOP language like Java or C#.
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#18I look forward to seeing the ladder logic editor. I run PLCFiddle [0], which is a purely React ladder logic editor.
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#19Which 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…
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 he would have considered SQLite if it was as widespread back then.
It was only later that people realised ECS could be a performance optimisation, associated it with OOP and made libraries for it.
[1] A very fun adventure game, and fun to reverse engineer. One of the "Easter Eggs" involves teaching you how to extract data from itself.
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#20Which 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…
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 that game, and in the middle of optimizing it for processing performance I realized that all I'm doing is essentially hand-writing database indexes, so why not use a proper database instead? And it turns out, SQLite is fast enough when used in-memory.