Tweaking the jump arc would certainly help, but I think there's a more proper fix. I've noticed that the major issue here is that bumping the Turtle's head on a ceiling negates all their horizontal movement, causing them to whiff what would otherwise appear to be easy jumps. Tackling THAT problem in the collision code might prove to feel even better in the long run; if your vertical momentum was zeroed out but your horizontal momentum was unaffected, those jumps would become significantly easier without touching the arc at all. I'm wondering if it's as simple as a horizontal movement sensor that's a pixel or two too high? Also curious if such a fix would end up breaking things elsewhere where you can suddenly slide into a ceiling that you shouldn't be able to, but I expect it won't be so bad as that.
Very good point. I feel that hitting your head would still reduce your horizontal velocity a bit, but perhaps not as extreme as it does now. Shadow Hog! I nominate you to investigate environmental collision detection in the sidescrolling areas of TMNT!
While it's possible to go this route, the ultimate point of tweaking a platforming game's physics and controls isn't to arrive at "objectively easy traversal" - it's to highlight specific kinds of traversal challenges and explore the possibilities in a dialogue between level design and systems design. TMNT's head hits are a pretty clear example of designed intent. When your jumps are made easier, it's more likely that your game is making you do something else with them. For example, Metroid's jumping allows you to float and land very precisely, which frees up attention for the shooting mechanics. But Mario's jumps are faster and very tied to the horizontal running motion, and the horizontal is intentionally slidey with slow stops and starts, so Mario jumping is really about constantly feeling "out of control". TMNT is in a state where every mechanic is a muddle and doesn't know what it wants to be, but the short arcs are clearly where the platforming gameplay is supposed to feel tough and you are supposed to fail. Another way to think about TMNT's problem is: there's a disconnect between the frame of A button release and when the turtle starts falling. In a Mario-style jump you decide the top of the arc by letting go; it kills Y velocity on that frame and lets gravity take over. That makes you feel like you're controlling it precisely and it means there are a huge variety of jumps because of the combined effect of horizontal velocity and release time, which the level design uses to great effect. But TMNT wants to allow a mix of short jumps and huge screen-sized jumps from a standing start, while making it possible to do both quickly. The way in which the original design went to accommodate the different sizes was to front-load the entire control scheme so that the arc is expressed within 8 frames. That's a problem because held button inputs are never as intuitive as "on press/on release", and using three held-button states to describe the future behavior of the jump aliases the different jumps into what are essentially fighting game command specials, vs watching the character to see when they hit the top of the arc and releasing at exactly that moment. Tuning the jump as done in the video makes this input much easier, but also hurts the responsiveness of the largest jump. A literal double jump would solve this. That gives you the control, it lets you make the high jumps quickly, and it clarifies the short/medium challenge mechanic, even if we don't change the actual arcs or frame timings at all(though tuning the first jump to be a clear fall-on-release definitely makes it more appealing).
HAHA neat. I was one of the programmers who translated this game to the C64. Everything you say is something we noticed back in the day as we tried to reverse engineer this (We were not furnished with source code). We ended up trying to make it as close to the original as possible and did not try and improve it. ;-)
What is it with companies demanding ports and not handing source code over? That's four I can think of now, you guys and the 3DO DOOM people, then the disaster that was the Sonic Genesis GBA port, and the team that had to reverse engineer Nights Into Dreams for the PC port. I just watched a playthrough of the C64 version, and color me impressed! The game looks pretty much like the only things that had to be simplified was the music and graphics, it looks pretty much like the NES version I played. If you still have contact with whoever did the main theme, give them a shout out! It sounds just as rockin' as the NES version! (and the overworld theme is going to be stuck in my head again, oops)
I was playing this on a Commodore my friend has a few years ago with and was wondering why only one button was used for both up and jump (think it was up and jump it might have been attack and jump, will try it on his machine again to make sure what share it was) were you limited by source code or was it to accommodate something like the 1 button joystick controllers people had from the 2600?
@@radiance_37k you might be thinking of basic, where you add the line number for each line of code "10 code here. 20 code here." Then you can ask code between with "11 more code" etc. The guys who ported to c64 did so in assembly no doubt (or some kind of other low level, higher than ASM, language)
This video perfectly illustrates why TMNT felt weird to play way back when. The jump mechanics in particular were frustrating to a much younger me. Seems like with a little tweaking like this in development this game could have been a real classic instead of just notable.
This is such an awesome video, will definitely share. The water level and lack of direction are often some of the biggest complaints this game gets but the wonky physics always felt like the worst part of the game for me. Glad that after nearly 3 decades I have an explanation of why it felt that way for me.
Dude I have memories of that jump burned into my eyelids - I see it every time I goto sleep. I was 5-6 years old and every time I would play TMNT I would end up having to call my cousin who was 13-14 and beg him to ride his bike down the street and do the jump for me. Luckily I had a pretty cool older cousin who would usually do it if he wasn’t busy. When I finally did it myself a few years later after pulling the NES back out I felt like the kid in the Wizard.
10:22 The way I've seen variable jumps done is to decrease gravity while the button is held (and you're going up) or to increase gravity when you release the button, or perhaps a combination of both.
Mario did it by just holding the upward velocity constant until the jump button is released or a frame limit is reached. After that you're released to gravity.
@@khatharrmalkavian3306from what I understand, at least in Super Mario World, the game still keeps checking if the jump button is held while in the air regardless of time This leads to the phenomenon that speedrunners coined "regrabbing" where you hold the jump button again at different descending points if your jump for some extra horizontal distance. It's funny how such little changes to code can basically add a high skill mechanic like that lol
I had an NES Advantage controller and something I learned early on was that using the Turbo feature made precision jumping a hell of a lot easier. Every time I needed to make a short jump, just turn on Turbo. I have a lot of memories from 30 years ago of that jump at 6:18, and with the Turbo it's so easy.
The NES Max was really good for that since the big downside of the NES Advantage was that you had to toggle the turbo mode on and off for your buttons, whereas the Max had dedicated turbo buttons. Only downside of the Max was that darn sliding D pad.
@@-Keith- I had the max growing up. The dedicated turbo buttons were invaluable. To get around the dpad problem, just got used to pressing the black frame around it.
It would be a lot more fair if the game used typical lava mechanics where you continuously take damage by standing in the water. That way there would still be a penalty for missed jumps, but a less frustrating one than being swept all the way outside. You could even justify it in-universe by saying that Shredder poisoned the sewers to thwart the turtles, which sounds like something he'd do.
I never noticed that the high jump was a double jump until this video. Something about slowing it down made the sudden boost in velocity easier to see.
@@JohnSmith-nj4zq But in the video it's considered an automatic double jump, which in my opininon is an accurate description since the game gives you a new starting velocity mid-jump, like you'd get out of a more common double jump.
@@JanneSiimesvaara It's more like Street Fighter 2, There's a low, medium and high. SOTN jumping twice is what an actual double jump is and looks like.
Never noticed until now but the Turtles definitely do the trademark Belmont strut when they walk. I wonder if some of the same animators worked on both.
The Belmont Strut, I love it! There's also an unused subweapon that functions similar to holy water from CV that was found. Possibly related to one of the initial subweapons pitched being a bomb item that does area damage.
Yeah... I suppose it was a natural holdover as gaming evolved over the years. Processors got faster, but tying physics to the frame rate still saved time.
When Ben Heck did it on his game on a microcontroller, I left a cheeky comment about how he was tying the game's physics to frame rate, but in reality, this kinda used to be the only way to do it in time. I suspect anyone who saw my comment knew that as well.
It never ceases to amaze me how such small groups of people programmed this in such a short time with such rudimentary tools. The more I look at these videos, the more I understand the sheer complexity of the task. I was 7 when I played this, and I definitely wanted to be a programmer at that age. Looking at this video today is wonderful, looking at it back then would've been beyond incredible. Thanks!!
It would be great for someone to redo the game physics as a quality of life patch and compare to the original. There could be a compelling game in here if the control were more intuitive and less frustrating.
@@SirBuzz yea it is. Games are released with busted code cause they ran out of time and this is as good as it gets. Have you seen the smb64 code fixes??? The dumbasses left debugging on and just turning it off bumped the performance like 20%. Debugging was left on. That’s not part of the gaming experience.
I haven't played on an emulator in a long time, but my suggestion is to play with turbo fire if you have the option. On the NES, if you use the NES Advantage, turn on the Turbo and set it to max. You'll get a short jump 100% of the time. That's what I did when I was a kid and it made the jump at 9:05 elementary.
I think TMNT nes game was designed for the 30 fps jump if you play the game some jumps really feel like it the jump he shows in the video couldn’t be made at a 60 fps jump
While unrelated to the timing, preciseness and collision complications of the jumping mechanic, I'd also feel that a tweak to the Turtle's weapon attack during a double jump might also be necessary. You'll notice that when you press the B button, the Turtle will use their standing attack animation, or crouching attack if the Down button was held. That means the hitbox grows from its tiny spinning size to a full body size that makes your Turtle vulnerable. Replacing that frame with just the animation frames from the weapon will keep the Turtle's spinning animation as they draw out their weapon, like the frames seen in a Mr. Invincibility session.
I'm not a gave dev, but I would imagine this channel is a gift to gave devs. Either way, I think the fusion of game mechanics and real-world examples is really cool.
11:54 “Not a Fix. A Direction.” I really like that, I’m tired of people calling stuff in games that couldn’t be more of a matter of personal taste objectively bad decisions that need to be be “fixed”.
The most fascinating jump physics I can think of is Bomb Jack, you have an incredibly high jump, but hitting jump again causes your vertical speed to be set to 0 (or at least, a very low value), so you can 'hover' with a fast finger.
just a detail: "gravity" is very rarely adjusted dynamically (or even statically, but during development - you usually tweak it at the beginning, until you find a value which feels right, and then never touch it again, because it refers to "downward force (multiplier of weight) applied globally to everything that has weight", so messing around with it would mess up everything. what's better to tweak is "weight", which refers to downward force (base value) for a single specific object.
Just played through this game again thanks to the Cowabunga Collection, and this video really helps explain the frustration everyone has to grapple with when revisiting this classic, great stuff!
I may have mentioned this on another video, but I would really love to see an examination of how a game with large levels goes about compressing/decompressing them. My go-to example is Solar Jetman, which manages to fit some impressively huge levels into a "mere" 256KB.
Not to mention it's got some equally impressive, sophisticated gravity physics going on by NES standards. Which just happens to be pretty relevant to this vid. 😁
It was made by Rare if I'm not mistaken, so it's likely CHR RAM based utilizing a lot of tile compression among other things. They had a habit of really trying to push the hardware.
Solar Jetman levels are made from 256 different 128*128 pixels big metatiles. This substantially reduces the size needed to store all levels. Planet 2 for example is 32*26 metatiles big i.e. only 832 bytes is needed for the level's layout. They did a really good job with the levels so these big blocks aren't really noticeable.
Solar Jetman example image where the metatiles are outlined and their ID/number (0-255) shown. drive.google.com/file/d/1UBtwvcrjnp2ccuXgDld97YBxaHPUmris/view?usp=sharing
And this is why I love this channel, especially the Behind the code videos. I had always considered jump physics when designing a game, particularly the gravity and mimicking real world gravitational acceleration. I never considered converting it from m/s^2 to fps but it makes a lot of sense. Though I suppose it depends on the game and how a character is suppose to move. Floaty jumps are what you would expect for playable ninjas. Once again awesome video and keep up the good work. It's always appreciated.
It’s amazing this game is still so impactful many years later. I bought the COWABUNGA COLLECTION just to get this game. I still have my NES. This was the 3rd game I had for it when I was a kid
Supposedly TMNT's "engine" was based off another Konami game; GetsuFumaDen, which is a game with equally floaty movement and loose combat (so much that if you were to press the jump button when falling into a pit, you can actually perform a mid-air jump)
You are absolutely right, there is so much promise to this game and while it has been patched for QOL by others, fixing the jumping and combat animations would be amazing.
rather than bad jump design - level design is done exactly for it.. it could be more said to be over estimation of players - many 8bit games had pretty evil designs, like pixel perfect jumps - difficulty for replaying what is often a short game because it will take time to get good enough to complete it - though not as short as *some* modern games
While I will never understand assembly programming and the technical details go right over my head, It's always interesting to see a behind the scenes look on how a game operates.
I love these deep dives into NES games, and especially TMNT!! Would you be willing to return to the Bomb Swim one more time to dive into the secrets of the current/boost? I've always been interested in that considering how inconsistent it seems to be.
@@retrogambit7101 - You're a runner? Me, too! A humble 23:13 in Any%, but that may improve if I can learn the secrets of boost/current. Sometimes I'll be bonk-free and still miss current, so I'm trying to figure out what I'm doing wrong, or what knowledge I'm missing.
@@retrogambit7101 Oh, he does??? NICE! I initially learned off one of his runs, but recently I started using Stuff is Stuff's tuto. Gonna have to go give Skunky some more views, lol... Thanks, man!
Speaking as a player: How about remove a floor tile from the top floor or add a floor tile to the bottom floor? Then how about moving the enemy spawn point a tile or two left or right so the player doesn't have to take a cheap hit and fall back into the water?
You deserve more subscribers. As a game developer, I love your content and hope it continues. This episode was one of my favorites. You make assembly code look so simple haha.
I'm quite surprised at how the jump logic works in the game. Re-assigning the speed once the jump has started is not how I imagined it would be done. Perhaps executing the jump once the button has been released ... although it would introduce the feeling of input lag. Anyway, great video, as usual. Very interesting and very didactic. Love this series.
Yeah I didn't expect it either and never noticed it when playing. I can't think of a good alternative since the game has no run button and no specific double jump button to make it explicit.
I wonder how many rom patches this will lead to. A simple better jump / attack rom hack would be very welcome. Allowing turtles to keep their momentum when bumping heads would be amazing. Of course, a full 60FPS conversion would be lovely, but good luck with that.
It’s funny to see this video. I remember as a child I got stuck in this game at the sewer part you showed because I was unaware of the different jumps. It’s nice to know it wasn’t completely my fault all these years later.
This may be beyond patching, but could the jump physics be rewritten where pressing the jump button applies a high jump velocity, but releasing it instead changes your upward velocity to zero or a low number. If I’m understanding right, it would be the reverse on how TMNT implemented their jumping physics. Instead of three different jumps, you would have one jump that is instead cancelled when you release the jump button.
While I haven't looked at Mega Man 2's exact jump mechanics, I believe it has what you are describing. I showed some footage from it in this video. If you were to duplicate the jump logic from Mega Man 2 for TMNT, you'd have to consider adapting for 30 fps and probably adding the automatic double jump to the end for jump height requirements. Platforming in the NES Mega Man series feels good, and the frame rate allows for it.
Great discussion - I love how you use specific dissections to look at broader concepts as a whole. For a lot of these 'bad' games, I'm really impressed by the ingenious (if imperfect) solutions that devs came up with, operating at a time with very little precedent or theoretical knowledge. The fact that many of these solutions are still perfectly functional in modern development contexts is mind-blowing to me!
Your videos are great for indie devs! I would love it if you ever have the time to look at the hit detection in Ironsword. The way armor and damage works in that game is so strange.
This video makes me wonder about another NES oddity: _Ghosts 'n Goblins._ There's nothing "wrong" with any of the game aside from some generic NES vertical-wrap glitching. However, I find it incredibly odd that the game seems to run at, like, 15 FPS…
Nice to see someone giving this game some attention, I think it's a great game that just needed more polish, and I'm glad to see you taking a stab at making it just that much better
Konami and Digital Eclipse should have come to you, before putting this game on the Cowabunga Collection. They could have talked to you to help them make some tweaks to the game, to fix some of it's oversights with your knowledge. They already tried with the "Remove Flicker" and "Remove Slowdown" options (which don't even work 100% reliably anyway), but with your help and knowledge of coding, they could have made a lot more bug fixes for this old game, so that old AND new audiences could enjoy it much better.
I assume they still have access to the original source code and didn't lean on the wrapper-emulator alone for all of their tweaks, but maybe that was the extent of their changes. That said - I am not sure if the ROI for putting time into tweaking the original game mechanics is worth it for them.
It’s like you peered into my childhood and found all the frustrating parts of this game to make code videos about. I wonder if there’s another way of tackling the problem by changing horizontal movement slightly. I just wonder how much level design would need to change in order to support the new physics. Since I never beat this game, I’m not sure if changes would make soft locked situations occur.
Honestly I don't have a lick of coding knowledge, maybe a slight idea of how scripting generally works as a whole. But these videos are still INCREDIBLY fascinating to me. I can somewhat understand the basic idea of what you're explaining, and your explanations are just wonderful. Great stuff, man. 👍🏻❤️
This is fascinating, from design considerations to a bit of code walking. If you get enough people tweaking the code achieving different solutions, I'd love to see a follow up on this one. If not, can't wait to see what you tackle next!
I doubt the floaty jump was a mistake. Or at least, it wasn't left in on accident. If it was a result of changing from 60fps to 30, I would think that they noticed and preferred a more floaty jump for this game, electing to leave that value as is. They clearly designed the levels around it, having a few points where specific jumps (or even not jumping at all) are required to pass, expecting the player to learn that mechanic. Use the wrong jump, you don't pass, thus making sure that only players who understand this mechanic move on to a more difficult section. The choke point shown doesn't even have the consequence of failure as high as most other games, since you don't lose a life or any health from it.
My gamer friend always complains that good movement is easy to make in a game and programmers are bad at their job (because I'm interested in game dev). Meanwhile here is a 13 minute video breaking down just the player's jump. It's not easy, people.
A simpler solution, IMO... Just make the turtle (an amphibian creature by nature) be able to swim!! Lol. Just a gag coming from my frustration with this game. Awesome video, as always. Learning how code works for these “simple” aspects of a game really makes me value all the effort the programmers put into their software, even if they failed.
I wonder how development on these games would have been different if the devs knew that 40~ years later someone would decompile their code and do an in-depth analysis of the small mistakes that led to some of the most infamous glitches and problems in their games. We see the effect that day one patches and the danger of someone datamining your game have on modern development, and the funniest part is that some of these hot-fixes are totally doable with just a bunch of game genie codes. It definitely makes you think. Back then, programming was a done deal because nobody expected the general public to have the kinds of tools to be able to do this. It's honestly fascinating.
While I wish we didn't live in a "release now, patch later" world, it sure is nice for devs to not only fix bugs but also tweak mechanics after a game has been released. Pairing this approach with a physical release that does not contain those patches as well as the possibility that the server that provides those patches could no longer exist at some point in the future is a cause for alarm for those that may want to revisit a PS5 game (for example) 20 years later.
back then they did not have the tools and what kind of cuts / quick changes where made to make the games fit into the rom space / cpu power / ram? Other stuff cut for time leading to quick changes to get the game out on time?
Hi man! Congrats for showing us these great things! I have a request. There seems to be a glitch fighting Shredder. Sometimes, even if you kill him the game stucks, your turtle freezes as he goes on trying to hit you. It should be something with Shredder's lifebar. You could make a video about this!
I recall that the creator of Rockman 4 Minus Infinity was able to free up something like 40% of the CPU by re-writing the music code (!!!), allowing that ROM hack to be drastically more complex than the original game. I wonder if there aren't some optimizations that could be done to key game loops of TMNT to free up enough CPU cycles to make it a 60 FPS game.
Wouldn't be surprised if that's the case: Mega Man games in particular, I recall, where often made on a death march-pace and I wonder if even this game, big a license as it was, was made with enough time to really work out CPU-freeing solutions or if it was just "do whatever to get it working it needs to be done now now NOW!" With our increased knowledge, documentation and time, so much more is possible now than was back then...
Have you looked into Getsu Fuma Den on Famicom at all? I always had the impression that TMNT was built on top of its codebase, but it's a 60 fps game, so it'd be interesting to see what changed in the physics code between the two.
I did look at Getsu Fuma Den a little bit while making this video! I wasn't in there long, though. You are the second person to being up Getsu Fuma Den in the comments, and I am glad that a bunch of us are kinda on the same page in terms of Konami code/engine history. I will say this, though - at a glance, the TMNT engine could be a bogged down and heavily modified version of the GFD engine (if the two are related). I wouldn't be surprised if Konami assigned Turtles to a "B team" and said "use this as a starting point to create a Turtles game." While the two look to be related, I only really tracked down the gravity constant. It was not a match to TMNT (regardless of frame rate), and I want to say it is applied in a different way. So even the logic may have been a bit different.
Flashback to early 90s, preteen me cursing the sewer jump. I would later come across the turbo 4 controller and discovered that the top jump button on the controller was mapped to short jump. Never thought I would revisit this experience as a hobbyist game programmer from a completely different perspective 3 decades later.
This is a really interesting topic! Making old classic games feel better to play is really nice. Also the perfect feeling to a games physics is an interesting topic. Perhaps it's hard to find that sweet spot, wich everyone likes. When we developed Alwa's Awakening to modern platforms as Steam, PS4 and Switch etc. We went for what we thought would be the sweet spot for game play and feel to the game. Some people often comments that the gravity is feeling sluggish and the movement speed is to slow. After getting used to the settings in the game people somtimes change their opinion and sees the benefit when doing hard jumps. When porting the game to a real NES, we wanted the game to feel like the original on Steam etc. Brad Smith who made the conversion to NES made an excellent work, and the game feels just like the original. I guess it would be possible to find Game Genie codes for the NES versions that alter things like the gravity and movement speed. But as you said, this would affect the gameplay in even more than just movement speed etc. The leveldesign is made for the settings made in the original code, and could mess up the playability. Still it would be awesome to play around with some settings using Game Genie codes for the game.
Just started watching this because I recall being stuck on one of the levels for days as a small kid. I eventually figured out you had to lightly *tap* the jump button to pass without hitting your head and dropping into the water. Edit: LOL you covered the exact spot I was stuck on as a kid at 6.21 !!
These code videos are all super helpful! If there is any game I would love to see code insight for, it would be SNES Harvest Moon, specifically what effects weather RNG and fishing RNG!
Dunno why but I love this channel even though I understand the bare minimum of programming talk. Well done captivating even us who arent that knowledgeable, but just love retro.
always great to see a little under the hood of a nostalgic game. I wonder if there's anything interesting in the old NES ducktales game. movement in that game always seemed really great, so maybe that's only interesting in a "what makes it great" sense, but the way enemies spawned was often quite annoying. maybe that's also an area worth looking into.
Standard falling acceleration in platformer games is actually faster than proportional effects of real gravity on humans in real life (in addition to other industry standards like midair redirectional control). That's right, high jumps aren't a result of "low gravity" but rather games have _high_ gravity making the extreme heights of heroes' high jumps all the more impressive!
Posting on a very old fire tablet. Your videos are very good and I enjoy learning about coding. If I had to give a next tmnt fix, it be Ralph's and Mike's attack method. Since Sprite editing might be outside your wheel hous, yet I also feel like Feasters Quest also covered damage and distancing I would be interested in hearing your thoughts on basic ideas on how to fix it. Thank you for your video again.
I love having jump heights you can control in a platformer, but I never thought of having the jump heights set at specific intervals. When I've been coding I've always set it to simply set the vertical velocity to zero once the player lets go of the button. This is what it always felt like games were doing, but maybe I have been wrong. How are controlled jumps handled within Batman (NES)? Even as an adult I always felt like a champ for pulling off tricky jumps with expert timing. I wonder if the game was secretly holding my hand with a design similar to this...
Speaking of jumps, I would love to see how the Roc's feather or other pretend 3D jumps are done in games like Super Mario RPG or games that can vary the jump height in '3D'. :)
Correct me if I'm interpreting this wrong, but a 4 frame window for the short hop at 30 FPS would be equivalent to an 8 frame window in a 60 FPS game, correct? I understand that this may be a little difficult for people at first, but when compared to games like Smash Bros it is still a really huge window. Short hops are performed in Melee by releasing before the jumpsquat is concluded. For the fastest in the cast, that occurs on frame 3 (at 60 fps). In fact, only one character in the entire cast has an 8 frame jumpsquat, Bowser. If anything, the middle jump seems the most difficult to perform in TMNT. Since holding long is trivial, and releasing quickly is just accomplished by tapping. Only the middle jump requires timing.
So are we going to get a video on the iconic Super Mario Bros. jump physics? -- I would love to see this! It would be even better if we got to see the differences between all three of the original NES games!
Yes, I agree. The flat bounce rate whenever you stomp on a Koopa against a staircase for points and infinite 1-UPs is unforgiving. In Super Mario All-Stars, for the first Super Mario Bros., this has been corrected to a slightly higher rate ($FB vs. $FC) and the player now continuously jumps on the Koopa without interruption. However, this has not been changed for the Vs. Super Mario Bros. arcade game, which has some level layouts we'd also see in Super Mario Bros. 2 (Japan; what we call Super Mario Bros.: The Lost Levels), and so for some of these altered levels this flat bounce rate does not work well over very wide gaps even when Mario stomps on a flying Koopa Paratroopa. For The Lost Levels, these physics have been altered to a significant degree to address the shortcomings in the earlier games: the player's Y speed is now loaded into Y instead of A, with an initial set value of $FA for even higher rates of bounce against enemies. For the flying Koopa Paratroopas, a special check occurs, which is loaded into A, to see if you have stomped on either one of the two varieties of this enemy (red=vertical and green=horizontal) and, if so, to load the much higher bounce rate value of $F8 into Y instead. Two jumps to this changed bounce rate check have been added to the end of the 'EnemyStompedPts' routine (a JMP, which replaced a rather unnecessary Y speed check that ends with an RTS) and right after the BCC in the 'ChkForDemoteKoopa' routine (a JSR) while the JMP to the old bounce rate check that ends the latter routine was changed to an RTS.
@@ClassicTVMan1981X This is very interesting. I'm very curious about the iconic jump physics between the various mario games. The SNES jump physics were the best feeling out of the series, but the SMB3 bounce from on top of a koopa when holding the jump button was definitely the start of what a great-feeling mario game was. I'm not sure whether I prefer the SMB3 or SMW bounce mechanics, but both were definitely good for their respective levels and level layouts, though SMW could be exploited quite a lot more than SMB3 by players.
@@awesomedata8973 And let me add that what I said is especially true for the PAL (50 FPS) releases, even the later one with the bugfixes included. The flat bounce rate wasn't changed from NTSC (meaning still $FC), and so for PAL it's very frustrating to try the turtle tipping trick for infinite lives. In both cases, a Game Genie code can be used to fix this: XNYIXO (for the first PAL release) or XNYIKO (for the second PAL release), which will change the bounce rate from $FC to the higher $FA. For the PAL release of Super Mario All-Stars, in Super Mario Bros. they changed this bounce rate to $FA, while in The Lost Levels, the mainstream bounce rate is now $F9 while that for the flying Koopa Paratroopas is $F7.
I beat this game on the Cowabunga Collection, but oh man...that Rewind feature was CRUCIAL because the jumping and pits/water were so TERRIBLE. Glad you took a dive into this!
Anything, really. I enjoyed the videos on zipping and QuickMan's AI. Perhaps a glance at how the code evolved for how MegaMan moves around from 1-6? Might turn into a lengthy video, though.
Nowadays it is exciting to have a deep look into the games internals using emulators but at the time the game was made, I can't imagine the stress if such tweaks were performed at the end of the development cycle potentially breaking the levels anywhere in the game :D
NES TMNT is so frustrating because visually it hosts all the things we young gamers wanted in the game. Thank you for this video which shows the ways it can be improved. I do hope your suggestions are taken up by the community so a sincere patch is made that turns NES TMNT from a rough cut into a sparkling gem.
Even if it was theoretically perfect, only tweaking things like physics and framerate, without altering any fundamental game design decisions, the game would still be _boring,_ and that's the worst thing that a piece of entertainment can possibly be. At best, it would go from worthless to sufficiently playable. You'd need to essentially completely overhaul the game design for it to be considered good.
I assume they thought it would add some strategy to switch turtles depending on the enemies in the current area, but switching all the time just for damage output gets monotonous rather quickly, imo. I know that different enemies take a different amount of damage depending on the turtle used. It isn't just about which weapon is being wielded. So I assume there is some sort of main LUT used depending on the enemy attacked and then turtle selected... with some sort of base case. So one approach would be to locate the table and edit it as a ROM hack or perhaps edit the code so the turtles do some flat amount of damage. Also consider that there are damage boosts when a turtle has lost so much health.
Tweaking the jump arc would certainly help, but I think there's a more proper fix. I've noticed that the major issue here is that bumping the Turtle's head on a ceiling negates all their horizontal movement, causing them to whiff what would otherwise appear to be easy jumps. Tackling THAT problem in the collision code might prove to feel even better in the long run; if your vertical momentum was zeroed out but your horizontal momentum was unaffected, those jumps would become significantly easier without touching the arc at all. I'm wondering if it's as simple as a horizontal movement sensor that's a pixel or two too high? Also curious if such a fix would end up breaking things elsewhere where you can suddenly slide into a ceiling that you shouldn't be able to, but I expect it won't be so bad as that.
Very good point. I feel that hitting your head would still reduce your horizontal velocity a bit, but perhaps not as extreme as it does now.
Shadow Hog! I nominate you to investigate environmental collision detection in the sidescrolling areas of TMNT!
@@DisplacedGamers Oh no! I guess I have to learn 6502 ASM now! (๑•﹏•)
(FR tho, it _is_ tempting...)
While it's possible to go this route, the ultimate point of tweaking a platforming game's physics and controls isn't to arrive at "objectively easy traversal" - it's to highlight specific kinds of traversal challenges and explore the possibilities in a dialogue between level design and systems design. TMNT's head hits are a pretty clear example of designed intent. When your jumps are made easier, it's more likely that your game is making you do something else with them. For example, Metroid's jumping allows you to float and land very precisely, which frees up attention for the shooting mechanics. But Mario's jumps are faster and very tied to the horizontal running motion, and the horizontal is intentionally slidey with slow stops and starts, so Mario jumping is really about constantly feeling "out of control". TMNT is in a state where every mechanic is a muddle and doesn't know what it wants to be, but the short arcs are clearly where the platforming gameplay is supposed to feel tough and you are supposed to fail.
Another way to think about TMNT's problem is: there's a disconnect between the frame of A button release and when the turtle starts falling. In a Mario-style jump you decide the top of the arc by letting go; it kills Y velocity on that frame and lets gravity take over. That makes you feel like you're controlling it precisely and it means there are a huge variety of jumps because of the combined effect of horizontal velocity and release time, which the level design uses to great effect. But TMNT wants to allow a mix of short jumps and huge screen-sized jumps from a standing start, while making it possible to do both quickly. The way in which the original design went to accommodate the different sizes was to front-load the entire control scheme so that the arc is expressed within 8 frames. That's a problem because held button inputs are never as intuitive as "on press/on release", and using three held-button states to describe the future behavior of the jump aliases the different jumps into what are essentially fighting game command specials, vs watching the character to see when they hit the top of the arc and releasing at exactly that moment. Tuning the jump as done in the video makes this input much easier, but also hurts the responsiveness of the largest jump.
A literal double jump would solve this. That gives you the control, it lets you make the high jumps quickly, and it clarifies the short/medium challenge mechanic, even if we don't change the actual arcs or frame timings at all(though tuning the first jump to be a clear fall-on-release definitely makes it more appealing).
smart. i was thinking all you'd need is to assign, say, a double tap forward to a mostly horizontal vaulting jump
I think you could improve headbonking a bit by shrinking the top the hitbox a few pixels when jumping, similar to a double jump.
HAHA neat. I was one of the programmers who translated this game to the C64. Everything you say is something we noticed back in the day as we tried to reverse engineer this (We were not furnished with source code). We ended up trying to make it as close to the original as possible and did not try and improve it. ;-)
What is it with companies demanding ports and not handing source code over? That's four I can think of now, you guys and the 3DO DOOM people, then the disaster that was the Sonic Genesis GBA port, and the team that had to reverse engineer Nights Into Dreams for the PC port.
I just watched a playthrough of the C64 version, and color me impressed! The game looks pretty much like the only things that had to be simplified was the music and graphics, it looks pretty much like the NES version I played.
If you still have contact with whoever did the main theme, give them a shout out! It sounds just as rockin' as the NES version! (and the overworld theme is going to be stuck in my head again, oops)
I was playing this on a Commodore my friend has a few years ago with and was wondering why only one button was used for both up and jump (think it was up and jump it might have been attack and jump, will try it on his machine again to make sure what share it was) were you limited by source code or was it to accommodate something like the 1 button joystick controllers people had from the 2600?
I still have a C64 :)
I tried programming a bit on it... Holy crap it was tedious, how did you manage with adding lines in between code?
@@radiance_37k you might be thinking of basic, where you add the line number for each line of code "10 code here. 20 code here." Then you can ask code between with "11 more code" etc.
The guys who ported to c64 did so in assembly no doubt (or some kind of other low level, higher than ASM, language)
@@cradledani I honestly did not realize that was an option, nor that you could ask for more lines.
Thanks for clearing that up :)
This video perfectly illustrates why TMNT felt weird to play way back when. The jump mechanics in particular were frustrating to a much younger me. Seems like with a little tweaking like this in development this game could have been a real classic instead of just notable.
It very much IS a classic, just in that butthead-difficult kind of way that Battletoads and Spelunker are
@@TonyTheTGR Nintendo Hard classics, ah, how I (don't) miss thee.
Ar
Kaizo TMNT 😈
Another big problem is there's no invulnerability time after taking damage.
This is such an awesome video, will definitely share. The water level and lack of direction are often some of the biggest complaints this game gets but the wonky physics always felt like the worst part of the game for me. Glad that after nearly 3 decades I have an explanation of why it felt that way for me.
Thank you, and thank you for the share!
He fixed the water level in his previous video.
Dude I have memories of that jump burned into my eyelids - I see it every time I goto sleep. I was 5-6 years old and every time I would play TMNT I would end up having to call my cousin who was 13-14 and beg him to ride his bike down the street and do the jump for me. Luckily I had a pretty cool older cousin who would usually do it if he wasn’t busy. When I finally did it myself a few years later after pulling the NES back out I felt like the kid in the Wizard.
10:22 The way I've seen variable jumps done is to decrease gravity while the button is held (and you're going up) or to increase gravity when you release the button, or perhaps a combination of both.
Mario did it by just holding the upward velocity constant until the jump button is released or a frame limit is reached. After that you're released to gravity.
@@khatharrmalkavian3306from what I understand, at least in Super Mario World, the game still keeps checking if the jump button is held while in the air regardless of time
This leads to the phenomenon that speedrunners coined "regrabbing" where you hold the jump button again at different descending points if your jump for some extra horizontal distance. It's funny how such little changes to code can basically add a high skill mechanic like that lol
I had an NES Advantage controller and something I learned early on was that using the Turbo feature made precision jumping a hell of a lot easier. Every time I needed to make a short jump, just turn on Turbo. I have a lot of memories from 30 years ago of that jump at 6:18, and with the Turbo it's so easy.
Yeesssss! That is a great strat.
This.
The NES Max was really good for that since the big downside of the NES Advantage was that you had to toggle the turbo mode on and off for your buttons, whereas the Max had dedicated turbo buttons. Only downside of the Max was that darn sliding D pad.
Personnally, my strat for those jumps was to simply quick-tap the button and barely touch it...
@@-Keith- I had the max growing up. The dedicated turbo buttons were invaluable. To get around the dpad problem, just got used to pressing the black frame around it.
It would be a lot more fair if the game used typical lava mechanics where you continuously take damage by standing in the water. That way there would still be a penalty for missed jumps, but a less frustrating one than being swept all the way outside. You could even justify it in-universe by saying that Shredder poisoned the sewers to thwart the turtles, which sounds like something he'd do.
I never noticed that the high jump was a double jump until this video. Something about slowing it down made the sudden boost in velocity easier to see.
It's not a double jump, just a high jump. A double jump is like in Castlevania SOTN where you can jump again when you are in air.
@@JohnSmith-nj4zq But in the video it's considered an automatic double jump, which in my opininon is an accurate description since the game gives you a new starting velocity mid-jump, like you'd get out of a more common double jump.
@@JanneSiimesvaara It's more like Street Fighter 2, There's a low, medium and high. SOTN jumping twice is what an actual double jump is and looks like.
Never noticed until now but the Turtles definitely do the trademark Belmont strut when they walk. I wonder if some of the same animators worked on both.
The Belmont Strut, I love it! There's also an unused subweapon that functions similar to holy water from CV that was found. Possibly related to one of the initial subweapons pitched being a bomb item that does area damage.
Most likely, given Ultra was simply a sub-company of Konami, to bend the games per year released limit imposed by Nintendo
Possibly why the input lag for attack was programmed into the game... To have that Castlevania feel. It's an action game but in a different pace
You mean Belmont uses the Turtles walk right? Lol.
As someone who's played a lot of FPSes, the phrase "tie physics to the frame rate" gave me a chill.
Yeah... I suppose it was a natural holdover as gaming evolved over the years. Processors got faster, but tying physics to the frame rate still saved time.
Anyone that plays Elder Scrolls game should get chills as well.
@@themonsterunderyourbed9408 I didn't get chills, I deadbutt _flinched_ .
@@neoqwerty dead ass
When Ben Heck did it on his game on a microcontroller, I left a cheeky comment about how he was tying the game's physics to frame rate, but in reality, this kinda used to be the only way to do it in time. I suspect anyone who saw my comment knew that as well.
I love how you include Game Genie codes for the fixes. I need to try them out. Keep up the hard work!
It never ceases to amaze me how such small groups of people programmed this in such a short time with such rudimentary tools. The more I look at these videos, the more I understand the sheer complexity of the task. I was 7 when I played this, and I definitely wanted to be a programmer at that age. Looking at this video today is wonderful, looking at it back then would've been beyond incredible. Thanks!!
It would be great for someone to redo the game physics as a quality of life patch and compare to the original. There could be a compelling game in here if the control were more intuitive and less frustrating.
Quality of life rom patches are life!
@@SirBuzz yea it is. Games are released with busted code cause they ran out of time and this is as good as it gets. Have you seen the smb64 code fixes??? The dumbasses left debugging on and just turning it off bumped the performance like 20%.
Debugging was left on.
That’s not part of the gaming experience.
I haven't played on an emulator in a long time, but my suggestion is to play with turbo fire if you have the option. On the NES, if you use the NES Advantage, turn on the Turbo and set it to max. You'll get a short jump 100% of the time. That's what I did when I was a kid and it made the jump at 9:05 elementary.
I think TMNT nes game was designed for the 30 fps jump if you play the game some jumps really feel like it the jump he shows in the video couldn’t be made at a 60 fps jump
It's a good idea, but then it should be rebranded as a new version not to be confused with the original.
The side by side comparison between CnD Jump and TMNT jump 😀👍
I hadn't noticed the double jump despite it being very visible.
Thanks again for all your hard work! Love your stuff!
Peak UA-cam when there is talk of a mechanics of a NES game, Not found anywhere else.
While unrelated to the timing, preciseness and collision complications of the jumping mechanic, I'd also feel that a tweak to the Turtle's weapon attack during a double jump might also be necessary. You'll notice that when you press the B button, the Turtle will use their standing attack animation, or crouching attack if the Down button was held. That means the hitbox grows from its tiny spinning size to a full body size that makes your Turtle vulnerable. Replacing that frame with just the animation frames from the weapon will keep the Turtle's spinning animation as they draw out their weapon, like the frames seen in a Mr. Invincibility session.
I'm not a gave dev, but I would imagine this channel is a gift to gave devs. Either way, I think the fusion of game mechanics and real-world examples is really cool.
11:54 “Not a Fix. A Direction.” I really like that, I’m tired of people calling stuff in games that couldn’t be more of a matter of personal taste objectively bad decisions that need to be be “fixed”.
TMNT taught me how to jump in video games. The fact that there are 3 distinct jumps that can happen based on your input blew my mind.
The most fascinating jump physics I can think of is Bomb Jack, you have an incredibly high jump, but hitting jump again causes your vertical speed to be set to 0 (or at least, a very low value), so you can 'hover' with a fast finger.
just a detail: "gravity" is very rarely adjusted dynamically (or even statically, but during development - you usually tweak it at the beginning, until you find a value which feels right, and then never touch it again, because it refers to "downward force (multiplier of weight) applied globally to everything that has weight", so messing around with it would mess up everything. what's better to tweak is "weight", which refers to downward force (base value) for a single specific object.
Just played through this game again thanks to the Cowabunga Collection, and this video really helps explain the frustration everyone has to grapple with when revisiting this classic, great stuff!
1337 video length.
I adore your content. This must take so much time to produce. Great work.
I may have mentioned this on another video, but I would really love to see an examination of how a game with large levels goes about compressing/decompressing them. My go-to example is Solar Jetman, which manages to fit some impressively huge levels into a "mere" 256KB.
Not to mention it's got some equally impressive, sophisticated gravity physics going on by NES standards. Which just happens to be pretty relevant to this vid. 😁
Yeah, you see some ingenious workarounds in some of the old coding, true masters of their class at the time.
It was made by Rare if I'm not mistaken, so it's likely CHR RAM based utilizing a lot of tile compression among other things. They had a habit of really trying to push the hardware.
Solar Jetman levels are made from 256 different 128*128 pixels big metatiles. This substantially reduces the size needed to store all levels.
Planet 2 for example is 32*26 metatiles big i.e. only 832 bytes is needed for the level's layout.
They did a really good job with the levels so these big blocks aren't really noticeable.
Solar Jetman example image where the metatiles are outlined and their ID/number (0-255) shown.
drive.google.com/file/d/1UBtwvcrjnp2ccuXgDld97YBxaHPUmris/view?usp=sharing
And this is why I love this channel, especially the Behind the code videos.
I had always considered jump physics when designing a game, particularly the gravity and mimicking real world gravitational acceleration. I never considered converting it from m/s^2 to fps but it makes a lot of sense. Though I suppose it depends on the game and how a character is suppose to move. Floaty jumps are what you would expect for playable ninjas.
Once again awesome video and keep up the good work. It's always appreciated.
It’s amazing this game is still so impactful many years later.
I bought the COWABUNGA COLLECTION just to get this game.
I still have my NES.
This was the 3rd game I had for it when I was a kid
I agree: the huge problem with these jumps is that bumping the turtle’s head negates horizontal velocity and movement.
That ruins everything
Supposedly TMNT's "engine" was based off another Konami game; GetsuFumaDen, which is a game with equally floaty movement and loose combat (so much that if you were to press the jump button when falling into a pit, you can actually perform a mid-air jump)
You are absolutely right, there is so much promise to this game and while it has been patched for QOL by others, fixing the jumping and combat animations would be amazing.
rather than bad jump design - level design is done exactly for it.. it could be more said to be over estimation of players - many 8bit games had pretty evil designs, like pixel perfect jumps - difficulty for replaying what is often a short game because it will take time to get good enough to complete it - though not as short as *some* modern games
While I will never understand assembly programming and the technical details go right over my head, It's always interesting to see a behind the scenes look on how a game operates.
I love these deep dives into NES games, and especially TMNT!!
Would you be willing to return to the Bomb Swim one more time to dive into the secrets of the current/boost? I've always been interested in that considering how inconsistent it seems to be.
You can actually manipulate the current and ride it as long as you dont bonk against any walls. We usually try to stay in a current during speeruns.
@@retrogambit7101 - You're a runner? Me, too! A humble 23:13 in Any%, but that may improve if I can learn the secrets of boost/current. Sometimes I'll be bonk-free and still miss current, so I'm trying to figure out what I'm doing wrong, or what knowledge I'm missing.
@@rawkfistgaming Skunky has a great tutorial on current boost. Not sure if its on SR or his YT
@@rawkfistgaming Im also trying to improve my Glitchless run and Any%
@@retrogambit7101 Oh, he does??? NICE! I initially learned off one of his runs, but recently I started using Stuff is Stuff's tuto. Gonna have to go give Skunky some more views, lol... Thanks, man!
A ROM hack fixing the hit boxes on things plus these jump and attack improvements would be amazing.
Speaking as a player: How about remove a floor tile from the top floor or add a floor tile to the bottom floor? Then how about moving the enemy spawn point a tile or two left or right so the player doesn't have to take a cheap hit and fall back into the water?
You deserve more subscribers. As a game developer, I love your content and hope it continues. This episode was one of my favorites. You make assembly code look so simple haha.
i love the length of the video, 13:37 is perfect
I'm quite surprised at how the jump logic works in the game. Re-assigning the speed once the jump has started is not how I imagined it would be done. Perhaps executing the jump once the button has been released ... although it would introduce the feeling of input lag. Anyway, great video, as usual. Very interesting and very didactic. Love this series.
Yeah I didn't expect it either and never noticed it when playing. I can't think of a good alternative since the game has no run button and no specific double jump button to make it explicit.
I wonder how many rom patches this will lead to. A simple better jump / attack rom hack would be very welcome. Allowing turtles to keep their momentum when bumping heads would be amazing. Of course, a full 60FPS conversion would be lovely, but good luck with that.
I would love a full 60 fps conversion
I remember that specific jump being so damn frustrating for me as a kid.
Great video as always!
I remember that jump being impossible on the PC version. Until I discovered the can't-die cheat code to just walk on water
I could never make that jump. No matter how many times I tried, I never once made it.
It’s funny to see this video. I remember as a child I got stuck in this game at the sewer part you showed because I was unaware of the different jumps. It’s nice to know it wasn’t completely my fault all these years later.
This may be beyond patching, but could the jump physics be rewritten where pressing the jump button applies a high jump velocity, but releasing it instead changes your upward velocity to zero or a low number.
If I’m understanding right, it would be the reverse on how TMNT implemented their jumping physics.
Instead of three different jumps, you would have one jump that is instead cancelled when you release the jump button.
While I haven't looked at Mega Man 2's exact jump mechanics, I believe it has what you are describing. I showed some footage from it in this video.
If you were to duplicate the jump logic from Mega Man 2 for TMNT, you'd have to consider adapting for 30 fps and probably adding the automatic double jump to the end for jump height requirements.
Platforming in the NES Mega Man series feels good, and the frame rate allows for it.
Great discussion - I love how you use specific dissections to look at broader concepts as a whole. For a lot of these 'bad' games, I'm really impressed by the ingenious (if imperfect) solutions that devs came up with, operating at a time with very little precedent or theoretical knowledge. The fact that many of these solutions are still perfectly functional in modern development contexts is mind-blowing to me!
Your videos are great for indie devs! I would love it if you ever have the time to look at the hit detection in Ironsword. The way armor and damage works in that game is so strange.
This video makes me wonder about another NES oddity: _Ghosts 'n Goblins._
There's nothing "wrong" with any of the game aside from some generic NES vertical-wrap glitching. However, I find it incredibly odd that the game seems to run at, like, 15 FPS…
Nice to see someone giving this game some attention, I think it's a great game that just needed more polish, and I'm glad to see you taking a stab at making it just that much better
Thank you!
Interesting this comes up not long after I went into a personal deep dive into Shadows of the Empire PC's gravity, and how it's affected by framerate.
Konami and Digital Eclipse should have come to you, before putting this game on the Cowabunga Collection. They could have talked to you to help them make some tweaks to the game, to fix some of it's oversights with your knowledge. They already tried with the "Remove Flicker" and "Remove Slowdown" options (which don't even work 100% reliably anyway), but with your help and knowledge of coding, they could have made a lot more bug fixes for this old game, so that old AND new audiences could enjoy it much better.
I assume they still have access to the original source code and didn't lean on the wrapper-emulator alone for all of their tweaks, but maybe that was the extent of their changes.
That said - I am not sure if the ROI for putting time into tweaking the original game mechanics is worth it for them.
No kidding - this series is the best on UA-cam. So much value. Thank you.
It’s like you peered into my childhood and found all the frustrating parts of this game to make code videos about. I wonder if there’s another way of tackling the problem by changing horizontal movement slightly. I just wonder how much level design would need to change in order to support the new physics. Since I never beat this game, I’m not sure if changes would make soft locked situations occur.
This channel is a treasure cove for developers
Honestly I don't have a lick of coding knowledge, maybe a slight idea of how scripting generally works as a whole. But these videos are still INCREDIBLY fascinating to me. I can somewhat understand the basic idea of what you're explaining, and your explanations are just wonderful. Great stuff, man. 👍🏻❤️
Thank you, James. Your comment means a lot as I want the video to be as accessible as possible despite loading it down with technical information.
This is fascinating, from design considerations to a bit of code walking. If you get enough people tweaking the code achieving different solutions, I'd love to see a follow up on this one. If not, can't wait to see what you tackle next!
Becoming one of my favorite channels. Your video narration & explanation are excellent. I'm also not a programmer. Keep it up!
Thank you so much, John!
I doubt the floaty jump was a mistake. Or at least, it wasn't left in on accident. If it was a result of changing from 60fps to 30, I would think that they noticed and preferred a more floaty jump for this game, electing to leave that value as is. They clearly designed the levels around it, having a few points where specific jumps (or even not jumping at all) are required to pass, expecting the player to learn that mechanic. Use the wrong jump, you don't pass, thus making sure that only players who understand this mechanic move on to a more difficult section. The choke point shown doesn't even have the consequence of failure as high as most other games, since you don't lose a life or any health from it.
My gamer friend always complains that good movement is easy to make in a game and programmers are bad at their job (because I'm interested in game dev). Meanwhile here is a 13 minute video breaking down just the player's jump. It's not easy, people.
Thank you for explaining one of the major frustrations of my childhood to me. ❤️
A simpler solution, IMO... Just make the turtle (an amphibian creature by nature) be able to swim!!
Lol. Just a gag coming from my frustration with this game. Awesome video, as always. Learning how code works for these “simple” aspects of a game really makes me value all the effort the programmers put into their software, even if they failed.
But... they CAN swim. There's an entire level dedicated to it.
@@Pulmonox They forgot this logic gap when you fall in water in a sewer.
@@Raytheman581 It's clearly _holographic_ water, planted there by Shredder to trick them into falling to their death in a black hole!!!
@@neoqwerty Darn that Shredhead! What will he think of next.
I remember the dials on the NES Advantage allowed you to set up the controller to always do a small jump when you press the button.
I wonder how development on these games would have been different if the devs knew that 40~ years later someone would decompile their code and do an in-depth analysis of the small mistakes that led to some of the most infamous glitches and problems in their games. We see the effect that day one patches and the danger of someone datamining your game have on modern development, and the funniest part is that some of these hot-fixes are totally doable with just a bunch of game genie codes.
It definitely makes you think. Back then, programming was a done deal because nobody expected the general public to have the kinds of tools to be able to do this. It's honestly fascinating.
While I wish we didn't live in a "release now, patch later" world, it sure is nice for devs to not only fix bugs but also tweak mechanics after a game has been released.
Pairing this approach with a physical release that does not contain those patches as well as the possibility that the server that provides those patches could no longer exist at some point in the future is a cause for alarm for those that may want to revisit a PS5 game (for example) 20 years later.
back then they did not have the tools and what kind of cuts / quick changes where made to make the games fit into the rom space / cpu power / ram? Other stuff cut for time leading to quick changes to get the game out on time?
I'm really happy someone is finally digging into the original TMNT game like this
Hi man! Congrats for showing us these great things! I have a request. There seems to be a glitch fighting Shredder. Sometimes, even if you kill him the game stucks, your turtle freezes as he goes on trying to hit you. It should be something with Shredder's lifebar. You could make a video about this!
I recall that the creator of Rockman 4 Minus Infinity was able to free up something like 40% of the CPU by re-writing the music code (!!!), allowing that ROM hack to be drastically more complex than the original game. I wonder if there aren't some optimizations that could be done to key game loops of TMNT to free up enough CPU cycles to make it a 60 FPS game.
Wouldn't be surprised if that's the case: Mega Man games in particular, I recall, where often made on a death march-pace and I wonder if even this game, big a license as it was, was made with enough time to really work out CPU-freeing solutions or if it was just "do whatever to get it working it needs to be done now now NOW!" With our increased knowledge, documentation and time, so much more is possible now than was back then...
PureSabe is _nuts_ with what he squeezed out of MM4... And he did it again with Rockman 7 EP!
Have you looked into Getsu Fuma Den on Famicom at all? I always had the impression that TMNT was built on top of its codebase, but it's a 60 fps game, so it'd be interesting to see what changed in the physics code between the two.
I did look at Getsu Fuma Den a little bit while making this video! I wasn't in there long, though.
You are the second person to being up Getsu Fuma Den in the comments, and I am glad that a bunch of us are kinda on the same page in terms of Konami code/engine history.
I will say this, though - at a glance, the TMNT engine could be a bogged down and heavily modified version of the GFD engine (if the two are related). I wouldn't be surprised if Konami assigned Turtles to a "B team" and said "use this as a starting point to create a Turtles game."
While the two look to be related, I only really tracked down the gravity constant. It was not a match to TMNT (regardless of frame rate), and I want to say it is applied in a different way. So even the logic may have been a bit different.
Imagine just sitting around disassembling 6502 all day. This guy is living the dream 😎
Flashback to early 90s, preteen me cursing the sewer jump. I would later come across the turbo 4 controller and discovered that the top jump button on the controller was mapped to short jump.
Never thought I would revisit this experience as a hobbyist game programmer from a completely different perspective 3 decades later.
The problem with TMNT is that they can't swim and they're turtles except for the dam level
Is almost like they are tortoises, not turtles
Strong currents
@@affegpus4195 Tortoises are turtles.
@@ciceronx Tortoises are land animals and can in fact not swim.
This is a really interesting topic! Making old classic games feel better to play is really nice. Also the perfect feeling to a games physics is an interesting topic. Perhaps it's hard to find that sweet spot, wich everyone likes.
When we developed Alwa's Awakening to modern platforms as Steam, PS4 and Switch etc. We went for what we thought would be the sweet spot for game play and feel to the game. Some people often comments that the gravity is feeling sluggish and the movement speed is to slow. After getting used to the settings in the game people somtimes change their opinion and sees the benefit when doing hard jumps.
When porting the game to a real NES, we wanted the game to feel like the original on Steam etc. Brad Smith who made the conversion to NES made an excellent work, and the game feels just like the original. I guess it would be possible to find Game Genie codes for the NES versions that alter things like the gravity and movement speed. But as you said, this would affect the gameplay in even more than just movement speed etc. The leveldesign is made for the settings made in the original code, and could mess up the playability. Still it would be awesome to play around with some settings using Game Genie codes for the game.
Thanks! I know nothing of code but your videos are still interesting enough and reveal things to me that I find amazing. And top notch editing skills.
Thank you. I really appreciate it!
Just started watching this because I recall being stuck on one of the levels for days as a small kid. I eventually figured out you had to lightly *tap* the jump button to pass without hitting your head and dropping into the water. Edit: LOL you covered the exact spot I was stuck on as a kid at 6.21 !!
Nice deep dive into the TMNT jump mechanics.
Me in highschool: I don't need math, I wanna be a game designer.
Me now: *DAMMIT!*
Each new video feels like Christmas morning. Keep up the good work :)
These code videos are all super helpful!
If there is any game I would love to see code insight for, it would be SNES Harvest Moon, specifically what effects weather RNG and fishing RNG!
Dunno why but I love this channel even though I understand the bare minimum of programming talk. Well done captivating even us who arent that knowledgeable, but just love retro.
always great to see a little under the hood of a nostalgic game.
I wonder if there's anything interesting in the old NES ducktales game. movement in that game always seemed really great, so maybe that's only interesting in a "what makes it great" sense, but the way enemies spawned was often quite annoying. maybe that's also an area worth looking into.
Another amazing video. Konami should have let you make a patched version of the game for Cowabunga Collection!
Well this video made this Thursday morning a lot better
Love this series. Really well done
Love these kinds of videos. You should really release these tweaks as patches for everyone to enjoy.
TMNT really is such an interesting game to look at under the hood with all it's design and gameplay quirks. You can do it!
Standard falling acceleration in platformer games is actually faster than proportional effects of real gravity on humans in real life (in addition to other industry standards like midair redirectional control). That's right, high jumps aren't a result of "low gravity" but rather games have _high_ gravity making the extreme heights of heroes' high jumps all the more impressive!
Posting on a very old fire tablet.
Your videos are very good and I enjoy learning about coding.
If I had to give a next tmnt fix, it be Ralph's and Mike's attack method. Since Sprite editing might be outside your wheel hous, yet I also feel like Feasters Quest also covered damage and distancing I would be interested in hearing your thoughts on basic ideas on how to fix it.
Thank you for your video again.
"What is gravity?
In physics, it's a fundamental force.
In game programming, it's an opinion."
What's mind blowing is that this channel doesn't have millions of subs
I love having jump heights you can control in a platformer, but I never thought of having the jump heights set at specific intervals.
When I've been coding I've always set it to simply set the vertical velocity to zero once the player lets go of the button. This is what it always felt like games were doing, but maybe I have been wrong.
How are controlled jumps handled within Batman (NES)? Even as an adult I always felt like a champ for pulling off tricky jumps with expert timing. I wonder if the game was secretly holding my hand with a design similar to this...
Yay another vid from the master, always get excited when you post love your vida
Speaking of jumps, I would love to see how the Roc's feather or other pretend 3D jumps are done in games like Super Mario RPG or games that can vary the jump height in '3D'. :)
Correct me if I'm interpreting this wrong, but a 4 frame window for the short hop at 30 FPS would be equivalent to an 8 frame window in a 60 FPS game, correct? I understand that this may be a little difficult for people at first, but when compared to games like Smash Bros it is still a really huge window. Short hops are performed in Melee by releasing before the jumpsquat is concluded. For the fastest in the cast, that occurs on frame 3 (at 60 fps). In fact, only one character in the entire cast has an 8 frame jumpsquat, Bowser.
If anything, the middle jump seems the most difficult to perform in TMNT. Since holding long is trivial, and releasing quickly is just accomplished by tapping. Only the middle jump requires timing.
So are we going to get a video on the iconic Super Mario Bros. jump physics? -- I would love to see this!
It would be even better if we got to see the differences between all three of the original NES games!
Yes, I agree. The flat bounce rate whenever you stomp on a Koopa against a staircase for points and infinite 1-UPs is unforgiving. In Super Mario All-Stars, for the first Super Mario Bros., this has been corrected to a slightly higher rate ($FB vs. $FC) and the player now continuously jumps on the Koopa without interruption. However, this has not been changed for the Vs. Super Mario Bros. arcade game, which has some level layouts we'd also see in Super Mario Bros. 2 (Japan; what we call Super Mario Bros.: The Lost Levels), and so for some of these altered levels this flat bounce rate does not work well over very wide gaps even when Mario stomps on a flying Koopa Paratroopa.
For The Lost Levels, these physics have been altered to a significant degree to address the shortcomings in the earlier games: the player's Y speed is now loaded into Y instead of A, with an initial set value of $FA for even higher rates of bounce against enemies. For the flying Koopa Paratroopas, a special check occurs, which is loaded into A, to see if you have stomped on either one of the two varieties of this enemy (red=vertical and green=horizontal) and, if so, to load the much higher bounce rate value of $F8 into Y instead. Two jumps to this changed bounce rate check have been added to the end of the 'EnemyStompedPts' routine (a JMP, which replaced a rather unnecessary Y speed check that ends with an RTS) and right after the BCC in the 'ChkForDemoteKoopa' routine (a JSR) while the JMP to the old bounce rate check that ends the latter routine was changed to an RTS.
@@ClassicTVMan1981X This is very interesting. I'm very curious about the iconic jump physics between the various mario games. The SNES jump physics were the best feeling out of the series, but the SMB3 bounce from on top of a koopa when holding the jump button was definitely the start of what a great-feeling mario game was.
I'm not sure whether I prefer the SMB3 or SMW bounce mechanics, but both were definitely good for their respective levels and level layouts, though SMW could be exploited quite a lot more than SMB3 by players.
@@awesomedata8973
And let me add that what I said is especially true for the PAL (50 FPS) releases, even the later one with the bugfixes included. The flat bounce rate wasn't changed from NTSC (meaning still $FC), and so for PAL it's very frustrating to try the turtle tipping trick for infinite lives. In both cases, a Game Genie code can be used to fix this: XNYIXO (for the first PAL release) or XNYIKO (for the second PAL release), which will change the bounce rate from $FC to the higher $FA.
For the PAL release of Super Mario All-Stars, in Super Mario Bros. they changed this bounce rate to $FA, while in The Lost Levels, the mainstream bounce rate is now $F9 while that for the flying Koopa Paratroopas is $F7.
I beat this game on the Cowabunga Collection, but oh man...that Rewind feature was CRUCIAL because the jumping and pits/water were so TERRIBLE. Glad you took a dive into this!
Oh wow. I didn't know they put a rewind feature in it. That was nice of them.
Love your videos. Would like to see a deep dive into more mechanics of the MegaMan games someday. Keep up the good work!
What would you like to see in the Mega Man series?
Anything, really. I enjoyed the videos on zipping and QuickMan's AI. Perhaps a glance at how the code evolved for how MegaMan moves around from 1-6? Might turn into a lengthy video, though.
Neat analysis video! Thanks for uploading!
Nowadays it is exciting to have a deep look into the games internals using emulators but at the time the game was made, I can't imagine the stress if such tweaks were performed at the end of the development cycle potentially breaking the levels anywhere in the game :D
NES TMNT is so frustrating because visually it hosts all the things we young gamers wanted in the game.
Thank you for this video which shows the ways it can be improved. I do hope your suggestions are taken up by the community so a sincere patch is made that turns NES TMNT from a rough cut into a sparkling gem.
Even if it was theoretically perfect, only tweaking things like physics and framerate, without altering any fundamental game design decisions, the game would still be _boring,_ and that's the worst thing that a piece of entertainment can possibly be.
At best, it would go from worthless to sufficiently playable. You'd need to essentially completely overhaul the game design for it to be considered good.
@@alfiehicks1 I played Silver Surfer. "Sufficiently playable" is my jam. :)
This was super-interesting. I am not well-versed in coding fo rht eNES or anything, but it was pretty understandable - great job!
Excellent video and background music ;)
Awesome video! How do you go about getting the source code for these games?
I would love a tutorial in how to swap the damage output for each turtle to make it more balanced.
I assume they thought it would add some strategy to switch turtles depending on the enemies in the current area, but switching all the time just for damage output gets monotonous rather quickly, imo.
I know that different enemies take a different amount of damage depending on the turtle used. It isn't just about which weapon is being wielded. So I assume there is some sort of main LUT used depending on the enemy attacked and then turtle selected... with some sort of base case.
So one approach would be to locate the table and edit it as a ROM hack or perhaps edit the code so the turtles do some flat amount of damage.
Also consider that there are damage boosts when a turtle has lost so much health.
this is cool. video game jump mechanics have always been interesting to me.