This interview is part of our Road to the IGF series.

Instead of unraveling a murder mystery and finding the killer, in Overboard!, you most definitely ARE the killer. And now you need to throw suspicion off of you if you're going to get away with it. To that end, you'll need to lie, trick, seduce, and cast doubt on other people, doing whatever you can to be sure you don't end up in handcuffs in this narrative adventure.

Game Developer spoke with inkle's Jon Ingold, writer and designer of the IGF Excellence in Narrative and Design-nominated experience, about how they created so many different ways for the player to throw off their pursuers, how they solved the challenges of giving the player so many possible options before they even started making the game, and how they overcame the challenges that came from having so many possible routes through the game. 

What's your background in making games? 

Jon Ingold, writer and designer of Overboard!: I started out making text adventures for a small community of hobbyists in the early 2000s until I got a job as a narrative designer at a Sony studio. There, I met Joseph Humfrey, and we left to found inkle in 2011. Together we made Sorcery!, 80 Days, Heaven’s Vault, and Overboard!, which is our most recent title. 

How did you come up with the concept for Overboard!? 

Ingold: It was the collision of quite a few things. Firstly, the UK had just gone into another lockdown and we were all feeling miserable—we felt like doing something short and fun that we didn’t need to take too seriously. I’d been listening to a version of Murder on the Orient Express on the radio and had been playing Cluedo with my children. I remember explaining to one of them that just because it turned out their character was the murderer, that didn’t mean they’d lost the game. 

All these elements swirled together and we gave us the idea of making a game as fast as we could - we originally wanted to make the whole thing in a month—where the sole idea is that you’re the murderer and you need to cover it up. 

What development tools were used to build your game? 

Ingold: Like all of our titles, we do the narrative scripting and interactivity in ink, our open-sourcing interactive fiction markup language. With every game we add more and more functionality into ink, so in Overboard! it’s handling things like the characters moving around the map in real time, and the pop-up notifications when you learn new information, and so on. Ink plugs into Unity, and we used that for making the interface and game-side features like the fast-replay system and so on. We process audio using Amadeus, draw in Photoshop, and communicate using Slack! 

What interested you about creating a whodunnit in reverse? In creating a game where the player sows misinformation and distrust? 

Ingold: We’re always interested in games that revolve around characters. A game has the central character, who you want to be compelling and interesting and flawed and brilliant all at once - but it also has lots of other characters who you only really get to enjoy if you interact with them. So, we like our games to have an interesting cast and lots of ways to affect their lives. 

Playing the murderer, and having to lie, cheat and deceive your way to freedom, felt like a great way to get people interacting with the other characters—thinking about what they do and don’t know, and making things like “does this person trust me?” a core part of the gameplay. We also loved the hook of the idea. 

The first thing we did when starting work on the game was sketch out the opening moves as a ten-line ink file, and even then, we all felt it: “Oh no, how am I going to get out of this one?!?" 

The player is capable of many different means of throwing people off of their trail: blackmail, lies, seduction, friendship, etc. What thoughts went into giving player so many different means to throw suspicion off of them? 

Ingold: When we began work on the game, we didn’t know how big we wanted the scope to be—was it a fairly linear experience, or something broader that you explored? So, initially we implemented the minimum we needed to make the game work: one way to throw off suspicion, one way to plant suspicion on someone else, and so forth. Then we played it, and it became pretty obvious that, if built that way, the game was simply too hard. 

So, we went the other way and made a list of all the sorts of things the player would ideally be able to do—a big list full of ridiculous suggestions like “drug the old lady” and “throw everyone overboard” and “hide a body under your bed”. We raided every stereotype we could, trawled through our recollections of Agatha Christie novels and pulpy 30s movies. Then, we set about implementing absolutely all of them, as efficiently and clearly as we could. 

By the end of development, there was only one thing on the list that we hadn’t managed to get in somewhere—"steal the crucifix from the chapel and bludgeon people with it while God chastises you.” It would have been a lot of fun, but very very difficult to implement. So we decided that one, finally, was beyond the pale. 

What sort of work went into implementing these abilities into the game? In making so many different options possible? And what challenges came from giving players so many roads to take? 

Ingold: Luckily, the breadth of Overboard! was already a solved problem, technically, at the point where we began work on the game. For Heaven’s Vault, released in 2019, we’d build a system of “knowledge modeling”, which allows the game to efficiently track what you—and what other characters—know and believe about the state of the game world, and to vary options and content quickly and dynamically based on that state. 

In Heaven’s Vault, that system drives the conversations and plot occurrences across a 20 hour highly-repayable non-linear adventure game… so adapting it for the relatively compact setting of Overboard! wasn’t too difficult. We plugged in the code and then began loading it up with specifics, and because we knew how the system worked before we started, we could make sure that all the content was correctly marked up and tagged as we wrote it, minimizing the number of continuity errors that needed finding and fixing (though there were still hundreds, of course). 

One thing that came up during early play testing was that the breadth of the game was leaving players on their third run and higher feeling a little lost for what to do, however. They’d taken the choices that seemed right to them—and people tend to get “stuck" on choices, and find it hard to try different routes on repeat runs. That got us thinking about a system that provided some kind of encouragement to try new things—we didn’t want to spoil any of the core puzzles, and we didn’t want to implement a cold “achieve these achievements” system: but we settled on the idea of Questions. 

The game tracks things Veronica has perceived but not fully seen across games, and opens them as a question: things like “Who is inside Carstairs cabin?” or “Is the ship really sinking?” These are fed into a tick-box menu that pops up at the start of the run to give the player something to focus on—if they want to. 

It gave the game some achievable medium-term goals; we could prioritize the order in which questions appeared to help teach players the mechanics and some of the tricks for finding new content. And best of all, it simply advertises that the game is still wider than you think it is (until you’ve actually finished it, of course.) 

You mention a "core spine" in an article you previously did for Game Developer—a conclusion that would be reached if the player did nothing, and how the game uses a "patchwork approach" to finally assemble its case against whoever ends up being seen as the prime suspect, and to decide which characters would know what about the case. Why did you choose and create such a system for the game? How did it help make the game come together in a compelling way? 

Ingold: So, the spine and patching system is primarily for the final scene of the game—in which all the characters come together, and share what they know, and a detective character assembles the best case he can against the most likely suspect (usually you), and an ending is reached. 

The difficulty with a scene like this is, on the one hand, it absolutely has to move forward, at quite a brisk pace, and be continually escalating towards a conclusion (or it feels rambling and endless), but at the same time, it has to be able to react and reform itself around any combination of a hundred different variables, from the massive to the minor. 

So the design we settled was this idea of a core spine—it’s still not linear, but rather has the big significant branches baked into it. This provides a script that’s a good length and will make a compelling case based on what we consider to be the default game state—where all the variables are where they would be if the player did nothing. Then, for every step of that script, we make sure we’re checking—is the game state in the right place for this line? If not, where can we jump to—usually we skip out a beat. Then, we have to consider additions to the spine. 

So, now the player has implanted some new idea into one of the characters, and we want them to bring it up with as much impact as possible so the results feel exciting. To do that, we write a separate mini-beat of content (a “patch”), and we insert it absolutely everywhere in the flow where it makes sense. The patch itself has some code to make sure it will be invisible/inactive if it’s not appropriate, and that it won’t even run twice: if it was patched in up there, it doesn’t need to be patched in again down here. That way the same patch can be used regardless of which way the core spine happens to flow in this game. 

And that design lets us build out the complexity organically. We have a core spine of core branching decisions; we have big significant patches; and then we have minor flourishes within those patches for details which alter a line here or there, or change the exact flow of a particular revelation, but don’t derail the thrust of this particular play through. Then when we play the game, and if we find a play through that’s got a lull in it, or needs to be faster, we usually fix it by just patching something appropriate in a new place or a new way. So overall, the main beats get hit, but the player-modified stuff does too, and while it’s a testing nightmare, it basically always works, giving us a finite number of cases to fix rather than an infinite number of combinations to cover. Simple. Aargh! 

We had no idea if this would work. We tried it, and iterated a lot, and tested a lot, and eventually it settled into something robust—and in that way, it felt a lot like writing a classic game AI decision tree. Part design, and part bloody-mindedly not giving up! 

What drew you to allow the other characters to learn information dynamically on their own? What do you feel this added to the game? 

Ingold: The heart of the game is that it’s a comedy. It’s a farce. That means you should always be one step behind and always playing catch-up. People should walk in on you at inappropriate moments, see through your lies, and use your own words against you. To do that, the other characters can’t be waiting for you to act the whole time, they’ve got to be out in front. 

What challenges come from creating the writing for so many available possibilities the player can take? Into planning for so many possible routes, connections, and eventualities and being sure to have something in place for that many possibilities?

Ingold: The two biggest challenges were making sure that the game didn’t fall over, get stuck, or stop making sense, as well as making sure that players didn’t get into states where nothing interesting was happening, because we’d fill the game with content over here and not over there. We tackled both as constructively as we could—not by planning too much, but by making the game, and then using an autoplayed to smash through it thousands of times per hour looking for problems. 

We filled the game with asserts—deliberate crashes on demand—testing for things which shouldn’t happen. Is this person dead, who’s talking? Crash. Has this once-only seen happened before? Crash. Has the player run out of choices? Crash. Has nothing interesting happened in a while? Crash. We must have run a hundred thousand loops of the game from earliest builds to the final shipped build, and fixed a hundred thousand bugs from the minor to the massively obscure. And then of course, our human play testers found a lot more. One thing we learned on Pendragon was to include a fast way to report highly contextual bugs, so the player, with a few clicks, can send us a full log and a save to reproduce the issue they’ve had. 

But I love filling a game this way. It feels organic, and like you’re discovering the edges of what you have all the time, and it forces you to be inventive—you find new ways to fill out scenes, or push the player towards important or useful pieces of information, and you keep doing it until the game feels like a complex piece of clockwork. But it isn’t clockwork, really, it’s more a massively enormous pile of cogs.

This game, an IGF 2022 finalist, is featured as part of the IGF Awards ceremony, taking place at the Game Developers Conference on Wednesday, March 23 (with a simultaneous broadcast on GDC Twitch).