In The Uber Game, you play as a full-time driver trying to make ends meet. Do you return home to keep a promise to your son, or keep driving to earn more money? Do you drive 30 minutes to chase a 3x surge pricing?

We made this news game because we wanted to explore new ways to help people emotionally understand a subject.

We hope that by asking the player to make meaningful choices as an Uber driver, we can shift their perspective. Maybe by making a game, we can spark their curiosity and prompt them to critically examine the constraints and biases of systems like Uber and other gig-economy platforms.

Doing so would extend the role of journalism beyond just giving people the right answers, to equipping readers to ask the right questions and start important conversations.

A discussion about privilege in a Hacker News thread about the game

.

We also believe that games and play are an important but under-explored use of interactivity in journalism.

Driving for Uber seemed an apt subject to explore this way, because Uber was already using the language and technique of games in its driver app. By making a game about it, we would be using the medium as part of the message.

Scripting the Game | by Robin Kwong

We started with the reporting, which was done in a very similar way to how we would report for a written article about this topic (which Leslie Hook also did in her Uber feature story).

We focused on collecting the stories, anecdotes and strategies that form the events and incidents the player encounters throughout the game. We also made sure to record the structured data needed for the game’s simulation: Average fares per hour, average number of rides per hour, car rental costs, fuel costs, etc.

Alongside that, we made paper prototypes and play-tested a few basic game mechanics (a pathfinding game? A Monopoly-like dice-rolling game? etc). In the end, we decided on a choose-your-own adventure style game because we wanted to highlight the drivers’ anecdotes and stories.

Together with Leslie, I scripted the game using Ink, an open-source narrative scripting language made by Inkle Studios, a UK-based game company.

Sample of the Uber Game script in Ink

Using Ink had several big advantages. It let us create and test a barebones version of the game without needing developers, artists or UX designers. In the later stages of development, it also allowed us to separate the script from other development work, so that we could work in parallel and make changes to the script until the last moment.

Integrating Ink into an FT Interactive Page | by David Blood

On the FT’s interactive news desk, we have our own front-end project scaffolding tool called Starter Kit. We’re a JavaScript shop, so Starter Kit provides a Webpack build system with all the Node-based tooling we need to start work on a new project. It sets you up with a page that includes the essential FT page furniture and some of the key components from Origami, our in-house components library, as well as FT-specific analytics and deployment scripts. With a few style tweaks, Origami components were used throughout The Uber Game.

Default FT Starter Kit page.

Our first step in developing the page was to establish how to integrate an Ink story into an FT interactive page. This turned out to be pleasantly straightforward: working in a fresh Starter Kit project, we were able to use inkjs to implement a basic mechanism for navigating the entire game in under 90 lines of JavaScript. This mechanism became the backbone for the main portion of the game, though it ultimately weighed in at more than 1,000 lines of JavaScript!

As designs for the game screen layouts and UX started to land, it became clear that we would need a non-native solution for animating elements on the page. Writing so many complex CSS transitions and their associated JavaScript from scratch would have been hugely time-consuming, so we opted instead to use anime.js, a JavaScript animation engine. It easily handled the range of transitions required by our designs, with the added bonus that it integrated smoothly with the inkjs code.

The Uber Game is by far our most heavily customised Starter Kit project, requiring more than 700 lines of original SCSS to transform it from a default FT interactive page into a visually rich, app-like experience. Despite this complexity, the experience has reinforced for us the importance of being able to quickly deploy a prototype with a structure and tools that are familiar across the team, enabling rapid collaborative development from the start.

Designing the User Experience | by Nicolai Knoll

Our initial concept was to use the driver’s app as the player’s tool to navigate through the story. It’s an essential part of the real driver’s experience and the one element that we could pull out from there and put in front of our players. Since Uber’s app is already quite gamified, it gave us the elements we needed to tell the story like the rating and time gauges, dialog boxes to communicate with Uber, etc.

Using Framer, an interactive design tool, we turned this concept into a prototype for initial testing sessions. It became clear this form of storytelling could work, but was missing a more engaging and fun presentation that would keep people engaged and playing for several minutes.

The isometric illustration style, done by Rebecca Turner in Affinity Designer, filled this gap perfectly: it was a great way to bring crucial elements like the map alive and introduced a modern and human aesthetic at the same time. This made the game feel much more approachable and open and created a visual reference to casual mobile games and old-school and text-based adventures.

For production, we simplified the structure of the screens into a few templates and components that could be used to build the majority of the game.

Preloading Image Files | by Callum Locke

The game has dozens of background illustrations. We needed a way to manage asset loading: something that would allow the user to start playing the game as soon as the first images are ready, while continuing to download subsequent images in the background so they’re (usually) ready by the time they need to be displayed.

We made a simple promise-based image loading mechanism, which looks something like this:

const memo = {};

const loadImage = (url) => {

 // Create a promise to download the image - but only if
 // this is the first call for this image
 if (!memo[url]) {
   memo[url] = fetch(url)
     .then(res => res.blob())
     .then(URL.createObjectURL);

 }

 // return the promise
 return memo[url];

};

// At the start of the game, start preloading images
loadImage('image-1.jpg');
loadImage('image-2.jpg');
loadImage('image-3.jpg');
// ...etc

// Later on, you can consume images like this:
showLoadingScreen();
const blobURL = await loadImage('image-1.jpg');
container.style.backgroundImage = `url(${blobURL})`;
hideLoadingScreen();
// etc.

The nice thing about this approach is that, at any point in the game, you can request an image and wait until it’s ready—perhaps showing a loading screen in the meantime. You don’t have to know whether or not the image has finished (or even started) preloading. You just wait for the promise to resolve. In most cases, this takes no time at all, and the user won’t notice any interruption.

Recording Players’ Scores | by Ændrew Rininsland

To add a sense of competition to the game and provide contextual information in the final screens, we built a backend that records player decisions and compares them against how other players did.

The backend records two things: incidental decisions as they happen (did you help your in-game son with his homework? Did you buy a business license?) and your total income at the end of the game. It uses a NodeJS process written in TypeScript comprised of little more than Sequelize for communicating with the database and Zeit Micro for handling requests. I hadn’t used Postgres’ data analysis functions very extensively, so I initially queried the News Nerdery Slack group for suggestions on how to create deciles, which Anthony DeBarros very helpfully assisted with. In the end we decided we actually needed percentiles instead, which resulted in the following query:

SELECT percent_rank(${Number(income)})
WITHIN GROUP (ORDER BY income)
FROM results
WHERE difficulty = '${difficulty}';

Even with 122,000 rows in the database (each representing a separate play-through), that query takes only a tenth of a second. If I wasn’t totally sold on Postgres as a technology before this project, I definitely am now.

In terms of infrastructure, it’s currently being served by two Heroku 1X dynos and a Standard–0 size Heroku Postgres database. I had initially planned to do some crazy architectural stuff with Amazon Web Services involving a lot of caching, but quickly realized even this simple setup is somewhat overpowered given the requirements of the project—at its peak, we were serving about 14 requests a second, and that only utilized about 1/2 capacity (to put that into perspective, on a complete playthrough lasting anywhere from 5 to 10 minutes, a user will make about 6 requests).

Tracking Engagement Metrics | by Joanna S. Kao

Since this is the first game we had created of this magnitude, we wanted answers to a number of editorial and usability questions—is this something people would make time for? Would our readers play through the entire game? Are there any design lessons we can learn from how people have interacted with this?

Every page at the FT has some basic tracking, but we also wanted to know where users were dropping off while playing the game. If a large number of players were leaving the game at the same point, it could potentially indicate a lack of interest in the storyline, or fatigue from making choices and clicking buttons.

Because the game progresses linearly—there are no cheats to skip days or circle back in time—we were able to gather players’ “story depth” (similar to “scroll depth” in a traditional text story). We tracked every time a player began the game, reached the beginning or end of a work day and clicked through each of the ending summary screens. To answer our questions about fatigue, we also kept track of how many decisions they had to make before they left the game.

We were pleasantly surprised to see how many players stuck through to the end of the game. More than 70 percent of the players who began the game, finished the game—a number significantly higher than a typical interactive. The analytics we collected using a combination of internal analytics tools and Google Analytics helped us understand what was successful about our experiment and what we should do for future projects.

• Share on Twitter
• Share on Facebook