Richard Hinckley, Sr. Learning Resource Engineer, returns to the livestream to discuss data-driven character movement. We’ll demonstrate how to use curves to affect the feeling of your game’s character controls. Friction, acceleration, jump arcs, and even gravity can all be altered with curves to create a unique feel for your character.
This is similar in spirit to my previous stream about the importance of camera code. I’m not sure about Paragon animations, but the idea here is to show how using curves to control aspects of character motion will lead to better-feeling movement and control than using pure, standard mathematical functions or linear blends. We’ll be using a really basic setup to show the differences in how movement looks, stripping out animation, camera work, etc. to get to the core of the movement itself.
Anyway, I think this material is an important part of a GPP’s fundamental toolkit, like the camera concepts I showed last time. I hope you like it!
Hi there Richard, great stuff as always!
My question didn’t get addressed in the live stream so I was hoping you could get round to possibly answering it here:
using the curve editing system you showed, how would one go about implementing a jump height variation depending on how long the player kept a button pressed ?
I understand that when WasJustReleased() is called, gravity kicks in - at whatever point you are in the curve. Am I correct ?
So, essentially, the behaviour I’m after is like in a 3D Super Mario game where you can tap the button for short hops or hold the button down longer to give yourself more height.
Yes, that’s basically it. In my code here, you could probably just set the ActiveGravityCurve to nullptr or your fall curve whenever you’re off-ground and the jump button has been released and that would be the most basic part.
To finish it out, you need to know that you’re officially in the hold-to-gain-height part of your jump, so I’d say to set a timer when you start jumping, and then if you release the jump button in the air, you check the timer. If the timer is still running, you start your special fall sequence and deactivate the timer. You also deactivate the time if anything changes that takes away your height control, e.g. you land unexpectedly, you take damage and get knocked back, anything like that. FTimerHandle is pretty versatile…and now I want to do a stream about it. (No promises!)
The short answer is “it will work exactly as well as everything else related to netplay.” But we can go into more detail:
To address your mention of a movement component and something that was said in chat during the stream, yes, this Pawn code I wrote would be really good to put in a movement component. I only kept it in Pawn because I wanted a quick and dirty thing so I could stay focused on curves. So you absolutely could take this code concept and put it into a Character Movement Component or Pawn Movement Component if you like using them, and in many cases, that would be the best practice. There should be no new issues with networking because the curves exist as data assets that all the clients (and the server) will have. All machines in the game should be able to predict movement just as accurately with a (known) curve as with a mathematical formula, and server correction should only happen in cases where it would have happened anyway. What messes up net games (aside from unavoidable realities like packet loss) is when a machine does something that other machines have no way of knowing about. However, in this case, as long as they know you’re jumping, they should know what your jump curve is because they have everything they need to figure it out or look it up on their own.
Of course, I didn’t write this code properly for networking since I was just trying to demonstrate what curves can help you accomplish, but if you have decent networked play already working and simply swap curves in for mathematical formulas, it will work exactly the same with regard to net play.
This depends on how your mental model works. Two concepts come to mind. One, look at where your input vectors are applied and add the curve-based movement there. Two, look at where your input vectors are collected in the first place and add another input vector for motion coming from curves.
Depending on what you’re doing, you may need different information, or you may already have all you need. A simple way to apply curves might be to have a few “curve slots” like jump, dash, etc., and in each slot, you can place a specific curve and a starting time. Then you sync this up, and it affects velocity or position appropriately. However, this depends on how your model works.
That’s a good question, and I don’t think we have documentation aimed at that specific issue. In general, our documentation focuses on how the systems work, but doesn’t dive too deeply into how you can modify them or build them out. I would start by thinking of movement components in general, rather than specifically “character” movement components. We have template projects with different types of movement, such as top-down, side-view, full 3D third or first person, and even vehicles. As you may be able to tell from the stream, I generally write my own code for systems like camera, controls, and certain aspects of physics in order to get the exact feel I want. Studying character movement component as a base is a good idea, and expanding it is viable. As a learning exercise, you will probably pick up more if you study and then build your own, so there’s no “mystery code” inherited from the parent class.
I hope this helps to clear up the questions you had. Thanks for watching and posting!
Excellent, just what I was looking for. Is there any chance you could have a live stream about making such “start from scratch” pawn movements, having network replication in mind. Things like motion prediction, latency, authoritative corrections done by server and etc… While having a smooth experience on client side.