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

71–80 of 83 posts

Re: Introduction to Data-Oriented Design [pdf]

#71

Post by btschaegg »

andreygrehov wrote: post #61

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…

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.

Re: Introduction to Data-Oriented Design [pdf]

#72

Post by groundzeros2015 »

inigyou wrote: post #50
groundzeros2015 wrote: post #37

Earlier quoted context omitted.

> 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 solut…

OOP is not Singleton, it is "class Car extends Vehicle {Tyre tyres[4]}" etc

I responded to that. It’s nonsense which doesn’t work:

> 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)

What behavior are you going to out in vehicle? Here are a few potential subclasses you’ll need to consider:

- hang glider

- wheelies

- train

- skis

- lawn mower

- windsurfing board

Re: Introduction to Data-Oriented Design [pdf]

#73

Post by shepherdjerred »

inigyou wrote: post #51
nextaccountic wrote: post #47

Earlier quoted context omitted.

But why? This looks like the mother of all boilerplates. And for what purpose? Also: just having stuff in an array or vector invites you to the ABA problem. You need a generation counter in there too, or else the array indice may get reused if something is deleted and another thing is reinserted at the same index. But that's yet another boilerplate that would easily be overlooked if you had to do everything manually.…

> You need a generation counter in there too, or else the array indice may get reused if something is deleted and another thing is reinserted at the same index. It's really sounding like you're pretending not to know what your program does, which is one of the core OOP ideas that DOD refutes. In OOP you have an array of Shape and you pretend not to know which shapes your program implements, so the only way to draw th…

This is such a good explanation of OOP vs DOD

Re: Introduction to Data-Oriented Design [pdf]

#74

Post by ghosty141 »

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?

good question, autocorrect in a non english language.

Re: Introduction to Data-Oriented Design [pdf]

#75

Post by dustbunny »

groundzeros2015 wrote: post #36
dustbunny wrote: post #31

Earlier quoted context omitted.

> 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

This is a reductive ad hominem, not a first principals examination.

Re: Introduction to Data-Oriented Design [pdf]

#76

Post by dustbunny »

samiv wrote: post #43
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…

While the idea is itself not without merit the problem is when people design these data oriented systems without abstractions and in fact it's often difficult to find good abstractions around the data the problem comes when the system, the data and functionality needs to change. There will be problems. So while it's great to think about the data flow it's also important to think about the abstractions around it,.ie t…

This is what ECS frameworks like Flecs can help with. They provide the tools and abstractions so you can write heavily modular code in this model. If you don't need the generic modularity, flecs will not feel like your gaining anything for the boilerplate you gotta write and the stuff you gotta learn, but if your making something huge that needs work for years, learning flecs is probably worth it.

Re: Introduction to Data-Oriented Design [pdf]

#77

Post by groundzeros2015 »

dustbunny wrote: post #75
groundzeros2015 wrote: post #36

Earlier quoted context omitted.

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

This is a reductive ad hominem, not a first principals examination.

No it’s not an ad hominem.

The first principles examination is you need an array of structs.

If your goal is to ship a product you would use this proven technique. It’s shipped more AAA and small games than any other.

The ECS is a hobby project which solves problems unrelated to your goal. (Making a cool ECS) And because it was not engineered with the goal of shipping you’re sitting on a pile of unknowns when you try to.

Re: Introduction to Data-Oriented Design [pdf]

#78

Post by andreygrehov »

btschaegg wrote: post #71
andreygrehov wrote: post #61

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…

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.

Ah, thanks for flagging. You are 100% correct.

Re: Introduction to Data-Oriented Design [pdf]

#79

Post by dustbunny »

groundzeros2015 wrote: post #77
dustbunny wrote: post #75

Earlier quoted context omitted.

This is a reductive ad hominem, not a first principals examination.

No it’s not an ad hominem. The first principles examination is you need an array of structs. If your goal is to ship a product you would use this proven technique. It’s shipped more AAA and small games than any other. The ECS is a hobby project which solves problems unrelated to your goal. (Making a cool ECS) And because it was not engineered with the goal of shipping you’re sitting on a pile of unknowns when you try…

Proven technique is an Appeal to Authority. You have offered no real first principal evidence for your claims. Here's some evidence in favor of flecs:

I find value in its reflection and serialization system, as well as it's pipeline API.

Games require far more than a bunch of arrays. The simulation code itself is dwarfed by the UI, VFX, animation and scene layout code. The APIs in Flecs have a lot of value for these "not the core game" use cases.

Conversely, the amount of boilerplate you have to write to stand something up in Flecs is massive. And the use of macros in Flecs APIs tends to break editor auto complete. And the learning curve is very big. And the output code just looks very different from Orthodox C.

Getting nerd trapped fucking around with ECS is a real risk. The rabbit hole goes deep. But the library itself is valuable, powerful and well done.

This is my honest thoughts on ECS systems derived from first hand experience.

Re: Introduction to Data-Oriented Design [pdf]

#80

Post by HelloNurse »

inigyou wrote: post #66
HelloNurse wrote: post #56

Earlier quoted context omitted.

I certainly don't know "what my program does" if it's a game where, at every frame of the simulation, thousands of entities might or might not be created, deleted and recycled depending on player inputs. Can you describe a superior replacement for generation counters?

If you don't know what your program does, DOD asserts that you are a bad programmer and you should first figure out what your program does before continuing. Sounds like you're writing a game engine, not a game?

You don't seem to grasp that handling individual entity state has a cost that has to be minimized and amortized.

A generation counter offers a good deal in many common cases: for the fixed small cost of incrementing the generation counter when an entity ID is assigned a trivial test, also fixed cost, can disambiguate successively recycled entities that share the same number and tell which one is current.

This adds up to work proportional to the number of distinct entities plus, assuming obsolete references are eliminated, work proportional to the number of references to entities, which is clearly very good. Do you recommend a different way to solve the same problem? There is at least one obvious one.

Post reply on HN