Chapter 16

Higher Level Game Engine Components

• Runtime game object model
  • Spawning/Destroying game objects
  • Linkage to low level engine systems
  • Real time simulation of object behaviors
  • Ability to define new game object types
  • Unique object IDs
  • Game object queries
  • Game object references
  • Finite state machine support
  • Network replication (for online multiplayer)
  • Saving and loading/object persistence
• Level management and streaming
• Real time object model updating
• messaging and event handling
• Scripting
• Objectives and game flow management

Runtime game object model architecture

• Can be either
  • Object centric: each game object is a single class instance/small connection of instances
  • Property centric: each game object is a unique ID which connects properties in different data tables. The properties define the behavior. Each property can be a class.

Object centric example

• Example is Hydro Thunder game by Midway.
• There is a WorldOb_t representing a 3D object, with 3D mesh, orientation, etc.
• Written in C, uses function pointers and void pointers to implement polymorphism
• Example: struct WorldOb_s {

    Orient_t m_transform;
    Mesh3d* m_pMesh;
    void* m_pUserData;
    void (*m_pUpdate)(); // polymorphic update
    void (*m_pDraw)(); // polymorphic draw
  

  }

Object centric Monolithic Class design

• 
• Example: Unreal engine; each game object derives from a master, root object, with a wide tree of inheritance going down. The master object in Unreal is called an Actor
  • 
• Issue: The more deep and wide the inheritance goes, the more limited you are in terms of flexibility, and you can end up wasting memory and resources from unused properties inherited from parents
• Better to compose or aggregate classes rather than inherit them (remember from Clean Code: "Prefer composition over inheritance")
  • 

Property Centric game model architecture

• 
• Have been used in Deus Ex 2, Thief games
• More like a relational database, with primary keys and attributes
• Properties which define behavior can either be implemented as classes/objects or via scripting
• Pros: can be more memory efficient (only store properties that are used), cache coherency (contiguous memory storage)
  • Struct-of-arrays approach
• Cons: difficult to enforce relationship between properties, harder to define higher-level behavior through a property collection

World Chunk Data Formats

• Store world properties and objects such as static/dynamic mesh data, region volumes, objects initial values, etc.
• Can be stored in:
  • Binary files (uneditable, pointer handling, inflexible)
  • Serialized object file such as json, xml
    • Use spawner objects, have schema, default values

Air Locks

• Can be used as a small buffer area between two levels/large game areas for seamless transitioning the player in real time, without a loading screen or anything

Level loading and object spawning

• Can use a stack based allocator to load and unload levels
  • 
• Objects can be spawned using memory pools, or 'small memory allocators'
  • Have blocks of fixed sizes, such as 2,4,8,16,32, and allocate an object into an area of the nearest larger size

Game Saves

• Stores the current state of the world
• Can get away with partial state saving in some cases where the player won't notice the difference (e.g. an AI location)
• Can have save points so limited to a certain area/location

Object references

• Suggest smart pointers over raw pointers
• Handles: index/indices into a global handle table, which contains the pointer/reference to a specific object
  • All handles are now valid when an object becomes NULL, since this is indicated in the handle table
  • 

Updating game objects in real time

• The simple 'call an update function' for each object in the main loop doesn't always work
  • Due to concurrency and dependance on subsystems and order-matters between objects
• Common to have multiple update calls (e.g. pre and post animation update, pre and post physics update) in order to account for changes calculated by the engine
• Common to cache the previous state of an object so for each frame, other objects can reference a stable value
  • The states of all game objects are consistent Before and After the update loop, but NOT during it
• For performance, it is good to batch related updates and perform them all at once, possibly in parallel with SIMD

• Bucketed updates: only call a certain update for objects in the same 'bucket' to avoid calling the update on unnecessary objects

    enum Bucket
    {
        kBucketVehiclesPlatforms,
        kBucketCharacters,
        kBucketAttachedObjects,
        kBucketCount
    };
  
    void UpdateBucket(Bucket bucket)
    {
        for (each gameObject in bucket)
        {
            gameObject.PreAnimUpdate(dt);
        }
  
        g_animationEngine.CalculateIntermediatePoses(bucket, dt);
  
        for (each gameObject in bucket)
        {
            gameObject.PostAnimUpdate(dt)
        }
        ...
    }
  
    void main()
    {
        while (true)
        {
            UpdateBucket(kBucketVehiclesPlatforms);
            UpdateBucket(kBucketCharacters);
            ...
        }
    }
  

• Concurrency: can call asynchronous functions to kick off a task, then perform other tasks while it is running, then call a sync when we need to wait for the concurrent task to be completed

  • Can improve performance by waiting longer if the task is not critical to happen at that timepoint
  • Degree of Parallelism: the theoretical maximum number of jobs that can be executed at once in parallel based on order dependency between tasks
    • 
    • 
    • 
  • Job system is also possible

Events and message passing

• Common to use events between systems and objects, like SDL_Event and SDL_PollEvent
• Events can contain arguments/parameters either hard-coded or via Variants, which cast the same amount of memory as different types
  • 
• Chain of Responsibility Can be used to pass up an event through the object hierarchy until it reaches its desired location (each object passes to its parent)
  • 

Data driven event/message passing

• Design responses to events in the object/data via scripting or some other method
• Implemented via 'data streams', where objects have input/output ports, each defined with a certain type (e.g. bool), which can be edited in a GUI graph editor such as Unreal Blueprints
  • 
  • 

Scripting: Popular languages

• QuakeC
• UnrealScript
• Lua
• Python
• Pawn/Small/Small-C

Script handling in the engine

• The language interpreter is contained within the game engine, 'emulating' the system for the script to run in (example from Naughty Dog's DC language)

    void DcExecuteScript(DCByteCode* pCode)
    {
        DCStackFrame* pCurStackFrame = DcPushStackFrame(pCode);
  
        while (pCurStackFrame != nullptr)
        {
            DCInstruction& instr = pCurStackFrame->GetNextInstruction();
  
            ...
        }
    }
  

• Language calls can be tied/binded to engine calls via the language function string or similar

• Data types can be mapped to engine specific types
• Arguments can use Variants for dynamic object typing
• Events/messages can be sent to the script
• Script 'multithreading' can happen by the interpreter managing time between multiple scripts running at once (via preemptive or cooperative scheduling)

Chapter 17 (Other game systems)

• Movie Playing / FMVs
• Multiplayer Networking
• Game Camera
  • Look-at camera
  • Follow Cameras
  • Real Time Strategy Camera
  • Cinematic Camera
• Weapons
• Cover
• Specialized traversal (ladders, ropes)
• Vehicle Systems
• Puzzle Mechanics
• Artificial Intelligence