Hello! This is Game Programming Patterns 101 and this video is about the Command Pattern.

Going straight to the point, there’s two definitions we can use:

1. The original one, from the gang of four original book, where almost all known patterns were first explained formally.
2. And the one offered by wikipedia because this is the internet.

Book Definition

As the book defines: Encapsulate a request as an object thereby letting users parameterize clients with different requests, queue or log requests, and support undoable operations.

Wiki definition

And as wikipedia defines: .. An object is used to encapsulate all information needed to perform an action or trigger an event at a later time.

Both definitions mean taking some concept and turning it into a piece of data, an object in our case, that you can stick in a variable, pass to a function, store or whatever.

To picture it better, we can make an example.

void InputHandler::handleInput()
{
	if (isPressed(BUTTON_X)) jump();
	else if (isPressed(BUTTON_Y)) fireGun();
	else if (isPressed(BUTTON_A)) swapWeapon();
	else if (isPressed(BUTTON_B)) lurchIneffectively();
}

Imagine we are handling our inputs like this. Not too flexible since the mapping of buttons and actions is hardcoded and once the action was made, it disappear, no record, no nothing.

class Command {
public:
	virtual ~Command() { }
	virtual void execute() = 0;
};

To make it better, we can add something in between the handler function and the ultimate action.

Introducing the core concept of the command pattern. An empty abstract class that’s gonna be used to create our commands inheriting from it. Like, for example, Jump()

class JumpCommand : public Command {
public:
	virtual void execute() { jump(); }
}

The JumpCommand class inherits from the base one, Command.

Something we’re going to have in all commands is the execute() function. In each derived class, we’re going to implement the action we really need in there.

class InputHandler {
public:
	void handleInput();
private:
	Command* buttonX;
	Command* buttonY;
	...
}

In our Input Handler class that we saw before, we can store a Pointer to a command for each button we have, then, the buttons can be mapped to different command clases, maybe to nothing, or even be set and changed later by the player.

void InputHandler::handleInput() {
	if (isPressed(BUTTON_X)) buttonX->execute();
	else if (isPressed(BUTTON_Y)) buttonY->execute();
	else if (isPressed(BUTTON_A)) buttonA->execute();
	else if (isPressed(BUTTON_B)) buttonB->execute();
}

All we need to do after is to access those pointers to call each execute() function in the input handler. Since all of them are commands in their base class, we can let the inheritance do the trick.

The same result can be obtained by using interfaces, but since the parent class is just empty with minimal implementation, it would be enough.

So far, we managed to improve the code by making possible exchanging the behavior of the buttons; but there’s more useful things we can do with this pattern.

A common case, is to implement a Redo operation. To make the commands undo or redo, we need to define another operation in our command base class or interface.

class Command {
public:
	virtual ~Command() { }
	virtual void execute() = 0;
	virtual void undo() = 0;
};

This new function reverses the state changed by the corresponding execute() function. In order to use the undo() function, we need to save the needed information inside our child command class. Information like the original position if moved, a potion name if it was used, and things like that.

class MoveUnitCommand : public Command {
	Unit* ThisUnit;
	int Pos_X, Pos_Y;
	int Prev_X, Prev_Y;
		
public:
	MoveUnitCommand(Unit* NewUnit, int X, int Y) :
		ThisUnit(NewUnit), Pos_X(X), Pos_Y(Y), Prev_X(0), Prev_Y(0)
			
	virtual void Execte();
	virtual void Undo();
}

virtual void execute() {
	// Remember the unit's position before the move so we can restore it.
	Prev_X = ThisUnit->GetPosition().X
	Prev_Y = ThisUnit->GetPosition().Y;
	ThisUnit->moveTo(Pos_X, Pos_Y);
}

virtual void undo() {
	ThisUnit->moveTo(Prev_X, Prev_Y);
}

This example considers a class where we have values to store the position before the execution. To let the player undo a move, we keep around the last command executed. When the player bangs ctrl+Z (or whatever) we call that command’s undo().

After all this, supporting multiple levels of undo() and redo() is not much more conplicated. Instead of remembering the last command, we can keep a list of them. To redo() or undo() we just do the same than before but moving across the list instead.

With this little example we can have a pretty much operational implementation following the Command Pattern. But as a final thought: Notice that some commands are just stateless junks of pure behavior. In cases like this, having more than one instance of that class can waste memory. Flywheight pattern addresses that and we are going to review it in the following posts.

As always, we can share the definitions from the gang of 4 and Wikipedia to have a broad picture.

The official design patterns book said:

“Use sharing to support large numbers of fine-grained objects efficiently.”

And Wikipedia mentioned it this way:

“The Flyweight pattern minimizes memory usage by sharing some of its data between similar objects.”

Basically — it’s about sharing heavy data across many objects instead of duplicating and multiplying it everywhere.

So picture this: You’re walking through a dense and ancient forest.

Thousands of leaves floating in the air and trees stretch down the hills getting lost into the misty distance.

Every game developer dream of creating epic scenes like this.

But — rendering thousands of leaves and trees can obliterate your memory and computer bus communication.

Even if your machine could somehow hold all that data, moving it back and forth GPU and CPU would choke the performance anyways.

Coding a not efficient tree like that might look like this:

class Tree {
private:
    Mesh StaticMesh;
    Texture Bark;
    Texture Leaves;
    Vector Location;
    double Height;
    double Thickness;
    Color BarkTint;
    Color LeafTint;

This is a quite a bit of data per tree; and the mesh and textures are the ones hitting heavier.

But lucky us, in reality, most trees are probably using the same mesh and textures, so this case sounds like a good candidate for the Flyweight pattern.

We could split the the class to keep the heavy parts separately.

class TreeModel {
private:
    Mesh StaticMesh;
    Texture Bark;
    Texture Leaves;

The rest goes to each individual Tree. They just need to hold lightweight unique info — like its position, size, or tint.

This is the concept of Intrinsic and Extrinsic data for the Flyweight pattern.

Intrinsic is the static data that could be shared across many trees. Like the Mesh, Texture. Is the same for all.

class Tree {
private:
    TreeModel* IntrinsicTreeData;
    
    Vector Location;
    double Height;
    double Thickness;
    Color BarkTint;
    Color LeafTint;

Extrinsic is the data that cannot be shared, like the position or the state. The amount of wood left if you can loot it, etc.

Now, thousands of trees can share one TreeModel, saving a potentially massive amounts of memory using it as the Intrinsic instance of the data.

The Intrinsic Tree Data can be pass to the class upon creation, so its instance is created only once.

class Tree {
	Tree(TreeModel* newIntrinsicTreeData) : 
		IntrinsicTreeData(newIntrinsicTreeData) {}
		
	void SetExtrinsicValues(
		Vector Location,
    double Height,
    double Thickness,
    Color BarkTint,
    Color LeafTint);

At first glance, this seems like simple asset reuse, kind of a stretch calling it a pattern.

But the Flyweight pattern becomes really clever when we apply it in places without obvious sharable pieces in the objects.

Let’s look at another example: terrain tiles for a world map.

We could model terrain with an enum like this:

enum TerrainType {
    TERRAIN_GRASS,
    TERRAIN_HILL,
    TERRAIN_RIVER

And a world map could contain something like this:

class World {
private:
    TerrainType Tiles[WIDTH][HEIGHT];

Let’s say we want to check if a tile is water; we could do something like this:

bool World::IsWater(int x, int y) {
    switch (Tiles[x][y]) {
        case TERRAIN_GRASS: return false;
        case TERRAIN_HILL:  return false;
        case TERRAIN_RIVER: return true;

This is fine, It kinda works… but it’s clunky and a little awful to be honest.

Switches everywhere. Hard to extend. Messy when adding new behaviors.

SO! Instead of that, we create a new class for our Terrain type:

class Terrain {
public:
    Terrain(int moveCost, bool isWater, Texture texture)
        : MoveCost(moveCost), bIsWater(isWater), TerrainTexture(texture) {}

    bool isWater() { return bIsWater; }
    int getMoveCost() { return MoveCost; }

private:
    int MoveCost;
    bool bIsWater;
    Texture TerrainTexture;

Attributes like the cost of moving through it or if is water will be stored here.

Along with the texture and any other element independent from the world.

Now, our world class can store pointers to shared Terrain objects instead of dumb enumerators inside an enum.

class World {
private:
    Terrain* Tiles[WIDTH][HEIGHT];

Every grass tile points to the same GrassTerrain instance.

Every river tile will point to a shared RiverTerrain instance.

Much better. Clean. No switch statements.

In a super simple version, we can just create terrains upfront.

When creating the world, the terrain types can be already created and stored in within the world.

class World {
public:
    World() : GrassTerrain(1, false, GRASS_TEXTURE),
          HillTerrain(3, false, HILL_TEXTURE),
          RiverTerrain(2, true, RIVER_TEXTURE) {}

private:
    Terrain GrassTerrain;
    Terrain HillTerrain;
    Terrain RiverTerrain;
    Terrain* Tiles[WIDTH][HEIGHT];

When generating the map, you just assign pointers to these shared terrains.

This can be done by a function following location instructions or by noise or something like that.

But that topic goes beyond the intention of this video so let’s avoid it.

If you want even more flexibility, for example, dynamically creating terrains based on data files, you can create terrains on demand using a Factory Method.

That’s another pattern that we’ll explore in future videos so stay tuned.

Anyways. With this setup, querying terrain properties becomes super clean: Bravo!

No switch statements or asking stuff to the world. Everything shared and holding its own stuff.

int walkingCost = world.GetTile(2, 3).getMoveCost();

Now, this is awesome and all but you might worry:

“Isn’t using pointers slower than using enums directly?”. And you might sound like you should be right.

But in the tests from Game Programming Patterns author, Flyweight objects were actually faster than using enums, thanks to better data layout and fewer branch mispredictions.

Sounds really convincing, but performance can vary depending on how your memory is organized, so it might not be always the case.

Always profile if you’re unsure, at least to see for yourself.

In summary and to close already. If you find yourself using enums and switch statements everywhere, consider using this pattern. The Flyweight Pattern.

It will make your code: Easier to extend. Cleaner. Maybe faster.

And Much more memory efficient, since the point is sharing.

This sounds like a sponsorship from this pattern.