Players on Hatch hardly need an introduction to Monument Valley, the Escheresque puzzle game where Princess Ida is led through fantastical castles of impossible geometry. First released in 2014, Monument Valley was a breakout hit for developer ustwo games, which previously had made the colourful, psychedelic one-touch runner Whale Trail and the abstract puzzler Blip Blup. Princess Ida’s mesmerising journey of illusion has also grown into something of a cultural phenomenon, giving rise to a sequel – Monument Valley 2 – and a forthcoming Hollywood movie.
The story of the making of Monument Valley has been told before, in many different media, and is perhaps best told by the studio itself. But I wanted to find out more about how a relatively small team made such an outsize impact on the industry and culture at large. How is the studio organised? How does it decide what to work on? What can indie developers learn from their experience? So while in town for a conference, I leapt at the opportunity to visit the studio’s premises in a converted pickle factory in south London, and sit down with the studio’s head of development, Peter Pashley – or just “Pash” around the office. What follows is an edited transcript of our conversation.
How did the studio get started and how does it work?
One of the things that makes us unusual is that we’re not a games studio that has come together out of the ruins of other game studios, which seems to be how most of the game industry seems to happen. People leave different studios, come together, and make a new studio, like a phoenix from the ashes. But that’s not how we formed. We were an initiative from a design studio to reach out into games. What that means is that our DNA from the beginning has been based in user experience and design, rather than in more traditional game industry working practices. We have a tight focus on the player, on the user, and we try and keep that focus there as much as possible, keeping a holistic view of what the player’s personal experience or personal journey is to and through our products.
That DNA also means that our foundations are in quite new ways of working on software development – very agile, very small-team based, non-hierarchical based ways of working. That’s something that has become more fashionable since we started, and is not so new anymore. But it has definitely imbued us with a way of making games which isn’t “sit down, write a Game Design Document, and then build it.” It’s an iterative process of actually thinking that you’ve got the seed of an idea, building it out, trying it out with users and then building on that and seeing where it goes.
When it comes to how we organize the studio, that makes us a bit different to other games companies, because we are looking more for teams to work as a team and for ideas and concepts to come from those teams, rather than those teams just being given something to implement.
When you’re finding those people to work with – when you hire up – how many have a background in games?
We try to recruit from as broad a range of backgrounds as possible. In some roles that’s easier than in others. We find that in the more technical roles, you pretty much have to have some games experience. You have to know what a polygon is and what a frame is and so on. Otherwise, all of that person’s ways of working kind of have to be relearned. But we think that people who have experience doing things in addition to games are an integral part of the melting pot of experience that we want on the team. We want to draw as much as possible from outside of games, and gain inspiration from outside of games. One of our goals has always been to make games that feel like they’re part of mainstream culture, rather than being bounded to the cultural norms of games. And that’s something that has happened to the games industry – especially the indies – over the last five years or so. But it’s something that we try and keep in mind when hiring, that recruits have lots of interests outside of games.
I get a sense from walking around the studio here that people have a broad variety of interests, and deep interest in other humanities as well.
If you look at the games industry 30 years ago, they were basically engineers – creative engineers, but there was this kind of engineering assumption that making games was a difficult engineering challenge, and studios would be quite focused on engineering. The more creative, “arty” parts would maybe seem like a splash of colour in an otherwise grey office. But the power of hardware and the power of software has got to the point where engineering is much less a complicated part of making games than it used to be, especially for our kind of projects. And that’s one of the things that we always try to ensure: that the way we work is very friendly for non-engineers, for artists and designers. If people are struggling through horrible tools or whatever, we’re not going to succeed. So making things user friendly for the designers and artists and really fast for them to iterate on is really important. That is something that Unity has helped the entire industry to do.
Does the studio work exclusively in Unity?
Everything we’ve made after Whale Trail – which was made in a custom C++ engine and was the first thing I worked on at the company – has been in Unity. It was around 2011 or 2012 when we got to what was – for us – the tipping point where the hardware was decent enough that, even if Unity wasn’t the most optimised thing in the world, it was still good enough to do cool stuff with.
It’s quite an evolution from Whale Trail to Monument Valley. How did the studio make that journey?
Whale Trail gave us an appreciation for visuals that are really appealing to people, not from a technical superiority point of view, but just something that’s enjoyable to look at. And it had a great song! It also gave us confidence that we can make something that has emotional impact on people.
But the other big step was Blip Blup, which is probably the least well known of our games. It was the first game that we made on Unity, and one of the reasons we made the game was to learn how to make games on Unity. The premise is that you have a grid of various different tile types, some are blockers, some you aren’t allowed to touch, some you have to touch multiple times, and so on. It was on Blip that we basically learned how to make puzzle levels.
But we didn’t do the best job of user testing. I mean, we did user testing – but we were user testing it with the same people over and over again. We were thinking “we want people who are into puzzle games to enjoy this.” And they did. It was only when we started user testing the tutorial segment that we realised that it was actually quite hard to teach people how to play the game. I ascribe the, shall we say, lack of success of Blip to that. Because I still think it’s an enjoyable puzzle game to play – If you can figure out how the mechanics work.
It was this experience that, in a lot of ways, drove the design considerations in Monument Valley. We knew that onboarding was critical, and so we were testing that from day one. The first two levels that we built are actually the same first two levels that made it into the final game. And those were the levels that gave us confidence that we had a product that you could just put in anybody’s hand, without any instruction, and they would have a great time with it. That was the point when we greenlit it – we know what we’re building now, we’ve got these levels which are proof that not only is it a cool concept, but we can actually get people into that concept. We learned that lesson the hard way on Blip.
So while I wouldn’t say that Monument Valley directly flowed out of our first two games, I don’t think we could have made it without those learning experiences beforehand.
How do you decide what projects to prioritise and work on? How would you advise small teams just starting out?
The first thing I need to say is that you can take pretty much any game idea and polish it up into an OK game. But finding something that has the potential to really feel new, and to excite players because of that newness, is like panning for gold. It’s impossible to sit down and say “we want to think of a really new idea.” These ideas come from random connections between other things that you are thinking about.
So not trying to rush it, giving yourself time, making sure that you try lots and lots of different things and setting some kind of a time limit on an individual idea – that is really important. If you can’t get something that feels exciting – without you having to try to get excited about it, and is exciting to other people – then move on to the next thing. Because when you do find that nugget of gold in your sieve, it makes everything else easy. You have the confidence that your game is built around this great idea, and all you have to do is do it justice. That nugget of gold becomes the self-motivator for the rest of the project. Not only is it a core of gold, it’s a shining beacon for what the game wants to be. And if you listen to that, you can follow that to a great game.
I’ve heard musicians say the same thing about making music, and writers about their work. Do you get a feeling that a game “wants” to be something, and it’s kind of demanding that you do it?
I think so. For me at least, I feel like there is a reason to make this thing which goes beyond “I want to make it.” It’s clearly a thing that should be made – and other people can see it as well. If you can figure out why that thing needs to be made, if you can listen to it clearly enough to actually be able to hear it, then you can validate what you’re building against that.
For Monument Valley, we had it easy because the twin concepts of “cool, tiny castles in your pocket on your screen” and the impossible, Escheresque geometry are intrinsically nice to interact with, and they light up people’s brains. I still remember when we went to GDC for the first time with Monument Valley and we were showing it off just before release. On the first level, where you rotate a bit of architecture so that it forms a Penrose triangle, almost without exception people would emit a little sound of relief and enjoyment – “oahhhh.” It was a quiet noise, but the fact that people involuntarily were making that noise meant that we knew we had gold.
With Land’s End, which is a VR title that we made between MV1 and MV2, it took us a very long time to get to the proof of concept. The ability to spend that much time chasing that feeling – we could have put something out much earlier that just wasn’t very good – and having the luxury of time to go “right, this doesn’t work, let’s try again,” and the determination and persistence to keep pulling at that thread is something that not everybody has. And that’s definitely a luxury that we have. The backing of the bigger ustwo design studio allowed us to do it for Monument Valley, and the success of Monument Valley enabled us to do it for Land’s End.
I can imagine many game studios not being nearly as patient, because they can’t afford to be.
Exactly. That mindset might give you some surefire money in the near term, but I think if you’re putting something out that you know is not the right thing, then you’re shooting yourself in the foot when it comes to the potential of that title. It’s unusual that something is going to do really well if it’s not really fulfilling what it “wants to be.” Sometimes you can just polish something so much that it’s good anyway. But then, that requires spending loads of money too. So do you spend that time at the beginning of the project, when the team is small and you can iterate quickly? Or do you spend that time at the end of the project, with loads and loads of people and it’s really expensive? My preference is always to make sure that your business has the luxury of time for a small team to figure out what the game needs to be.
Your colleague Dan Gray gave a presentation at Pocket Gamer about succeeding as a premium mobile game developer, and trying to find something that is special when there’s so much “free” competition out there. Have you ever thought about making a game on the free-to-play model?
We’ve made various attempts at making a free game, and what it always comes down to is that we feel like we’re building a monetisation scheme rather than an excellent game. The kind of games that we’re interested in making tend to be quite polished and bespoke and small-scope, and as far as we can see, the only real way of making money out of a free game is that it has to be something that takes a lot of your time to play. We’ve always had a focus on making games that fit into people’s lives. Even seven years ago, we were busy people that didn’t have all that much time to play games, and we knew that we wanted to make games for people who also don’t have all that much time to play games. Why can’t games be like films, which are an hour and a half duration and you get that all-killer, no-filler experience? You come away thinking, “that was an amazing hour and a half of my life.”
But we would love to find a way to make a free game, because that means that more people can play our games. That’s a big part of why we want to make games – we want to make claim to a broad audience and mainstream culture. What we do know is that there is a market for something that’s relatively short but that people feel is valuable to them. That they come away from that time thinking, “I did not just spend my time, I’ve given myself an emotional, experiential shot that I wouldn’t have been able to get in any other way.”
And that will never go away, in the same way that films will never go away either – even though you can do different things with longform TV series, for example, than with film. They’re both great. The same applies to games.
Hatch was founded in part because we believe that there has to be a way to bring these relatively brief, premium games to a bigger audience – “There’s this subscription service and it’s reliably providing me with interesting experiences, something that will mean something to me and sit with me after I’m done.”
I think of it often as being about stories. Humans are for whatever reason evolutionarily designed to enjoy stories. But a story has a beginning, a middle and an end. If it doesn’t conclude, if you don’t get to that point where the things that the story’s been telling you make sense, then that story is no good. Or it’s not a story. But play isn’t a story, play is “I do this thing that makes me feel good,” and maybe there are social elements and such too. Games exist in a strange amalgam of play and narrative. Some are more toward narrative and some are more toward pure play. But stories are never going to go away, and I think certain kinds of stories we can make more powerful by making them interactive. That urge to make them more easily available to more people is great.
That’s a good note to end on. Thank you!