4 ms·

How does a “data oriented” game engine differ from “non data oriented” game engines?

serverholic 4y ago
This is likely related to data-oriented design https://en.m.wikipedia.org/wiki/Data-oriented_design https://en.m.wikipedia.org/wiki/Data-oriented_design The idea is that you use data structures and algorithms to make better use of CPU cache.
eastof 4y ago
Mostly it has to do with internally storing "objects" as Structures of Arrays (SoA) instead of the traditional object-oriented Array of Structures (AoS) for more parallelization opportunities with SIMD improving cache efficiency. See https://en.m.wikipedia.org/wiki/Data-oriented_design https://en.m.wikipedia.org/wiki/Data-oriented_design
jjames 4y ago
I believe this refers to the Entity Component System.
jackmott42 4y ago
This usually means that data is organized in ways that are friendly to cpu cache, instruction parallelism, and multithreading. Lining up data in arrays, arrays of positions instead of arrays of objects each of which has a position, and so on. Usually this is done via an entity component system.
laundmo 4y ago
Edit: i was a dunce and explained data-driven, which it also is, but is not what you asked. Bevy is data oriented due to its ECS: roughly: which data an entity has attached to it decides which behaviours are run. Want something to have a health bar? Just attach the Health { current: 50, max: 100 } struct and it will have all associated behaviour like being able to take damage. Want to make it invincible again? Just remove the Health struct. This is different from OOP engines, where you might need to keep an is_invincible boolean around to check against.
kroltan 4y ago
It is basically operating on the "column-oriented database" idea, which when applied to a game becomes the "Entity-Component-System" paradigm. More performance thanks to cache locality, makes it much easier to write multithreaded gameplay code (remember, games are basically a big ol' pile of "cross-cutting concerns" [1]), as well as facilitating simulation-y code by allowing you to address game objects by arbitrary sets of properties. --- [1]: Games often break the traditional "layers" we like to build in software architecture to enhance maintainability. That means traditionally you often get blobs of references and mutations scattered everywhere through the code. In a shooter, the visuals for a bullet need to know not only their origin and direction, but possibly the pose of any players in their path, as well as stats about the weapon, or even network latency, for a crude example.

This is likely related to data-oriented design https://en.m.wikipedia.org/wiki/Data-oriented_design https://en.m.wikipedia.org/wiki/Data-oriented_design The idea is that you use data structures and algorithms to make better use of CPU cache.

eastof 4y ago

Mostly it has to do with internally storing "objects" as Structures of Arrays (SoA) instead of the traditional object-oriented Array of Structures (AoS) for more parallelization opportunities with SIMD improving cache efficiency. See https://en.m.wikipedia.org/wiki/Data-oriented_design https://en.m.wikipedia.org/wiki/Data-oriented_design

jjames 4y ago

I believe this refers to the Entity Component System.

jackmott42 4y ago

This usually means that data is organized in ways that are friendly to cpu cache, instruction parallelism, and multithreading. Lining up data in arrays, arrays of positions instead of arrays of objects each of which has a position, and so on. Usually this is done via an entity component system.

laundmo 4y ago

Edit: i was a dunce and explained data-driven, which it also is, but is not what you asked. Bevy is data oriented due to its ECS: roughly: which data an entity has attached to it decides which behaviours are run. Want something to have a health bar? Just attach the Health { current: 50, max: 100 } struct and it will have all associated behaviour like being able to take damage. Want to make it invincible again? Just remove the Health struct. This is different from OOP engines, where you might need to keep an is_invincible boolean around to check against.

kroltan 4y ago

It is basically operating on the "column-oriented database" idea, which when applied to a game becomes the "Entity-Component-System" paradigm. More performance thanks to cache locality, makes it much easier to write multithreaded gameplay code (remember, games are basically a big ol' pile of "cross-cutting concerns" [1]), as well as facilitating simulation-y code by allowing you to address game objects by arbitrary sets of properties. --- [1]: Games often break the traditional "layers" we like to build in software architecture to enhance maintainability. That means traditionally you often get blobs of references and mutations scattered everywhere through the code. In a shooter, the visuals for a bullet need to know not only their origin and direction, but possibly the pose of any players in their path, as well as stats about the weapon, or even network latency, for a crude example.