Sneaking into Stealth

May 20, 2016

It was not quite a month ago when I first announced project Stealth, one of my upcoming game dev projects. As I mentioned then, I knew that Stealth would be “a narratively strong game that follows the story of two modern day thieves as they pull off different heists.” However, I wasn’t sure exactly what the game was going to be like. There was a lot up in the air in terms of the balance of story, stealth, puzzle solving, and other aspects. And while I haven’t locked all of that down yet, I have a much better understanding now of the “shape” of this game.

In my professional career I’ve done a lot of software design. I’ve worked in both waterfall and agile design methodologies and have written a lot of design docs in both. However, my preferred way of exploring a software problem space has always been to jump in and get my hands dirty with code. To be sure, you can figure out a lot of design “stuff” by introspection, that is sitting back and thinking about all the requirements you have. However, there’s a point of diminishing returns with this sort of theoretical design. To move beyond it, you either have to spend a lot more time thinking about the software or else you can start to do some programming. No approach I’ve used has ever revealed as much about how a software problem should be solved as actually attempting to solve it in code. That’s when all the little details that could trip you up really come to light.

So, I’ve been doing some significant development on a prototype level for the full game that I’m planning. The most beneficial decision I made early on towards this end was to use the same game tech I had previously developed for the Sleuthhounds series of computer games. To be sure, Stealth is a very different game from Sleuthhounds and yet it still has the same fundamentals of needing to render graphics, play sounds, manage game states, et cetera, et cetera. It’s also similar to Sleuthhounds in that both make story a strong component of the gameplay. So a lot of the tech involved with having characters move about, say things, and do things was pretty well directly transferrable.

Working on Stealth to this point has also been similar to working on the first Sleuthhounds game. When starting on a new type of game it’s important to work out the different technological systems that will power that game. For Sleuthhounds these were basic systems like making characters walk, making characters say lines, being able to pick up items, and so on. With Stealth, as I mentioned, a number of these apply as well. Having the work of Sleuthhounds already implemented has catapulted development of Stealth forward very far very fast. However, Stealth also brings in a bunch of new systems of its own.

In Stealth the player will take on the role of a computer hacker guiding a cat burglar on their joint heists. To accomplish this, the player needs a number of game systems that resemble actual computer software. The player’s main view on the game world is through a series of security cameras. So the player needs the ability to switch between cameras, to rotate and tilt cameras, and to zoom cameras.

The player also needs a system by which they can suggest to the cat burglar where to go and what to do. So some sort of navigational system was needed. And some way to identify parts of the environment that could be interacted with was needed.

Of course, it wouldn’t make for very interesting heists if there was no opposition. So that meant adding guards into the prototype level. And those guards needed some sort of system to control their behaviour. Something that would allow them to wander around on patrol, or chase the cat burglar if they spotted her, or escort her out of the building to the waiting police if they caught her. And to make the guards humanistic there needed to be a way to allow guards to meet and chat with each other.

Each of these different tasks, whether for the player, the cat burglar, or the guards, required its own technological piece in the game. It’s fairly easy to take any one of those pieces and from a high-level design point of view work through ideas on how that particular piece should work. The tricky part is when you start pulling all those pieces together and you see how they interact. For example, suppose the player has directed the cat burglar to a door that she can pick the lock on. Now suppose the guards spot her while she’s en route. The guards give chase, but how does the cat burglar respond? And what if the player then does something to distract the guards, like setting off a fire alarm? How do the guards respond to that distraction? How does the cat burglar take advantage of the time it buys her?

In developing a new type of game there are a lot of basic systems that have to be put in place. Pieces that just take time to write. The interesting part of the game then starts to develop when you see how those pieces interact with each other. It’s important to get those fundamental pieces right early on in development because they form the technological bedrock on which the rest of the game technology is built.

At this point, I’m getting very close to having a first pass done on those fundamental pieces. The prototype’s in a state playable by me and I’ve been finding it enjoyable. I’m not at the point where I can start to tweak the balance of the gameplay to get the experience that I want to deliver just right. I anticipate another week, perhaps two, to have the prototype at a point where it will be playable by others. That will for sure bring another large round of enhancements, improvements, and other tweaks to the tech based on people’s feedback and how they play the game. But that’s a subject for another blog.