The real key pillar to this world view is putting the data first in your design of the algorithm.
So if your working on a physics engine and your optimizing collision detection, you think about the data in -> data out of the problem you are solving as the primary driver of how the code should be written.
You start with defining the data, and build from there.
Different types of applications all have different shapes of data so would have differently shaped optimal code. Eg) a physics engine would use some kind of spatial hash thing which can be optimized differently based on if stuff can be added/removed while it's running. A 3d renderer operates on big buffers of matrices and vertex data. A game is usually composed of some long lived things and a lot of short lived things.
The key message in Mike Acton's talk was:
"If you have different data, you have a different problem."
While ECS systems are not a panacea that solves all problems in a perfect data oriented way, they are generally more malleable than Object Oriented hierarchies. This means it's generally more feasible to write "near optimal" code in an ECS framework than in a mature Object Oriented code base.
But the key message isn't "use X framework", it's "start by defining the data".
I actually see ECS as a subset of the relational data model. It's effectively binary relations, in database / E.F. Codd terms.
When you look at it from that angle, rather than as an optimization technique, it makes it clear there is actually an elegant programming model here.
Unfortunately game engine programmers tend to think databases are super uncool and not relevant. They could actually learn a lot.
"flecs" pulls in some concepts from the relational algebraic world in that it has some sense of joins, etc. but it's a bit ad hoc.
The ultimate "data oriented design" game engine could be a high speed, GPU/SIMD accelerated, in-memory Datalog engine. And then the game world expressed in Horn clauses and logic.
I personally love the idea of DoD but from my experience it rarely works well in practice since one of the key assumptions of understanding ur problem is often not given as new requirements pop up and change all the time.
At work we are rewriting and reengineering system from scratch and its crazy because the limitations of the old system are now gone we get the most insane feature requests that are even accepted by the team lead et al. This makes such an approach impossible since DoD is exactly the opposite of flexible design in my opinion.
Im curious has anybody really followed this in a big long living commercial project?
I wish people weren’t so dogmatic about DOD. It’s applicable mainly when you have extremely large amounts of data which can be processed in parallel, which seems mostly the case with video games (eg. look at most DOD examples) and other niche cases. It’s called “Data-Oriented Design” but it really should be called “parallel-processing design” because the average DOD advocate will never advocate for a different OOP approach if it solves a problem where those techniques are more appropriate. Advocates tend to be quite dogmatic, ask them about RAII or modern C++\Rust for example and you’ll see what I mean.
And I say this as someone who basically sees programming as data and associated algorithms and always approaches problems by considering state or data first.
I would strongly recommend reading Data-Oriented Programming in Java by Chris Kiehl [1]. Chris introduces you to the data-oriented thinking through a series of super basic examples, gradually making things more interesting. He leverages the latest Java features (e.g. record classes) to illustrate the ideas and explains why these features are important. I don't know him personally, but we both work at AWS. I liked the book so much, that I reached out internally thanking him for writing the book.
Note: AFAIU "Data Oriented Programming" (as championed e.g. in the Clojure community) and "Data Oriented Design" (as championed in the video game community) are very different philosophies for different use-cases and diametrically opposed on many dimensions. People knowing only the one phrase and assuming both to be synonymous will be in for a lot of confusion when reading about the other.
these are obvious techniques from array world, j/k/apl, and the source of e.g. arthur's bold speed claims.
personally I've discovered it insufficient to "just" convert tables to lists, you also need to understand the rest of the array principles to then effectively manipulate your data, and just to be able to hold compute in your head. because I believe in this approach I spent time learning j and k, but the end result is that my solutions become too alien for the general practitioner. it becomes apl written in whatever host language.
this is something that is not addressed in a lot of DOD talks, what happens when you do the full realization of technique: bulk list primitives, bulk transforms, SIMD optimizations, list compression, etc. and it's also the reason people claim this only works in narrow scopes (like gamedev). in reality you can write all your code for lack of better term the apl way, you're just going to make it unreadable to non apl practitioners. I'm not quite sure how to reconcile this in general, short of forcing apl to be part of general CS curriculum.
18 comments
[ 3.0 ms ] story [ 46.1 ms ] threadSo if your working on a physics engine and your optimizing collision detection, you think about the data in -> data out of the problem you are solving as the primary driver of how the code should be written.
You start with defining the data, and build from there.
Different types of applications all have different shapes of data so would have differently shaped optimal code. Eg) a physics engine would use some kind of spatial hash thing which can be optimized differently based on if stuff can be added/removed while it's running. A 3d renderer operates on big buffers of matrices and vertex data. A game is usually composed of some long lived things and a lot of short lived things.
The key message in Mike Acton's talk was:
"If you have different data, you have a different problem."
While ECS systems are not a panacea that solves all problems in a perfect data oriented way, they are generally more malleable than Object Oriented hierarchies. This means it's generally more feasible to write "near optimal" code in an ECS framework than in a mature Object Oriented code base.
But the key message isn't "use X framework", it's "start by defining the data".
When you look at it from that angle, rather than as an optimization technique, it makes it clear there is actually an elegant programming model here.
Unfortunately game engine programmers tend to think databases are super uncool and not relevant. They could actually learn a lot.
"flecs" pulls in some concepts from the relational algebraic world in that it has some sense of joins, etc. but it's a bit ad hoc.
The ultimate "data oriented design" game engine could be a high speed, GPU/SIMD accelerated, in-memory Datalog engine. And then the game world expressed in Horn clauses and logic.
https://github.com/timbran-project/mica is some of my playing in this area.
At work we are rewriting and reengineering system from scratch and its crazy because the limitations of the old system are now gone we get the most insane feature requests that are even accepted by the team lead et al. This makes such an approach impossible since DoD is exactly the opposite of flexible design in my opinion.
Im curious has anybody really followed this in a big long living commercial project?
And I say this as someone who basically sees programming as data and associated algorithms and always approaches problems by considering state or data first.
Data first is fine for simple systems, but lead to chaos for complex systems.
[1]: https://odin-lang.org/
[1] https://www.manning.com/books/data-oriented-programming-in-j...
personally I've discovered it insufficient to "just" convert tables to lists, you also need to understand the rest of the array principles to then effectively manipulate your data, and just to be able to hold compute in your head. because I believe in this approach I spent time learning j and k, but the end result is that my solutions become too alien for the general practitioner. it becomes apl written in whatever host language.
this is something that is not addressed in a lot of DOD talks, what happens when you do the full realization of technique: bulk list primitives, bulk transforms, SIMD optimizations, list compression, etc. and it's also the reason people claim this only works in narrow scopes (like gamedev). in reality you can write all your code for lack of better term the apl way, you're just going to make it unreadable to non apl practitioners. I'm not quite sure how to reconcile this in general, short of forcing apl to be part of general CS curriculum.