In honor of the fifth anniversary of the release of Klei Entertainment's Mark of the Ninja, we're publishing a digital version of this in-depth postmortem of the game, which first ran in the February 2013 issue of Game Developer magazine.

The piece was contributed by Nels Anderson, who was Mark of the Ninja’s lead designer, and Klei Entertainment founder Jamie Cheng. Klei has gone on to release Don't Starve, Invisible Inc., Don't Starve Together, and Oxygen Not Included (currently in early access.)

Mark of the Ninja originated from a simple concept: We wanted to make a ninja game where the player actually acts and feels like one. The only way to do that properly was to make a stealth game. But stealth games have a reputation for being a notoriously diffcult genre to work in, and we certainly discovered that said reputation was deserved. Furthermore, a 2D side-scrolling stealth game is something that had basically never been done before.

On just about every front—design, art, engineering, and sound—Mark of the Ninja pushed us beyond our experience. We had to find, often with no small effort, new solutions to the myriad challenges we faced. But by concentrating on the core experience we were seeking to deliver, and collaborating as a trusting, solution-focused team, we were able to produce a game that seems to have truly earned a place in the stealth canon.

Mark of the Ninja began as a two-minute concept video. Sixteen months later, we released the game on Xbox Live Arcade, with a Steam version following one month after that. In this postmortem, we will detail the largest things that made the game a success, as well as the aspects of the project that challenged us the most.

WHAT WENT RIGHT

1. Building on solid tech

Mark of the Ninja had one huge design risk: We had no idea how stealth gameplay would actually work in 2D. Had we also started our technology from scratch, we could easily have spent over a year in pre-production.

Thankfully, we had at our disposal the robust and proven pipeline of Shank 2, which allowed us to very quickly begin prototyping our ideas (many of which failed).

Having this mature pipeline ensured that the art team could work unfettered to create their amazing animation and background art without being bottlenecked by technology, or having to worry about fitting their work into memory.

In addition, we spent a large amount of time upfront designing our level-creation pipeline. In our previous projects (Shank and Shank 2), each level was meticulously hand-painted.

We built those levels using the painful, classic waterfall process of designing the level upfront, then blocking it out, then painting the level, then hoping to never change the level again, because doing so meant a costly repainting of significant portions of artwork.

We knew that Ninja would live and die by being able to iterate on level design, and to facilitate that we designed a toolset that would enable designers to quickly change the level without huge knock-on effects to the rest of the team. We invested months into building a robust texture-tiling system for the environment art and better preview tools, because we knew that building good tools would have a multiplicative effect on our productivity.

2. Playtesting early and often

One of our key decisions on Ninja was to have early and constant playtesting. Playtests were held twice a week, with candidates combed from Craigslist. We needed to constantly and consistently test our design assumptions with fresh players.

Over the months, we fine-tuned the process of receiving and acting on feedback, focusing not on implementing player suggestions, but trying to get to the underlying motivations that our design caused. This was key to our success as a stealth game: When players complained that the combat was not satisfying, we would ask why they were motivated to fight.

When players didn’t understand our tutorial, we slowly tuned our controls and subtle cues, rather than simply flashing the instructions with even bigger text. This ran the gamut from changing the positions of light sources to emphasize the light/darkness visibility mechanic, to adding a pair of props the player had to strike simultaneously to progress, to ensure they understood multi-target aiming.

The playtests also helped us tune some of our core visual feedback, which became the solid foundation of our game. From designing subtle animation cues for what would happen when the player pressed a button, to producing the vast environment art that needed to look both dark and clearly readable at the same time, we needed to watch new players fumble through our game in order to see it from the perspective of someone who hadn’t been playing Ninja every day.

Perhaps our only complaint is that we didn’t start our playtests early enough. We did do some playtesting with other local devs, but the game felt too rough to get what we wanted out of public playtests until about eight months into development. For future projects, we’re definitely going to figure out how to do playtesting even sooner, even if the builds are rather rough around the edges.

3. Great relationship with Microsoft

It’s hard to talk about publishers, because the bad news is immediately reported on, and the good news is largely dismissed as biased because the developer needs to preserve its business relationships. For our part, we’ve always worked incredibly hard to have a great, positive relationship with our partners, mostly because the alternative just isn’t any fun. Who would want to spend over a year in an adversarial relationship?

Our approach was to once a week give our producer at Microsoft Studios (Torin Rettig) the information he needed in order to determine our major risks, and discuss them with him over Skype.

This enabled both parties to turn what is traditionally a status update into a mutual problem-solving relationship, and indeed more than a few times he was able to clear platform-specific roadblocks before we hit them.

Microsoft was tremendously helpful, in everything from dealing with ratings boards worldwide to helping resolve certain TCR issues, which were all things a self publishing indie would have to deal with totally on their own.

The hardest part of the relationship was when both parties were wondering whether this game could actually be made. Indeed, for about six months, both Klei and Microsoft asked the question “Can this actually be done?” However, once we were over that hump, and we decided that the answer was yes, this is something special (even though there are still at least a dozen things that we don’t yet know how they will turn out), Microsoft put 100% trust in us.

Those who work with publishers probably understand that this is not exactly commonplace, and the mutual trust—that we could deliver and they would help—allowed us to focus on the task at hand. Crucially, the relationship turned what is usually a resource drain into a net positive, and I believe that is to the credit of both parties.

4. Polish and iteration time

Our game was first slated to complete in mid-April, and we ended up in certification at the end of July, making the game about three or four months over our original schedule. Having lived through the hell of crunching to hit a date for Shank, and missing some crucial polish time, we were adamant to not repeat our previous missteps and instead paid for the extension out of pocket.

The extra months allowed us to not only complete the game, but also to take a step back, and thoroughly playtest the complete experience from end to end.

Being able to do this, and understand that at this stage in the process we didn’t need to churn out assets but simply let the game simmer, afforded us the time and focus to make the small adjustments that took the game experience to the next level. We cut and edited cinematics, tweaked levels, adjusted controls, and even merged some items that we felt were too similar to each other.

The need for a holistic polish stage was a lesson we learned from our previous games, and we’re super glad that we listened to ourselves, and took the time to continue to iterate, right up to the end.

5. FOCUS ON CORE STEALTH PRINCIPLES, RATHER THAN GENRE CONVENTION

Early on in the project, we decided that being stealthy had four core elements: Observe, Plan, Execute, React. Our design decisions continued to come back to this core, and allowed us to move away from simply copying genre tropes to creating new ways to move the genre forward.

As there are very few examples of 2D stealth games, and there were even fewer when we began Ninja, we had no templates to draw from.

Instead, we ended up looking at the core experience that 3D stealth games provided, and really dug into how they are novel compared to other types of character-based action-adventure games. From this, we distilled what we believe makes stealth games interesting: player-centric systems, and intentional gameplay.

Stealth games thrive by placing the player in a world with a lot of interacting systems, and giving players the ability to approach situations as they see fit. They are fundamentally games about player choice. Encounters can be approached in a number of ways, all of which are valid. This was our gameplay target.

Once we had identified this, we were able to make design decisions that moved us closer to this goal, even if those decisions violated the conventions of the stealth genre. For example, most stealth games have being hidden as an analog state, where a light gem or some similar mechanism will convey a spectrum of concealment. In Ninja, stealth is totally binary. Either the player is hidden, or the player is illuminated, and that’s it.

We made these kinds of design decisions throughout Ninja and it ultimately ended up creating an experience that feels like a stealth game, even though it differs in a lot of significant ways from 3D stealth games that came before it.

WHAT WENT WRONG

1. INITIAL LACK OF FOCUS

Early on in development, we tried a lot of stuff. We had grand ideas of multistep elaborate cause-and-effect chains, where fire could propagate and enemies would react to every situation intelligently, and differently. We did this for a few months, and actually made significant progress in many of the systems.

But the problem was that none of it was any fun. About four months in, it was apparent that we still didn’t have a clear idea of what the core game experience was going to be, and we needed to head into production if we were to complete the game on time.

In the summer of 2011, the team regrouped, and we spent the next two months in an intensive deep dive to find the core. We did this by creating level after level to test what designs were actually creating interesting decisions for players, and soon determined the core mechanics that were essential to our experience.

As a result, we ended up wasting large amounts of art and animation as we drastically changed the direction of the game over a few short months. Although we eventually found the essence of the game, it caused many knock-on effects (further explained below), and we began to worry whether the game we envisioned could be made at all. We fully believe that the iterative process could have been significantly sped up and resulted in far less wasted effort.

2. STORY CAME LATE IN THE DEVELOPMENT CYCLE

Our initial lack of focus, and the subsequent rush at the end of preproduction, had huge knock-on effects during production. It was only after the level iteration that we decided on shifting from light storytelling to a full-on story with plenty of cinematics, and we had not planned for the resources we needed to animate that story.

Worse, at this point we still had no script, and even once it was written it was still subject to change based on gameplay. So we scrambled to hire contractors and organize the script, storyboards, and scene—all of which became a daunting task. It’s a huge testament to the art team that we were able to create our highest quality animation in such a short time span.

We’re mostly happy with the story delivered (with one caveat, see 5), but there were defnitely times where we would have liked to change something but knew we simply didn’t have the flexibility in the schedule anymore to do so.

3. NAILING DOWN CERTAIN MECHANICS LATE

Since we figured out Ninja's core concept rather late in development, the advanced mechanics had to come even later still. We had written down what we felt the late-game mechanics would be, but we had no idea if they would work, and indeed many of them turned out to be duds.

For example, the last major ability the player receives is a short-range teleport. There were two other mechanics that we tried: an air-dash and a time-stop. These both required a significant investment in programming, art, design, and testing, and were testable only a few months before we shipped.

Once we tested those abilities, we discovered they just weren’t fun within the context of our game. Scrapping them after so much investment so late in the process was difficult, but we had to put the quality of the game first. Many games fall apart in their final act (probably for similar reasons) and we didn’t want to make the same mistake.

The teleport ability that we shipped in Ninja was only implemented two or three months before we went into certification, and its implementation required designers to rework the level design to utilize it effectively.

4. DESIGN CRUNCH

Largely due to the issues mentioned above, the design team ended up having to put in some major effort late in the project. Although we nailed the level design, many of the later design elements were still in the nascent stages of development. And even though we invested plenty of time in developing our tools, they were not initially meant for the large, sprawling levels that we were now designing, and the giant levels ended up taking minutes for an incremental change or up to an hour for full exports, causing considerable slowdown in design.

Beyond this, Ninja is a game that lives or dies by its polish and precision. Moving a single light a couple tiles in one direction can transform an encounter from dull to interesting. An encounter having four guards when space only really supports three can take the situation from challenging and interesting to basically impossible. But having never made a game like this before, a lot of these lessons had to be learned in the trenches, trying many different things until they gelled.

The design team had the daunting task of creating levels while some mechanics were still in flux and the story was rushing in. Although every department felt the effect of pre-production sneaking into production, it was the design team that took the brunt of it, and the last six months of development were especially hard.

5. STORY PLAYED TOO STRAIGHT

Even though we determined that Mark of the Ninja would have a more traditional story structure, we still wanted the narrative to be ambitious and unique. However, we also felt that we didn’t want to overwhelm players with a complicated, unfamiliar narrative right from the outset, especially considering the game has a lot of mechanical and systemic novelty players must also understand. So we opted to play the story very straight at the outset and let the complexity and nuance come in about halfway through the game.

What we didn’t realize was that some people would see the seemingly simple setup—a rote revenge story—and assume that’s all there was. By the time the complicated and nuanced aspect of the story began to unfold, we’ had already lost a portion of the audience plot-wise and couldn’t get them back.

Now we don’t think this was a complete failure, as we have heard from a number of people that they were very pleasantly surprised by the narrative in NINJA and how it turned out to be far more than they expected. The ending especially was praised by a number of players and critics alike. But this certainly wasn’t the proportion we intended, and it became something we will certainly be mindful of in any future projects that have a narrative component.

GO NINJA GO

Mark of the Ninja was, without question, Klei’s most ambitious project to date. It was also the game that proved, albeit not without some growing pains, that Klei can successfully work on more than one project at a time. Ninja provided an opportunity for a great deal of the team to grow and gain valuable experience, as the team was a combination of Shank veterans and developers new to the studio.

Our guiding principle is that we believe we can walk the walk: We can create a great game without sacrificing our lives and borrowing from the future, and we work together to find solutions to the challenges posed by creating new and different games.

Despite, or possibly because of the challenges, the game is one we are all tremendously proud of, and it has been extremely well-received. A number of people we trust commented that Mark of the Ninja is Klei’s breakout game, and given what we learned creating it, we certainly intend to do everything we can to make that true.