
Entity Component Systems and Data Oriented Design [pdf] - magoghm
http://aras-p.info/texts/files/2018Academy%20-%20ECS-DoD.pdf
======
twtw
A response to the OOP part of this:
[https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-
long...](https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-
oop/)

I have no preference here, just posting it as an interesting further reading.

~~~
platz
I agree that ECS is at its most fundamental a relational scheme. Not sure why
that is controversial though..

------
zimablue
There are some parallels here with data engineering/science I think, at least
on the surface of "array of structs" => "struct of arrays" is another view on
"row oriented" vs "column oriented" data. Killing the object hierarchy and
moving to a more relational style (indexed dataframes). OO -> Systems, Systems
seem like seperated functional programming.

~~~
_pmf_
I wonder why ECS is completely absent in non-game systems. It seems like a
natural way for non-invasive extension.

------
plopz
In ECS I don't understand where you put the collections (scene graphs, quad
trees, etc) or what manages them. Does anyone have insight in this?

~~~
osaariki
Like kvark said, they don't really fit the ECS model well. The standard answer
would be to encapsulate them into a system (i.e. go outside the ECS).

The way I see ECSs is that they are in-memory relational databases that only
support equijoins (look up component matching entity ID) and optimize for
table scans. The typical choice of an index structure is a contiguous ordered
array, making for very fast lookups and scans. If insertion/deletion
performance becomes an issue you can add one level of indirection and only
keep a list of pointers to components ordered. However, like you indicated,
games also need other kinds of queries, so scene graphs and quad trees should
be supported as indices on the same level as the arrays and hash tables that
are traditional for ECSs.

I would love to see an in-memory database with all the features required by
games. There are some very different tradeoffs to be made than in typical in-
memory databases:

\- The most important queries are known up-front, since the
simulation/rendering loop is fairly defined.

\- Transactions don't need to be durable. Just need to be able to checkpoint
once in a while.

\- Lots of bulk updates from the simulation.

\- Query language needs to be well integrated into the application language to
avoid overheads.

------
ryanmarsh
I really wish there was a video of this talk, I like this deck but I'm missing
the color commentary.

~~~
aras_p
There was a video, but since I talked in Lithuanian, I doubt if it would be
useful to many people :)

------
platz
jonathan blow is not a big fan of ECS

[https://www.youtube.com/watch?v=4t1K66dMhWk](https://www.youtube.com/watch?v=4t1K66dMhWk)

~~~
Impossible
Jonathan Blow's commentary isn't anti-ECS. It's more skeptical of Rust's
borrow checker, more specifically he's pointing out how the original talk ends
with bypassing the borrow checker and copying a pattern that would have equal
safety in C or C++.

~~~
platz
That is true + there is an offhand quote he makes about ECS in general, but
99% is about the issue you mention

------
netgusto
An ECS for Go, with a TypeScript port:
[https://github.com/ByteArena/ecs](https://github.com/ByteArena/ecs)

~~~
lytedev
For the past few days I've been messing with an ECS module for Elixir! My fork
is here: [https://github.com/lytedev/ecs](https://github.com/lytedev/ecs)

Really simple with Elixir, but the naive implementation has some potential
performance issues methinks.

