 This video was brought to you by my patrons, thank you so much for your support! Hello there! Continuing the series of studies of design patterns using Grote Engine, today we'll talk about the command pattern. So without further ado, let's get started! Ok, so the definition of the command pattern is not very reasonable, you can reason about it very well. Let me quote what it often means. How it is described, it encapsulates a request as an object, thereby letting you permittize clients with different requests, queue or log requests, and support undoable operations. Ok, this doesn't mean a lot, often other authors give other definitions which are better understandable, you can reason about them better. So I will quote this other definition because this has a core aspect of the command pattern and is more reasonable. A command pattern is a behavioral design pattern that turns a request into a standalone object that contains all information about the request. This transformation lets you permittize methods with different requests, delay or queue a request execution and support undoable operations. Alright, this one has a lot of core aspects that means a lot about the command pattern. It turns a request into a standalone object that contains all the information about the request and by doing so we can create kills of requests, we can delay the different requests and support undoable operations which is one of the main things about the command patterns I think. Alright, so let's try to implement this command pattern using nodes here in Godot Engine. But before we actually implement this let me try to contextualize the implementation that I will try to use here. So I made a design for a game that I want to develop this year and I think that the command pattern will fit very well a problem that I faced in the design. So let's try to understand the problem. At some point the players will be able to stack actions that will be executed later. So we will be able to stack some actions on a character that will be executed in a first in first out order. Each action including walking has an execution time that may impact the synchrony of the cooking process. So after we set the actions we will execute them so we first plan how will be the execution of the recipe and then we execute this recipe. And I think that the command pattern will be this solution for this mechanic because let's try to remember the description of the command pattern. With the command pattern we can delay and kill the request that we made for execution of a given method. So at some point we can say ok this object will do this that and this other thing but won't be now we just wanted to make it at some point. So we have this stack we have the skill of requests and at some point we can say ok execute this now and it will start to execute what we will request previously. So I think that this is a very good solution for this problem that I have in my game design. So I think that I will use this command pattern for the implementation of this mechanic. So back in Godot let's try to implement this. You'll see that the command pattern is very similar to the strategy pattern but the way that I understood it is that it is a very specific implementation of the strategy pattern so it will follow the strategy principles but we have a very specific set of algorithms here. So I will try to make a walk command here to simulate what I will implement in my game and for that we will create a custom node and go here into node and I will make this a actor command save this actor command save I'll create a script save this as well and basically an actor command will ask for an actor and for a grid that will be the grid that the actor is supposed to interact with. So in my game let me show you again in my game we have a grid where we can arrange some objects and the actor interact with this object so the grid will tell which object is in which cell. So this is what the command will ask so it will ask for an actor and it will ask for the grid and it will have two methods. That is the execute so we will tell a command to execute and an un-execute method so why do we have this un-execute? Remember that one of the core aspects of the command pattern is that it is an undoable queue of requests of methods that the object made so we have a method for the execution of this request of this command and we also have an implementation for undo this execution so we can go back and forward in this queue of events and we can execute and un-execute them. So with this set let's create another command so I will go here in new inherited scene actor command and I will call this the walk command save this save and I will right click here and extend the script to create the actual walk command here. So the walk command will also ask for a direction of the movement with by default will be 0 will be a vector 2 with 00 and finally we can implement the execution and un-execution of this command. So in the execute method we will map the actor position into the grid we will try to get the cell where the character is currently. So var cell or better actor cell will be the grid dot word to map and we will try to get the actor global position and this will return a cell into the grid that will be the actor cell. Then we will go to the actor and we will set its global position to be the grid dot map to world actor cell plus the direction which we get. So we will use this to offset the cell that we just made here and this is the execute method. So the un-execution of this method un-execute will be the same thing but instead of adding the direction we will remove the direction so we will offset it in the other way around and this is it. This is the walk command. This is everything that it does. So now let's try to make this actually work into an actual context. So after this we have a command but I just thought that it would be better if we export this variable and create a subset of walk command so we will have a subfamily of walk commands one to walk to the left, one to walk to the right and so on. So to do that I will export this variable so we can edit on the inspector here. So we have this already. So I will create four inherited nodes that will just implement this direction here so I will just set this vector. So one pointing to the left, one pointing to the right, one pointing up and another pointing down. So we can instantiate and associate this specific command into let's say a button or something like that. So I've created this walk family already so we have the walk up which have the vector two pointing up, walk right, walk left, walk down and now we can associate each one of these to specific events of our game. So I've created a small setup here. We have an actor here and this actor has some buttons. These buttons are custom buttons that has a spotted packet scene that will be associated to these buttons. Let's set this, we have the left, let me open the commands here. We have the left here, then the right, up and down, down, yep. So these buttons will have the button up signal connected to this actor. So I'm using this controls node to make this so let me open this. Basically it just connects its commands to a receiver so remember that the observer pattern asks for a receiver. So we use the connect method to connect the button up to the method add command of this receiver and passing the command that is attached to these buttons. So we'll basically just pass this packet scene to this actor here. Since we are connecting to this add command method we will receive a command and we will create an instance of this command and since the commands, remember let me open the command actor commands here, it asks for an actor and for a grid. So if we go back here we are setting the actor to be the actor itself and the grid to be the parent of this actor which will be a tile map. And then we go to the command queue which is this node here and we add these commands as children of this command queue. In the command queue we have two methods, one to execute and another to un-execute and note that I just named these methods like this just for convenience but this has nothing to do with the actual command pattern. So in the execute method it will batch execute the commands that are its children. So it will go to each of these children and execute them with a delay between each execution. So a 0.5 seconds delay. And on the un-execute method we take this children array so we will get its children and we will invert this array so we will un-execute it from bottom to top. So on a filo order, so first in, last out order. Here we have a fitful order, first in, first out and here we have a filo order. So it will go to each of its children, actually this inverted array of children and un-execute each of them with a 0.5 seconds delay as well. So this is how this will happen. Then I have another small setup here for the game, quote marks game. So you can see that we have the actor being a child of the grid. That will be the grid that it will pass on to the commands. And we have a play and unplay button which will basically just get each of the child of this grid and un-execute or execute its commands queue. So if you go here, we have this on the unplay, we have the un-execute version of this command queue and then on the play we have the execute version of the command queue. So let's play the game and now if I go here and press each of these buttons, so let's go and down, down, right, right, up, left, left, up. When I play this button it will execute the command queue. Let's take a look on this command queue. I will go here in the remote sync tree and we have the actor already open here, command queue. We have as children of this command queue, we have walk down, walk down, walk right, right, up, left, left, up. Just the way that we press the buttons. So let's go back here. When I execute them, there we have it. And then since we don't take rid of these commands, we can un-execute each of them. So we can go back in time and just rewind what we have here. So I will go here and unplay and you can see that we have it un-execute each of the commands that we have here. So I was talking in Twitter, if you don't follow me there, please follow me there, that this is a very good way to make a rewind mechanics. So let's say you have a actor that has a command that set its velocity, that set its speed to 100 on the positive horizontal axis. So you can have an unversion of this, I mean a version that un-executes this command that will set this velocity to be negative 100 on the horizontal axis and then you have your character walking forward and then backward and you don't have to keep track of the vectors that led your actor to the position that it was because now you just have to un-execute command, you just have to un-execute actions that your character did. So this is very convenient for rewind mechanics I think. And this is it, I hope you enjoyed it, if you have some doubts or if I say something wrong please correct me in the comments below, I'll be more than happy to help you and to get some feedback as well. Also don't forget to leave a thumbs up if you like this kind of content, this is a very good way to know that I am on the right path into delivering content to you. And don't forget to subscribe as well so you get this content when I release it. By the way, if you like this kind of content, if you want to support my work and what I'm doing here, you can become one of my patrons. So that's it, I hope you enjoyed it, thank you so much for watching, keep developing and see you next time.