“Monaco” – A Technical Readout 10 Years in the Making

First, please watch the video below to understand the concept surrounding this game. I’m not asking for the whole 15 minutes, but I ended up watching it all so maybe humor me for five of those 15 (that’s about as long as Gangnam Style):

I hope that has piqued the interest because I’m about to say a bunch of words.

Monaco is a three-way marriage between top-down game play and its two wives: co-op and line-of-sight. For those unfamiliar with the phrase “top-down” just imagine playing Pac-Man. “Co-op,” for those really bad with context clues, means two to four friends can play together and this “line-of-sight” technology is what makes Monaco into a puzzle. The characters consist of eight different retro-looking sprites all possessing one passive ability (no buttons to press) and one active ability (triggered by a button). Line-of-sight is a huge part of this game, so let’s talk about it more.

In an hour long talk at the Game Developer’s Conference (GDC) titled, “How to win IGF in 15 weeks or less,” developer, mastermind and genius, Andy Schatz, talks about his award-winning game Monaco. In the section, “No Consensus on a Standard Roguelike Visibility Algorithm,” he talks about how he developed the key element in Monaco – a limited line of sight. The Secret Code video above demonstrated this. As the player, you can only see what’s in your line of sight. The rest of the level looks like a blueprint of the room. This easily frustrates the hell out of players. With guards, security cams and dogs patrolling the building, you and your character have to make the right choices, sometimes before you’re even aware of what’s around the next corner.

Line-of-sight visibility is created by mapping the game in tiles. Imagine a blueprint cut into bunches of tiny blocks. These “blocks,” or the more technical word, tiles, are shaded for walls and clear when, well, rooms are clear. The tile-editor Schatz used was one of his own creation. He started with the tile-laced blueprint and the computer would check every single tile between point A and B to determine visibility. That is probably the most time consuming way to do it. If a map is about 400 tiles and the AI’s line of sight is 20, every time that AI makes a step, it has to re-evaluate every single tile it its line-of-sight. That’s a lot of work and I don’t even math. After much trial and error, Schatz landed on a “caching” system. Instead of evaluating every tile from player to target, just shoot straight for the target. If the target is visible, all the tiles in between must be. Simple, effective and plain brilliant technology.

Schatz also talks about the usage of sound in Monaco. He wanted to cross the uncanny valley not in images, but in recognizable sound. In short, the “uncanny valley” hypothesis basically refers to anything that looks and acts as close to human as possible but isn’t quite human – it’s uncanny! For Monaco, Schatz felt this uncanny valley would be best crossed by using sounds from the real world. “You can jump right over the uncanny valley in sound, but still remain incredibly symbolic in graphics,” says Schatz from the GDC video. Hence, using 8-bit sprites instead of making human renderings. He explains that a French guard yelling, “Stop!” heightens the sense of panic and escape in a player. In the Secret Code video, the guy playing the demo really hated seagulls screeching and I even jumped hearing the dog bark. Schatz got all his sounds from freesound.org and Austin Wintory (www.austinwintory.com) is composing the soundtrack. Below are some screen shots of the sound credits detailing what sorts of sounds are from the real world among them sounds like “running up the stairs,” “metal door slam,” “helicopter start,” “water drip echo” and “male breathing.” Back in the Secret Code video, the little sprite takes a piss which sounds totally real. Must have been awkward looking up that sound effect… Full album here.

Credits of sound screenshot (thanks Nolam)

Sound credit screenshot 2 (thanks Nolam)

Players can also develop their own levels to share with friends. At the GDC, Shatz talks about how as he was playing he would build things only as needed, so he eventually built a level-editor. He also worked out networking so friends can send each other their levels over the Internet. The level files are only around 3kb of data so saving them won’t take up a bunch of space on a hard drive.

The tech behind player-made levels, quite honestly, confused the hell out of me. After much reading and re-reading, however, I’ve finally come to a simplistic explanation. Step one: A player creates a level. Step two: The level data is read by the computer and it renders a side view of what the level looks like. Step three: All the level data is actually stored across the side view render, thus keeping the level all together instead of having a bunch of zipped files. Those with experience sharing custom levels with friends will understand and for those who don’t, just think of it this way: a .zip is a folder that has condensed multiple files into a workable size that when “unzipped” at its final destination releases all the files within it at their full size. Like zipping your jacket keeps that neon colored shirt out of view from the rest of society, then you take off the jacket and BAM, blind people everywhere. This is called Steganography. “[A]ll I’m doing is taking all that junk level data, and spreading it like butter across the least significant bits of every pixel in the (side view) image,” says Schatz in his Facebook blog. If you’d like to hear more about it, check the GDC video at “Level Design is Slower than Coding” or read this Facebook post. Here’s a picture of the “side view:”

On the Monaco Facebook, Schatz attempts to look at level building in a different way. Instead of solely letting the player go out and make their own (which is why things usually end up in shit), the custom levels should be thought of as a community. Players helping other players improve their levels. Haven’t heard too much else about this, updates will follow.

Design was another area that gave Monaco some hardship. Andy Schatz brought on Andy Nguyen (fondly called “the Andys” in the Monaco chat) to develop levels. Schatz was excited that he could now play levels where he didn’t already know where all the security was and Nguyen was pumping out levels fast. In an email, Nguyen told me, “Design is complex due to its ambiguity and our limited history (games only having been around for 30 years compared to other media).” Monaco deals in tiles and so Schatz decided to embrace the concept of a square. Squares are hidden, crunched and squashed within other squares on almost every inch of the game. Will be posting more updates about design when Nguyen and Schatz finish a week long de-bugging process. They NEED their space.

Finally, I read an interview with Schatz on Indie Game Challenge and he summed up the game in one simplistic paragraph, “There’s never been a game like Monaco. It combines old-school top-down gameplay like Pacman with character-based co-op games like Team Fortress, and mixes in some beautiful line-of-sight technology from indie rogue-likes. This is a game that should have existed years ago, but for some reason, has never been made until now.” Another incredible aspect is that Schatz had never used C#, a type of programming language, until he started Monaco. So, not only did he develop his own game, he also developed his own tile editor and learned the programming language. Monaco was built essentially from dirt – digital indie game dirt located in the beautiful Mediterranean city, Monaco. Andy Schatz has been thinking about Monaco since 2003 and, ten years later, he’s opened for pre-orders and is fixing bugs while you read this 1500 word blog. Visit the site http://www.monacoismine.com

Big thanks to Nolam for the screenshots of the credits, Andy Nguyen for answering my emails, Monaco’s Facebook blog for supplemental info, the GDC video and Andy Schatz for creating a very cool indie game.