Return to Answer

There is no such thing as a "game with DOD". Firstable, that buzz-word is a bit fuzzy, because each system is designed data-oriented. Each program works on a set of data and makes certain transformations to it. Impossible to do that without orienting the design towards the data. So it's not mutually exclusive with "normal" design, but adds some limitiations in the way memory is accessed.

The idea behind DOD is to pack and group data belonging to one functionality closer together in a continious memory block, in order to have less cache misses, no (or at least minimal) random memory accesses and to write code for highly optimized processors like the Cell's SPUs in the PS3 with its limited memory resources, optimizing memory access and DMAs to and from it's main memory.

This does not simply mean to change everything from "Array-of-Structures" (AoS) to "Structure of Arrays" (SoA) like shown in the examples here. It can also mean mixing both and to interleave and pack data belonging to one functionality closely together, like for instance "position" and "velocity" to avoid jumping in memory for the integration of the position.

However, pure DOD systems are very hard to implement, as each pointer access is a violation of that pure concept, as you don't access a continious memory block anymore, but doing random memory accesses by dereferencing a pointer. This is particularily important for writing code for the SPU when moving for instance a particle system from the CPU to the SPU, but in the normal daily game development it is not important. It's a way to optimize sub-functionality, not to write games with it.

Mike Acton from Insomniac Games has a lot of intesting material related to this topic, you can find some of his stuff here, highly recommended.

There is no such thing as a "game with DOD". Firstable, that buzz-word is a bit fuzzy, because each system is designed data-oriented. Each program works on a set of data and makes certain transformations to it. Impossible to do that without orienting the design towards the data. So it's not mutually exclusive with "normal" design, but adds constraints in memory layout and the way memory is accessed respectively.

The idea behind DOD is to pack and group data belonging to one functionality closer together in a continious memory block, in order to have less cache misses, getting rid of virtual functions and vtables, easier parallelization, no (or minimal) random memory accesses and to write code for highly optimized processors like the Cell's SPUs in the PS3 with its limited memory resources, optimizing memory access and DMAs to and from it's main memory.

This does not simply mean to change everything from "Array-of-Structures" (AoS) to "Structure of Arrays" (SoA) like shown in the examples here. It can also mean mixing both and to interleave and pack data belonging to one functionality closely together, like for instance "position" and "velocity" to avoid jumping in memory for the integration of the position.

However, pure DOD systems are very hard to implement, as each pointer access is a violation of that pure concept, as you don't access a continious memory block anymore, but doing random memory accesses by dereferencing a pointer. This is particularily important for writing code for the SPU when moving for instance a particle system from the CPU to the SPU, but in the normal daily game development it is not important. It's a way to optimize sub-functionality, not to write games with it (yet, as Noels article explains).

Mike Acton from Insomniac Games has a lot of intesting material related to this topic, you can find some of his stuff here as well as Noel's articles, both highly recommended.

There is no such thing as a "game with DOD". Firstable, that buzz-word is a bit fuzzy, because each system is designed data-oriented. Each program works on a set of data and makes certain transformations to it. Impossible to do that without orienting the design towards the data. So it's not mutually exclusive with "normal" design, but adds some limitiations in the way memory is accessed.

The idea behind DOD is to pack and group data belonging to one functionality closer together in a continious memory block, in order to have less cache misses, no (or at least minimal) random memory accesses and to write code for highly optimized processors like the Cell's SPUs in the PS3 with its limited memory resources, optimizing memory access and DMAs to and from it's main memory.

This does not simply mean to change everything from "Array-of-Structures" (AoS) to "Structure of Arrays" (SoA) like shown in the examples here. It can also mean to interleave and pack data belonging to one functionality closely together, like for instance "position" and "velocity" to avoid jumping in memory for the integration of the position.

However, pure DOD systems are very hard to implement, as each pointer access is a violation of that pure concept, as you don't access a continious memory block anymore, but doing random memory accesses. This is particularily important for writing code for the SPU when moving for instance a particle system from the CPU to the SPU, but in the normal daily game development it is not important. It's a way to optimize sub-functionality, not to write games with it.

Mike Acton from Insomniac Games has a lot of intesting material related to this topic, you can find some of his stuff here, highly recommended.

There is no such thing as a "game with DOD". Firstable, that buzz-word is a bit fuzzy, because each system is designed data-oriented. Each program works on a set of data and makes certain transformations to it. Impossible to do that without orienting the design towards the data. So it's not mutually exclusive with "normal" design, but adds some limitiations in the way memory is accessed.

The idea behind DOD is to pack and group data belonging to one functionality closer together in a continious memory block, in order to have less cache misses, no (or at least minimal) random memory accesses and to write code for highly optimized processors like the Cell's SPUs in the PS3 with its limited memory resources, optimizing memory access and DMAs to and from it's main memory.

This does not simply mean to change everything from "Array-of-Structures" (AoS) to "Structure of Arrays" (SoA) like shown in the examples here. It can also mean mixing both and to interleave and pack data belonging to one functionality closely together, like for instance "position" and "velocity" to avoid jumping in memory for the integration of the position.

However, pure DOD systems are very hard to implement, as each pointer access is a violation of that pure concept, as you don't access a continious memory block anymore, but doing random memory accesses by dereferencing a pointer. This is particularily important for writing code for the SPU when moving for instance a particle system from the CPU to the SPU, but in the normal daily game development it is not important. It's a way to optimize sub-functionality, not to write games with it.

Mike Acton from Insomniac Games has a lot of intesting material related to this topic, you can find some of his stuff here, highly recommended.

There is no such thing as a "game with DOD". Firstable, that buzz-word is a bit fuzzy, because each system is designed data-oriented. Each program works on a set of data and makes certain transformations to it. Impossible to do that without orienting the design towards the data. So it's not mutually exclusive with "normal" design, but adds some limitiations in the way memory is accessed.

The idea behind DOD is to pack and group data belonging to one functionality closer together in a continious memory block, in order to have less cache misses, no (or at least minimal) random memory accesses and to write code for highly optimized processors like the Cell's SPUs in the PS3 with its limited memory resources, optimizing memory access and DMAs with its main memory.

This does not simply mean to change everything from "Array-of-Structures" (AoS) to "Structure of Arrays" (SoA) like shown in the examples here. It can also mean to interleave and pack data belonging to one function closely together, like "position" and "velocity" and avoid jumping in memory.

However, pure DOD systems are very hard to implement, as each pointer access is a violation of that pure concept, as you don't access a continious memory block anymore, but doing random memory accesses. This is particularily important for writing code for the SPU when moving for instance a particle system from the CPU to the SPU, but in the normal daily game development it is not important. It's a way to optimize sub-functionality, not to write games with it.

There is no such thing as a "game with DOD". Firstable, that buzz-word is a bit fuzzy, because each system is designed data-oriented. Each program works on a set of data and makes certain transformations to it. Impossible to do that without orienting the design towards the data. So it's not mutually exclusive with "normal" design, but adds some limitiations in the way memory is accessed.

The idea behind DOD is to pack and group data belonging to one functionality closer together in a continious memory block, in order to have less cache misses, no (or at least minimal) random memory accesses and to write code for highly optimized processors like the Cell's SPUs in the PS3 with its limited memory resources, optimizing memory access and DMAs to and from it's main memory.

This does not simply mean to change everything from "Array-of-Structures" (AoS) to "Structure of Arrays" (SoA) like shown in the examples here. It can also mean to interleave and pack data belonging to one functionality closely together, like for instance "position" and "velocity" to avoid jumping in memory for the integration of the position.

However, pure DOD systems are very hard to implement, as each pointer access is a violation of that pure concept, as you don't access a continious memory block anymore, but doing random memory accesses. This is particularily important for writing code for the SPU when moving for instance a particle system from the CPU to the SPU, but in the normal daily game development it is not important. It's a way to optimize sub-functionality, not to write games with it.

Mike Acton from Insomniac Games has a lot of intesting material related to this topic, you can find some of his stuff here, highly recommended.