The Bad Jump Design and 30 FPS Gravity of TMNT (NES) - Behind the Code

jumping in a video game is complicated if you're a gamer and take to the controls then mission accomplished for the developers you don't care about mechanics if things feel right if you're implementing a jump in a game you have to make a lot of decisions and hope those decisions do not frustrate the gamer and then after decisions have been made implementation demands math what is your starting upward velocity and what is gravity that should be enough to get things started and also send you back down to the ground but before you deal with allowing the player to land one big question is does how long you hold down the a button affect how high you jump if it does starting upward velocity and gravity aren't enough you have to compromise your physics during the middle of your jump turtles compromises physics and arguably does not do it very well one button is responsible for three types of jumps let's break down tmnt's jump implementation we're going to get technical what is gravity in physics it's a fundamental force in game programming it's an opinion while perhaps the gravity on earth is a good starting point for implementing physics in a video game pure realism may compromise what is fun so with a bit of creative freedom at their side what steps does a programmer take to implement jumping along with gravity standard acceleration due to gravity is close to 9.8 meters per second squared how does this go into a game distance traveled can be implemented using a conversion to pixels possibly based on the height of the playable character for some form of accuracy but what about time meters per second squared do we need to keep track of time in an nes game if only we could make time a constant have the same amount of time pass between updates to player enemy or item positions on the screen wait we already have that the frame rate of video output to a television is more or less clockwork if the passage of time between updates is always the same 1 60th of a second in the case of the north american nes we can just tie physics to the frame rate and make time a constant we don't bog down the cpu with calculations just for acceleration due to gravity on every frame the programmer just adds a single magic number each time so a simple jump example might be player presses a button game assigns starting velocity to the player a gravity constant influences vertical velocity's value each frame and vertical velocity is applied to the player's position each frame we examine this in the ninja gaiden episode of behind the code the game adds just over 20 percent of a pixel each frame to push gravity's influence and wouldn't this value or other values close to it translate fairly well to other nes games sure so long as the game runs at 60 frames per second but how could it not didn't i just say that the video output frame rate is 60 frames per second to the television i did indeed but the frame rate of the game doesn't always match video output frame rate of the console that's up to the programmer and the efficiency of their code tmnt runs at 30 frames per second each rendered frame is output twice to the tv two questions how and why we've talked about the cpu and ppu working side by side in previous episodes of behind the code the cpu calculates positions collision detection and more to set up the next frame of video as the ppu outputs the current frame of video so long as the cpu can complete the calculations to set up the next frame game frame rate and video output frame rate match at 60 fps but what if there isn't enough time for the cpu to get the work done before the next frame is drawn to the screen no updates are specified for the ppu to render a new frame and the previous frame of video output is repeated this is unintentional and the gamer experiences slow down as the cpu continues to have too much work to perform inside a single frame's time if this happens too often during testing and the programmer cannot tighten their coat up enough to maintain 60 frames per second they may elect to design the game with a lower frame rate in the case of a 30 fps game the cpu can split the work across the time used for two video output frames the ppu draws each new game frame to the screen twice in a row and then receives the next game frame since the necessary calculations for the next frame take place every 30th of a second instead of 60th numbers such as gravity that assume a constant passage of time should be adjusted if the frame rate of tmt is half a 60fps game then wouldn't the gravity constant designed for around 60fps need to be maybe doubled for 30 fps possibly but again the value of gravity is still an opinion that said chip and dale's rescue rangers and teenage mutant ninja turtles have almost the same value for their gravity constant if we look at jumping of the game side by side these jumps are quite different in terms of hang time it's obvious that chip on the left returns to the ground a lot faster than leonardo on the right the difference gravity is applied every 60th of a second for rescue rangers and every 30th of a second for tmnt was this an intentional design decision for tmnt or was the gravity constant unaltered when the game was perhaps migrated from 60 fps to 30 fps during development the influence of gravity on your jump not only dictates how high you go but how fast you get there you ascend quickly and gravity takes longer to get you to the ground it feels floaty gamers call this a moon jump tmnt has three jump heights a short jump a normal medium jump and a high jump which is more accurately described as an automatic double jump more on that later the jump you make depends on how long you hold down the a button and now we've reached the crux of tmnt's jumping problem in my opinion the game requires you to make short jumps despite low gravity and this requires holding down the a button a very short amount of time with a quick tap despite being stressed about the jump potentially the nebulous physics do not include the human equation if anything you're going to tense up and hold down the a button longer than you want to make this short jump you have to press and release the a button within four frames if you fail to do this by taking too long to release a you hit your head and fall into the water let's dive into the mechanics not the water of this i wrote a script to log our vertical velocity during a jump i'll make a normal or medium jump to explain what you see here the three types of jumps are indicated here a one two or three will appear depending on the jump the normal jump is a one that's our current jump y is the current y velocity anim is the animation we see this will change when we hit jump three count is the frame counter for the jump maximum value is eight because the code only cares about how long the a button is held and holding at 8 frames put your turtle into the final jump the high spin jump no need to worry about anything after 8 frames the jump happens at 30 frames per second so 1 30th of a second has passed each time this number is incremented the velocity for each frame is listed in a box that appears at the bottom you can see our gravity constant of 84 over 256 is applied for each frame so in this case i made a medium jump by releasing the a button between 4 frames and 8 frames okay what about a short jump to execute a short jump we have to release a before the fourth frame so what happens when you do that vertical velocity receives a new value it's hardcoded to -2.44 when the code detects you let go of the a button before jump frame four this is how the jump is shortened your speed changes mid-jump physics start like any other jump as the game can't predict what you want to do when it sees that you let go of the a button before jump frame 4 it slows your ascent gravity remains unchanged it continues to be applied as usual but velocity is downshifted here the exact frame you let go of a doesn't matter frame 4 is the milestone check for a short jump or not all previous frames will have the same y velocity regardless of jump height what about the high jump if you hold down a for 8 frames or more velocity is reassigned later on this time the same starting upward velocity from the ground is used at frame 8 a value of minus 6. that's why i called this a double jump the game puts the turtle into a spin at this point this does two things it reduces the hitbox of the turtle and serves to distract the gamer from noticing they are in the air for so long we can disable the spin and get an idea of the hang time of a high jump it's pretty long since gravity is lower than your average nes game the turtles move upward pretty fast this does not leave much of a time window to release the a button for a shorter jump and perhaps passes a greater difficulty onto the player alright now let's look at the code this area increments the jump frame counter checks to see if the a button is still held down and alters velocity when necessary this code is easier to explain since you've already seen what it does thanks to the script we just used first thing we do is figure out if the a button is still held down next up if we are past frame 8 we skip ahead no checks are necessary after frame 8. otherwise the specific jump frame checks kick in if we are on frame 4 we check for a short jump here by looking to see if the a button is still held if it is we skip ahead if it isn't this is a short jump these values are used to reassign jump velocity the code for the high jump same thing are we on frame 8 if so check for a high jump if a button isn't held skip ahead if it is still held this is a high jump you can attack during a high jump to cancel the spin and that check is performed here otherwise the turtle spins under that the double jump value of -6 is reassigned to velocity the controller read starting upward velocity and gravity the items that make the heart of a jump are performed elsewhere but this is your breakdown of our code that loosens up the physics the question now is can we alter gravity and frame counting in such a way that jumping does not require such precise timing for a button presses here is the tug of war for jump design we could alter the code so the short jump allows the a button to be held more than just 4 frames the problem with this is that the turtle is still moving up with the usual velocity before the short jump activates and reduces that velocity that's too fast to take off speed to allow for more frames so now you have to compensate for this by increasing gravity for example keep the turtle from moving upward at such a fast rate that makes the jump landable however the takeoff distance from the ledge is tight because of the jump arc so maybe we should reduce the assigned velocity for a short jump to improve the jump arc this is starting to make a difference there is more forgiveness in the jump window as the a button can now be released prior to six frames instead of four the gravity tweak along with an adjustment to short jump velocity provide a more forgiving jump arc and gets the turtle down to the ground at a faster speed control on the ground is going to be much more responsive versus hang time in the air the only other item that is perhaps worth tweaking is the high jump velocity higher gravity means a -6 double jump v low on frame 8 is not going to get the turtle up as high as it did under default gravity perhaps -8 is the way to go to regain that high jump here are the rom addresses along with their old and new values plus the game genie codes to get us there i didn't select these values using fancy math i just did some trial and error until control started to feel right you may wish to spend additional time making adjustments to gravity velocities and more to dial in some superior controls for jumping in tmnt these values were enough to make a point the medium jump has all but been eliminated perhaps it would be even better to settle on a single type of jump and then implement a double jump with a second press of a to reach those higher platforms so if we finish up by talking about modifying tmt's jump design whatever jumping you have in a platformer has to be compatible with level layout if you experiment with altering or even gutting and rewriting turtle jump code i would recommend finding some areas in the game in an emulator creating a save state for each of them and loading them up as you make your changes this allows you to quickly test your changes and make sure the new jump logic feels compatible with all platforming and combat these areas of code give you your addresses for creating game genie codes or rom patches i'm interested in reading or even seeing any new jump logic some of you produce personally the shorter jump time getting back to the ground faster than the original design made me that much more aware of how slow the attack speeds were should each turtle have a shorter wind-up time for their attack and therefore less input lag so to speak t even t sure feels like a rabbit hole in terms of gameplay that could be tweaked to be better please like and subscribe for more videos like this one i also have a patreon available for those of you interested and thanks for watching

Channel: Displaced Gamers

Views: 157,037

Keywords: teenage mutant ninja turtles, nes, cowabunga collection, bugs, programming, game genie, cheats, jumping, gravity, water jump, sewer jump, frame rate, 30 fps, broken jump

Id: A_edefG5lfs

Length: 13min 37sec (817 seconds)

Published: Thu Sep 01 2022