When a Game's Development Gets Canceled -Translation- (Hiroshi Matsuyama, Note.com)

Disclaimer: Following this article is a non-profit fan-translation, please support the original creator!

Source: Note.com

Author: Hiroshi Matsuyama

Original Post Date: July 24, 2021

Developing a single video game requires an enormous amount of time and money.

It depends on the project, of course, but these days it's not uncommon for a game to be developed by hundreds of people over the course of three, four, or even more years.

In terms of budget, development alone can easily cost several billion yen.

And yet, even games that were supposed to be brought into the world sometimes end up being canceled before they're ever released.

For most people, the reaction is usually something like:

"Wait, what? That game got canceled? Why all of a sudden?"

That's especially true when it's the latest entry in a well-known franchise or a title based on a famous IP.

So why does this happen? What causes a game's development to be canceled after so much time, money, and effort have already been invested?

In some cases, a game's development can be canceled even after it has already been officially announced to the public.

When that happens, the reason is often fairly straightforward: the game was nearly finished, pre-orders were opened, but hardly anyone placed an order, so the company decided to cancel the release altogether.

In other words, the lack of demand made it clear that the project would be operating at a loss before it even hit the market.

From an outsider's perspective, it's easy to think:

"Even if sales are low, wouldn't it be better to release it anyway and recover at least some of the money?"

However, selling a product also requires resources—time, manpower, effort, and ultimately money.

To put it bluntly, there are situations where a company chooses not to release a product simply to avoid increasing its losses any further.

This kind of decision is especially common among larger companies.

Those companies usually have other games in the pipeline, and their thinking tends to be: rather than spending additional time, effort, and money on a title that is already guaranteed to lose money, it's better to focus those resources on projects that have a real chance of succeeding.

Seen that way, canceling the game isn't necessarily a purely negative decision—it can be a practical and forward-looking choice about how to allocate resources where they'll have the greatest impact.

As I mentioned at the beginning, developing a video game requires an extraordinary amount of money, time, and effort. Because of that, projects undergo extremely thorough evaluation and scrutiny before development even begins.

Who will make the game? What kind of game will it be? Is there actually a market for it? How much profit could it generate if released? How realistic is it to successfully complete the project and bring it to market?

Questions like these are discussed over and over again, examined from every angle, and only after extensive deliberation are contracts signed and development finally allowed to begin.

Depending on the project's size and scope, this planning and evaluation phase alone can take anywhere from six months to a full year.

And yet, even after all those discussions, reviews, and preparations—and even after development has officially started—there are still cases where the decision is made to cancel the project.

In fact, many of these canceled projects never become public knowledge in the first place. Because they are often terminated during the development stage, before any announcement has been made, they simply disappear behind the scenes without anyone outside the company ever knowing they existed.

So why does this happen?

Why would a project that went through countless rounds of discussion and approval before contracts were signed end up being canceled anyway?

What kinds of situations lead a company to conclude that a game's development should be stopped altogether?

It would be nice if I could say that every game CyberConnect2 has ever worked on was completed and released without a single cancellation.

But reality isn't quite that kind.

CyberConnect2 has had projects that were canceled during development.

You might be thinking,

"Really? There were canceled projects?"

And honestly, that's a fair reaction.

After all, we've never talked about them publicly before.

In keeping with the theme of this article, I'd like to share some stories about those canceled projects from CyberConnect2's past.

Over the last 25 years, there have been roughly three projects that were either canceled outright or ended in circumstances that were effectively the same thing.

These three projects all came from different eras of the company's history and had nothing in common with one another. They were completely separate projects, and each one was canceled for a different reason.

Because of confidentiality obligations, I'll have to be careful about how I describe certain details. Rather than focusing on the projects themselves, I hope these stories can serve as lessons about what can be done to avoid ending up in situations like these.

To be honest, I suspect neither writing about this nor reading about it is going to be particularly pleasant.

So let's take it easy as we go through it.

When a Game's Development Gets Canceled

Even when we say a project was "canceled," there are actually several different ways that can happen.

Broadly speaking, they can be divided into three categories:

1. The project is canceled outright.
2. Development is transferred to another studio partway through.
3. The project is reworked under a revised contract and effectively becomes a different game.

Let's go through them one by one.

Pattern 1: Complete Cancellation

This is the kind of project that starts off vaguely from the very beginning.

By "the beginning," I mean the fundamental concept stage. To put it simply, it's the sort of arrangement where:

"We'd like to make a game together with CyberConnect2, but we'll figure out what kind of game it should be as we go."

Looking back, it's a genuinely frightening way to start a project.

After all, it means the extensive discussions and planning I talked about earlier never really happened before development began. Under those circumstances, it's hardly surprising that things don't work out.

Everyone may have a rough sense of direction, but nobody actually knows what the correct destination looks like.

As a result, whenever progress is reviewed, the only feedback tends to be:

"Well... at least it's not this."

Nobody can make a definitive decision because nobody knows what the final answer is supposed to be. It becomes a project where no one can confidently steer the ship.

It's a truly dangerous situation.

Time drags on without meaningful progress. Then, before long, information about next-generation hardware starts appearing, and suddenly people begin saying:

"Wait a minute. Is there really any point in spending another two or three years developing this for the current platform?"

And with that, the decision is made to cancel the project.

Pattern 2: The Development Studio Is Replaced Midway Through

I need to choose my words carefully here.

In truth, this situation is very similar to Pattern 1.

The project itself has been approved, but there is no clearly defined quality target. The guiding philosophy becomes something like:

"Let's just keep improving it and see how far we can take it."

When that happens, every review meeting ends the same way:

"Hmm... we can still raise the quality further, can't we?"

Because nobody ever establishes a concrete finish line, the team ends up digging a hole endlessly, never being told when to stop.

And the consequences are fairly obvious.

The development staff gradually become exhausted, both physically and mentally.

After all, they have no idea how long they're expected to keep digging.

No matter how many times they ask for clarification, the answer remains:

"Keep digging until we say it's good enough. We'll pay for it."

At that point, the problem is no longer just about money.

Simply put, people start leaving.

Some burn out. Some suffer mentally and decide they can't continue.

Eventually, the company reaches a point where it can no longer tolerate the situation.

Once enough people leave, the project becomes impossible to develop in practical terms.

So at a certain stage, the company says:

"We'd like to terminate this arrangement."

The project is halted, and development is handed over to another studio.

Pattern 3: The Project Is Reworked and Restarted

Strictly speaking, this isn't really a cancellation.

It's more accurate to call it a change in contract terms.

However, because the final product ends up being substantially different from what was originally agreed upon, the initial concept is effectively canceled all the same.

The circumstances behind this type of case can be quite complicated.

Sometimes licensing issues arise, or a company's business strategy changes dramatically midway through development.

Other times, development simply doesn't go well, and the team is unable to produce something that makes people confidently say:

"This is it."

There are also situations where a client looks at the project and says:

"It might become fun once it's finished, but honestly, I have no idea how we'd market or sell it."

When that happens, the response is usually:

"Let's stop for a moment and have a serious discussion."

Development is paused, and everyone reevaluates the situation.

The remaining time, budget, and manpower are weighed against the project's prospects, and eventually the conclusion becomes:

"Let's abandon the current plan and switch to a new one."

Looking back on these three cases (setting aside the specific circumstances behind Case 3), one thing becomes abundantly clear:

The beginning is everything.

Starting a project without a clearly defined direction is something you should never do.

And the core issue shared by these cases can be summarized as follows:

The Problem: No One Is Making Decisions

(Or the person who is supposed to make decisions refuses to do so.)

At this point, you might be thinking:

"Isn't that the director's job?"

Or:

"Shouldn't the producer just step in and say, 'This is the direction we're taking'?"

I completely understand that reaction.

However, depending on the situation, there are projects where the director or producer doesn't actually have final decision-making authority.

You might respond:

"What kind of nonsense is that?"

And honestly, that's probably the correct reaction.

The point is that you should never get involved in—or even start—a project structured that way.

If you discover after signing a contract that nobody truly has the authority to make final decisions, then it's the kind of project you should discuss ending as soon as possible.

Quite simply, it's a waste of time.

I say this now, but I do so with a great deal of self-reflection.

The only reason I can speak so plainly about it is because I've spent a long time looking back on mistakes we've made in the past.

It's not something I can talk about proudly. If anything, it's a source of embarrassment and regret—both then and now.

I wrote this article partly as a reminder to myself not to repeat those mistakes.

Of course, no matter how much we reflect on the past, we can't turn back time.

All we can do is learn from it.

If putting these experiences into words can provide even a little guidance or insight to some of the people reading this, then I'll consider it worthwhile.

Unfortunately, cases where game development is canceled altogether are not uncommon in the game industry.

That doesn't mean they should be common, of course—but they do happen.

Compared to many other companies, CyberConnect2's record of three canceled projects over twenty-five years is actually on the lower end.

There are companies that have experienced far messier situations, and some game studios have even gone out of business as a result of projects that failed in this way.

I'd like to avoid that outcome whenever possible, and I hope we can reduce these kinds of unfortunate situations, even if only a little. That's one of the reasons I decided to write this article.

To be honest, I believe that it's precisely these kinds of failures—the projects that didn't work out—that should be openly discussed and shared. If more people exchanged information about their mistakes and lessons learned, we could avoid repeating the same errors.

But in reality, that's rarely what happens.

Especially at larger companies, people are reluctant to talk about failures publicly. In many cases, those stories don't just remain confidential outside the company—they become restricted internally as well. Before long, the lessons aren't even being shared among employees within the same organization.

It's something I'd really like to see change.

So, I'd like to make a proposal to my colleagues across the game industry.

How about organizing a forum where we can exchange stories about projects that didn't go well—within reasonable professional boundaries, of course, and without violating confidentiality agreements?

To be fair, conversations like these often come up over drinks anyway.

But perhaps it's time to discuss them a little more seriously.

If we want a brighter future for the game industry, then we, as developers, should start by sharing information with one another and increasing the number of problems we can recognize and prevent before they happen.

If that idea interests you, please don't hesitate to get in touch.

Thank you for reading.