Video

Thanks for the support! Giving the current audience intention, multiplayer will be discussed somewhere in the middle of August or early September ^__^.

Ah, man you'll miss on that, sadly(. What I've meant by combo is a long line of attacks, that is invoked by a single button, but consecutively. i.e. You have an attack button, but the second pressing during the hit_1 will invoke hit_2 and so on and so on, untill you'll break the series and leave attacking for some time, putting the series progress to hit_1 again. With a twist that I'll flex with creation of 5 different attack lines of 4 attacks from 6 assets only). What you are talking about is fighting style comboing, like MK-ish fatalities etc. The implementation isn't so hard, I'd probably do a video on them if people will be interested in MM sometime in the future. But if nothing magical happens during my absence, MM is probably paused till at least August to make space for enemies and AIs :D.

​@@PointDown aw dang[

I might have misunderstood your question, but the whole thing doesn't have AnimationTree at all. Animation is done in a simple AnimationPlayer node named as SkeletonAnimator in HumanoidModel scene. The building of this all from zero is shown in the long version of controller series, animations precisely are in the 2nd episode. Can I ask what is your end goal, what did you mean by swapping out for different usage of animation node, and what animation node exactly did you speak of? Maybe I still could help.

@@PointDown ah yes looking I saw that. M end goal is to ultimately replace the animations with my own attack and such. I thought this was an easier system than doing animation blend tree and such but looking at the scripts I think I'm a bit confused as to how it calls and such

@@sanparuzu Ah, this system is indeed much easier than AnimationTree nodes at this point. It calls to animate at exactly one place: HumanoidModel's root node Model, in the method switch_to(). The general idea is that we have a state machine representing the character, and the animation player is just set to playing the animation for a state. When state changes - animation player changes animation too, that's all the code about animations here, plus some custom blending timings written in an ugly way in the AnimationPlayer's script (I plan to implement them as a table later, maybe, this is a demo anyway). The harder part is how to work with animations of attacks, because most of attacks have a root motion component. I have a video about root motion on my channel, it's a bit advanced if you aren't familiar with Godot's animation resources. BUT!) I scheduled a video that contains my animation import routine, more than enough info for you to change everything to your own animations. It is scheduled to 21.06. Sadly I won't be able to answer comments under it till the end of the month.

It's the guideline for an input on "what to do if several options present". Imagine your player has 1 HP and they see an incoming hit from the boss. Panicking, they managed to press Crouch, Attack and Evade buttons in one input tick. Without inputs sorting, we'll probably default to random or the first in an array, which is not consistent and is probably a vile design. I'd say, player will be much happier if we just let them Evade the attack every time this happens. Sorting inputs by priority gives us a way to do this in expressive way and with great scalability. Moreover, ease of change is also here, with one number change I can make the system prefer an Attack over roll in this situation, if, for example, our combat has a mechanic of parrying attacks with an opposed attack (f.e. Holloknight). That's will be infinitely better than manually changing order of if operations in every state.

Hi) I cant fully understand your question. Animations are sort of glued together with the skeleton, you cant change the skeleton and continue with old animations, you need your tracks names to match the bones names. I maybe misunderstood you, anyway, if this is the case, I scheduled the video with my animation pipeline to 21.06, maybe you'll find something interested there.

Well, this problem doesn't have a single solution, but a gradient of measures. Previous MM episode has a little section on animation scaling to match legs movement together with velocity. Then on top of that, many games use inverse kinematics for legs to snap them to the surface and diminishing the cringe on slopes and stairs. Then you can forbid into-a-wall-running by sensing walls near and your legs will stop slide, as the character is standing idle.

Well, as I said, the goal defines the results perception. I am not creating a game about crazy parkour, hence the ultra control being undesired, if one want to create a parkour game, why not allow ultra control, yes. This is the reason I am showing 2.5 ways of dealing with the problem and do some commentary on acceleration / rotation natures of fall control for broader audience to choose.

The game is Overgrowth. Creator has amazing blog posts about dot and cross products under a Wolfire Games name.

Yup, nice idea, but the whole wallrunning is an overkill imo. If I'd need to polish this further, but left as is, I'd just add an animation of soft knee/foot kick-off from the wall and landing, then prohibited to run into the wall, if I'm near it. Godot actually has a built-in CharacterBody3D.is_on_wall(), so easy to implement. Maybe I'll do it in the future if MM gets some love and I'll continue with parkour.

может быть позднее, доработанный

Yup. GDscript is ok, but I still like C# much more. This channel could very well be a Unity channel. Better language, better existing content, has their nice DOTS to exercise the brain. But the fucking editor casually consumes 3.5 gb memory plus has a memory leak on top if you activate ECS stuff. And VS on top of that. Yeah... And here we have Godot, that is still a bit raw at times and crushes regularly once a week. Well, guess what, to close crashed Godot editor and reopen it again takes about 15 seconds :D. My heart forever with it at this point.

Check Move.react_on_hit() in my demo and the Staggered move heir. After that, just rewrite reaction and maybe have an animation for being knocked back.

5:52 is an explanation for orbiting vector. Base orbiting component is an input component. Orbiting curved then is strictly defined. And why is orbiting is lower then the circle - is "an implementation sense" detail. Orbiting component is the orbiting velocity of the character *per frame*. This is about 0.05 meters for a realistic running human speed, because a second has 60 phys-frames usually in 2024. And the camera arm length is just the camera arm length of several meters. Surely, the geometry problem solution will break on hight speeds, but you need to have 400+ km/h for it to start, and if that's the case I doubt you need a soulslike camera. The diagram has these proportions just for illustration purposes.

Nah, to work daily in Mordor, you need some drafting questions figured out with government, by what I mean get fucking shot in foreign land for the war that isn't yours, if you are able to walk. And I'm softly kiting the whole thing in internal emigration. I do some side-hustles with gray payment here and there. I'm mostly doing these vids out of spare time surplus and to save sanity via the creative process). P.S. Sorry for the late answer, for some reason youtube ate the notification, I saw it randomly reopening my vid(.

@@PointDown Good luck man, glad you're still with us. War is an evil of the powerful, and sometimes our art is all we have. I'll keep boosting your work on here as long as you keep feeling like posting it 🔥❤

Yup, but I am happy to throw any additional algorithmic complexity as long as it saves me human readability. When I spoke of branching, I spoke of literal ugly if wall in my states that got eliminated by automating the choice. The overall complexity of operations on such scale is minuscule, with or without this addition, the frame time doesn't change, I have a small performance check in the end of the 3rd episode for the series. P.S. Sorry for the late answer, for some reason youtube ate the notification, I saw it randomly reopening my vid(.

@@PointDown thanks for the response however "late" you might think it. Said complexity figures are also basically always calculated at their worst case, and for most frames that is not the case for this design.

Yes, there is. I am a fun of do it yourself concept and probably would implement my own solution directly working with skeleton. But there are actual physical bones in Godot. Setuping them nicely is tedious, but the result can be jawdropping. I don't have any videos on the subject, you can check this one czcams.com/video/0MHY2TDeMLM/video.html. Also you can search for inverse kinematics for legs tutorial, they also are touching the theme of manipulating skeleton while having an animation to play.

@@PointDown wow this is amazing. i'm gonna try it out on a next project. the most stuff regarding manipulating bones was a simple "look at" solution for bones like the neck which I posted in my channel. It's quite basic and does not have smoothing but I managed to improve it earlier

When I heard the term "dependency injection" in the last video I thought I was back at work doing PHP lol

Thanks for feedback!) Considering tilting, I'll write the idea down, but probably not earlier than September, as I set for myself at least two more series goals. Fast answer for selfresearch - modify your movement Moves to distinct behaviour between turning and running straight (probably by remembering small amount of recent delta-velocities). Then make your torso tilt a littlebit. This will make your legs bahave awkwardly, so you'll need to replicate what industry does - inverse kinematics for legs. Godot has some guides in that field, here's, for example: czcams.com/video/G_seJ2Yg1GA/video.html . With a little bit of tinkering it is compatible with my skeleton-skin dividing beliefs. P.S I am making the last controller cycle video and my github has code for 5th branch already. There is a small node called DEV_ROOTFORGE, its an unpolished dev layer instrument for auto-baking root position tracks. Can be hard without commentary, but you can read it and research functions with docs. The issue it helps to eliminate is that animation player can't have a position track, so we are baking skeleton's position track into "value track" on backend animation that happens to be a Vector3 value track.

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.