Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to Data-Oriented Design [pdf]

gamedevs.org

Post reply on HN
Print view View original

31–40 of 83 posts

Re: Introduction to Data-Oriented Design [pdf]

#31

Post by dustbunny »

inigyou wrote: post #17
dustbunny wrote: post #6

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…

My experience with ECS is that you shouldn't use an "ECS system". You should just do ECS. Have an array of all your particles and then update all the positions according to the velocities. Don't use a framework where you do something like get_all_entities_with (). Just have struct particles {vector positions, velocities;}. Well, managing those parallel arrays gets pretty annoying, but you solve that with a parallel-a…

> My experience with ECS is that you shouldn't use an "ECS system"

Why? Flecs, for example, is pretty sick imo.

Re: Introduction to Data-Oriented Design [pdf]

#32

Post by parpfish »

QuantumNomad_ wrote: post #30
zx8080 wrote: post #26

Earlier quoted context omitted.

> You are working for Mike Acton. AI generated skill?

Possible, but regardless of whether or not that is the case his name is well known enough and he has been around long enough that his name definitely appears in a lot of the texts the LLMs were trained on, in contexts that relate to his views on programming. Try asking your LLM of choice this in an empty session with no other context: You are working for Mike Acton. What principles do you follow when writing code? Ma…

> Maybe he found that telling it that it works for him nudges it in a direction that is beneficial

I think that’s call “spooky Acton at a distance”

Re: Introduction to Data-Oriented Design [pdf]

#34

Post by nine_k »

ButlerianJihad wrote: post #22
ghosty141 wrote: post #15

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…

Why do you lowercase "oriented" when "DOD" (and "OOD") is the usage in the slides?

Autocorrect to Department of Defense?

Re: Introduction to Data-Oriented Design [pdf]

#35

Post by slopinthebag »

inigyou wrote: post #28
slopinthebag wrote: post #24

Earlier quoted context omitted.

The problem is that there are a lot of subtleties to an ECS that these frameworks solve, and they perform better than a naive approach too. Your solution of a particles struct doesn’t even support a fundamental feature of ECS’s which is runtime composition. It’s really a different solution altogether, which is fine but it’s not a replacement for an ECS.

Often you don't have runtime composition and don't need it. By prematurely generalizing you're venturing close to OOP territory.

“Prematurely generalizing” is now an OOP thing? Are we just using OOP as a term for anything bad now?

Ooh here is a controversial one. DOD is premature optimization. Most programs don’t have enough data where the storage and access is a factor for performance. In fact it might be slower to use DOD.

Re: Introduction to Data-Oriented Design [pdf]

#36

Post by groundzeros2015 »

dustbunny wrote: post #31
inigyou wrote: post #17

Earlier quoted context omitted.

My experience with ECS is that you shouldn't use an "ECS system". You should just do ECS. Have an array of all your particles and then update all the positions according to the velocities. Don't use a framework where you do something like get_all_entities_with (). Just have struct particles {vector positions, velocities;}. Well, managing those parallel arrays gets pretty annoying, but you solve that with a parallel-a…

> My experience with ECS is that you shouldn't use an "ECS system" Why? Flecs, for example, is pretty sick imo.

Because the people who made them got nerd trapped fucking around with ECS and never shipped a product

Re: Introduction to Data-Oriented Design [pdf]

#37

Post by groundzeros2015 »

inigyou wrote: post #18
PessimalDecimal wrote: post #14

This seems like a particular branding on cache-aware data structures and algorithms. Is there more to it?

I consider it generally the ideology of anti-OOP. While OOP ideology teaches you to structure the program after the problem it solves, DOD ideology explicitly teaches you to throw all that away and think about what runs fastest on the computer. Maybe it should be called Computer-Oriented Programming or Hardware-Oriented Programming. The specifics very a lot but the top-level ideology of "fuck OOP" is consistent. Peop…

> While OOP ideology teaches you to structure the program after the problem it solves

I completely disagree with this characterization. OOP teaches you a synthetic set of concepts (go4) and then asks you to solve problems in terms of that.

And the reason why the canonical bird as a subclass of animal doesn’t work, is it’s extremely difficult to divide the world into strict categories (are you Aristotle). So the solution is to organize virtually rather than around natural traits.

The most natural way to solve a programming problem is a big list of instructions with if/else and goto. It’s very learnable, even for young children.

Re: Introduction to Data-Oriented Design [pdf]

#38

Post by [deleted] »

inigyou wrote: post #18
PessimalDecimal wrote: post #14

This seems like a particular branding on cache-aware data structures and algorithms. Is there more to it?

I consider it generally the ideology of anti-OOP. While OOP ideology teaches you to structure the program after the problem it solves, DOD ideology explicitly teaches you to throw all that away and think about what runs fastest on the computer. Maybe it should be called Computer-Oriented Programming or Hardware-Oriented Programming. The specifics very a lot but the top-level ideology of "fuck OOP" is consistent. Peop…

[deleted]

Re: Introduction to Data-Oriented Design [pdf]

#39

Post by saghm »

dustbunny wrote: post #6

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…

This is basically how I've always designed things, and I really feel like it's the best approach. Pick the right way to model data, and the algorithms will flow naturally from it. The cognitive load of reading "data" code rather than "algorithm" code is a lot lower in my opinion; reading through a bunch of declarative types like struct definitions isn't nearly as much work as reading through functions that operate on them, and moreover, it's a lot easier to spot any potential bugs in them because you don't need to maintain very much "state" in order to understand them. Maybe this is why I've generally found ECS conceptually pretty easy to wrap my head around (which is of course separate from whether it's easy to use or not, as that depends a lot more on both what the framework exposes and how a team chooses to use it).

Re: Introduction to Data-Oriented Design [pdf]

#40

Post by Rendello »

PessimalDecimal wrote: post #14

This seems like a particular branding on cache-aware data structures and algorithms. Is there more to it?

> cache-aware data structures and algorithms

Maybe hardware- and access-aware more generally.

One of Mike Acton's other talks has a "Is Data-Oriented Design even a thing?" section, which goes over what he means when he refers to DOD:

https://www.youtube.com/watch?v=rX0ItVEVjHc&t=741s

Post reply on HN