Story navigation: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8

I love to build and create. LEGO toys were among my absolute favorites growing up, and I spent large chunks of elementary and middle school drawing towns, dungeons, and overworlds for video games I wanted to make. I've poured countless joyful hours into developing my perpetually in-progress ROM hack of Super Mario World, multiplayer maps for Heroes of Might and Magic III and Star Wars: Jedi Knight II: Jedi Outcast, and levels for basically every game that's ever given me a level editor. It should come as no surprise, then, that level design was easily my favorite part of working on OH JOES!.

I didn't set out to make a proper fangame—in fact, if you had told me the game would require extensive programming and 35 other people to finish, I would've laughed and dropped the idea on the spot. I was looking forward to a project that was 80% level design and graphics, 20% whatever else was necessary to make it a standalone download. All I wanted was another opportunity to make a Mega Man level, and I was willing to branch out and try my hand at a few new skills to make it happen.

In the short time that I had been designing Mega Man levels, I had learned some important lessons. In lieu of the "Lessons in Level Design" blog post I started a year ago but never finished writing, here are my key takeaways from Make a Good Mega Man Level Contest (MaGMML) and Mega Man Endless:

• Learning curve is always important, even if expert players are your target audience.
• Get other people to playtest your level, because you cannot accurately judge difficulty or fairness when you know more about the level at the beginning than players will know at the end.
• There's a line between variety and excess; keep the enemy and hazard selection focused.
• Keep an eye on level length, both in terms of screen count and completion time.
• Ideally, levels should be beatable without taking damage, using only the default weapon.
• Use instant death sparingly and deliberately.
• Anything players can do, they will do, no matter how inane or counter-intuitive it is.
• Setting player expectations is critical, especially in a nonstandard Mega Man level, because players otherwise make (usually false) assumptions based on their own unique gaming experiences.
• Consider the player's likely emotional state at various points in the level—fatigue, panic, and complacency can change the dynamic of the challenges.

In addition to these points, I worked out some core guidelines specifically for OH JOES!—a checklist, if you will, for every challenge in the game:

1. Give the player ample time and guidance to understand the nature of each challenge before being threatened with bodily harm, introducing new enemies and gimmicks in a (reasonably) safe environment.
2. Aside from basic platforming mishaps, injury and death should only occur as a direct or indirect result of a Joe. Challenges surrounding power-ups bend this rule a bit, because you wouldn't subject yourself to extra danger if you didn't need power-ups to keep fighting Joes.
3. Through special weapons, careful observation, damage boosting, power-ups, Game Over hints, and a reasonable amount of practice, any player of any skill level should be able to beat the game.

With all these suggestions and rules swirling around in my head, I got to work on the level design. The ideas I had in mind for creative Joe use relied on the player being familiar with the Joes' attack patterns, so an intro section devoid of gimmicks was essential. This was good practice for me as a level designer, too; when you've got the ability to create anything your imagination (and limited programming skill) can come up with, it's easy to forget the importance of starting with "boring" challenges as a warmup for the player.

The first few screens of the game draw inspiration from the official Mega Man games, at least in terms of Joe placement. Just like in Bomb Man's stage, your first encounter with a Sniper Joe is out in the open with nowhere to hide, and your second encounter is on a ledge (though this time it's more feasible to hop up on the ledge if you prefer face-to-face combat). Although I would normally never kick off a level using something as complicated as a Sniper Joe—let alone with no safe place to observe the enemy's behavior—I wanted to emulate the experience of playing through the official games and encountering these enemies for the first time.

Next was the obligatory Returning Sniper Joe at the top of a boring ladder (I had to do that at least once), followed by one atop a short ledge, as in Quick Man's stage. Except this time, you could charge your default weapon and take out the Joe without ever moving into the line of fire. As often as possible, I wanted to give players the option to avoid engaging Joes in normal combat—but if they did have to fight, I wanted the environment to interfere with the usual formula of "hang back at a safe distance and trade shots at roughly the same rate."

Part of thinking strategically is remembering and understanding everything you have at your disposal. To enter the room with Hammer Joes, whose projectiles can often be avoided by sliding under them, I force the player to slide through a narrow passageway. The first Joe is up on a high ledge reminiscent of the one in Hard Man's stage; though in OH JOES! it's definitely possible to jump up to the ledge unassisted, it's enough of a stretch that some players might investigate whether they have any support utilities (which they do). The second Joe fulfills the "Joe blocking a boring hallway" obligation, but the encounter gives the player a chance to practice avoiding projectiles while falling, with enough room to either slide under the Joe's projectiles or hang back and jump over them. Freedom of choice is a core component of the Mega Man franchise, and I wanted to incorporate that into the challenge design as often as possible.

This is the level of thought I put into each and every one of the game's 300+ screens. Once gimmicks entered the mix, I started thinking about situations I hadn't seen before in other Mega Man games, and the game took on a "sampler platter" approach to level design. Each screen was a self-contained example of how Joes could be used in more interesting and creative ways than usual. At the time, I wasn't planning on adding more stages or combining gimmicks, so I tended to ramp up the challenge complexity pretty quickly—four or five screens was all I thought you were going to get with these gimmicks.

To maintain the element of player choice, I employed split paths—a hub room would introduce two new gimmicks in a safe environment, and then the player could pick whichever gimmick they preferred. The options I offered were never arbitrary; by the end of the game, I wanted players to have survived challenges based around forced movement (magnet vs quicksand), ubiquitous gimmicks people take for granted (ladder vs water), gimmicks that everyone hates (Guts lifts vs Quick lasers), destructible blocks (Dust blocks vs Chill blocks), and...uh...cone-shaped things (needles vs springs). OK, so that last one was a stretch, but I was running out of gimmicks in the MaGMML devkit that (a) had potentially interesting interactions with Joes, and (b) weren't too glitchy to use reliably.

That's why the puzzle-oriented challenge choice (Sheep blocks vs Yoku blocks) eventually changed to Sheep blocks vs fake blocks. Yoku blocks ended up being too much of a liability to keep, but I didn't have any good alternatives in the devkit (and I wasn't about to program another gimmick, given how much effort the Sheep blocks and Chill blocks were). Desperate, I turned to Mega Man 5 for inspiration: by simply adding a tile layer in front of the player, I could recreate the pass-through blocks seen briefly in Napalm Man's stage (and in one of the fortress stages). It was a lazy solution, but it offered some interesting Joe interactions and fit the puzzle mandate well enough.

By the time the game had expanded into three stages, I had an unusual problem on my hands: my emphasis on split paths potentially put the player at a disadvantage. If first-time players made it through the second stage without dying, or at least without trying out any given alternate path after being sent back to a checkpoint, they'd enter the third stage having only seen 50% of the gimmicks about to be thrown at them. I wanted to start combining gimmicks, still giving players the option to choose between one pair of gimmicks over another pair, but I had to ensure that players had a proper warmup no matter how much or how little they saw in the previous stage.

I wrote a list of all the gimmicks in the game, and then I started mentally smashing them together. Most importantly, each choice of paths needed to offer players at least one gimmick they had definitely seen before. For example, a choice between "magnets + needles" or "Chill blocks + water" was out of the question, because it was entirely possible for players to have selected all the paths in Stage 2 that allowed them to avoid those gimmicks. My problem wasn't so much that these gimmicks hadn't been selected for their ability to work well together; it was that this restriction ruled out many of the combinations I actually wanted to use. Believe me, "Chill blocks + fake blocks" was not my first choice.

Even with at least one path featuring a familiar gimmick, I wanted to give players enough of a warmup that they could take a chance on a path that was totally new. This is how "three screens of one gimmick, three screens of the other, then three with both combined" became the formula for Stage 3. Any shorter, and the learning curve might be too accelerated; any longer, and the stage's screen count would fall too far outside normal parameters for a Mega Man game (usually 20-30 screens).

Of course, when I decided to add a fourth stage combining every gimmick with every other gimmick, all that careful planning went out the window. I still tried to give the player a choice between thematically similar options, but otherwise the design mentality was that (a) players should be pretty comfortable with most of the gimmicks by now, and (b) the abnormally high screen count would necessitate thinking strategically and using everything at one's disposal to survive—things I had tried to encourage from the very beginning.

It was exhausting to design a stage that was effectively 12 half-levels with connecting hubs. On the plus side, I was able to showcase a huge amount of variety in how Joes could be used, which was the whole point of this exercise. On the minus side, it's pretty clear that I was running out of ideas for a few of the combinations ("ladders + fake blocks" might as well just be "fake blocks"), and the nature of the stage made it incredibly hard to keep a steady difficulty curve. I can't tell you how many times I overhauled the Guts path so that it wasn't outrageously more difficult than the other paths at that juncture.

Level design is so much more than making interesting challenges. There's an art to crafting level architecture that's visually appealing as well as functional. Challenges don't exist in a vacuum; it's important to consider the context of what comes before and after. Assets don't always function as well as you want them to, and sometimes the only solution is to work around them rather than fix them. And perhaps most relevant for me, planning ahead—and sticking to the plan—is essential.

Story navigation: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8

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.

My next attempt went much better; creating the Machine Gun Joe from Mega Man 9 was mostly a matter of making the Sniper Joe from the original Mega Man fire more shots and jump on a schedule. Granted, it took a few evenings to get a firm handle on things like alarms, image_xscale (bullets came out of his blaster facing the wrong direction), the difference between image_index and sprite_index (when the appointed time came for him to jump, he turned into a frog), and the importance of gravity (the first time he jumped without a ceiling overhead, he peacefully ascended to the sky and never returned). I also spent some time playing and reviewing gameplay footage of Mega Man 9 to ensure I got his timing and behavior as accurate as possible. I was incredibly proud of the result, and it was the confidence boost I needed to press on with the project.

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.

In fact, the entire premise of the game stems from a programming limitation. I knew I wanted a game about Joes, and Proto Man was already included as a playable character in MaGMML, so I thought it would be both different and poetic to have Mega Man's shield-toting brother take on a fortress of shielded enemies. Except...I had no idea how to program Proto Man's shot-reflecting shield, and it seemed like a hassle for the tiny scope of the project. At the same time, I wasn't about to use Proto Man's usual character sprites if his shield was merely decorative. The solution, of course, was to separate him from his shield somehow. Regular Joe steals Proto Man's shield because I couldn't figure out how to make it reflect shots.

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.

One thing I failed to realize was just how rough the foundation for my project was. Fangames in general are not known for their fidelity to the source material in terms of programming accuracy, and even the official games vary in subtle ways—the speed of screen transitions and the floatiness of Mega Man's jumping, for example, vary from game to game. I've played a lot of Mega Man, both official and unofficial, so I've learned to filter out these little differences unless they clash too much with my usual gameplay style to adapt to them. By using Make a Good Mega Man Level Contest (or MaGMML, for short) as the basis for my game engine, I was inheriting a host of glitches and inaccuracies that—at the time—were barely apparent unless I tried to use Rush Jet. The longer I worked on OH JOES!, the more apparent it became that the engine needed an overhaul.

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.

These are the kinds of issues you run into when you've learned just enough about programming to think you know anything. As my confidence grew, so too did the list of features—things like multiple difficulties, a second playable character, a third playable character, and an option to save and quit in the middle of the game. Fortunately, these fared much better than Item-2 did. As long as movement wasn't involved, I was surprisingly capable of implementing anything I wanted. I may have started out by tinkering with someone else's project, but by the end, I was the lead programmer of my own fangame. That's amazing to me. Especially because I am not a programmer.

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.

Story navigation: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8

Ever since I was a little kid, it's been my dream to create a video game of my own—particularly a Mega Man game. In the last few years, I've had multiple opportunities to make that a partial reality; I've designed levels for multiple Mega Man fangames, and I even have my name in the credits of an official Mega Man game. Yesterday, my dream was realized in full with the release of OH JOES! (A Proto Man Adventure), a scrappy little platformer that took 2 years and 35 people to make. Working on this game has been a fun, infuriating, soul-crushing, uplifting, and highly educational journey, and I've got plenty of stories to share. Some of them may even be interesting.

If you've seen any of my YouTube videos or Mega Man fangame livestreams, you know that I harbor a special grudge against Joes—an iconic enemy type that has, in my estimation, long overstayed its welcome. Nothing sends the pace of a game to a grinding halt like a durable, shielded enemy blocking the boring hallway you're trying to walk through. There should be some obvious irony, then, in my decision to design a game centered entirely around Joes.

It all started in the wake of Mega Man Endless and the first Make a Good Mega Man Level Contest (MaGMML, for short), two fangames featuring levels with overly familiar configurations of overly familiar varieties of Joes. At the time, I was riding high on the exhilaration of designing publicly playable Mega Man levels for the first time in my life, and I was eager to create more. On May 17, 2016, I sent this message to Blyka and SnoruntPyro, the respective leads on Endless and MaGMML:

They tell you to start small when designing your first game. I had envisioned a short starting area introducing you to the different types of Joes, then a series of gimmick-driven challenges using Joes in unconventional ways, with an occasional branching path where you would choose one special weapon to add to your arsenal before proceeding. I recognized that programming anything from scratch would be a challenge, but I planned to keep the weapons simple and adapt as much code as possible from existing enemies. I was determined not to get bogged down by special features. "Maze of Death," my level contribution to MaGMML1, came together in 20 days; in my mind, this was just "Maze of Death" with Joes and a handful of new elements. In retrospect, there's no way OH JOES! was ever going to be just a single level, and there's no way it was going to magically come together in just a month.

In fact, it took about 4 months just to lock down the programming. I wanted to ensure everything essential was programmed and stable before starting work on the level design—and because I am not a programmer, I wanted the most onerous part of the project out of the way as soon as possible. Along the way, I scaled back the weapon roster, gave the player the Energy Balancer and all weapons by default, and ditched the helicarrier boss idea—which is totally going to be the final boss of HERE WE JOE AGAIN! (A Completely Unnecessary Sequel to OH JOES!) if I ever have a large enough lapse in judgment to do this kind of thing again.

With most of the technical prep (supposedly) completed, the next big step was the level design. I like to map everything out with placeholder tiles, adding real graphics toward the end of the process when the design is more or less final. For me, this keeps the focus on the gameplay, and it minimizes the wasted time and room for graphical error associated with repeatedly redecorating a level while it's constantly changing.

By the beginning of October, OH JOES! looked like this (click to embiggen):

Ostensibly, this was the framework for the final product: a linear intro section, followed by four pairs of split paths. The interior square in the top right was meant to become the boss chamber (replacement boss for the helicarrier still TBD at this point). This would've kept the game to 30 screens from start to finish—not including the alternate paths, which would still clock in under 50 screens—which is completely reasonable for a Mega Man stage.

The colorful Sheep block path in the middle was still in progress; I programmed the gimmick from scratch and was having trouble getting it to function properly in the scrolling section up top. Most notably, there was a Yoku block path in this iteration. Although I was pleased with how deviously evil it was to use these disappearing/reappearing blocks as an unstable bridge, a temporary cage, and an underhanded lesson about making assumptions, the whole path ended up being more mean than fun. On top of that, I kept getting stuck inside the blocks as they appeared, instead of being shunted to the side as is customary. It wasn't long before I swapped out the gimmick for the one ultimately used in the game.

I don't remember the exact thought process that extended the length of this project from a few more weeks to a year and a half, but I was having fun with the level design and had no shortage of ideas for new challenges. By mid October, the game had grown enough that it made sense to split it into two stages—one to introduce the Joes, and one to introduce the gimmicks. By early November, I was working on a third stage that combined pairs of gimmicks from the second stage. Admittedly, some of the pairings were awkward—I ran out of good ideas for combining Chill blocks with fake blocks after the first screen—but that's what happens when you stray from the design plan. I had selected those gimmicks because they were already programmed (or straightforward enough to program), not because I was thinking about smashing them together later.

By December, a fourth stage combining all gimmicks was underway. I was happier with the "sampler platter" approach of the fourth stage than I was with the "maybe these will work together" approach of the third stage—I even briefly considered cutting the third stage altogether. Unfortunately, math was not on my side here: 12 substages (one for each gimmick) times 12 screens each (one for each other gimmick being combined, plus an intro screen) plus hub screens connecting all the substages equaled 150+ new screens to design. The entire game was originally only 50 screens. So much for OH JOES! being "basically a glorified MaGMML level."

It took me until the middle of January (now 2017) to design something for all those new screens, and by then, I had found yet another way to make more work for myself. I'd finally gotten around to programming a final boss—a mech that broke off into a helicopter when destroyed, which dropped the Joe who stole your shield (who, now defenseless, would just waddle around the room until destroyed). Any normal developer would've been satisfied with that kind of boss fight, but I had let the gimmicks become as much of a focus as the Joes.

At the end of the fourth stage was a teleporter with a display overhead that cycled through pictures of all the gimmicks in the game. When you jumped in, you were teleported to a boss chamber featuring whatever gimmick was pictured. I only designed a handful of boss chambers before I realized that this idea was just not going to work. Too much clutter—not to mention that the helicopter portion of the boss fight was obnoxious, broken, and not really in line with the rest of the game's challenges. The boss fight was promptly revamped to be the simplified one seen in the final game.

It was April before I had tested and finessed my level design enough to feel comfortable applying real graphics to the game. Unable to leave well enough alone, I had also added Break Man as a second playable character, despite my initial resistance to special features—and despite the fact that I hadn't been designing the game with his unique abilities in mind. Multiple difficulty settings weren't far behind, but these were much easier to implement. What I consider normal Mega Man difficulty is actually hard for most people, so I just took the existing game and called it Difficult mode. For Normal and Easy modes, I gave the Joes easier attack patterns, removed some Joes in particularly tricky locations, and added safety platforms for the latter mode. Boom—multiple difficulties.

This is where OH JOES! crossed the boundary from "longer than originally planned" to "exactly the kind of overcomplicated game I was trying to avoid." I started spriting a third playable character in June. I added the Proto Shield and all its projectile-deflecting complications as a postgame bonus. I started sneaking in more and more Easter eggs, many of them almost too obscure to be worth the effort. And that's to say nothing of all the coordination I was doing with the composers, artists, programmers, translators, and playtesters who had become involved in the project. For months, I had thought about OH JOES! as this little solo side project, but that was no longer remotely the case by the halfway point of 2017.

I can't even begin to explain where the next 3/4 of a year went. That's when playtesting kicked into high gear and bug-fixing became a top priority—a lot of time was devoted to waiting for playtester feedback, watching people's playthrough videos, pulling my hair out at the sight of outrageous glitches I didn't know how to fix, retooling one thing after another in response to feedback, banging my head against the keyboard because I couldn't figure out how to fix something, and waiting on responses from the people I solicited to fix my game. The last 48 hours leading up to the game's release were spent replaying the game on different difficulties as different characters, fixing last-minute issues, re-testing everything to make sure nothing else broke in the process, and getting everything in order for the big announcement.

Now begins the long process of incorporating feedback from the largest group of playtesters I'll ever have. OH JOES! may be released, but it's almost like the project is just getting started again.