A Thought Experiment: Using the ECS Pattern Outside of Game Engines
Which ECS? :).<p>Despite &quot;clear&quot; 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.<p>So outside games, if you pick &quot;ECS as composition over inheritance&quot;, you get something like here, or Clojure&#x27;s &quot;let&#x27;s use maps for everything&quot;. If you go for &quot;ECS as a performance optimization&quot; - a frequently touted benefit - you&#x27;ll end up storing a lot of global arrays (perhaps arranged in structures), each packing every instance of a component&#x27;s property across all entities.<p>If you go for &quot;ECS as a way to have data-driven entities modifiable on the fly&quot; or &quot;ECS as a way to make game logic cleaner&quot;, then congratulations, you&#x27;ve just reinvented a relational database! Since you&#x27;re not developing a game, you might as well store your data in SQLite and call it a day.<p>(In fact, I&#x27;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 &quot;ECS for game logic&quot; pattern.)<p>In the end, the author explored one way of doing ECS. There are plenty others, worth their own thought experiments :).