Halloween Sale! Get our games for 60% off on Steam!


Hey guys! Get your copy of Auditorium, Fractal, Splice, or Intake for the cost of a cup of coffee as a part of Steam’s Halloween sale! Now’s the perfect time to pick up a copy for yourself or a friend. And remember—the full version of Auditorium is still available to play for free online until October 31st!

As always, thanks for supporting us! We couldn’t do this without you!

It’s facelift time. Set your mind on Fire.

We’re at a point now where we’ve seen trends come and pass and we’ve seen different markets rise and fall. It’s a deeply interesting and scary thing to swim in, because we need to constantly reinvent ourselves to stay afloat. And today, we’re unfurling the sails of our new ship.

Welcome to the new home of Cipher Prime. We’re hoping our new site helps people play our games better, faster, harder, and stronger. We find most people who know one of our games have no idea we make others, so we’re hoping we’ve solved that problem! If we didn’t, maybe our homepage can just inspire a few people. In any case, thanks so much for taking a look, and leave us any feedback you can offer!

To celebrate this change, we have decided to make Auditorium ( our first title ) free online for 1 month. If you’d like to play offline, you’ll still need to pony up that sweet $10. Additionally, we’ve added a new page for Auditorium Duet and updated the Splice content to reflect our pending release on PS4 and PS3.  Checkout the new Splice trailer!

Cipher Prime is changing, but we want you to be a part of it. Will is about to embark on a cross-country bicycle trip with some fellow developers. You can follow his development at http://www.nerdsacrossamerica.com. Dain has a new album coming out called, “Android Soul” that should release within the next few months. As always, you can follow @willstall, @dainsaint, or @cipherprime for more Auditorium Duet and Game Jam footage.

Thanks so much!

Intake Now Updated

We’ve been listening to user feedback and we’ve made some changes to Intake. We’ve been hearing that lots of people are having some problems at level 5. So to fix that, we are giving new players 5,000 mg at the start of the game. Now you can buy a life right off the bat! Also we updated Intake so that special levels start appearing at level 10, rather than level 5.


Bug Fixes:

  • Fixed pills spawning after the death scene
  • Fixed random unlocks while in attract mode

Thanks for playing Intake! We appreciate your love and support, so let us know if you have any problems.


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.

Intake on iOS? The Big Question Answered

We know you all have been wondering: “Gee whiz guys! When are you gonna release Intake on iOS?” Well, it’s never going to happen.

Real TalkAaron_hearts_you

SIKE! We are totally about to launch Intake for iOS!  We know, we know, you can barely contain your excitement. Don’t worry guys. You will be the first to know when it hits the App Store!


If you enjoyed all the pill-popping, bass-dropping, dubstep-wubbing, sparkle party extravaganza of our Mac/PC version of the game, you are going to completely lose it with our intense pocket edition! It’s got all the features of the desktop build plus the luxury of getting your Intake fix any time you want, on the go.

Haven’t heard of Intake?!?! Don’t worry! You’re gonna kill it with our new retro-futuristic drugstep arcade shooter. It’s got it all! Classic shmup style gameplay, over 70 finely tuned achievements, five bonus challenge modes, including a pro mode, colorblind settings, six different scoreboards to climb, super ridiculous powerup action, and an insane dubstep soundtrack written by none other than our very own Dain Saint.

What, you don’t feel like waiting? Oh, you don’t have an iOS device? No worries! You can always grab the game on Steam. We got your back. 😉

Also, visit playintake.com. You’ll need sunglasses.

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.