“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.

It’s Cipher, Not Cypher

Let’s set the record straight.

Our studio is named “Cipher Prime”, not “Cypher Prime”. In interviews and reviews (and even in customer support emails), people frequently refer to us as “cypher prime,” perhaps mistakenly believing that we are incorrectly spelling in our own name. Let’s take a closer look at these two spelling variants to explain why we chose cipher prime over cypher prime.

What is a Cipher/Cypher?

The term “cipher” is most commonly used in cryptography. This versatile term can refer to the acts of encoding or decoding a secret message, or to the secret message itself.

not cypher prime

Where did the variants come from?

The word we know today as cipher originated in the late 14th century from the Arabic word sifr, meaning “zero.” At this point in the English language (Middle English) the spellings of words were not yet explicitly defined, and writers commonly substituted i‘s for y‘s at will, hence the emergence of cypher as a variant for cipher.

However, after the Great Vowel shift and the standardization of spelling in the 15th and 16th centuries, many of the y’s that denoted “eye” sounds in English were replaced by i’s–hence the change of “wyf” to “wife,” and “cypher” to “cipher.”


Even so, cypher is still considered a valid variant of cipher in many orthographic circles today. Cypher is most popular in England, where it first emerged.

Why We Chose Cipher

Because we’re American, and because cipher is by far the most commonly used spelling, and because we think “cypher” looks kind of silly.

No Need to Construct Additional Pylons

For the past week, most of Cipher Prime has been out of the office, celebrating Nikko‘s wedding and catching some tasty Cali waves. Excuses, excuses.

But rest assured, I’ve been holding down the fort, and have even found a way to use the solitude productively: I’ve been creating a new server-side build manager for Unity.

As it stands, every time we need a new build of our games, we have to get one of our devs to drop what they’re doing, change a bunch of settings, build on their machine, and distribute the build internally for testing. And if we need to submit a build for contests while in the middle of production, it gets even more time-consuming and prone to user error.

Pylon: Build Orders Made Easy

Build orders made easy

To solve this problem, I built Pylon, a build manager that interfaces with Unity Asset Server to compile builds server-side. All you have to do is note what platforms you’re building for, name the build, and press a button — bam, go get a cup of coffee while the server generates your build. You can even select which revision you want to build, which is helpful when one of your guys breaks the build but you still need a working copy to send to press.

Once the builds are complete, they are then neatly organized by project, and the server generates trackable download links that can be used internally or emailed to select people:

pylon 2 x240

I’m looking forward to getting this battle-tested when the team returns next week. As we progress with Duet, I’m expecting this server to save us hundreds of man-hours normally wasted on the build process.

Why “Pylon”?

Because we play too much StarCraft II. Naturally, I named the server after the Protoss structure that enables you to build more units, the “pylon”.

starcraft pylon x240

With Pylon, I’m hoping we’ll execute our build orders as efficiently in the office as we do in StarCraft. And if all goes well, we may decide to release this as a product for Unity users everywhere. But let us break it first — I wouldn’t even consider this alpha level software yet! We’ll keep you posted. 

Conventions, Concerts and Couples!

We’ve got two upcoming events and a special bulletin to make. Here are the deets:

1. Philadelphia GameLoop

Like talking about games? Dislike being told what to talk about? Come to GameLoop!

What: GameLoop is a self-organizing conference–an unconference, if you will–wherein attendees decide the subjects of talks democratically.

When: Saturday, May 18th, 2013, 9:00 AM


University of the Arts
Terra Hall, 16th Floor
211 S. Broad St.
Philadelphia, PA 19107

How: Register here!


2. Dain’s Performing

This Saturday, Dain Saint will be performing at 8static, a monthly chiptune music event. This 8static will be hosting A-Rival’s TRUTHCANNON album release party, and Dain will toast the evening with an all-new set of vocal-based songs. Should be awesome.

When: May 11th, 2013; doors open at 7:00 PM


531 North 12th Street
Philadelphia, PA 19123

How: Register here!



A shout-out to resident bad boy Nikkolai Davenport, who (in true nerd fashion) got hitched on May 4th. May the force always be with you, Nikko and Jillian. Congratulations, guys!

Choosing Game Jam Themes

Every month at Cipher Prime, we hold a twelve-hour game jam, a contest in which people try to create a game based off a theme of our choosing. Along with stressing over hosting the event (and, of course, over our own jamming efforts), we stress over choosing game jam themes.


Picking a jam theme isn’t as easy as it might sound. As an organizer, you want to give jammers an interesting jumping-off point, while still letting them be creative. Oftentimes, too much freedom leaves teams paralyzed with indecision; having constraints can actually make teams think more creatively. When thinking about how much freedom a theme gives teams, it’s also important to realize that people will often self-impose restrictions subconsciously.


Both the Global Game Jam (GGJ) and the Philly Game Jam (PGJ) have used pictures as jam themes (below). The GGJ used a drawing of the ouroboros, and the PGJ used a photo of decrepit playground equipment.

When the games were submitted, the GGJ received lots of games containing snakes, and the PGJ received lots of games containing a playground wheel as a centerpiece. At this year’s GGJ, the theme was the sound of a heartbeat. As when the theme was a picture, many people interpreted the theme literally and submitted games that involved hearts, or love, or something else that connected very simply to the theme. While there are plenty of counter-examples to this phenomenon, anecdotally, photo- or audio-based themes lead to a higher number of literal interpretations (and fewer original games). Because these themes engage with a particular sense (sight, hearing) very strongly, people have a hard time moving beyond that strong initial engagement to something deeper. Text-based themes lack a defined visual or aural form, freeing people to think about themes abstractly, rather than concretely.


If we’re sticking with text, generally a single word will suffice for a theme. Abstract nouns tend to give jammers plenty of context to work from without allowing them to simply utilize the theme for a set piece. Concrete nouns, however, tend to pigeonhole participants by allowing them to latch on to something tangible in the same way that picture-based themes do. Verbs, similarly, limit thinking by spoon-feeding potential player actions to designers. Conversely, single-word adjectives tend to be way too broad–it would be far too easy for designers to make any game they felt like, and then make sure that at least one tertiary aspect of the game could be described by that adjective. This is probably why the GGJ organizers have never chosen a single-word theme that was either a verb or adjective.


Not all good themes come from abstract nouns. Another common source of good themes is catchphrases (such as GGJ’s “As long as we have each other, we will never run out of problems”). While not frequently utilized, phrases as themes can be deployed to great effect. They force jammers to consider both the literal words of the phrase, which can lead to gameplay ideas, and also the emotion and the context of the phrase, which can add many more layers of depth to consider. For instance, in 2009 the PGJ used for its theme the Michener quote, “An age is called Dark not because the light fails to shine, but because people refuse to see it.” This quote produces lots of jumping-off points, from the light/dark dichotomy, to perception of the human condition, even potentially to Dark age history. Any of these avenues could be explored and still be thematically relevant.


Textual themes are popular with the granddaddy of organized game jams, Ludum Dare (LD). LD’s community self-selects a theme for each competition. But this can lead to internal conflict. When participants get to select their own theme, they’re likely to pick a favorite theme, or one that fits a design idea they’ve had. If that theme isn’t selected, all the time they’ve spent invested in the design seems wasted, discouraging the person from participating. Additionally, having participants vote can lead to very generic themes. For instance, in 2013, LD’s theme was “Minimalism”; in 2008, LD’s theme was “Minimalist”. Having a single entity, rather than an entire community, choose a theme can prevent similar or poor themes from being chosen.


The point of any game jam theme is, ultimately, to inspire and cultivate creativity. Because they’re made in such a limited period of time, the games made at jams are never going to be the same as a game made over the course of several months or years. Participants shouldn’t be trying to make a generic first-person shooter, RPG or platformer. Game jams are opportunities for game creators to make something new and interesting, and game jam themes should respect that.

May 2nd: Intel-Sponsored Game Jam!

This Thursday, the Intel Level Up Competition will be sponsoring our game jam! The winner of this very special game jam will receive a 250 GB Solid State Drive!

What’s a game jam?

A game jam is a contest in which people try to create a game in a limited period of time. Once a month, Cipher Prime hosts game jams–we choose a theme, and then challenge Dev Night attendees to make a game based off of that theme. Everyone votes for their favorite project at the next Dev Night, and the winner takes home a sick-nasty prize!

The rules

We’re bending our typical game jam rules for this week’s throw-down:

  • Participants have an entire week to work on their games (starting from 5:00 PM on Thursday, May 2nd)
  • Participants can work on their games from wherever they like
  • Games are due by the beginning of our next Dev Night (5:00 PM on Thursday, May 9th)
  • If you want to participate, let the Dev Night Google Group know!

What’s the theme?

This month’s theme is “Options.” Use it as you will. You could make a game about moral choices, or a game about in-game options menus. Get creative, and start creating!

Out of the Rectangle


In the original Auditorium, the gamespace was just a single black rectangle. Although we’ve always been happy with how Auditorium turned out visually, we also think it would be fun to create a gamespace that gives players more colors, particles, and music!

So one feature that we’ve been prototyping (and we’re feeling pretty good about it so far) is a movable camera that lets Duet players move around a space that’s much more expansive than Auditorium’s gamespace. The GIF above demos this feature: players will be able to pan the camera and see different areas of any particular level.

The extra space will make it easier for two players to share the same level, and it’ll also give us more creative potential for making awesome puzzles and colorscapes. We haven’t yet decided what degree of camera freedom to use in puzzles, although we’re currently leaning towards a “horizontal” gamespace.

Gaming and Neurodiversity: Learn to Play, Play to Learn

When we started making games, we didn’t make them with autism in mind. Yet over the years, we’ve received many emails from the parents of children on the autism spectrum, thanking us for creating experiences that they could share with their children. Messages like these have raised a question in our minds: why do our games resonate with the autistic community?

Last Friday, Cipher Prime partnered with The Philadelphia Science Festival to hold an autism awareness event titled “Gaming as Therapy: A Pathway to Interaction.” At the event, we shared Auditorium, Pulse, and Splice with attendees. We also helped organize a series of speakers for the event, including Craig Newschaffer, the founding director of the Autism Institute at Drexel University, Amanda Almon, scientific and medical illustrator, and our own Dain Saint.

Dain’s talk explored the neurodiversity-friendly aspects of our games, including our approach to rewarding player action and creating accessible experiences.

Without further ado, here’s Dain’s talk!


If you’re interested in receiving more news, promotions, ramblings, and/or snuggles, subscribe to our mailing list. We’ll love you extra. 

Cipher Prime Interviews Brian Provinciano

At our last Dev Night Cipher Prime had the pleasure of interviewing Retro City Rampage designer Brian Provinciano. Together we laughed, learned, and loved. Here’s are some of his awesome thoughts!

Q: What made you think you wanted to do Retro City Rampage, specifically?
A: I didn’t necessarily see Retro City Rampage as the finished product when I started this project. I started it to see what it was like to build my own engine for an open-world game, to figure out how these games (and creating a game for the Nintendo) worked. From there, as I started to come up with funny ideas, my vision became more robust. The game turned into this ultimate microphone for whatever I wanted to do.

Q: Retro City Rampage began as Grand Theftendo, a recreation of Grand Theft Auto III that you built for the Nintendo. Were the hardware limitations of the Nintendo something that stifled you, or that inspired you? 
A: Adhering to NES standards began as an exciting challenge, but I had to go through so many revisions to bypass the technical limitations of the system that frankly I was glad to make the shift to C++ when I did. Still, I’m proud of how I kept the gameplay so NES-esque. For instance, I restricted myself to the NES’s palette, to the number of colors that the NES could display onscreen at a given time. My accurateness adds an extra level of polish.

Q: Do you consider Retro City Rampage a success?
A: I do now. But when it launched, I didn’t feel that it was a success. I had imagined this huge launch date, but it didn’t end up being as massive as I’d hoped. The other thing that I didn’t expect–and I know this will sound naive–was that people wouldn’t like it. Leading up to the game’s release, I would demo the game and hear almost nothing negative from anyone. So when it launched, that’s what I figured it would be like. I’ve realized that it was absurd to think that. When reviews started coming out, I would focus on the negative ones instead of basking in the positive ones, and that’s the biggest mistake I made at launch. I didn’t let myself enjoy the success of completing something I spent years working on. To this date, I haven’t held a release party. When the game initially sold only 20,000 units, I was really bummed. But the good news is that it’s still selling. Actually, it’s sold more this year than it did last year–now it’s sold over 100,000 units.

Q: Do you have any words of advice for those who want to go full-time indie?
A: The biggest shocker to me when I went full-time indie was the time I’d end up spending on non-development tasks. Once I went indie, I had to make sure that I made money and that the game succeeded. So I had to start worrying about the business, about office administration, accounting, legal matters, getting licensed by consoles. All of that non-fun stuff. When I quit my full-time job, I figured I’d have another nine hours a day to spend working on my game, but I often ended up spending those nine hours on paperwork and emails. If you’re going to make games, I would recommend working with at least one other person. Doing it all yourself is just way too much of a burden.

Q: Bro, do you even lift?
A: …Yes. Yes I do.


If you’re interested in receiving more news, promotions, ramblings, and/or snuggles, subscribe to our mailing list. We’ll love you extra. 

The Birds and the Bees

Where do Cipher Prime game ideas come from?

What we love most about being a game company is bringing our crazy ideas to life. When we’re not doing our “normal work” (chipping away at our main studio project, dealing with customer support, yelling at each other, etc.) we’re making silly little prototypes for fun.

But every so often we’ve got to knuckle down and make a cool product. So how do we do it? And how has our process changed over the years?


Cipher Prime started out as an interactive media company, doing Flash and other web development work. At that point, games were just a twinkle in Cipher Prime’s eye. Long story short, Auditorium began as a very different experience from what it is today. Young Dain and Young Will explain it all in this video (1:40-2:40):


Our sophomore game, Fractal, was a more “traditional” creative experience, since we tried to design it from the ground up. It began as a competitive multiplayer arcade game, with everything prototyped out on paper, but ended up having something of an identity crisis as each member of the team gravitated toward making their own vision of the game. Fractal’s present-day arcade mode, puzzle mode, and campaign mode were each refined by different team members!

Fractal on paper.

Wanting to unify the creative process, Cipher Prime team members agreed in the future to make a prototype first, then show it to the team. If the team likes it, the team builds on it.


Will drew the concept for Pulse out on a napkin. Nobody else thought it would work as a game. I mean, come on–it was on a napkin. So he built it out in Flash, along with a level editor. By forcing the rest of the team to play by tapping the dots in time to the music, Will convinced Cipher Prime to do its first rhythm game.


In 2011, Cipher Prime attended the Indiecade festival in Culver City, California. While there, Dain ended up coming down with a pretty terrible fever and was stuck in his hotel room the entire weekend. So what do you do when you’re stuck in the middle of a game development convention, having fever dreams about rearranging binary trees? You make the prototype to Splice. Afterward, he pitched it to the rest of Cipher Prime, and we ran with it.

original splice

Feedback and Intake

Our two pre-production games for Auditorium: Duet (Feedback and Intake), were initially based off designs made by Will. For Feedback, Will came up with a radial pong design, Andrei built out the first prototype, and after joining the team, Aaron rebuilt it from the ground up. Intake, likewise, was actually based on the first game that Will ever made! The team took on his game concept and fleshed it out as a Cipher Prime title.

Feedback and intake.


So, what are we doing with Auditorium: Duet? Well, we’ve already got a very basic prototype (the original Auditorium), and we know the feeling that we’re going for: a rewarding, cooperative multiplayer experience. We’re big fans of iterative development, and we like “proving” ideas to each other by building them out and making sure they feel right.

We’re building Duet through feature-based prototyping. We have a bunch of ideas for how we want to extend Auditorium, all of which are varying degrees of crazy: new visual styles, new camera motions, new controls, and new genre-bending experiences. But we’re implementing them slowly, as a team, and making sure that they work.