Targeting Unreal Mass with DOTS: CPU Cache Efficiency and Parallel Processing for Fluid AAA Games

This report deeply compares Data-Oriented Design (DOD) and Traditional Object-Oriented Programming (OOP) approaches in Unity and Unreal Engine 5 game engines from a game developer perspective. The research aims to analyze the fundamental performance outcomes of memory layout optimization, CPU cache utilization, and multithreading support in particular. The report dives into technical details through concrete code examples and integration steps in current engine versions. Additionally, inspired by titles such as Kena: Bridge of Spirits, the strategic impacts of these architectural choices are evaluated for high-budget (AAA) third-person, open-world, and mobile platform games. Each claim has been substantiated based on the provided sources.

Fundamental Paradigm Differences: Data Storage Logic and Performance Outcomes

The core difference between Data-Oriented Design (DOD) and Object-Oriented Programming (OOP) is built upon how data is grouped as logical units and stored in memory. While OOP focuses on objects that bundle data together with functionality, DOD aims to optimize memory access patterns by keeping data of the same type together. This division in the core paradigm holds critical importance in terms of the ability to fully utilize the performance potential of modern computer architectures.

Object-Oriented Programming (OOP) generally relies on the logic of "storing data inside the object." Considering a character object, this object will possess properties containing different data types such as Position, Health, and Velocity. Each character object occupies its own distinct address space in memory. If a complex game has hundreds or thousands of characters, these objects are scattered randomly in memory. When an operation like moving all characters is executed in an Update loop, the CPU has to access each character's Position data separately. In this case, the probability of CharacterA's Position information and Health information residing in the same memory block is low; since they are different objects, they are at different addresses. Similarly, CharacterB's Position information is likely quite far from CharacterA's data. This causes the CPU, whenever it needs to pull data from memory, to access different and non-contiguous memory blocks every time. This situation creates a performance bottleneck that contradicts the structure of modern CPUs. Sudden stutters and FPS drops experienced in games like Kena: Bridge of Spirits serve as a typical indicator of performance issues stemming from such OOP-based, cache-unfriendly memory access patterns.

Data-Oriented Design (DOD), on the other hand, reverses this logic. DOD centers on the data that makes up their contents rather than objects, and aims to store data of the same type as densely and sequentially as possible in memory. The most common and formal application of this approach is the Entity Component System (ECS) architecture. ECS defines complex entities as simple "entities", adds their behaviors and properties via independent "components", and processes them through "systems" that utilize these components. At the foundation of this architecture lie Structure of Arrays (SoA) or similar data structures. Unlike the AoS (Array of Structures) logic in OOP, SoA refers to creating a separate array for each data type. For instance, all characters' Position information is stored sequentially in a single array (positions[]), all characters' Health information in another array (health[]), and all characters' Velocity information in a third array (velocity[]). Thanks to this arrangement, the task of updating the positions of all characters simultaneously requires loading only one large data block into the CPU just once. The sequential memory access pattern allows the CPU to efficiently utilize accelerated caches like L1 and L2, because once the initial data is loaded, adjacent data is also cached and can be used repeatedly. Unity's ECS documentation emphasizes that data is stored in fixed-size, contiguous memory blocks called Chunks, and how compatible this is with CPU cache lines. This simple yet effective change dramatically improves the performance of algorithms running on large data sets.

FeatureObject-Oriented Programming (OOP)Data-Oriented Design (DOD/ECS)Data Grouping Logic"Store data inside the object" (AoS - Array of Struct)"Store the same data together" (SoA - Struct of Array)Memory LayoutData resides in random and distributed memoryData is stored sequentially and compactly in memoryData Access PatternScattered, cross-accesses are commonSequential, local accesses are dominantCache EfficiencyTypically low (high number of Cache Misses)Typically high (low number of Cache Hits)Architectural CompositionCentered on inheritance and abstractionFlexible structure composed of componentsTypical ApplicationUnity GameObjects, Unreal ActorsUnity DOTS/Entities, Unreal Mass

These fundamental paradigms have followed different developmental paths for modern game engines like Unity and Unreal Engine 5. While Unity retains the OOP-based GameObject architecture, it has introduced a completely new data-oriented stack called DOTS (Data-Oriented Technology Stack). This grants developers the flexibility to use these two approaches together in different parts of the project. For example, while the user interface and certain specific game mechanics are managed with OOP, physics simulation or the control of a large amount of AI units can be realized with DOD. However, Unreal Engine 5's core architecture is deeply OOP-focused through UObject inheritance. Nevertheless, Unreal has also developed specific solutions for areas requiring high performance. Most importantly, this is the Mass Entity Framework. Mass is a framework designed specifically for scenarios where hundreds or thousands of AI units operate simultaneously, capable of performing data-oriented calculations. The purpose of Mass is to push past the performance limits of the Actor/Component architecture and provide the opportunity for parallelization by organizing certain tasks (for example, large-scale unit management) in a data-oriented manner. Additionally, the Chaos physics system has also evolved towards data-oriented approaches and includes caching mechanisms to prevent recalculating simulations. Therefore, both engines are progressing toward combining the flexibility of OOP and the performance of DOD, yet they follow different strategies stemming from their distinct architectural backgrounds.

Memory Layout and CPU Cache Efficiency Analysis

The performance of modern game engines is bounded by the reality that the CPU is vastly faster than the speed at which it pulls data from RAM. The way to overcome this "von Neumann bottleneck" is to utilize the CPU's extremely fast but small L1, L2, and L3 caches as efficiently as possible. When the CPU accesses a memory address, instead of reading just the data at that address from memory, it also pulls a few bytes located immediately next to it (usually a 64-byte "cache line") into the cache together. If the next required data is within this cache line, the CPU can access it swiftly; this situation is called a "cache hit." Otherwise, it is forced to load a new data block from the slow RAM, which is referred to as a "cache miss," a significant performance bottleneck. Data-Oriented Design (DOD) offers an architectural solution aimed at increasing the cache hit rate by avoiding the scattered memory access patterns brought by OOP in particular.

The Object-Oriented Programming (OOP) approach naturally leads to a scattered memory layout. A Character object houses members containing different data types such as position, health, and rotation. Each Character object begins with its own unique address in memory. When one wishes to call the update function of all characters in a loop, the CPU must go to the beginning of each Character object in memory. The members (data) of these objects do not have to be close to one another. For instance, CharacterA's position member and CharacterB's health member perhaps do not reside within the same 64-byte cache line. This causes the CPU, whenever we want to process data in a sequential manner, to be forced to constantly jump to different and distant memory addresses. Transitioning to a new address every single time means invalidating the previous cache line, which leads to a high rate of cache misses. For mobile platforms, this situation is even more critical; performing more operations while consuming less power constitutes a fundamental advantage for mobile devices.

Data-Oriented Design (DOD) offers a direct solution to this problem. The DOTS architecture in Unity stores data in fixed-size, completely contiguous memory blocks called "Chunks." Each Chunk contains a "Structure of Arrays" (SoA) array made up of components of the same type. For example, all data related to a component named Translation is stored in a single continuous memory block. Similarly, Rotation data resides sequentially in another chunk or within the same chunk in a separate SoA array. This arrangement enables a system (for example, MovementSystem) to process all Translation data within a single for loop. While running this loop, the CPU loads a large data block from memory only once and uses this data repeatedly, because all relevant data is very close to each other. This situation allows CPU caches to be used efficiently and dramatically reduces the cache miss rate. The fact that Entities in Unity's ECS architecture gather all the component data they contain within a single memory block maximizes this efficiency. More importantly, the layout of data in memory within Unity's DOTS architecture matches perfectly with the CPU's own memory organization (for example, the 64-byte lines of the L1 data cache). The sizes and alignments of data fields are optimized according to the requirements of cache lines. This turns into a significant advantage especially on modern mobile CPUs like the Arm Cortex-X4, because the performance of these architectures is directly related to

memory bandwidth and cache efficiency being at the highest level.

A similar philosophy exists in Unreal Engine 5. The Mass Entity Framework provides the opportunity for more efficient storage in memory by grouping entities and their components according to complex data structures called Archetypes. An Archetype defines a specific set of components. For instance, you can create an Archetype that is "Movable and Has a Weapon." Then, all entities possessing these types of components (e.g., 500 soldiers) are automatically stored in the chunks belonging to this Archetype. This allows queries to be executed more efficiently and less CPU cache to be wasted. Performing low-level optimizations aimed at Mass in newer versions such as UE 5.7 serves as clear proof that this framework is performance-focused. Furthermore, the Chaos physics system has also evolved toward data-oriented approaches and includes caching mechanisms to prevent the recalculation of simulations. Tools like the Chaos Cache Manager ensure that a simulation is calculated once and played back more than once, preventing the CPU from performing the same operation over and over again. This provides a significant performance gain especially in CPU-intensive operations such as dynamic destruction or fluid simulations.

In conclusion, memory layout optimization and CPU cache efficiency stand among the most critical factors determining the performance of modern game engines. While the OOP approach wastes the potential of CPU caches by making data access patterns naturally scattered, DOD offers a direct solution to this problem. Unity's DOTS and Unreal Engine 5's Mass framework are both designed to boost performance by avoiding scattered memory access patterns and utilizing CPU caches efficiently. This architectural change holds vital importance for delivering the desired fluid experience, particularly in games offering a rich and vibrant world like Kena: Bridge of Spirits. As for mobile platforms, these optimizations provide energy savings by offering the capability to perform more work while consuming less power.

Multi-Threading Integration and Parallel Processing Capacity

Modern processors feature multiple processor cores, and each of these cores can operate on its own. Multi-threading is the ability to use this parallel processing power in actual gameplay logic. However, the OOP-based code structure requires congested synchronization mechanisms to prevent data conflicts, which can lead to unexpected stalls and idle CPU cores. Data-Oriented Design (DOD) offers an architectural-level solution to these problems, making the parallel execution of code naturally easier.

In the Object-Oriented Programming (OOP) approach, code typically runs synchronously on a single main thread (for example, GameThread in Unreal or Main Thread in Unity). This thread processes much of the game logic, such as player input, AI logic, and physics updates. Although other subsystems (rendering, audio, physics) usually run on separate threads, these threads generally operate independently of the main thread. Because a large portion of your code runs on a single thread, the other cores of the CPU often wait idle. If a developer wants to add parallelism in an OOP-based project, they are forced to use synchronization mechanisms such as locks, mutexes, or semaphores to prevent data conflicts. These mechanisms can cause other threads to wait for a thread to finish a critical section (for example, a write operation on a list). Wait time means that a CPU core remains idle, which leads to unexpected hitches and an overall performance drop. Unreal Engine 5 has built-in multi-threading support, but the engine sometimes gets stuck on a single thread, restricting developers from fully utilizing it. This means that a large portion of the CPU's potential power is wasted.

Data-Oriented Design (DOD) is an architectural paradigm designed for parallel processing. DOD adopts principles that eliminate data conflicts among threads that read data from a single place and write to a single place. Unity's DOTS architecture is the clearest example of this philosophy and combines two fundamental technologies: Job System and Burst Compiler. The Job System breaks your code into pieces and allows you to run them in parallel across different CPU cores. An Entities.ForEach loop inside a SystemBase is actually compiled as a job. This job eliminates data races by preventing data from being modified on a single thread. Each job can be safely executed on different CPU cores. This enables parallelization without the need for complex synchronization code to prevent data conflicts. The Burst Compiler is a compiler optimization that translates C# code into highly optimized native C++ code. Burst compiles the code at the C/C++ level using the LLVM back-end, allowing you to capture the performance achievable from C++. It is extremely efficient, especially for loops, mathematical calculations, and data conversion operations. Every SystemBase in your system (for example, MovementSystem) actually runs as a job and can be optimized by Burst to run in parallel on different CPU cores. This eliminates data races by preventing data from being modified on a single thread and ensures parallelization safety.

In Unreal Engine 5, the Mass Entity Framework also adopts similar principles that facilitate the use of multi-threading. Mass facilitates multi-threading by organizing a specific task (for example, running pathfinding logic for hundreds of AIs) in a data-oriented manner and running it in parallel across multiple threads. Mass is also designed to integrate with other Unreal thread models, such as the render graph. This increases global performance by ensuring that different engine parts run in parallel on different threads. Starting from the Unreal Engine 5.0 release, the engine itself has also made improvements to increase multi-threading usage; for instance, stability and performance updates made to the Vulkan RHI have enabled better multi-threading utilization on both desktop and mobile platforms.

Concrete Code Example (Unity DOTS):


public class CharacterController_OOP : MonoBehaviour
{
    public float moveSpeed = 5f;
    void Update()
    {
        
        foreach(var character in allCharacters)
        {
            character.Move(); 
        }
    }
}

using UnityEngine;
using Unity.Entities;
using Unity.Transforms;
using Unity.Mathematics;
public class MovementSystem_DOD : SystemBase
{
    protected override void OnUpdate()
    {
        float deltaTime = Time.DeltaTime;
       
        Entities.ForEach((ref Translation translation, in Rotation rotation, in MoveSpeed speed) =>
        {
            translation.Value += speed.value * deltaTime * math.rotate(rotation.Value, new float3(0, 0, 1)).normalize();
        }).Schedule();
    }
}

In this example, while the OOP approach runs synchronously on the main thread, the DOD approach schedules the Entities.ForEach loop inside OnUpdate as a job that can be processed in parallel by the Job System. This job can be optimized by Burst and executed simultaneously on different CPU cores. This eliminates data races by preventing data from being modified on a single thread and ensures parallelization safety.

As a result, DOD naturally facilitates multi-threading usage by eliminating the synchronization difficulties and unexpected stalls brought by OOP. Unity's DOTS and Unreal Engine 5's Mass framework are both designed to improve performance by avoiding scattered memory access patterns and efficiently utilizing CPU caches. This architectural change is of vital importance to provide the desired fluid experience, especially in games that offer a rich and vibrant world like Kena: Bridge of Spirits. For mobile platforms, these optimizations provide energy savings by offering the opportunity to accomplish more work with less power consumption.

Data-Oriented Technology Stack (DOTS) Within the Unity Ecosystem

While maintaining the OOP-based GameObject architecture, Unity also introduces a completely new technology stack called the Data-Oriented Technology Stack (DOTS) for high-performance applications. DOTS optimizes memory layout based on data-oriented design principles, increases CPU cache efficiency, and naturally provides multi-threading support. This section examines the core components of DOTS, concrete code examples, and the integration process.

The Entitities package forms the foundation of DOTS. This package fundamentally provides Entity Component System (ECS) elements such as Entities, Component Data, and Systems. The core philosophy here is to take data outside of functionality and store it more efficiently in memory. 1. Entities: Entities are empty containers with unique IDs that do not carry any data. An Entity is not an object; it is merely an EntityId. This makes it very lightweight in memory and makes it possible to create and destroy them quickly. 2. Component Data: These are structs that carry data. They must be a struct, and inheritance cannot be used. For example, simple data-carrying structures such as Translation { public float3 Value; } or Health { public int Value; } are defined. These structs implement the IComponentData interface. 3. Systems: This is the logic that processes this data. Classes inheriting from the SystemBase class use queries to select specific data types (components) and perform operations on this data. The OnUpdate method is scheduled as a job and typically contains an Entities.ForEach loop.

Concrete Code Example (Unity DOTS): The following code compares how moving a character is handled differently with OOP and DOTS:


public class PlayerController_OOP : MonoBehaviour
{
    public float moveSpeed = 5f;
    void Update()
    {
      
        float moveInput = Input.GetAxis("Horizontal");
        transform.Translate(Vector3.right * moveInput * moveSpeed * Time.deltaTime);
    }
}


public struct Translation : IComponentData
{
    public float3 Value;
}
public struct Rotation : IComponentData
{
    public quaternion Value;
}
public struct MoveSpeed : IComponentData
{
    public float value;
}
// 2. System Expressing Game Logic
public class MovementSystem : SystemBase
{
    protected override void OnUpdate()
    {
       
        float deltaTime = Time.DeltaTime;
     
        Entities
            .WithName("MoveEntities")
            .ForEach((ref Translation translation, in Rotation rotation, in MoveSpeed speed) =>
            {
                translation.Value += speed.value * deltaTime * math.normalize(math.mul(rotation.Value, new float3(0, 0, 1)));
            }).Schedule();

        
        Dependency.Complete();
    }
}

In this example, the DOD approach demonstrates how data is grouped and processed in memory. The loop inside Entities.ForEach is compiled as a single job that can be optimized by Burst and executed in parallel across different CPU cores. This eliminates data races by preventing data from being modified on a single thread and ensures parallelization safety.

Integration Steps (Unity DOTS): Integrating DOTS into a Unity project starts with creating a standard Unity project and then requires adding the necessary packages via the Package Manager:

Package Manager: Go to the Edit > Project Settings > Packages menu or the Window > Package Manager menu inside the IDE.
Add Required Packages: The following core DOTS packages can be added for the project:
- com.unity.entities: The package that provides the core ECS architecture.
- com.unity.jobs: The package required to run the job system.
- com.unity.burst: The package that translates C# code into native C++ code and optimizes it.
- com.unity.mathematics: Provides fundamental mathematical types used for DOTS, such as vector and matrix operations.
- com.unity.netcode.entities: Required for network-enabled DOTS applications.
Defining Data Structure: Structs implementing the IComponentData interface are created. These structs carry data but cannot contain functions.
Creating Systems: Classes inheriting from the SystemBase class are created. These classes override lifecycle methods such as OnUpdate, OnFixedUpdate, or OnCreate.
Renderer Integration: A renderer is required to display Entities created with DOTS on the screen. Initially, it is practical to use the Hybrid Renderer to reflect DOTS data onto existing GameObjects. This allows you to maintain the existing rendering pipeline while utilizing DOTS' data-oriented architecture. Later on, Entities Graphics packages that can integrate with URP or HDRP can be used.

Strategic Implications for AAA Open World and Mobile Optimization: Games like Kena: Bridge of Spirits require both a rich, detailed environment (AA open world) and fluid, reactive character control. Mobile platforms, on the other hand, add an extra layer of challenge in terms of limited CPU/GPU power and battery life.

Performance and Fluidity: DOD is one of the most powerful tools to reduce sudden stalls and FPS drops, especially in OOP-based projects. The stutters problems in the game Kena clearly reveal the difference that the DOD approach can bring. DOD provides higher data processing capacity by utilizing the full power of the CPU, which makes targeting a more stable 60 FPS possible.

Mobile Platform Optimization:

CPU Power: Mobile CPUs (such as Arm Cortex-X4) are becoming increasingly powerful, but energy efficiency is still a critical factor. DOD can minimize CPU idle time, enabling it to accomplish more work with less power consumption. Improvements such as the 33% bandwidth reduction in Arm's Cortex-X4 architecture may mean that applications running with DOD will benefit even more from this.
Memory Management: Memory usage must be meticulously managed on mobile platforms. DOTS can reduce overall memory usage by working with more tightly packed and allocated data in memory. Technologies like Unity's AssetBundle compression formats and SVT (Virtual Texturing), when combined with DOD's data layout, can create a highly efficient structure for mobile platforms.
ProGuard Minification: Tools like ProGuard minification for Android, when used together with the optimized code generated by DOD, can further improve distribution size and performance.

As a result, Unity's DOTS stack is a powerful toolset designed to push past the scalability limits of OOP. Developers can adopt a hybrid approach by using DOTS in areas of the project where performance is critical (physics, AI, particle systems) without disrupting the existing OOP-based structure.

Performance-Oriented Architectural Approaches in Unreal Engine 5: Mass and Chaos

Unreal Engine 5 is deeply object-oriented programming (OOP) focused in its core architecture through UObject inheritance. However, the high performance and scalability demands required for AAA-quality games have forced the engine itself to evolve and adapt data-oriented approaches. To meet this need, Unreal Engine 5 offers two main performance-oriented architectural approaches: Mass Entity Framework and Chaos Physics. Going beyond Unreal's OOP-based structure by adopting data-oriented design principles, these two systems provide a vital performance boost, especially for large-scale simulations and physics simulations.

Mass Entity Framework: Data-Oriented Gameplay Mass is a framework designed for data-oriented computations in Unreal Engine 5, developed specifically for scenarios where hundreds or thousands of game units are managed simultaneously. Instead of replacing Unreal Gameplay, Mass is designed as a data-oriented and parallel-processing-friendly layer built on top of the existing Actor/Component architecture. Its core philosophy is to increase performance by grouping large amounts of similar data sets more efficiently in memory and processing them in parallel across multiple threads.

The core components of the Mass architecture are:

Entity: In Mass, an entity is an empty container with a unique ID that carries no data. This makes it extremely lightweight, much like Entitys in Unity.
Component: It is the data structure that carries data. It can be a float value, a vector, or a complex structure. Components make it possible to group data in memory.
System: This is the logic that selects entities with specific components and processes them. These systems can be parallelized while processing data.
Archetype: This is the most important and unique component of the Mass architecture. An Archetype defines a specific set of components. For example, an Archetype with "Position", "Velocity", and "AIController" components can be created. Then, all entities with these types of components (for example, 1000 enemy units) are automatically stored in memory blocks belonging to this Archetype. This allows queries to be executed more efficiently and CPU cache to be wasted less.

Concrete Code Example (Unreal Engine 5 - Mass): Mass is typically used with C++ or via specialized nodes within a Blueprint. Below is a pseudocode example that gives a general idea of the basic structure of a Mass system:


USTRUCT(BlueprintType)
struct FPositionComponent
{
    GENERATED_BODY()
    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Components")
    FVector Location;
};
USTRUCT(BlueprintType)
struct FVelocityComponent
{
    GENERATED_BODY()
    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Components")
    FVector Velocity;
};

class FMovementSystem : public FGlobalComponentSystem
{
public:
    virtual void Tick(float DeltaTime) override
    {
      
        Query.ForEach(
            [&](FEntityHandle Entity, FMutableRef<FPositionComponent> PositionComp, FMutableRef<FVelocityComponent> VelocityComp)
            {
               
                PositionComp->Location += VelocityComp->Velocity * DeltaTime;
            });
    }
};
// 3. The System is Registered and Integrated with the Engine
IMPLEMENT_MODULE(MyModule, MyModuleName);

In this example, the Query.ForEach call forms the basis of Mass's data-oriented structure. The system selects all entities with the specified components and processes the data of these entities in a single loop. This loop can be executed on different threads by Unreal's internal parallel processing mechanisms. In newer versions like UE 5.7, low-level

optimizations for Mass continue, which is clear proof of the framework being performance-oriented.

Chaos Physics and Caching:

Chaos is the default physics engine in Unreal Engine 5 and was designed as part of the OOP architecture. However, Chaos itself has also embraced data-oriented principles and is designed to boost performance, particularly for CPU-intensive simulations. Chaos supports features such as breakable joints and collision restitution.

The most important feature of Chaos's performance-oriented aspect is the caching capability of simulations. If a complex physics simulation (for example, the collapse of a large building) is recalculated every frame, this process becomes very expensive. The Chaos Cache Manager is designed to solve this problem. The developer records a simulation, and the engine saves a copy of this simulation to memory or disk. Then, when the simulation is replayed, the engine uses the recorded data instead of recalculating, which saves significant CPU time. This is extremely effective, especially for repeating effects or dynamic objects. However, this system must be meticulously tuned to work correctly; when configured incorrectly, cache data becomes out of sync and objects can snap back to their original positions.

Integration Steps (Unreal Engine 5):

Integrating systems like Mass and Chaos into an Unreal project is generally easier since they are already available in the engine's default configuration.

Enabling the Plugin: You can activate the Mass plugin from project settings (Settings > Plugins > Gameplay > Mass).
Development with Blueprint or C++: Mass can be used from the Mass Entity palette within the Blueprint editor or by writing C++ code directly. Blueprint support is ideal for rapid prototyping.
Creating a System: You can start by using ready-made controllers like MassEntityPlayerController or by creating your own system in C++ via FMassExecutionContext.
Chaos Settings: Chaos physics settings are found under Project Settings > Chaos Physics. Features such as collision restitution can be enabled in these settings. For Chaos caching, the bEnableCache option inside Chaos Solver Settings must be enabled.

Strategic Impacts:

Unreal Engine 5's data-oriented approaches hold strategic importance, especially for AAA open-world and mobile platforms. In games styled like Kena, there is a vast world with constant vitality right in front of the player. When the instantaneous behaviors of any NPC or object in this world are managed in an OOP style, hundreds of different memory addresses are accessed every frame, causing hitches (stutters). The DOD approach is vital to providing the desired fluid experience in such games. For mobile platforms, CPU cache efficiency is even more critical; doing more processing while consuming less power is a fundamental advantage for mobile devices. Unreal Engine 5's Niagara particle system, when used together with technologies like SVT (Virtual Texture), can also provide significant performance and memory improvements through the caching of simulations.

In conclusion, while maintaining its OOP-based structure, Unreal Engine 5 has developed Mass and Chaos, which are powerful data-oriented layers, to meet performance-oriented needs. While offering developers the performance required for large-scale, data-intensive simulations, these systems work in an integrated manner without altering the engine's core architecture.

Strategic Implications and Productivity Cost: An Evaluation for AAA Open World and Mobile Platforms

The choice between Data-Oriented Design (DOD) and Object-Oriented Programming (OOP) goes beyond being merely a technical preference, becoming a strategic decision for a game's success. Especially for rich, fluid, and expansive AAA games like Kena: Bridge of Spirits and mobile platforms with limited resources, this decision has profound impacts on performance, development speed, and the gameplay experience. DOD is a powerful paradigm specifically designed to overcome the scalability limits of OOP, but these advantages must be weighed against costs such as the learning curve and integration cost.

Strategic Implications for AAA Open World and Fluidity Issues:

Kena: Bridge of Spirits stands out as a game offering a rich mythological world, fluid character control, and detailed environmental elements. In discussions on Steam community forums, the game's performance issues ("stutter" and "FPS drops") have been brought up. The underlying technical reasons behind such issues are likely the scalability limits of an OOP-based architecture. In OOP, every entity in the scene (NPC, object, particle system) has its own GameObject and its attached components. Since these GameObjects are stored distributedly in memory, updating all of these entities every frame commands the CPU to access hundreds of different memory addresses. This results in a high number of CPU cache misses, forcing the processor to fetch data from slow RAM, which causes noticeable stutters (sudden slowdowns). DOD provides a direct solution to this problem. Frameworks like DOTS in Unity or Mass in Unreal Engine 5 store similar data types (for example, position data of all NPCs) contiguously in memory. This means a thread can fetch all this data from memory at once and process it, which dramatically increases the CPU cache hit rate and overall performance. This architecture is of vital importance to provide the desired fluid experience sought in games like Kena. DOD provides higher data processing capacity by utilizing the full power of the CPU, making it possible to target a more stable 60 FPS.

Strategic Implications for Mobile Platform Optimization:

Mobile platforms have more constrained resources compared to desktops or game consoles: less CPU power, less RAM, and a critical factor, battery life. Therefore, energy efficiency and memory management become key metrics of success for mobile game developers.

Energy Efficiency: Mobile processors (such as Arm Cortex-X4) are becoming increasingly powerful, but energy efficiency remains a critical factor. DOD allows the CPU to get more work done while consuming less power by minimizing idle time. Improvements such as the 33% bandwidth reduction in Arm's Cortex-X4 architecture may mean that applications running with DOD will benefit even more from this. Lower CPU usage also helps the device heat up less and the battery drain more slowly.
Memory Management: Memory usage must be meticulously managed on mobile platforms. DOD can reduce overall memory usage by working with tighter and allocated data in memory. Technologies like Unity's AssetBundle compression formats () and SVT (Virtual Texturing) (), when combined with DOD's data layout, can create a highly efficient structure for mobile platforms. Additionally, newer technologies such as Unity's DirectStorage support () and shader streaming also support the vision behind DOD's data management-based architecture.
Productivity and Development Time: Mobile-specific optimizations (such as ProGuard minification) () and the use of platform-specific APIs () when considered alongside DOD, create a more efficient codebase, making these optimizations more effective.

Productivity Cost and Developer Experience:

The performance advantages offered by DOD must be weighed against a steep learning curve and the cost of an initial drop in productivity.

Conversion Difficulty: An existing, large OOP-based project cannot be completely converted to a DOD architecture. A hybrid approach is usually followed: some critical areas (physics, AI, particle systems) are moved to DOD, while other areas (UI, certain custom gameplay mechanics) are left under the existing OOP structure. Although Unity's Hybrid Renderer () facilitates such transitions, a complete integration presents problems. The issues in Kena are most likely related to the scalability of the existing OOP-based structure and suggest that they could be solved with an architectural shift like DOD.
Experience Level: DOD can have a quite steep learning curve, especially for developers with OOP experience. Looking at the code, transitioning from the mindset of "I have an object that I own" to "what am I going to do with this dataset" is difficult. This can initially slow down development speed.
Tool Ecosystem: OOP-based Unity and Unreal have a tool ecosystem developed and matured over the years. DOD frameworks like DOTS and Mass are also evolving, but they may still have shortcomings and their documentation might be newer. For example, some bugs related to DOTS (such as burst assembly loading errors) () or the integration of systems like Unreal's Chaos Cache Manager () can still create challenges for developers.

Comparative Evaluation:

CriterionObject-Oriented Programming (OOP)Data-Oriented Design (DOD)Learning CurveLow, it is a common and popular paradigmHigh, requires a new philosophyProductivity (Initial)High, suitable for rapid prototypingLow, can be slow initiallyPerformance (Scalability)Limited, slows down for large datasetsHigh, scales well over millions of dataCPU Cache EfficiencyLow (scattered access)High (contiguous access)Ease of Parallel ProcessingMedium (requires synchronization)High (naturally parallel)Mobile Platform SuitabilityReasonable, but lower energy efficiencyHigh, utilizes the CPU more efficientlyIntegration (Existing Projects)Easy, directly compatible with existing projectsDifficult, requires a hybrid approach

Conclusion and Strategic Recommendation:

The choice between OOP and DOD varies depending on factors such as the scale of the game, the target platform, and the team's area of expertise. For small and medium-scale projects or rapid prototyping, OOP can be advantageous in terms of development speed and flexibility. However, for AAA games containing a fluid, rich, and expansive world like Kena: Bridge of Spirits, DOD becomes an indispensable option in terms of performance and scalability. As for mobile platforms, DOD makes itself even more attractive by offering extras such as energy efficiency and lower memory usage. Developers should carefully analyze project requirements and consider adopting a hybrid strategy that combines the flexibility of OOP and the performance of DOD. This will make it possible to apply the right architecture in different parts of the project.

*Note : Visuals Were Generated By Google Gemini.

Data-Oriented Design (DOD) and Object-Oriented Programming (OOP) Comparison: Architectural and Performance Analysis on Unity DOTS and Unreal Engine 5