Data-Oriented Design

[droqen]

On Noel Llopis'
"Data-Oriented Design"

[droqen]

Understanding: What is data-oriented design (DOD) from Noel's perspective?

. . . data-oriented design does not imply that . . . [it] exposes a large amount of functionality outside of code and lets the data determine the behaviour of the game. That is an orthogonal concept . . .

Data-oriented design shifts the perspective of programming from objects to the data itself. . .

Okay, so my first grasp of DOD is that it's about pieces of free-floating data, unattached to the OOP concept of 'objects'. Is that all, though? Surely we need some tools for organizing data. OOP is also data-oriented, but it provides a particular lens through which we understand that data. All DOD is telling me so far is that the lens is unspecified.

[droqen]

Ideal Data

If we look at a program from the data point of view, what does the ideal data look like?

. . . large blocks of contiguous, homogenous data that we can process sequentially.

. . . large blocks of homogenous data, which allow us to process the data sequentially (see Figure 1b)

Nice. I like seeing this sentence practically repeated. It is absolutely central.

[droqen]

How do you actually get started with data-oriented design? . . . It's OK to think about it in OOP terms for now, just to help us identify the data.

HMm. I have some doubts about usefulness of this advice when the way to approach this type of thinking is to start by thinking about it in OOP terms, the way of thinking the piece is trying to reduce or get away from.

That is, Llopis elsewhere claims "we can make things easy for us and for the hardware and organize our data to deal with the common case of having many items of the same type" (i.e. in the DOD way) [emphasis mine] and now here is suggesting we can think about things "in OOP terms for now". Is this only because he's expecting people to come from an OOP perspective and they will need a little bit of a transitional period before switching over to DOD thinking, or is OOP thinking actually an instrumental part of the process here? Sorry for the interruption, Noel. Reading...

[droqen]

Modularity.

. . . data-oriented design is beneficial to both performance and ease of development.

I'm going to break Llopis' argument here up into a few pieces.

- small functions. . . specifically to transform data
- functions. . . with very few dependencies on other parts of the code.
- The codebase ends up being very flat. . .
- lots of leaf functions without many dependencies

This level of modularity and lack of dependences makes understanding, replacing, and updating the code much easier.

My interest is not only in development but game design as well, and I can only speak to the marriage of the two. Often it is not very useful to change one small piece insulated from every other piece; if there is a problem, a design problem, it involves subtle changes to many interrelated pieces, and modularity can be troublesome if there is no intuitive fabric which connects the pieces.

What is that fabric?

[droqen]

In OOP, the fabric is "objects," which works great when you happen to want to change procedures and data all wrapped up within an object (e.g. player movement controls), and not so great when you happen to want to change procedures and data strewn across many objects (e.g. your melee attack clips a wall and then contacts the potion that the enemy is holding in their hand), but so far this piece seems to suggest no replacement for objects.

Still, thinking about and reading this is helping me grasp the problem more firmly in my mind.

When we think about objects, we immediately think of trees

See also A CITY IS NOT A TREE, which suggests that people naturally think in trees.

[droqen]

Think very carefully how the data is used during the transformation process from input to output. You might realize that you need to [do X with the data, which would be easier if it was Y-structured.] . . . Data-oriented design is a bit of a departure from traditional programming approaches, but by always thinking about the data and how it needs to be transformed, you'll be able to reap huge benefits both in terms of performance and ease of development.

Here's where I feel engineering and design are at a crossroads. I'm not suggesting that OOP is better, but how do you think about the way data is going to be used in the future if you don't, and can't, know?

This article does not appear to address that problem. Data must be organized or searchable, and Llopis' proposed solution is to think ahead of time about every way in which you will need to access the data and organize it appropriately.

Again, OOP is not better; OOP says "this is the way to organize data", Llopis says "there are other ways to organize data, and you have to choose the right one for the circumstances."

Sometimes we just need a default data structure though, something we can use before we know what the circumstances are. In that case, is OOP best (I don't think it is), or is there another structure/paradigm that we can use?