top of page
Search
  • Writer's pictureCalcite Games

Space Debris: Process Over Product on Breach of Space.

Updated: Feb 20, 2022

By Christopher B. (Programmer & Sound Designer for Breach of Space)

Breach of Space has gone through many transformations over the last 18 months. My team, Calcite Games, began working on it in August of 2020 as a team of three: one programmer (me), one concept artist, and one 3D artist. This project, whatever it was to become, would be the capstone project for most of us as graduates of Indiana University’s Game Design program. We would spend four semesters pitching, designing, building, and releasing our game, with some projects being scrapped and those members being redistributed along the way.


With the game approaching our release deadline, I began to reflect on the permutations of the project over the last nineteen months, everything I have learned, and more importantly how I learned those things. But I’m getting ahead of myself.


Before our first semester had even started, I ended up in a meeting with the other two members of the team. They already had an idea of what the game should be: a roguelike, two-player, procedurally generated dungeon crawler for mobile. My initial reaction to this clown car of buzzwords was that this was not going to happen, that even a large team would have trouble producing this in such a short amount of time. But I was also interested in learning how to program proc-gen environments and setting up concurrent online play and didn’t want to just say “no” to learning new things (nor my new teammates). So, I spent the last week of summer vacation making a prototype.




This very first version of Breach of Space was set aboard a spaceship travelling to a new planet, where the environment changed depending on exposure to some sort of aerosol neurotoxin being pumped into the ship. Characters would also change, being either boss battles or NPC interactions, causing the mechanics to shift from combat to exploration. These eldritch horrors were actually on the ship, whereas the nice clean interiors and friendly faces were a product of hallucinations.


It was super ambitions / nearly impossible. Our professors preached “process over product” to us, so while they never said “This is bonkers” to us, we soon realized how over-scoped the project was. We first cut the mobile aspect of it, then the multiplayer, levels of deterioration, entire systems. It was not long before the three of us went back to the drawing board to start from scratch with something smaller.


We started thinking about what we liked about this first build, what we would really love to keep. Space and retrofuturism stayed, as did having a shady corporation be front-and-center of the plot. The idea of completing a lot of small tasks was floated. The gears began turning, and soon we had a new idea for Breach of Space: a management simulator, where you controlled a fleet of robotic workers from the comfort of your office chair.


The player would interact with a set of computer monitors, not actually able to leave the room. It was Five Nights at Freddy’s meets Overcooked meets The Outer Worlds, with a loop similar to an idle game. Various things would go wrong around the ship, and it was up to the player to keep everything from crashing into chaos. You earned currency that could be spent on items that you could purchase from the vending machine in your office. You would get emails from your boss that required attention, and eventually you would have to complete short minigames to reset the power or empty an airlock. It was chaotic, and sometimes fun.

During this time, we were preparing for an end-of-semester Shark Tank, a pitch presentation to industry professionals that could be the difference between getting cut and continuing to make your game. We had iterated over our game a few times that semester, pitching it in mock versions of the Shark Tank to other students and faculty, all while running semi-weekly playtests. The minigames became part of the core loop, and the interactions with your boss became a messaging system for the robot workers.




With the Shark Tank behind us, we had lived to see another day and had a long list of feedback to take into consideration during the coming semester. Our biggest takeaway from the Shark Tank was that we were trying to make two games instead of one, so we cut the minigames and began concerning ourselves with fleshing out the select-robot-to-do-job loop of the game.

We were worried about the players’ cognitive load, and whether they would be able to process the number of screens (especially while looking into a screen already) and whether this was a bottleneck we were willing to risk. So, we decided to prototype a version of the game that was more akin to an RTS, with the player zooming over the entire facility looking for issues, manufacturing new robots, and upgrading areas. I even wrote a brief for adding a power system, requiring the player to balance electricity between the robots, systems, and even rooms of the map. We were about to record a teaser trailer for the game, when our professor had an idea.

Another team was making a game called Office Hijinx, where the player had to fail upwards at an office job by sabotaging office equipment until they became the boss of the company. Both the Breach of Space and the Office Hijinx teams were kind of losing the plot a little and were making the same game (sort of): theirs was about destruction, ours was about repair, theirs was in a corporate hellscape on Earth, ours in a corporate hellscape in space. Our strengths were their weaknesses and vise-versa. We decided to combine forces, take what was working from both projects, and make something new.


We spent that week figuring out the new game. Management simulator was traded in for stealth. Third-person for first-person. The robots became the enemies. We had to get a teaser trailer out.


The trailer became our most up-to-date design document, and we started working on design briefs and updated documentation. But then summer came, and work kind of slowed after nine months of rushing to the next thing. But since our team had now grown to 12, we were still able to mostly wear only one or two hats (instead of nine). We accrued art assets, we refactored code from both sides, music and sound effects began getting slotted in. Breach of Space was now a stealth game, where you had to sabotage your way through a corporation that has taken over your home planet.


We sketched out a storyline about a distress signal from inside the company causing your scrapper player-character to investigate. We broke the facility up into different zones, each with its own vibe (oxygen factory, barracks). We planned for a crafting system like in Alien: Isolation (though not as complex), but this was scaled back to just the trusty noisemaker. Minigames came back in the form of hacking doors and forcefields. Multiple types of robot enemies were planned out, but around this time we began to see the deadline approaching. Areas were scrapped, whole systems abandoned.


I saw the finish line, and I looked at the game and felt it was far from finished. I started thinking about where we had started, the work we had put into so many systems and assets and design briefs, and how much of it ended up on the cutting room floor. I was worried about how I had spent my time in college, working on this game.


But then I remembered: “Process over product.”


I have learned so many things working on Breach of Space, many of which came directly from messing something up! I learned about every step of the game development process because I’ve fumbled my way through them. Whether as a team member, a programmer, or a generalist game developer, I am better because of the mess that I created with my team over the last almost two years.


Breach of Space is being released very soon. But regardless of what it ends up being, the journey was a heck of a ride.

13 views0 comments

Recent Posts

See All

Tips on How to be a Successful Game Design Student

By: Deja P. (Programming & Marketing for Breach of Space) 1. Networking The first tip on how to be a successful game design student is to network. In order to get a job in the game industry you have t

Post: Blog2_Post
bottom of page