Agents vs Operatives (aka Spy Break)

spybreaklogoBack in 2008 when I was a managing partner at Polycot, we had an idea for a Facebook game.  I’ve always loved the spy genre, and it didn’t seem well represented, so we spent a few months of idle time writing up specifications, prototyping screens and mapping out how the application would work.  After it became obvious we didn’t have the budget to develop or launch the game, we shelved the project.  In the spirit of sharing ideas, here’s a glimpse inside the first phase of a game project.

Back Story

Agents vs Operatives, or Spybreak as it might have been known if it had reached the light of day, was a Facebook game.  Our setup was that players had been recruited as either Agents (good guys) or Operatives (bad guys) by competing cold war era organizations:

GALAXY – Global Alliance Limiting Aggressive Xenophobic sYndicates

and…

KOSMOS – Kommitte Over Sabotage and Mayhem, Overseas Services

Our design theme was inspired heavily by the early Bond films, the Flint films, Get Smart, and the fantastic game No One Lives Forever.

The Game Experience

UI Comp
User Interface Comp

The spy genre gives us a nice set of tools to make a game with.  There’s a spy (the player), bad guys and traps (obstacles), cool items (inventory), and exotic locations (setting).  I’d played a lot of Kingdom of Loathing, which has a similar set of elements, though KoL is an extremely silly parody of the fantasy genre.  We wanted AVO to be wry and funny, but not silly.  Like NOLF in theme, but KoL in experience, if you will.

When you’re developing a game you have to think about how people will play, and design a game to suit it.  Facebook games need to be playable in small chunks, though you may have a lot of time to burn, not everyone does.  We wanted a game you could play a mission or two of over your coffee break, and feel like you’d accomplished something.

We had three classes in the game: Muscle, Tech and Spook.  Tech characters would be able to crack security systems and take shortcuts while spooks would be able to use disguises or sweet talk their way around bad guys.  Muscle characters would just fight their way from one end to the other.

We decided on a mission setup where the player worked their way through a random arrangement of rooms (a dungeon) populated by randomly generated but thematically appropriate bad guys (monsters), trying to get to a goal, be it a safe with documents in it, a piece of stolen technology, or what have you (treasure).  We wanted to have at least a selection of classes available who would have different experiences, so we added the idea of optional routes that you could only get to if you had certain skills.  Here’s what we were shooting for with our random dungeon generator:

Test Dungeon Outline

When you started a mission you’d be dropped in a mission start area, like a square outside of a museum or a back alley behind a warehouse.  We had a selection of areas, in which we’d create some generic room types.  For instance the museum area would have a loading dock, an atrium, a long hallway, a display room, a break room, etc.  The game would put together a random arrangement of these areas when the mission was started, so each mission would feel a little different.  We also wanted some thematic variety, so we came up with the idea of having theme sets for areas.  For a museum you might have a cephalopod museum, a historic losers museum, a doll sized furniture museum, etc.  We’d differentiate these by substituting description phrases in the generic room descriptions, so the room might be:

You’re standing in yet another hallway. Marble columns arch from floor to ceiling evenly along the length of the hall. Security cameras sit high in the corners %instance_variable. The floors are spotless, shining in the glow of incandescent lamps set into small alcoves. A threadbare rug extends the length of the hall.

There is %roomlib_title here.

Assuming this was a Cephalopod Museum, into that we would substitute an instance variable like ‘above seashell sconces’ and the roomlib title would be ‘an angry-looking octopus’.

Those who have money do art, those who don’t have money do text.  Fortunately with layered graphics we figured we’d be able to create generic room backgrounds and then drop unique sprites on top of them as we had money to pay artists.

The rooms would be populated by thematically appropriate bad guys, and to proceed through the room you’d need to defeat or incapacitate them.  You’d get equipment for completing missions or helping out your friends, so you’d have leveled guns or grenades or disguises, if you were a spook.  Get through all the rooms and you successfully complete the mission.

Mission SelectionAs a Facebook game, you need to limit the amount of content and progression players can burn through in a sitting.  Otherwise, assuming your game is fun, they’ll burn through all your content in one sitting and then be done with it.  We planned on doing that by limiting the missions available to players.  We’d have low-value missions available regularly throughout the day that were only available for a set time (like the next 3 hours), and daily missions that were high value that were available all day.  You’d be able to help out your Facebook friends who were playing the game by sending them access to mid-value missions.

We also had the concept of multi-player missions, so the reward wouldn’t unlock unless all of the players who agreed for the mission completed it within the set time.  Since we were allowing good guys and bad guys, you’d also be able to PvP with other players, though we didn’t prototype that too heavily.

Over time you’d level up, gaining the ability to go on multi-player missions, go on missions in cities other than your home city.  We’d differentiate cities with unique areas and unique variables, so Paris might have a Stinky Cheese museum and cathedrals while Los Angeles might have a Plastic Surgery Parts warehouse and movie sets.

A Tragic Fate

In the end we didn’t get beyond a simple web demonstration without enemies that Ethan built in rails.  As a consulting shop we’d have had to finance it with profits from other projects, and since everyone had bills to pay, those profits never stayed around for long.  Not having a graphic designer on staff also meant we’d have to pay other folks to do a lot of work, which became a major stumbling block.  We probably could have repurposed this idea for an iPhone game, but by the time that platform was ripe we had other ideas to try.

I’ve uploaded a bunch of design documents to github, if you’d like to check out more.  Maybe someone will take the idea and run with it.  It’s still a game I want to play.

Leave a Reply