From a few minutes of my own research, Strider NES was originally made by some Japanese team, never finished, then handed over to an American team who "finished" it by just translating it and leaving everything else incomplete. This entire game is just some cursed spaghetti code casserole that wasn't even put in the oven. It's _fascinating_
According to the game's composer, work on NES/Famicom Strider was pretty much finished when Capcom decided to only release it overseas. There's a prototype of the Japanese version that's clearly unfinished compared to the American release. NES Strider is a finished game. It's just a poorly programmed one. It's more likely that Capcom didn't release it in Japan due to the manga not being a huge hit (it lasted one volume) and the Famicom market being tighter. In Japan the game industry was more competitive by the end of the 1980s because of the PC Engine's success, but in America the NES still dominated everything. The NES version of Legendary Wings was a similar deal, developed by Capcom in Japan but never released there.
It's really a shame; I absolutely LOVED the direction they took the NES game, far more than what the Arcade game did. It would be really nice to see a properly-made version of this game, following the expansive sort-of-metroidvania style that the NES version was trying to accomplish.
If you're looking to investigate fascinatingly broken games, might I recommend Super Pitfall? Everything in that game seems to be held together by string. Why do the lava bubbles corrupt the music? Why do you just randomly jump through the floor sometimes? Why do the waterfall sprites disappear so much? Why do none of the enemy sprites ever line up with the terrain properly? The game is a real treasure trove of brokenness.
This video should be shown in software engineering classes, as an object lesson for why the concept of Finite State Machines is important to understand. The programmers here clearly didn't think in terms of "here's the checks to do if the player-character is jumping; here's the checks when he's walking; here's the checks when he's standing still on the ground; etc - and he can only be doing one of those at a time"; but instead just did every check in every "state", as the ASM equivalent of a long series of if-statements, with many possible overlapping "states" active at once.
It's not really an issue that an FSM addresses directly. It's a constraint programming issue, because the physics in Strider are supporting several features simultaneously that produce multiple competing answers: are we ascending a slope, is a wall colliding, are we jumping, are we trying to triangle jump? What a constraint solver does is frame the problem in terms of "filter down many competing and potentially valid answers into a single definitive one by turning it into a sorting-and-ranking problem". Applying sorting makes it much easier to reason about than trying to break it down into a large number of finite states. What Strider actually does, and what everyone tends to do when addressing constraint logic one feature at a time, is to add more and more state to try to adjust one answer as you go along, losing a lot of information in the process. You don't want to lose information in your physics until you know you can make the optimization(and this is why the common axis-aligned platforming logic of "run X axis physics, then run Y axis physics" manages to work well, but imperfectly - it's an optimization on solving for both permutations and selecting the one that gives free movement, it just drops one permutation from ever being considered).
it's very good for my imposter syndrome that the way these types of bugs are created require programming in ways that immediately set off alarm bells in my head.
It's worthwhile to note there are good times to use this kind of code, like when you want to blend logic. A string of conditionals in the right order can keep code very tight and produce muliple effects. For example, if the player is not touching the ceiling, skip to the next check, otherwise set vertical velocity to zero. This allows all previous X movement to continue to propagate while allowing downstream gravity or ejection to start from a known point. It requires extensive planning, but it allows for overlaid logic to address complicated states.
So, the sprite logic starts late in the frame, the controller inputs are read late in the frame, and the physics calculations happen late in the frame.... What is Strider doing early in the frame? Microwaving fish soup in the NES's breakroom?
Late in the frame is specifically when you want to do all the input and input-dependent tasks. The later you can do them, the less total input to output latency you're going to have. But before the vblank hits and you have to update the scroll and upload the sprite table quickly. If you're wondering what you might be doing early in the frame... well the very first thing you want to do is pick a good time to run the sound/music routine to update the soundchip registers, maybe you do this on a line interrupt to reduce jitter, then you want to load the graphics tiles for the things getting scrolled in, which takes a while, update the tilemap. You might even be doing enemy animation sprite and position updates early in the frame before you process inputs, projectile updates as well. You do this in the shadow buffer in main RAM. Enemy logic too, because if the enemy seems to react to your actions rather than catch them mid flight as if it was mind reading you, its just a tad more convincing. You can process pickups before inputs as well, making them also a frame delayed, it's fine, looks even a little weighty, nice.
I used to laugh out loud at every juddering sprite and shaking pickup when i played this as a kid, now that i have a little bit more knowledge in coding and such this just makes me realize how up against the wall the devs had to have been to have all this conflicting code. Just seeing Hiryu running against a wall like in every other NES game made me realize just how robbed we were of an optimized version of this.
To me it seems like the coder had no idea what they were doing and created their own "creative" ways out of lack of experience. It doesn't make sense to me that they would program it this way first and then try to fix it later. If someone knew best practices they'd do it right the first time
@@MaxOakland back in those days, no one knew the "best practices" for making video games, (platformers weren't even a decade old at that point, and it's not like many of the previous entries in the genre could be looked to as positive inspiration), and they were moreorless programming on the bare metal, not much different from the changes we see in the video, so it may not have been totally obvious what each function was doing without a lot of tracing . . . probably on graph paper. Emulators didn't exist, and nintendo didn't produce software to run the games on PC, so you had to load prototype carts, insert those into dev machines, and test that way, and that could take hours from start to starting to play the prototype. Strider is . . . particularly bad, but a LOT of bugs in old video games, even otherwise well-polished ones, are simple off-by-one or swap-two-instructions errors, which I think is a good indication of how difficult it was to debug on the platform.
Times were definitely different back then. I don't think programming this logic, you would even get a chance to "run" it, you would be sitting there with grid paper and flowcharts making the jump mechanics, and maybe different people actually coded it vs writing the grids. Like think about this - an engineer with a math background "designs" the jump, hands it to some coders to "make" the jump and at this point nothing is even running on hardware yet. A month later long after thinking about the grid paper and math, you find out the code doesn't work that great and then you are finding out it needs a ton of band aids, the code the other guy wrote was sloppy and meanwhile the scroller guys decided to skip your frames once in a while. Meanwhile, another month later, a QA team plays it, says "it's not that great... " and the boss says "but is it playable?" and the QA team says "well kinda". And then 3 months later, it's on the shelves ready for Christmas.
@@djrmarketing598 beta testing was very common. But even if they didn't have beta testing, this is a weird and uncommon way to do physics logic. That's what makes it so buggy and so interesting
I had to spend literally THOUSANDS of hours playing NES Strider, even though I'd avoided it for decades. I felt it was my duty to make sure I encompassed everything "Strider" that I could, when I made the Strider 2014 game, not just what I've loved about Strider since 1989. Oh so very painful...
Despite NES games being somewhat of a niche, this is honestly more valuable than most game development tutorials and "essays" I've found. It's not about the code per say, as in, what I should type. It's more about the problem I'm trying to solve. The way you structure your videos gives me better ideas about how I should try to think about specific problems, and the logic required to make the code blocks I write work with each other, instead of just trying to find the right "Fix", the right math formula, whatever. I can't say I understand everything, but you often put me on the right path, and that's all I can ask for.
Honestly what I love about channels like Displaced Gamers and RGME, they focus less on what the code says exactly and more on the logic of the CPU and likely what the developers were thinking when designing things. It makes it very helpful to actually learn and understand these things. Very useful, even if you aren't familiar with 6502, or even retro games in general.
I LOVED this game as a kid, but I absolutely HATED the physics. It was so bad, that I put it away for years until I was a teenager and gave it another shot. I beat it and loved it, to a point. The physics made it where I couldn't recommend it to anyone. Thanks for explaining the issues.
There were so many games like that for me. I've always been bad at video games, which is at least partly why I like RPG's more than platformers, less frustration.
This one was a blast. What do you think of holding down A for the Triangle Jump? Should I have gone for something else? There are so many other issues to address in Strider. Speaking of things to address in Strider - I think I will upload some of my Strider work to the Displaced Gamers GitHub (by the way... Displaced Gamers "is on GitHub"). This project took a lot more reversing than usual. Perhaps someone can take the work and run with it. github.com/DisplacedGamers Hope everyone has a great day!
Seems like a relatively sane solution to the problem and an elegant fix that you can do it in a single GG code. As far as overall "feel" of wall jumping, I think nothing has beaten the Mega Man X series for me, so I would consider it an improvement if your fall speed actually reduced down when in contact with a wall instead of sped up, but I also think Super Metroid feels awful when a lot of people tell me they have no problems with it, so maybe it's a "me" problem.
@@WillowEpp Super Metroid's wall jump is tricky, but the game helps you a little with a unique frame of animation to let you know the window to press the jump button. If you're spin jumping along a wall, then press away from the wall, there is a window of about 2 frames where Samus' sprite switches to one where here feet look planted on the wall. That's when you hit jump.
@@GeekSHO Oh, I know exactly *HOW* it works. I _can_ *do* it. I just hate how it feels. It _feels awful_ to me. This is a subjective thing. (I still think that if there were more than three months between the release Rockman X and Super Metroid there's a good chance it would have turned out differently, but we'll never know for sure. ㄟ( ▔, ▔ )ㄏ )
Heh, so the Nintendo Power tip for triangle jump is basically to button mash and hope for the best. Really was a poor implementation of wall-jumping. I still love that way Batman does it. That lil stop as his sprite animates to change direction is strangely satisfying :O
As seen in the comments sections of the first video, NES Strider seems to have been initially programmed by someone with no (or very little) previous experience with the system and then a more experienced programmer at Capcom (who was responsible for that game) had to jury-rig fixes just to get a "sellable" product out the door in a relatively tight time frame.
even 30+ years later the NES ninja gaiden sprites are so lovely. Even if it's just a screenshot/photo. I was chuckling when it switched over to strider and that pill pickup was all shakey
I’d love to see a series where you take what’s been learned from these videos and slowly build up the most optimal/feature rich nes side scroller possible. (Though that would be a monolithic project)
That would be a crazy project, indeed. That said, perhaps these videos are a good resource for any other developer to do that very thing. I'll keep making more of them.
You're honestly the best at this particular niche, and it's a huge window for many people my age to get into programming with content we can relate to that isn't at the "Hello world" level of baby steps. The understanding and presentation is simply unmatched.
This is a delightful look into a game so hilariously broken it's a miracle it runs at all. Please, cover this aberration as much as you'd like; it's absolutely fascinating to watch you go through this code - it's less 'sphagetti' and more like a pile of hashbrowns.
MY MAN! I had a sneaking feeling you'd be the one to crack this. Very impressive work! I remember renting this a couple times as a kid, without the manual, and not knowing what to do when that first required jump came up in the Egypt map. It always felt off, because everything else for those first ten minutes was so easy.
Thanks for another deep dive on this broken mess of a game! This has been a fun mini-series so far, and I suspect I'm not alone in saying that I would love to see a part 3 with some further analysis on the bugs you didn't get to in this video.
Oh you're definitely not alone in wanting to see more of the code that produces this busted aberration. That said, I can totally understand if DisplacedGamers needs a break from it. There's plenty of other wonk games out there, after all.
Early day programming was so obtuse compared to what we can do now. It's still really fascinating to see the weird ways early game code tried to solve problems. Videos like this make me wonder how much different older games would be with a "code update" I know that there are plenty of examples in the ROM hacking community but it's still fun to think about.
Wow. Just crazy. First, the amount of work you went through to set up all that testing and output just to figure out just what in the world is going on with the game lol Second, I'm experiencing that weird feeling of remembering how the jumping felt and now having the understanding of the code's logic present the connection between the experience and the problematic code. Sort of like that innate feeling you eventually gain in physics class when understand what it feels like for falling objects and centripetal force and then applying it to say being on the moon and almost being able to envision-experience the feeling of what it would feel like. I always chalked up the triangle-jump jankyness to the frame rates of the game and me needing to be slower because the game just couldn't keep up with the input. Now I see (and can almost feel) the effects of the routines in place causing that sense I had so many years ago, and now understanding just how affected the jumping was, not because of the performance, but because of the code design. On a similar note of performance. There's a little known-game that might be worthwhile looking at is Bio Force Ape. Back in the NES vs Sega days, there was that whole rivalry that was taking place and the blast processing marketing that Sega kept marketing to compete against NES' slower performance. They used Sonic's speed as their main marketing tactic. However, Bio Force Ape which was never released but someone discovered a playable copy in 2001 (I think it was 2011), and it's speed is, what looks like to me anyhow, right on par with Sonic. It might be interesting to see a breakdown of the tricks they used to achieve the speed increase. My guess is a lower sprite count, but that's probably way oversimplifying it since they probably did tons of other things too.
I actually took the time to finish the game despite the awful experience of movement and every sprite interaction feeling glitchy. I had recorded the last stage on a VHS tape of games I had completed, so I got to watch it again over the years. This video doesn't even get into the difficulty of jumping effectively off of slopes which are prevalent in the game and usually interacted with while scrolling is happening. I had to figure out the wall jumping without knowing any of this too. I would just try and try again when physics broke and I definitely remember making sure to stop the screen scrolling before difficult jumps despite not knowing why this helped. Thanks for making all those hours of frustration finally feel like it wasn't my failure to learn... it helps to know that I was actually learning to subconsciously manage a handful of horrible bugs and somehow still be able to beat it without having to restart my VCR recording too many times to make it possible.
Thank you for making this video. Its one of the few i completely understood, regardless of my lack of programming knowledge. I played the game enough as a kid (and still remember) to get exactly what you were referring to via the code... and just how stupid it all is in regards to Capcom making things overly complicated, plus being absolutely sloppy as hell! would be really cool if you wrote a patch for the game to fix all these issues to make Strider actually worth playing AND worthy of Capcoms name down the road. Im sure a lot of us would be elated to play a PROPERLY FUNCTIONING version of this game versus one that (as you put) tied its shoe laces together and face planted! LOL! Btw, excellent use of Out of This World as a visual reference (I got a damn good laugh out of that).
"It gets better, as in worse" is a pretty good way to describe this games coding. Highly doubt its the worst offender of bad NES code but its probably the worst on a game that was actually somewhat known. I never had Strider as a kid but i knew it was another NES game my friends liked.
This is a fun reminder for the GDQ "Learn to Speedrun Strider" segment from a few years ago. IIRC they literally had someone new to the game come up and do a run beat it in minutes because of how completely borked it is. Hope to see you going over moonwalking through walls as well as the others.
Thanks for covering strider! One of the few games we had as a kid and most people have never heard of it. Those wall jumps were sooo tough, I'd run out of time for the level trying to do them
A solution that comes to mind to fix the triangle jump logic: only require the button press, not the direction change. The player will still naturally hold the wanted direction to reach the opposite wall. To prevent abuse, we could also ensure that you can't jump more than once in a row from the same wall (by comparing the x position of the wall jump with the previous one?)
Back in the day we just learned how to do it. It wasn't easy but I beat the game. I can attest that the technique did not stay in "muscle memory" as I tried playing it again and could not pull off the triangle jump with any sort of consistency.
It really looks like they were learning as they went along and just added band-aid fixes as they encountered things. Reminds me of my first try writing a pac-man clone.
"Holding A and just using the controller to wall jump" is basically what I did as a kid...with the A button on turbo. I wonder how they handled it in testing. I mean, someone had to have at least played through the stages, right?
Awesome. Thanks for continuing to look into Strider. I mentioned in previous comments as well, but definitely have a look at the leaked Japanese unreleased ROM sometime too, it's broken, but in different ways. Now having seen some of the weird choices you found in this video (+1.5, wtf) I'd guess the JP ROM might be a build before it got given to someone who didn't know the code to "polish" before dumping it out to the US market.
I've started writing my own emulator, although for the PS2 and not NES, but I'm definitely going to incorporate a debugger into it because of your video series. The more I see of this series, the more I wish every emulator had a debugger built in. I know it sounds silly, but I'm also going to write a PS1 emulator at the same time because if it does PS2 games it should also handle PS1, since the original hardware could, and I don't accept the later revisions that removed those chips as valid for the purpose of writing my emulator.
@@anon_y_mousse really think you're thinking of the PS3's loss of PS2 compatibility, as most of the PS1 hardware in the PS2 was a pare of the IO Processor and integral to operation in PS2 mode. That's where the R3000 lived, as well as the DMA controller, sound processor, controller and memory card port handlers...
This is FASCINATING. I've always loved this game, warts and all, and think it'd be a prime candidate for something like a Blaster Master Zero-style remake. I take some pride in having gotten pretty good at this game's finicky triangle jump, and although it's a happy accident at best, conceptually I like the idea of it being a very hard technique to pull off. I mean, it would be! Incidentally, I never took to the arcade/Genesis Strider, despite trying to get into it roughly once a year.
Whoa.Somebody actually explained the games"springy" jumping. The game felt a little glitchy with the scrolling and graphic tiles. Still,cool game and it's different that the other Strider games.
You know, watching these videos about Strider, I really don’t know how my friend and I beat it as kids. I know we beat it because I remember the story and everything. But holy crap that triangle jump must’ve given us fits! Thankfully, I did have a subscription to Nintendo Power and I did have that issue.
That code is an absolute mess. The fact that the game is functional at all is amazing. I know with the triangle jumps the easiest way to get consistency with it was to hesitate about a half a second when trying them. The presses indeed needed to be precise.
I remember when I first played Strider on the NES, I was seriously considering taking it back to the store, because I was *sure* it was a defective copy. That's how bad the physics are in this game, and it's nice to see some explanation, even if the explanation itself is baffling - why would Capcom do this instead of just using a normal jump physics routine? Was it all to (badly) implement wall jumping?
... also, I was amused that Strider bounces off walls the same way as the square in Adventure, for what I suspect is the exact same reason (specifically, that it has wall ejection without wall collision). Even later Atari 2600 games like Haunted House don't do that.
@@MaxOakland The game's credits highly suggest that the initial programmer was indeed very inexperienced with NES development and that a more senior programmer had to jury-rig "fixes" to get the game to a "sellable" state.
Haha all the problem described are the pretty similar to the ones I'm having trying to implement jump/collisions in GM, thanks for the detailed analysis on this and the Ninja Gaiden games. Its a great guide platforming designing.
My childhood game and I'm so glad to see I'm not the problem the game is 😆. So happy to see you explain and fix the game. Looking forward to seeing more😄😄
As a kid, i had no idea Stixer had all these problems. Despite that, i still managed to finish it. I still remember my save file code from over 30 years ago. I played the hell out of that game.😅
You can! He provides Game Genie codes for most of the fixes, and the ones that he doesn't, he usually shows where in memory he's making changes. You could either hex edit a ROM or use Mesen (or another emulator that allows on-the-fly memory edits) to apply his patches.
Oh good greif man, My apologies. This is the one thing that's always kept me from completing Stryder and was a bit inebriated when asking. You gave it, thank you. This is the best surprise game genie code from your videos ever!
I love this game, rad themes, rad graphics, rad music, rad ideas, but JESUSCHRIST.... *THE JANK.* The game is now much funnier to me knowing all of this weird logic is going on while we play it, it's one of those games so broken it would need to be entirely re-coded in order to work properly PS: I'd love if you did a video comparing Menace Beach with Sunday Funday. They're unlicensed games, originally by Color Dreams, then modified by Wisdom Tree. They're essentially the exact same game with a few graphical differences, but Sunday Funday runs much smoother and detects inputs quickier, I'd love to know why (and see if that can be done for other Color Dreams/Wisdom Tree games that use the same engine)
amazing video right here. i don't know the development story behind this game but i imagine it must've been, uh, stressful. at the very least. makes me realize that for how much video games have progressed, devs have always been rushed to hell and back and buggy shit has always been tolerated somewhat so long as a game releases lol would you someday be interested in taking a look at just wtf is happening in the game Super Pitfall? from what i've seen it's a really buggy mess and i don't think anyone's actually done a deep dive into it. though tbf the nes does have a lot of buggy games in its library, so i'm not really surprised lol
Lookup tables does reduce the CPU load, which was probably the solution they picked to keep the game running as fast as possible. But yea 😅 if you mess up the value’s it’s probably worse than slowdown
Hearing the short version of doing the Triangle Jump: "Oh, so it's like Super Metroid?" Hearing how broken it is: "Wow, that's... not a good implementation"
11:13 & 15:51 This is not a good suggestion to do the Triangle Jump because this is also what I did initially by myself without relying on any guide or advice as a kid playing the game in 1992. Wildly rocking left & right while jumping only brings frustration and finger injury. The method that works for me is : There is no need to hold down the jump button. Tapping jump or holding jump will give the same jumping height results. Do not walk against the wall before jumping, your jumping height will cut short to about 1/3 making it impossible. Do not rock the direction left & right multiple times wildly within 1 second, the actual timing is changing the directions calmly around each second. Doing it too fast will make you fail. So watch from 11:36 - 12:01 carefully to understand the steps below. Do not be afraid of dropping down a few pixels; it is important, more reliable and comfortable to do the triangle jump this way. Start by walking towards the wall and tap jump. Let the character touch the wall, then stall and start dropping down a few pixels. Then only press the opposite direction, and then tap jump within half or quarter seconds to make a successful jump. (You can attempt to press the opposite direction & jump at the same time, but you will fail if the jump button is pressed first instead before the opposite direction button is pressed) Repeat the touch wall, stalling, dropping down a few pixels, then changing directions, tap jump within quarter second of direction change. Using a turbo jump will help doing this easier as it will help you concentrate on the touching wall, stalling, dropping down a few pixels, then changing directions. I have reconfirmed my methods above just a few minutes ago on my NES.
Having recently played through Strider NES myself last week as part of a full series playthrough, I can confirm that (at least for me) this method was more reliable than the few times I tried to rock the d-pad around. Triangle Jumping still wasn't _great,_ but I was able to get through the game without ever using the Jump Trick for platforming.
Other versions of strider (16bit) seemed kind of buggy to me as well. As a kid, I didn't know exactly what it was that made it look "cheap" overall (aside from obvious stuff like being able to jump through walls etc..), but videos like this one give me a glimpse into what might have been going on there from a code perspective.
What a huge mess of code, and here I was feeling like my own code from yesterday's experiment I had uploaded on RUclips earlier was completely busted. Maybe I didn't do that bad after all considering it's actually working exactly as intended, lmao
Oh God ... those wall jumps! Bane of my childhood! Whenever I got to one of them, I had to have my stepdad do them for me because I just could not get the hang of them, I always thought I was just bad at the game but now it's a small comfort to know it wasn't me at all...
The fact people can reach the end of the game is frankly a miracle when the spaghetti is mixed in with spider webbing, silly string, cheese string, shoe string, and worms.
if i'm not mistaken, super metroid actually uses a very similar wall jump mechanic. you have to make contact with a wall and then rock the d-pad the opposite direction about one frame before you hit the jump button again or it doesn't appear to work
i don't know if you take suggestions mr displaced but i'd love to see a deep dive on ghosts n goblins for the NES, things like why the game sometimes swallows your inputs, the crazy amount of slowdown and sprite flickering to rival mega man 3, and maybe the unforgiving game design like arthur having the belmont jump
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
From a few minutes of my own research, Strider NES was originally made by some Japanese team, never finished, then handed over to an American team who "finished" it by just translating it and leaving everything else incomplete. This entire game is just some cursed spaghetti code casserole that wasn't even put in the oven. It's _fascinating_
Yeah, it feels a lot more like a prototype than a full release. Still a really interesting game tho
According to the game's composer, work on NES/Famicom Strider was pretty much finished when Capcom decided to only release it overseas. There's a prototype of the Japanese version that's clearly unfinished compared to the American release. NES Strider is a finished game. It's just a poorly programmed one.
It's more likely that Capcom didn't release it in Japan due to the manga not being a huge hit (it lasted one volume) and the Famicom market being tighter. In Japan the game industry was more competitive by the end of the 1980s because of the PC Engine's success, but in America the NES still dominated everything.
The NES version of Legendary Wings was a similar deal, developed by Capcom in Japan but never released there.
It's really a shame; I absolutely LOVED the direction they took the NES game, far more than what the Arcade game did. It would be really nice to see a properly-made version of this game, following the expansive sort-of-metroidvania style that the NES version was trying to accomplish.
Yeah, I remember seeing that Japnese prototype a few years back. A - very - rough prototype at best, which never say the light of day.
This went from "I imagine it might be broken" to "Sweet Jesus, how this even managed to work?".
you should see his previous video (on sprite management) to see even more entertaining shenanigans :D
The answer is _just enough_
You've managed to encapsulate the entire process I go through every time I look at my old code.
As long as it compiles it's probably good enough
What's crazy is the cancelled Famicom version handled things even worse.
If you're looking to investigate fascinatingly broken games, might I recommend Super Pitfall? Everything in that game seems to be held together by string. Why do the lava bubbles corrupt the music? Why do you just randomly jump through the floor sometimes? Why do the waterfall sprites disappear so much? Why do none of the enemy sprites ever line up with the terrain properly? The game is a real treasure trove of brokenness.
'This completes our review of things Strider can do OK.' made me cackle
This video should be shown in software engineering classes, as an object lesson for why the concept of Finite State Machines is important to understand. The programmers here clearly didn't think in terms of "here's the checks to do if the player-character is jumping; here's the checks when he's walking; here's the checks when he's standing still on the ground; etc - and he can only be doing one of those at a time"; but instead just did every check in every "state", as the ASM equivalent of a long series of if-statements, with many possible overlapping "states" active at once.
Exactly. These can be extremely hard to debug
It's not really an issue that an FSM addresses directly. It's a constraint programming issue, because the physics in Strider are supporting several features simultaneously that produce multiple competing answers: are we ascending a slope, is a wall colliding, are we jumping, are we trying to triangle jump? What a constraint solver does is frame the problem in terms of "filter down many competing and potentially valid answers into a single definitive one by turning it into a sorting-and-ranking problem". Applying sorting makes it much easier to reason about than trying to break it down into a large number of finite states.
What Strider actually does, and what everyone tends to do when addressing constraint logic one feature at a time, is to add more and more state to try to adjust one answer as you go along, losing a lot of information in the process. You don't want to lose information in your physics until you know you can make the optimization(and this is why the common axis-aligned platforming logic of "run X axis physics, then run Y axis physics" manages to work well, but imperfectly - it's an optimization on solving for both permutations and selecting the one that gives free movement, it just drops one permutation from ever being considered).
it's very good for my imposter syndrome that the way these types of bugs are created require programming in ways that immediately set off alarm bells in my head.
It's worthwhile to note there are good times to use this kind of code, like when you want to blend logic. A string of conditionals in the right order can keep code very tight and produce muliple effects. For example, if the player is not touching the ceiling, skip to the next check, otherwise set vertical velocity to zero. This allows all previous X movement to continue to propagate while allowing downstream gravity or ejection to start from a known point. It requires extensive planning, but it allows for overlaid logic to address complicated states.
So in a nutshell they anticipated quantum computing in a videogame.
So, the sprite logic starts late in the frame, the controller inputs are read late in the frame, and the physics calculations happen late in the frame.... What is Strider doing early in the frame? Microwaving fish soup in the NES's breakroom?
Hey... What's that smell?
Late in the frame is specifically when you want to do all the input and input-dependent tasks. The later you can do them, the less total input to output latency you're going to have. But before the vblank hits and you have to update the scroll and upload the sprite table quickly.
If you're wondering what you might be doing early in the frame... well the very first thing you want to do is pick a good time to run the sound/music routine to update the soundchip registers, maybe you do this on a line interrupt to reduce jitter, then you want to load the graphics tiles for the things getting scrolled in, which takes a while, update the tilemap. You might even be doing enemy animation sprite and position updates early in the frame before you process inputs, projectile updates as well. You do this in the shadow buffer in main RAM. Enemy logic too, because if the enemy seems to react to your actions rather than catch them mid flight as if it was mind reading you, its just a tad more convincing. You can process pickups before inputs as well, making them also a frame delayed, it's fine, looks even a little weighty, nice.
It's finishing the overdue and now pointless sprite worn from the previous frame 😂
I used to laugh out loud at every juddering sprite and shaking pickup when i played this as a kid, now that i have a little bit more knowledge in coding and such this just makes me realize how up against the wall the devs had to have been to have all this conflicting code. Just seeing Hiryu running against a wall like in every other NES game made me realize just how robbed we were of an optimized version of this.
To me it seems like the coder had no idea what they were doing and created their own "creative" ways out of lack of experience. It doesn't make sense to me that they would program it this way first and then try to fix it later. If someone knew best practices they'd do it right the first time
@@MaxOakland back in those days, no one knew the "best practices" for making video games, (platformers weren't even a decade old at that point, and it's not like many of the previous entries in the genre could be looked to as positive inspiration), and they were moreorless programming on the bare metal, not much different from the changes we see in the video, so it may not have been totally obvious what each function was doing without a lot of tracing . . . probably on graph paper. Emulators didn't exist, and nintendo didn't produce software to run the games on PC, so you had to load prototype carts, insert those into dev machines, and test that way, and that could take hours from start to starting to play the prototype.
Strider is . . . particularly bad, but a LOT of bugs in old video games, even otherwise well-polished ones, are simple off-by-one or swap-two-instructions errors, which I think is a good indication of how difficult it was to debug on the platform.
Times were definitely different back then. I don't think programming this logic, you would even get a chance to "run" it, you would be sitting there with grid paper and flowcharts making the jump mechanics, and maybe different people actually coded it vs writing the grids. Like think about this - an engineer with a math background "designs" the jump, hands it to some coders to "make" the jump and at this point nothing is even running on hardware yet. A month later long after thinking about the grid paper and math, you find out the code doesn't work that great and then you are finding out it needs a ton of band aids, the code the other guy wrote was sloppy and meanwhile the scroller guys decided to skip your frames once in a while. Meanwhile, another month later, a QA team plays it, says "it's not that great... " and the boss says "but is it playable?" and the QA team says "well kinda". And then 3 months later, it's on the shelves ready for Christmas.
@@djrmarketing598 beta testing was very common. But even if they didn't have beta testing, this is a weird and uncommon way to do physics logic. That's what makes it so buggy and so interesting
@@djrmarketing598 Right? You didnt exactly have Game Maker Studio 2 to test this in at the time.
I had to spend literally THOUSANDS of hours playing NES Strider, even though I'd avoided it for decades. I felt it was my duty to make sure I encompassed everything "Strider" that I could, when I made the Strider 2014 game, not just what I've loved about Strider since 1989. Oh so very painful...
So you're THAT Tony Barnes. Well, those efforts paid off pretty well!
Would that have included Tiertex's Strider II/Returns? Good lord.
Your game is a pretty mediocre metroidvania with cheap design ngl
That first 50 seconds plays out like baby's first Gamemaker platformer. Certainly looked a hell of a lot like mine.
I can't wait for the eventual nine hour long Strider omnibus episode!
See you in 2045.
I would happily watch all 9 hours@@DisplacedGamers
@@DisplacedGamersMore like 2048 in Kazakhstan, right?
Despite NES games being somewhat of a niche, this is honestly more valuable than most game development tutorials and "essays" I've found. It's not about the code per say, as in, what I should type. It's more about the problem I'm trying to solve. The way you structure your videos gives me better ideas about how I should try to think about specific problems, and the logic required to make the code blocks I write work with each other, instead of just trying to find the right "Fix", the right math formula, whatever.
I can't say I understand everything, but you often put me on the right path, and that's all I can ask for.
Honestly what I love about channels like Displaced Gamers and RGME, they focus less on what the code says exactly and more on the logic of the CPU and likely what the developers were thinking when designing things. It makes it very helpful to actually learn and understand these things. Very useful, even if you aren't familiar with 6502, or even retro games in general.
I LOVED this game as a kid, but I absolutely HATED the physics. It was so bad, that I put it away for years until I was a teenager and gave it another shot. I beat it and loved it, to a point. The physics made it where I couldn't recommend it to anyone. Thanks for explaining the issues.
Right there with you. I was too young to really have the words to describe what I didn't like, but this is pretty much it.
same. i loved the visuals, sound, story, setting, etc. but it just felt like such garbage gameplay. and now i know why.
There were so many games like that for me. I've always been bad at video games, which is at least partly why I like RPG's more than platformers, less frustration.
@@anon_y_mousse well, in the case of strider, it definitely wasn't just your fault. the game is legitimately programmed terribly haha.
Yep, same for me. As broken as this game is, it's a miracle that it can be beaten. But, it's actually pretty fun and satisfying to beat!
This one was a blast. What do you think of holding down A for the Triangle Jump? Should I have gone for something else? There are so many other issues to address in Strider.
Speaking of things to address in Strider - I think I will upload some of my Strider work to the Displaced Gamers GitHub (by the way... Displaced Gamers "is on GitHub"). This project took a lot more reversing than usual. Perhaps someone can take the work and run with it. github.com/DisplacedGamers
Hope everyone has a great day!
Seems like a relatively sane solution to the problem and an elegant fix that you can do it in a single GG code.
As far as overall "feel" of wall jumping, I think nothing has beaten the Mega Man X series for me, so I would consider it an improvement if your fall speed actually reduced down when in contact with a wall instead of sped up, but I also think Super Metroid feels awful when a lot of people tell me they have no problems with it, so maybe it's a "me" problem.
@@WillowEpp Super Metroid's wall jump is tricky, but the game helps you a little with a unique frame of animation to let you know the window to press the jump button. If you're spin jumping along a wall, then press away from the wall, there is a window of about 2 frames where Samus' sprite switches to one where here feet look planted on the wall. That's when you hit jump.
@@GeekSHO Oh, I know exactly *HOW* it works. I _can_ *do* it. I just hate how it feels. It _feels awful_ to me. This is a subjective thing.
(I still think that if there were more than three months between the release Rockman X and Super Metroid there's a good chance it would have turned out differently, but we'll never know for sure. ㄟ( ▔, ▔ )ㄏ )
This is basically coder church. PREACH IT BROTHER AMEN!
I agree that the solution is better and a good patch but it's too easy and some timing constraint should make it more fun.
Heh, so the Nintendo Power tip for triangle jump is basically to button mash and hope for the best. Really was a poor implementation of wall-jumping. I still love that way Batman does it. That lil stop as his sprite animates to change direction is strangely satisfying :O
“I have an untested solution that will probably break 5 other things…. Let’s try it!”. I haven’t laughed that hard in a while. 😂
Followed up by "ehh, that's enough." haha Which is absolutely what they said when they shipped this game.
You know it’s going to be a good day when you see a new behind the code in your feed.
Amen! :)
Absolutely. Deepest and most thoughtful analysis on the entire site.
My god this game is a gold mine of bad freaking code decisions.
As seen in the comments sections of the first video, NES Strider seems to have been initially programmed by someone with no (or very little) previous experience with the system and then a more experienced programmer at Capcom (who was responsible for that game) had to jury-rig fixes just to get a "sellable" product out the door in a relatively tight time frame.
even 30+ years later the NES ninja gaiden sprites are so lovely. Even if it's just a screenshot/photo. I was chuckling when it switched over to strider and that pill pickup was all shakey
I’d love to see a series where you take what’s been learned from these videos and slowly build up the most optimal/feature rich nes side scroller possible. (Though that would be a monolithic project)
That would be a crazy project, indeed. That said, perhaps these videos are a good resource for any other developer to do that very thing. I'll keep making more of them.
@@DisplacedGamers I'm listening.
You're honestly the best at this particular niche, and it's a huge window for many people my age to get into programming with content we can relate to that isn't at the "Hello world" level of baby steps. The understanding and presentation is simply unmatched.
This is a delightful look into a game so hilariously broken it's a miracle it runs at all. Please, cover this aberration as much as you'd like; it's absolutely fascinating to watch you go through this code - it's less 'sphagetti' and more like a pile of hashbrowns.
MY MAN! I had a sneaking feeling you'd be the one to crack this. Very impressive work! I remember renting this a couple times as a kid, without the manual, and not knowing what to do when that first required jump came up in the Egypt map. It always felt off, because everything else for those first ten minutes was so easy.
I always find these videos so well laid out and easy to follow.
Thanks for another deep dive on this broken mess of a game! This has been a fun mini-series so far, and I suspect I'm not alone in saying that I would love to see a part 3 with some further analysis on the bugs you didn't get to in this video.
I wouldn't mind making a third part at some point, but I need to get this game out of my dreams. lol
@@DisplacedGamers Haha, fair enough.
Oh you're definitely not alone in wanting to see more of the code that produces this busted aberration. That said, I can totally understand if DisplacedGamers needs a break from it. There's plenty of other wonk games out there, after all.
I kind of like how strider gets so much mileage as examples on what not to do
Seems like a case study.
This series on Strider is pioneering a new genre among programming/tech youtube : code gore. Will we examine code behind Action 52 next? :P
@@stephen-ngFuck, you're right. I even watched the Action 52 video and I just forgot about it :P
There's code behind Action 52?
@@ShinoSarnaApparently it was so traumatic that your brain made you forget it, lol.
I can't imagine how many Game Genie codes it would take to make any of those games playable.
He will never do another video if you make him analyze Action52
Early day programming was so obtuse compared to what we can do now. It's still really fascinating to see the weird ways early game code tried to solve problems. Videos like this make me wonder how much different older games would be with a "code update" I know that there are plenty of examples in the ROM hacking community but it's still fun to think about.
lol @ 4:36 "It gets better (as in worse)". Great video as always
Man I love your videos. Absolutely fascinating!
Loved this game as a youth despite the wonky physics. I was excited to see that you were going to tackle this one, excellent video.
The music is the game is insanely good
Wow. Just crazy. First, the amount of work you went through to set up all that testing and output just to figure out just what in the world is going on with the game lol Second, I'm experiencing that weird feeling of remembering how the jumping felt and now having the understanding of the code's logic present the connection between the experience and the problematic code. Sort of like that innate feeling you eventually gain in physics class when understand what it feels like for falling objects and centripetal force and then applying it to say being on the moon and almost being able to envision-experience the feeling of what it would feel like. I always chalked up the triangle-jump jankyness to the frame rates of the game and me needing to be slower because the game just couldn't keep up with the input. Now I see (and can almost feel) the effects of the routines in place causing that sense I had so many years ago, and now understanding just how affected the jumping was, not because of the performance, but because of the code design.
On a similar note of performance. There's a little known-game that might be worthwhile looking at is Bio Force Ape. Back in the NES vs Sega days, there was that whole rivalry that was taking place and the blast processing marketing that Sega kept marketing to compete against NES' slower performance. They used Sonic's speed as their main marketing tactic. However, Bio Force Ape which was never released but someone discovered a playable copy in 2001 (I think it was 2011), and it's speed is, what looks like to me anyhow, right on par with Sonic. It might be interesting to see a breakdown of the tricks they used to achieve the speed increase. My guess is a lower sprite count, but that's probably way oversimplifying it since they probably did tons of other things too.
This is the kind of janky collision physics code i wrote when i first dabbled in gamemaker
edit: OH NO IT'S WORSE
lol
I actually took the time to finish the game despite the awful experience of movement and every sprite interaction feeling glitchy. I had recorded the last stage on a VHS tape of games I had completed, so I got to watch it again over the years. This video doesn't even get into the difficulty of jumping effectively off of slopes which are prevalent in the game and usually interacted with while scrolling is happening. I had to figure out the wall jumping without knowing any of this too. I would just try and try again when physics broke and I definitely remember making sure to stop the screen scrolling before difficult jumps despite not knowing why this helped. Thanks for making all those hours of frustration finally feel like it wasn't my failure to learn... it helps to know that I was actually learning to subconsciously manage a handful of horrible bugs and somehow still be able to beat it without having to restart my VCR recording too many times to make it possible.
All this “simplifies” information is way over my head, but I LOVE IT! I just need to consume it until it makes sense to me 😂. Great video! Thank you!
Thank you for making this video. Its one of the few i completely understood, regardless of my lack of programming knowledge. I played the game enough as a kid (and still remember) to get exactly what you were referring to via the code... and just how stupid it all is in regards to Capcom making things overly complicated, plus being absolutely sloppy as hell!
would be really cool if you wrote a patch for the game to fix all these issues to make Strider actually worth playing AND worthy of Capcoms name down the road. Im sure a lot of us would be elated to play a PROPERLY FUNCTIONING version of this game versus one that (as you put) tied its shoe laces together and face planted! LOL! Btw, excellent use of Out of This World as a visual reference (I got a damn good laugh out of that).
"It gets better, as in worse" is a pretty good way to describe this games coding.
Highly doubt its the worst offender of bad NES code but its probably the worst on a game that was actually somewhat known. I never had Strider as a kid but i knew it was another NES game my friends liked.
New Displaced Gamers video! Great way to start the Weekend!
I can't believe I, not only beat this game, but moderately enjoyed it
1:18 “Implemenation” 😅 Great video though, thanks for all the hard work on these.
This is a fun reminder for the GDQ "Learn to Speedrun Strider" segment from a few years ago.
IIRC they literally had someone new to the game come up and do a run beat it in minutes because of how completely borked it is.
Hope to see you going over moonwalking through walls as well as the others.
Thanks for covering strider! One of the few games we had as a kid and most people have never heard of it. Those wall jumps were sooo tough, I'd run out of time for the level trying to do them
The og Arcade game is well known, not so much the nes port though
Amazing after all these years to finally get an explanation of what was actually going on!
This is super cool. I always thought the wall jump felt off when I was a kid, but didn't have an issue executing it.
(18:26) This part gave me a chuckle. It'll be quite interesting when you finally cover those wacky oddities.
I don't know if this channel has merch, but a "Better grab a TACO!" shirt should be on it.
A solution that comes to mind to fix the triangle jump logic: only require the button press, not the direction change. The player will still naturally hold the wanted direction to reach the opposite wall. To prevent abuse, we could also ensure that you can't jump more than once in a row from the same wall (by comparing the x position of the wall jump with the previous one?)
With physics this overcomplicated I'm not surprised that Strider has the rendering issues mentioned in the last video
Back in the day we just learned how to do it. It wasn't easy but I beat the game. I can attest that the technique did not stay in "muscle memory" as I tried playing it again and could not pull off the triangle jump with any sort of consistency.
It really looks like they were learning as they went along and just added band-aid fixes as they encountered things. Reminds me of my first try writing a pac-man clone.
As neat as this is to see laid out I never had a problem with the game as it was
"Holding A and just using the controller to wall jump" is basically what I did as a kid...with the A button on turbo. I wonder how they handled it in testing. I mean, someone had to have at least played through the stages, right?
Sounds like Stryder is a solid candidate for a ground-up remake, not just a graphical overhaul or port.
Awesome. Thanks for continuing to look into Strider. I mentioned in previous comments as well, but definitely have a look at the leaked Japanese unreleased ROM sometime too, it's broken, but in different ways. Now having seen some of the weird choices you found in this video (+1.5, wtf) I'd guess the JP ROM might be a build before it got given to someone who didn't know the code to "polish" before dumping it out to the US market.
I've always loved your voice - it's like Phil Hartman giving a computer science lecture
Would love to see another deep dive and a way to patch the game to fix these ! Thanks for this video. Learning lots :)
I've started writing my own emulator, although for the PS2 and not NES, but I'm definitely going to incorporate a debugger into it because of your video series. The more I see of this series, the more I wish every emulator had a debugger built in. I know it sounds silly, but I'm also going to write a PS1 emulator at the same time because if it does PS2 games it should also handle PS1, since the original hardware could, and I don't accept the later revisions that removed those chips as valid for the purpose of writing my emulator.
That's awesome! Good luck with your work. I feel the same about debuggers in emulators. I also wish they were all as good as Mesen's.
Mesen is just amazing in that regard @@DisplacedGamers
I think all revisions of the PS2 can play PS1 games.
@@CptJistuce If they could then it was with emulation, because they removed the PS1 chips in later revisions.
@@anon_y_mousse really think you're thinking of the PS3's loss of PS2 compatibility, as most of the PS1 hardware in the PS2 was a pare of the IO Processor and integral to operation in PS2 mode. That's where the R3000 lived, as well as the DMA controller, sound processor, controller and memory card port handlers...
I'd be curious to see the difference in coding of Strider NES to other games that had decent wall jumping, like Batman NES.
Always fun to find out my poor gaming skills are only half of why this game was so hard 30 years ago. ...sill love it though :P
This is FASCINATING. I've always loved this game, warts and all, and think it'd be a prime candidate for something like a Blaster Master Zero-style remake. I take some pride in having gotten pretty good at this game's finicky triangle jump, and although it's a happy accident at best, conceptually I like the idea of it being a very hard technique to pull off. I mean, it would be!
Incidentally, I never took to the arcade/Genesis Strider, despite trying to get into it roughly once a year.
This was an exercise in frustration. No idea how i beat this as a kid.
@11:27 was that.. was that a _walking taco_ reference?
Man, I could go for one of those right now. Oh great video as usual btw
It wasn't, however now I am also hungry.
Whoa.Somebody actually explained the games"springy" jumping. The game felt a little glitchy with the scrolling and graphic tiles. Still,cool game and it's different that the other Strider games.
This informative video just made me even more impressed with 13-year-old me for having finished this game, bugs and all.
You know, watching these videos about Strider, I really don’t know how my friend and I beat it as kids. I know we beat it because I remember the story and everything. But holy crap that triangle jump must’ve given us fits!
Thankfully, I did have a subscription to Nintendo Power and I did have that issue.
Cool video I’ve learned so much watching these videos.
There is no defense for this game, but I still love it dearly. It's like a comfy blanket... except it's really ratty and falling apart.
You should turn these fixes into an IPS patch that people could apply to their games.
That code is an absolute mess. The fact that the game is functional at all is amazing. I know with the triangle jumps the easiest way to get consistency with it was to hesitate about a half a second when trying them. The presses indeed needed to be precise.
"Welcome to the table of two sub-routines..." You done fricked us on this one!
I remember when I first played Strider on the NES, I was seriously considering taking it back to the store, because I was *sure* it was a defective copy. That's how bad the physics are in this game, and it's nice to see some explanation, even if the explanation itself is baffling - why would Capcom do this instead of just using a normal jump physics routine? Was it all to (badly) implement wall jumping?
... also, I was amused that Strider bounces off walls the same way as the square in Adventure, for what I suspect is the exact same reason (specifically, that it has wall ejection without wall collision). Even later Atari 2600 games like Haunted House don't do that.
It seems like a completely inept programmer did the work for some reason. Maybe it was an intern
@@MaxOakland The game's credits highly suggest that the initial programmer was indeed very inexperienced with NES development and that a more senior programmer had to jury-rig "fixes" to get the game to a "sellable" state.
Haha all the problem described are the pretty similar to the ones I'm having trying to implement jump/collisions in GM, thanks for the detailed analysis on this and the Ninja Gaiden games. Its a great guide platforming designing.
Excellently done, as always.
I absolutely love these Strider videos.
My childhood game and I'm so glad to see I'm not the problem the game is 😆. So happy to see you explain and fix the game. Looking forward to seeing more😄😄
Now, I'm not some incredible programming genius, but even I hear "jump frame lookup table" and find myself lost for words.
As a kid, i had no idea Stixer had all these problems. Despite that, i still managed to finish it. I still remember my save file code from over 30 years ago. I played the hell out of that game.😅
30 years later... There's wall-jumping in this game, and I now know why I never beat it...
When I watch these videos, I wish I could play the game with these fixes. It would be cool if I could go someplace or someone had these rooms fixed
You can! He provides Game Genie codes for most of the fixes, and the ones that he doesn't, he usually shows where in memory he's making changes. You could either hex edit a ROM or use Mesen (or another emulator that allows on-the-fly memory edits) to apply his patches.
10:28 STILL WANT THE CODE! Just requesting again... I probabily will never be able to, but I LOVE your vids, just keep on Keepin' ON!
Oh good greif man, My apologies. This is the one thing that's always kept me from completing Stryder and was a bit inebriated when asking. You gave it, thank you. This is the best surprise game genie code from your videos ever!
I love this game, rad themes, rad graphics, rad music, rad ideas, but JESUSCHRIST.... *THE JANK.* The game is now much funnier to me knowing all of this weird logic is going on while we play it, it's one of those games so broken it would need to be entirely re-coded in order to work properly
PS: I'd love if you did a video comparing Menace Beach with Sunday Funday. They're unlicensed games, originally by Color Dreams, then modified by Wisdom Tree. They're essentially the exact same game with a few graphical differences, but Sunday Funday runs much smoother and detects inputs quickier, I'd love to know why (and see if that can be done for other Color Dreams/Wisdom Tree games that use the same engine)
Played it, loved it, beat it, and never had a problem with the triangle jump
You could make two years worth of videos about Strider's code.
Nintendo: "Do the physics in your game work?"
Devs: "......We have physics, yes."
The more I watch this the more I get the feeling that the devs had some severe cases of "I forgor" when developing this
amazing video right here. i don't know the development story behind this game but i imagine it must've been, uh, stressful. at the very least. makes me realize that for how much video games have progressed, devs have always been rushed to hell and back and buggy shit has always been tolerated somewhat so long as a game releases lol
would you someday be interested in taking a look at just wtf is happening in the game Super Pitfall? from what i've seen it's a really buggy mess and i don't think anyone's actually done a deep dive into it. though tbf the nes does have a lot of buggy games in its library, so i'm not really surprised lol
I like that the end of this video seems to be you realizing that this is not a productive use of your time or expertise
this is gold. pure gold. my sides legit hurt at how busted this game is, lol.
Lookup tables does reduce the CPU load, which was probably the solution they picked to keep the game running as fast as possible.
But yea 😅 if you mess up the value’s it’s probably worse than slowdown
"Some physics are bypassed when scrolling" sounds like a cool gimmick for a platformer that actually knows what it's doing.
Hearing the short version of doing the Triangle Jump: "Oh, so it's like Super Metroid?"
Hearing how broken it is: "Wow, that's... not a good implementation"
I simply love you and your explinations.................. Kudos!
You ARE the MAN! With the master PLAN!
There has to be a "Strider if the game code was fixed" version floating around by now. It must feel great to play.
11:13 & 15:51 This is not a good suggestion to do the Triangle Jump because this is also what I did initially by myself without relying on any guide or advice as a kid playing the game in 1992.
Wildly rocking left & right while jumping only brings frustration and finger injury.
The method that works for me is :
There is no need to hold down the jump button. Tapping jump or holding jump will give the same jumping height results.
Do not walk against the wall before jumping, your jumping height will cut short to about 1/3 making it impossible.
Do not rock the direction left & right multiple times wildly within 1 second, the actual timing is changing the directions calmly around each second. Doing it too fast will make you fail.
So watch from 11:36 - 12:01 carefully to understand the steps below.
Do not be afraid of dropping down a few pixels; it is important, more reliable and comfortable to do the triangle jump this way.
Start by walking towards the wall and tap jump.
Let the character touch the wall, then stall and start dropping down a few pixels.
Then only press the opposite direction, and then tap jump within half or quarter seconds to make a successful jump. (You can attempt to press the opposite direction & jump at the same time, but you will fail if the jump button is pressed first instead before the opposite direction button is pressed)
Repeat the touch wall, stalling, dropping down a few pixels, then changing directions, tap jump within quarter second of direction change.
Using a turbo jump will help doing this easier as it will help you concentrate on the touching wall, stalling, dropping down a few pixels, then changing directions.
I have reconfirmed my methods above just a few minutes ago on my NES.
Having recently played through Strider NES myself last week as part of a full series playthrough, I can confirm that (at least for me) this method was more reliable than the few times I tried to rock the d-pad around. Triangle Jumping still wasn't _great,_ but I was able to get through the game without ever using the Jump Trick for platforming.
Other versions of strider (16bit) seemed kind of buggy to me as well. As a kid, I didn't know exactly what it was that made it look "cheap" overall (aside from obvious stuff like being able to jump through walls etc..), but videos like this one give me a glimpse into what might have been going on there from a code perspective.
What a huge mess of code, and here I was feeling like my own code from yesterday's experiment I had uploaded on RUclips earlier was completely busted.
Maybe I didn't do that bad after all considering it's actually working exactly as intended, lmao
Oh God ... those wall jumps! Bane of my childhood! Whenever I got to one of them, I had to have my stepdad do them for me because I just could not get the hang of them, I always thought I was just bad at the game but now it's a small comfort to know it wasn't me at all...
The fact people can reach the end of the game is frankly a miracle when the spaghetti is mixed in with spider webbing, silly string, cheese string, shoe string, and worms.
if i'm not mistaken, super metroid actually uses a very similar wall jump mechanic. you have to make contact with a wall and then rock the d-pad the opposite direction about one frame before you hit the jump button again or it doesn't appear to work
i don't know if you take suggestions mr displaced but i'd love to see a deep dive on ghosts n goblins for the NES, things like why the game sometimes swallows your inputs, the crazy amount of slowdown and sprite flickering to rival mega man 3, and maybe the unforgiving game design like arthur having the belmont jump
Can we take a moment to appreciate the teleporting leg brace at around 3:45?