[MM#27] Starting Development on Mega Man2 (Patreon)

Less Than Three Months of Development

As soon as development of the NES (overseas) version of Legendary Wings was completed in early spring, we had meetings with Lucasfilm, and then I immediately began planning the Famicom version of Willow. The project was originally scheduled to continue as planned and be released sometime in the early part of the following year. However, once I decided to insert the planning for Mega Man2, a number of those schedules had to be rearranged.

On top of that, Mega Man2 was now expected to launch during the year-end holiday season. Even if we started immediately, we had less than three months to complete it—an unbelievably short development schedule.

It was entirely my own doing, but I still had to make sure the staff wouldn't bear an unreasonable burden because of it. I could never ask everyone to suffer through my selfish decision.

My highest priority was therefore to create a schedule that allowed the team to work efficiently, without wasted effort, and within reasonable limits. At the same time, I had to prepare design documents that were complete enough for everyone to begin working immediately.

The first decision I made was to ban overtime.

At the time, both CAPCOM's arcade division and consumer division had many teams working overtime because their schedules had fallen behind. The staff were all young and simply relied on their stamina to keep going.

I had also spent countless nights sleeping at the office while working on Trojan and the original Mega Man. Part of that was because I was still a newcomer and had to learn unfamiliar tasks, but I often found that those long hours affected my work the following day. There were also times when I pushed myself too hard and became ill. From my experience, I didn't believe that kind of working style was actually very efficient.

With such a tight schedule, if even one staff member became sick, or if productivity dropped after an overnight work session, the entire project could easily fall seriously behind.

That was why my first priority was to create an environment where everyone could continue working steadily until the very end without interruption.

Banning overtime meant that everyone's working hours became fixed, which naturally limited how much work could be done each day.

To make those hours as productive as possible, I divided every task into daily goals and made it absolutely clear what needed to be completed each day. For sprite graphics, for example, the goal was to finish one object per day—whether it was a large enemy, a small enemy, or an item.

Graphics for the 8-bit Famicom didn't require nearly as much time to create as graphics for large arcade hardware.

Completing the main sprite along with several animation patterns was generally enough, so the workload wasn't unreasonable. I used the same approach for the background graphics, dividing the available workdays between the first-half stages and the later stages to determine how much time could be spent on each one.

The reason I was able to plan everything this precisely from the very beginning was that I wasn't changing the basic system established in Mega Man.

By that point, the total number of stages had already been decided, so even estimating generously, the number of large enemies and small enemies that would be needed remained within realistic limits.

The one thing that couldn't be scheduled so neatly was designing the characters themselves.

No matter how clearly I explained a character's concept and role, creating a fitting visual design wasn't something that could be measured simply by workload. To solve this, I did the same thing I had done for the original Mega Man: I attached a simple rough sketch to each character design sheet, alongside the specifications describing its movements, attacks, and abilities.

The artists then continued using the character design approach we had established during Mega Man, using my rough sketches as visual references while creating the final designs.

Eventually, I no longer even needed to draw those rough sketches, and yet the team continued producing one appealing character after another.

Even if someone couldn't finish their assigned work for the day, I still insisted that they leave at the scheduled time.

Based on my own experience creating sprite graphics, I believed the daily goals were achievable. Any unfinished work would simply be incorporated into the following day's schedule.

Of course, that also meant that falling behind would require finishing two characters the next day instead of one.

It may sound strict, but I believed our working environment was better organized than any other team in the company.

From there, everything depended on the staff's ability to stay focused.

To me, efficiency has always meant creating an environment where people can concentrate on their work continuously. There simply isn't time for constant breaks or idle conversations.

Even today, I still believe that simply spending more time because you couldn't finish something is one of the least efficient ways to work.

The Purpose of the First-Half Stages

After creating Mega Man, I came to understand many things that I hadn't fully realized during its development.

The most important of them was the relationship between two mechanics: obtaining weapons from defeated enemies, and allowing players to freely choose the order of the first-half stages.

Both of these ideas had originally been introduced independently as solutions to problems I had identified in Ghosts 'n Goblins.

However, once combined, they complemented each other perfectly and created an entirely new style of gameplay.

That synergy became the very thing that defined Mega Man's originality.

There was no doubt in my mind that expanding this core concept would be the key to evolving the series.

The problem was that there simply wasn't enough time.

I needed to settle on concrete game design decisions immediately.

For that reason, I left the overall game structure unchanged: eight selectable stages in the first half, followed by several stages in the latter half.

The short development schedule certainly influenced that decision, but more importantly, I believed this structure was exactly where Mega Man's unique appeal came to life.

What needed to change instead was the design of those first-half stages.

In the original Mega Man, I felt that this part of the game was rather unfocused. Even while playing it, something about those stages felt strangely at odds with the game's otherwise distinctive system.

I eventually realized that the problem lay in the difference between conquering a stage and simply reaching a destination.

In traditional stage-based action games, the objective is to conquer the stage itself and defeat the boss waiting at the end.

In Mega Man, however, the true objective is simply to reach the boss and defeat it.

To put it another way, the game could almost function even if the stages themselves disappeared and only the bosses remained.

So why did the stages feel uncomfortable?

Because players couldn't fully enjoy the gameplay that took place along the way.

The goal wasn't to clear the stage itself—it was to obtain the boss's weapon.

From the player's perspective, everything between the start and the boss simply became an obstacle.

Even if a stage contained clever and enjoyable gimmicks, being held up for too long would cause frustration before the player ever had the chance to appreciate the challenge.

That feeling became even stronger in simple stages where all you did was shoot small enemies.

In conventional action games, progressing through the stage is itself the objective.

But when the real goal is obtaining the boss's weapon, players naturally want to reach the boss as smoothly as possible.

Simply making the stages easier wasn't the answer.

Instead, I began wondering whether this very piece of player psychology could be turned to our advantage.

If we could make clever use of that mindset, perhaps we could create stage designs that were uniquely suited to Mega Man.

Stages and Gimmicks

The concept behind Mega Man was to create an action game that players would want to play over and over again. That philosophy remained unchanged in Mega Man2. To achieve that, however, the stage design itself needed to evolve. The stage structure of Mega Man1 had left me with a lingering sense of inconsistency, so I decided to revise it extensively.

My new philosophy for stage design was as follows:

The stage itself should be fun.

It should never be easy.

Players should want to reach the boss without feeling unpleasant frustration.

It should make them want to try again and again.

Could such a seemingly contradictory stage design really be possible?

To answer that question, I broadened my perspective and began thinking about how the first-half stages should relate to the later stages.

In Mega Man1, the latter half consisted of several final stages that players tackled only after obtaining every weapon. In that sense, it served a role similar to beginning the second loop in Ghosts 'n Goblins. There was, however, one important difference. Ghosts 'n Goblins is fundamentally designed around a first-time playthrough, whereas the latter half of Mega Man can be viewed as an advanced application of what players learned in the first-half stages.

I realized that this relationship was what gave the first-half stages their true purpose.

Any brand-new gimmick naturally raises the game's difficulty simply because players have never experienced it before. If such mechanics first appeared in the latter half of the game, players would suddenly feel that the difficulty had spiked unfairly.

Instead, I designed the first-half stages around distinctive new gimmicks so that players could learn each one there. Then, when similar mechanics appeared later, they would immediately understand how to deal with them.

I wouldn't go so far as to call the first-half stages tutorials, but they certainly served a similar purpose.

At the same time, those mechanics couldn't become stressful. They needed to be enjoyable enough that players would want to challenge them repeatedly.

That led me to establish a simple policy shared by every first-half stage:

One Stage. One Gimmick. One Try.

In other words, each stage would focus on a single core gameplay idea, with just enough content for players to understand that mechanic through one complete attempt.

I've always believed that making a game interesting requires making it challenging.

When people say, "It's not fun because it's difficult," I believe that's not quite true. What they really mean is, "It's not fun because I can't clear it."

That's a philosophy I arrived at through my own experience.

The sense of accomplishment that comes from overcoming repeated trial and error is directly proportional to the challenge itself.

The gimmicks in the first-half stages were designed specifically to create that feeling of accomplishment.

This approach wouldn't have worked in conventional action games. It was only possible because of Mega Man's unique game structure.

In that sense, this stage design truly became the embodiment of the series' originality.

In Mega Man1, we had to cut two of the planned first-half stages because of memory limitations.

That couldn't be helped, but I worried that removing them would throw off the game's overall pacing and total playtime. To compensate, I artificially extended stages such as Cut Man's and Bomb Man's by redistributing their content, which unfortunately resulted in unnecessarily long stages that served little purpose.

Looking back, my understanding of the role of the first-half stages simply wasn't mature enough.

I used that mistake as a lesson, and the stage design in Mega Man2 was built on an entirely different philosophy.

Every first-half stage in Mega Man2 is relatively short.

That's because each one is centered around a single gameplay gimmick that players can experience repeatedly.

"If only I hadn't made that mistake there, I could have made it through!"

"If I can just get past that one section, I'll finally reach the boss!"

Those stages were designed to create exactly those kinds of feelings.

Developing Willow

The team that had developed the NES version of Legendary Wings continued directly into development of Willow.

We worked in a small room partitioned off in the corner of the floor—just large enough to fit six or seven desks. That's where I worked alongside the graphic artists and programmers.

Meanwhile, the staff assigned to Mega Man2 remained at the desks of their respective teams.

They had already begun creating several versatile small enemies that could be used across multiple stages. As for the backgrounds, before anyone started drawing pixel art, we first had to calculate the available memory and determine how many characters could fit on screen, adjusting the amount of detail accordingly.

We also needed to establish the design direction for Willow as quickly as possible.

At that point, however, all we really had was the vague image of "an action game with RPG elements."

For the time being, we decided on the number of stages, their general atmosphere, and the scale of the player character, Willow, and immediately began production.

Since the game would use a top-down perspective, we first experimented with different approaches to drawing backgrounds while balancing them against the available memory.

Unlike Mega Man, however, Willow couldn't truly begin until the scenario was complete.

Back then, there were no dedicated scenario writers at CAPCOM, so I would have to write it myself.

The problem was that I had never written a game scenario—or even a short story.

Before I could begin, I first needed to learn how such stories were constructed by studying other games and whatever reference materials I could find.

Bookstores carried magazines devoted to film, television, and stage-play screenwriting, but there wasn't a single book explaining how to write scenarios for games.

That's when I remembered Jesus, an adventure game I had played in the room of my colleague M.K., who had joined CAPCOM at the same time I did.

What I wanted to learn wasn't how to write sentences—it was how to structure a story.

Willow is, at its heart, a tale of an adventure toward a distant destination.

If I simply followed the movie's storyline exactly, I felt the game would become rather monotonous.

The real challenge, I believed, was how to establish a strong central narrative while arranging branching events and foreshadowing around it to keep the journey engaging.

This wasn't something Lucasfilm had specifically requested, but I had already decided that, even if I adapted the story for a game, every major character from the film would still appear.

In the movie, Willow never fights with a sword or shield.

In the game, however, I wanted him to stand proudly as the hero of a classic fantasy adventure.

That was the one point I refused to compromise on.

However, I had no idea that the task of writing Willow's scenario would later confront me as an unimaginable trial.

(Automatic translation by AI)