This video is a reupload from my other channel. From now on I will upload videos about video game development and Godot on this channel, subscribe to stay up to date!
@@TeslasMoustache419 Apologies! When uploading this one I had to delete the previous one, and there was a period of time where there was nothing uploaded, but now it's done =)
absolutely phenomenal lightweight video. im working on my first project and was looking on how to implement grid based tactics characters. characters can get captured by either team so this makes that aspect very intuitive. i just changed player_controller to character controller and command all characters on the screen like that. and even better if i want them to walk to certain spots on the map after special events i just have a neutral AI that just sends a grid coordinate and lets the player code handle the pathfinding. thank you!
The Command Pattern works like a charm in board/grid games as you mentioned. I'm glad it was useful to you! And thank you very much for watching the video!
I think I would have tried to use animationplayer. Disable the player inputs and just call the players commands in animation player. That way you can also just make a new animation for each cutscene.
ty for this video. helped a lot for my first gamejam. wanted to have ai-controlled characters. made a base-character getting controlled by different types of controller. works fine.😊
Man, this is such a cool pattern; it's a bit complicated, but I can see why this could work at scale. Although, I wonder if instead of using a smelly stinky chain of if statements, the AI controller could just await finished signals from commands and timers like this: await get_tree().create_timer(seconds).timeout command.execute(...) # emits "finished" at the end await command.finished The AI controller might not even have to use _process / _physics_process, just have the chain of events called once the AI controller is initialized, maybe. If that's the case, maybe chains of events like these could even be turned into resources for reuse :D
The example I give in this video of AiController is so that you understand the concept. As you say, this type of class must use more sophisticated mechanisms, but I did not want to implement them because they would only make the explanation much more confusing and would move attention to something that is irrelevant to the pattern I am trying to explain in the video.
Yeah, I don't see why not. One should mix all the patterns that one considers necessary so that the code is flexible, clean and clear. And yes, I would mix it with a state machine.
One question about this pattern. Suppose its not an action game but a turn based rpg. Would you have a controller for the map scene and a controller for the battle scene? Would it be best to use the same controller with all the commands and then just filter what you use in each scene?
The specific case and needs would have to be studied, but if the map scene and the battle scene are different components, each with its own peculiarities, yes, each one should have an independent controller adapted to its needs.
Thank you for this tutorial But why use a container controller in 8:53 if you can only use one command at a time? Is there a reason rather than storing the command in a simple variable?
You are welcome! The reason is so that the current Controller can be added to the node tree. ControllerContainer is simply a Node to add that class to.
Really interesting. Similar to UE input system. Btw, I'm always curious about implementing good collision response programming structure. I don't thing it is good if the GameObject instances have hard coded response on it. I'm thinking about creating collision response library for the GameObject to inherit or ref from it. But not sure it will scalable. What your advice about the good way to implement this in Godot? Thank you before.
In my opinion the advantage of using high-level engines like Godot is that all these basic functionalities are already implemented. If you want to go down to the level of creating your own mechanisms, perhaps it would be better to use a framework instead of an engine; but of course that's just my opinion. Specifically in the case of Godot, collisions are very well integrated into classes like CharacterBody2D.
this is so confusing. i used this in a pong game as exercise. in the main menu i select 1 player or 2 player. depending on the choice i set player 2 to the AI or to a player. it's fine with AI, but the player2 is where i struggle. as a bandaid fix i simply duplicated the human controller and changed the variables for the keys. it's fine in such a simple game, but it's undesirable, since if i make changes to the human controller in the future i also have to make changes in the duplicate. i tried extending the human controller, but then i'm one inheritance layer too deep and can't reference the HumanController2 script in the same way that i reference the HumanController script.
@@GameDevWDavid i want to have two people be able to play against each other. i don't know how else to assign different controls to the HumanController.
@@simpson6700 Oh I see, in that case you can't use a duplicate of HumanController, since HumanController receives keyboard inputs for only one player. In that case you should have two different classes, for example HumanControllerP1 and HumanControllerP2, each with different key mappings. Of course this could be improved with an abstract class one level higher to avoid duplicating code, but for now I'd go with it.
Call me simple, but I just don't get how splitting up player input from a single script you can read through into 7 different scripts you have to page between just to follow the logic of making an attack is supposed to be a better system. There HAS to be a less convoluted way to do this.
You could just have a series of Boolean variables in the player script that trigger movement functions alongside inputs. Then add a “command” node with a trigger (collision, area node, etc) that shifts the player variables. For more complex cinematics you can use timers, multiple area triggers, etc. So like what he’s doing, but without all the extra scripts and steps.
@export Var iscontrolled:= false @export Var goright:=false Func right(): if iscontrolled: if goright: player.position.x+=1 goright=false else: if Input.is_action_pressed(“right”): player.position.x+=1 This is off the top of my head for what you’d see in the player script. The control node’s script would just be sequences of variable changing on timers or something else, and this could probably be optimized, but is a general idea
you might as well just show us the code and let us figure out because you don't really explain how anything works...you just write lines and lines of code
I try to follow an entertaining style of explanation, mixing minimal theory with practice. If you watch carefully what I do and say you will be able to understand what I am trying to explain. This video was on my other channel and had about 14K views, no one at any time told me that they didn't understand what I was explaining. What may be happening is that perhaps you are more interested in the purely theoretical, in that case I recommend that you look directly at the book on which I base myself to make these videos: gameprogrammingpatterns.com/command.html
If you are having difficulties with understanding what is presented in this video, you should start slower and work on your foundations. Stuff done here is pretty straightforward and you shouldn’t struggle with it if you’re watching this. What is being done: 1. Create a base controller class that defines common methods to control the character. 2. Abstract the logic in the player class to use this new controller by creating the based HumanController. 3. Create an AIController that will be the controller that takes over when a cinematic is taking place. Everything around these 3 key points is just boilerplate code that you should be able to comfortably interpret. If you’re not comfortable, I suggest to just go back to the basics and then come back and try again. Also, your complaining tone is not great. You are getting a video with useful information for free that someone took the time to make so… A little bit of respect comes a long way when giving your opinion.
