Wow you found this page, welcome! It’s either you;

• Typed the correct URL (if that’s the case, congrats!)
• One of people that I trust and owe something to, so I hope this can help and paid a bit of something I owed

Here’s my personal interview preparation note. It started as an old note that I wrote back in college as a fresh-graduate, found in an old hard drive

But I decided to improve the whole thing by fact-checking and adding some things that either actually get asked in the interview or things that I learned, gained and experienced during my ~5 years of career thus far

// TODO: Visualize several things with three.js just like 1000 boids article?

Fundamentals and C++ #

1. Scope and lifetime #

• Scope: Where the variable is visible (where you can type its name and the compiler knows what it is)
• Lifetime: When the variable actually exists in the memory

Usually these overlaps, but not always

Example of mismatch: If an object gets created on the Heap via new keyword, the pointer variable might go out of scope (you can’t see it anymore), but the object itself has an infinite lifetime, until you explicitly delete it. Typically this is called a memory leak

2. Automatic storage (stack scope) #

Default behavior for variables declared inside functions or code blocks {}

Object is created when execution reaches the declaration. It is automatically destroyed when execution reaches the closing curly brace } of that block

 1class Player {
 2public:
 3    Player() { std::cout << "Player Created\n"; }
 4    ~Player() { std::cout << "Player Destroyed\n"; }
 5};
 6
 7void GameLoop() {
 8    std::cout << "Start Loop\n";
 9    
10    // Scope 1: The Function Body
11    Player p1; // Created here
12
13    {
14        // Scope 2: A nested block (e.g., inside an if statement)
15        std::cout << "Entering Block\n";
16        Player p2; // Created here
17        std::cout << "Leaving Block\n";
18    } // <--- p2 is DESTROYED here immediately. p1 is still alive.
19
20    std::cout << "End Loop\n";
21} // <--- p1 is DESTROYED here.

Understand that p2 does not exist outside that small block. Typically we often use {} blocks to specifically force an object (like a temporary texture or mutex lock) to die early to free up resources

3. Static storage (static keyword) #

3a. Static local variable #

A variable inside a function that gets marked as static is initialized only once, the first time the code runs and it retains its value between function calls. Its lifetime is the entire program execution

 1int GetNextID() {
 2    // This line runs ONLY the first time GetNextID is called
 3    static int counter = 0; 
 4    
 5    counter++;
 6    return counter;
 7}
 8
 9// Usage:
10// GetNextID() -> returns 1
11// GetNextID() -> returns 2 (It remembers!)

3b. Static class member #

A variable in a class marked static is shared by all instances of that class. It is not stored inside the object itself

 1class Enemy {
 2public:
 3    static int EnemyCount; // Declaration
 4    Enemy() { EnemyCount++; }
 5    ~Enemy() { EnemyCount--; }
 6};
 7
 8// Definition (must be done outside the class, usually in .cpp)
 9int Enemy::EnemyCount = 0; 
10
11// If you spawn 50 Enemy objects, there is still only ONE "EnemyCount" variable in memory.

4. RAII (Resource Acquisition is Initialization) #

Stupid name. But arguably one of the most important concept in modern C++. It relies entirely on Scope and Lifetime

The concept: You acquire a resource (open a file, allocate memory, lock a thread) in the Constructor and you release it in the Destructor. C++ guarantees destructors run when a stack object goes out of scope, this subsequently prevents leaks

=== BAD CODE ===

 1void ProcessFile() {
 2    FILE* f = fopen("data.txt", "r"); // Acquire
 3    
 4    if (!f) return;
 5    
 6    // ... do work ...
 7    if (ErrorDetected) {
 8        return; // DANGER! We returned without closing 'f'. Resource leak!
 9    }
10
11    fclose(f); // Release
12}

=== GOOD CODE ===

 1class FileHandler {
 2    FILE* f;
 3public:
 4    FileHandler(const char* name) { f = fopen(name, "r"); }
 5    ~FileHandler() { if(f) fclose(f); } // Destructor handles cleanup
 6};
 7
 8void ProcessFile() {
 9    FileHandler myFile("data.txt"); 
10    
11    // ... do work ...
12    if (ErrorDetected) {
13        return; // SAFE. myFile goes out of scope, destructor runs, file closes.
14    }
15}

Typically this proves that you know how to write “exception safe” code. If the game crashes or throws an error, RAII ensures you don’t leave any memory leaks behind

5. Member initialization order #

Class members are initialized in the order they are declared in the header file, NOT the order they appear in the constructor’s initialization list. This is often the trap that catches me off-guard

The trap:

1class BadClass {
2    int y;
3    int x; // Declared SECOND
4public:
5    // Constructor attempts to init x first, then use x to init y.
6    // Looks fine here...
7    BadClass(int val) : x(val), y(x * 2) {} 
8};

The bug:

• The compiler looks at the header
• y is declared first
• It initializes y first
• It tries to set y = x * 2
• BUT x hasn’t been initialized yet! it contains garbage memory
• y becomes garbage value
• Then x is initialized

To fix, always keep initialization list in the same order as your variable declarations. Most compilers will actually warn you about this (-Wreorder)

6. Constructors and Destructors #

6a. Lifecycle #

• Constructor (MyClass()): Called automatically when an object is created. It sets up the “invariant” (state required for the object to function)
• Destructor (~MyClass()): Called automatically when an object is destroyed, either due to eithergoes out of scope or delete is explicitly called

It’s a good idea to avoid heavy logic in Constructors. Why? C++ constructors cannot return error codes. Let’s say if loading a texture fails inside a constructor, you have to throw an exception (which many game engines disable) or leave the object in an invalid “zombie” state

Safe pattern: Lightweight constructor + an Init() function that returns a bool for success/failure

6b. Virtual Destructor #

Say you have a Base class Enemy, and a derived class Boss. You are holding a pointer to the Base class, but it points to the derived object

The trap:

 1class Enemy {
 2public:
 3    Enemy() { std::cout << "Enemy Created\n"; }
 4    // NON-VIRTUAL Destructor
 5    ~Enemy() { std::cout << "Enemy Destroyed\n"; } 
 6};
 7
 8class Boss : public Enemy {
 9    int* heavyData;
10public:
11    Boss() { heavyData = new int[1000]; std::cout << "Boss Created\n"; }
12    ~Boss() { 
13        delete[] heavyData; // Cleanup
14        std::cout << "Boss Destroyed\n"; 
15    }
16};
17
18void KillEnemy() {
19    // Polymorphism: Base pointer holding Derived object
20    Enemy* e = new Boss(); 
21    
22    // ... game logic ...
23
24    delete e; // <--- PROBLEM HERE
25}

This essentially makes it so that if ~Enemy() is not marked as virtual, the compiler only looks at the pointer of type Enemy*. It calls ~Enemy(), but it never calls ~Boss(). Thus, heavyData array in Boss never gets deleted, causing memory leak

The fix:

1class Enemy {
2public:
3    virtual ~Enemy() { std::cout << "Enemy Destroyed\n"; }
4};

Simple enough. Now, delete e looks up the vtable and sees that the object is actually a Boss. Subsequently calls ~Boss() first, followed by ~Enemy()

6c. Initialization lists vs. Assignment #

There are two ways to give values to member variables in a constructor. One is faster; the other is sometimes impossible

Option A: Assignment, inside the body #

1class Player {
2    std::string name;
3public:
4    Player(std::string n) {
5        name = n; 
6    }
7};

• name is default constructed (empty string created)
• The assignment operator is called to copy n into name
• The temporary string is destroyed

We’re wasting CPU cycles creating an empty string, just to overwrite it immediately

Option B: Initialization list, after the colon #

1class Player {
2    std::string name;
3public:
4    Player(std::string n) : name(n) { // <--- This is the list
5        // Body is empty
6    }
7};

Now, name is copy constructed directly from n. More efficient since we no longer waste CPU cycle for creating empty string

It’s almost always a good idea to use initialization lists for:

• const members, since they cannot be assigned to later
• Reference members (int& ref, etc.), since they must be bound upon creation
• Objects without default constructors. If a member class requires arguments to be built, you must pass them in the list

6d. The rule of three (and five lol) #

This relates to how C++ handles copying objects. By default, C++ does a shallow copy, which just copies the bits

It creates a problem, if your class manages a raw pointer (i.e., to a texture or an array), a shallow copy copies the address, not the data itself

Hypotetically, it goes like this:

• Obj A is created. Allocates memory at address 0x123
• Obj B is created as a copy of A. It also points to 0x123
• Obj A is destroyed, deletes 0x123
• Obj B is destroyed as well, it tries to delete 0x123 again
• Crash, double free error

 1#include <algorithm> // For std::copy
 2
 3class Buffer {
 4private:
 5    int* data;
 6    size_t size;
 7
 8public:
 9    // 1. Constructor (Resource Acquisition)
10    Buffer(size_t s) : size(s) {
11        data = new int[size]; 
12        // Fill with dummy data
13        for(size_t i=0; i<size; ++i) data[i] = 0;
14    }
15
16    // 2. Destructor (Resource Release)
17    ~Buffer() {
18        delete[] data; // If we didn't implement Copy logic, this would crash on copy!
19    }
20
21    // 3. Copy Constructor (Deep Copy)
22    // Called when: Buffer b = a;
23    Buffer(const Buffer& other) : size(other.size) {
24        // A. Allocate NEW memory
25        data = new int[size];
26        
27        // B. Copy the VALUES (Deep Copy), not the pointer
28        std::copy(other.data, other.data + size, data);
29    }
30
31    // 4. Copy Assignment Operator (Deep Copy)
32    // Called when: b = a; (Both already exist)
33    Buffer& operator=(const Buffer& other) {
34        // A. Self-assignment check (Critical!)
35        // If someone writes "a = a;", we shouldn't delete our own data.
36        if (this == &other) {
37            return *this;
38        }
39
40        // B. Clean up OLD memory
41        delete[] data;
42
43        // C. Allocate NEW memory and Copy
44        size = other.size;
45        data = new int[size];
46        std::copy(other.data, other.data + size, data);
47
48        // D. Return *this to allow chaining (a = b = c)
49        return *this;
50    }
51};

The rule of three: If you need to define a custom Destructor (to delete memory), you almost certainly also need to define a custom Copy Constrcutor and Copy Assignment Operator to handle Deep Copies (allocating new memory for the copy)

Now with modern C++, there’s the rule of five: For performance sake, we also add:

• Move Constructor, instead of copying data, we “steal” the pointer from the temporary object that is about to die anyway
• Move assignment operator

Typically this is called move semantics

 1class Buffer {
 2    // ... (Previous Rule of Three code goes here) ...
 3
 4public:
 5    // 5. Move Constructor
 6    // Called when: Buffer b = std::move(a);
 7    // Note: 'other' is not const, because we are going to modify it.
 8    Buffer(Buffer&& other) noexcept 
 9        : data(nullptr), size(0) // Initialize self to empty
10    {
11        // A. Steal the resources
12        data = other.data;
13        size = other.size;
14
15        // B. Null out the source (So its destructor deletes nothing)
16        other.data = nullptr;
17        other.size = 0;
18    }
19
20    // 6. Move Assignment Operator
21    // Called when: b = std::move(a);
22    Buffer& operator=(Buffer&& other) noexcept {
23        // A. Self-assignment check
24        if (this == &other) {
25            return *this;
26        }
27
28        // B. Clean up OUR old memory (We are being overwritten)
29        delete[] data;
30
31        // C. Steal resources
32        data = other.data;
33        size = other.size;
34
35        // D. Null out the source
36        other.data = nullptr;
37        other.size = 0;
38
39        return *this;
40    }
41};

Pro-gamer move: There’s this trick called Copy-and-Swap. It simplifies above rules by reusing code and providing strong exception safety. Albeit with an addition of a swap() function

 1class Buffer {
 2    int* data;
 3    size_t size;
 4
 5public:
 6    // Constructor
 7    Buffer(size_t s) : size(s), data(new int[s]) {}
 8    
 9    // Destructor
10    ~Buffer() { delete[] data; }
11
12    // Copy Constructor (Same as before)
13    Buffer(const Buffer& other) : size(other.size), data(new int[other.size]) {
14        std::copy(other.data, other.data + size, data);
15    }
16
17    // Move Constructor (Same as before)
18    Buffer(Buffer&& other) noexcept : data(nullptr), size(0) {
19        swap(*this, other);
20    }
21
22    // FRIEND SWAP FUNCTION
23    // Swaps the guts of two objects efficiently
24    friend void swap(Buffer& first, Buffer& second) noexcept {
25        using std::swap;
26        swap(first.size, second.size);
27        swap(first.data, second.data);
28    }
29
30    // UNIFIED ASSIGNMENT OPERATOR
31    // Handles BOTH Copy-Assign and Move-Assign!
32    // Notice the parameter is passed by VALUE (creates a copy or move automatically)
33    Buffer& operator=(Buffer other) {
34        // Swap our (old) data with the copy's (new) data.
35        // When 'other' goes out of scope at the end of this function,
36        // the destructor cleans up our old data automatically.
37        swap(*this, other);
38        return *this;
39    }
40};

6e. explicit keyword #

Prevents accidental type conversion that can cause weird-ass bugs

The trap:

 1class Health {
 2public:
 3    // Constructor that takes ONE argument
 4    Health(int hp) { ... } 
 5};
 6
 7void HealPlayer(Health h) { ... }
 8
 9// Usage
10HealPlayer(50); // <--- This compiles!

Compiler sees you passed an int (50), sees Health has a constructor that takes an int, and implicitly converts 50 into a Health object. This is often confusing and likely unintended

The fix:

1class Health {
2public:
3    explicit Health(int hp) { ... }
4};
5
6HealPlayer(50); // Compiler Error!
7HealPlayer(Health(50)); // Allowed. You must be explicit.

7. Stack and Heap allocation #

7a. The Stack. Fast, automatic but small #

Think of The Stack like a stack of plates. You can only add to the top, and take off the top.

• Allocation is extremely fast. The CPU internally just moves a pointer, the “Stack Pointer” down to make a room. Typically only cost one CPU instruction
• Deallocation is also extremely fast. The CPU moves the pointer back up. The memory is “freed” instantly
• Lifetime is stricly tied to scope blocks {}
• Size limit is very small, usually 1-8MB depending on the OS

 1void UpdatePlayer() {
 2    // Stack Allocation
 3    // 1. Fast.
 4    // 2. Automatically deleted when function ends.
 5    Vector3 position = {10.0f, 20.0f, 30.0f}; 
 6    
 7    int health = 100;
 8    
 9    // If you create a huge array here, you get a "Stack Overflow"
10    // double hugeArray[1000000]; // <--- CRASH
11}

7b. The Heap. Slow, manual but large #

Also called the “Free Store”, a giant pool of unstructured memory

• Allocation is slow. When calling new or malloc, the OS has to search through The Heap to find a continous block of empty memory that fits the request. This takes time
• Deallocation is slow and manual, must explicity call delete or free
• Lifetime persists until explicitly destroy it
• Size limit depends on the physical RAM

 1void CreateLevel() {
 2    // Heap Allocation
 3    // 1. Slower (OS has to find space).
 4    // 2. Must be manually deleted.
 5    Enemy* boss = new Enemy(); 
 6    
 7    // ... game runs ...
 8    
 9    delete boss; // If you forget this -> Memory Leak.
10}

7c. “Game Loop” #

Never allocate on The Heap, inside the main Game Loop (Tick()/Update()). Why?

• new is slow. Doing it 60 times/second (or 1000x a frame for particle systems, perhaps) definitely kills framerate
• Fragmentation, imagine The Heap as a block of Swiss Cheese
  • Allocate 10 bytes, then 20, then 10
  • You delete the middle (20 bytes one)
  • You now have a “hole”
  • If you then later try to allocate 30 bytes, you can’t fit it in the hole. You have to go to the end and then re-allocate
  • Over hours of gameplay, The Heap becomes a mess of tiny holes (fragmentation), and eventually could cause an out of memory crash even if you technically still have free RAM

Then, when should we use Heap? Use heap for large assets, like textures or levels or objects that need to live longer than the current function scope

However, avoid Heap allocation inside game loop calls to prevent fragmentation and CPU spikes. For temporary data in a frame, prefer the stack

7d. Smart Pointers (Modern C++) #

Since manual delete calls are error-prone, Modern C++ (>= C++11) introduced smart pointers

1. std::unique_ptr

• Owns the object exclusively, when the pointer goes out of scope, it automatically calls delete on the object
• Overhead is almost zero, it’s just a wrapper around a raw pointer
• I’d suggest to use this by default for heap objects

 1#include <memory>
 2
 3void SpawnEnemy() {
 4    // Creates an Enemy on the heap, wrapped in a unique_ptr
 5    std::unique_ptr<Enemy> e = std::make_unique<Enemy>();
 6    
 7    e->Attack();
 8    
 9    // No need to call delete! 
10    // When 'e' goes out of scope here, the Enemy is deleted.
11}

2. std::shared_ptr

• Multiple pointers can own the same object. The object is only deleted when the last pointer looking at it dies
• Overhead is high since it maintains a “reference count” (internally, an int) that must be thread-safe (atomic). Every time you copy the pointer, it has to ++ or – the counter
• I’d suggest to use this sparingly, only when ownership is truly shared. E.g., texture used by 50 different models. The texture should die when all 50 models are gone

7e. The “Pointer-chasing” problem #

Connects to a topic called Cache locality

• In stack, data is usually contigous (next to each other). CPU loves this. It loads a “Cache Line” (typically 64 bytes) and gets all your variables at once
• In heap, the data is scattered randomly
  • If you have a std::vector<Enemy*>, the vector is just a list of ptrs
  • To update enemy 1, the CPU jumps address to address A
  • To update enemy 2, the CPU jumps address to address B
  • This jumping causes Cache misses, which are very slow

Prefer contigous memory as much as possible, like std::vector<Enemy> instead of std::vector<Enemy*> because it keeps the data close togehter and avoids “Pointer Chasing” on The Heap.

7f. Pro-gamer move: “Memory Arena” #

The concept: Heap size, Stack speed

Now that we know that standard heap allocation is slow and causes fragmentation, while stack allocation is fast but the stack is too small - there’s a neat trick that carries the best of both worlds called Memory Arena

• You allocate a huge block of memory on The Heap at startup, e.g., 100MB
• You manage this block yourself, using a simple pointer
• To “allocate” an object, you just move the pointer forward
• To “free” memory, you don’t delete individual objects. Just reset the pointer to the start

Essentially this makes it so that:

• Allocating is just an integer addition, O(1), no OS overhead - fast
• Since you allocate objects one after another, they sit next to each other in RAM (cache locality)
• No fragmentation, since you immediately fill the block linearly, no holes
• Instant cleanup since we can free objects contained in the arenas by setting Head = 0

The Trap: Destructors Reset() effectively frees the memory, but it does not call destructors

• If you store POD (Plain Old Data, like int, Vector3, Matrix), this is fine
• If you store complex objects (like std::vector or std::string) inside the arena, the object wrapper is freed, but the memory it allocated internally is leaked forever

The Fix: Only use Arenas for POD types, or manually call the destructor p->~T() before resetting

 1#include <cstddef>
 2#include <cstdint>
 3#include <iostream>
 4
 5class MemoryArena {
 6private:
 7    uint8_t* MemoryBlock; // The big chunk of memory
 8    size_t Size;          // Total size (e.g., 100MB)
 9    size_t Offset;        // Current "Head" position
10
11public:
12    // 1. Startup: Allocate the big block once (using malloc/new)
13    MemoryArena(size_t sizeBytes) : Size(sizeBytes), Offset(0) {
14        MemoryBlock = new uint8_t[sizeBytes]; 
15    }
16
17    // 2. Shutdown: Free the big block
18    ~MemoryArena() {
19        delete[] MemoryBlock;
20    }
21
22    // 3. Allocate: The "Pointer Bump"
23    void* Alloc(size_t sizeBytes) {
24        // Check if we have space
25        if (Offset + sizeBytes > Size) {
26            return nullptr; // Out of memory!
27        }
28
29        // Get the pointer to the current free spot
30        void* ptr = &MemoryBlock[Offset];
31
32        // Move the head forward
33        Offset += sizeBytes;
34
35        return ptr;
36    }
37
38    // 4. Deallocate: The Magic Reset
39    // We don't free individual items. We wipe everything at once.
40    void Reset() {
41        Offset = 0;
42    }
43};
44
45
46// Usage in game loop
47
48struct Particle { float x, y; }; // POD type: Safe!
49
50int main() {
51    MemoryArena FrameArena(1024 * 1024); 
52
53    while (GameIsRunning) {
54        FrameArena.Reset(); 
55
56        for (int i = 0; i < 1000; i++) {
57            // Placement new
58            void* mem = FrameArena.Alloc(sizeof(Particle));
59            Particle* p = new(mem) Particle(); 
60        }
61        Render();
62    }
63}

When to use this? I found several useful case that benefits from this trick:

1. Frame allocator I used a linear memory arena for temporary data that only needs to exist for one frame. E.g., UI text meshes, temp arrays for physics queries or debug drawing lines. At the end of the frame, I just call Reset() lol

2. Level allocator When loading a level, I typically allocate all assets (textures, meshes, etc.) into a specific arena. When the player leaves the level, I don’t have to track down every single texture to delete it. I just destroy the entire level arena. Effectively doing instant cleanup and guarantees zero memory leaks between levels

Important note

Since Alloc() returns a void* (raw memory), the constructor is not called automatically. We need to use something called Placement New

• Standard new Player() -> allocates memory AND calls constructor
• Placement New new(ptr) Player() -> uses EXISTING memory ptr and calls constructor there

1void* mem = Arena.Alloc(sizeof(Enemy));
2Enemy* e = new(mem) Enemy(); // Construct the enemy in our arena

The Trap: Alignment If you allocate a char (1 byte) and then immediately allocate an int (4 bytes), the int might end up at memory address 0x01. This is unaligned. On x86 CPUs, this is slow. On ARM (Mobile/Switch), this crashes the game

The Fix: We must align the pointer before returning it

 1#include <cstddef>
 2#include <cstdint>
 3#include <memory> // for std::align
 4
 5class MemoryArena {
 6private:
 7    uint8_t* MemoryBlock; 
 8    size_t Size;          
 9    size_t Offset;        
10
11public:
12    MemoryArena(size_t sizeBytes) : Size(sizeBytes), Offset(0) {
13        MemoryBlock = new uint8_t[sizeBytes]; 
14    }
15
16    ~MemoryArena() {
17        // WARNING: This does NOT call destructors for objects inside!
18        // Only use Arena for POD (Plain Old Data) or manually call destructors before resetting.
19        delete[] MemoryBlock;
20    }
21
22    void* Alloc(size_t sizeBytes, size_t alignment) {
23        // 1. Calculate current address
24        uintptr_t currentPtr = (uintptr_t)MemoryBlock + Offset;
25        
26        // 2. Calculate padding needed to align this address
27        // Example: Address is 1, alignment is 4. We need 3 bytes padding.
28        size_t padding = (alignment - (currentPtr % alignment)) % alignment;
29
30        // 3. Check space
31        if (Offset + padding + sizeBytes > Size) {
32            return nullptr; 
33        }
34
35        // 4. Apply padding and return aligned pointer
36        Offset += padding;
37        void* ptr = &MemoryBlock[Offset];
38        Offset += sizeBytes;
39        
40        return ptr;
41    }
42
43    void Reset() { Offset = 0; }
44};
45
46// Usage
47// alignof(T) gets the required alignment for a type
48void* mem = Arena.Alloc(sizeof(Enemy), alignof(Enemy));
49Enemy* e = new(mem) Enemy();

8. Common C++ containers #

Choosing the right container is often a choice between “easy to write” vs “runs fast”. Understanding of Big O notation and CPU cache behavior is important

8a. std::vector #

Under the hood this is just a dynamic array. It allocates a contigous block of memory on The Heap

• Performance:
  • Random access via v[i]: O(1)
  • Insertion at the end via push_back(): O(1) amortized, usually fast but slow when need to resize
  • Insertion/Deletion in Middle: O(n), since it has to shift all subsequent elements in memory
• CPU loves it. Since it’s a contigous memory. The data sits side-by-side, thus the CPU loads it into the cache efficiently. Iterating through a vector is the fastest thing a CPU can do

reserve() trick

When a vector fills up, it has to:

• Allocate a new, bigger block of memory (usually 2x current size)
• Move or Copy everything from the old block to the new one.
• The Trap: std::vector will only Move (fast) if your Move Constructor is marked noexcept. If it isn’t, C++ falls back to Copying (slow) to guarantee exception safety.
• Delete the old block

This is slow. By reserving a certain number of elements in the array, we’ll avoid reallocation.

1std::vector<Enemy> enemies;
2enemies.reserve(100); // No reallocation for the first 100 items.

It’s also a good idea to mark your Move Constructor as noexcept though:

1class Particle {
2public:
3    // FAST: Vector will move this when resizing
4    Particle(Particle&& other) noexcept { ... }
5
6    // SLOW: Vector will COPY this when resizing because it's not safe to move
7    Particle(Particle&& other) { ... } 
8};

Usage example: Entity Manager

Say you have a list of enemies, bullets or particles. You need to update them every single frame, and need maximum iteration speed

 1struct Enemy {
 2    int id;
 3    float health;
 4    void Update() { /* AI logic */ }
 5};
 6
 7class EnemyManager {
 8    // CHOICE: vector because we iterate this 60 times a second.
 9    // The contiguous memory means the CPU cache stays hot.
10    std::vector<Enemy> enemies;
11
12public:
13    void InitLevel(int enemyCount) {
14        // OPTIMIZATION: Reserve memory upfront to prevent resizing lag spikes.
15        enemies.reserve(enemyCount); 
16        
17        for(int i = 0; i < enemyCount; i++) {
18            enemies.push_back(Enemy{i, 100.0f});
19        }
20    }
21
22    void UpdateAll() {
23        // Fast iteration
24        for (auto& e : enemies) {
25            e.Update();
26        }
27    }
28};

• Why not List? A list would scatter enemies across memory, causing cache misses every time we move to the next enemy
• Why not Map? We don’t need to look them up by ID here, just need to process all of them

8b. std::list #

This is a doubly linked list. Each node contains the data + a pointer to the next node + a pointer to the previous node

• Performance
  • Random access via l[i]: O(n), terrible. Since you have to walk the chain from the start to find the nth element
  • Insertion/Deletion: O(1), you just change the pointer. However, you have to find the spot first (which takes O(n))
• CPU hates it. Prone to cache misses since the nodes are scattered all over the heap. Iterating a list is significantly slower than a vector because the CPU has to wait for memory fetches constantly
• Use this only when you need to frequently insert/remove items from the middle of the sequence and you already have a pointer to that location

Usage example: Status effect system

Say a player might have “Poison”, “Regen” and “Stun” effects active. The effects expire at different times and with a random order. We frequently need to delete an effect from the middle of the list when its timer runs out

 1struct StatusEffect {
 2    std::string name;
 3    float duration;
 4};
 5
 6class Player {
 7    // CHOICE: list because we delete from the middle frequently.
 8    // Removing an item from a list is just rewiring pointers (cheap).
 9    // Removing from the middle of a vector requires shifting all data (expensive).
10    std::list<StatusEffect> activeEffects;
11
12public:
13    void AddEffect(std::string name, float time) {
14        activeEffects.push_back({name, time});
15    }
16
17    void TickEffects(float deltaTime) {
18        auto it = activeEffects.begin();
19        while (it != activeEffects.end()) {
20            it->duration -= deltaTime;
21            
22            if (it->duration <= 0) {
23                // Efficient removal from middle (No data shifting)
24                it = activeEffects.erase(it); 
25            } else {
26                ++it;
27            }
28        }
29    }
30};

• Why not Vector? If you have 50 effects and remove index 0, a vector has to shift the other 49 items down one slot. A list just updates two pointers

8c. std::map #

Under the hood, it’s usually a Red-Black Tree (Binary Search Tree) that keeps elements sorted by key

Performance typically is O(log n) for lookups, insertions and deletions

Use this when you need the data to be sorted

Usage example: Event Timeline / Replay System

Say you want to store game events (player jumped, enemy died, etc.) keyed by the Time they occured. You need to process them strictly in chronological order

 1struct GameEvent {
 2    std::string action;
 3    int actorID;
 4};
 5
 6class ReplaySystem {
 7    // CHOICE: map because it automatically sorts by Key (Time).
 8    // float = Time (Key), GameEvent = Data (Value)
 9    std::map<float, GameEvent> timeline;
10
11public:
12    void RecordEvent(float time, std::string action, int id) {
13        // Insertions are O(log n), but they are automatically sorted.
14        timeline[time] = {action, id};
15    }
16
17    void Playback() {
18        // Iterating a map ALWAYS goes from smallest Key to largest Key.
19        for (const auto& pair : timeline) {
20            float time = pair.first;
21            const GameEvent& evt = pair.second;
22            
23            std::cout << "At " << time << "s: " << evt.action << "\n";
24        }
25    }
26};

8d. std::unordered_map #

Under the hood, it’s a hash table. It hashes the Key to find a “bucket”. Unlike std::map, the elements are stored in random order

Performance typically O(1), faster than std::map

There’s a catch though, if many keys hash to the same bucket (collision), performance degrades to O(n). Also, calculating the Hash takes time

Usage example: Asset Manager (Texture Cache)

Say you need to load a texture by its filename. You don’t care about the alphabetical order of files; you just want say “Give me Hero.png”, and get it instantly

 1class Texture { /* ... heavy image data ... */ };
 2
 3class AssetManager {
 4    // CHOICE: unordered_map for O(1) lookup speed.
 5    // Key = Filename (string), Value = Pointer to Texture
 6    std::unordered_map<std::string, Texture*> textureCache;
 7
 8public:
 9    Texture* GetTexture(std::string filename) {
10        // 1. Check if we already loaded it (Fast lookup)
11        auto it = textureCache.find(filename);
12        
13        if (it != textureCache.end()) {
14            return it->second; // Found it! Return existing.
15        }
16
17        // 2. Not found, load from disk (Slow)
18        Texture* newTex = new Texture(); // (Pseudo-code loading)
19        textureCache[filename] = newTex;
20        return newTex;
21    }
22};

8e. std::array #

This is a fixed-size array that lives on The Stack, usually.

• Syntax: std::array<int, 5> myArr;
• Performance is identical to a raw C-Array (int myArr[5])
• Use this over raw C-Array since it adds safe and handy features like .size() for capacity check and .at() for bounds checking, without any neglible performance cost

Usage example: Equipment Slots

 1class PlayerEquipment {
 2public:
 3    enum Slot { HEAD, CHEST, LEGS, FEET, COUNT };
 4
 5    // CHOICE: array because the size is known at compile time (4 slots).
 6    // It lives on the Stack (inside the class), avoiding Heap allocation overhead.
 7    std::array<int, Slot::COUNT> itemIDs;
 8
 9    PlayerEquipment() {
10        // Safe filling
11        itemIDs.fill(0); 
12    }
13
14    void Equip(Slot s, int id) {
15        // .at() provides bounds checking (throws error if s is invalid)
16        // unlike raw C-arrays which would just overwrite random memory.
17        itemIDs.at(s) = id; 
18    }
19};

• Why not Vector? A vector would allocate heap memory for just 4 integers. That’s wasteful.

8f. Pro-gamer move: Swap-and-Pop array (Unordered array/Swapback array) #

As described above, deleting an object from a std::vector without reserve()-ing it ahead of time is inefficient. The following container is a simple workaround, albeit with a glaring downside

If you don’t care about the order of elements, you can use a technique called Swap-and-Pop

• The technique:

  • Take the last element in the array
  • Copy/Move it into the slot of the dead element
  • Delete the last element (cheap!)

• Cost: O(1), moved exactly one object

• Use this when:

  • Order doesn’t matter. E.g., particle system, pool of active enemies, list of SFXs, etc.
  • Frequent deletions, you add and remove items constantly every frame

• Don’t use this when:

  • Order matters. E.g., rendering layer. Don’t show background layer on after UI layer and vice versa
  • Indices are cached externally. If another system holds “index 5” to refer to a specific enemy, and you swap a different enemy into index 5, the other system will now point to the wrong enemy

Implementation:

 1// We can implement this as a wrapper around std::vector
 2
 3#include <vector>
 4#include <cassert>
 5
 6template <typename T>
 7class SwapbackArray {
 8private:
 9    std::vector<T> data;
10
11public:
12    // Standard access
13    T& operator[](size_t index) { return data[index]; }
14    const T& operator[](size_t index) const { return data[index]; }
15    size_t size() const { return data.size(); }
16    
17    // O(1) Insertion (Same as vector)
18    void push_back(const T& value) {
19        data.push_back(value);
20    }
21
22    // THE MAGIC: O(1) Removal
23    void remove_at(size_t index) {
24        assert(index < data.size());
25
26        // 1. Overwrite the item to be removed with the last item
27        // We use std::move to be efficient if T is a complex object
28        data[index] = std::move(data.back());
29
30        // 2. Remove the last item (now that it has been moved)
31        // pop_back on a vector is O(1)
32        data.pop_back();
33    }
34};
35
36// Usage example: A particle system. We iterate through particles. If one dies, remove it instantly without breaking the loop or shifting memory
37
38struct Particle {
39    float lifeTime;
40    float x, y;
41};
42
43int main() {
44    SwapbackArray<Particle> particles;
45
46    // Spawn 10,000 particles
47    for(int i=0; i<10000; i++) {
48        particles.push_back({10.0f, 0, 0});
49    }
50
51    // Update Loop
52    // NOTICE: We iterate BACKWARDS or handle the index carefully
53    // because swapping changes the current index!
54    for (size_t i = 0; i < particles.size(); /* no increment here */) {
55        
56        Particle& p = particles[i];
57        p.lifeTime -= 0.016f; // DeltaTime
58
59        if (p.lifeTime <= 0) {
60            // O(1) Removal
61            // The particle at 'i' is replaced by the last particle.
62            // We do NOT increment 'i', because we need to process 
63            // the *new* particle that just got swapped into this slot.
64            particles.remove_at(i);
65        } else {
66            // Only increment if we didn't remove
67            ++i;
68        }
69    }
70    
71    return 0;
72}

8g. Iterator Invalidation #

What happens to iterators when you modify a container?

Say you’re looping through a vector of enemies, and you decide to delete one

1std::vector<int> numbers = {1, 2, 3, 4, 5};
2
3for (auto it = numbers.begin(); it != numbers.end(); ++it) {
4    if (*it == 3) {
5        numbers.erase(it); // <--- CRASH / Undefined Behavior
6        // The 'erase' function invalidates the iterator 'it'.
7        // The loop then tries to do '++it' on a dead iterator.
8    }
9}

The fix:

1for (auto it = numbers.begin(); it != numbers.end(); /* empty */) {
2    if (*it == 3) {
3        it = numbers.erase(it); // Update 'it' to the next valid element
4    } else {
5        ++it; // Only increment if we didn't delete
6    }
7}

9. Strings #

9a. Cost of std::string #

Unlike an int (which is just 4 bytes on stack), a std::string is a complex object

• Heap allocation: If the text is long, std::string calls new to store the characters on The Heap
• Copying is expensive (std::string a = b;) usually triggers a heap allocation and memory copy (memcpy)
• When the string goes out of the scope, it calls delete

The following code allocates and frees memory every single frame (60 times/sec). This causes heap fragmentation and CPU overhead. We should cache the string or use a fixed-size buffer

1void UpdateHUD(int score) {
2    // 1. Converts int to string (allocation)
3    // 2. Creates "Score: " (allocation)
4    // 3. Concatenates them (allocation + copy)
5    std::string text = "Score: " + std::to_string(score); 
6    
7    RenderText(text);
8} // text is destroyed (deallocation)

9b. SSO (Small String Optimization) #

This is a compiler optimization in std::string. To avoid the expensive heap allocation for short strings like “Name”, “HP”, “Ammo”, std::string has a small internal buffer (typically 15-22 chars) directly inside the object itself

• Short string (< 16 chars) -> stored on The Stack, inside the object itself. Fast, no new/delete
• Long string (> 16 chars) -> stored on The Heap, slow

Keep frequently used strings, like obj names or tags short enough to fit in SSO so it can avoid heap allocation

9c. const char* vs std::string vs std::string_view #

1.const char*, the C-Style String #

• Just a pointer to a read-only array of chars ending in a null terminator \0
• Zero overhead, it’s just a pointer (8 bytes)
• Unsafe, since you don’t know the size. Have to use strlen() to find the length, which is O(n)

2. std::string #

• Safe, easy to resize, owns the memory
• It’s heavy since it does allocations
• Use this when you need to store or modify texts

3. std::string_view #

• A lightweight wrapper that looks at an existing string, either char* or std::string without actually copying it. Consists of just a pointer and a length
• Use this for function parameters

 1// BAD: Copies the string (Heap allocation if long)
 2void ProcessName(std::string name) { ... }
 3
 4// BETTER: Pass by const reference (No copy, but requires a std::string input)
 5void ProcessName(const std::string& name) { ... }
 6
 7// BEST (C++17): Accepts "char*" OR "std::string" with ZERO copies/allocations
 8void ProcessName(std::string_view name) { 
 9    if (name == "Player") { ... } // Fast comparison
10}

9d. String Hashing #

Comparing strings ("Player" == "Player") is slow. It has to check every character; P == P, l == l, etc. This is O(n), where n is the length of the string

Hashing/interning is used to get around this. In Unreal , we convert strings into integers (Hashes)

• “Player” -> Hash function -> 0xA1B2C3D4
• “Enemy” -> Hash function -> 0xE5F6G7H8

Then the comparison becomes: if (0xA1B2C3D4 == 0xE5F6G7H8), just a single integer comparison. O(1), extremely fast

In UE, FName is a hashed string. It is case-insensitive and immutable. It is used to identify assets, bones and sockets cz comparison is instant

9e. snprintf() / fmt() for Formatting #

Concatenating strings with + is slow and messy

std::string s = "Health: " + std::to_string(hp) + " / " + std::to_string(maxHp);

Better alternatives:

snprintf (C-Style). Fast, writes to a stack buffer #

1char buffer[64];
2snprintf(buffer, sizeof(buffer), "Health: %d / %d", hp, maxHp);

std::format (C++20). Type-safe, fast and modern #

1std::string s = std::format("Health: {} / {}", hp, maxHp);

10. Alignment and Padding #

10a. CPU word size #

The CPU reads memory in chunks, not byte-by-byte

• A 64-bit CPU wants to read data from addresses that are multiples of 8 (64 bits)
• A 32-bit integer wants to live at an address that is divisible by 4

If you put a 4-byte int at address 0x01 instead of 0x00 or 0x04, the CPU has to do extra work (two reads + bit shifting) to get that number

This is called Unaligned Access. To prevent this, the compiler automatically inserts Padding (empty bytes)

10b. Padding visualizatoin #

Let’s look at the following struct. You might think the size is just the sum of its parts. It’s not

Naive struct:

1struct BadStruct {
2    char a;     // 1 byte
3    // --- 3 bytes of PADDING inserted here ---
4    int b;      // 4 bytes (Needs 4-byte alignment)
5    char c;     // 1 byte
6    // --- 3 bytes of PADDING inserted here ---
7    // Total Size: 1 + 3 + 4 + 1 + 3 = 12 bytes
8};

• int b needs to start at an address divisible by 4. Since char a only took 1 byte, the compiler adds 3 junk bytes so b starts at offset 4
• We’re wasting 6 bytes due to padding (50%!)

Nicely packed struct:

1struct GoodStruct {
2    int b;      // 4 bytes
3    char a;     // 1 byte
4    char c;     // 1 byte
5    // --- 2 bytes of PADDING at the end ---
6    // Total Size: 4 + 1 + 1 + 2 = 8 bytes
7};

The key is to reorder variables from largest to smallest. Doing so, we reduced the size from 12 bytes -> 8 bytes

This looks like it won’t matter that much, but consider if you have an array of 1.000.000 particles,

• BadStruct -> 12MB RAM usage
• GoodStruct -> 8MB RAM usage

We saved 4MB of RAM usage and significantly reduced the number of times the CPU has to fetch data from main memory due to fewer cache misses

10c. alignof and sizeof #

Consider the following:

1std::cout << sizeof(BadStruct); // Output: 12
2std::cout << alignof(BadStruct); // Output: 4 (Because the largest member is an int)

The alignment of a struct is usually equal to the alignment of its largest member

10d. Cache lines (the 64-byte rule) #

Modern CPUs fetch memory in “Cache Lines”, typically 64 bytes

• When you ask for Variable A, the CPU fetches Variable A + the next ~60 bytes of data automatically
• The key here is you want your struct to fit nearly inside a cache line so CPU gets everything in one go

Important note:

There’s a condition called False sharing, where 2 threads are writing to 2 different variables that happen to sit on the same cache line. The CPU cores fight over that cache line, causing massive slowdowns

To fix this, use alignas(64) to force a variable to start on a new cache line

1struct ThreadSafeCounter {
2    alignas(64) int counterA; // Thread 1 uses this
3    alignas(64) int counterB; // Thread 2 uses this
4    // Now they are far apart in memory. No fighting.
5};

10d. SIMD (Single Instruction, Multiple Data) alignment (vectorization) #

SIMD concept #

If you are doing heavy math (physics, graphics), you might use SIMD (Single Instruction, Multiple Data) instructions (SSE/AVX)

• These instructions operate on 4 floats at once (128 bits) or 8 floats (256 bits)
• It is important that the data must be aligned to 16 bytes (for SSE) or 32 bytes (for AVX). Otherwise, the program might crash

UE uses this internally inside FVector, often aligned specifically to allow fast math operations

Normal C++ code is SISD (Single Instruction, Single Data)

float c = a + b;, simple enough - one addition

Alignment requirement #

To load data into these special registers efficiently, the memory address must be a multiple of the register size (typically 16 bytes for SSE)

• Aligned load via _mm_load_ps: Fast. Requires the addrress to end in 0, 10, 20, etc. (Hex!). Crashes if address is wrong
• Unaligned load via __mm_loadu_ps: Historically slower, but on modern CPUs (Haswell and newer), the performance penalty is negligible. It is safe to use on any address
• The Crash: The real danger isn’t speed, it’s using an Aligned instruction on Unaligned memory (e.g., address ending in 0x04). The CPU throws a hardware exception and the game crashes instantly

Concrete example, the vector class #

The “Normal” Class (Dangerous for SIMD):

 1struct Vector4 {
 2    float x, y, z, w; 
 3    // Size: 16 bytes.
 4    // Alignment: 4 bytes (because 'float' needs 4-byte alignment).
 5};
 6
 7void Math() {
 8    // This might be allocated at address 0x1004.
 9    Vector4 v; 
10}

The “SIMD-Ready” Class:

 1// We use the alignas keyword (C++11) to force the compiler to pad the memory so it always starts on a 16-byte boundary.
 2
 3#include <immintrin.h> // Header for SIMD intrinsics (SSE/AVX)
 4
 5// Force this struct to always start at a memory address divisible by 16
 6struct alignas(16) Vector4SIMD {
 7    float x, y, z, w;
 8};
 9
10void FastAdd(Vector4SIMD* a, Vector4SIMD* b, Vector4SIMD* result) {
11    // 1. Load data from RAM into 128-bit CPU Registers
12    // _mm_load_ps REQUIRES 16-byte alignment.
13    // If we didn't use alignas(16) above, this line would CRASH.
14    __m128 vecA = _mm_load_ps(&a->x); 
15    __m128 vecB = _mm_load_ps(&b->x);
16
17    // 2. Do the math (Add 4 floats at once)
18    __m128 vecRes = _mm_add_ps(vecA, vecB);
19
20    // 3. Store back to RAM
21    _mm_store_ps(&result->x, vecRes);
22}

Heap allocation gotcha #

alignas(16) works perfectly for variables on the Stack or Global variables. The compiler handles it

However, if you use new:

Vector4SIMD* ptr = new Vector4SIMD();

The standard new operator does not guarantee 16-byte alignment on all platforms, especially older Windows versions. It might give you an address ending in 8

The fix:

Override the new and delete operators for your class to use _aligned_malloc for Windows or posix_memalign for Linux/Consoles

 1struct alignas(16) Vector4SIMD {
 2    float x, y, z, w;
 3
 4    // Override new to ensure heap allocation is aligned
 5    void* operator new(size_t i) {
 6        return _aligned_malloc(i, 16);
 7    }
 8
 9    void operator delete(void* p) {
10        _aligned_free(p);
11    }
12};

11. V-Table, or how Virtual Functions work #

How does the computer actually know which function to call at runtime?

When a class has at least one virtual function, the compiler secretly adds a hidden pointer to the class called the vptr (vritual pointer). This points to a static table in memory called vtable (virtual table)

• The vtable is an array of function pointers, shared by all objects of that class
• The cost:
  • Memory, every object gets 8 bytes larger (on 64-bit systems) to hold the vptr
  • Performance, calling a virtual function requires an extra memory lookup. Dereferencing vptr -> finding function address -> actually calling it. Again, this could cause cache miss due to indirect lookup. This also prevent compiler from inlining the function

Then, every function shouldn’t be virtual. Because of the overhead explained above

1class Base {
2    int x;
3    virtual void Bark() {} // <--- Causes creation of vtable
4};
5
6// Memory Layout of 'Base' object:
7// [ vptr ] (8 bytes) -> Points to Base::vtable
8// [  x   ] (4 bytes)
9// [ pad  ] (4 bytes)

12. C++ casting #

In games, you constantly have a generic pointer (e.g., AActor* in Unreal or GameObject in Unity) and you need to cast it to a specific class (e.g., Player*)

12a. static_cast<T> #

I like to call this the “I know what I’m doing” cast lol

• When? Compile-time check. Used when you are 100% sure the types are compatible (e.g., float to int, or Base to Derived if you are certain).
• Cost is free, zero runtime overhead
• Danger: If you cast a generic Enemy* to Boss*, but it was actually a Minion*, the game will crash or have a corrupted memory

12b. dynamic_cast<T> #

This is the “safety check” cast

• When? Runtime check. Used when you don’t know what the object is
• If the cast is illega, it returns nullptr
• Cost is slow, since it relies on RTTI (Run-time type information). It has to crawl through the class hierarchy string names to check compatibility
• Many game engines like UE disable RTTI for performance and provide their own version Cast<T>

12c. const_cast<T> #

• When? To remove the const property
• Red flag: If you use this, you usually designed your architecture wrong

12d. reinterpret_cast<T> #

Or as how I like to call it the “Trust me, bro” cast lol

• When? Treating bits as something else. e.g., Casting a pointer to an integer
• Usage is typically in low-level networking or serialization

12e. Example #

 1void OnHit(Entity* other) {
 2    // BAD: C-Style cast (Hard to search for, unsafe)
 3    // Player* p = (Player*)other; 
 4
 5    // GOOD: Dynamic cast (Safe, but slow)
 6    Player* p = dynamic_cast<Player*>(other);
 7    if (p) {
 8        p->TakeDamage();
 9    }
10    
11    // BEST (In Unreal Engine):
12    // Player* p = Cast<Player>(other); // Uses custom fast casting
13}

13. const correctness #

This is a “character trait”, shows you are disciplined

If a function does not modify the object, it must be marked as const

Why?

• Safety, the compiler will error if you accidentally change a variable inside the function body
• API design, implicitly tells other programmer that “it’s safe to call this function, this won’t break anything since it doesn’t mutate any value”

I typically got caught off-guard about this: const int* vs int* const

• const int* ptr: The data is constant. (You can’t change the value *ptr = 5, but you can move the pointer ptr++)
• int* const ptr: The pointer is constant. (You can change the value *ptr = 5, but you can’t move the pointer ptr++)
• const int* const ptr: Both are constant

 1class Weapon {
 2    int ammo;
 3public:
 4    // This function MUST be const because it just reads data.
 5    int GetAmmo() const { 
 6        // ammo--; // <--- Compiler Error! Good!
 7        return ammo; 
 8    }
 9
10    // This function cannot be const because it changes state.
11    void Fire() { 
12        ammo--; 
13    }
14};
15
16void UpdateUI(const Weapon& w) {
17    // Because 'w' is passed as const reference...
18    std::cout << w.GetAmmo(); // Allowed (GetAmmo is const)
19    // w.Fire(); // Compiler Error! (Fire is not const)
20}

14. Special Member Functions (The Implicit Rules) #

We touched on the Rule of three and five. But you need to know exactly what the compiler generates for you and when it stops doing so

The 6 special members:

1. Default Constructor
2. Destructor
3. Copy Constructor
4. Copy Assignment Operator
5. Move Constructor
6. Move Assignment Operator

The hidden rules:

1. If you declare any constrctor, the compiler stops generating the Default Constructor
2. If you declare a Move operation, be it constructor or assignment, the compiler deletes the Copy operations implicitly

Rule 2 caught me off-guard so many times

Say you write this:

1class Player {
2    int health;
3    std::string name;
4};

Here is the exact code the compiler generates behind the scenes. It performs Member-wise operations

 1class Player {
 2    int health;
 3    std::string name;
 4
 5public:
 6    // 1. Implicit Default Constructor
 7    // It calls the default constructor of every member.
 8    // Note: 'health' (int) is NOT initialized (contains garbage) because it's a primitive.
 9    // 'name' (string) IS initialized to "" because std::string has a constructor.
10    Player() : health(), name() {} 
11
12    // 2. Implicit Destructor
13    // Calls destructors of members in REVERSE order of declaration.
14    ~Player() {
15        // name.~string(); // Called automatically
16        // health (int) has no destructor, so nothing happens.
17    }
18
19    // 3. Implicit Copy Constructor
20    // Copies every member.
21    Player(const Player& other) 
22        : health(other.health), name(other.name) {} 
23
24    // 4. Implicit Copy Assignment Operator
25    Player& operator=(const Player& other) {
26        health = other.health;
27        name = other.name; // Calls std::string::operator=
28        return *this;
29    }
30
31    // 5. Implicit Move Constructor
32    // Casts every member to r-value reference (std::move).
33    Player(Player&& other) 
34        : health(std::move(other.health)), name(std::move(other.name)) {}
35
36    // 6. Implicit Move Assignment Operator
37    Player& operator=(Player&& other) {
38        health = std::move(other.health);
39        name = std::move(other.name); // Calls std::string::operator=(string&&)
40        return *this;
41    }
42};

Typical game engine usage: delete keyword

In games, many object like RenderContext and NetworkSocket should never be copied. You must explicitly disable these functions

 1class Texture {
 2public:
 3    // 1. Allow Default Construction
 4    Texture() = default;
 5
 6    // 2. DISABLE Copying (Unique Asset)
 7    // If someone tries: Texture b = a; -> Compiler Error.
 8    Texture(const Texture&) = delete;
 9    Texture& operator=(const Texture&) = delete;
10
11    // 3. ALLOW Moving (Transfer ownership)
12    Texture(Texture&&) = default;
13    Texture& operator=(Texture&&) = default;
14};

15. CRTP (Curiously Recurring Template Pattern) #

This is a technique to achieve Polymorphism (overriding behavior) without Virtual Functions. Weird, right?

Why it matters? Virtual functions have runtime overhead (vtable lookup). CRTP resolves the function call at Compile Time. It is heavily used in engine math libraries and ECS frameworks

The pattern: The Base class takes the Derived class as a template parameter

class Derived : public Base<Derived> { ... }

 1template <typename Derived>
 2class SpriteBase {
 3public:
 4    void Draw() {
 5        // STATIC POLYMORPHISM
 6        // We cast 'this' to the Derived type at compile time.
 7        // No vtable. No runtime lookup. The compiler inlines this.
 8        static_cast<Derived*>(this)->DrawImplementation();
 9    }
10};
11
12class PlayerSprite : public SpriteBase<PlayerSprite> {
13public:
14    void DrawImplementation() {
15        std::cout << "Drawing Player\n";
16    }
17};
18
19class EnemySprite : public SpriteBase<EnemySprite> {
20public:
21    void DrawImplementation() {
22        std::cout << "Drawing Enemy\n";
23    }
24};
25
26// Usage
27template <typename T>
28void Render(SpriteBase<T>& sprite) {
29    sprite.Draw(); // Calls specific implementation directly
30}

16. SFINAE (Substitution Failure Is Not An Error) #

C++ and their stupid naming. Sounds scary but this is actually useful

It allows you to write functions that only exist for specific types

Why it matters?

You might want a generic Serialize() function, but you’d like it to behave differntly for int, struct, and ptrs. SFINAE lets you enable/disable functions based on the type passed in

 1#include <type_traits>
 2#include <iostream>
 3
 4// Function 1: Only compiles if T is a Floating Point number (float, double)
 5template <typename T>
 6typename std::enable_if<std::is_floating_point<T>::value, void>::type
 7ProcessMath(T value) {
 8    std::cout << "Processing Float: " << value << "\n";
 9}
10
11// Function 2: Only compiles if T is an Integer (int, long)
12template <typename T>
13typename std::enable_if<std::is_integral<T>::value, void>::type
14ProcessMath(T value) {
15    std::cout << "Processing Int: " << value << "\n";
16}
17
18int main() {
19    ProcessMath(10.5f); // Calls Function 1
20    ProcessMath(5);     // Calls Function 2
21    // ProcessMath("String"); // Compiler Error: No matching function found!
22}

17. Concepts (C++20’s replacement for SFINAE) #

In the previous section, we looked at SFINAE (std::enable_if). It is ugly, hard to read, and produces terrifying compiler error messages (often 100 lines of template garbage)

Concepts are the modern replacement. They allow you to specify Constraints on template parameters in plain English

17a. Replacing SFINAE with concepts #

Let’s rewrite the Math example from the previous section

SFINAE code:

1template <typename T>
2typename std::enable_if<std::is_integral<T>::value, void>::type
3Process(T value) { ... }

Concepts code:

 1#include <concepts>
 2
 3// Syntax 1: The "requires" clause
 4template <typename T>
 5requires std::integral<T> // <--- Readable!
 6void Process(T value) {
 7    std::cout << "Processing Int: " << value << "\n";
 8}
 9
10// Syntax 2: Abbreviated Template (Even cleaner)
11void Process(std::floating_point auto value) {
12    std::cout << "Processing Float: " << value << "\n";
13}

17b. Custom Concepts aka. Duck Typing #

You can define a Concept that says: “Look, I don’t care what class this is, as long as it has a Draw() function”.

Define the concept:

1template <typename T>
2concept Renderable = requires(T a) {
3    { a.Draw() } -> std::same_as<void>; // Must have Draw() returning void
4    { a.GetZOrder() } -> std::convertible_to<int>; // Must have GetZOrder() returning int
5};

Using the concept:

 1class Player { 
 2public: 
 3    void Draw() {} 
 4    int GetZOrder() { return 1; }
 5};
 6
 7class SoundManager { 
 8    // No Draw() function
 9};
10
11// This function ONLY accepts types that fit the 'Renderable' concept
12void RenderObject(Renderable auto& obj) {
13    obj.Draw();
14}
15
16int main() {
17    Player p;
18    RenderObject(p); // OK!
19
20    SoundManager s;
21    // RenderObject(s); 
22    // ERROR: "SoundManager does not satisfy concept Renderable. 
23    //        because 'a.Draw()' would be invalid."
24}

18. Template Metaprogramming (TMP) #

Wikipedia calls it “art” of writing code that runs entirely during Compilation. Depending on your use-case though, this might actually complicate things and “muck” the “art”

Why it matters? If you can calculate something at compile time, like Sine Table or a String Hash, the CPU can save cycles at runtime. As they say, “Runtime is expensive, Compile time is free”

In modern C++, we use constexpr. Unlike old C++ that uses recursive templates, starting from C++17 onwards, we use constexpr instead, which look like normal code but runs during compilation

Code example: Compile-time String Hashing As discussed in the String section, game engines typically hashes Strings into integer IDs for faster comparison and indexing. With TMP, we can hash the string "Player.png" into an integer 0xA1B2 while the game is compiling

 1// C++17 constexpr function
 2constexpr uint32_t HashString(const char* str) {
 3    uint32_t hash = 5381;
 4    while (*str) {
 5        hash = ((hash << 5) + hash) + *str; // hash * 33 + c
 6        str++;
 7    }
 8    return hash;
 9}
10
11int main() {
12    // This calculation happens inside the compiler.
13    // The resulting binary just contains the number: 228562779
14    // NO runtime CPU cost.
15    constexpr uint32_t PlayerID = HashString("Player");
16
17    switch(InputID) {
18        case PlayerID: // We can even use it in switch cases!
19            // ...
20            break;
21    }
22}

OOP vs DOD #

A trendy topic. Game engines like Unity with DOTS and UE with Mass Entity are traditionally an OOP engine that attempting to move towards DOD. But why?

1. The fundamental difference #

• OOP, object-oriented. Organizes code around “Things” (Objects)
  • Mental model: A Player is a:
    • Box that contains
      • Health
      • Pos
      • Velocity
      • Update() func
• DOD, data-oriented. Organizes code around “Data” (Arrays)
  • Mental model: There’s arrays of:
    • Healths
    • Positions
    • Velocities
  • Player is just an index in all those arrays

2. The hardware reality (CPU cache) #

• CPU is super fast. While RAM is slow
• When the CPU asks for data, it fetches a Cache Line (64 bytes)
• Your goal is to: if you fetch 64 bytes, you want all 64 bytes to be useful data

The OOP problem (Array of Structs - AoS)

Imagine you have an array of Enemy objects. You’d want to update their positions via Pos += Vel * dt

 1class Enemy {
 2    bool isDead;        // 1 byte (+3 padding)
 3    Vector3 position;   // 12 bytes
 4    Vector3 velocity;   // 12 bytes
 5    int aiState;        // 4 bytes
 6    float health;       // 4 bytes
 7    Texture* sprite;    // 8 bytes
 8    // Total: ~48 bytes per Enemy
 9};
10
11std::vector<Enemy> enemies; // The "Array of Structures"

The loop:

1for (auto& e : enemies) {
2    e.position += e.velocity * dt;
3}

What the CPU sees:

1. Fetch Enemy[0]. We need position and velocity (24 bytes)
2. We also loaded isDead, aiState, health, and sprite into the cache. We don’t need them. That is “Waste
3. Because the struct is large (48 bytes), a 64-byte cache line can only hold 1.3 enemies
4. To update 1000 enemies, we need to fetch from RAM hundreds of times, slow

The DOD approach (Structs of Arrays - SoA)

Instead of one class, we split the data into separate arrays

1struct EnemySystem {
2    std::vector<Vector3> positions;
3    std::vector<Vector3> velocities;
4    std::vector<float> healths;
5    std::vector<int> aiStates;
6};

The loop:

1// We only touch the position and velocity arrays
2for (int i = 0; i < count; i++) {
3    positions[i] += velocities[i] * dt;
4}

What the CPU sees:

1. We load the positions array. It is just Vector3s
2. A 64-byte cache line holds 5.3 positions (12 bytes each)
3. We load the velocities array

We process 4-5x more enemies per RAM fetch and this layout is perfectfor SIMD. Allowing the CPU to update 4 positions at once

3. When to use OOP vs DOD? #

DOD by itself is not a silver bullet. It is harder to write and debug

• Use OOP for:

  • The Main Player (Complex logic, lots of unique state)
  • UI Systems
  • Game Mode / Game State logic
  • Interaction systems (Doors, Chests)

• Use DOD for:

  • 10,000 Zombies
  • Particle Systems
  • Traffic simulation
  • Anything where you have lots of objects doing the same thing

4. Converting OOP -> DOD code example #

OOP style

1class Ball {
2    Vector3 pos, vel;
3public:
4    void Update(float dt) {
5        pos += vel * dt;
6    }
7};
8std::vector<Ball> balls;
9// Update: balls[i].Update(dt); -> Pointer chasing / Cache pollution

DOD style

 1struct BallData {
 2    std::vector<Vector3> positions;
 3    std::vector<Vector3> velocities;
 4};
 5
 6void UpdateBalls(BallData& data, float dt) {
 7    size_t count = data.positions.size();
 8    
 9    // This loop is incredibly fast and auto-vectorizable by the compiler
10    for (size_t i = 0; i < count; ++i) {
11        data.positions[i] += data.velocities[i] * dt;
12    }
13}

4. ECS #

ECS is the formal architectural pattern for Data-Oriented Programming.

• Entity is just an ID (int), e.g., Entity #50

• Component: Pure Data. No functions

  • PositionComponent { x, y, z }
  • VelocityComponent { x, y, z }

• System: The logic itself. Runs on arrays of components

  • MovementSystem: Iterats all Position and Velocity components, and adds them

• ECS uses a ‘Structure of Arrays’ layout which maximizes Cache Locality

• By keeping similar data contiguous in memory, we reduce Cache Misses

• It also decouples logic from data, making it easier to parallelize (multithread) updates because systems don’t have complex dependencies like OOP inheritance trees

Mini, native ECS implementation

  1#include <vector>
  2#include <iostream>
  3
  4// ==========================================
  5// 1. COMPONENTS (Pure Data)
  6// ==========================================
  7struct Position {
  8    float x, y;
  9};
 10
 11struct Velocity {
 12    float x, y;
 13};
 14
 15// ==========================================
 16// 2. THE ECS MANAGER (The "Database")
 17// ==========================================
 18class ECSManager {
 19public:
 20    // DEFINITION OF "ENTITY":
 21    // An Entity is just an index into these arrays.
 22    // Entity 0 is index 0, Entity 1 is index 1.
 23    
 24    // STORAGE (Structure of Arrays - SoA):
 25    // Instead of vector<Object>, we have vectors of data types.
 26    // This ensures contiguous memory for the CPU cache.
 27    std::vector<Position> positions;
 28    std::vector<Velocity> velocities;
 29    
 30    // MASKS:
 31    // We need to know which entity has which component.
 32    // (In a real engine, we'd use a Bitmask, e.g., 0b0011)
 33    std::vector<bool> hasPosition;
 34    std::vector<bool> hasVelocity;
 35
 36    // Create a new "Entity" (Just resizing the arrays)
 37    int CreateEntity() {
 38        positions.emplace_back();
 39        velocities.emplace_back();
 40        hasPosition.push_back(false);
 41        hasVelocity.push_back(false);
 42        return positions.size() - 1; // Return the ID
 43    }
 44
 45    // Add Component Functions
 46    void AddPosition(int entityID, float x, float y) {
 47        positions[entityID] = {x, y};
 48        hasPosition[entityID] = true;
 49    }
 50
 51    void AddVelocity(int entityID, float x, float y) {
 52        velocities[entityID] = {x, y};
 53        hasVelocity[entityID] = true;
 54    }
 55};
 56
 57// ==========================================
 58// 3. THE SYSTEM (The Logic)
 59// ==========================================
 60class MovementSystem {
 61public:
 62    void Update(ECSManager& ecs, float deltaTime) {
 63        // THE PERFORMANCE MAGIC:
 64        // We iterate through raw data arrays. 
 65        // The CPU loads a chunk of Positions, then a chunk of Velocities.
 66        // Very few cache misses compared to jumping between Objects.
 67        
 68        size_t count = ecs.positions.size();
 69
 70        for (size_t i = 0; i < count; ++i) {
 71            // Check if this entity has BOTH components required for movement
 72            if (ecs.hasPosition[i] && ecs.hasVelocity[i]) {
 73                
 74                // Logic: Pos += Vel * dt
 75                ecs.positions[i].x += ecs.velocities[i].x * deltaTime;
 76                ecs.positions[i].y += ecs.velocities[i].y * deltaTime;
 77            }
 78        }
 79    }
 80};
 81
 82// ==========================================
 83// 4. USAGE
 84// ==========================================
 85int main() {
 86    ECSManager ecs;
 87    MovementSystem mover;
 88
 89    // 1. Create Entities
 90    int playerID = ecs.CreateEntity();
 91    ecs.AddPosition(playerID, 0, 0);
 92    ecs.AddVelocity(playerID, 10, 5); // Player moves
 93
 94    int treeID = ecs.CreateEntity();
 95    ecs.AddPosition(treeID, 50, 50); 
 96    // Tree has NO velocity, so the system will skip it
 97
 98    // 2. Game Loop
 99    float dt = 0.016f; // 60 FPS
100    
101    mover.Update(ecs, dt);
102
103    std::cout << "Player Pos: " << ecs.positions[playerID].x << "\n"; // Output: 0.16
104    std::cout << "Tree Pos: "   << ecs.positions[treeID].x   << "\n"; // Output: 50 (Unchanged)
105
106    return 0;
107}

IMPORTANT NOTE

• This is a naive implementation where the Entity ID matches the Array Index
• In a real engine (like EnTT or FLECS), we would use Sparse Sets or Archetypes to handle the fact that not all entities have all components, to avoid wasting memory on empty slots

5. Parallelization #

5a. OOP concurrency problem #

Why is it hard to multithread standard OOP code?

• Hidden Dependencies: Object A might call ObjectB->GetHealth(). If Thread 1 updates Object A and Thread 2 updates Object B, you might get a race condition
• Deadlocks: To fix race conditions, you add Mutexes/Locks. If A locks B, and B locks A, the game freezes
• Pointer Chasing: Threads spend more time waiting for RAM (Cache Misses) than actually doing math

5b. Data parallelism #

In ECS, we have a contiguous array of Positions

• Independence: Updating Position[0] has zero effect on Position[1]
• The Strategy: We don’t need complex locks. We just split the array
  • Core 1: Updates indices 0 to 5,000
  • Core 2: Updates indices 5,001 to 10,000

5c. Code example #

We extend the previous Mini-ECS. We will use C++17 Parallel Algorithms (std::execution::par) to show how trivial this becomes with DOD. In UE, you’d use ParallelFor instead

 1#include <execution> // C++17 Parallel Policies
 2#include <algorithm> // for std::for_each
 3#include <numeric>   // for std::iota
 4
 5class MovementSystem {
 6public:
 7    // 1. Single-Threaded (Old Way)
 8    void UpdateSerial(ECSManager& ecs, float dt) {
 9        for (size_t i = 0; i < ecs.positions.size(); ++i) {
10            ProcessEntity(ecs, i, dt);
11        }
12    }
13
14    // 2. Multi-Threaded (The DOD Way)
15    void UpdateParallel(ECSManager& ecs, float dt) {
16        size_t count = ecs.positions.size();
17        
18        // Helper: Create a vector of indices [0, 1, 2, ... count-1]
19        // We need this to iterate over indices in parallel.
20        std::vector<int> indices(count);
21        std::iota(indices.begin(), indices.end(), 0);
22
23        // EXECUTE IN PARALLEL
24        // std::execution::par tells the compiler: 
25        // "You can split this loop across multiple CPU cores."
26        std::for_each(std::execution::par, indices.begin(), indices.end(), 
27            [&](int i) {
28                // This lambda runs on multiple threads simultaneously.
29                // Because 'i' is unique for every thread, 
30                // we have NO Race Conditions on writing data.
31                ProcessEntity(ecs, i, dt);
32            }
33        );
34    }
35
36private:
37    // The logic is identical, but now thread-safe by design
38    void ProcessEntity(ECSManager& ecs, int i, float dt) {
39        if (ecs.hasPosition[i] && ecs.hasVelocity[i]) {
40            // Read from Velocity (Safe)
41            float vx = ecs.velocities[i].x;
42            float vy = ecs.velocities[i].y;
43
44            // Write to Position (Safe - no other thread touches index 'i')
45            ecs.positions[i].x += vx * dt;
46            ecs.positions[i].y += vy * dt;
47        }
48    }
49};

5d. False Sharing #

There’s a hardware pitfall in the code above

• CPU Cores load memory in Cache Lines (64 bytes)
• Position struct is 8 bytes (float x, y)
• One Cache Line holds 8 Positions (Pos[0]-Pos[7])

Possible scenario:

1. Core 1 tries to write to Pos[0]
2. Core 2 tries to write to Pos[1]
3. They are on the same Cache Line
4. The CPU cores fight over ownership of that cache line. The memory system has to “ping-pong” the cache line between cores Result: Performance is worse than single-threaded code

To fix this, we’re gonna do chunking. Instead of letting the library decide how to split the work, we explicitly divide our array into Chunks (or Blocks)

• Chunk Size: We pick a size (e.g., 1024 items) that is guaranteed to be larger than a Cache Line (64 bytes)
• The Logic: Thread 1 processes items 0-1023. Thread 2 processes 1024 to 2047 The Result: They might fight over the one cache line at the very border (index 1023/1024), but the other 1023 items are processed at maximum speed with zero contention

 1#include <execution>
 2#include <algorithm>
 3#include <vector>
 4#include <numeric>
 5#include <cmath>
 6
 7class MovementSystem {
 8    // ... (Previous UpdateSerial code) ...
 9
10public:
11    // 3. Multi-Threaded with CHUNKING (False Sharing Fix)
12    void UpdateParallelChunked(ECSManager& ecs, float dt) {
13        int totalEntities = ecs.positions.size();
14        
15        // STEP 1: Define a Chunk Size
16        // A Cache Line is 64 bytes.
17        // Position (8 bytes) + Velocity (8 bytes) = 16 bytes per entity.
18        // 4 entities fill a cache line.
19        // We choose 1024 to be extremely safe and reduce overhead.
20        const int CHUNK_SIZE = 1024;
21
22        // STEP 2: Calculate number of chunks needed
23        // (Integer division ceiling trick: (A + B - 1) / B)
24        int numChunks = (totalEntities + CHUNK_SIZE - 1) / CHUNK_SIZE;
25
26        // Create a list of Chunk IDs: [0, 1, 2, ... numChunks-1]
27        std::vector<int> chunkIDs(numChunks);
28        std::iota(chunkIDs.begin(), chunkIDs.end(), 0);
29
30        // STEP 3: Parallelize over CHUNKS, not Entities
31        std::for_each(std::execution::par, chunkIDs.begin(), chunkIDs.end(), 
32            [&](int chunkIndex) {
33                
34                // Calculate the range for this specific thread
35                int start = chunkIndex * CHUNK_SIZE;
36                
37                // Ensure the last chunk doesn't go out of bounds
38                int end = std::min(start + CHUNK_SIZE, totalEntities);
39
40                // STEP 4: Process the Chunk (Serial Loop)
41                // This thread now has exclusive access to this range of memory.
42                // No other thread is writing to indices [start ... end].
43                for (int i = start; i < end; ++i) {
44                    ProcessEntity(ecs, i, dt);
45                }
46            }
47        );
48    }
49
50private:
51    void ProcessEntity(ECSManager& ecs, int i, float dt) {
52        if (ecs.hasPosition[i] && ecs.hasVelocity[i]) {
53            ecs.positions[i].x += ecs.velocities[i].x * dt;
54            ecs.positions[i].y += ecs.velocities[i].y * dt;
55        }
56    }
57};

UE specific notes #

1. Tick() problem #

In Unreal, Tick() is the function that runs every single frame

Even an empty Tick() function has overhead. The engine has to iterate through a list of ticking actors, check if they are paused, check their tick group, and call the function

Imagine you have 1,000 enemies. Each one has a Blueprint with a Tick event checking “Is Player Close?”

• 1,000 checks x 60 FPS = 60,000 checks per second
• This logic runs on the Game Thread. If the Game Thread takes longer than 16.6ms, your FPS drops below 60

Ideally, disbable Tick by default (PrimaryActorTick.bCanEverTick = false;) and only enable it for actors that absolutely need continuous updates (like a homing missile/projectiles)

2. BP vs C++ #

Blueprints (BP) are a scripting language running on a Virtual Machine (VM)

• The Speed Difference: Depending on the complexity, raw C++ is roughly 10x to 100x faster than Blueprint logic
• The slowness comes from the “marshalling” overhead—calling a C++ function from BP requires the VM to translate data types back and forth

When to use which?

• Use C++ for:
  • Heavy math (Physics calculations, procedural generation)
  • Tick() logic (if you must tick)
  • Complex loops (looping 10,000 times in BP is suicide)
  • Core systems (Inventory, Health, Networking)
• Use BP for:
  • One-off events (OnOverlap, OnClicked)
  • Visuals (Timelines, spawning particles, playing sounds)
  • Level Design (referencing specific assets)

Ideally, the workflow should be like this;

• Expose a UFUNCTION(BlueprintImplementableEvent) called OnTakeDamageVisuals() in C++
• The C++ handles the math (subtracting HP), then calls the BP event so the designer can easily add a flash effect or sound without touching code

3. Event-driven architecture #

Instead of checking “Is X happening?” every frame (Polling), wait for the engine to tell you “X happened” (Events)

Bad (Polling in Tick):

1void Tick(float DeltaTime) {
2    // Running this every frame is wasteful
3    if (GetDistanceTo(Player) < 100.0f) {
4        Explode();
5    }
6}

Event-Driven:

1// Use a Collision Component (Sphere/Box). The physics engine is already checking overlaps efficiently using spatial partitioning (Octrees/BVH)
2
3// In Constructor
4SphereComp->OnComponentBeginOverlap.AddDynamic(this, &AMine::OnOverlap);
5
6// Only runs ONCE when the player actually touches the sphere
7void AMine::OnOverlap(...) {
8    Explode();
9}

4. Timers #

If you need to check something periodically (e.g., “Regenerate Health”), do not use Tick. Use a Timer.

1GetWorldTimerManager().SetTimer(RegenHandle, this, &APlayer::RegenHealth, 1.0f, true);

This runs once per second, not 60 times per second. It removes the load from the critical frame loop

5. Significance Manager #

Not all objects are equal. An enemy 5 meters away is “Significant.” An enemy 500 meters away is “Insignificant”

How it works:

• You implement logic to lower the “Tick Rate” based on significance
  • Close: Tick every frame. High quality animation
  • Far: Tick every 10 frames. Disable animation updates. Use lower LOD (Level of Detail) meshes

Use Significance Manager to throttle the tick rate of distant entities, or simply disable their Tick entirely until they come within range

6. Cast vs Interface (Soft Reference) #

This is about Memory Management

The Scenario: You have a PlayerCharacter. You want to interact with a Chest, a Door, and a Lever

1. Approach A: Casting (The “Hard Reference”) If you Cast, you tell the engine: “This Player class knows about the Chest class”

 1// Player.cpp
 2#include "Chest.h" // <--- HARD REFERENCE
 3#include "Door.h"  // <--- HARD REFERENCE
 4
 5void APlayer::Interact(AActor* Target) {
 6    // Try to cast to Chest
 7    AChest* Chest = Cast<AChest>(Target);
 8    if (Chest) {
 9        Chest->Open();
10        return;
11    }
12
13    // Try to cast to Door
14    ADoor* Door = Cast<ADoor>(Target);
15    if (Door) {
16        Door->Open();
17        return;
18    }
19}

When you load Player.uasset (or spawn the C++ class), the engine sees the #include "Chest.h". It says “I need to load the Chest class to know what it is”

• The Chest class references a Gold Texture
• The Chest class references a Wood Sound Just spawning the Player loads the Chest, the Door, the Gold Texture, and the Wood Sound into RAM. Even if there is no chest in the level…

2. Approach B: Interfaces (The “Decoupled” Solution) An Interface is a contract. “I promise I have a function called OnInteract().” The Player doesn’t care who implements it

Step 1: Define the Interface

 1// InteractInterface.h
 2#pragma once
 3#include "CoreMinimal.h"
 4#include "UObject/Interface.h"
 5#include "InteractInterface.generated.h"
 6
 7UINTERFACE(MinimalAPI)
 8class UInteractInterface : public UInterface { GENERATED_BODY() };
 9
10class IInteractInterface {
11    GENERATED_BODY()
12public:
13    // BlueprintNativeEvent allows both C++ and BP to override this
14    UFUNCTION(BlueprintNativeEvent, BlueprintCallable)
15    void OnInteract();
16};

Step 2: Implement in Objects

1// Chest.h
2class AChest : public AActor, public IInteractInterface {
3    // ...
4    virtual void OnInteract_Implementation() override {
5        OpenChestLogic();
6    }
7};

Step 3: Call it from Player (No Casting!)

 1// Player.cpp
 2#include "InteractInterface.h" // Only includes the lightweight interface
 3
 4void APlayer::Interact(AActor* Target) {
 5    // Check if the target implements the interface
 6    if (Target && Target->Implements<UInteractInterface>()) {
 7        
 8        // Execute the function. 
 9        // We don't know if it's a Chest or a Door. We don't care.
10        IInteractInterface::Execute_OnInteract(Target);
11    }
12}

The Result:

• The Player class does not know Chest.h exists
• Loading the Player does not load the Chest textures/sounds
• You save memory usage and reduce load times

Prefer Interfaces for interaction systems to avoid creating hard reference chains. This ensures that loading the Player character doesn’t accidentally load every interactive object in the entire game into memory

7. UE’s UObject Cast<T> #

7a. The Problem: dynamic_cast vs Cast<T> #

In standard C++, dynamic_cast relies on RTTI (Run-Time Type Information)

• Pros: Safe. Returns nullptr if the cast fails
• Cons: Slow. It has to traverse the inheritance tree at runtime
• Unreal: Disables RTTI by default for performance. Therefore, dynamic_cast doesn’t work on UObjects in the standard way

Unreal created its own reflection system to handle this

7b. How Cast<T> Works (The Two-Step Process) #

When you call Cast<AMyActor>(Obj), Unreal does two checks:

Step A: The Fast Path (Class Cast Flags)

For core engine classes (Actor, Pawn, Character, StaticMeshComponent, etc.), Unreal doesn’t even look at the inheritance tree. It checks a Bitmask

Every class has a ClassCastFlags integer.

• CASTCLASS_AActor
• CASTCLASS_APawn

1// Pseudo-code of what happens inside Cast<>
2if (Object->GetClass()->HasAnyCastFlag(TCastFlags<TargetType>::Value)) {
3    return (TargetType*)Object;
4}

Cost: Bitwise AND, extremely fast

Step B: The Generic Path (IsA / IsChildOf)

If you are casting to a custom class (e.g., AMyGameHero) that doesn’t have a dedicated engine flag, Unreal calls IsA<T>(), which calls IsChildOf()

This is where the O(1) magic happens

7c. Performance difference in Editor vs. Shipping #

The implementation of IsChildOf changes depending on your build configuration

In Editor Builds (UE_EDITOR = 1) The engine assumes classes might change at runtime (Hot Reload / Live Coding)

• Algorithm: It walks up the inheritance tree
  • Check this. Is it Target? No
  • Check Super. Is it Target? No
  • Check Super->Super. Is it Target? Yes

Complexity: O(Depth). The deeper your hierarchy, the slower the cast

In Shipping/Game Builds (UE_EDITOR = 0)

The engine knows the class hierarchy is immutable (baked). It generates a StructBaseChainArray for every class

Concept: Every class holds an array of pointers to all its parents Algorithm:

• Get the depth of the Target Class (e.g., Depth 3)
• Check if MyClass.StructBaseChainArray[3] == TargetClass

Complexity: O(1). Constant time. It doesn’t matter if the inheritance depth is 2 or 50; it is a single array lookup

7d. Other Cast Types #

• CastChecked<T>

  • Behavior: Casts the object. If it fails, Crashes the game (Asserts)
  • Performance: In Shipping builds, the check is stripped out. It compiles down to a static_cast (or raw cast), making it effectively free
  • Usage: Use this when you are 100% sure of the type (e.g., inside BeginPlay after spawning a specific blueprint) and you want it to crash during development if you are wrong

• ExactCast<T>

  • Behavior: Checks if the object is exactly that class (not a child)
  • Logic: Object->GetClass() == T::StaticClass()
  • Performance: Always O(1)

So, Cast<T> is not always expensive. It depends on the build configuration

1. Fast Path: If casting to common engine classes like AActor, it uses a Bitmask check, which is instant
2. Generic Path: For custom classes, in the Editor, it walks the inheritance tree (O(Depth)). However, in Shipping builds, Unreal uses a cached StructBaseChainArray to perform the lookup in O(1) constant time

8. Modular Architecture #

8a. The concept #

Unreal Engine is a collection of Modules (Core, Engine, AIModule, etc.). Your game should be too

If you put your Inventory, AI, Combat, and UI all in one module (MyGame):

1. Spaghetti Dependencies: The UI accidentally accesses private AI variables
2. Compile Time: Changing one line in the Inventory header triggers a recompile of the AI and Combat systems
3. No Reuse: You can’t easily copy your Inventory system to your next project

Instead, split features into separate Modules (or Plugins)

• MyGame_Core: Interfaces, Types, Math (Depends on nothing)
• MyGame_Inventory: Inventory Logic (Depends on Core)
• MyGame_Combat: Combat Logic (Depends on Core)
• MyGame_Main: The glue (Depends on Inventory & Combat)

8b. “Clean” dependency rule via Build.cs #

Understand the difference between Public and Private dependencies in the .Build.cs file. This is how you enforce architecture

• PublicDependencyModuleNames: “I expose types from this module in my public headers.” (Transitive)
• PrivateDependencyModuleNames: “I use this module internally, but no one including me needs to know about it.” (Encapsulation)

Example: Your Inventory module uses Slate internally to draw debug info.

• Put Slate in PrivateDependency
• Now, the Combat module (which depends on Inventory) does not automatically link against Slate. This keeps the build lightweight

8c. Concrete example, inventory module #

Folder Structure:

1/Source
2  /MyGame_Inventory
3    /MyGame_Inventory.Build.cs
4    /Public
5      IInventoryInterface.h  <-- The Contract
6      InventoryComponent.h   <-- The Public API
7    /Private
8      InventoryComponent.cpp <-- The Implementation
9      InventoryInternalHelpers.h <-- Hidden from the rest of the game

The Interface (Public/IInventoryInterface.h):

We use an Interface to decouple systems. The UI module doesn’t need to know about the InventoryComponent class, only that something has items

 1#pragma once
 2#include "CoreMinimal.h"
 3#include "UObject/Interface.h"
 4#include "IInventoryInterface.generated.h"
 5
 6UINTERFACE(MinimalAPI)
 7class UInventoryInterface : public UInterface { GENERATED_BODY() };
 8
 9class MYGAME_INVENTORY_API IInventoryInterface {
10    GENERATED_BODY()
11public:
12    virtual int32 GetItemCount(FName ItemID) const = 0;
13    virtual bool AddItem(FName ItemID, int32 Amount) = 0;
14};

The Build File (MyGame_Inventory.Build.cs):

 1public class MyGame_Inventory : ModuleRules
 2{
 3    public MyGame_Inventory(ReadOnlyTargetRules Target) : base(Target)
 4    {
 5        // Expose the Interface to other modules
 6        PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine" });
 7        
 8        // Internal logic only
 9        PrivateDependencyModuleNames.AddRange(new string[] { "Slate", "SlateCore" }); 
10    }
11}

9. Automation testing #

9a. Unit testing #

Unreal has a built-in testing framework. You should write Unit Tests for pure C++ logic (like math or inventory calculations) that doesn’t require spawning an Actor in a world

 1// File: Private/Tests/InventoryTests.cpp
 2
 3#include "Misc/AutomationTest.h"
 4#include "InventoryComponent.h"
 5
 6// Define the test: "MyGame.Inventory.AddItem"
 7// Flags: EditorContext (Runs in Editor), EngineFilter (Standard test)
 8IMPLEMENT_SIMPLE_AUTOMATION_TEST(FInventoryAddItemTest, "MyGame.Inventory.AddItem", EAutomationTestFlags::EditorContext | EAutomationTestFlags::EngineFilter)
 9
10bool FInventoryAddItemTest::RunTest(const FString& Parameters)
11{
12    // 1. Arrange (Setup)
13    // Since UComponents usually need an Owner, we might test a plain C++ struct helper here
14    // Or create a temporary object if possible.
15    // For this example, let's assume we have a helper struct 'FInventoryContainer'.
16    FInventoryContainer Container;
17    
18    // 2. Act (Execute)
19    Container.AddItem("Sword", 1);
20    Container.AddItem("Sword", 2);
21
22    // 3. Assert (Verify)
23    // TestEqual prints a nice error message if they don't match.
24    TestEqual(TEXT("Sword count should be 3"), Container.GetCount("Sword"), 3);
25    
26    // TestTrue checks boolean
27    TestTrue(TEXT("Container should not be empty"), Container.HasItems());
28
29    return true;
30}

9b. Functional Testing (Integration Test) #

Unit tests are great, but in Unreal, you often need to test things that require the World, Physics, or Spawning. This is a Functional Test

We use AFunctionalTest, an actual Actor you place in a special Test Level

 1// File: Private/Tests/Functional/InventoryFunctionalTest.h
 2
 3#include "FunctionalTest.h"
 4#include "InventoryComponent.h"
 5#include "InventoryFunctionalTest.generated.h"
 6
 7UCLASS()
 8class AInventoryFunctionalTest : public AFunctionalTest
 9{
10    GENERATED_BODY()
11
12public:
13    AInventoryFunctionalTest()
14    {
15        // Set a time limit for the test
16        TimeLimit = 5.0f;
17    }
18
19    virtual void StartTest() override
20    {
21        Super::StartTest();
22
23        // 1. Spawn a dummy actor
24        AActor* DummyActor = GetWorld()->SpawnActor<AActor>();
25        
26        // 2. Add our component
27        UInventoryComponent* InvComp = NewObject<UInventoryComponent>(DummyActor);
28        InvComp->RegisterComponent();
29
30        // 3. Perform Action
31        InvComp->AddItem("Gold", 100);
32
33        // 4. Verify
34        if (InvComp->GetItemCount("Gold") == 100)
35        {
36            FinishTest(EFunctionalTestResult::Succeeded, TEXT("Gold added successfully"));
37        }
38        else
39        {
40            FinishTest(EFunctionalTestResult::Failed, TEXT("Gold count mismatch"));
41        }
42        
43        // Cleanup
44        DummyActor->Destroy();
45    }
46};