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 part