Making the impossible possible in Monument Valley

Monument Valley was born out the desire to make a game about architecture. UsTwo's eight-person team imagined a game where every level would be clean, a single striking design object that might look good on a poster. In 1934, Oscar Reutersvard pioneered the modeling of "impossible objects", 3D objects that make a fundamental sense if viewed in parts, but defy logic when viewed as a whole. The so-called "Penrose Triangle" and the work of M.C. Escher were elaborations on these basic ideas, and were clear influences on Monument Valley. You can make these objects work in the real world, but only from one particular direction: Something that looks like a triangle from one angle is a jointed 3D path from another. The eight-person team modeled objects like these in Unity, and found the key was getting them to line up just perfectly. Having the tiny, white-capped character of Ida walk correctly on the world and all its angles was an interesting technical challenge, explains tech director Peter Pashley. "Building the shape is relatively easy: You put together a bunch of cubes with one triangular bit, and it's easy to make it look right. The hard thing is getting that navigation and locomotion to work properly," Pashley says. The navigation system had several goals: Level designers would have to mark up walk-able areas, manual markup had to be kept to a minimum, and the system should find connections automatically, while respecting human perception and avoiding disorienting players too much.

Most standard navigation systems depend on the interconnections of nodes in a web; Monument Valley's nodes were dotted across the objects' walkable spaces, which allowed the team to connect nodes where Ida should be able to transition to a different part of the object. This let the team design puzzles where the player would have to experiment with their own sense of reality, and sensible connections and paths seem to suddenly reveal themselves. "Every time you made a configuration like this and then did what was necessary to stop bad connections forming, as soon as you wanted to modify that or iterate on it, you'd have to do it all over again. So we had to find a way to make it automatic -- it involves ordering those nodes in depth order from the game camera, and then going through them in depth order and deciding which ones should occlude the ones that are in front or behind." "Getting the system working took a while, but when it was finally working, that automation transformed how easy it was for us to make levels. Everything was perfectly flexible, and that suddenly made making levels really pleasurable," says Pashley. Ida's interaction with objects depends on her orientation: Something that is a ladder if it's approached from one angle could be a ripple on the floor if approached from another. "The solution is to have two nodes, basically in exactly the same place, one as a ladder and one as a floor," Pashley explains.

The complex system includes a lot of edge cases, and the team needed a lot of test scenes showing multiple different configurations, so that they could see that nothing in the design ecosystem broke when making changes within those edge cases. Specificity and simplicity is the heart of how Monument Valley functions, Pashley says. Something that looks like a smooth path from one angle becomes a broken path if the object Ida's on is rotated. To keep her from gliding in space, and to create paths that she can navigate in one configuration but not in another, the team couldn't simply build an ecosystem of predictive connections. "You build geometry which rotates, and would have to think really carefully about what's behind it," says Pashley. "We ended up only making those decision points when the geometry was in one of the snap positions, and that's a common theme of this: Making this impossibility work easily is about simplifying it. Making sure you're thinking about points rather than areas, and that you're only recalculating connections at certain points in time and in certain configurations."

UsTwo could also mark up navigation nodes as accessible or inaccessible, in part to account for the player's likely imprecise touches on the delicate shapes from time to time -- areas Ida can reach in a certain configuration have highlighted nodes, and that path of highlights shifts if the geometry shifts. This keeps Ida from walking someplace other than where the player intended, or from breaking the rules of her own universe if the player's touch is slightly off their objective. "Instant communication was really key to being able to collaborate on these levels," Pashley says. Monument Valley's levels were built in three stages: Conceived as a configuration, tested for functionality and then edited to conform to the game's aesthetic principles. Minor duplication and transformation of simple building blocks in Unity, then adding navigation markup directly to the geometry made it relatively easy to experiment quickly with new ideas, and it also made the team comfortable throwing things away and only pursuing concepts that really worked. After building the level geometry and concept in a "whitebox" stage, the next phase involves making the world "visually functional." "Often there are elements players don't understand, because their geometry is all the same color, and you have to call something out," Pashley says. Just minor differentiations in color made levels easier to develop, test and prove. "The 'visually functional' stage was the point we could make a decision about a level, and say it works, and is good, and we could commit to spending the resources to making it look really pretty," explains Pashley. Ten months isn't a particularly long time to create a game, so the team took pains to ensure it was spending its time wisely when it came to investing in visuals, and did all its experimentation and throw-aways earlier in the level refinement process. Very little went to a stage of further polish without the team being absolutely certain that it wanted to include the level.

The geometry was made of quads instead of cubes, so as not to waste polys and to make levels easier to texture. "That was a critical part of the pipeline for us: We wanted the artist to really quickly be able to add variety on the geometry. We knew we wanted clean lines, but we also wanted to be able to get new artwork in there as quickly as possible," Pashley says. "We didn't use standard 3D lighting techniques: Point lights won't work, because here, things that are next to each other aren't next to each other," he explains. "And we wanted to keep the pipeline simple." The use of quads, though, meant that there was still some "sparkling" behind the seams of the world, and some artifacting. So before final builds, everything gets exported, which takes massive lists of quads and condenses them into a combined mesh. "This is really important: It's how we make something that looks good, but runs well," says Pashley. As for the actual rendering, the team starts with textures, applies textures, and develops a clean and basic look for the game. "But it somehow feels 'dead', and what we really wanted was for this to feel like a real world, 3D and weighty, with an illustrative quality." So the team applied ambient occlusion through standard unity light map generation tools -- it doesn't just look better, but creates a real, "chunky" feel for the game's geometric places. They also applied a semi-transparent quad oer the entire works, creating a gradient overlay. "It just brings it to life a bit," he says. Lastly they apply vignette around the edges, achieving the feel of a real, printed piece of artwork. "It ends up with a bunch of art we can hang on gallery walls, that people will buy, that allows us to say we fulfilled our aim of making each screen of game something you'd want to print out and frame, and hang on your wall." "The process of making your game is a user experience for you as a game developer, and you should make your tools as easy as possible."