[In this retrospective, Chris Chung reflects on the development of Catlateral Damage and how it went from a gimmicky game jam prototype to a full release.]

When I was a kid in elementary school, I was introduced to Super Mario World, Sonic the Hedgehog 2, and Pokémon Red/Blue and instantly fell in love with video games. I continued playing and dreaming of creating my own games, and eventually went on to study some programming in high school and artistic game development in college. I also somehow earned a Computer Science minor, but wouldn’t have even considered myself a programmer! I broke into the industry as a QA tester in 2012 but always had aspirations of becoming a full-time indie developer.

Catlateral Damage was originally created for the 7DFPS game jam in August of 2013, along with games like Probably Archery, SUPERHOT, and Notch's Shambles. I grew up with cats my whole life and had always wanted to play a game that allowed me to experience everyday environments from a house cat’s perspective. My childhood cat, Nippy, (who passed away in 2014 partway through development) provided the inspiration for the game since he was always a very mischievous cat. Using my knowledge of feline behavior and very basic Unity skills, I created a prototype that consisted of one small bedroom and a first-person cat with a stationary paw “weapon”. You could walk around, moon jump, and move the camera to swing your paw around and knock things on the floor. (You can actually still play the original prototype on Kongregate.)

Nippy in real life and in the final game

Although a few sites covered the game shortly after the jam, there was an explosion of press a few months later in January of 2014 that convinced me that this project was definitely worth pursuing. A couple months later, I lost my QA job and started working full-time on the game in collaboration with Fire Hose Games as part of their accelerator program. We had a successful Kickstarter campaign, I adopted two adorable cats, we attended a few PAXs, I proposed to and married my wife, and we finally launched the game on Steam on May 27th, 2015!

My cats, Wil & Lyn, who were adopted during development

What Went Right

1. Kickstarter

Overall, our Kickstarter was very successful. We did our research, included a bunch of great reward tiers, and finished with $61,944 our of $40,000 goal. I feel like our video and story were both pretty good and showed off what we were trying to create. The large amount of press the game got several months earlier was definitely helpful. PewDiePie playing the game a few weeks before the campain launched probably helped, too! We also participated in OUYA’s Free the Game’s fund, which gave a bit more funding for a minimal amount of work to port the game to the microconsole.

Where we really shined, in my opinion, was with our rewards. There were the standard low-level tiers of getting a copy of the game plus some additional bonuses like the game’s soundtrack and your name in the credits. There was only one tier that included physical rewards to minimize manufacturing and shipping costs: a Catlateral Damage t-shirt and laser pointer (“a reward for you and one for your cat”).

My favorites, though, were the ones where backers could send in a photo of their cat to be randomly placed within levels or even get their cat as a playable character. Not only did this make up a significant portion of our funding (about a third of our total), but it allowed me to involve our backers in a really personal and unique way. Several backers even pledged to include photos as a way to memorialize their pets who had passed away. This was especially touching to me since the game was a way to memorialize the cats I grew up with, too.

Every photo in the game; lots of cats, 9 dogs, and 1 iguana

2. Scope management

Since Catlateral Damage was my first commercial project as a full-time indie and I had previously been living on QA tester wages, my main concern was shipping the game in a reasonable timeframe so I didn’t run out of money. Managing scope is one of the most important skills of game development and I believe I handled it well for this project. Like any project, there were plenty of times where cool new features and content would be pitched and added to the backlog, and I would have to assess how long they would take and cut them appropriately. These ranged from fun little things, like an interactive fish bowl, to bigger features that would have taken weeks or months, like adding a third-person view.

Given the nature of the game, it always felt like there was infinite potential and tons of different things that could be added. Even now that the game is out, I still get a bunch of suggestions from players! Some things I would have loved to add but weren't feasible during development are multiplayer (multiple cats competing to knock over the most objects), level editing tools (Steam Workshop), special abilities for each cat, more upgrades and power-ups, and more/different types of levels and objects to play with.

3. Development resources vs. game content

Given the combined resources of me, Fire Hose, a few contractors, and a project duration of about 1.75 years (initially part-time, then full-time), I feel like we shipped a pretty substantial game. Originally, I planned on creating a small number of 3D models and building levels by hand, reusing as much content as possible. When it became apparent that replayability would be an issue I switched gears and started building a procedural level generation system with lots more content. As someone who struggled through every programming course in college and barely knew how to use the engine, I'm surprised at how well everything came together!

All of the physics objects in the game!

There are several factors that allowed us to accomplish what we did. The game's mechanics are fairly simple, which let me establish a pretty straightforward integration pipeline. The low poly, cel shaded art style with the same texture and shader on all objects helped with integration, too. My concern with scope and desire to get things in as quickly as possible probably resulted in an efficient development cycle, too; I didn't spend excess time tweaking aspects of the game that would have resulted in diminishing returns in the long run. On the other hand, I did feel like my overall inexperience with the tools made development slower.

4. Working with others

We worked with three contractors outside of Fire Hose to help with the game: an artist to create lots of 3D models, a composer to create the game’s music, and a publicist to market the game at launch.

Being a very DIY type of person, I initially planned on doing everything myself (well, besides music; I have zero music ability). When building new content, I would start creating it in Unity, move over to Blender to create a model, switch back to Unity to import the art, and repeat for all new content. It became apparent that this wasn’t a very efficient workflow and that I had lots of other programming tasks, so we brought on Amy Mazzucotelli to help create 3D artwork. She did a fantastic job of cranking out tons of new content while making sure it retained the same style as the existing art.

For music, I honestly didn’t really know what the game needed. Luckily, the developers of Fire Hose’s second accelerator game, 20XX, were working with an amazing composer, Brandon Ellis, who we asked to help us out. He was able to whip up wonderfully playful, catchy tracks in a short amount of time (I believe we asked if he could do 8 tracks in 6 weeks) and they fit so well into the game.

Towards the end of development we wanted to make sure we didn't mess up marketing for the game’s launch. To do so, we reached out to our PR friend and fellow Boston developer Will Brierly, who has experience promoting silly first-person games. Will was a big help in reaching out to tons of press sites and YouTubers while I focused on the last-minute tasks that needed to be done for launch.

So, my takeaway from this is: if you’re the lone wolf type, unless you’re incredibly talented, are rich, and/or have lots of time, I highly suggest working with others!

5. A smooth launch

The game’s launch was surprisingly smooth. Primarily, there were no critical bugs that prevented players from playing or other occurrences that negatively affected us (such as, other big-name launches, ill-timed logistical issues, etc.). Will’s PR outreach got us a bunch of articles near and on launch day, our Kickstarter beta period on Steam ensured a simple deployment, and our day-one sales were pretty good!

The only issue I can think of was that Steam trading cards went in pretty late (my bad) and weren’t approved until 30 minutes after the game went live. I was able to silently update things through Steam though, so I’m pretty sure no one noticed that the game launched without them.

Progress screenshots from the prototype (top-left) to the final game (bottom)

What Went Wrong

1. Core design work

Besides the decision to switch to a procedural level generation structure before the Kickstarter, a lot of core design decisions were made far too late in development. The core gameplay and metagame were never really fully designed because we were always focused on the quickest way to get the game done, and we never really took a step back to really think about what the final game would look like to players. There were multiple changes in direction over the course of development, which ultimately resulted in some mismatched gameplay.

Initially, the game’s structure was going to mimic a simple puzzle game, where the player would complete premade rooms (“levels”) within houses (“worlds”) until all of them were completed. After the procedural system was in, I started pursuing a roguelike design with rooms that would lock and unlock as you completed objectives and randomized upgrades. When the roguelike system didn’t seem to be working, I made entire houses open from the start, added some side objectives (bonus and high-value objects), and added random events (drawing inspiration from Kirby Air Ride’s City Trial game mode). With our self-imposed deadline coming closer, we stripped the metagame down to a simple infinite runner structure with high scores and optional, functionless unlockables.

The really old level select menu, with different objectives for each room

2. Shallow gameplay

One issue that has always been apparent is the game’s lack of replayability, and we were never quite able to find a solution. We understood that the game should be about a cat knocking stuff over but didn’t think enough about how to keep that fun for more than 10 minutes. Part of this is because I naively thought the core concept of being a cat and having a bunch of collectibles (like cat photos) would be enough to keep players entertained. (Maybe this would have been enough if the full game had released before the indie “crazy animal simulator” phase?) I had also wanted to keep the gameplay fairly freeform and welcoming to more casual players. After all, you’re an adorable cat and no one should tell you want to do!

Unfortunately, lots of players look for challenging gameplay, a sense of progression, and depth in the games they buy and play and Catlateral Damage doesn’t have much of that. It definitely feels like more of a toy than a game at times. It doesn’t demand your attention and no matter how long or often you play it’ll always offer the same experience. In a way I don’t think this is necessarily a bad thing. Perhaps embracing the playfulness of it by adding mechanics that reward experimentation and exploration within the game space rather than forcing goals onto it would have helped make the game feel more substantial.

3. Stale content

Although there is a ton of objects to knock over, several toys to play with, various different level types, and a handful of little randomized bits, the game tends to feel stale very quickly. This could be because there is just not enough content (only hundreds of objects instead of thousands). Or, maybe the level data just presents most of, if not all, the content to the player in each play session so there’s nothing to unlock or discover. You can pretty much see every piece of content by playing each level once.

I also feel like although there is a decent amount of content, it’s all the same to the player mechanically; each object is just a visually different object to knock on the floor. This could be fixed by really tweaking the physics components of each object (weight, friction, etc.) so objects feel significantly different when they are knocked around or when they hit the floor. There could be other interactions between objects, like objects that stick together, repel each other, or create some other special reactions. Moving targets could present a more interesting challenge than just going after stationary objects.

How every level ends

4. Not enough playtesting/QA

Towards the end of development, a lot of things were getting cut due to time constraints and one of those was formal QA testing. This feels incredibly ironic to me because working as a dedicated QA tester has shown me how vital QA is to the development process. It is possible that this experience actually helped me test features and content as they went in instead of throwing them in and testing later. Fortunately, as mentioned above, there weren’t any critical bugs, but there were still some non-trivial ones that would have easily been caught with just a bit more testing.

Earlier in development I was bringing versions of the game to local meetups like Boston Indies, usually to test out builds before demoing at events like PAX. As it got closer to launch though, I decided to focus on getting the game done instead of trekking out to meetups. This additional playtesting closer to launch may have helped to solve some of the design issues we were experiencing and thus made the game better at launch.

5. Lack of polish

The last thing I wish we had spent more time on was some overall polish to give the game more personality and to make it feel better. Since I was concentrating on getting the game done in the months leading up to launch, I didn’t have the time or creative capacity to add little details. And since we were trying to meet our deadlines and only add what we needed to, polish was pushed to the backburner and a lot of it was cut at the end. Some things that I would have liked to add are more/better particles, shader and texture tweaks, player movement tweaks, UI improvements, and more cat puns.

An example of the type of polish I think the game needed much more of is the little crosshair in the middle of the screen. It's not intrusive and players are happy when they notice it. It also changes in different contexts: if the player is near a small object it'll change to inform them that the object can be picked up and carried; if the player is near a toy like a house plant it'll change to let them know that the toy can be bitten. Most players probably won't notice little bits like this, but having a bunch of them makes the game feel better.

Just a little kitty snout

Conclusion

Looking back on it, Catlateral Damage was definitely a success for me. I was able to work with great people to ship a reasonably sized game in a decent timeframe. And financially, I’m better off than I was as a QA tester! As my harshest critic though, there are several places where I could have done better to fix some of the game’s glaring weaknesses. More time on certain areas may have improved the game but come with the downside of delays and increased costs. I’m satisfied with where the game is now but I’m planning on adding and tweaking a few more things in free updates in the near future. After all, launching a game isn’t necessarily the end in this day and age!

Chris Chung is an indie game developer who loves video games and cats. He was the primary designer, sole programmer, lead artist, producer, social media expert, newbie businessman, and cat whisperer on Catlateral Damage.

Data Box: