I read recently somewhere that Quickman's AI was designed with a flat floor in mind, so the devs raised the floor of Quickman's room like that to deliberately trigger the AI mistakes and make him a little easier than he otherwise would have been. And then, later, you fight him on a flat floor during the rematch to make him harder. I wish I could find where I read that again. (I'll post again if I can find it) :D
That's weird because, while the raised floor does give you some opportunities to take advantage of his AI, it also makes it much harder to jump *over* him when he charges at you. On flat ground, jumping over him is pretty easy.
@@JamieVegas While this is a theory I thought of in a few minutes, I think it's plausible. Mega Man 2 was developed in the free time of the team between other projects. So, because of that it had some time crunch. Which means some of the rough edges of the game weren't ironed out in time for the release. I think Quick Man's A.I. bugging out on the raised floor is a part of that.
First the flat floor applies to all the remaches with some things like metal man’s conveyer being removed and flash man not having ice physics. The second thing is that Quick Man is actually much harder to fight on the original arena than the flat floor. I have done buster only and no damage runs on almost every robot master in every game and I for a fact know it took me longer to do a perfect run on quick man on the original elevated room than the flat floor. Also the bugs make him even harder as sometimes he will just run over the gaps while sometimes he will get stuck and the player doesn’t know which of the sequences will happen.
Quick was always my favorite robot master. It's fun that the running into walls was made a canon part of his character. The lore says that he moves so fast that got his visual processing lags behind his actual movement
@@tjcihlar1 sane, after playing the japanese version of Mega Man the Wily Wars ( Rockman Mega World ), which is the best version to play ( the PAL version is slowed down ), I sufferend against this guy. Each shot dealt 1 damage, each shot = 1 damage. It's basically impossible to kill that guy so I used 2 of his weaknesses.
It's so interesting how clumsy AI coding results in a slight difficulty increase during the endgame rematch! Kinda reminds me of how Space Invaders' gradually increasing speed is really just slowdown decreasing as the player reduces the number of sprites the game has to keep track of.
Yeah, it's one of those cases where you have to wonder if the bugs were deliberately left in. It seems like the "buggy" version of the fight is more dynamic and interesting than a "fixed" version. He's easier to hit if he gets stuck, but you can never predict when you'll get a clear shot. It's a bit of accidental randomness that works in the fight's favor.
SNES ASM hacker here. We love your videos man, you do a great job showing the technical details but quickly summarizing it in an easily digestible way with great visual aids. Of course it helps that Mega Man is one of my favorite NES games. Great work :)
I wonder if this might have been a known bug that was left in on purpose? Quick Man in his "broken" state is already arguably the hardest of the 8 robot masters in Mega Man 2, so the additional "downtime" to get a few hits in now and then as well as what is effectively a randomization of his jump count could have been seen as being better than the intended behavior, and was intentionally left in. Sometimes "good enough" is better than a polished product lol
Wouldn't the nullification of the first jump make the second jump's boomerangs harder to combat simply by making them less predictable? There are times when speed is less of a threat than unpredictability.
@@MasterKnightDH Possibly! But two things with that: First, I don't know the exact stats for that fight specifically, but GENERALLY speaking their weapon is a robot master's weakest attack. Conversely, worst thing you can usually do when fighting a boss is hug him. This is one of the primary reasons why Quick Man and Heat Man (and, to a lesser extent, Air Man) tend to be the most troublesome fights, and Bubble Man and Flash Man tend to be easier. It's really easy to stay away from the latter, and really hard with the former. To put it another way: Quick Man's most lethal attack is touching you, and I'll take making it easier to avoid that than boomerangs any day of the week. The second thing is that, with Quick Man specifically, the hardest part isn't even avoiding damage from boomerangs OR him. It's landing return fire. Any battle with Quick Man is going to fundamentally be a war of attrition, and I feel like anything that makes it easier to hurt him consistently is a hard nerf to the fight.
I wouldn't say quick is the hardest it just impossible not to get hit due to his random AI cause the buster does a lot of damage even on difficult. just come to the battle with full health and with luck you will easily win.
I read that Megaman 2 was made under an extremely tight schedule and they only had time to test if the code worked, but didn’t have time to refine it or make sure it worked *well* That explains a lot about this
Definitely an interesting breakdown on AI, especially in a capcom game. Its interesting to see how something as arbitrary as his failed ejection code changes the fight drastically when its fixed. Not sure when you would even get a chance to shoot him! Better get flashman's weapon and pray
"Fixed" Quick Man would probably be considered easier by the hardcore players because he would be far more predictable. Vanilla Quick Man can jump randomly and shoot randomly depending on whether or not he gets stuck in the wall. "Fixed" Quick Man does not shoot randomly, you will always be able to tell when he will shoot, making it much easier to dodge
@@wandwoodgames5699 who is or was RoahmMythril? Feel free to reply with as many game tropes and lines as you please. EDIT: AAAAND I see the original line now...lol
15:39 "The vertical check sees that his top right side is stuck in what it assumes is the ceiling." See, I wasn't entirely sure I was following what was going on until you said this, and then it all clicked into place with a horrified, "Oh no. Oh no no no no".
@@welovethesnorks My amigo. One does not teach game dev by dissecting a video game, showing you the assembly code, and then how to modify said values using Game Genie codes. The video isn't teaching you how to remake or create Megaman 2 in Unity. They are literally reverse engineering the game code, to find what is wrong, and then fixing it. This has far more to do with computer science than it does game dev. Go ask a game dev the last time the debugged assembly code, or didn't use a premade engine and didn't use a high level programming language. Maybe you don't see the parallels between this and computer science, so only believe it to be "game dev"?
@@jessedaniels2230 my friend there is a lot to address in your comment, a lot of assumptions that make you look silly. There are new NES games made all of the time, assembly code is still code and everything mentioned in all of these videos are used in game dev. I'm not sure where you are getting "unity" from, but that is amateur shit. You sound like a person that doesn't, and cannot, make games - so please stop trying to lecture me about this video that is literally about game development at the core. What are you using the code for? Websites? Is that your CS degree? No? See how assuming works?
You know the Quick Man flicker would have made so much more sense if it was actually on purpose to give the illusion he moves so fast he blurs. I was surprised to learn this was a bug all along! I think this could totally work out, have a simple counter where 1 pixel is added every other frame in either direction, AFTER the velocity logic. That would look pretty convincing for running/jumping in a direction at the speed of, well, QUICK, lol
I wonder how much work would be needed to fix the Quick Man's entire behaviour, that would be a pretty cool ROMhack project... it's funny how much the explanations make a lot of sense, and make me wonder "did they even test their stuff?" lol
I love these breakdowns. As a kid I used to just try and rush most mega man bosses. One AI break down that would be interesting to learn about is the one in Final Fantasy tactics. There have been a few times I've seen it be clever, and more times where they were dumb (mostly ally AI)
I read a piece on the corelation to code in ff5 being relatable to FFT code. Through it I was able to revise my own play strategies in ff5 and got me thinking of how FFT could be fixed to work better. There are many flaws and untold features that need light shed on them in both games frankly.
I did an AI FFT battle with description text th-cam.com/video/Zwuu99twlNw/w-d-xo.html You need good setup like tailwind (defender) and geomancer as well as use berserker for who attacks. No idea how to set up turn 1 golem. Shame setup is probably needed, let alone Agrias is only good as another class as holy knight has low attack. Did a ton of exploits with that game too. Though a technical info like this I couldn’t do.
@@MrVariant geomancy was my go-to backup skill after the samurai blade skills. Hell Ivy alone ended up clutch too many times with its excellent Stop chance. There are some interesting combinations that work in that game, so much so I opt for those combos instead of really using much of what is available.
@@residentgrey oh sure glad I could help. The power garb helps Agrias there as well though surprisingly she makes a better monk with equip sword for higher physical attack and holy sword. Lol the game makes no sense. I know a speed run where rpg limit break abused the time mage's quick for draw out when not doing the obvious with math skill and farmed jp fast by the Friendly Fire Tactics moniker (I'd throw stone or tailwind myself). I owned midlight deep on chocobo with Ramza as an onion knight with glacier gun on chocobo, and Reis' holy breath is rapha on steroids, doing about 400 damage per random hit. Final boss I had a vid didn't even get a final turn without Orlandu and reacts by buffing faith lol. th-cam.com/video/WVrKIGX0Gr4/w-d-xo.html
I always thought that Quick Man running into walls was a statement on Wily's recurring "good enough" methodology for designing his robot masters. He made Quick Man run fast, but his processors can't quite keep up with his feet. Kind of like how some species of bug are so small and so fast that they need to stop mid-run because their eyes don't catch enough light.
I guess that explains why his Battle Network counterpart does the same thing. Quickman.EXE blocks all attacks when he's stationary and can only be damaged while he's jumping or throwing boomerangs.
There's an in-universe explanation for bosses in MegaMan games to have bugged code. Dr. Light designed the processing hardware and AI code of the original robot masters while Dr. Wiley took lead on the power core and body design. Quick Man having flawed code for handling collisions is just... funny.
This is such a cool channel. Every time I watch something from you, I learn a little more about code, despite being a coder at a few jobs. It's so interesting to see under the hood of my childhood games.
I'm willing to bet those glitches were left in to make Quick Man more manageable to defeat. Notably too, his AI was written with a flat arena in mind but they added those bumps to make him easier, no doubt knowing he'd get hung up on them as well to provide more opportunities to hit him (which is why the Wily Stage rematch is so much harder: you fight him in a flat arena that time).
When I first started trying to program games I made exactly the same kinds of mistakes. If that puts me on par with Capcom's NES-era team, I'll consider myself in good company!
Remember that this game was coded quickly, early in gaming's history and during the team's spare-time. So I'm thinking this is a combination of bugs and getting the boss done as swiftly as his character. Not a good combo for being careful with the order of operation.
Quite plausible. It could even be that the developers were aware of some of the flaws but only had time and resources to devote to more important development issues; such situations seem not uncommon in the industry.
@@TravisTev That's my thoughts, in particular here. The bottom line is they had a bum-wrap (Poor Conditions) with which to make a classic game. They succeeded, but at the cost of missing some fine details and cleanup. If you want MM2 refined, look for the "Megamix" patch for the game online. It smooths out A LOT of what the team missed without altering the game too radically. Even give you the option of applying fixes as one sees fit.
i remember hearing that Quikman's difficulty was more due to the broken code than design, and supposedly the designers knew the code was broken but because of the difficulty spike and lack of any game-breaking issues they left it alone. Hear-say of course. But hearing this...i dunno how truthful that is anymore. If hes constnatly in the air surely thats harder than what we got
Thanks for leaving this comment, vineheart01. I have heard this line of reasoning for many of the bugs found in various games - another example being the pendant bug in Faxanadu. The game thinks you have the pendant at the start of the game and then takes away the power if you pick it up. Some have claimed the developers did it as a lazy fix for the difficulty, but this line of thought doesn't make sense to me. Unless the developers for Game X specifically state that they knew something was broken and they left it that way due to time constraints OR that yes, they did make a "dumb tweak" to adjust game difficulty, I am going to assume things like Quick Man getting stuck in a wall or inverse pendant logic in Faxanadu are simply bugs rather than a poor programmer's design tweak for difficulty. To specifically answer the Quick Man issue - If I were the programmer and was allowed the time to fix the bug, I would have: 1: Fixed the wall ejection logic vs velocity application order and also corrected the off by one bug. 2: Probably have noticed the change in difficulty and suggested to the project lead/designer that we increase the frame count for Quick Man's running phase - literally change one value. Heck - I may have even made the tweak without asking depending on my working relationship with other people on the dev team.
@@DisplacedGamers My issue is that, unlike the off-by-one errors, this seems a weird bug to have show up. Why would you run these in the wrong order in the first place?
@@ZipplyZane Probably just early development woes, theres a TON of decision or shortfalls in the old games that nobody would even consider an issue these days, they'd just casually fix it and move on.
@@ZipplyZane I think it's easier to see these logic errors when you're looking at a finished code base. But remember, the specific routines that we're seeing now may have appeared (been programmed) in ANY order, and the code within changed in minor or major ways, at any time. Who knows what state it was in, when a given bug was introduced, and then how it changed afterward.
@@ZipplyZane One thing to keep in mind: Capcom only let the team work on the game in their spare time AND still expected them to have it complete within a certain time frame. The fact they had to deal with these constraints, ended up releasing it somewhat incomplete and with flaws, and yet it is still considered one of the best games of all time is nothing short of incredible.
This is fascinating, I'm both amazed and grateful for this bug as it makes the battle more unpredictable and at the same time it makes it a little easier.
I don't know if it's the most important part of the video, but I enjoy seeing you look for the simplest solution to a problem. It would be easy to go, "Okay, we'll rewrite it but good this time." Easy, in quotations of course, but asking, "What is the simplest change we could make that would solve the issue, or even just have the largest impact?" is a great skill. Watching you demonstrate how to break down code, analyze it, and then look for improvements has probably helped a lot of people become better programmers.
Thank you! Attempting to use a Game Genie for a fix helps restrict me to changing just a few bytes - although I break the rules and create a new subroutine on occasion.
it would have been better to have had a flat and low floor with platforms above in that boss stage too. I can also see some other movement logic that could scan better now. This brings forth many other options for a fix or enhancements.
I agree. The room layout for Quick Man doesn't really seem like a good design for his a.i. - broken or not. Yet! It is possible that the room layout was designed in that way to help curb the difficulty for the player. Him running inside a "channel" in the floor will cage him momentarily.
I just found your channel and these videos are an absolute blast to watch. I've been getting into gamedev myself and these videos really show off a lot of particular tricks and solutions to problems that i find genuinely invaluable. As interesting as these videos are on a surface level to me (I love tech and programming) they're absolutely amazing reference material. The quality in the editing and explanations are top notch
It's fascinating to me that these games don't use a common 'eject from wall/floor' routine for everything, Especially since the robot masters and Megaman are all the same size and do running/jumping physics.
The main point of those video: Quick Man is so quick that he outruns the game's logic. I'm not that good at coding, let alone assembly coding, but I like to watch these videos just to have a glimpse on how my favorite games work.
I think you are missing a few key points regarding uneven hit detection boundaries, logical order of operations for collision resolution specific to Quick Man, as well as redundant conditionals & subroutines... but yes, Quick Man is quick.
This is great! With the patch, Quickman became way more nimble, but at the same time way more predicable. I think that balances it. Some boss batles in the Megaman series feel like you gotta get lucky (ie Shadowman) and this was one of them, but now it's clear something really wasn't working correctly
That "ejection" being in the wrong place made me remember something similar that happens in Rockman/Megaman 4 when you beat a boss. There's an animation where Rockman/Megaman runs to the middle of the screen, jumps and stays floating in mid-air to "absorbe" the new power. But what happens if Rockman/Megaman is already standing in the middle of the screen? Well, the animation skips the jump and suddenly "teleports" Rockman/Megaman to mid-air. I haven't looked at the code, but probably there's some kind of routine that goes something like "check distance to center of the screen > run to center > jump", then call the "absorbe" routine; but if you're already there at the center, it skips the routine completely and goes directly to "absorbe power" in mid-air, skipping the jumping part. I remember when I was a kid having fun trying to position megaman exactly in the middle to trigger this after every boss fight. Want to investigate it?
That seems like a case of incorrect branching instead. "If this is the case, then jump to that other place in the code", except they put said point one action too late.
Fantastic video as always! Peanut gallery incoming: 0:53 I see that DEX at 879E--is that necessary? Could they have increased the subsequent addresses by 1? 2:08 But in a TAS, hoo boy. RNG manipulation so easy it'll spoil you for life. 5:00 Floating point? _What?_ That's amazing! 18:05 FCEUX has a cool feature called the Code Data Logger that can tell you, for every byte, whether it's been used as code, data, or neither. There's a rare glitch where Quick Man will do his blocking stance when hit with a weapon that should damage him. No idea how it works.
"Floating point? What? That's amazing!" It's not *really* floating-point. It's fractional fixed point; treating certain low bits as fractional. The math works out the same; it's all in interpreting what it means.
Hmm. I wonder what is going on with the blocking logic when MM is using a valid weapon. Sorry about the use of "floating point." I just used it as a term that many other programmers would recognize and would help me complete a sentence and keep rolling. Showing the fractions as decimals in the slides was another way to just make it easier to read. It is still just an unsigned number from 0 to 255 behind the scenes.
2:46 Had there been four choices for quick man to jump they could have just done LDA $4A AND #3 and skipped that whole integer division thing. For NES programming is it better to bend your game design around the CPU or just accept that sometimes you need to do actual multiplication/division?
Prime example of "a bug that became a feature", whether intentionally or not. Such a simple AI, yet all is issues and their ramifications are amazing. And the greatest fact of it is that it works, and beautifully.
Since I'm currently learning coding it's nice to hear familiar terms. Before it was even mentioned I suspected Megamans position would be factored in the AI logic. I love your eork with these videos Chris, keep em coming mate. They're always a treat.
This is so so so cool, and I would love to see more stuff like this! I have a few of questions for you (edited to address one that was already asked and answered): 1. When you talk about "floating-point" math in this video, is it really IEEE 754 floating point as we know it in the modern era, or is it just fixed-point math using pixels combined with subpixels? Or some other thing? *Edit: it seems that it is some kind of fractional fixed point, as answered in a comment below. So never mind this one!* 2. When Quick Man is ejected from a wall, it appears that his subpixels aren't cleared the same way that Mega Man's are. This just means that the ejection logic for Quick Man is different from the logic for Mega Man, right? Like they don't simply use the same process for some reason? If so, any idea why? If not, am I missing something? 3. Quick Man appears to be ejected horizontally while running into a 16-pixel-high block, but you said his code only checks one point for horizontal ejection, and it's at the top of his head. How is he ejected horizontally in this case? I have a bottomless curiosity for stuff like this, so it goes without saying that this is like in my top three favorite TH-cam channels. Please keep up the great work!
This kind of fixed point fractional values are great to "fake" smoothness when you otherwise have a noticeably low resolution for anything, be it the screen, sound fidelity, graphical fidelity, movement, etc.
I highly doubt it's IEEE 754, with the limited RAM of the NES you don't really want to burn 8 bytes on a single value. You technically have 2k of ram but after taking into account sprites, music, and the call stack, in practice you have about $500 bytes for game logic
On the subject of ejection logic: from what I've heard about the production of the megaman games, I wouldn't be surprised if that was a case of copy-paste gone wrong or something.
Fascinating. I've done a little reverse engineering of Strider for NES, which seems to have a similar issue with 'wiggling' when running against the wall. Probably a similar mistake in the order of moving vs ejecting code. I might spend some more time looking at this now that you've revealed a likely culprit!
Oooh! That's great. Strider for NES is... an interesting subject. I haven't played it in a long, long time, but I want to say that play control was not quite where it should have been? Like something felt a little off?
I think incorrect order can't be enough for the oscillation. It has to be that the subpixel position is not reset during ejection (as seems to be the case in this video I think?) Then the order of ejection and movement shouldn't matter for the oscillation behavior, but of course it matters if you want to avoid being inside of a wall!
@@DisplacedGamers Yeah, Strider fascinates me a lot. Play control is definitely weird. Strange behavior when you jump while running against a wall, frequent cases of jumps being “eaten” during certain situations like running downhill (where you hear the sound but the character just doesn't leave the ground, kind of like the Quick Man issue in a way), etc. That game would be an interesting one for a technical dive, I think.
@@DisplacedGamers Yeah, it's particularly fascinating, since it has a troubled dev history, with the US version shipping and the JP one getting canned - but a preprod cart was found and dumped of the JP ROM not that long ago, and the movement code is different. Seems better in some ways and worse in others, but being able to compare the code in two different states of development was part of what made it interesting to me.
This was the most fascinating (and useful) video you've done about Mega Man 2 thusfar. (Though admittedly it required groundwork set by previous videos.) I had never supposed that so much of his randomness was actually created by errors in the code. Now I'm curious about so many other robot masters. What are the other bosses' patterns, and what factors may have influenced their apparent challenge? Were the bosses in the later games easier to master because their behavior was less buggy, or was this just part of the changes in design?
My first thought was Quick man was treating steps like walls and his collision detection really couldn't tell the difference. If his head bumps into anything, then he's hit a wall (or mega man) hence the decision to program him the way they did. But, I'm not looking at the code (nor would I understand what I was seeing). Nevertheless, this was a fascinating video.
It's hard to believe there's anything but just some time crunched programmers who did the best they could for corporate bosses who didn't care much about QA, just that the release date was met for a popular sequel. The boss fight was a minute or two of the game experience, and I'm sure someone said "Hey boss the jump codes kinda f*cked but it works just good enough.."... Or maybe they just didn't have "external" emulator type debuggers like we do today.
so, in completelly profane words, his AI setup is completelly out of whack in every single frame at the end of the cycle (due to the conformation of the room mostly), eating up parts of the following cycle without any real consequenciality for that frame, effectivelly restarting the cycle at a random point of the cycle itself the 'randomized restart' doesn't activate as often in the rematch due the flat ground and that is why the battle feels so different, but the walls of the room can still mess up the cycle
I started trying to learn romhacking not too long ago, and I tried to fix this bug as part of a set of quality of life improvements. Admittedly my solution was a lot less in-depth than yours but it seems to work: I just flipped Quick Man's direction whenever his AI picks a new action, since in practice it seems like he always does that anyway.
Wow, I can follow the ASM with my knowledge of 16-bit 65816! Very cool and enlightening. Do you know how the code is documented? My own mod is in dire need of better organization, and I could use a guide.
Fascinating. I've never gotten into ROM-hacking, but used to use emulators and savestates to try and reverse-engineer how enemies and bosses worked in games. I wonder how many behaviors that I had assumed were do to RNG were actually from errors like this...
At first I was thinking there was going to be a bug section. I was kind of right with that being the whole video was basically quickman's bugs, with some coding in between.
Nice video as usual, but about the Doc Robots from Mega Man 3? Do they copy the code from Mega Man 2 wholesale or do they recreate it, have they even done some corrections to it?
I wouldn't be surprised that it started as a bug but was left in the code as a feature. In this case the bug makes the boss easier to hit but at the same time his pattern seems more random. If the bug dosen't break anything it can be used as a feature. It could be an easy solution to add more randomness to the boss pattern. Imagine if later in the game you would fight him again but now the bug is fixed and the boss is quicker but his pattern is clearer!
Here's my 3 hypotheses for how this happened: 1) copy&paste accident (too convenient). 2) someone noticed the behaviour, and thought it looked like Quick was freaking out, and just went with it (sloppy, dubious). 3) someone broke the code while fixing something else (most likely, imho).
He has a Block?!?!!?!? This robot master has always been a pain and I've only ever used his weakness against him. I never even knew he blocked attacks.
Hmm... fixing this bug makes him more jumpy and difficult to hit, but also more predictable. Perhaps more calls to the random routine should be added to do 1, 2, or 3 jumps, and also to randomize the running time? Then again, to make his AI more thematically difficult, it would be interesting if you could make him do mini hops to go up and down the "steps" in the room as he runs so as to not get stuck, maybe reverse direction when reaching the outer walls. Not sure if all this is possible within the game space available though.
I'm thinking about how the Doc-Quickman in MM3 compares. In that game he seemingly picks between 1-3 jumps randomly. The boomerangs seem to function the same though.
Thank you so much for asking a question I had for years if not decades. Do you think the devs knew about the bug but left it in to make the fight easier? Also is the bug still present in the Doc Robot refight in MM3?
I'm having fun watching these with my nephew. He's a young aspiring programmer. I think you do a fantastic job explaining basic concepts, and he doesn't get frustrated or tired while watching.
Great vid. I would say the "glitch" in him completing a first jump by falling into the floor, but it makes him more erratic to the casual player and isn't that the point?
I read recently somewhere that Quickman's AI was designed with a flat floor in mind, so the devs raised the floor of Quickman's room like that to deliberately trigger the AI mistakes and make him a little easier than he otherwise would have been. And then, later, you fight him on a flat floor during the rematch to make him harder. I wish I could find where I read that again. (I'll post again if I can find it) :D
That's weird because, while the raised floor does give you some opportunities to take advantage of his AI, it also makes it much harder to jump *over* him when he charges at you. On flat ground, jumping over him is pretty easy.
@@JamieVegas - Yep. You're welcome.
@@JamieVegas p
@@JamieVegas While this is a theory I thought of in a few minutes, I think it's plausible. Mega Man 2 was developed in the free time of the team between other projects. So, because of that it had some time crunch. Which means some of the rough edges of the game weren't ironed out in time for the release. I think Quick Man's A.I. bugging out on the raised floor is a part of that.
First the flat floor applies to all the remaches with some things like metal man’s conveyer being removed and flash man not having ice physics. The second thing is that Quick Man is actually much harder to fight on the original arena than the flat floor. I have done buster only and no damage runs on almost every robot master in every game and I for a fact know it took me longer to do a perfect run on quick man on the original elevated room than the flat floor. Also the bugs make him even harder as sometimes he will just run over the gaps while sometimes he will get stuck and the player doesn’t know which of the sequences will happen.
Quick Man is so fast that he runs into a wall before even realizing he hit it.
2 fast 4 u
Me whenever I have speed hacks on
Quick was always my favorite robot master. It's fun that the running into walls was made a canon part of his character. The lore says that he moves so fast that got his visual processing lags behind his actual movement
Oh I hated the guy, too many deaths. And after having to go through the stage with the instakill bars.
@@tjcihlar1 sane, after playing the japanese version of Mega Man the Wily Wars ( Rockman Mega World ), which is the best version to play ( the PAL version is slowed down ), I sufferend against this guy. Each shot dealt 1 damage, each shot = 1 damage. It's basically impossible to kill that guy so I used 2 of his weaknesses.
roahmmythril must be relieved, his long time rival explained...
It's so interesting how clumsy AI coding results in a slight difficulty increase during the endgame rematch! Kinda reminds me of how Space Invaders' gradually increasing speed is really just slowdown decreasing as the player reduces the number of sprites the game has to keep track of.
Yeah, it's one of those cases where you have to wonder if the bugs were deliberately left in. It seems like the "buggy" version of the fight is more dynamic and interesting than a "fixed" version. He's easier to hit if he gets stuck, but you can never predict when you'll get a clear shot. It's a bit of accidental randomness that works in the fight's favor.
TL;DR: It's not a bug, it's a feature
SNES ASM hacker here. We love your videos man, you do a great job showing the technical details but quickly summarizing it in an easily digestible way with great visual aids. Of course it helps that Mega Man is one of my favorite NES games. Great work :)
this channel is one of the few times i genuinely get excited for someone to lecture me over the internet about something
Ha! Thanks, Smedis2
I wonder if this might have been a known bug that was left in on purpose? Quick Man in his "broken" state is already arguably the hardest of the 8 robot masters in Mega Man 2, so the additional "downtime" to get a few hits in now and then as well as what is effectively a randomization of his jump count could have been seen as being better than the intended behavior, and was intentionally left in. Sometimes "good enough" is better than a polished product lol
Wouldn't the nullification of the first jump make the second jump's boomerangs harder to combat simply by making them less predictable? There are times when speed is less of a threat than unpredictability.
@@MasterKnightDH Possibly! But two things with that:
First, I don't know the exact stats for that fight specifically, but GENERALLY speaking their weapon is a robot master's weakest attack. Conversely, worst thing you can usually do when fighting a boss is hug him. This is one of the primary reasons why Quick Man and Heat Man (and, to a lesser extent, Air Man) tend to be the most troublesome fights, and Bubble Man and Flash Man tend to be easier. It's really easy to stay away from the latter, and really hard with the former. To put it another way: Quick Man's most lethal attack is touching you, and I'll take making it easier to avoid that than boomerangs any day of the week.
The second thing is that, with Quick Man specifically, the hardest part isn't even avoiding damage from boomerangs OR him. It's landing return fire. Any battle with Quick Man is going to fundamentally be a war of attrition, and I feel like anything that makes it easier to hurt him consistently is a hard nerf to the fight.
@@ValkyrieTiara Heat Man is very easy, his pattern is simple and and reactable. He's easily the easiest boss in MM2 to beat without taking damage.
@LordGoomba Crashman has a simple pattern that is easily manipulated. Once you get it down he is easy to beat with just the buster.
I wouldn't say quick is the hardest it just impossible not to get hit due to his random AI cause the buster does a lot of damage even on difficult. just come to the battle with full health and with luck you will easily win.
I read that Megaman 2 was made under an extremely tight schedule and they only had time to test if the code worked, but didn’t have time to refine it or make sure it worked *well*
That explains a lot about this
nah this was on purpose, the ejection looks more natural than the programming fix
Definitely an interesting breakdown on AI, especially in a capcom game. Its interesting to see how something as arbitrary as his failed ejection code changes the fight drastically when its fixed. Not sure when you would even get a chance to shoot him! Better get flashman's weapon and pray
the many tricks to get more out of less create interesting situations.
RoahmMythril Did a no-damage, buster-only run of QUICK MAN's stage. The video is like 10 years oldor something tho
RoahmMythril, is a name I have not heard in years.
"Fixed" Quick Man would probably be considered easier by the hardcore players because he would be far more predictable. Vanilla Quick Man can jump randomly and shoot randomly depending on whether or not he gets stuck in the wall. "Fixed" Quick Man does not shoot randomly, you will always be able to tell when he will shoot, making it much easier to dodge
@@wandwoodgames5699 who is or was RoahmMythril? Feel free to reply with as many game tropes and lines as you please.
EDIT: AAAAND I see the original line now...lol
I’m imagining Dr. Wily watching this video and getting increasingly frustrated until he throws a clipboard across his lab
15:39 "The vertical check sees that his top right side is stuck in what it assumes is the ceiling." See, I wasn't entirely sure I was following what was going on until you said this, and then it all clicked into place with a horrified, "Oh no. Oh no no no no".
Four years for a CS degree, better education in less than 20 minutes. Keep up the good work my friend.
what does a CS degree have to do with game dev? its a little broad dontcha think
@@welovethesnorks How did you watch this video and walk away with thinking it is about “game dev”?
@@fourtwizzy my friend this entire video is gamedev material, how did you watch this video and walk away thinking it "wasn't about game dev" ?
@@welovethesnorks My amigo. One does not teach game dev by dissecting a video game, showing you the assembly code, and then how to modify said values using Game Genie codes. The video isn't teaching you how to remake or create Megaman 2 in Unity. They are literally reverse engineering the game code, to find what is wrong, and then fixing it. This has far more to do with computer science than it does game dev. Go ask a game dev the last time the debugged assembly code, or didn't use a premade engine and didn't use a high level programming language.
Maybe you don't see the parallels between this and computer science, so only believe it to be "game dev"?
@@jessedaniels2230 my friend there is a lot to address in your comment, a lot of assumptions that make you look silly. There are new NES games made all of the time, assembly code is still code and everything mentioned in all of these videos are used in game dev. I'm not sure where you are getting "unity" from, but that is amateur shit. You sound like a person that doesn't, and cannot, make games - so please stop trying to lecture me about this video that is literally about game development at the core. What are you using the code for? Websites? Is that your CS degree? No? See how assuming works?
You know the Quick Man flicker would have made so much more sense if it was actually on purpose to give the illusion he moves so fast he blurs.
I was surprised to learn this was a bug all along! I think this could totally work out, have a simple counter where 1 pixel is added every other frame in either direction, AFTER the velocity logic.
That would look pretty convincing for running/jumping in a direction at the speed of, well, QUICK, lol
I wonder how much work would be needed to fix the Quick Man's entire behaviour, that would be a pretty cool ROMhack project...
it's funny how much the explanations make a lot of sense, and make me wonder "did they even test their stuff?" lol
Don't take it for fact that it's a bug, to me it seems like it's on purpose
I love these breakdowns. As a kid I used to just try and rush most mega man bosses. One AI break down that would be interesting to learn about is the one in Final Fantasy tactics. There have been a few times I've seen it be clever, and more times where they were dumb (mostly ally AI)
I read a piece on the corelation to code in ff5 being relatable to FFT code. Through it I was able to revise my own play strategies in ff5 and got me thinking of how FFT could be fixed to work better. There are many flaws and untold features that need light shed on them in both games frankly.
@@residentgrey Do you have a link to that article?
I did an AI FFT battle with description text th-cam.com/video/Zwuu99twlNw/w-d-xo.html
You need good setup like tailwind (defender) and geomancer as well as use berserker for who attacks. No idea how to set up turn 1 golem. Shame setup is probably needed, let alone Agrias is only good as another class as holy knight has low attack. Did a ton of exploits with that game too.
Though a technical info like this I couldn’t do.
@@MrVariant geomancy was my go-to backup skill after the samurai blade skills. Hell Ivy alone ended up clutch too many times with its excellent Stop chance. There are some interesting combinations that work in that game, so much so I opt for those combos instead of really using much of what is available.
@@residentgrey oh sure glad I could help. The power garb helps Agrias there as well though surprisingly she makes a better monk with equip sword for higher physical attack and holy sword. Lol the game makes no sense. I know a speed run where rpg limit break abused the time mage's quick for draw out when not doing the obvious with math skill and farmed jp fast by the Friendly Fire Tactics moniker (I'd throw stone or tailwind myself). I owned midlight deep on chocobo with Ramza as an onion knight with glacier gun on chocobo, and Reis' holy breath is rapha on steroids, doing about 400 damage per random hit.
Final boss I had a vid didn't even get a final turn without Orlandu and reacts by buffing faith lol. th-cam.com/video/WVrKIGX0Gr4/w-d-xo.html
I always thought that Quick Man running into walls was a statement on Wily's recurring "good enough" methodology for designing his robot masters. He made Quick Man run fast, but his processors can't quite keep up with his feet. Kind of like how some species of bug are so small and so fast that they need to stop mid-run because their eyes don't catch enough light.
Wait a minute, Quickman can block certain weapons??? I've never seen that happen before.
you actually have to hit him with those, and generally taht does not happen unless you're testing damages, or have no idea of what's his weackness
@@serPomiz Yeah, I have only seen it to beat the game without getting hit, because this boss is a massive run killer
Don't remember seeing that either. Seems like a useful deliberate strategy
I guess that explains why his Battle Network counterpart does the same thing. Quickman.EXE blocks all attacks when he's stationary and can only be damaged while he's jumping or throwing boomerangs.
This was, by far, my favorite video! -- Great job on the technical explanations and animated visualizations!!! :D
Thank you!
Also -- Thanks for fixing Quick Man.
It's very strange to see him behaving the way he was _meant_ to behave in that stage! :D
no one is confirming he was *meant* to behave that way
There's an in-universe explanation for bosses in MegaMan games to have bugged code. Dr. Light designed the processing hardware and AI code of the original robot masters while Dr. Wiley took lead on the power core and body design.
Quick Man having flawed code for handling collisions is just... funny.
This is such a cool channel. Every time I watch something from you, I learn a little more about code, despite being a coder at a few jobs. It's so interesting to see under the hood of my childhood games.
Displaced Gamers and Retro Games Mechanics Explained uploaded the same day, this is going to be a nice Friday night
Always fun to see how one flip in the order messes up everything after that.
This one was so much fun! Thank you for taking the time to make this.
these vids are highly educative, im working on my own megaman maker game and coding is my current goal
Thanks!
Thank you!
I'm willing to bet those glitches were left in to make Quick Man more manageable to defeat. Notably too, his AI was written with a flat arena in mind but they added those bumps to make him easier, no doubt knowing he'd get hung up on them as well to provide more opportunities to hit him (which is why the Wily Stage rematch is so much harder: you fight him in a flat arena that time).
exactly. I don't know how anyone would ever see this as a bug unless they didn't actually grow up with an NES
When I first started trying to program games I made exactly the same kinds of mistakes. If that puts me on par with Capcom's NES-era team, I'll consider myself in good company!
no one has confirmed this was a mistake
Remember that this game was coded quickly, early in gaming's history and during the team's spare-time. So I'm thinking this is a combination of bugs and getting the boss done as swiftly as his character. Not a good combo for being careful with the order of operation.
Quite plausible. It could even be that the developers were aware of some of the flaws but only had time and resources to devote to more important development issues; such situations seem not uncommon in the industry.
@@TravisTev That's my thoughts, in particular here. The bottom line is they had a bum-wrap (Poor Conditions) with which to make a classic game. They succeeded, but at the cost of missing some fine details and cleanup. If you want MM2 refined, look for the "Megamix" patch for the game online. It smooths out A LOT of what the team missed without altering the game too radically. Even give you the option of applying fixes as one sees fit.
Also, Quick Man is a robot. It makes sense from a lore standpoint that Dr. Wily made some bugs.
i remember hearing that Quikman's difficulty was more due to the broken code than design, and supposedly the designers knew the code was broken but because of the difficulty spike and lack of any game-breaking issues they left it alone.
Hear-say of course.
But hearing this...i dunno how truthful that is anymore. If hes constnatly in the air surely thats harder than what we got
Thanks for leaving this comment, vineheart01. I have heard this line of reasoning for many of the bugs found in various games - another example being the pendant bug in Faxanadu. The game thinks you have the pendant at the start of the game and then takes away the power if you pick it up. Some have claimed the developers did it as a lazy fix for the difficulty, but this line of thought doesn't make sense to me.
Unless the developers for Game X specifically state that they knew something was broken and they left it that way due to time constraints OR that yes, they did make a "dumb tweak" to adjust game difficulty, I am going to assume things like Quick Man getting stuck in a wall or inverse pendant logic in Faxanadu are simply bugs rather than a poor programmer's design tweak for difficulty.
To specifically answer the Quick Man issue - If I were the programmer and was allowed the time to fix the bug, I would have:
1: Fixed the wall ejection logic vs velocity application order and also corrected the off by one bug.
2: Probably have noticed the change in difficulty and suggested to the project lead/designer that we increase the frame count for Quick Man's running phase - literally change one value. Heck - I may have even made the tweak without asking depending on my working relationship with other people on the dev team.
@@DisplacedGamers My issue is that, unlike the off-by-one errors, this seems a weird bug to have show up. Why would you run these in the wrong order in the first place?
@@ZipplyZane Probably just early development woes, theres a TON of decision or shortfalls in the old games that nobody would even consider an issue these days, they'd just casually fix it and move on.
@@ZipplyZane I think it's easier to see these logic errors when you're looking at a finished code base. But remember, the specific routines that we're seeing now may have appeared (been programmed) in ANY order, and the code within changed in minor or major ways, at any time. Who knows what state it was in, when a given bug was introduced, and then how it changed afterward.
@@ZipplyZane One thing to keep in mind: Capcom only let the team work on the game in their spare time AND still expected them to have it complete within a certain time frame. The fact they had to deal with these constraints, ended up releasing it somewhat incomplete and with flaws, and yet it is still considered one of the best games of all time is nothing short of incredible.
Time for some coffee and code. Love these vids!
This is fascinating, I'm both amazed and grateful for this bug as it makes the battle more unpredictable and at the same time it makes it a little easier.
I don't know if it's the most important part of the video, but I enjoy seeing you look for the simplest solution to a problem. It would be easy to go, "Okay, we'll rewrite it but good this time." Easy, in quotations of course, but asking, "What is the simplest change we could make that would solve the issue, or even just have the largest impact?" is a great skill. Watching you demonstrate how to break down code, analyze it, and then look for improvements has probably helped a lot of people become better programmers.
Thank you! Attempting to use a Game Genie for a fix helps restrict me to changing just a few bytes - although I break the rules and create a new subroutine on occasion.
Well thanks man, I was just about to go to bed when I came across this now I’m goin down a rabbit hole 😂
it would have been better to have had a flat and low floor with platforms above in that boss stage too. I can also see some other movement logic that could scan better now. This brings forth many other options for a fix or enhancements.
I agree. The room layout for Quick Man doesn't really seem like a good design for his a.i. - broken or not.
Yet! It is possible that the room layout was designed in that way to help curb the difficulty for the player. Him running inside a "channel" in the floor will cage him momentarily.
I just found your channel and these videos are an absolute blast to watch.
I've been getting into gamedev myself and these videos really show off a lot of particular tricks and solutions to problems that i find genuinely invaluable.
As interesting as these videos are on a surface level to me (I love tech and programming) they're absolutely amazing reference material. The quality in the editing and explanations are top notch
Thanks!
With the title alone, you will never run out of content!
Little did I know when first playing this game as a kid that 30+ years later I'd be watching an in-depth breakdown of Quick Man's behavior.
It's fascinating to me that these games don't use a common 'eject from wall/floor' routine for everything, Especially since the robot masters and Megaman are all the same size and do running/jumping physics.
that incorrect, they don't do the same running/jumping physics - literally in this video mega man and quick man have different velocities
The main point of those video: Quick Man is so quick that he outruns the game's logic.
I'm not that good at coding, let alone assembly coding, but I like to watch these videos just to have a glimpse on how my favorite games work.
I think you are missing a few key points regarding uneven hit detection boundaries, logical order of operations for collision resolution specific to Quick Man, as well as redundant conditionals & subroutines... but yes, Quick Man is quick.
This is great! With the patch, Quickman became way more nimble, but at the same time way more predicable. I think that balances it. Some boss batles in the Megaman series feel like you gotta get lucky (ie Shadowman) and this was one of them, but now it's clear something really wasn't working correctly
Reason #21 why I am not a game designer, just a gamer
That "ejection" being in the wrong place made me remember something similar that happens in Rockman/Megaman 4 when you beat a boss. There's an animation where Rockman/Megaman runs to the middle of the screen, jumps and stays floating in mid-air to "absorbe" the new power. But what happens if Rockman/Megaman is already standing in the middle of the screen? Well, the animation skips the jump and suddenly "teleports" Rockman/Megaman to mid-air. I haven't looked at the code, but probably there's some kind of routine that goes something like "check distance to center of the screen > run to center > jump", then call the "absorbe" routine; but if you're already there at the center, it skips the routine completely and goes directly to "absorbe power" in mid-air, skipping the jumping part.
I remember when I was a kid having fun trying to position megaman exactly in the middle to trigger this after every boss fight. Want to investigate it?
That seems like a case of incorrect branching instead. "If this is the case, then jump to that other place in the code", except they put said point one action too late.
More of these please! The code behind why AI does odd things is fascinating!
Fantastic video as always! Peanut gallery incoming:
0:53 I see that DEX at 879E--is that necessary? Could they have increased the subsequent addresses by 1?
2:08 But in a TAS, hoo boy. RNG manipulation so easy it'll spoil you for life.
5:00 Floating point? _What?_ That's amazing!
18:05 FCEUX has a cool feature called the Code Data Logger that can tell you, for every byte, whether it's been used as code, data, or neither.
There's a rare glitch where Quick Man will do his blocking stance when hit with a weapon that should damage him. No idea how it works.
Mesen has a Code Data Logger too, among other _powerful_ debugging capabilities
"Floating point? What? That's amazing!" It's not *really* floating-point. It's fractional fixed point; treating certain low bits as fractional. The math works out the same; it's all in interpreting what it means.
Ah I gotcha. Same as usual pixels + subpixels.
I've also seen a cool vector routine that can compute and I think even scale a vector between two points.
Hmm. I wonder what is going on with the blocking logic when MM is using a valid weapon.
Sorry about the use of "floating point." I just used it as a term that many other programmers would recognize and would help me complete a sentence and keep rolling. Showing the fractions as decimals in the slides was another way to just make it easier to read. It is still just an unsigned number from 0 to 255 behind the scenes.
Idk how easily this can be checked, but I wonder how many of the bugs w/ this boss carried over to the Mega Man 3 re-fight.
This is one of those times you could make a case that it's not a bug, it's a feature
At least, if any balance tweaking of the boss was done, it was done based off the "broken" code, not the fixed version.
MegaMan and programming discussion in one video? LIKED.
2:46 Had there been four choices for quick man to jump they could have just done LDA $4A AND #3 and skipped that whole integer division thing. For NES programming is it better to bend your game design around the CPU or just accept that sometimes you need to do actual multiplication/division?
wait...didnt they write something about the running into walls thing into quick man's lore at some point?
Really makes me wonder where is the line between intelligence and an organism/computer following simple tasks.
Lovely breakdown!
This boss haunted my childhood. Hardest mega man robot master
Prime example of "a bug that became a feature", whether intentionally or not. Such a simple AI, yet all is issues and their ramifications are amazing. And the greatest fact of it is that it works, and beautifully.
Hey can you do Ivan Stewart’s super off road on nes ?
Neat analysis video! Thanks for uploading!
Since I'm currently learning coding it's nice to hear familiar terms. Before it was even mentioned I suspected Megamans position would be factored in the AI logic. I love your eork with these videos Chris, keep em coming mate. They're always a treat.
Fun to learn how monsters and machines attack in old games :)
Okay! I was wondering what codes Dr. Wiley used! Genius work but it looks like he may have designed him to quickly!
This is so so so cool, and I would love to see more stuff like this! I have a few of questions for you (edited to address one that was already asked and answered):
1. When you talk about "floating-point" math in this video, is it really IEEE 754 floating point as we know it in the modern era, or is it just fixed-point math using pixels combined with subpixels? Or some other thing? *Edit: it seems that it is some kind of fractional fixed point, as answered in a comment below. So never mind this one!*
2. When Quick Man is ejected from a wall, it appears that his subpixels aren't cleared the same way that Mega Man's are. This just means that the ejection logic for Quick Man is different from the logic for Mega Man, right? Like they don't simply use the same process for some reason? If so, any idea why? If not, am I missing something?
3. Quick Man appears to be ejected horizontally while running into a 16-pixel-high block, but you said his code only checks one point for horizontal ejection, and it's at the top of his head. How is he ejected horizontally in this case?
I have a bottomless curiosity for stuff like this, so it goes without saying that this is like in my top three favorite TH-cam channels. Please keep up the great work!
This kind of fixed point fractional values are great to "fake" smoothness when you otherwise have a noticeably low resolution for anything, be it the screen, sound fidelity, graphical fidelity, movement, etc.
Came here to ask the same questions 2 and 3 :)
I highly doubt it's IEEE 754, with the limited RAM of the NES you don't really want to burn 8 bytes on a single value. You technically have 2k of ram but after taking into account sprites, music, and the call stack, in practice you have about $500 bytes for game logic
On the subject of ejection logic: from what I've heard about the production of the megaman games, I wouldn't be surprised if that was a case of copy-paste gone wrong or something.
Question: is this same code used for Doc Quick in Megaman 3?
Good question. We'd have to reverse the code for Mega Man 3 or try to make the observations about it.
Fascinating. I've done a little reverse engineering of Strider for NES, which seems to have a similar issue with 'wiggling' when running against the wall. Probably a similar mistake in the order of moving vs ejecting code. I might spend some more time looking at this now that you've revealed a likely culprit!
Oooh! That's great. Strider for NES is... an interesting subject. I haven't played it in a long, long time, but I want to say that play control was not quite where it should have been? Like something felt a little off?
I think incorrect order can't be enough for the oscillation. It has to be that the subpixel position is not reset during ejection (as seems to be the case in this video I think?) Then the order of ejection and movement shouldn't matter for the oscillation behavior, but of course it matters if you want to avoid being inside of a wall!
@@DisplacedGamers Yeah, Strider fascinates me a lot. Play control is definitely weird. Strange behavior when you jump while running against a wall, frequent cases of jumps being “eaten” during certain situations like running downhill (where you hear the sound but the character just doesn't leave the ground, kind of like the Quick Man issue in a way), etc. That game would be an interesting one for a technical dive, I think.
@@DisplacedGamers Yeah, it's particularly fascinating, since it has a troubled dev history, with the US version shipping and the JP one getting canned - but a preprod cart was found and dumped of the JP ROM not that long ago, and the movement code is different. Seems better in some ways and worse in others, but being able to compare the code in two different states of development was part of what made it interesting to me.
This was the most fascinating (and useful) video you've done about Mega Man 2 thusfar.
(Though admittedly it required groundwork set by previous videos.)
I had never supposed that so much of his randomness was actually created by errors in the code.
Now I'm curious about so many other robot masters. What are the other bosses' patterns, and what factors may have influenced their apparent challenge? Were the bosses in the later games easier to master because their behavior was less buggy, or was this just part of the changes in design?
My first thought was Quick man was treating steps like walls and his collision detection really couldn't tell the difference. If his head bumps into anything, then he's hit a wall (or mega man) hence the decision to program him the way they did. But, I'm not looking at the code (nor would I understand what I was seeing). Nevertheless, this was a fascinating video.
It's hard to believe there's anything but just some time crunched programmers who did the best they could for corporate bosses who didn't care much about QA, just that the release date was met for a popular sequel. The boss fight was a minute or two of the game experience, and I'm sure someone said "Hey boss the jump codes kinda f*cked but it works just good enough.."... Or maybe they just didn't have "external" emulator type debuggers like we do today.
I feel like this is a massive help to those that edit Boss AI in rom hacks and such
so, in completelly profane words, his AI setup is completelly out of whack in every single frame at the end of the cycle (due to the conformation of the room mostly), eating up parts of the following cycle without any real consequenciality for that frame, effectivelly restarting the cycle at a random point of the cycle itself
the 'randomized restart' doesn't activate as often in the rematch due the flat ground and that is why the battle feels so different, but the walls of the room can still mess up the cycle
I started trying to learn romhacking not too long ago, and I tried to fix this bug as part of a set of quality of life improvements. Admittedly my solution was a lot less in-depth than yours but it seems to work: I just flipped Quick Man's direction whenever his AI picks a new action, since in practice it seems like he always does that anyway.
Quick Man: *gets stuck*
Mega Man: “Should I help him, or finish him?”
Wow, I can follow the ASM with my knowledge of 16-bit 65816! Very cool and enlightening. Do you know how the code is documented? My own mod is in dire need of better organization, and I could use a guide.
Fascinating.
I've never gotten into ROM-hacking, but used to use emulators and savestates to try and reverse-engineer how enemies and bosses worked in games. I wonder how many behaviors that I had assumed were do to RNG were actually from errors like this...
I could watch these all day. I mean I already do
Quick Man was already the hardest robot master and you want to make him harder?
lol. : "Good luck!"
ROAHM! ROAHM WE FOUND IT!!!
This was explained by Fellon in 2015, to which Roahm also replied: th-cam.com/video/RBYhn781J3M/w-d-xo.html
As always, way above my head, but still very enjoyable to watch! 👌
Thanks for watching and sticking with it!
I've been looking for a channel liek yours for a long time, im glad i finnaly found it.
At first I was thinking there was going to be a bug section. I was kind of right with that being the whole video was basically quickman's bugs, with some coding in between.
I like this it would be cool if you did AI explained for other megaman robot masters it would be a really cool series
Nice video as usual, but about the Doc Robots from Mega Man 3? Do they copy the code from Mega Man 2 wholesale or do they recreate it, have they even done some corrections to it?
I'd have to reverse MM3 to find out. It is possible someone else has already looked at it and can answer this.
Wouldn't mind playing a ROMhack with all the bugs and stuff fixed, just to see how different it could be.
@17:30 - Quickman handlers! Hahaha! Sounds funny 😀
Quick Man with Metal Man's projectiles seem so OP.
I wouldn't be surprised that it started as a bug but was left in the code as a feature. In this case the bug makes the boss easier to hit but at the same time his pattern seems more random. If the bug dosen't break anything it can be used as a feature. It could be an easy solution to add more randomness to the boss pattern. Imagine if later in the game you would fight him again but now the bug is fixed and the boss is quicker but his pattern is clearer!
Here's my 3 hypotheses for how this happened:
1) copy&paste accident (too convenient).
2) someone noticed the behaviour, and thought it looked like Quick was freaking out, and just went with it (sloppy, dubious).
3) someone broke the code while fixing something else (most likely, imho).
I'm so excited!
He has a Block?!?!!?!? This robot master has always been a pain and I've only ever used his weakness against him. I never even knew he blocked attacks.
And I was listening to Quickman's music from The Megas today
So how do you beat him without getting hit?
I’m watching this at 255 views. Perfect
Oh no, now it has 0 views
Oh that explains why the first time it loaded as an unboxing of an air fryer.
Hmm... fixing this bug makes him more jumpy and difficult to hit, but also more predictable. Perhaps more calls to the random routine should be added to do 1, 2, or 3 jumps, and also to randomize the running time? Then again, to make his AI more thematically difficult, it would be interesting if you could make him do mini hops to go up and down the "steps" in the room as he runs so as to not get stuck, maybe reverse direction when reaching the outer walls. Not sure if all this is possible within the game space available though.
I'm thinking about how the Doc-Quickman in MM3 compares. In that game he seemingly picks between 1-3 jumps randomly. The boomerangs seem to function the same though.
Thank you so much for asking a question I had for years if not decades. Do you think the devs knew about the bug but left it in to make the fight easier? Also is the bug still present in the Doc Robot refight in MM3?
Quick Man will never get a girlfriend because he is so fast.
Great stuff, I'd love to see more on the fixed maths used - I take it's 4.4? Love these videos.
14 boomerangs and we have almost a bullet-hell here, but i really like to try these absurd gameplay
Great video, but I noticed the audio was occasionally drifting louder and softer. Don't know if anyone else hears that, maybe it's just me.
Is there a clean fix to megaman 1's getting ejected from boss rooms if they knock him back?
This is why I dont think I'd ever make a game. This boss is not a complicated fight but this looks like it was extremely difficult to code.
Huh, never knew Quick Man would essentially be stunned by the metal blade
I'm having fun watching these with my nephew. He's a young aspiring programmer. I think you do a fantastic job explaining basic concepts, and he doesn't get frustrated or tired while watching.
Great vid. I would say the "glitch" in him completing a first jump by falling into the floor, but it makes him more erratic to the casual player and isn't that the point?