Hacker News new | comments | ask | show | jobs | submit login
Practical Examples in Data Oriented Design (2013) [pdf] (gamedevs.org)
95 points by Tomte on Jan 1, 2018 | hide | past | web | favorite | 9 comments

Somewhat related: My periodic rants about the terrible database designs of games.


Hi! Long time follower of your blog here. As a general database-internals-enthusiast-in-training, this kind of stuff is really fascinating to read about.

In general, however, I kind of get the impression that game development is much less rigorous even than normal software engineering, and that things are less well-architected, much more ad hoc/hackier, etc. Is there any truth to this?

Hey, not the OP, but I did want to offer my 2c anyway, as someone into gamedev. I'd say you're both very right and very, very wrong at the same time.

In game development, especially with indies, in the early phases of development many developers take an approach of valuing "getting it going" over everything else. While this might sound short-sighted, it's actually a very canny decision, and often is the only way to gain enough of a foothold to ensure the long-term success of the project when you're working on a very complex piece of software like a game - see Jonathan Blow's youtube video on "The art of getting things going". Additionally there's the relationship of this approach with the game design process, where you need a very fast iteration time on prototyping game mechanics in the early stages, to start finding your way towards something interesting to flesh out into a full product.

With that being said, in commercial game development (and experienced indie developers), the performance standards are so much higher than most other fields of programming that it is actually absurd. The focus on performance of much of enterprise software, web apps, and even most native tools, is nowhere even in the same league as that of high-quality games.

I would also say that at the highest level of game development there is a very high quality level of code organization and architecture. Games are one of the most complex types of programs, involving physical simulation of a large amount of objects, skeletal animation skinning, very complex rendering and shading, realtime deterministic state synchronization over a network, audio streaming, and on, and on, and on, all happening on a realtime basis.

There's simply no room to be "ad hoc" or "hacky" in AAA gamedev because the systems involved are so complex that their architecture has to be extremely robust to even be able to finish the game at all. In my opinion, other fields of programming have a lot to learn from the lessons of game development, but unfortunately gamedev is a bit of an insular field and there's not much cross-pollination between gamedev and other industries.

Or you could just look at it like this:

AAA Gamedev: Formula 1 car

Google / AWS : State of the art metropolitan high-speed rail system

Enterprise Software: Diesel bus service

Native apps and tools: Sedans, hatchbacks, vans, sports cars

Web apps: Bicycles

Electron apps: Bicycle with a lawnmower engine welded to the frame that tops out around 20mph and gets 3 miles to the gallon

Extremely generalized, but here's my viewpoint:

If startups are a risky venture, video games are insane, and video game startups essentially doomed to failure.

Your window for sales is the first few months after release. After that they generally slow to a trickle. Microtransactions get brought in to rectify that situation, but then further increase the risk that players will reject your game en masse.

Spending time to make a beautiful architecture doesn't make sense. Companies that sell game engines have an incentive to do things right, but spend too long and you'll lag behind the competition in shiny features and your customers will jump ship to things that help them sell games.

Key to game development is to iterate fast and fail fast. Building up a prototype and getting it to a state where it's "fun" is crucial, and then the sunk costs fallacy kicks in and the prototype gets cleaned up and shipped.

Players are unconcerned with bugs despite often complaining about them. The success of early access games like Minecraft, Day Z, and PlayerUnknown's Battlegrounds despite often gamebreaking bugs proves this.

The disconnect between quality and success has become so pronounced that an entire subgenre of "simulators" has popped up where the core gameplay mechanic is the game being buggy and/or frustrating to play. Goat Simulator, Surgeon Simulator, Getting Over It with Bennett Foddy, and Hand Simulator come to mind here, but there are plenty more.

That's the meme, and I used to think that it could be true. I'd worked at some small and large game studios, and now I'm at one of the big three software companies. Things are much, much more hacked together here than in any of my previous jobs. The main difference here is that we can throw money and people at a problem: over-scale things by ridiculous amounts, hire whole teams for basic things.

At the game studios I've worked at, programmers created unique designs that worked really well for the games they were made for, usually created and maintained by a single person. These things are rarely evangelized due to lack of time, resources, or need (games still come in boxes, and the codebase doesn't need to live forever.) An outside engineer might see it and think it's poorly designed because they haven't seen the pattern on HN.

I think that we'll see more robust engineering discussion from game programmers as games as a service becomes more the norm.

This is all anecdotal, and I'd like to hear what others think.

Slide #3 is evergreen, seen that exact image in many talks and it's still just as relevant today as when I first saw it.

These slides may be difficult for beginners to follow. A more in-depth treatment can be found at Robert Nystrom's wonderful game Programming Patterns resource available for free online:


And of course Mike Acton's classic talk:

CppCon 2014: Mike Acton "Data-Oriented Design and C++"


All these resources are CPU oriented. As next gen GPUs begin to dominate for data queries. It will be interesting to see how the game changes as well.

The Rise of the GPU: How GPUs Will Change the Way You Look at Big Data


I also found this to be a really good resource:


I love data oriented programming. It lets you worry on data instead of useless design patterns and others abstract languages paradigms which i never understand what it is trying to accomplish.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact