11:20
Thu
06
Jan 2011

In April 2008 I've written an essay "Fanatyzm obiektowy" (in Polish, it means "Object-Oriented Fanaticism"). I've always believed there is something wrong with object-oriented programming, that it simply doesn't meet its own objectives and so following it blindly as an ideology not only a programming language mechanics has many pitfalls. Now I'm glad that recently a concept of "Data-Oriented Design" (DOD) emerged and gained popularity among game developers. Here is my try to aggregate all important information on this subject that can be found on the Internet:

Slides:

• Pitfalls of Object Oriented Programming, Tony Albrecht (Sony Computer Entertainment Europe)
• Practical Examples in Data Oriented Design, Niklas Frykholm (BitSquid)
• Introduction to Data-Oriented Design (DICE)
• A Step Towards Data Orientation, Johan Torp (DICE)
• Memory Optimization, Christer Ericson (Sony Computer Entertainment) - PPT, PDF
• Typical C++ Bullshit, Mike Acton (Insomniac Games)
• Three Big Lies, Mike Acton (Insomniac Games)

Blog entries:

• Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP), Noel Llopis (Original article in Game Developer)
• Data-Oriented Design Now And In The Future, Games from Within
• Data oriented design links, Mark's Testblog
• Musings on Data-Oriented Design, Solid Angle
• Is Data-Oriented Design a Paradigm?, Solid Angle
• Data Oriented Luddites, TomF's Tech Blog
• Data-Oriented Design, Subtle Brilliance
• The Latency Elephant, Seven Degrees Of Freedom
• OOP != classes, but may == DOD, Roathe.com
• Data Oriented Programming, JustinLiew.Com

Other:

• Data Oriented Design @ Google+

If you know any other good readings on this subject, please leave a comment. I'll update my list.

As far as I can see, focusing more on data instead of objects gives a number of benefits for the code:

• It runs faster (because of more cache-friendly memory access patterns)
• It's more clear, simple, direct (because of the lack of class inheritance and other OOP stuff)
• It's more modular (no hidden dependencies inside object->update())
• It can be more easily parallelized and offload for coprocessing

Of course DOD doesn't exist in the void. It's related to many other concepts and you can find many good sources of knowledge about each one. Some of them are:

• Preprocessing data with offline tools to load them in game runtime just in form suitable to be directly consumed - shaders already compiled, textures already compressed with mipmaps calculated, meshes loaded directly to vertex buffers, all data in binary form. No XML or other text parsing, no OBJ or DAE models loaded by the game.
• Cache efficiency - understanding how memory cache works on contemporary CPUs, caring about data layout to ensure best possible memory access patterns.
• Parallel programming - including multithreading, SIMD and coprocessing (like on PS3 SPU).
• Memory management. Dynamic memory allocation from heap is slow, causes lots of cache misses and memory fragmentation, so much effort is put to develop better, custom memory allocators, to preallocate memory pools etc.
• Memory blobs - some try to load complex objects of different types from binary files straight into memory and then offset all pointers, manually intialize vtables and do other such magic :)
• Component architecture for game entities - organizing code of this traditionally most object-oriented part of the game in a way that is more flexible, clean and also more efficient thanks to allowing more data-oriented design than traditional class hierarchy with Object derived by Unit derived by Enemy derived by BigFinalBoss :)

Comments (3) | Tags: software engineering c++

Comments

Post comment