Live data from Hacker News

A Thought Experiment: Using the ECS Pattern Outside of Game Engines

adventures.michaelfbryan.com

1–10 of 75 posts

Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines

#4
I did this lightweight ECS for Go and TypeScript:

TS: 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

#7
I'm accidentally using this approach in my CMS for saving .NET Core classes (with interfaces - and supports explicit interface implementations) into document stores.

EDIT: 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

#8
post #3

I find ECS a pretty intuitive concept, but it always ends up being a massive yak shave to me

Agreed. The vast majority of the benefit is simply from learning to use composition over inheritance.

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

#9
Which 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 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

#10
post #5

How is an Entity Component System different from Objects and Controls in something like Visual Basic for example?

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.

Post reply on HN