As I've said before, I am not a programmer. Before OH JOES!, most of my exposure to programming was in elementary school, where I used QBasic and an ancient software called Story Tree to craft Choose Your Own Adventure–style text adventures. What business did I have designing an action-platformer with moving platforms, complicated collision detection, and randomized text dependent on global variables, to name but a few components? In my defense, when I started the project, all I thought I'd need to do was add one or two new objects and reconfigure a couple of menus. After all, OH JOES! was supposed to be little more than a bonus level for a game that had already been released.
After designing my levels for Mega Man Endless and Make a Good Mega Man Level Contest (MaGMML), I knew my way around the GameMaker program interface. The problem was deciphering what all the code meant. I had no desire to start from the ground up, following the tutorials to design a Breakout clone and become an Actually Competent Programmer; I intended to locate objects in the MaGMML devkit with specific behaviors, isolate the code that controlled those behaviors, and then adapt the code to create the enemies and special weapons I wanted to add. I was a code scavenger, not a programmer.
OH JOES! would have ended up much differently if I'd had any real programming ability at the beginning. The very first enemy I tried to add was Rider Joe, who would have patrolled the surface of the water areas I planned to design. I thought it would be a welcome change of pace to have a mobile, unshielded enemy to break up the monotony of Sniper Joes everywhere. I lifted some code from Mousubeil, a mouse enemy that moves back and forth and turns around when it hits a wall or ledge. When I ran a test to see if the code worked, Rider Joe piloted his Marine Bike in reverse, through a wall, and out of my game forever.
I opted not to include the Returning Machine Gun Joe from Mega Man 10; his differences from the regular Machine Gun Joe weren't enough to justify the extra programming effort for the short game I had in mind, plus I was intimidated by the prospect of making his shield breakable for full authenticity. I did want to include more Joes than were in the MaGMML devkit, however, and fellow fangame developer Blyka volunteered the Crystal Joe code he developed for SuperDanny 2. Altogether, I now had seven varieties of Joe to use in my glorified MaGMML level—technically eight, if you count Cannon Joe, but he no longer fit with my design plan. Without Rider Joe, it made less sense to make a game about Joes in general; my main purpose was to showcase how the most obnoxious and overused Joes (ie, the shielded ones) could be used in creative new ways.
For the record, I regret not trying harder to get Rider Joe to work. I think I would have produced a better game while still getting my point across if it were just about Joes in general.
With the enemies finalized, it was time to get the weapon selection sorted. At the start of the project, I worked up a list of weapons that I thought would be (a) easy to program, and (b) specifically useful for dispatching Joes. The shield-piercing Laser Trident was at the top of the list, but I also had the rapid-fire Needle Cannon on there, along with Hyper Bomb and a few different barrier weapons. However, I also wanted to avoid weapons that had been used in MaGMML and Endless, which helped me narrow down what to include when I decided on giving the player only two special weapons. Proto Coil was always going to fill the utility slot; Rush Coil was already in the devkit, and changing the graphics required minimal effort. Call it laziness, if you want; I call it efficiency.
Laser Trident proved to be a bit of a challenge—the weapon accelerates as it moves, and I couldn't find anything in the devkit with acceleration code I could copy. Around the same time, I started manually adding the touch-'em-and-they-disappear Sheep Man blocks from Mega Man 10, which I thought would add a nice puzzle element without requiring too much programming skill. After all, they're just stationary blocks; how much trouble could they possibly cause?
Let me tell you: stationary blocks are devious troublemakers like you wouldn't believe. I could get them to disappear just fine, but making them reappear after leaving the screen and returning—that was some arcane wizardry that demanded outside help. Issues with Sheep Man blocks persisted up until the very last round of playtesting, and included everything from constantly flashing to leaving invisible spikes behind after disappearing.
This is where I started to pester other programmers from the Mega Man fan community. I was highly selective in my search for assistance: Do you know more than me about programming? Can you spare a minute? This rigorous interview process secured about a half-dozen programmers who each single-handedly rescued the project from utter disaster at one point or another. Blyka, SnoruntPyro, and Entity1037 all made key contributions toward the start of the project, but perhaps the biggest hero of early development was Renhoek, who tirelessly volunteered as my go-to programming consultant during those formative months. In hindsight, though, it might've been better for my programming friends to spend their time creating new objects from scratch instead of figuring out how to patch and polish my scavenged, often nonsensical code.
Here's another example of how programming limitations informed the level design: due to issues that were never fully resolved, Sheep Man blocks don't function properly in scrolling sections. You'll notice that every Sheep Man block challenge in OH JOES!, without exception, takes place on a single, self-contained screen. That's the entire reason why the Stage 4 route with this gimmick is predominantly vertical—although a couple Mega Man games feature vertical scrolling, it's not the norm, so it's less conspicuous to string together 12 non-scrolling screens in a vertical fashion. With any luck, you didn't even notice.
Ironically, following the premise to its logical conclusion meant eventually fighting a Joe equipped with Proto Man's shot-reflecting shield. This is part of why it took so long to figure out a substitute final boss after the helicarrier idea fell through—I knew what the answer was, but I didn't want to deal with it. Naturally, once I had the code, I didn't let it go to waste. If Regular Joe could use the Proto Shield, so could Proto Man once he got it back. I even have one more idea in mind for the reflection mechanic, but there are still more pressing things to program, even now that the game has been released.
For starters, the Joes in the devkit were largely inaccurate to their official counterparts. Hitboxes were off; animations were incomplete; attack patterns were varying degrees of completely off the mark. I was willing to allow for some discrepancies, given the aforementioned variations from game to game, but I at least wanted the regular Sniper Joe to fire the right style of projectile. I started cross-referencing the official games to make sure my Joes sufficiently resembled the ones that drove me to make this game in the first place.
Working on the Sniper Joe from the original Mega Man was an educational experience, as it was probably the first time I needed to do any real programming. This particular enemy is renowned for being obnoxiously unpredictable, but after careful observation, I discovered a sort of elegance in its randomization. The number of shots he fires depends on his relative position to the player—positioned above, he'll only fire one shot; anywhere else, it's 1-4 shots. He jumps at random, but never more than twice in a row. The time he hides behind his shield varies, but the timer resets every time you hit his shield—in other words, he won't start firing until you stop. I did actual research, not just code scavenging, to figure out how to emulate this behavior. While the Sniper Joe in OH JOES! is not wholly accurate—I made a few deliberate changes that hopefully preserve the general behavior while toning down the annoyance factor somewhat—I was proud of my accomplishment.
The other Joes received some tweaking, but they were eventually replaced with the more accurate ones Blyka developed for his SuperDanny games. Admittedly, I should've thought to ask for them sooner, as a large portion of the challenges at that point had already been designed around the old MaGMML enemy behavior. Most notably, Sniper Armor used to be less selective about when to fire, and Skeleton Joe previously had a very different throwing arc. I tried to redesign any challenges that really didn't work with the updated behaviors, but if a few areas still don't feel quite right, that might be why.
I want to clear up a widespread misconception about Blyka's Mega Man engine, which MaGMML (and, in turn, OH JOES!) is based on. People treat Blyka's Engine as the punchline to any joke about bad programming, the "Thanks, Obama" of the Mega Man fangame scene—and I'm tired of it. MaGMML is notorious for being buggy, and multiple players managed to break OH JOES! within 10 minutes of its release; none of this is the fault of Blyka or his engine.
I've worked with Blyka on two projects and have had long discussions with him about his other game development endeavors—this is a guy who has a keen eye for detail, cares a great deal about authenticity, and puts a high priority on game stability. If MaGMML is buggy, it's because everything created from scratch wasn't playtested thoroughly enough. If OH JOES! is buggy, it's because I taught myself how to program as I went, declaring the game to be "good enough" when I finally burned out on trying to get things as perfect as I wanted them to be. If you're going to blame Blyka's Engine for anything, blame it for not including an example of how to make a moving platform that actually works correctly.
Indeed, trying to recreate the jet sled from Mega Man 2 was a terrible idea. Item-2, as the utility is known, was supposed to be easy—after being summoned, it accelerates to its top speed (which I now knew how to do because of Laser Trident) and travels in a straight line until it hits a wall. First, I couldn't get it to be solid on top but pass-through on the bottom. Then I couldn't get the hero to stay standing on it while it moved. Then I couldn't stop the player from getting lodged in walls when it came to a halt. Almost every programmer involved in the project contributed some code to improve Item-2, to the point where no one (least of all me) really understands how it works anymore. Despite it seemingly working fine upon release, I'm still receiving reports of players taking up permanent residence in a ceiling somewhere.
I will emphasize that this game wouldn't have been possible without all the help I got. I can cite plenty of specific elements for which other programmers were responsible—Entity1037 rewrote the enemy collision code; WreckingPrograms overhauled the way resizing the game window was handled; Renhoek sorted out the logistical difficulties with Stage 4 being one stage and multiple stages at once; SnoruntPyro got the victory animation to animate when the game itself refused to allow it; Blyka resolved a baffling issue where players would randomly fall through the tops of ladders; and so on. One benefit of working with so many creative and talented programmers is that some of that ability rubs off, so I've learned a lot from these people about how to write decent code, plan for future expansion, and troubleshoot a game.
I may not be an Actually Competent Programmer—I'm more like a Not Entirely Incompetent Code Manipulator—but I definitely feel like I earned my programming credit on this game. At best, programming was a rewarding experience where I claimed honest-to-goodness ownership of the game while pushing my problem-solving skills to their limit. At worst, it was a waste of entire evenings and an infuriating exercise in banging my head against the wall. Unquestionably, it was my least favorite hat of all the ones I wore for this project. But I'm glad I tried it on.