So, I’m on a kick lately to figure out some basketball game mechanics and was curious what the group here would do for tracking where a player is in a jumpshot to determine how close to the apex he/she is to track when the user should release the button pushed to shoot. I’ve got a jump mechanic using velocity, but I’m not tied to it because I’m not sure how to track where the player is in relation to the height of his/her jump.
So, to clarify, I want to set a jumpheight (or time, if better) and start jumping when the user presses a button and then capture how close the player is to his jump height when the user releases the button. If it could be returned as a % of how close the user is to the player’s max jump height that would be even better.
Thoughts on best implementing this? I’m open to any option that makes this easy to implement.
Thanks!
Assuming constant gravity, the physics equations that govern ballistic motion are known as dynamics. Wikipedia has a great article to start you in on the mental tools necessary to reason about the problem.
As far as the specific problem of finding out when the player is at the top of the arc, it will be when his motion changes from going up (velocity is positive on the Y axis) to not going up (velocity is zero or negative). On that frame he is at the top of his arc.
Basic dynamics equations can give you that time, but Unity (and all physics simulations) occur in discrete time intervals, not continuous time the way the real world works*.
- Disregarding quantum effects for my definition of “real world”
Good stuff, but I also need to know before the player reaches the top of his jump, perhaps how close he is to the apex… I’ve managed to get the apex based on that change in velocity approach, but it doesn’t help for my “shot release” indicator of how close to the apex the player is, either going up or coming down from his jump.
Wouldn’t the magnitude of the vertical velocity give you a start on distance from peak? It’s not linear, but if you want linear, you can check the time of release, and the time of the peak (just read it from Time.time
and take the difference) and that would be a linear indication of how close it was to release.
Yeah, I’m going to experiment with that time diff idea… Still open to ideas on implementation but I’ll report back with anything I come up with…
It sounds like the game mechanic would be a lot more fun if you focused on time rather than height. Measuring jump height seems more realistic, but harder for the player to get a feeling of the mechanic, because height can change a lot depending on small differences of gravity, jump force and velocity. I would suggest something like:
private float airTimeTarget;
private float jumpStartingTime;
public float threshold;
void OnJumpPressed()
{
airTimeTarget = CalculateAirTimeTarget();
jumpStartingTime = Time.time;
}
void OnJumpReleased()
{
float timeDifference = Mathf.abs((Time.time - jumpStartingTime) - airTimeTarget);
if (timeDifference < threshold)
{
//Player jumped correctly
}
}
The threshold could change depending on difficulty settings, there could be different thresholds for different airTimeTargets, and the reward could be calculated in proportion to the time difference instead of on the basis of a threshold. Then, the nice thing about this, is that your jump doesn’t have to be physically accurate, so you can just do an animation and adjust the root motion and animation duration depending on the airTimeTarget. This is good because it’s a lot more intuitive for players to know when to release the button by looking at an animation than by looking at a position that can change a lot between frames. Another advantage is that it makes it easier to really exaggerate your poses and the curves of your motions to make this feel cooler; i.e. the vertical velocity can change a lot slower at the top of the jump, and even pause for a little while.