Stealth in 2D: Design lessons from Mark of the Ninja

How do you make a 2D stealth game? In the postmortem for the February 2013 issue of Game Developer magazine, Klei devs explain how they adapted core stealth principles to work in a new environment -- and some of the design challenges that came up in the process. Here are some choice extracts from the postmortem:

What went right: Focus on core stealth principles

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: 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.

More in the February issue

The February 2013 issue of Game Developer magazine is now available via subscription and digital purchase. This issue also features an in-depth look at designing better touchscreen controls, a collection of interviews with triple-A free-to-play developers, and more. You can subscribe to the print or digital edition, download the Game Developer iOS app to subscribe or buy individual issues from your iOS device, or purchase individual digital issues from our store.