A new player has connected.

connection_foundA few months back, we received an email with a strange request. Admir is a Steam gamer, who described to us an uplifting friendship he’d developed over two years with a fellow gamer, Lina. He spoke wonders of her tirelessly cheerful personality and the positive affect it had on his life. As it turned out, Lina is a fan of Splice — and her birthday was fast approaching. He wondered if there was any way we could help him show his appreciation. The line that did me in was:

“Her name is Lina and she is someone who influenced me and changed me for the better and I couldn’t be more happier that I know her.”

And something about people coming together through games to make each other better people just resonated with me on that particular day. So, feeling inspired, I wrote a small piece of music for Lina, in the style of Splice. (From what I hear, it was very well received)

Within our community, we all know people for whom the unforgiving pressures of life and industry prove to be too much to handle alone. And often, when we need a helping hand or a kind word, we find it altogether too easy to become more withdrawn and isolated, stubbornly maintaining that our problems are ours alone. It is in those moments that we need each other the most.

Games can provide distraction, yes. But they also provide a space to connect. For one of our games to be part of that connection, no matter how small, is an enduring reminder that we all possess the ability to bring joy to each others lives.

Why do I make games? For simple, human moments like this.

Happy birthday, Lina!

Permission, Dedication, and the art of Game Jams.

For over 3 years now I’ve been hosting a weekly event in Philadelphia called Dev Night. The main purpose of this event is to help grow and centralize the gaming community in Philadelphia. One thing above all others accomplishes this task: our Monthly Game Jams.

What is a Game Jam?

For people in the gaming industry, the term “Game Jam” means a ton of things. But what game jams do very well is bring people into the community. So what is a Game Jam? It’s an event where people come together to make games based around a theme in a very short amount of time. Some times you have 1 hour (Zero Hour Game Jam); sometimes you have 48 hrs (Ludum dare). Other times, you don’t know what the hell you’re going to get (Philly Dev Night).

Why do we Jam?

I run a game studio called Cipher Prime, organize events like the Geek Awards, and manage the Philly Game Forge. My day-to-day is always crazy and involves a lot of disciplines. I also have to be quite resourceful with my use of time. Holding back on experimentation helps me finish my goals faster most of the time. But, experimentation in my craft is what makes me better and sharpens my skills. Game Jams are not just something I want to do, they’re a thing I need to do. If I want to get better, I need to take risks and I need to work under pressure.

Why does it work?

We’ve all heard the saying, “Practice Makes Perfect” and a lot of us have also heard,”Perfect Practice Makes Perfect”. We’ve heard Malcolm Gladwell talk about the 10,000 hour principle in Outliers, and we’ve read inspirational books by Tim Ferriss. But, what really helps motivate me and most of the people I know is *proof*.

Loish is one of my favorite digital painters. But she didn’t start off brilliant. She started off with passion, and became amazing through dedication. I recently did a talk on this concept: Dedication over Motivation. The games industry is rather new, so it’s hard to have 100’s of examples of qualified growth. In the BuzzFeed era, we readers and consumers seem to need everything in quick graphs. So here is the growth chart that Loish did, that chronicles her growth from 2003-2014 .

Yeah, it’s awesome. But guess what: Your games can improve like that too. Here is a screenshot of my first game I made in 2004 called BBO. And here’s the remade version called Intake made in 2013.

@willstall - 10 years of game design


Also, Game Jams are about finding the people in your life who are going to inspire you to become better. As you grow, so will those around you. Game Development is a Coop Team Game and you’re going to want those skilled friends once you start tackling some seriously large projects.

Why doesn’t everyone do them?

All the time people come to me and say there is no way they can make a game. It seems like people need permission to even try. For all those people, game jams are my way of saying, “I’m giving you permission to be great.” If you came up to me at Dev Night tonight and told me you couldn’t make a game, I’d ask you if you ever played tag, or checkers, or any other type of game that’s ever existed. Eventually, you’ll say yes. Then, I’d challenge you to make a “house rule” for that game. Most people already have these for their favorite games. Good news folks: you’re already game designers.

The Challenge

For everyone who is interested, I’d like to challenge you to be a better you. Do the thing you love; monthly at the very least. Test yourself regularly and set some goals. If you love making games, I’ll see you at Dev Night. If something else is your poison, I’ll fucking cheer for you. Let’s be awesome together. Let me know how it goes.

What do you do?

It’s Philly Tech Week here, which means lots of events, meetings, and conferences. Many business cards exchanged, many more names told and quickly forgotten because let’s face it, we’re all terrible at names. But more often than not, every new conversation starts with the same four words:

What do you do?

And as someone who makes games for a living, it’s actually kind of hard to answer. Gaming is a young medium, and as you talk to people outside the industry, you realise we have nothing close to the vocabulary needed to describe what we do.

What do I mean? Well, lets look at some other media.


Words: what do you do?
I’m a writer. A poet. A story-teller. A blogger. Author. Editor. Copywriter. Wordsmith.

I write poems. Novels, novellas. Magazine articles. Blogs. Epics. Tall tales and short stories. (I tweet.) Because I know, in my hands, the word is worth a thousand pictures.

Pictures: what do you do?
I’m an artist. Illustrator. Painter. Graphic Designer.

I do fine art, and illustrations. Character design and visual identity. Realism, surrealism; cubism and modernism. I paint “ism” on a wall and dare you to tell me it’s not art.

Sounds: what do you do?
I’m a composer. Singer, song-writer. Performer. Instrumentalist. Musician.

I write songs, and albums. Concertos and scores. Sometimes a jingle; sometimes a ditty. I jam for hours with no clear goal in sight, and come out with rhythms that make you remember when we were naked and free under the ink-black sky.

Video: what do you do?
I’m a film-maker. Director. Auteur, if you’ll allow it. And yes, an editor,

I shoot videos, movies, TV shows. Documentaries and exposés. Vignettes, here and there. I’ve been known to vlog. I show you a window to the past or a glimpse of the future, take you to faraway lands real and imagined — and you don’t even have to lift a finger.

Games: what do you do?
I make games.


Which of course is bullshit. We refer to Cipher Prime’s games as “Arthouse Games”, which needs still more clarification as “Think about the movies at Sundance, but instead of movies it’s games.” Trying to explain the differences between Flower and Mortal Kombat X can be frustrating, because we have to rely on the vocabulary of other media.  Mortal Kombat X is your Hollywood blockbuster; Flower is a collection of poems. But at the end of the day, they are both still considered “games”, in a way that an action movie and a book of poetry would never be called the same thing.

I’m genuinely curious about this. I wonder, in a decade, what words we’ll use to describe the experiences we make. And maybe that’s our responsibility, to start creating and using those new words.

But I need some new words *today*. So let’s try this again.

Games: what do you do?
I’m a game maker. Yes, an author. Yes, an artist. Programmer, maybe, but logician certainly. I’m an emotional manipulator. A rule-maker; a rule-breaker.

I make games. I distill dreams; I create universes. Playgrounds, sandboxes, and toy chests. Experiences. I reject your reality and substitute my own.

At the end of my GDC talk, I remarked that I create illusions for a living. The more I think about that, the more I realise it is an absolute truth. We use arcane languages to interact with hidden worlds using forces we can hardly explain to extract an emotional response from our audience. And we’ve done it for so long it’s become mundane to us, but really — have you ever tried to explain what you did at work today to someone outside the games industry?

So what do we do?

We are — all of us — magicians.

My First Unity Game in a Week – An Intern’s Tale

Hello all, I’m Mary (@MaryKCassin), and I’m the new intern here at Cipher Prime. I’m currently a rising junior at Ringling College of Art and Design studying Game Art and I’ve been interning here since the beginning of May.

My first full-blown assignment as a Cipher Prime intern came on my second week here:

Create a game in a week using Unity.

I was a little daunted, because I had never touched Unity before or made a functioning game. I knew I had to keep it simple, but I still wanted the game to be entertaining.

Then Christiana, a fellow intern, thought I should make a drunk simulation game. The goal would be to try and keep your drunk character from tipping over by using the arrow keys to keep him upright. I thought this was a great idea and that it could be even more fun if I made BJ, our boss, the main character.

Get BJ Home” was born!

Intro slide

Intro Slide  death slide  Screen Shot 2014-05-30 at 3.02.35 PM

Learning Unity

My first challenge was just getting to know the nuts and bolts of Unity. To get myself started, I did a “make a game in 15min” tutorial on YouTube. This tutorial coupled with my previous knowledge of UDK and UE4 gave me the confidence to jump into a strange new development tool.

Drunken Movement

How do you simulate a drunken walk?

First, I had to figure out how to apply physics to the character as well a way to control the character while having him drunkenly stumble down the street. Funnily enough, this was the easiest problem to solve. I realized if I just made a triangle mesh with the point facing down and turned on gravity, you’ve got a “drunk” mesh.  I added a script that made the player rotate on the x-axis using the arrow keys and that was that.

Then I had to figure out how I was going to move the character down the street. At first I though I would just move the scene so that it appeared that the player was moving. But after realizing that would be too much work I scrapped that idea. Then, with Zenas’ (founder of QuadraTron Games and a member of the Philly Game Forge) help, I scripted a vector lerping between two places that moves the object a reasonable speed.

Game States

Next, my game needed death and win states. This was a little more difficult. I learned about flagging and tagging objects. Zenas had to help me and do a lot of explaining, but I eventually understood the whole process and constructed a fully formed game loop!

Asset Creation

Creating the assets was fun but stressful, because I had to make a south Philly city street scene in a week. I managed to make enough assets, and when I put the lighting low enough then you couldn’t see the corners I had to cut to get everything done in time.

The Show and Lessons Learned!

 DSC_0170   DSC_0175   DSC_0201   DSC_0183

When it all came together it was pretty cool seeing that I had made a game and I think everyone at Dev Night got a kick out of it.  When people stepped up to the plate I realized that it was probably too challenging. I was the only person who could finish the level.

Next time, I know I need to get someone to play test my game before I show it off to the world. I enjoyed making the game in Unity much more than I’d anticipated, and I found out which areas of game development I need to improve on (mostly scripting). Can’t wait for the next one!

You can play my game right below here! See if you can get BJ home.

Procedural Dynamic Room Generation in “ARE”

For the Global Game Jam this year, our team wanted to make a game that behaved like a personality test. It would try to determine if you liked killing enemies, collecting items, running around wildly, or interacting with the game’s inhabitants. Once the game had a handle on what you preferred, it would tailor itself to your desires. If you liked killing things, more enemies would be spawned. If you spent a lot of time in rooms opening chests, the next rooms you went to would have more in them to explore. It was immediately apparent that a predesigned level wouldn’t work, as we wanted the experience to be dynamic and different for each type of player. So, we needed some sort of procedural room generation, and we needed it fast. I was responsible for that feature, and found it so interesting that I wanted to share how I handled it.

I’ve played a lot of roguelikes, so the concept of random room generation wasn’t totally foreign to me. However, I hadn’t seen any that really impressed me. Especially not compared to the random generators that have been made for tabletop games. Some of the better ones generate traps, monsters, and loot in addition to  basic rooms and corridors. In particular, the generators available on Donjon’s site are worth a look. Not only are they infinitely configurable, but their source code is (kind of) open! For traditional “dungeons”, they usually generate X number of rooms, and then connect them up with corridors. There’s generally a certain number of large, medium, and small rooms, but everything is calculated at once. This technique is powerful, and with enough tweaking, you can make some really nice looking maps without a lot of effort. Getting this version up and running in our game wasn’t difficult. All we had to do was have a large enough grid, randomly drop the rooms in, and then place cubes where the walls should be.

Fig 1. Randomly placed rooms. I didn’t bother writing code to create corridors to connect the rooms, because we had realized this wouldn’t work for us.

Fig 1. Randomly placed rooms. I didn’t bother writing code to create corridors to connect the rooms, because we had realized this wouldn’t work for us.

However, this technique wasn’t going to work for our game. Since the whole point of the game was to dynamically adjust to the player’s play style, a complete map generated at runtime didn’t make sense. We needed something that was totally dynamic, where levels could be built incrementally as needed. This gave me an opportunity to fix a problem I have with most dungeon generators. Since they were usually designed to be easy to draw on paper/wet-erase maps, rooms are usually defined in chunks of squares, either 5ft or 1m. This means walls are usually that thick, which is unrealistic (most interior walls are only ~6” thick!), and room dimensions would be defined in those increments. I wanted our rooms to be able to exist outside of a strict grid system, and to not waste a lot of space with walls. So, I built a relatively simple system.

Rather than storing a grid, I tracked two different types of objects: rooms and doors. Doors only stored their position and orientation (latitudinal or longitudinal), and the two rooms they connected. Rooms knew their position, size, and kept a list of doors that were connected to them. I had a geometry generator that could spit out walls, floors, and doors into the world, and could combine those primitives into generating rooms of random sizes. The system was designed so that if a newly generated room shared a wall with an existing room, any doors in that shared wall would automatically link to the new room.

Fig 2. First test of the geometry generator, creating rooms of random sizes.

Fig 2. First test of the geometry generator, creating rooms of random sizes.

From that first step, I set about building the levels additively. I’d spawn a starting room with a single door. Then, the system would select a random door that was only attached to a single room, and generate a room that used that door as an ingress. While in-game, new rooms were only created whenever a player opened a door (that didn’t already lead to a room). Assuming that each room had at least one door in addition to the source door (and most had more), the map could theoretically expand infinitely. The rooms generated this way had a random size between two bounds, which meant that they were all relatively the same size and proportions. Besides being boring, they would often clump together, and in some cases ended cutting themselves off. So, I added a way to define different types of rooms. This controlled their bounds in each direction, which wasn’t perfect, but was effective. There were three types of rooms: a small room, a large room, and a hallway, which created very long, but narrow rooms. This worked well enough for our game, theoretically, but I decided to go just a little bit further.

Fig 3. Large rooms, small rooms, and hallways. The hallways did a good job of keeping the rooms from clumping up too much. They were also fun to run down!

Fig 3. Large rooms, small rooms, and hallways. The hallways did a good job of keeping the rooms from clumping up too much. They were also fun to run down!

The problem I found was that while the rooms were generating dynamically,they didn’t align well. Two rooms would be adjacent to each other, but would have a small gap between them. Rooms weren’t allowed to be large enough to overlap existing rooms so rather than using the generated size, the generator was just creating a “closet”. Closets are the smallest room that could be generated when a door opened, just a square room where each wall is the width of a door. So, rather than just selecting a random size from within a set of bounds, I used a new method. Whenever a door opened, the system would generate a closet. Then, the closet would inflate over a series of iterations based on the type of room it was (using the parameters from the previous method). When the room reached a size where it could expand no further, or it had finished its expansion iterations (which were limited per room type), it would project outward to see if there were any other rooms close by. If there were, it would expand just far enough to become flush with the nearby rooms. This way, if two rooms were close, and their shared wall had a door in it (which would lead to nothing), the new room would expand enough to utilize that door. If it didn’t, the door from the existing room would most likely have little space to generate a new room, and very tiny rooms were not something we wanted to see too many of.

Fig 4. In addition to linking together better, the new room generation had different colors they could be decorated with!

Fig 4. In addition to linking together better, the new room generation had different colors they could be decorated with!

The maps generated with this new technique were much more interesting to navigate, as well as connecting much more fluidly. Since this was game jam code, though, it wasn’t perfect. The final expansion step only checked for rooms in cardinal directions from its center and corners. Which meant that for a larger room, it was possible that a smaller room wouldn’t be hit by any of the rays checking the expansion, causing the large room to expand even larger, overlapping the smaller room. This usually only happened if there were many small rooms built near a large room, and then a door nearby generated a large room, which was infrequent.

Fig 5. Also, all of the things the characters say are randomly generated...and hilarious.

Fig 5. Also, all of the things the characters say are randomly generated…and hilarious.

Since it was a game jam, and I’d spent half of my coding hours working on this algorithm, I opted to leave the bug in and focus on less important things (like player interaction, pfeh). Regardless, I’m happy with how the room generation came out, and I’m interested in pursuing it further. If you’d like to check out this method of room generation, you can see it in action in ARE!

If all that was too much words for you, here’s a TL;DR version of my room generation algorithm.

  1. Define Room Types (small/large room, hallway, etc)
  2. Generate a room with a single door.
  3. When the player opens a door, create a closet (smallest room possible).
  4. The closet decides what type of room it wants to be (from the room types)
  5. Inflate the size of the room a random (but small) amount based on its room type.
  6. Repeat 5 until the maximum number of iterations has been reached (defined, again, by room type), or until an expansion would cause the room to overlap existing rooms.
  7. Project rays out from the corners and center in cardinal directions, to try to find other rooms that are nearby. If there are, expand slightly so the new room shares a wall with the existing room.
  8. Make sure that the new room has at least one door that didn’t previously exist. Otherwise, no new rooms can be generated from it, and the map is no longer infinite.
  9. When player opens a door that isn’t already linked to two rooms, go back to step 4.

My Year One at Cipher Prime

It’s early morning.  Light spills through the tall Old City windows into a mostly empty office here at the Philly Game Forge, and shines on a collection of weird plants I grew out of random stolen clippings from a restaurant down the street.  My mornings usually start quiet with the plants and morning light.  And coffee.  It’s good times. I’m sitting here trying to figure out how to fit all I want to say about my experience so far at Cipher Prime into a blog post.  It’s unlikely I will accomplish that, but here’s my best shot!


The journey began when, finding freedom from my “big girl” job with Lockheed Martin, I discovered the courage to start fresh as an intern again. I called up some friends of mine who I truly respect: Cipher Prime.  I was pumped to be a part of a passionate team right here in my own city, Philadelphia, making something amazing that I love — video games.  When I started here, there was no Game Forge. It was just a tiny office and a small intern cave where they keep the important amenities like coffee, Red Bull, and a teapot.  But that tiny room is where my game development journey with Cipher Prime began, and it’s been a runaway rollercoaster of excitement ever since.

DSC_0578 IMG_3839 893041_10200820255609388_1780880116_o830279_10200564119366142_598284345_o

My professional background is in 3D animation, visual effects, and highly photorealistic rendering. I spent the last few years as a production artist developing military simulation software.  So I couldn’t resist the appeal Cipher Prime’s explosively colorized Sparkle Party design aesthetic.  However, I had no idea how expansive the range of opportunities would be for me here.  Over the past year I have spent time exploring every aspect of design I had ever imagined myself being interested in.

Graphic Design became the foundation of my education. I’ve been learning strong visual communication from master designer, Will Stallwood. One valuable concept I try to practice is adjusting to any style we chose to implement and gracefully applying those choices consistently throughout a project, while not being overly repetitive or bland.  This is something you can immediately recognize in the games we make.  It’s a practice our team tries to bring into both our studio’s games and the little games we make together for fun at dev night or game jams.  For example, our visual style, gameplay, and even coding architecture will follow consistent choices we make together as a team.  Those choices might change a gazillion times as we make new discoveries along the way, but it’s the choices we make that shape the journey. And they form the essential experiences we share with the lovely people who play our games.  The effect, I think, is a very strong user experience and at the end of the day, we really just want it to be fun for the gamer!


This year has been a fantastic adventure that has provided me with opportunities to create things I never would have imagined myself making. For instance, I made over 100 unique vector icons during production on our newest release, Intake; I sang on my first recorded album with Dain Saint for our summer project, Shimsham: The Legend of Jazz Hands; I wrote my first game code in C# using Unity while working on my silly side project, Kitty Punch Crunch: Return of the Claw; I created animation with 3D software, Blender, which I had never even heard of before, within a week’s deadline, then made a game trailer with it; I even got to destroy a part of my workplace during the creation of Philly Game Forge. These are just a few of the things I am proud to have done this year.


I’m grateful to have found this place: a home at the Philly Game Forge, with my bros, where I get to collaborate every day to create awesome stuff.  It’s an honor to be a part of a team that encourages and supports each other as well as other devs in our community here in Philly.  Not to mention, I am THE COOLEST mom at the playground, hands down.  Yeah, it’s a pretty good gig and I like it here.


Five By Five

For an in-depth look at where we’ve been, what we’ve done, and where we’re going, Will was kind enough to put together this awesome retrospective. Check it out!



Five years is a peculiar quantity of time, at once an eternity and an instant. And it seems appropriate that a company founded on the concept of digital ink would commemorate it with the real variety.

But I’m getting ahead of myself.

Five years ago, Will and I started a digital media company. It was as much a venture as it was a gesture, a middle finger to the turnover-burnout culture of the graphic design industry we’d been raised in. We started a company because we wanted to express ourselves, take control of the things we spent our time doing.

“Yo, you wanna start a company?”
“I already filed the paperwork.”

We made a game because, well, wouldn’t you? That’s how these things go. And with Auditorium, we discovered that a little piece of code, wrapped with music and light, duct-taped and polished and put on display for all the world to see, could touch someone halfway across the globe. Which, if you want to talk emotions hard to put into words…

Imagine being on your fourth sleepless night, your third pack of ramen, your second eviction notice, and suddenly, a letter comes in the mail. A thank-you note from a teacher who was touched by something you created, and attached to the letter, two gold stars.

Gold. Frickin. Stars.

And after that, you start getting emails from around town. From the game community. The community, which you’re just learning exists. “Hey, there’s this thing called the IGDA, maybe you guys should talk?”

“Hey guys, we’re gonna talk about making things up as you go along.”
“You may notice we didn’t prepare anything.”

And you realize this community is home. The home of more crazy people who stay up till daylight because their shader isn’t compiling right on arm6. People who argue for twenty minute spells about pixels, kerning, difficulty curves, architecture, controls, consoles, platforms — but never argue about the fun. And slowly, surely, you find more of them hanging out, becoming family.

Fast forward. Our company is five members and five years strong. Our neighbor leaves the office next to us.

“Let’s kick down the wall.”
“Well obviously.”

And now we have the Philly Game Forge. A new home for the family we found — or found us, I suppose. Our inaugural showcase was a testament to how much we’ve grown as a community, and as individuals. Tell me five years ago that hundreds of people would show up on a Friday night in Philly to see games they’ve never heard by people they’ve never met and I’dve given you one hell of an eyebrow.

And yet.


In the midst of the crowd, I saw that same passion from before. People creating what they want to create for no reason other than they felt it should exist. And people connecting with those creations, and smiling, and experiencing the fun.

Gold. Frickin. Star.

So of course, sitting in a tattoo shop on a Sunday getting ink seemed appropriate. And even more so, it’s appropriate that even though Will and I can agree on getting the tat, we still get to disagree about the direction it should face.


But it feels right getting something indelible, a reminder of the road behind and the wide open space ahead. It’s not every day you can feel like you know where you’re going, and it’s certainly not every day you can feel like you’ll get there.

But every day, you can damn well find the fun.

igf logo 240x240

Who Wins the IGF?

Independent Games Festival (IGF) winners come in all shapes, sizes, and genres. But what sets the handful of winners apart from the hundreds of entries the contest receives each year? Is there anything that developers can do to distinguish themselves from the crowd? In this article we’ll look at how IGF winners over the last two years did it.


igf banner 720x240 bordered

Our Findings

This article is damned long, so here’s a summary of our findings. We found that IGF winners were characterized, with very few outliers, by:

  • Some type of prior “notoriety”, which might come from the developer’s previous games, a pre-existing version of the game itself, a large or growing fan base, or other factors discussed below.
  • Development times averaging out at over two years.
  • Having at least two people involved in the development process.
  • Being more than just “feature complete” (one of the requirements for an IGF submission). By the time IGF winners are announced in March, the majority of them are highly polished, and are often already commercially releasable games.
  • A widely varying amount of information available in developer blogs. Winning developers differed greatly in their posting frequency and blog content, although most of the winners made sure to at least announce, “I’m making this thing!”
  • Awesome trailers.
  • Diverse geographic location, if “diverse” includes only Europe and former British colonies.
  • Many different game engines, some commercial and some custom-built.
  • Varying amounts of press, ranging from zero to boatloads.

These findings aren’t necessarily guidelines for developers to follow. They’re just a few of the things to consider when you wonder how your game stacks up against the competition.

Why Examine Past IGF Winners?

Our studio, Cipher Prime, would love to snag an IGF nomination, or, Cthulhu-willing, an IGF win. There are few indie developers who wouldn’t. Getting eyes on your work is the end-all, be-all of any small studio, and IGF finalists get press exposure, critical acclaim, the validation of their peers, ponies, and also more press exposure, in case I hadn’t mentioned that.

eric svedang

So when I was unwillingly shanghaied from my happy programming place and forced to research and write this article for us, I was trying to answer some questions our studio had about the winners. We were looking for examples that we could emulate, and that might clue us in to what we can do better. What were winners’ development cycles like? How were their release schedules structured? How much did they discuss their game before and during the IGF process? How much press were they getting?

Intrinsic and Extrinsic Factors in
Game Development

A lot of those questions involve things that I consider to be “extrinsic” to game development, as opposed to intrinsic factors, which include things like the genre, design, content, and player experience of the games themselves.

In this article, we don’t care about those intrinsic factors, because even a cursory glance at the IGF finalists shows you how different the games can be. Each winner is its own brand of unique, and it’s probably unproductive to try and emulate any one of them. Given that the judges rotate every year, and that variety is the spice of life, you’re much better off forging your own path and bringing your own idiosyncratic vision to fruition.

But extrinsic factors are a different story. They cover the external, less sexy considerations of game development, like how long a game’s development cycle is, or how often one should reach out to the public and the press.

The rest of this article examines what sorts of prior notoriety IGF winners have achieved, how long their development process took, how they structured their release schedules, how much public outreach they did, and a few other extrinsic factors, like which game engine was used and where the game was developed.

How notorious are the IGF winners?

IGF entries exist on a spectrum of notoriety, a word I’m using as a catch-all term for the popularity, recognition, acclaim, and/or general ballyhoo surrounding a game and its developers.

When you look at IGF entries, at one extreme you have the projects submitted by hobbyists who have never shown their game to anyone before entering the contest, and who don’t talk about the game during the contest or afterward. At the other extreme, you’ve got world-class developers who’ve made their mark on the indie scene and have visibly worked on their project for years.

The vast majority of IGF winners over the past two years fall toward the latter end of the spectrum.

However, those winning projects have achieved their notoriety in many quite different ways. Some of them rest on the strength of their developers’ previous games. Some games were swept up in an organic wave of word-of-mouth fandom. Other games already existed in different versions and were lauded in other contests for their technical or aesthetic achievements.

This next section discusses a number of the different “paths” to notoriety, and some of the recent IGF winners that exemplify them.

Compulsive Contest Winners

Many IGF-winning games are already on the industry’s radar, having proven themselves incapable of blending in with the crowd. They’ve won other contests and may even have been nominated (or won!) in previous IGFs. Antichamber and Fez are two great examples.

Antichamber (2012 Technical Excellence Winner) has a long and meandering production story. The project grew out of game ideas Alexander Bruce had been throwing around since as early as 2006. Initially titled Hazard: The Journey Of Life, it was first shown off at the Tokyo Game Show’s Sense of Wonder Night in 2009, when it was an Unreal Tournament 3 mod. Bruce started developing a standalone later that year, which would be acclaimed in Make Something Unreal, selected for the PAX10 and IndieCade, and even nominated for the Nuovo Award in the 2011 IGF. After that year, the game was substantially reworked and renamed as Antichamber, and subsequently won the Technical Excellence award in 2012.

antichamber orange 720x240

Fez (2012 Seumas McNally Grand Prize Winner) was nominated in the Seumas McNally Grand Prize and Technical Excellence categories. Polytron first announced the development of Fez in July 2007, on the TIGForums. The original thread is still open, and is currently on its 162nd page, with over 320k views. The game won the 2008 IGF for Excellence in Visual Art Award, though its development then stalled for years for various reasons, many of them chronicled by Indie Game: The Movie. But in 2011, the game was selected as one of the PAX10 at PAX Prime 2011, and won the Story/World Design and Grand Jury awards at IndieCade. It was finally released on XBLA a month after winning the Seumas McNally Grand Prize in 2012.

fez banner

Blockbuster Commercial Successes

Other IGF-winning games had already achieved substantial commercial success before being submitted to the IGF; that success generally correlates with a well-deserved fan base for their games. These games usually snagged the Audience Award in addition to nominations in other categories. FTL: Faster Than Light and Frozen Synapse are representative examples.

FTL: Faster Than Light (2013 Excellence in Design Winner and 2013 Audience Award Winner) was nominated for the Seumas McNally Grand Prize and Excellence in Design. FTL has a well-documented and exciting history, including a 2011 IGF China nomination, a groundswell of Kickstarter support (a $10k Kickstarter that blew up to a $200k finish), a successful commercial launch on Steam, GOG, and their own website in September 2012, and a host of 2012 Game of the Year placements and mentions. The game was a rock star well before its IGF nominations and win.

ftl banner

Frozen Synapse (2012 Audience Award Winner), was nominated in two categories: Excellence in Design and the Seumas McNally Grand Prize. It spent four years in development, but benefited from a very active beta scene and a great deal of commercial success even before the IGF awards. The pre-order beta started in April 2010, and brought in $135k for its developers, Mode 7. It was followed a year later by the Steam release on May 26, 2011, and in September of that year, the Humble Frozen Synapse Bundle was released, which brought in $1.1 million in revenue.

FrozenSynapse banner

Second-Generation Makeovers

Some IGF winners, like Dear Esther and Spelunky, were actually overhauls or mods of pre-existing games. The original versions of those games were often already critically acclaimed, and after rising from the ashes of their visual and technical revamps, or their platform ports, were found twice as stunning.

Dear Esther (2012 Excellence in Visual Arts Winner) was a finalist in four 2012 categories: the Seumas McNally Grand Prize, Excellence in Visual Art, Excellence in Audio, and the Nuovo Award. It was originally a Source engine mod created while its developer, thechineseroom, was a research group at the University of Portsmouth. It was released in 2008, and won critical praise and awards, including Best World/Story at Indiecade 2009. That same year the team also began revamping the game with new technology, after receiving a full Source license from Valve. In 2011, thechineseroom started their fully independent studio with Indie Fund backing, and pushed up their release date after switching Dear Esther over to the Portal 2 Engine. Dear Esther released on Steam on February 14, 2012, and won the IGF Excellence in Visual Art award a month later.

Dear Esther 3

Spelunky (2012 Excellence in Design Winner), was a finalist in three 2012 categories: Technical Excellence, Excellence in Design, and the Seumas McNally Grand Prize. Derek Yu originally made the game in Gamemaker, and released it as freeware in 2008, on the TIGSource forums. In December 2009, the source to Spelunky was released, and a healthy mod community grew up around the game. Earlier that year, Jonathon Blow also contacted Derek Yu about doing a commercial version for XBLA release, and put him in touch with Microsoft. That kicked off a two-year development cycle culminating in a July 2012 launch.

spelunky logo 720x240

Games with Well-Known Developers

IGF winners with good developer genes are those games that spring from the heads of established indie studios with distinctive reputations, like Amanita Design or Simogo Games. Or if they’re from new studios, they’re studios whose founders have well-known development chops, like the Tomorrow Corporation.

Botanicula (2012 Audio Winner) was produced by Amanita Design, the Czech Republic’s indie pride, which already had half-a-dozen titles under its belt, including the multi-award winning Machinarium (which also won the 2009 IGF Excellence in Visual Art award). Prior to its two 2012 IGF nominations (for Audio and Art), Botanicula was already getting press, including a Rock, Paper, Shotgun preview. And two weeks after receiving the IGF win, the game was already set to release in a Humble Bundle (the Humble Botanicula Debut), which ended up pushing $800k in revenue.

botanicula 720x240 2

Beat Sneak Bandit (2012 Mobile Winner), is the third game from Simogo Games, a Swedish iOS studio. The studio is best known for the stand out art styles of its first two games, Kosmo Spin and Bumpy Road, which set them apart from 99% of the noise available on the App Store. Thanks to this, even before its IGF nomination, Beat Sneak Bandit had an IGN exclusive, as well as later previews in mobile news sites like Touch Arcade and PocketGamer.

beat sneak bandit banner 2

Little Inferno (2013 Technical Excellence winner), despite being the Tomorrow Corporation’s freshman work, is in a similar position because of its creators’ arrival in the industry via World of Goo and Henry Hatsworth. The developers were getting indie press well before the game’s release, and their Nintendo connections helped Little Inferno become one of the Wii U’s 29 launch titles on November 18, 2012, which in turn resulted in a vicious press cycle irreparably increasing the game’s popularity and reach.

little inferno 720x240

Word-of-Mouth Darlings

Organically fertilized press games don’t have much of the above-mentioned flair, but pick up a good deal of press and word-of-mouth due to their own strengths. For instance, Cart Life just tickled (though tickling may not be a bleak enough word) the indie world the right way, and Kentucky Route Zero had a jaw-dropping trailer.

Cart Life (2013 Seumas McNally Grand Prize Winner, 2013 Nuovo Winner, 2013 Excellence in Narrative) won every category that it was nominated in. The game was built in Adventure Game Studio, and released for free in May 2011. It was virtually unknown for many months afterward, except for a mention here or there. But in January 2011, Electron Dance lavished much praise on the game, and Rock, Paper, Shotgun and Kotaku covered it soon after. If you look at the Google Trends data for “cart life” searches, you’ll see that although the number of searches dipped after early 2012, they increased again once Cart Life was submitted to the IGF, even before it was announced as a finalist in January 2013.

cart life 2

Kentucky Route Zero (2013 Excellence in Visual Art Winner) was nominated in four categories at the 2013 IGF: the Seumas McNally Grand Prize, Excellence in Visual Art, Excellence in Audio, and Excellence in Narrative. Cardboard Computer’s game also hadn’t gotten a lot of press in its two-and-a-half year development time. Its Kickstarter (early 2011) was modestly successful, but didn’t generate much buzz. However, in October 2012 the studio released a new trailer for their IGF entry, showing off eighteen months of new and vastly improved design and artistic direction. Their work was amply rewarded by articles in Rock, Paper, ShotgunKotakuEurogamer, and other press outlets. There was an even bigger press explosion after their January nomination.

kentucky route zero banner 720x240 photoshopped

How long does it take to make an IGF winner?

Andy Schatz’s Monaco took home two IGF awards in 2010 (the Seumas McNally Grand Prize and Excellence in Design). At GDC 2011 he gave a post-mortem of Monaco’s development (here’s the link–it’s well worth a watch), describing how he went from conception to IGF winner in fifteen weeks.


However, Monaco’s lightning-fast turnaround seems to be an exception.

In the past two years, only Beat Sneak Bandit and Storyteller clocked in at less than one year of development before winning the IGF. Beat Sneak Bandit actually released commercially after six or seven months of development, and Storyteller won the Nuovo award while it was still in alpha, though Dan Benmergui had been working on it for about a year. FTL’s development time was one-and-a-half years, which included its Kickstarter and IGF China nomination a year prior to the 2012 win.

storyteller banner 720x240

But most IGF winners pour at least two years into their games before they manage to snag an award. The Botanicula, Kentucky Route Zero, and Little Inferno developers all took approximately two-and-a-half years to finish their games. 140, which is still in development, was a personal project with two years of development behind it when it won the award for Audio excellence. Richard Hofmeier, the creator of Cart Life, joked that his projected thirty-day jaunt turned into a three-year odyssey.

140 720x240

A few winners took two or more years to develop the version of the game that won the IGF, but these winning versions were based on original games or mods that had already taken some time to development. Dear Esther and Antichamber were both mods that took between one and two years to create and were released on their own before their subsequent recreation (each totaling four and four plus years, respectively).

Antichamber screenshot 720x240

Fez and Frozen Synapse lie at the lengthy end of the development spectrum, each taking four or more years of work before their IGF wins.

The upshot of these long development times is that IGF winners are much more than feature complete. They are mature, they are polished, they are refined, and they are labors of love. It’s tough to compare how many actual man-hours go into development, because teams and individuals work at varying degrees of efficiency and at different points on the full-time/part-time spectrum. But the fact that most of the winners stuck through their projects for more than two years, on average, speaks a lot about their dedication to their creations.

How do IGF winners schedule their releases?

How did the IGF affect developers’ release decisions? Although there were some winning titles that were released well before they could even have been submitted to the IGF, and others that are still unreleased, the majority of IGF winners were already released or ready to be released around the time of the IGF.

Five of the past two years’ thirteen winners were released before the IGF announced its nominees. Beat Sneak Bandit, FTL, Little Inferno, and Frozen Synapse were all released in the year before their IGF wins. Cart Life was freely released two years prior, but did some clean-up and a commercial Steam release a month before its IGF win.

frozen synapse screenshot 720x240

Similarly, Kentucky Route Zero and Dear Esther also released a month before their IGF win. Kentucky Route Zero did something very commercially savvy, selling the game on their own site on the day they were nominated, and then doing a wider release (through Steam) the following month.

Of the games released after the IGF, Fez and Botanicula released a month after their wins, Spelunky the summer afterward, and Antichamber almost a year after. Even if these release dates suggest that the games were far from finished at the time of their submission, recall that these games had already received plenty of notoriety from prior incarnations or their previous contest wins.

fez screenshot 720x240

Storyteller and 140 are the only examples of games that were largely unfinished when they won their IGF awards.

IGF-winning games are much more likely to be polished and feature-complete, and are often already on the commercially releasable starting blocks.

What other extrinsic factors correlate with IGF success?

We also looked at a handful of other extrinsic factors, like team size, public outreach, geography, and choice of game engine.

Team Size

Every IGF-winning game, with the exceptions of Storyteller (by Dan Benmergui) and Cart Life (by Richard Hofmeier), was created by a group of two or more developers. These groups worked in full-time partnerships or teams, or outsourced some work to other people, or both. This average team size isn’t very surprising, because while collaboration can make the creation process more difficult, it can result in a much better end product than developing alone.

thumbs man 720x240


There was a wide spectrum of how much information was disseminated. On one end, some games were pretty much under wraps until their release, or at least until entering the IGF. Cart Life and 140, for instance.

A handful of games didn’t have dedicated development blogs, but developers would sometimes discuss development issues or progress reports on their own sites, as in the cases of Storyteller and Anti-Chamber.

words 720x240

Other games had more methodical dev blogs. These often started half-way through development, and then regularly updated weekly or monthly. Many of the art-heavy games took this approach, like Botanicula, Beat Sneak Bandit, and Little Inferno. Games with beta pre-sales, like FTL (which also had a Kickstarter) and Frozen Synapse were also fairly consistent about releasing new info about their games.

While dev blogs varied greatly in style, and while their posting schedules weren’t always consistent, usually developers released at least some information about their games.


My findings on this particular extrinsic factor are more a matter of personal opinion than anything else, but I think that pretty much every single IGF winner had an awesome trailer. Even the simpler trailers containing nothing much more than gameplay are really well done and make for a really compelling experience. Several of the games really worked to use video to their advantage, uploading multiple trailers, teasers, and gameplay videos.

If you’ve got some time, check them out: 140, Antichamber, Beat Sneak Bandit, Botanicula (teaser, pre-release, official), Cart LifeDear EstherFezFTL: Faster Than LightKentucky Route ZeroLittle Inferno (also), SpelunkyStoryteller.


The IGF winners came from a fairly “diverse” range of countries. Diverse, at least, within the subset of Western countries usually associated with indie game development. The USA had a strong showing (Cart Life, Kentucky Route Zero, Little Inferno, Spelunky). The UK (Dear Esther, Frozen Synapse), Canada (Fez), and Australia (Antichamber) represented the former British Empire. Continental Europe also presented a handful of winners (140, Denmark; Botanicula, Czech Republic; Beat Sneak Bandit, Sweden). Outside of Europe and Anglo-America, Argentina (Storyteller) and China (FTL, though its studio, Subset Games, was formed by American expatriates) prevailed in the IGF.

old world map 720X240

Game Engines

Developers also chose a wide variety of game engines. Kentucky Route Zero, 140, and Beat Sneak Bandit were all Unity games. Cart Life was built in Adventure Game Studios. Dear Esther was created using the Portal 2 engine, Source. Frozen Synapse and Antichamber were developed in modified versions of the Torque and Unreal engines, respectively. Botanicula and Storyteller were built in Flash. The developers of FTL, Fez, Little Inferno, and Spelunky all ended up rolling their own engines.


The IGF and “indie games” in general have greatly matured over the past decade. This article only covers IGF winners over the past two years, but if you look back, many previous winners (Minecraft, Amnesia, Limbo, Machinarium, World of Goo, and so on) pretty much fit the general template I’ve described above.

Moreover, many of the winners weren’t just nominated in the categories that they won, but in multiple categories. That really speaks to how well put-together each of them was.

oscar awards 720x240

We think that this research sheds some light on the games that have won the IGF, and more importantly, on the circumstances surrounding their creation. Seeing how dedicated IGF winners have been to their games inspires us as a studio to redouble and focus our own efforts. For others interested in creating an IGF-winning game, consider the work you’re doing outside of the game itself.

What have you been doing to increase the notoriety of your game? Are you submitting to as many contests as you can? Are you working on growing your community or fan base? Are you taking proper advantage of press opportunities, if any? Are you showing off your work to the public?

How finished, really, is your game? If there’s anything that doesn’t feel quite right about it — maybe the controls are off, or there’s still placeholder art or music — reconsider if your game is really in contest-ready state. Spend the extra time (and money, if possible) on presentation, once you’ve got the core of your game down. That includes making a banging trailer for it. If you’re not leveraging the talents of other people, consider whether that’s the best thing for your vision.

Of course, this isn’t a formula to winning an IGF, or any contest. And there are always exceptions to each rule. Hopefully, though, this article will at least serve as some food for thought. These are suggestions for where you could focus your attention in your efforts to get your game to go as far as it can go.

“Hey! It’s research, baby.”

The folks around here at the office have been after me for some time now about doing a “musing,” since I haven’t really posted any to date. I feel that these musings should be a reflection of personal experiences, something to take pride in, something that stands as a digest of interests and projects you’ve become invested in. The trouble is my interests shift so quickly that I rarely have a chance to recap in any form of writing, let alone a musing for the public to read. So, with this being my first musing, I’d like to talk video games — since it’s on my mind for the moment.

Now, I’m going to argue here that when I play games I’m actually doing research. For years I ran my own business in IT. With limited time on my hands, I couldn’t justify playing any games when there was always work to be done. After realizing a career in game development was something you actually could do, I closed up shop and started pursuing the dream.

So what’s this bit about research? Well, I still play for the entertainment factor, but I also play to familiarize myself with all the games I’ve missed out on over the years. Having a common understanding of interfaces used in games can help you immensely as a designer by giving you a common language with your audience. Even if you’re just as a tester.

Here’s the short list of titles I’ve been pla… *cough* …ah, “researching” this month.

GRID 2 (Steam)

Just got my hooks into this game. Playing the original, it was hard to imagine how the game might be improved upon, but the brilliant folks over at Codemasters have managed to do just that. While other games would have you traverse menu systems, GRID 2 nearly places you right into the driver seat as you open the game. The graphics are absolutely stunning. So good in fact, that they left me drooling and dreaming of what it might look like with an i7 processor and a current gen NVIDIA card. The game does appear to be tuned for Intel’s latest multi-core and on-chip graphics processors, but even with my Core Duo and a single GTX9600 the game looked spectacular. Seeing the Chicago cityscape instantly brought back memories of being there. The level of detail in the game borders on the realistic. Unbelievable. The controls are perfectly dialed in, making gameplay super enjoyable. In my case, I’m using an Xbox 360 controller for Windows. Can only imagine what it’s like with a decent driving wheel. I simply can’t recommend the game more highly. If you’re a game designer, pick it up for the sole purpose of research if nothing else. It’s a good measure of where to set the bar.

One thing I’d like to point out in particular about GRID is that Codemasters excels at how they handle camera movement. The replay camera really caught my attention in the first game. The default replay view follows the car around the track with a keen sense of framing, so that you’re not always just looking at the back of the car or have it centered in the viewport. The camera actually leads ahead of the car and anticipates directional movement, keeping the vehicle at a position on screen in line with the rule of thirds. It also pivots the camera angle to take in more of the scenery around the track. The attention to real-time cinematic detail in GRID is some of the best I’ve seen in a game. In GRID 2 they’ve taken it even further, improving the driver’s camera movement so that it anticipates corners and directional changes during gameplay — giving the driver a better perspective on the track and a more natural and fluid feel behind the controls.

DOTA 2 (Steam)

What drew me to DOTA 2 in the first place was the Workshop system. Valve has provided users with an interface for creating items for hero characters in game. While looking through the Art Guide for DOTA 2, I was amazed to see how they handle their texture maps. Each hero and item makes use of just four texture files. The first two are pretty standard: one consisting of a diffuse map for color, and the other a normal map for showing physical detail on low-poly meshes. The last two are really interesting: four additional texture maps are shoe-horned into each file. They’re able to do this by using the image’s four channels — red, green, blue, and alpha — independently of each other for storing gray-scale shader masks. Brilliant! If you’re an artist interested in doing any sort of 3D work for video games, it’s worth your while to check out DOTA 2.

Outside of the Steam Workshop side of DOTA 2, I hadn’t actually started playing this game until just a few weeks ago. The gameplay is simple enough: defend your towers, level-up and upgrade your hero for that match, and coordinate with your five man team to focus attacks on the opposing team and their structures until they’ve all been destroyed. The scope of the game becomes immense when you begin to look through the different heroes and their upgrades.

Sanctum 2 (Steam)

This one deserves more play time. It’s definitely a game to be played with friends. If you like tower defense games, as I do, this first-person shooter-style really puts an interesting twist on the genre. First of all, being a multi-player tower defense game allows each player to control the wall placements and path generation for enemies. This requires either a considerable amount of cooperation, or a delegation of duties among players. While one player place the wall sections, another player places the defensive weapons atop the wall sections. The remaining players select weapons to level up and pour credits earned during the last match into them. Once the level is set, the game becomes a survival match. If there were another game out there I could remotely compare it to, it would be the Man vs. Machine mode of Team Fortress 2. Lots of fun. For any artists out there, the high-chroma and stylized art in Sanctum 2 is also worth checking out.

Thomas Was Alone (PS Vita / PS3)

Extremely charming game. I have to say though, when I first saw the gameplay months ago, I wasn’t all that interested in it. I wasn’t crazy about the blocky, prototypy looking graphics. It wasn’t until I sat down with it and began to play that I absolutely fell in love with it. The simplicity I mistook for a lack of effort became a shining example of elegance in design. Did you know that Thomas Was Alone has a commentary track? Go to options and find the volume sliders. You’ll see one there for Commentary.

Plants vs. Zombies (PS Vita)

What can I say. I like tower defense games. Call it a guilty pleasure if you must. I remember seeing it in QA when I was a tester. I wonder if I’d still be as interested in playing the game if I had been on that test team. I tested Fractal before it released on the iPad, and I still enjoy playing it. Although, I haven’t played it on my own time in quite a while, and haven’t completed the campaign or puzzles on any of the copies I own. Something to think about.

I do like how Plants vs. Zombies differs from the traditional tower defense, though. Instead of guiding the enemy along a path, you attempt to build an impenetrable wall against the waves of zombies. Normally towers don’t take any damage, but you also normally have to leave a path open to the goal. In Plants vs. Zombies, you expect your towers to fall and have to budget for new ones when the do. Interestingly enough, strategies normally used in RTS games seem to translate well here. Much like walling off for an opener as Terran in Starcraft 2, you’re trying to hold the enemy off long enough to build a strong economy first. Then purchase and upgrade active defenses to build up your offensive.

I’m going to make an effort to continue this sort of writing as a monthly series. It’s important to be familiar with the games in the market today, for the purpose of vocabulary if nothing else. But it’s also important to compare today’s titles with those from years past, and identify how games have evolved and continue to be improved upon. You’ll end up being a better designer for it.

“Interface First” Game Design

At Cipher Prime, we create games constantly. You may only see one or two of our games released a year, but behind the scenes we make games weekly — sometimes even daily. The biggest problem is always getting started. Game jams help by providing a theme, but there are so many different places you could start with creating a digital game. I have a personal style: looking at “controls”.

As a designer, I spend a lot of time taking complex interactions and stripping them down to their basic form. I love games like Quake 3, Ikaruga, and Lumines — to me, arcade games will never die. One major thing these games all have in common is that their controls are tight, sexy, and responsive. When I look at these games, it’s hard to not think the game designers took a lot of cues from their control interfaces. When I start creating a game, the very first question I ask is, “How do I want to interact with this thing?”

In many cases, I’ll design an entire game based on what I perceive to be the most direct, unique, or even absurd way to interact with a device or controller.


The way you interact with a device can change everything about your game design. In fact, the entire game can change based off one small insight about the way you interact with a thing. This is because your control interface is very tightly coupled to the inner loop: the very core of a game. In Mario, for instance, you’d define jumping, running, pouncing, firing, etc. as part of the inner loop. These are things you do often, over and over again.

On a closer look, these things are also intensely affected by the way you interact with your game. What if the jumping in Mario was based on your physical body actually jumping? Do you think you could still design levels that require you to jump from one platform to another in 0.3 seconds? My guess is that even the most physically fit players would start suffering from fatigue after just a few minutes of gameplay.

Anyone who knows me well would tell you I have a sick obsession for color theory. In fact, I regularly joke about being an Official Color Picker rather than designer. Since color means so much to me, let’s assume you’re creating a game where changing colors is the heart of the inner loop, and see how that affects the game design. Here’s some questions I might ask myself next, in no particular order:

“Do I want a fast- or slow-paced game? Turn-based or asynchronous?”
—For this game, let’s go fast paced asynchronous.

“Am I going to do something that relies on skill, intellect, or some combination of the two?”
—Intellect: who needs it? Let’s do something skill based.

“Why the hell am I making this? Is it for me or someone else?”
—Screw everyone else.

“Do I want something single player or multiplayer, competitive or cooperative?”
—In the vein of screwing people over, let’s do something multiplayer competitive.

Now that we know some of our very basic goals, let’s take a look at this color picker from a couple different interface options.


How about a simple controller like the old-school NES?

Chances are, we’re going to need the gamepad area for movement. With that in mind, that leaves us with two buttons. If we use one button, we can cycle colors. Cycling colors can be fast if there isn’t a range of more than 2-3 colors. However, when your get to 4 or more colors, you’ll have to press a button at least 3 times just to get to a specific color. Now you could easily do this, but you’d end up pretty frustrated, and it would be a slower experience. Conversely, you could map both buttons to two different palettes, which will give you up to 6 colors. This could lead to some confusion, but a diligent player will figure it out fast. With two buttons you could even move up or down a list of colors, giving you more granular control of your selection. If you’ve played Tetris, you can see how being able to spin both left and right came in handy for high level play. Another design solution could be to make one button cycle through colors, while the second button cycles through shades. This will cut down on visual confusion, but also give you at least 6 colors.

The iPad is an extremely interesting interface.

Your first instinct might be to design the color picker to have a slider. Unfortunately, this isn’t exactly an optimal design, because sliders are finicky on touch screens and they’re not typically very precise. A good go-to tactic for fast switching is direct access: divide the screen into different clickable areas for switching colors. We could have as many colors we want with the only limiting factor being the size of one’s fingers. Alternatively, we could always emulate a button from another device, such as a controller, but why would you? The iPad isn’t a controller, it’s a screen you can touch — it’s better to use that to your advantage.

Now let’s look at the Playstation Dualshock controller.

In both arena shooters and first person shooters, one is used to using two analog sticks. What if we took that familiarity and used the second analog stick as color picker? Not only does this thought inform the design of our color wheel, it also informs the game design itself. With 360 degrees of motion as well as intensity from 0-1, we have access to a nearly infinite range of colors. This is an extremely elegant design. But is it too much? Chances are, any gameplay that hinges on selecting a color that precisly isn’t going to allow for the fast-paced gameplay we’re looking for. Thankfully, our input being both radial and analog means we can break the selection down into parts. In fact, we could adjust the size of the color wheel as we go, giving the gameplay even more breadth.


The keyboard is probably one of the most widely accessible interfaces.

The problem is it offers a ton of choices. As I said earlier, it’s a designers job to tackle the clutter; a typical keyboard might have 101 keys. We could make every single key to a color, which could certainly be fun for a typing game. If we take a cue from Quake3, we could just map the 1-0 keys as colors. If we use just 3 keys, we could play around with some pretty fun color mixing ideas.

The mouse is probably the most used interface device.

Unfortunately, it can be tragically slow when it comes to something like inventories. In many cases, designer will use menus and sub-menus to complete a challenge like this. Luckily for us, we hate making menus. It’s fairly safe to say most people have the option to both left and right click these days — even on Mac  — so we could do a number of two-button options that I already presented. We’ve already thought about the Playstation controller and the radial analog selection sounds great — we could easily take this idea and adapt it to the mouse. We could use the left click to bring up the radial menu and pick the color when we release the button.

Let’s look at one final device: the Kinect.

The Kinect is a game-changer — literally. How the hell do we make color picking work when you’re just waving your hand in the air? One very interesting solution is to not actually pick colors at all. Up until this point, we’ve only thought about the possibility that the user picks the color directly. What if the game presents you with color options and you just time your actions? For instance, as the game progresses you’d see the background color change through every available color — the second it hits teal, you do a jumping jack. This idea changes everything. With this line of thought we could go back and take another look at every one of devices we’ve discussed and come up with completely new ways to interact with them and a choice of colors.

There are a million-and-one ways to start a game. This is one of the William Stallwood methods of game design. I look at control interfaces and I let them inspire every part of the inner loop. Changing the way you look at a simple action can change the very action itself and breed tremendously unique and intuitive ideas that will shape your entire game. A button can always just activate something, but it can also do so much more. At the end of the day, you’re the game designer and you’re calling the shots. Your game could always use a controller, but I urge you strongly to think about the possibility that it can’t, shouldn’t, or just might be a different game entirely.