I spent a lot of time playing Hardspace:Shipbreaker because I enjoyed the game, and I learned about it as an example of Unity's Data Oriented Technology Stack (DOTS) in action. I was curious about the promised benefits of DOTS and wanted to know more about it. Unity's learning portal has published several guides relating to the topic including DOTS Best Practices. Among the list of pointers to various background primers is the book Data-Oriented Design by Richard Fabian. (*) The physical book and/or its various digital editions give a full treatment of the topic, but for those who just want to skim through to see the basic concepts, the author has actually made the raw text available online.

And by "raw text" I mean that almost literally. This is a bare-bones site ("HTML 1.0") with just contents in paragraphs. (Yes, HTML <P> tags.) Tables of information are in actual <TABLE> which sees little use on modern HTML sites. The CSS style sheet is used for its original purpose: declare styling on text with no layout or funny business with <div> mutations. The only images I see are actually code listings a.k.a. pictures of more text. I enjoyed reading such a feed of raw knowledge and here are a few notes.

If I were to summarize the book, I would go with "Why Game Developers Should Learn from Database Gurus." To be clear, this is not a book about databases, but it discusses many concepts from the world of databases because they are obviously data oriented in nature. Plus, databases have a tremendous history developing methods to work in parallel, taking advantage of multicore processors where most modern applications struggle to do the same. This requires certain ways of thinking about problems, and we can learn from those lessons.

While it would be silly to say every game should be built on SQL queries, it makes sense to consider data-oriented approaches for certain domains. After all, databases underlie a lot of what we do with computers. So many computer applications are merely custom variations of database CRUD pattern that we now have products like Amazon Honeycode built around the concept of letting people create CRUD apps without code. For core game loop data, a general database would incur too much overhead. But we can tailor game code to adopt database concepts where it makes sense to improve game performance.

This book has a focus on game development, which I was surprised by given the lack of mention in the title or in some of the abstracts. It does talk about Unity at places, but only because Unity is a game engine. This book predates Unity's currently ongoing DOTS overhaul, so DOTS is not mentioned. Code examples are in C/C++ and not the C# used by Unity, but as they are there mostly to illustrate concepts, the specific programming language is less important.

The text starts with a lot of thick theoretical foundations that I found difficult to chew through, with many words I found ambiguous. Things didn't start to click for me until some concrete examples were shown. There were examples of how object-oriented programming becomes unwieldy in large projects, and I find myself nodding a lot from my own career experience. Data-oriented design approaches were then given as examples of how many of those problems can be solved, and they certainly sound good in theory! But I have yet to see them in practice for large projects and, more importantly, this book didn't spend any time talking about how DOD might stumble into its own unwieldy problems. I don't know how to avoid them if I don't even know what they look like! Another way to present my wariness is this table:

Development Approach Greatness in Theory Hurdles in Reality
Object-Oriented Design Discussed Discussed
Data-Oriented Design Discussed ...?

After reading this book, I'm convinced enough of merits to give data-oriented design a try, but I will have to keep my eyes open for where it stumbles. Because I've been writing code long enough to be sure of one thing: every nifty new solution to existing problems will bring its own new and unique problems. In time, with practice, I'm sure I'll learn where DOD is the wrong tool for the job. The good news is that, thanks to the generalized nature of this book, I don't necessarily have to try applying these concepts inside Unity. Which is good because Unity is still rolling through a multi-year transition to DOD.

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.