[MM#04] Moving from Graphics to Planner (Patreon)

When the ROM production for the arcade game Tatakai No Banka (TROJAN) was completed and things settled down, the company decided to expand production capacity by significantly increasing the number of planners to manage the growing number of development teams.

Today, we call those roles producers and directors, but at the time they were simply called “planners.”

It had been more than eight years since the appearance of Space Invaders by Taito in 1978, and arcade games had continued to evolve. Still, compared to today, memory capacity was small, and because these were commercial-use machines, you didn’t see realistic art design or cinematic presentations that followed complex storylines. Play time directly impacted sales, so to increase turnover, games had to start the moment a coin was inserted and end within just a few minutes.

Planners were responsible for conceiving and designing those products and managing the development teams, essentially serving as the person in charge of product development.

Becoming a planner was voluntary. Even though I felt a little anxious about stepping into an entirely unfamiliar role, I raised my hand without hesitation. It felt like the best choice to clear away the vague frustration I’d been feeling about game development. And so, a few days later, I transferred from graphic designer to planner.

Right away, I was told to submit a proposal as practice. I had never written one before. There was no internet at the time, so I went to a bookstore to look for books explaining how to write proposals, but I couldn’t find anything specific to computer games.

I had no choice but to try writing one in my own way. Looking back, it was more of a setting document than a true proposal. If I recall correctly, it was for a vertical-scrolling shooting game. As a new feature, I had an idea where the player would rescue captured people. If you attacked an enemy base on the surface and hit it, you could infiltrate underground facilities, and once inside, the stage would shift to rescuing captives by destroying buildings where they were held.

Thinking about it now, it was the kind of idea everyone comes up with early in game development—adding new gameplay elements to an existing system to give it a feeling of originality. That approach isn’t entirely wrong, but adding features without a clear purpose can make gameplay messy and cause the program size to explode.

Because I had played arcade games since I was a student, I had an unfounded confidence in coming up with game ideas. But once I tried creating one myself, I realized how difficult it really was. The thing that struck me most was how many elements were actually needed just to set up the basic rules. There were so many things I hadn’t noticed when I was just playing, like having to account for every possible situation in which a player could lose a life.

Unlike movies or anime, games are interactive—the player controls the character. That’s obvious, but it means there isn’t just one fixed story on one timeline; player actions can change the flow infinitely. You have to consider all of those possible developments when designing a game. For me, it was a completely different kind of creative process. The more my imagination expanded, the more gameplay elements I kept adding.

The feedback I received on my proposal focused mostly on those gaps. Things like, “What happens if the player goes to the far right edge instead of the center here?” or “If the player dies during the rescue stage, where do they restart?” Every gameplay idea spawns several related settings that all have to be addressed.

They were right, of course. But patching those holes with new rules just created even more settings to support those rules. I started to think the only solution was to rethink the entire concept from the ground up. I had put high hopes into that proposal, only to run headfirst into a wall that I couldn’t even fully understand.

One day, while I was making coffee in the break room, someone who joined the company at the same time as me, M.K., came in. He worked in a different development room, so we didn’t often talk, but for me, he was an important person.

That’s because, even though I liked manga and anime, I had spent my school days completely focused on sports and had almost no knowledge of media or digital content. After joining the game company, I realized something: I didn’t know anything about the world of subculture.

Sure, I had played plenty of games in arcades, but beyond that, there were entire worlds I didn’t know about, like PC games and tabletop games.

M.K. knew a lot about manga, anime, and games. If I was the athletic type, he was the cultural type. To tell a slightly embarrassing story, when I was drafting that practice proposal, I didn’t even know how to describe the speed of the player’s ship, so I measured the distance on a tabletop cabinet monitor with a ruler in centimeters. He laughed and told me about pixels.

Even so, he kindly explained things to me, like how characters were displayed via programming and how memory capacity worked. From then on, he became someone I really depended on.

“Did you already submit your proposal?” he asked, opening the kettle lid to check the water level. Steam immediately fogged up his glasses completely.

“Yeah. It was a disaster, though.”

“What kind of feedback did you get?”

“Oh, all sorts. They said it was nowhere near ready for commercialization.”

“Well, same here. I’ve never written a game proposal before either,” he said, taking off his fogged glasses, shaking them lightly, and blowing on them before putting them back on.

“How about you?”

“Not done yet. Gonna take a little more time,” he replied, scooping instant coffee into his personal mug.

I was curious what kind of game he was planning, but I figured it must be far more impressive than mine, so I hesitated to ask. Still, seeing his slightly serious expression made me want to hear his thoughts on my game.

“It’s a shooting game,” I began.

“Mm-hmm.”

“When you pick up a power-up item, your ship changes shape.”

“Transforms, huh?”

“Yeah. And it always shows what power-up you currently have.”

“I see.”

“Then when you pick up another power-up, it swaps out the one you had and changes form again.”

“So you can only hold one power-up at a time. Like the weapon system in Ghosts ’n Goblins.”

“Right. But as I kept adding power-up types, the number of ship forms increased, and while it seemed like a good idea at first, it got to the point where distinguishing all the different ship shapes became confusing and counterproductive.”

“So, in chasing gameplay ideas, your visual concept ended up working against you.”

He said this, sipped his coffee, and once again his glasses fogged up.

“Yeah. But I can’t exactly cut down the number of power-ups either.”

“That reminds me of KAMEN RIDER,” he said suddenly.

“Huh?”

“You know, the white stripes on the Rider suits.”

“Oh, you mean how Rider 1 has two stripes and Rider 2 has one.”

“Exactly. Rider 2 was created suddenly because of issues with Rider 1, and to give it a brighter image, they redesigned the suit.”

“Yeah, the early episodes had a stronger horror vibe.”

“So when Rider 2 appeared, it had one white stripe the original Rider didn’t have. But then when Rider 1 returned, they updated his suit to match Rider 2’s brighter colors.”

“And added two stripes.”

“Right, so visually they looked similar, and the two stripes were just to tell Rider 1 apart.”

“I actually started watching from Rider 2, so I was always confused. Later they tell you ‘the one with two stripes is Rider 1 and one stripe is Rider 2,’ but it just didn’t click.”

“Yeah, that was all the creators’ convenience.”

“The creators’ convenience, huh…? Oh!”

When he said that, something lit up deep in my mind. It felt like a faint light shining through the fog.

I rushed back to my desk, still holding my mug, and pulled out my practice proposal. I’d read it over and over before, but now I was seeing it in a completely different way.

So that’s it. I had been thinking about games not as a creator, but from the perspective of someone playing them!

I had assumed that all the games I’d played and all that experience would naturally lead to good ideas. But all that memory was from a user’s perspective—it didn’t include the core structure of how games are built. I was stacking my ideas on top of existing designs I had seen as a player, which naturally created contradictions. And because I hadn’t built the base structure myself, I couldn’t even fix them.

My proposal now looked embarrassingly crude. But as I read on with that mindset, everything started to make sense. It was like putting the pieces of a scattered puzzle back together.

That night when I got home, I decided to rewrite the proposal from scratch. It wasn’t for anyone else to see; it felt more like a personal ritual. And I felt like something new had just begun.

Looking back, I realized this also explained what had happened with Ghosts ’n Goblins. Changing gameplay on top of a finished design only creates contradictions. The marketing department’s requested changes were based on a user’s perspective, and layering user-facing ideas on top of a completed system only breaks it—it will never make it better.

That’s where the difficulty and fun of game design lie. The game I thought was just within reach felt far away again, but now I could see the path to get there stretching out in front of me. And I had taken my first step down it. I felt a rush of excitement and anticipation.

Then one day, I was finally given my first official assignment as a game planner. But it turned out to be a task I had never expected.

(Automatic translation by AI)