Undo and Redo with the Command Pattern - C# and Unity
Вставка
- Опубліковано 31 лип 2024
- The command pattern encapsulates commands from the systems that execute or undo those commands. This is useful in asynchronous applications and is useful to create undo and redo functionality.
0:00 Intro
2:25 ICommand Interface
3:00 Move Command
4:00 Turn-Based Input Manager
5:06 Turn-Based Character Controller
6:00 Undo System
7:28 Redo System
9:15 Command Handler
10:43 Final Thoughts
11:23 THE END
Programming Pattern Files: github.com/onewheelstudio/Pro...
Become A Channel Member: / @onewheelstudio
T-Shirts: onewheelstudio.com/merch/
My video and streaming kit: kit.co/onewheelstudio/tutoria...
Recommended Game Design Books: kit.co/onewheelstudio/game-de...
Discord: discord.onewheelstudio.com
Patreon: / onewheelstudio
Twitter: / onewheelstudio
Devlog: onewheelstudio.com/
Twitch: / onewheelstudio
#Programming Patterns #CommandPattern #GameDevelopment #cleancode #unity3d
For those who like written tutorials! Command Pattern: onewheelstudio.com/blog/2020/10/24/command-pattern-encapsulation-undo-and-redo
great video, clear and well explained.
In general though I would personal favour a "stack" instead of a list as by design you can push and pop the commands onto the undo redo stacks and avoid having to maintain indexes etc. Also while I 100% agree on encapsulating a commandhandler/manager It is still ill advised to expose that implementation detail out of the character. If a character can undo/redo his movement it shouldn't matter how that happens, if it is delegating or not, so to avoid Law of Demeter violations I would keep the Undo/Redo calls on the Character and internally delegate them to my handler `public void Undo => commands.Undo() ` etc.
Love your style of teaching, you earned my sub, sir! You mentioned behaviour trees in the state pattern video and I'd be delighted if you made a video about that topic.
such a nice and clean tutorial
this channel is really awesome. Thanks for another great video!
Good tutorial. I would like to mention, that I prefer to use Stack in such case. More flexible and code looks more elegant. Thx for sharing such great explanation of this pattern.
Why doesn't this guy have more subscribers? Goldmine, thanks
I would have created a new list for redos that got cleared if you enter a new command. Undo removes a command from the list and adds it to the redo list. Redoing removes it from the redo list and puts it back into the main command list.
I never though about using object pooling for the commands! what an intelligent idea
so well explained
Ty for your work! :)
thanks for sharing your knowledge! +1 sub, greetings from Bolivia
I'm glad it was useful!
thanks, great video
Is there another pattern you'd like to see covered? Which one?
Flyweight ?
MVVM? Has this been tackled already?
It is my understanding that it would play well with Command patterns.
Bridge Pattern
Factory Pattern
I think adding the undo command to the list is better done after execute. If execute fails, and you want to run the undo, the last one failed, and the undo will fail.
Hey, thank you for your tutorials. Do you think it would be possible to make a tutorial on aligning an moving object with uneven terrain, especially its rotation? For example if my cube goes up a slope it should rotate to match the slope angle. Its the rotation part to align it with the terrain that I don´t understand how to do in bolt. That would be such a great help and there are no other bolt tutorials that tackle that topic.
I probably won’t be able to make a tutorial that is that specific, but the first thing I would try is to raycast from the object to the terrain. I *think* you can then get the normal (vector perpendicular) to the point you hit on the terrain. From there you may be able to align your object with that vector?
@@OneWheelStudio Thanks a lot for the answer. That was exactly my approach to get the terrain normal via raycast hit normal and then set the transform.up of the object, but it always resets the rotation of the object. It has something to do that transform.up uses local scale instead of world scale and as a beginner that´s where I get problems, so I was hoping that you maybe can help, but if its too specific I´ll just continue my google search for solutions. :) thanks again for taking the time to answer
I've watched the observer pattern video dozens of times and have fully integrated the pattern into my own project. Although I understand not wanting to deviate from a 'pure' command pattern, I think it would be far more useful to show the command pattern together with the observer pattern. I won't have any trouble converting it over when I'm implementing it myself, but people new to observer might have trouble. Perhaps you could make a new video, something along the lines of 'Integrating observer and command patterns', which could cover this topic.
I wouldn't worry to much about deviating from a pattern. I see them as a framework to be modified for the current situation.
In terms of integrating the observer pattern, in my mind that would look something like invoking an event when a command is executed or maybe when it's undone. That might be a static event that anyone can listen to or it might be a "callback" that gets passed in along with the command. This would let the object that created the command know when it was executed.
I can see this being used in tutorials for any game, where you want to progress through particular moves and allow the player to go back to a previous step.
Would this be overkill for that or is this exactly what you'd use?
I’m not sure exactly what the tutorial or game looks like so a bit hard to say. My gut says it might be overkill, but depending on the game it might be perfect. I wonder if it could be used beyond a tutorial too? Can it be used for a similar mechanic in the game?
Im still cant understand the difference between this one to memento undo redo
pks make more design pattern tutorials.
No promises, but any pattern in particular?
I guess, we can use two stacks for undo and redo
What I can't quite understand is how all this abstraction actually helps with the logic? Can't you just have the list of commands directly in the code instead? Why do I need a middleman?