Brandon Dillon is the project lead on Double Fine's Hack 'n' Slash.
Double Fine has this great prototyping process called Amnesia Fortnight.
It’s a two-week period where everyone in the company forgets what they were working on and builds prototypes of new ideas. The ideas come from anyone in the studio; the majority of people in the company wind up pitching ideas every Fortnight. The process started during the development of Brütal Legend, but 2012 was the first year that Double Fine conducted Amnesia Fortnight in public.
That year, I pitched an idea for a game called Hack ‘n’ Slash. I’d been thinking about my love of classic, largely impenetrable action adventure games -- the kind you’d learn new secrets about through playground rumors and successive monthly issues of video game magazines. In particular, I’d been thinking about the peculiar way I came to enjoy these games.
I had a profound experience in my youth when I discovered emulators -- some emulators had tools that allowed me to search and modify the memory of the game, allowing me to negate any challenge the game presented and, more importantly, uncover the secrets hidden in the depths of the game’s code.
It triggered my love for the inner workings of things, seeded an interest in hacking and reverse engineering, and set me upon the path to become a game developer.
Screencap from a video we shot demonstrating how to hack my favorite NES game
Hacking these games was a deeply empowering experience. Hacking carries a stigma because of the harmful ways it can be used, and so hackers and reverse engineers tend to be secretive, mysterious figures, and the work they do seems from the outside to have a magical quality. In reality, though, reverse engineering is about as grounded as you can get: It involves looking at the inner workings of a machine, understanding the function of each individual component, and figuring out what everything does in concert.
The result of a hack may appear fantastical, but the process of hacking is about finding secrets and developing deep understanding, and it’s a rewarding and empowering pursuit that I’ve always wished more people could experience.
I’d wanted to make a game that taught the basic principles of reverse engineering for a while, but a concrete idea finally crystallized when playing back through The Legend of Zelda on the NES. I was struck by the similarities between hunting for secrets in an undirected open-world game and hunting for secrets in a big block of machine code you’re trying to reverse engineer, and hit upon the idea of marrying the two: An open-world exploration game about reverse engineering.
That was the core idea behind Hack ‘n’ Slash. I was really concerned about pitching it to the public, though. I assumed it was a way-too-niche, way-too-personal idea, but to my genuine surprise, it received more votes than any other pitch that year, and I started to gain some confidence that my interest in this stuff wasn’t just a weird personal quirk but something that other people could get value out of as well. I got to put together a team to make a prototype, and we then got funding for a full version from a group of investors led by Indie Fund.
Here’s how it went.
Double Fine’s prototyping process has lots of benefits; two weeks is just enough time to surmount a hard technical challenge or build a proof-of-concept version of a complicated piece of content, but it’s not enough time to meander or build things that aren’t critical to realize your idea. And you don’t need to build things to last -- you can build the thing that works just well enough to illustrate a concept. It’s a great method for taking and evaluating creative risks.
And, in the specific case of Hack ‘n’ Slash, it was a great method for testing different ways to recontextualize hacking mechanics. We tried three different core mechanics, and each taught us a lot.
The first environment concept for the prototype
The first was a treatment of a common emulator feature: savestates. Alice, the protagonist, carried a laptop around with her that she could use to checkpoint and restore the entire state of the game. It was designed to make it quick and easy to checkpoint the game and try an encounter from multiple approaches, but it didn’t feel like a unique mechanic; it just felt like a really thorough save system. It also wasn’t as powerful as a traditional emulator save state system; you only had one slot to work with, and restoring an earlier state accidentally was a frustrating and recurring problem.
The second mechanic was to represent the game’s data structures literally as places you could walk around inside of. In the prototype, there’s a library where every book is a file in the game’s file system, and every staircase leads to another directory. The library was underutilized mechanically and needlessly obfuscated with a symbolic substitution cipher obscuring the names of the directories and files, but for the subset of players who figured out the structure, it was an extremely compelling realization.
Hacking a guard’s variables in the prototype
The third mechanic was a USB-style cable you could throw out like the hookshot from the Legend of Zelda series. When it hit an enemy, you’d get a list of the enemy’s variables and the ability to tweak them however you liked. This was by far the biggest success of the prototype; it gave players a lot of ways to experiment, felt like real hacking, and created opportunities for self-expression.
Monsters spitting an inescapable stream of fireballs? Hack them so that they don’t spit fireballs anymore. Or hack them so that they spit a different pattern that you can traverse. Or hack one so that it spits one giant fireball that hits the other monsters and clears the map. It was clear that this mechanic had legs, and became the basis of the design for the full game.
The two week prototype allowed us to test other development strategies as well; for example, we built the prototype with a tiling system, thinking we’d get an interesting aesthetic out of high-resolution tiles. Constructing nice scenes out of high-resolution tiles is very difficult to do well, though, and we missed the flexibility of just painting nice environments. It was an instance where we had to learned not to just adopt every convention of the retro games that inspired Hack ‘n’ Slash, which was an important lesson for us to learn early.
And, perhaps most importantly, we had a fully playable prototype to show potential investors, and we could put everything we learned from building it into a concrete proposal for the full game.
There are several games that leverage hacking as an aesthetic. The point of Hack ‘n’ Slash was to leverage hacking as a mechanic. We decided this very early on, and it had two significant positive impacts on the game.
First, that distinction drove us to avoid a straightforward neon cyberpunk aesthetic for the world, and instead we drew inspiration from the charming, mysterious, fantastical worlds of the games that inspired Hack ‘n’ Slash.
Early interior concept
This had some surprise benefits: because we were leveraging the visual vocabulary of classic games, players who have grown up on video games intuitively understand how a pushable block or an armored guard “work.” Even if they’re unfamiliar with coding or hacking concepts, they come into the game with knowledge that makes a page of strange variables less intimidating because they control behaviors the player is already familiar with.
Second, we stayed steadfast in our goal of making the hacking mechanics real. When you’re modifying something’s variables, you’re modifying their actual scripting variables, not a curated list of properties we tuned for puzzles.
Later, when you’re hacking the game’s code, you’re actually directly manipulating the compiled bytecode. Over the course of the game, you slowly get access to more and more code until, by the end, you’re able to directly manipulate every byte of code in the game’s file system.
This, of course, means that you’re able to make changes that break the game. But accidentally crashing the thing you’re hacking is an essential part of the hacking experience, and so we embraced it. Instead of trying to prevent you from getting in situations where the game could break, we tried to make the game resilient to being broken.
An in-game crash dialog
The game handles crashes directly and treats them as a “game over” screen of sorts. We had to build an extensive checkpointing system that not only tracked changes in the state of the world, but also tracked changes in the game’s internal file system, so that you were able to roll back to a previous point in time before you made a code change that made the game uncompletable.
Some of these decisions are polarizing; Hack ‘n’ Slash is absolutely the kind of game where you can get stuck in a confusing situation and have to struggle to work backwards and figure out how you got there. But knowing that the things you’re doing in the game are real and not just abstractions of hacking concepts intensifies the satisfaction of your successes and gives the game a unique texture.