Dealing with Godot's root motion bullshit once and for all
Vložit
- čas přidán 22. 05. 2024
- In the last episode of my character controller series I did a mistake when implementing a small root motion feature. The whole situation threw me off guard, stained the reputation and ruined the end of a beautiful series. I wont reapload anything and will leave the stained video forever in that state, but I returned with the revenge. In this 4.5 episode I will extensively discuss Godot's root motion algorithms to achieve deep understanding of what is going on when skeleton animation is being played. Then I'll suggest a nuclear solution for all root motion problems for all eternity, that is suitable both for classical Godot's logic-inside-animations approach and for my beloved decoupling of model and presentation.
00:00 What went wrong
02:07 Review of bad ways to fix root motion
04:40 What is the real cause of all this
06:24 Despair and insight
07:57 Nuclear solution
It took me months dealing with godot root motion issue until finally found the proper solution.
WHOOOAAAA
Mom, I'm on TV! I've just recommended your video under one of my owns a week or so ago. Sorry, I told your designs are questionable, but I want to stress, that the results are good nonetheless! And now I see you in my comment section in person :D. I'll probably release a small video about parkour in about a month and touch your approach a little more, to engrave my feelings about putting game logic inside animators, but I know what it takes to make a video, please, keep it up, its very inspiring!)
Please never stop making these videos!! I've been currently applying all knowledge in my own gamd
Hm, i stumbled upon this channel because i wanted to make a game in godot as its open source and seemingly growing. Then i discovered you need to know how to code and i dont have any previous experience and i dont know what im doing, and the frustration is adding up after a week of not being able to program a fucking camera moving in the play test. So, the thing im curious is, the game im trying to make has a 3d combat system of 3 sides (for now) that you can attack, up, right, and left, controled in a simulated widget. im trying to make the same combat system as the game For Honor has, but im thinking about making it a lot more input-intensive to take the system to its full potential. Do you think its really more dificult than to make a more traditional combat system like dark souls, or maybe even easier? I wonder to see a response from someone who actually knows and has some progress about making a game and its combat mechanics
Haven't played FH, sorry. I heard, they have a system that switches your stand dependent on the joystick position. If guard changing isnt a move with an animation, but simply a short hands reposition, I wouldn't have them as Moves, but simulated them with blending or with arms IK. Then input gots a new field - the variable for guard input. It can be left, right and up, but you then can create any number of zones or even direct hits with a vector. Your combat system layer then needs to store and change the parameter of current guard, and your moves need to ask for it. If there are 3 guard, I'd have three types of moves, like r_attack, u_attack and l_atrack, etc. If you want precise control with "infinite" guards decided by vector, I'd have one move that changes its animation and does some dark magic with blending and IK for arms.
Thanks for the great videos!!
Hi, how would you do a sword sheath system with your state system? Something seen Zelda BotW, where you take your sword out and then only do the slashing, and you can also put it away.
Haven't played, but I'll try by the intuition to describe some abstract sheathing. First you'll need to create a working layer for managing your ammunition. Something that is aware of your weapons and other probably grabbable things. You clearly have a "sheath socket" on your character back or pelvis. Then you need to add two new states: sheathing and unsheathing, two short animations that just linger and manipulate your ammunition layer in the end of the lifecycle, for example, sheathing marks your sword as sheathed on the back before transitioning. Then your visuals code needs to become smarter, now it doesn't blindly snap sword visuals to the right hand, but tracks its resting position between sheathed and unsheathed states. If you want your sheath states to be unblocking for action, you can sort of make them interruptable by anything by including the code similar to run, when they pass priority to any more suitable input, such as attack skipping unsheathing, for example. Then, most of the games with unsheathing usually make this animation sort of "parallel" with the legs action to be able to epic unsheathe while running. To achieve this, you will need to make use of animation blend tree, make it for once do the thing it is supposed to do, there are filters, so you can record your sheath animations for your hands only and then blend it with any other movement action you want.
@@PointDown Thank you for your detailed response! A working layer is a node that keeps track of stats such as a sheathed boolean or arrow count?
@@dude2542 Yep, as with resources example in the video. A separate class that sole purpose is to hold the information about your current active ammunition. It can have only a weapon_sheathed boolean for now, but you'll quickly find that it has a surprising amount of functional. It can hold information about all your equipment, offhands, two-hand wieldings of something, maybe it even tracks consumables and holds the info for something like a quick access radial menu on your middle mouse scroll. Then your states can ask that class if need be, for example, your combat system can use it when validating input package. It scans the input for an attacking command. Then asks your ammunition layer if your weapon is unsheathed. If it is, it translates the attack to the attacking move, but if it's not, it ignores the attack command and swaps it with an unsheathe command. So your attacking button now also pushes the character from the peaceful state to battle ready mode, as probably 50% of games do.
@@PointDown Did you study software engineering in school? Did you read a book on game development, or how do you know so much about data types? I am hopeful that your channel will grow, your content is so deep, it might require some rewatch once and twice, but overall you teach so many new things. Simple put currently you are my favourite teacher on the internet, next to Sebastian Lague.
@@dude2542 I had a really good programming base experiences in what I believe called highschool, but after that didn't pursue programming education in a university, but saved it deep in my heart and studied myself. I considered myself backend specialized and my best language is Java. I read one book about gamedev, but can't remember the title. I also consider my Godot knowledge base end experience rather limited, I picked up gamedev as a hobby last autumn and chose Godot with main argument being "I hate C++ so no unreal and I adore C# but hate Unity editor, so no Unity" . I might as well have much less experience with it then my viewers. As you can see, considering gamedev I'm almost a fraud, but I certainly can tell something about system analysis and systems design. I tend to apply general software engineering wisdom to my systems without making allowances for the fact that "we are creating a g a m e, take it easy". I decided to create the channel mainly because I saw glaring holes in some practices suggested to beginners by other creators, and I am too hopeful it'll grow). Thanks for the kind words, stranger ^_^. Considering data types, the general "you need to know data structures and algorithms" motif is a hoax. About 80% of problems are killed with dictionary structure. Essentially you need to understand the difference between dictionary, queue, stack and list and solve about 50 easy problems. Then it'll be usefull to understand how big O works and the difference between several sorting algos. The rest is elitism.
Слышу русский акцент. Может ещë и на русском языке начнëшь делать?
Не, не думаю. Мооожет быть, заморочусь с субтитрами когда-нибудь.
Причём сильный)