Jon Ingold and Joseph Humfrey are the creative director and development director at the Cambridge, UK company Inkle.

80 Days challenges the player to circumnavigate the globe in eighty days or less by any means - and any route - they can find. Playing as valet to Monsieur Phileas Fogg, the player must locate journeys, manage finances, while ensuring their master is comfortable.

It was originally intended to be a "side-project" for us, while we worked on the third installment of our Sorcery! series, but as the game grew we discovered it was more complicated - and more interesting - than we had realized.  What was slated to be a quick three-month build became a nine-month slog, with our writer's contribution rising from "20 or 30 cities worth of content" to over a hundred.

The game's reception was astonishing - firstly Editor's Choice on the App Store; then four-times BAFTA nominated, winner of an IGF and TIME Magazine's overall Game of Year. Since then, we've ported the game to Android, PC and Mac, and added around 200k more words of content.

What went right

1. The core idea

The original idea we had for 80 Days wasn't quite the one we made. The one-line pitch was "Jules Verne's novel, as an interactive story, where you race people in real-time." Our intention was to make a game that played out via notifications - over the course of eighty real days.

That idea got discarded because, it turns out, 80 Days is a really long period of time. But the idea of a race around the world by any route you want - that stuck, and gave us so much value in so many different ways - from giving us a clear tonal metric to compare our design decisions against, to giving us a concept that was attractive to players stumbling across the game for the first time.

And we needed that metric, because we were making a game that wasn’t much like any other games. This wasn’t some robot-bashing simulator: there are management games, but none about servants - there are games about exploring worlds, but none about travel. And games are often replayable, but can they be narrative and replayable? These doubts would have stopped the game at the concept stage, except that the central idea was so simple, and so strong, that it shone through.

A peek at how traveling looked in an early prototype version of 80 Days.

2. The art style

Our first sketches for the project used "typical" steampunk stylings: this was back when iOS 6 was exciting and new, and skeuomorphism wasn't something that made people blush. But we were concerned that conventional steampunk would seem somewhat cheap and rather kitsch, so we decided to start thinking anachronistically, looking mainly at travel posters from the Art Deco era.

For a while we were worried people simply wouldn't understand: what was 1930s style doing on a Victorian-set game? But after a while we realized the art style was really telegraphing the tone of the game - it isn't historical, it's futuristic, except it's the future as imagined by people in the past. That led to our original tag-line, "The year is 1872 - welcome to the future", which we still feel really captures what the game is all about.

The success behind the art style wasn’t a matter of pure aesthetics, however. We were consciously making a decision to make a style that would sit well with iOS 7. Apple’s controversial UI overhaul focused on flat design and primary color highlights, and we made sure to point out the visual design when we pitched the game to them.

We thought about our art style early, with the marketability on the platform in mind, and we feel it paid off.

3. The Inklewriter Engine

We knew we were writing a big game, but we had no concerns about the core engine - we'd just finished Sorcery! 2, a 350k word sprawling interactive story set within a single city.

It was the largest thing we'd produced in inklewriter at that time, and we'd had to do a lot of work to scale the engine up (including some low-level features, like streaming in story content on demand rather than loading the whole script up-front) - but by the time we started on 80 Days we had a scripting language we were confident with, a sturdy compiler, and an efficient, issue-free text engine that could take whatever we were going to throw at it - and that we could put into the hands of a writer, and let them just get on and create beautifully sprawling content.

4. Naturally episodic content meant we could scale

Speaking of content, both a key strength and weakness of 80 Days core concept is that it's inherently episodic - much as what happens in Vegas stays in Vegas, so does what happens in Tehran, Dubrovnik, and pretty much everywhere else you go. At the start of the writing process, we agree the core stats - money, health, time - and the core character traits - skillfulness, style, and 'properness' - and these are the only things we consistently track from city to city and journey to journey.

That meant when we asked Meg Jayanth to start writing, the first thing we wanted was just one journey that took us all around the world and back. The plan was to get that up and running, play it, see what worked, and branch out as much as we needed to.

In practice, that first journey wasn't complete for several months, and in the meantime we had already begun to encase the world in a spider's-web of routes and journeys. But the episodic nature of the design meant we could scale up in whichever direction we wanted, Meg could write scenes entirely out of order, and we were even able to jump in and provide additional content as well, all without stepping on each other's toes.

5. One tiny tweak: Making exploring cities optional

We made a hundred changes during development, but there was one choice that was particularly difficult, and scary - and completely changed the final game.

In our original design, we showed almost all the game routes on the globe. Story content appeared in cities as soon as you arrived; you read it; visited the market and moved on. It was a model we were confident with, having lifted it more or less directly from the Sorcery! games. But about halfway (and two hundred thousand words) into development, we realized that in 80 Days, it simply wasn't fun - and we didn't know why.

Players - ourselves - were skipping through city content without reading it; the market felt like a chore, and the choice of where to go next felt pointless as a result. We were terrified that the game was going to become a folly of Titanic proportions.

We tried various halfway-fixes, timing tweaks and details, but the change that in the end worked was a two-fold thing. First, we locked all the routes on the globe. Secondly, we introduced the Explore mechanic, which meant the story content for cities became something you wouldn't necessarily ever see.

That broke the story logic for most of the journeys we'd written at the time; and made a lot of stories nonsensical (you can't begin a story with waking somewhere if the player has arrived at 11am and then explore.) But once we'd fixed them all, the result was incredible. Our game suddenly felt player-driven, slick, and quick, and filled with highly valuable content - and as gameplay designers, we suddenly had the more incredible bag of rewards to dole out to players, in the form of routes. Talked to a merchant? Have a camel! Met a captain? Have a fishing boat. And so on - and on - and on... 

6. Teamwork!

80 Days was a huge undertaking for us, both conceptually, and it terms of the volume of work required to make it happen, but what made that possible was the teamwork and camaraderie that built up around the game. inkle is too small to have an office, but in the last few months of development, the core team of three were in constant communication via instant messenger, batting ideas back and forth, arguing, debating, and trying out concepts and ideas - including several plot-lines, jokes and characters that were slipped into the script and now seem like key pillars of the world!

Looking back, it's hard to know who had what idea on the game because we had such a great community development vibe. It was fantastic to experience, and the end result is definitely better for it. We can only hope to capture the same spirit on the next game we make together.

Core to that team spirit was the inclusion of Meg Jayanth, the lead writer on the project. We had originally met her several years earlier, but after playing her StoryNexus game, Samsara, we thought she’d be a good fit for the project. But, although we’d worked with writers before, they’d never been on projects of such scope, or where we had editorial control, and of course we knew that the written part of the game would be a huge part of its final quality and identity. So bringing in a relative unknown was a large risk for us and for the game.

We tried to mitigate that risk a little by getting Meg on board early, before we were working on the project ourselves, and giving her four or five months to find her style and voice before we moved onto the project full-time. We reasoned that, if she wasn’t going to be right for the project, that would be enough time to discover that.

Of course, the results speak for themselves - Meg proved to be not only a good writer, but a clever one too; consistently surprising us with new twists and mechanics that fed into the traveling gameplay - while also taking incredible pains to research the cities and journeys she was writing about, and to be as inclusive and even-handed about the cultures through which are story walked. We were soon looking forward with pleasure to every drop of new content, and more than once laughed out loud as we discovered the surprises she had laid in store.

The extended team were great too, and have never been properly thanked - Jaume Fabregat, who turned in amazing illustration after amazing illustration as we worked our way up from steamships to mechanical birds; Laurence Chapman, who appeared via an unsolicited email and within two weeks had composed the main theme, which we're still not tired of after hearing solidly for a year; and Trevor Horwood, a traditional proof-reader who successfully navigated Bitbucket’s online editing web-interface, and our inline logic heavy branching script to copy-edit the text.

What went wrong

1. Scope - The design!

80 Days is the hardest project either of us have ever worked on, and between us we have ten years' experience in AAA-development! Here, every design problem was an intractable one, and we chewed over and iterated on every single element of the game two or three times over. (At one point, Joe remarked it felt “like biting off more than you can chew, literally.”)

Hard problems, lots of iteration, all on a short schedule as our limited funds ran low resulted in a code-base that's far more tangled and complex than it should have been, and several corners of the design that were simply the best we could do in the time.

We were up against it for the whole duration of the project and worked solid weeks for months on end without holiday, and yet we still couldn't get every part to quite fit together, and there's a hundred little details in how the game unfolds, in the balance of the market and pricing systems - which could have been fixed, given a little more time.

We’re not sure what the takeaway from this is for us as a studio - was it the wrong project to tackle at this stage of our lifetime? We don’t think so, although, had it failed, it could have burned us out quite hard.

2. Scope - The content!

This was meant to be a medium-sized game, and it ended up being a colossal one - and that wasn't a choice, but a requirement of the design. We'd originally imagined a few routes around the world, with a few branches, providing an experience that most players played once, and a few replayed out of curiosity.

But the more we played, the more we realized we were really making a board-game, and that meant that from every "square" (a city) the player should be able to reasonably expect to be able to travel to every adjacent "square". To do that meant writing more journeys, but longer gaps meant longer journeys, which were much harder to write than short-hop trips, and rather slowed down the pace of the game. So we'd break up the longer journeys with more cities, which meant more journeys... and so forth, until Europe had turned into a fearsome spaghetti-maze.

That issue of scope was really what meant the original release of the game was rather thin once the player arrived in the Americas: we were simply burned out by that point, and were reserving most of our writing energy for additional long journeys that were safer than adding new cities.

3. The conversation game

The original design for the conversation game was "do some talking to people to fill the time between stops" ... and that was it. We didn't have any idea what the benefit to the player was, or what the mechanic was.

And when we came to prototype it, three-quarters of the way through development, nothing we tried worked. We tried passive, simple interactions, but they felt pointless - we tried a complex mini-game of collecting and playing strategic facts, only to take it out less than three weeks before the game shipped because, quite simply, no-one enjoyed it.

The final design is something a bit like a game of consequences, and a bit like a quiz, and when it works, it produces fun semi-robotic conversations. But more often than we'd like, what characters say is obtuse and not actually that helpful.

4. Testing

Before the release, we'd played the early game a lot, and journeyed around the world a few times. Our testing pool was perhaps seven or eight players, sourced from friends and relations, who played the game with some enthusiasm but little dedication. We were reasonably confident when we shipped that the game was in one piece. We were, of course, dead wrong.

Soon after the game went up on the App Store as Editor's Choice we began to receive emails via the in-game feedback button from players stuck in Acapulco, and stuck on the road to Houston. By the weekend, we were receiving ten emails day and night from players - some confused, some angry, but all wanting a fast response. After four months of something altogether too much like crunch, we were now working a solid weekend to fix a bug in real-time.

Thankfully, the in-game feedback button was also what saved us - we'd added it for beta-testers, and made it automatically attach a save file on sending, and we only decided to leave it in the final game on a whim. Without that, we would never have been able to diagnose all the weird and wonderful story issues that people have found: as every save file contains not just the current state of play, but the full record of all the choices the player made to get that point in the story.

5. Staggered releases

Since 80 Days was completed, we've released two large content updates; firstly adding the North Pole route, and the secondly, filling in the Americas (and a few other things besides). Thanks to continued support from Apple, we've been able to deliver those as free updates. But meanwhile, we've been porting to other platforms - firstly to Android, and now to Steam, and that staggered approach means we've had to face the worst indie-problem there is - visibility - not once but three times.

A simultaneous release across all platforms would have been much better for us, though there's no way we could have done, as the original game was built in Objective-C - and built on existing, Apple-centric code. But it leaves us in the strange position that, at the time of writing, TIME Magazine's Game of the Year 2014 is available on Steam, but doesn't have a Metacritic page because we've not yet had four numbered reviews of the PC version.

Sorcery! is slated for release starting from November; once that's done we'll be intending all releases to hit all platforms at once. It's unlikely we'll ever leave mobile behind - it's a form factor we both enjoy - but the hope is that by being available on all formats, we can afford to scale up our ambitions a little - and our team sizes!

Conclusion

80 Days has been the journey of a lifetime for us. The memory of the hard work and impossible problems have now, a year later, mostly faded, leaving us with just the happy glow from being part of a fantastic team, all working together on a shared goal we all believed in.

The reception of the game has been quite astonishing, touching people far beyond what we thought was possible for our little game about a valet, and the game has fundamentally changed our company, and thrown our ideas for what we should do next up into the air. We feel like people are expecting “80 Days 2”, but most likely we can’t do that - we need to do something else. Perhaps something with robots.