When you press the jump button, no animator draws an arc. The game does a tiny bit of maths, over and over, many times every second. Once you see that, a lot of "game feel" stops being magic. You can tune it, and you can break it on purpose.
Every game runs a loop: read your input, update the world, draw the picture, repeat. One pass around that loop is one frame. At 60 frames per second the loop runs 60 times a second, so each update covers about 0.017 seconds of game time.
During the update step the game moves things. To move a character it keeps track of two numbers: its position (where it is) and its velocity (how fast and in which direction it is moving). Each frame it does two small steps:
velocity = velocity + gravity × time_step
position = position + velocity × time_stepThat is nearly all of a jump. Pressing the button sets the velocity to a big number pointing up. Gravity then pulls that number down a little every frame, so the character slows, stops at the top, and starts falling faster and faster until it lands.
There are just two dials here: how hard the jump launches you, and how strong gravity is. Change them, press Jump, and watch the arc. The dotted line is a prediction from the formulas below; the dots are the real frames the simulation ran.
Notice two things. A faster launch makes the jump both higher and longer. Stronger gravity does the opposite: the jump gets lower and snappier. Many platformers use gravity that is much stronger than real life, because a heavy, quick fall feels responsive. A floaty jump is usually just low gravity.
You don't have to run the simulation to know where it ends. With launch speed v and gravity g, the peak height is v² ÷ (2 × g) and the time in the air is 2 × v ÷ g. That is what the dotted line and the readouts use. Designers often work backwards: "I want a jump about three character-heights tall that lasts half a second", then solve for v and g instead of guessing.
The simulation moves in steps, so it is only an approximation of smooth motion. Slow motion above runs the same maths with a smaller step so you can see the individual frames. If a game let the step size follow the frame rate, a slow computer would take bigger steps than a fast one and the jump could come out a little different. That is why many engines update physics on a fixed time step (often 60 or 50 times a second) no matter how fast the screen redraws. Every player then gets the same jump.
Once the basic arc works, designers add tiny cheats on top. Coyote time lets you still jump for a split second after running off a ledge. Jump buffering remembers a button press made just before you land and fires it the moment you touch down. Variable height cuts the upward speed when you let go of the button, so a tap is a hop and a hold is a leap. None of these need new physics, only a few more numbers and timers.
If you want to make this yourself, pick any beginner-friendly engine and build a square that moves left and right and jumps. Change one number at a time, the way you just did, and note what each one does. That habit, tweak a value and watch what changes, is most of what making games feels like at the start.