A Thought Experiment: Using the ECS Pattern Outside of Game Engines
adventures.michaelfbryan.com
A Thought Experiment: Using the ECS Pattern Outside of Game Engines
1–10 of 75 posts
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#2Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#3Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#4TS: https://github.com/netgusto/ecs-typescript
Go: https://github.com/bytearena/ecs
Very interesting programming concept indeed!
---
Edit: These implementations support tagged queries, and indexed views for faster iterations (ECS uses iterations a lot).
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#5Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#6How is an Entity Component System different from Objects and Controls in something like Visual Basic for example?
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#7EDIT: Actually, now when I think about it, this approach sorta makes every object (or Entity) into an independent, isolated database. Hm ...
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#8I find ECS a pretty intuitive concept, but it always ends up being a massive yak shave to me
Most applications that aren't games don't need to support things like finding all active objects of a type or maintain many discrete actors executing their own run loops.
But Unity isn't dumping a lot of marketing into talking about the decorator pattern so everyone is jumping right to ECS now.
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#9Despite "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 Clojure's "let's use maps for everything". 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.
If you go for "ECS as a way to have data-driven entities modifiable on the fly" or "ECS as a way to make game logic cleaner", then congratulations, you've just reinvented a relational database! Since you're not developing a game, you might as well store your data in SQLite and call it a day.
(In fact, I'm currently working on a roguelike game as a side project, whose distinct feature is that it stores all its game data in an in-memory SQLite database, precisely to experiment with a pure form of "ECS for game logic" pattern.)
In the end, the author explored one way of doing ECS. There are plenty others, worth their own thought experiments :).
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#10How is an Entity Component System different from Objects and Controls in something like Visual Basic for example?
Ecs is more like a database.
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.