Type Objects

In the previous lessons, we learned some techniques that allow objects in our C++ program to acopt characteristics defined in some external location. This might be a file created by a different program, a stream of data coming from the internet, or simply a text file that we can edit.

For example, we could let designers on our team or our end users add monsters to our game by editing a JSON file:

1{
2  "name": "Goblin",
3  "level": 3,
4  "health": 100,
5  "damage": 15,
6  "armor": 0.2,
7  "art": "goblin.png",
8  "position": { "x": 1, "y": 3 }
9}

However, with this simple system, we'll soon encounter some design problems. For example, if we were to create a dungeon with some monsters, we'll end up with a lot of duplication:

1[{
2  "name": "Goblin",
3  "level": 3,
4  "health": 100,
5  "damage": 15,
6  "armor": 0.2,
7  "art": "goblin.png",
8  "position": { "x": 1, "y": 3 }
9}, {
10  "name": "Goblin",
11  "level": 3,
12  "health": 100,
13  "damage": 15,
14  "armor": 0.2,
15  "art": "goblin.png",
16  "position": { "x": 2, "y": 1 }
17}, {
18  "name": "Goblin",
19  "level": 3,
20  "health": 100,
21  "damage": 15,
22  "armor": 0.2,
23  "art": "goblin.png",
24  "position": { "x": 4, "y": 7 }
25}]

Duplication in our serialized data is just as much of a problem as it is in our code. It makes changes quite difficult - if we need to change the health that goblins have, we have to update every copy.

Inefficient data organisation also has a runtime performance cost in a way that duplicate code often doesn't. Large blobs of data takes longer to deserialize and transfer.

Revisting Types

We probably recognise this as a familar problem - when groups of objects have a set of similar characteristics, we can represent them as being part of the same class, or having the same type.

We could represent those shared set of characteristics as a single value, which we'll call type:

1[{
2  "type": "Goblin",
3  "position": { "x": 1, "y": 3 }
4}, {
5  "type": "Goblin",
6  "position": { "x": 2, "y": 1 }
7}, {
8  "type": "Goblin",
9  "position": { "x": 4, "y": 7 }
10}]

Then, in the C++ code that deserializes our data, we can examine the requested type of each object, and map it to a corresponding class:

1// Defining a class
2class Goblin {
3public:
4  Goblin(int x, int y) : PositionX{x}, PositionY{y} {}
5  int PositionX;
6  int PositionY;
7  
8  std::string Name{"Goblin"};
9  int Level{3};
10  int Health{100};
11  int Damage{15};
12  float Armor{0.2};
13  std::string Art{"goblin.png"};
14};

1// Creating class instances
2Goblin A{1, 3};
3Goblin B{2, 1};
4Goblin C{4, 7};

The tradeoff here is that, having moves values that were previously defined in data back into our C++ code, we've lost some flexibility

Problems with Classes

The problem with relying solely on C++ classes is that it ties our type definitions directly to our compiled code. This introduces several limitations:

Firstly, modifying or adding new types of monsters now requires C++ programming knowledge. A game designer or even a player who wants to mod the game can't simply tweak a configuration file; they'd need access to the source code, and the C++ knowledge to modify it.

Secondly, this approach can slow down iteration. If we want to experiment with a new monster type or adjust the stats of an existing one, we have to stop the game, change the C++ class, recompile the entire project, and then restart. This cycle can be time-consuming, especially when fine-tuning game balance or exploring creative ideas.

Finally, if our game has a vast bestiary with many unique monsters, each differing only slightly in stats or appearance, we could end up with an explosion of C++ classes. This can make the codebase harder to manage and navigate, even if many of these classes are very similar.

While the C++ type system is incredibly powerful and forms the backbone of our programs, for scenarios demanding high flexibility and external configuration of object properties, layering another system on top can be highly beneficial.

Types as Data

So, we want to return granular control of our objects back outside of our program where they can be easily modified, but without causing the duplicate data problem we had before. The natural idea that probably comes to us is to have those types themselves defined as data that our program deserializes.

Elsewhere in our JSON file, or in a different file, we can define the types of enemies that our program will be using. These look very similar to the classes we had in our C++ code, except now they're represented as serialized data:

1{
2  "Goblin": {
3    "name": "Goblin",
4    "level": 3,
5    "health": 100,
6    "damage": 15,
7    "armor": 0.2,
8    "art": "goblin.png",
9  },
10  "Dragon": {
11    "name": "Dragon",
12    "level": 12,
13    "health": 1300,
14    "damage": 75,
15    "armor": 0.4,
16    "art": "dragon.png",
17  }
18}

We have just discovered the concept of a type object - a popular design pattern for solving this exact problem.

Type Objects

The Type Object pattern offers a way to define the shared characteristics of our game objects using data, rather than hardcoding everything into C++ classes.

This means we can have one general C++ class for many game entities, and their specific "type" (like being a Goblin or a Dragon) is determined by a separate "type object" they hold as a member variable.

This "type object" holds all the common properties for entities of that kind, like default health, damage, or artwork. Our individual entity instances will then store their own unique data (like current position or current health) and hold a reference to their type object.

This allows the C++ aspect of our type system to involve just two classes - one for the primary objects, which we'll call Entity in our examples, and a second class for the type objects, which we'll call MonsterType.

First, let's define our simple MonsterType struct, which we'll use later to instantiate our type objects:

1// MonsterType.h
2#pragma once
3#include <string>
4
5struct MonsterType {
6  std::string Name;
7  int Level;
8  // Shared maximum health for this type
9  int MaxHealth;
10  int Damage;
11  std::string ArtFile;
12};

Next, our Entity class will be quite generic. It stores its unique properties (like position and current health) and holds a reference to its MonsterType:

1// Entity.h
2#pragma once
3#include "MonsterType.h"
4
5class Entity {
6public:
7  Entity(const MonsterType& Type, int x, int y)
8  : Type{Type}, X_Pos{x}, Y_Pos{y},
9    CurrentHealth{Type.MaxHealth} {}
10
11  // Member variables
12  const MonsterType& Type; // See note below 
13  
14  // Instance-specific values
15  int X_Pos;
16  int Y_Pos;
17  int CurrentHealth;
18};

Now, let's see how to use our two classes this in main:

1// main.cpp
2#include "MonsterType.h"
3#include "Entity.h"
4
5int main() {
6  MonsterType GoblinType{
7    "Goblin",      // Name
8    3,             // Level
9    100,           // MaxHealth
10    15,            // Damage
11    "goblin.png"   // ArtFile
12  };
13
14  MonsterType DragonType{
15    "Dragon",      // Name
16    12,            // Level
17    1300,          // MaxHealth
18    75,            // Damage
19    "dragon.png"   // ArtFile
20  };
21
22  // Create Entity instances, providing
23  // their type and position
24  Entity GoblinA{GoblinType, 10, 20};
25  Entity GoblinB{GoblinType, 15, 25};
26  Entity BigDragon{DragonType, 50, 50};
27}

Benefits of Type Objects

The Type Object pattern offers several significant advantages, particularly in game development:

• Rapid Iteration: One of the most compelling benefits is the ability to update types very quickly. Since type definitions (like a monster's stats or abilities) are stored as data, changes can often be made without needing to recompile the C++ code. We can implement our code such that designers can tweak values in a JSON file, for example, and see the effects in-game almost immediately. This dramatically speeds up the design and balancing process.
• Accessibility for Non-Programmers: Because types are defined externally, individuals without C++ programming knowledge can modify or create new types. Game designers can balance enemy stats, artists can specify visual assets, and even players (in moddable games) can create custom content, all by editing data files.
• External and Dynamic Type Definitions: Types can be defined and managed entirely outside the core game executable. This data could come from dedicated external tools (like a custom monster editor) or a database. For online games, this unlocks particularly interesting possibilities: new monster types or item properties can be introduced or updated over the network, without requiring players to download and install a new game patch. They may not even need to restart their game.
• Reduced Code and Class Proliferation: Instead of creating numerous C++ classes for slight variations of entities (e.g., GoblinScout, GoblinWarrior, GoblinShaman), you can have a single Entity class and differentiate them through their type objects. This keeps the C++ class hierarchy cleaner and more manageable.

But fundamentally, the core advantage of type object systems is the flexibility - we can build it however we want, to meet the exact requirements of the program we're designing.

• Do we want our objects to have multiple types? No problem, just design them to have multiple type objects.
• Do we need some form of inheritance? We can implement that to our exact requirements.
• Do our objects need to change their type? Easy - we can add a setter to change the value stored in the Breed. We'll implement this later in the lesson.

But that's also the main disadvantage - the need to build and maintain this stuff ourselves.

If we need inheritance-like behaviour for our class, that's easy. The C++ type system already has built inheritance for us and, to access it, we just need to add : public SomeClass to our definition:

1class BigGoblin : public Goblin {
2public:
3  BigGoblin() {
4    // Update the inherited members
5    Name = "Big Goblin";
6    Health = 200;
7  }
8};

But if we wanted similar capabilities for our type object system, we'd need to build that ourselves:

1{
2  "Goblin": {
3    "name": "Goblin",
4    "level": 3,
5    "health": 100,
6    "damage": 15,
7    "armor": 0.2,
8    "art": "goblin.png",
9  },
10  "BigGoblin": {
11    // We'd need to write the C++ to implement this
12    "Parent": "Goblin", 
13    "name": "Big Goblin",
14    "health": 200,
15  }
16}

Writing the code to make this work would take some effort, and it's not a one-time cost. It leaves us with more code we need to maintain, more complexity in our project, and more things that can go wrong.

As always, we should aim to keep things as simple as possible, and only add complexity when we need it, or when we're relatively certain that the benefits will outweigh the costs.

Constructing Typed Objects

There are a couple of common ways we can instantiate our Entity objects and associate them with their MonsterType.

Standard Constructor Injection

The most straightforward method is to pass the MonsterType object (or a reference/pointer to it) directly into the Entity's constructor. This is the approach we've used so far:

1// main.cpp
2#include <iostream>
3#include "MonsterType.h"
4#include "Entity.h"
5
6int main() {
7  MonsterType GoblinType{
8    "Goblin", 3, 100, 15, "goblin.png"
9  };
10
11  // Entity constructor takes the MonsterType
12  Entity GoblinInstance{GoblinType, 5, 10}; 
13
14  std::cout << "Created a "
15    << GoblinInstance.Type.Name
16    << " at (" << GoblinInstance.X_Pos
17    << ", " << GoblinInstance.Y_Pos
18    << ") with " << GoblinInstance.CurrentHealth
19    << " HP.\n";
20}

1Created a Goblin at (5, 10) with 100 HP.

This approach is clear and follows familiar C++ practices for dependency injection. The Entity explicitly declares its need for a MonsterType.

Factory Method on the Type Object

An alternative is to have the MonsterType object itself be responsible for creating instances of entities that conform to its type. We can add a CreateInstance() or Construct() method to the MonsterType struct:

1// MonsterType.h
2#pragma once
3#include <string>
4// Forward declaration for Entity to avoid circular
5// dependency if Entity.h also includes MonsterType.h
6class Entity; 
7
8struct MonsterType {
9  std::string Name;
10  int Level;
11  int MaxHealth;
12  int Damage;
13  std::string ArtFile;
14
15  // Factory method
16  Entity CreateInstance(int x, int y) const; 
17};

1// MonsterType.cpp
2#include "MonsterType.h"
3#include "Entity.h"
4
5Entity MonsterType::CreateInstance(
6  int x, int y
7) const {
8  return Entity{*this, x, y};
9}

1// main.cpp
2#include <iostream>
3#include "MonsterType.h"
4#include "Entity.h"
5
6int main(int argc, char** argv) {
7  MonsterType GoblinType{
8    "Goblin", 3, 100, 15, "goblin.png"
9  };
10
11  Entity GoblinInstance{GoblinType, 5, 10};
12  Entity GoblinInstance{
13    GoblinType.CreateInstance(5, 10)};
14
15  std::cout << "Created a "
16    << GoblinInstance.Type.Name
17    << " at (" << GoblinInstance.X_Pos
18    << ", " << GoblinInstance.Y_Pos
19    << ") with " << GoblinInstance.CurrentHealth
20    << " HP.\n";
21    
22  return 0;
23}

1Created a Goblin at (5, 10) with 100 HP.

This factory method approach can be useful if the creation logic is complex or if the MonsterType needs to perform some setup on the Entity that goes beyond simple member initialization. It also keeps the creation knowledge localized within the MonsterType.

Both methods are valid, and the choice depends on the specific requirements of your project, and your preferred coding style.

Defining Behaviour

One significant advantage of the traditional C++ class system is how easily it allows us to define distinct behaviors for different types of objects - particularly when we use virtual functions and polymorphism. For example, a Goblin class could have a different Attack() method implementation than a Dragon class.

When we move towards a data-driven Type Object system, defining complex, unique behaviors purely through data becomes more challenging. Unless we integrate a scripting system (like Lua, which we discussed earlier in this chapter) that our type objects can reference or embed, we can't directly write arbitrary "code" in our data files.

However, a practical middle-ground approach is to add data fields to our type objects that influence behavior, which is then interpreted by the C++ Entity class. The behavior itself is still implemented in C++, but it can be parameterized or selected based on data from the type object.

For instance, we could add a FightingStyle property to our MonsterType data:

1{
2  "Goblin": {
3    "name": "Goblin",
4    "health": 100,
5    "art": "goblin.png",
6    "fightingStyle": "Swarm" 
7  },
8  "Ogre": {
9    "name": "Ogre",
10    "health": 500,
11    "art": "ogre.png",
12    "fightingStyle": "BruteForce" 
13  }
14}

Our MonsterType struct in C++ would then include this new field:

1// MonsterType.h
2#pragma once
3#include <string>
4class Entity;
5
6enum class FightingStyle {
7  Swarm, BruteForce, RangedSnipe
8};
9
10struct MonsterType {
11  std::string Name;
12  int Level;
13  int MaxHealth;
14  int Damage;
15  std::string ArtFile;
16  FightingStyle Style;
17
18  Entity CreateInstance(int x, int y) const;
19};

And our Entity class can have a method, say PerformCombatAction(), that uses this FightingStyle property to decide what to do:

1// Entity.h
2#pragma once
3#include <iostream>
4#include "MonsterType.h"
5
6class Entity {
7public:
8  Entity(const MonsterType& Type, int x, int y)
9    : Type{Type}, X_Pos{x}, Y_Pos{y},
10      CurrentHealth{Type.MaxHealth} {}
11
12  const MonsterType& Type;
13  int X_Pos;
14  int Y_Pos;
15  int CurrentHealth;
16
17  void PerformCombatAction() const {
18    std::cout << Type.Name << " considers its "
19      "action...\n";
20
21    using enum FightingStyle;
22    if (Type.Style == Swarm) {
23      std::cout << "  It attempts to overwhelm "
24        "with numbers!\n";
25    } else if (Type.Style == BruteForce) {
26      std::cout << "  It charges with brute "
27        "force!\n";
28    } else if (Type.Style == RangedSnipe) {
29      std::cout << "  It looks for a sniping "
30        "opportunity!\n";
31    } else {
32      std::cout << "  It attacks normally.\n";
33    }
34  }
35};

In our main function:

1// main.cpp
2#include "MonsterType.h"
3#include "Entity.h"
4
5int main(int argc, char** argv) {
6  using enum FightingStyle;
7  MonsterType GoblinType{
8    "Goblin", 3, 100, 15, "goblin.png", Swarm
9  };
10
11  MonsterType OgreType{
12    "Ogre", 5, 300, 25, "ogre.png", BruteForce
13  };
14
15  Entity Goblin{
16    GoblinType.CreateInstance(5, 10)};
17  Entity Ogre{OgreType.CreateInstance(10, 6)};
18
19  Goblin.PerformCombatAction();
20  Ogre.PerformCombatAction();
21  
22  return 0;
23}

1Goblin considers its action...
2  It attempts to overwhelm with numbers!
3Ogre considers its action...
4  It charges with brute force!

This way, designers can change the FightingStyle in the data to alter how entities behave, without touching C++ code. The range of behaviors is still defined in C++, but their selection and parameterization can be data-driven.

This approach provides a good balance between flexibility and the complexity of implementing a full scripting system. We could extend this further with more data fields, like a Spellbook array that lists the combat abilities the type has access to, or MovementPattern to represent how the type moves.

Changing Types

One of the defining capabilities of type objects is that they give us the ability to change an object's type at runtime.

C++ doesn't let us change the class of an object at run time, but it does let us change what is stored in a member variable, and a type object is just another variable. In the following example, we've added a SetType() function to our Entity class.

We've also changed the Type member from being a MonsterType reference to a MonsterType pointer, as references cannot be updated to point to other objects. The logic we write may also want to consider the the possibility the object having no type at all - that is, Type being a nullptr:

1// Entity.h
2#pragma once
3#include <iostream>
4#include "MonsterType.h"
5
6class Entity {
7public:
8  // Constructor now takes a pointer to MonsterType
9  Entity(const MonsterType* Type, int x, int y) 
10    : Type{Type}, X_Pos{x}, Y_Pos{y},
11      // Added null check and switched from
12      // the . to -> operator
13      CurrentHealth{Type ? Type->MaxHealth : 0} 
14  {}
15
16  // Changed type to pointer
17  const MonsterType* Type; 
18
19  void ChangeType(const MonsterType* NewType) {
20    if (!NewType) return; // Or handle error
21
22    std::cout << X_Pos << "," << Y_Pos 
23      << ": " << Type->Name
24      << " is transforming into a "
25      << NewType->Name << "!\n";
26    Type = NewType;
27
28    // Adjust health based on the new type.
29    // For example, cap current health at new
30    // max health, or fully heal to new max health.
31
32    // Let's set it to the new type's max health
33    // for this example.
34    CurrentHealth = Type->MaxHealth;
35  }
36
37  int X_Pos;
38  int Y_Pos;
39  int CurrentHealth;
40};

1// MonsterType.cpp
2#include "MonsterType.h"
3#include "Entity.h"
4
5Entity MonsterType::CreateInstance(
6  int x, int y
7) const {
8  // Change argument from reference to pointer
9  return Entity{*this, x, y};
10  return Entity{this, x, y};
11}

We can now dynamically change our object's type at run time:

1// main.cpp
2#include "MonsterType.h"
3#include "Entity.h"
4
5int main(int argc, char** argv) {
6  using enum FightingStyle;
7  MonsterType GoblinType{
8    "Goblin", 3, 100, 15, "goblin.png", Swarm
9  };
10
11  MonsterType DragonType{
12    "Dragon", 7, 500, 45, "dragon.png", RangedSnipe
13  };
14
15  Entity Goblin{
16    GoblinType.CreateInstance(5, 10)};
17
18  Goblin.ChangeType(&DragonType);
19  
20  return 0;
21}

15,10: Goblin is transforming into a Dragon!

In type object systems, it's generally the case that changing this value will have signicant impacts on the behaviour of the object. Naturally, the extent of this will depend on how we've designed our program.

In the following example, our object initially renders as a goblin (which we've simulated through some logging) and, after a type change, it renders itself as a dragon:

1// Entity.h
2#pragma once
3#include <iostream>
4#include "MonsterType.h"
5
6class Entity {
7public:
Previous Code (Unchanged)|Show
25
26  void Render() {
27    if (!Type) {
28      return; // Or handle error
29    }
30    std::cout << X_Pos << "," << Y_Pos
31      << ": Rendering " << Type->Name
32      << " using art file: " << Type->ArtFile
33      << "\n";
34  }
35};

Let's see this in action:

1// main.cpp
2#include "MonsterType.h"
3#include "Entity.h"
4
5int main(int argc, char** argv) {
6  using enum FightingStyle;
7  MonsterType GoblinType{
8    "Goblin", 3, 100, 15, "goblin.png", Swarm
9  };
10
11  MonsterType DragonType{
12    "Dragon", 7, 500, 45, "dragon.png",
13    RangedSnipe
14  };
15
16  Entity Enemy{
17    GoblinType.CreateInstance(5, 10)};
18
19  Enemy.Render();
20  Enemy.ChangeType(&DragonType);
21  Enemy.Render();
22  
23  return 0;
24}

15,10: Rendering Goblin using art file: goblin.png
25,10: Goblin is transforming into a Dragon!
35,10: Rendering Dragon using art file: dragon.png

Complete Code

A complete version of the files we created in this lesson is available below:

Summary

This lesson introduced the Type Object design pattern as a way to define an object's characteristics using external data rather than hardcoding them into C++ classes. We explored how this pattern separates an entity's fixed class from its variable, data-defined traits, leading to more flexible and maintainable game designs.

By using type objects, we can empower designers and even players to modify game content without recompiling code.

Key Takeaways:

• Type Objects allow shared characteristics of entities to be defined by data.
• This pattern decouples an entity's C++ class from its specific "kind" or "breed."
• Changes to entity types can be made externally, speeding up iteration.
• Type Objects facilitate data-driven design, making games more moddable.
• Behaviors can be influenced by data in type objects, offering a balance with C++ implemented logic.
• Entities can potentially change their type object at runtime, enabling dynamic transformations.

Free and Unlimited Access

Professional C++

Unlock the true power of C++ by mastering complex features, optimizing performance, and learning expert workflows used in professional development

View Course