Project lead Brandon Dillon walks us through what went right and wrong during development of Double Fine's Hack 'n' Slash, an open-world exploration game about hacking and reverse engineering.
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.
I don’t mean that the team “went right” in the clichéd sense that everyone brought enormous passion and dedication to the project and displayed grace under pressure and so forth (though of course I believe those things).
I specifically mean that I was able to compose a team of my favorite developers at Double Fine. We’d all worked together before, had respect for the work everyone else on the team did, and had an appreciation everyone’s unique strengths.
It was important to me that everyone’s identity come through in the game; the hacking mechanics are mine, but the characters belong to Mark Hamer and Say Oh, the crazy procedural rooms belong to Duncan Boehle, the jokes belong to Erin Eldridge, and the world belongs to Raz Mavlian. And the fact that the game came out at all belongs to our wonderful producers, Matt Hansen and Su Liu, who kept us honest.
Raz in a promotional shoot for the game
With additional opportunistic help from time to time from many other amazing people from within the walls of Double Fine, we managed to make a game that belonged to all of us, and I consider it to be one of the project’s greatest successes. Everyone’s identity comes through when you play, and the game is better for it.
Hack ‘n’ Slash was not funded through a traditional publisher arrangement. Investment came from Indie Fund and a collection of other prominent people in the indie games space. There were some major advantages over the traditional publisher arrangement: The investors were willing to take a bet on a risky game (Hack ‘n’ Slash would likely never have been made otherwise), and they were an invaluable source of feedback and advice.
Just the process of pitching the game to investment group made the game better; their feedback and concerns were concrete and useful, and I came out of the first pitch meeting. I remember a specific instance early in development where I was designing a complicated adventure game-style first act, complete with social engineering riddles and expensive and time-consuming narrative sequences.
I sent some early progress details out, thinking we were demonstrating good progress on this complicated chunk of the game, and got a gargantuan email back from Adam Saltsman with wide-ranging design advice, ultimately imploring me to get to the point and make the very first moment in the game demonstrate the game’s unique mechanics.
An early rough of some possible Act 1 town content
He presented a simple example of a door that you could hack open by switching its “locked” variable from “true” to "false,” which I wound up using as the very first puzzle in the game. In one email, he showed me how to eliminate a huge content production risk and dramatically improve the way the game communicated to the player.
It’s a very good group of people who helped in ways beyond financing the game.
In the Hack ‘n’ Slash prototype, I layered in an extra puzzle that required analyzing a glitch that resulted in an intentional crash, finding a special book in the library/file system, using some in-game encryption tools in a clever way, and working your way to a room you’re not normally supposed to be able to get to.
I just wanted to introduce a much more difficult challenge for people who were already familiar with reverse engineering concepts something to do beyond the prototype’s introductory concepts, but it gave the prototype an interesting additional life, with active forum threads full of people collaborating to crack the secrets well beyond the time most people had gotten what they could out of the short prototype.
This led us to reflect upon the secrets people are still discovering in classic games to this day, and hiding secrets became an important element in the broader design for the game, and we made sure to introduce some complicated ones (that can still be solved exclusively with in-game tools).
This became an important part of the game’s marketing, as well. We announced the full version of the game with a JPEG with a suspiciously large file size with all kinds of hidden assets embedded in it, put glitchy web requests that led to secret documents in press releases, printed decodable patterns into promotional T-shirts, and more.
The original Hack ‘n’ Slash announcement image
The audience for these puzzles were small, but they were staunch advocates for the game, which was very important for a game with no marketing budget. It was also a great opportunity to reuse puzzle ideas that proved too difficult to put on the critical path of the game itself.
At the time of this writing, there are still puzzles in the game that (to my knowledge) no one has worked out yet. I view this as a success: Hack ‘n’ Slash should be the kind of game that has long-running undiscovered secrets, and I’m glad there’s still stuff to be found.
Hack ‘n’ Slash had a very small team and a very short development schedule. This required us to be very rigorous about our production planning, and we couldn’t deviate far from our milestone schedule or our staffing plan.
To make this possible, the game’s schedule was a carefully constructed waterfall-style plan: I wrote an extensive design document up front detailing the game’s mechanics and and laying out all of the puzzles, and we stuck to the plan rigidly.
We still had some schedule slippages, but the game we shipped is largely what was detailed in those original documents, with each feature and puzzle ruthlessly whittled down to the essentials to get everything to fit as we inevitably ran into complications.
This means that the game is thinner than we had hoped. All of the essential features made it into the game, but areas of the game that should be full of secondary puzzles for you to explore at your leisure feel like lonely, repetitive backtracking. Overall, the experience feels less like an open-world exploration game and more like a linear puzzle game with the trappings of an open-world exploration game. The big moments are there, but the little moments that should bolster the experience aren’t there in sufficient supply.
Another problem with the production schedule we took on was that it was ill-suited to the kind of experimental game that Hack ‘n’ Slash clearly was.
Knowing that we had a lot of content to produce, we allocated about three months for preproduction, which was just enough time to work through all of the technical risks related to allowing self-modifying code and dynamically changing variables and procedurally generated rooms and so forth.
One of the game’s puzzle dependency diagrams from the original design doc
This means that we didn’t have time in our preproduction phase to address our game design risks. This means that the game mechanics came online throughout the course of development, where they were already tied to puzzle dependency chains and narrative beats.
We polished features as much as we could without breaking the designed structure of the game, but didn’t have room in the schedule to drastically revamp a mechanic once it came online, and so the quality of the game’s mechanics and puzzles and messaging is uneven.
Hack ‘n’ Slash is a very experimental game.
There wasn’t a lot of prior art we could rely upon to guide us to the best way to implement our hacking mechanics or teach people how to use them.
The advice we consistently got from experimental game designers was to implement the mechanics first and test them for understandability and see what kind of interplay the mechanics have with each other.
Early mockups for the code room machines
We went into production before any of that could happen, and so we instead tried to map the game design to a hacking “curriculum” based on my intuition on the right order to introduce increasingly more sophisticated hacking concepts.
We playtested the game regularly, but we ran into a couple of problems. First, our production schedule was tight, so we always had to squeeze in refinement and retesting where we could, and it never got the kind of dedicated focus it should’ve. Second, almost all of our on-site playtesting was done with Double Fine employees, whose implicit development knowledge gave them a leg up when it came to puzzles that require you you to demonstrate an understanding of the inner workings of the game.
As a result, the difficulty curve of the game is very uneven. The difficulty ramps up dramatically about halfway through, and we didn’t put enough time into refining and tuning the mechanics and puzzles to even out the parts people struggled with and make sure that people without existing programming knowledge had sufficient support to learn how to use the tools at their disposal.
As a way to try and address some of these issues, we released a version of Hack ‘n’ Slash via Steam Early Access months before the 1.0 release. The game already had a core audience comprising fans of the marketing puzzles, and programmers who were interested in the game’s premise. The idea was to get an early version of the game into their hands and get their expert feedback.
We held back the last act of the game, where you use all of the tools you’ve acquired to solve the final, hardest puzzles, so that people could focus their feedback on how we were introducing the mechanics up to that point.
Of course, their feedback was extremely helpful and guided the development of the final act and numerous tweaks throughout the game, but in every other way Hack ‘n’ Slash was poorly suited to Early Access.
An early mockup of a “code” room visually describing source code logic
It’s a puzzle game with a linear narrative, so many people understandably wanted to wait until they could experience the whole thing, and people who did jump in early had to wait months before they could play the most advanced content in the game. Hack ‘n’ Slash simply didn’t fit the mold of a successful Early Access game, and it confused the marketing; it was never really clear when you should jump in if you were interested in the game, and the people who jumped in early saw the game in a less polished, less stable state.
Our Early Access supporters did a lot to help the quality of the game, but Hack ‘n’ Slash would probably have benefitted more from us doing one big concerted push when the game was fully playable beginning to end.
Early on we decided that we wanted Hack ‘n’ Slash to be moddable. It has all of these interesting self-modifying capabilities and it begs for programmers to mess with it. So we implemented really deep, low-level support for mods and released the core engine code uncompiled so that programmers could see how everything worked easily.
This resulted in some really interesting mods: People quickly wrote translation mods for other languages and there were even a few interesting proof-of-concept security exploits (which we promptly worked with the mod writers to fix).
There was a glaring gap, though: Our level design tools were built in-house as plugins for an internal development tool that we didn’t ship with the game. This means that there was no easy way to build additional content for the game, which is what a lot of players wanted to do.
This meant that our extremely moddable engine remained relatively unmodded, which was a missed opportunity for a game about hacking.
Hack ‘n’ Slash is a polarizing game. It has some big flaws and missed opportunities. Some people are alienated by it, and others have profound experiences with it. At the same time, it’s also a very heartfelt game; it was built by a group of people that I love and respect and admire, and it attempts to communicate something deeply personally important to me about the joy of digging deeper and the value of hard-earned knowledge.
Sometimes, it succeeds. The team and I are extremely proud of it.
Developer: Double Fine
Publisher: Double Fine
Release Date: September 9, 2014
Platforms: PC, Mac, Linux
Number of Developers: 6 full-time developers, lots of part-time help from around the studio
Length of Development: 1 year, 4 months
You May Also Like
