Sponsored By

"I initially saw Mini Metro as an opportunity to have an iPad app under my belt and a little pocket money. My brother Peter saw it as potentially leading to a career as an independent game developer."

Game Developer, Staff

June 15, 2016

23 Min Read

Mini Metro is a game about building subway maps. Stations and passengers appear on a map, and the player builds lines to get people to where they need to be as efficiently as possible.

It has met with commercial success as well as enjoying a run on the festival and awards circuit, culminating in four nominations and one win at the 2016 IGF Awards and one nomination at the BAFTA Games Awards.

Mini Metro was prototyped in a weekend over three years ago. It took ten months to take to Greenlight, another sixteen months to release, and is currently in development for mobile. So postmortem is a bit of a misnomer, as the project is anything but dead!

THINGS THAT WENT WELL

1) Scope

Mini Metro is a game defined by its scope. It’s even in the title! Both of us, Peter and Robert, had worked in the game industry over a decade ago and had since spent a lot of time developing games at home, but had only ever abandoned projects rather than released them.

The original Ludum Dare entry for Mini Metro

In 2013, when Mini Metro was born, Peter had just started a family with his wife Mary and was a stay-at-home dad. He had a string of half-completed engines and game ideas that were never even started, but wanted to make and actually release a game. For the first time he was aware of how small in scope a game would have to be for him to complete it - he had about an hour and a half during the afternoon when his son had a nanny, and a couple more hours every evening. Robert had a full-time job, and didn't have the capacity to come home from his programming job and write even more code at home.

So we deliberately chose a project that fit within our constraints. We enumerated our many constraints, and drew up a list of the corresponding restrictions we had to put on any game concept.

Strengths:
●    Plenty of professional game programming experience.
●    Web development experience.
●    Good at executing simple, consistent graphic design.
●    A long history of playing board games, tabletop wargames, and video games.
●    Good at grokking game mechanics.
●    A pedantic streak, which helps tremendously when adding the final polish to a title.

Weaknesses:
●    Only a handful of hours a day for development.
●    Zero skills at producing art assets.
●    Zero music and audio skills.
●    A pedantic streak, which can mean getting distracted for long periods on trivial tasks.
●    No talent at PR and business, and not much drive to get better at it.

We outlined the following hard constraints that any concept would need to fit within:
●    No hand-built levels.
●    Nothing art-heavy.
●    No reliance on audio content.

One thing we immediately found is how ironically liberating it is operating within tight constraints. Not only could we immediately discard 90% of our potential ideas without agonizing for days over the viability of each one, but the constraints themselves inspired ideas. Themes that kept recurring in our concepts were procedural levels and abstract visual styles.

While we discussed a number of ideas that fit within the constraints, we didn’t prototype anything until Ludum Dare 26 in April 2013. Prototyping in a game jam wasn’t something we consciously decided on, but in hindsight it gave us our most important constraint. Any concept we couldn’t have fully prototyped in two days would have been too much for us to fully develop. As it is, Mini Metro has kept us busy for over three years!

2) Giving the game away

We chose to use Unity for our Ludum Dare entry because of the high uptake of the Unity Web Player—like most entrants, we wanted as many people to play our game as possible, and reasoned that a game playable in the browser would get more attention than a downloadable executable.

"It’s impossible to know for sure, but we don’t think Dinosaur Polo Club would be operating now if it wasn’t for that web-playable build."

So almost from the game’s inception it was freely playable online. In the weeks afterwards, when we were discussing how to continue development, we reasoned that keeping it freely playable up to release, and possibly even after release, wouldn’t be such a bad idea. The game we had in the back of our minds was Papers, Please. Lucas Pope had released betas of the game during development; while it’s impossible to know how that impacted the eventual sales, it obviously didn’t preclude commercial success.

The first release of Mini Metro’s playable alpha was in September 2013. We designed the website around the web player. It was front-and-center on the index page, not hidden away behind a button. The game was quick to play, relatively intuitive, and had a virality that the accessibility of the build played into. Hey check out this site, you can make your own subway map! Thanks to that virality the game sailed through Greenlight. It led to a lot of awareness and popularity, much more than we’d ever expected, which contributed to the success of the Steam launch months later.

Again, it’s impossible to know for sure, but we don’t think Dinosaur Polo Club would be operating now if it wasn’t for that web-playable build.

Early Access

Mini Metro is a near-perfect game for the Early Access model. At NZGDC 2015, Peter gave a talk on our experience going through Early Access and outlined the follow attributes that make it suitable:

●    Narrow vertical slice.
●    Brief play sessions.
●    No fixed narrative.
●    Procedural levels.
●    Segmented content (cities).

In short, we could build it quickly to a saleable state and update it in meaningful ways. It is designed to be played repeatedly, so buying the game in Early Access wouldn’t spoil the experience.

This turned out to be very important for us. Despite the small scope we missed the initial release date of Christmas 2013 by a mile. We ended up taking well over a year to get Mini Metro to its commercial release, and even then it was timed due to “external factors” ... a fancy way of saying we needed some money! Peter started work full-time on Mini Metro around March 2014, soon after it took off on Greenlight, with the anticipation of a full release in late April or May. However game balance turned out to be more complex than anticipated, an interface redesign escalated into a graphical overhaul of the entire game, and we had all sorts of problems scheduling the work on the audio.

A release on Early Access wasn’t something we’d originally considered, but when we realized just how far away a full release was it didn’t take long to decide to go down that route. We released on Early Access in August 2014. It worked out well for the game—Early Access was a natural extension of the open alpha we were already running. The game’s community was already used to regularly-updated builds, giving feedback, and talking with us online. A good chunk of the game’s community made the jump from the free alpha to the paid beta.

Mini Metro earned enough from launch to keep Dinosaur Polo Club running to the end of the year. In the following months it tailed off but was still earning above our expectations. The early release allowed Peter to remain working full-time, and Robert to eventually quit his day job and join full-time as well. Without it we doubt the game would have been finished.

3) Relatable concept

We've spent a lot of time over the past couple of years trying to figure out exactly what it is about Mini Metro that resonates with its players and enabled it to be a success. One thing we come back to is the relatableness of the concept; if someone has had experience with a public transit map, then they'll likely understand what Mini Metro is from a screenshot. The game sells its concept well.

"Inadvertently we made a game that communicates the idea of itself very well. It sells itself not just to the traditional demographics, but because it relates to an everyday concept, 'normal' people get sold on it too. "

We’re not sure if we're over thinking this, but the Dinosaur Polo Club theory holds that for a game to sell itself to a potential player, it needs to quickly communicate exactly what it is. If you're selling to self-identified gamers, it’s easy to communicate a game by relating it to a genre or another game. For example, the vast majority of people on Steam will know what you're talking about if you describe a game as a MOBA, or a first-person shooter, or the love-child of Theme Park, Euro Truck Simulator, and Spelunky (actually, that one might take some explanation). If a game is sufficiently differentiated from other games that it can't be explained quickly and succinctly, it runs the risk of being passed over by people who would have otherwise enjoyed it, if only they had understood the concept. We think Mini Metro managed to do an end-run around this by tying itself to a relatable real-world concept, instead of an abstract game genre.

Inadvertently we made a game that communicates the idea of itself very well. It sells itself not just to the traditional demographics, but because it relates to an everyday concept, “normal” people get sold on it too. People see the marketing for the game—a screenshot, the name, maybe the blurb—and get an accurate idea of what Mini Metro is. This either interests them and they want to know more, or turns them right off and they keep walking.

And we’ve found this is great! Not only does it make our job of communicating what Mini Metro is so much easier, because it communicates so clearly we don’t attract the wrong people and waste their time. At expos the Mini Metro booth mainly attracts people that end up enjoying the game, and likewise the Steam page only seems to pull in people that enjoy it. This has left us with a low return rate, a very high review user rating, and few complaints to answer.

4) The Team

There are two huge skill gaps in Dinosaur Polo Club; audio and art. We never expected to get away without help on Mini Metro’s audio. We didn’t want to phone it in. From very early on we had a vision of an entirely procedural audio environment, with every sound generated by events in the game.

Finding someone to do that job is difficult, as there aren’t many people with an interest in fully-procedural audio, and even less with experience. One who has both is Disasterpeace. After seeing his January demo, we figured we’d shoot for the moon and ask if he was interested in working on Mini Metro. To our astonishment he said yes! The story of Mini Metro's audio development would make for an entire series of articles so we can’t delve into it here. Suffice to say it was a lot of work, both in audio design and programming, but it was worth it. Excuse us as we wax lyrical for a moment; he made the game sing like few could.

"Mini Metro doesn’t have to provide incomes for a team of ten, just the two of us full-time and Jamie and Disasterpeace part-time."

Initially we thought we could manage the visual design ourselves. We cobbled together the look of the game, especially the user interface, by taking heavy inspiration from graphic design of the London and New York subways. It wasn’t until the game took off on Steam Greenlight that we put our egos aside and asked Jamie Churchman, an artist and ex-colleague of ours, if he’d be interested in looking over Mini Metro’s in-game visuals and tweaking a few things.

We anticipated it would be a small job, maybe two or three weeks, but he took the ball and ran with it. He not only redesigned every in-game visual element, but took the opportunity to improve every aspect of Mini Metro's visual design. He kept Helvetica as the typeface, but redesigned the user interface to be very much its own thing, while still echoing the classic MTA design. He rebuilt the city you fly around in the menu, helped storyboard the tutorial, redesigned the in-game interface for both desktop and mobile, and took care of all of the marketing materials. The icon, Steam capsules, box shots (not the German cover!), pseudo-3D wallpapers, trailers, these are all Jamie’s work.

Collaborating with the right people helped us turn Mini Metro into a polished, critically-acclaimed title. It’s been nominated for both its visual and audio design, and picked up Excellence in Audio at the 2016 IGF. Mini Metro may have still been successful if we’d licensed stock music and kept our amateur graphic design, but it wouldn’t be the game that we’re proud of today.

Collaborating with just them and no more meant we kept our sales requirements low. Mini Metro doesn’t have to provide incomes for a team of ten, just the two of us full-time and Jamie and Disasterpeace part-time.

5) Privilege

We’re white, male, and were born in a first-world country. Our parents weren’t especially wealthy, but they did make sure we had up-to-date computers. They paid for our university education. We both walked into programming jobs at a local game development studio. After we left, we had the luxury of being able to fail and learn for years without risk of financial hardship.

This isn’t to say that Mini Metro couldn’t have been built without all of these privileges. But it would be foolish to say they didn’t make the job a lot easier.

THINGS THAT DIDN'T GO WELL

1) Ad-hoc project management

"We spent at least a year saying that we’d be finished in about two or three months. This created a lot of confusion both with our audience as well as our personal situations."

We structured our work on a very casual basis. We’d have rough ideas about what we wanted to work on next but no formal plan of who was doing what and when. This led to feature creep “Oh, it’d be cool if we did this…” and to us having no realistic idea of the final scope or how long it would take us to get there. We spent at least a year saying that we’d be finished in about two or three months. This created a lot of confusion both with our audience as well as our personal situations.

We knew that a mobile release was inevitable—in fact, that was what we were originally focusing on, until we changed tack to desktop because of the viability of Early Access. Because of this, during the Early Access period we’d often jump the gun on mobile work instead of focusing on finishing the core game. Most of the time this work would be on something that would have had to be worked on at some point—performance on low-end devices, a build pipeline for automatic deployment to devices, reworking the interface to be touch-friendly, etc.—but ultimately it was diversifying and confusing our efforts, and delaying both releases.

We did a lot of things that we’d have never gotten away with if a producer was on the team. Despite writing the game in Unity, we had no desire to use Unity “properly” so used it as little more than a cross-platform C# engine. We embraced Matt Rix’s Futile framework and made no use of the editor. Not only did we make minimal use of the Unity Asset Store (the one plugin we used was Gregorio Zanon’s G-Audio Toolkit), we even spent valuable time replacing some core functionality of Unity, such as audio and texture compression, with our own native plugins.

Looking back on this, it’s probably fair to say this was caused in part by Mini Metro being financially sustainable since the launch on Early Access. It was selling enough to pay ourselves a reasonable amount so there wasn’t that usual financial pressure on us to ship. Coupled with our perfectionist tendencies, and no-one taking the producer role seriously, we were never going to manage that freedom well. It inevitably ended up drawing out the development time. It still is—as of writing, Mini Metro still isn’t out on mobile!

2) No interest in business development

We’re not the typical start-up, and the two of us have almost 100% skill crossover. This means that we’re fine when it comes to coding and designing, but there are a many gaps in our expertise: art production, creative direction, marketing, PR, but most of all business development.

Business is something that we both get turned off of very quickly. Once you start talking about revenue splits with publishers, contracts, playing hardball in negotiations, we both want to run a mile and start work on a new prototype.

"Our lack of business interest has also led us to not consciously identify and seek out opportunities for Mini Metro, and Dinosaur Polo Club in general."

This has led us to be overly cautious when offered opportunities. Early on in development we received four offers from publishers, all of which we turned up our nose at as we wanted to stick at it with just us and do it indie-styles. At least that’s what we told ourselves. Partly it was not wanting to think about it any more—all those Skype meetings and contract negotiations seemed a whole lot harder than coding. Partly it was not wanting to commit to taking Mini Metro down a specific path; we wanted to keep our options open.

Our lack of business interest has also led us to not consciously identify and seek out opportunities for Mini Metro, and Dinosaur Polo Club in general. We’re just going after the standard platforms and distribution models—desktop, mobile, maybe consoles—and haven’t given much more thought to it than that.

3) Differing goals

Robert Curry writes: At the time we started Mini Metro I had a web development job that I enjoyed, and saw my future there, so I wasn’t looking for a career change. The game jam was just an excuse to spend a weekend with my brother making a game, something we used to do every evening but hadn’t in many years.

"I saw Mini Metro as a neat opportunity to have an iPad app under my belt and maybe a little pocket money. My brother Peter saw it instead as potentially leading to a career as an independent game developer."

The idea came together so quickly and so naturally that we both agreed that we should take it further even before the end of the weekend. I saw this as a neat opportunity to have an iPad app under my belt and maybe a little pocket money. Peter saw it instead as potentially leading to a career as an independent game developer.

We began development on the “quick iPad release” very soon, however right from the start our differing views on what we wanted out of it led to problems. I would come home from a reasonably high-pressure job, embedded in a bank and working on internet banking software, and then try to shift gears for a few hours of development. Almost always I would sideline it and invest time in my other hobbies that let me wind down instead. Peter, on the other hand, saw this is as a massive opportunity so poured hours into it and reworked almost the entire game. After a few months the disparity became apparent and after a few tense meetings we agreed on a fairer workload and share of the (potential) revenue.

This was exacerbated by the massively successful Steam Greenlight launch. We made the natural assumption that Mini Metro was something worth spending time on and not just rushing out. The scope blew out, we got on a graphic designer to redesign all the UI, worked on new maps, more upgrades, you name it. At this stage I was torn: I was happier than ever at work, was part of a great team, had been taking on more responsibilities, and I didn’t want to give that up. But also I could see the potential of Mini Metro and didn’t want to miss out. So Peter and I made many more trips back to the negotiating table to talk about workload and revenue expectations. Needless to say this was not a pleasant time. It took a huge emotional toll and sent me to the brink of depression.

This began to turn around six months on, at the tail end of 2014: We took Mini Metro to IndieCade, and a week after we got back I took six weeks off from my job to work on Mini Metro full-time. The trip to Los Angeles was a real watershed moment for me and showed me how positive an experience games can be. I’m pretty certain that without that trip I’d still be writing banking software. Part-way through my sabbatical I realized that I wanted to work in this industry full-time again, so handed in my notice and became a full-time, permanent member of the Dinosaur Polo Club.

Peter Curry writes: After the great reception our Ludum Dare prototype had received, I threw myself into development of the commercial release. I had consciously decided on one last attempt at launching a career in indie development, and saw the concept that we'd come up with as my best shot. I saw it as my last shot, too—not only was I looking after one child full-time, but a second was en route (Mary found out the very morning that Ludum Dare 26 began). In my mind, we had nine months to ship. I knew I could only just manage development with one child, how could I possibly get anything done with two?!

Mini Metro didn't ship by the time Elizabeth was born, but we did get it up on Greenlight. Despite spending the bulk of my waking hours looking after a one-year-old, those ten months were the most productive I’ve ever been on a software project. When looking after Thomas, I'd be thinking over the current design and programming problems. I'd be so primed to work that when I did get in front of the laptop I had a focus that I have never since matched. Thomas was still waking around midnight each night, so I'd stay up until then coding. I wanted to finish Mini Metro, I wanted it to succeed, I wanted to go full-time. I wanted to call myself a game developer again.

I never considered that Robert didn't want that. I conned him into the game jam, and from that point on assumed that we had the same goal.

Robert are I are twins. We’re very alike in temperament and interests. We have no other sisters or brothers. As kids we played together all the time. We went to university together. We made games together, both in a studio and independently. We renovated a house together! We had very few disagreements, none serious. I don’t think we ever learned to properly communicate with each other because we never had a need to.

Mini Metro was the first time that we were working closely together since our lives had diverged. Of course we both knew our circumstances had changed. I had children; Robert didn’t. Robert was fulfilled at work; I hadn't enjoyed any of my paid work for years. But I didn’t realize how significantly that would affect our work together. It never occurred to me that we wouldn’t just sit down and start coding, safe in the knowledge that we were approaching the project from the same position.

"In chasing my dream, there was one other person I unconsciously sidelined. The outcome of a successful commercial release of Mini Metro would be me working on it full-time, not looking after the children. "

The inevitable result was frustration and resentment. I'd blow up at Robert over progress and we'd talk it over, calm down, sort it out. I'd think everything was fine, that we were on the same page, only to flare up again a month or two down the track. It took more than a year before I actually listened to what he was saying. To stop projecting my own aspirations onto him. It was the most confused and painful time of my life, mixed in with the ups and downs of parenting and the wonder and horror of expecting a second child. I never want to go through anything like it again.

Learning from what happened has been hard but necessary. We're trying to not take anything for granted; instead, we're taking a conscious approach to the continuing development of Mini Metro and the company as a whole. We're deliberately open with what we both want to get out of Dinosaur Polo Club in the short- and long-term.

In chasing my dream, there was one other person I unconsciously sidelined. Mary and I never discussed it, but the outcome of a successful commercial release of Mini Metro would be me working on it full-time, not looking after the children. And when it did happen, it happened so quickly. Mini Metro exploded through Greenlight when Elizabeth was two months old. The next day, instead of taking the kids out together, Mary took them both herself and I began working from home. I'd bulldozed a second person into the role I needed them to fill. I don't know what else to say. Talk to the people you care about. Think about the impact of your actions on others, especially if you’re coming from a position of privilege.

If I knew then…

For a tiny, time-poor team like we were in 2013, we think a useful summary of what we learned from Mini Metro is:

●    Be brutally honest about your capabilities. Scope to match what you can realistically achieve.
●    Prototype quickly. This does take a lot of options off the table, but that’s okay. Leave those for the future.
●    Be daring with your ideas. Innovation is your only strength. Don’t bring a knife to a gunfight, bring a bouncy castle.
●    Validate early. Don’t hide your game away. Think carefully before continuing work on a concept that you can’t get people to play.
●    Early validation efforts double as marketing and community building.
●    Keep the team lean! Bring in good people to fill just the gaps you need to. This is a common problem with student teams wanting to go professional after graduating.

But this is just us trying to deconstruct the success of Mini Metro. Game development will always be hard, risky, mucky, and unforgiving. It’s rewarding but not always in the way you hope. Mitigate the risks you can. Be brave and be honest. Respect your peers and respect your audience.

And don’t cross the streams.

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like