Design Patterns – The Command Pattern

Again, I am not gonna bother trying to find relevant images for this stuff, so have a nice picture of Wipeout Omega Collection that came out last week. Wipeout is my favourite Anti-Grav racer, sorry F-zero, I grew up with the PlayStation 🙂 .

Anyway, lets have a look at the Command Pattern. I have been reading up on the Command Pattern recently, and it seems pretty popular with it being Robert Nystrom’s favorite pattern! (He is the author of Game Programming Patterns. It is a good book, I would recommend it! He also has it all up for free on his website).

Unfortunately, as Mr Nystrom says, the Command pattern as an annoyingly obtuse description:

“Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.”

Seriously, it would be nice not to here a technical definition of something in a language other than nerd once in a while. In English, Commands are an object-oriented replacement for callbacks. It allows you to encapsulate actions into objects with the main objective being to provide the means to decouple the client from receiver.

Does that kind of make sense? OK, well either way let’s look at an example or two.

In the real world, say you were at Maccy D’s after a night out. You want a large portion of C-Nugz with a Cheezy B for the road (or a Large Chicken Nugget meal with an extra cheeseburger. They are only like an extra quid, so why the hell not?). Let’s say it is old school maccys where there is someone taking your order. You (the Client) ask the guy (the Invoker) for your meal of goodness (the Command). The guy plugs that in and a request is made to the Chef(the Receiver) to create it. Do you see what is going on? The Client gives an Invoker a Command that is then past on to the Reciever that actually knows how to deal with the Command.

Let’s look at it in more game dev terminology. I am going to write some C#, because C# is awesome (C++ is alright too, but C# is easier to just get stuff done 😉 )

Let’s say I am making that really popular Side Scrolling Shooter on Vita known as Storm Ship Shiro. We will likely want to put in a way to remap the controls (something I admittedly didn’t do back in the day…). First I am going to make an abstract class called Command.

public abstract class Command
{
public abstract void Execute()
}

The main part of the game I may want to remap is Firing the main Weapon. Firing the Weapon is a Command so what do you think I am gonna do? Make a class that inherits from this Command.

Cool so we have our command, what is our Client. Well in this case that is more “conceptual”. You could say our player is the Client. Our Invoker however could be our Input System that has the following code:

In this case the Client is the player, the Invoker is the Input System, Firing the Weapon is the Command and the Reciever is the Player’s ship.

If we check our simplified definition:

“Allows you to encapsulate actions in objects with the key idea being to provide the means to decouple client from reciever”

That is exactly what this Input system is doing.

Cool huh?

There are many other examples of how the Command pattern is used, one is Undoing and Redoing actions. Say you had a Tactics style game where you could see the outcome of your move. You move your character and then tell him to attack. You didn’t like that last action you performed. So you decided to return to just the move and then use an Item. The client here is still player but the Invoker is a core game system that has a load of commands for every action a character can do. The receiver then is the character themselves.