On a day like today, on December 21st 2013, Twin Robots debuted on OUYA, the first platform where it was released. A year has passed since, so today seemed appropriate to finally look back and write a post mortem on the game. Bear with me as this is my first post mortem ever! It will focus on the development pre-launch, whereas on an upcoming post I’ll write about what happened after that.
If you are short on time you can jump to the end of this post to read the fancy “What went wrong / What went right” section.
Twin Robots started when I was starting to learn Unity. I wanted to learn the ins and outs of the character controller so I grabbed the 3D model of a cute robot (that I designed some time ago to be 3D printed), quickly animated it in a walk cycle and imported it into Unity. I made some quick progress and that encouraged me to go on and build a platformer game. However, common sense weighed in and since this would be my first game using Unity I decided to go smaller: that’s how, after 6 months of part-time development, on September 2012 Save Sea Turtles! was born. You can read here how those 6 months of part-time development really meant about 22 days of full time work.
Once that game was done, I wanted to try a Ludum Dare competition. Well, I did jump in and built a lower resolution version of the cute robot (the original one was high poly), but once again the lack of spare time meant that I didn’t finish my game before the deathline. However, this became the foundation of what Twin Robots would be, and this is how it looked at the time:
I decided that I’d continue working on it making it a bigger, longer game; I pictured a game where this little robot would awake in a lonely lab in a post-apocalyptic world, thanks to a sun ray shining through an overcast sky for the first time in centuries. This would power the robot a bit to barely make it work, allowing him to get out of the lab to find clean energy sources to stay alive, refilling his battery along the way.
Being a solo dev, I quickly realized that it would take me years to finish all that on the side of my full time job; So I started to cut down on features, ending up with what Twin Robots is today: A much simpler game, with each level featuring a different combination of small set pieces that can be reused to save time instead of building a huge, unique scenario for each level. The intentionally dark ambiance also helped cutting down on production time, as well as design choices like using a single texture for the whole environment, with a limited palette of colors. The game was made targeting mobile devices so saving on textures was a must… specially those textures with transparent pixels that kill performance on lower end devices. There are no enemies in the game because those would add a lot of production time too: modeling, texturing, rigging, animating, and scripting them was something I just left out because otherwise I’d still be making this game today.
Even the game name itself, Twin Robots, was chosen after deciding to use the very same model for both robots, so I only needed to model, texture & animate it once; “Oh yes, they are the same model because they are twins, you know?”.
As you can see, there are a lot of places where I decided to cut down on features, but others took its time; From the very start, I wanted the basic mechanics like running & jumping to feel great, so I put a lot of work in those animations and the code that drives them. Maybe they didn’t end up great but good enough, a sentence I use quite often to convince myself to stop working on something and move forward.
It was all about being honest with myself, having a realistic view of what could be accomplished in a reasonable time frame with the resources I had at hand and what could not. What was important, and what was less important. Also, being able to do something doesn’t mean I had to.
The game was initially planned for mobile devices (Android) and desktop computers (standalone and in-browser). In August 2012 I backed a promising project for a console called the OUYA so I was planning to someday get the game running on it too, but for that I’d need to get my hands on it first. That happened, after some troubles with shipping, on July 2013. The first time I saw my game running on it, I knew that the OUYA would be the first platform to see the release of Twin Robots. It was a great feeling!
From there up to the release date on December 21, 2013, I kept working on the OUYA version almost exclusively.
About the time it took to finish: As I previously stated, I worked on this game on the side of my day job; By keeping track of the hours I really put in (using Paymo, by the way), I know that Twin robots was built in 288 hours. That means that, working 8 hours a day on a Mon-Fri schedule, it would have been done in 7 weeks; That’s under 2 months of full time work vs 1,3 years part time! Working part time really slows down the process.
About music and sound effects: Early versions of the game had background music but in the end I got rid of it because I much preferred the ambiance that sound effects provided, without the music interfering; Also, the music always got repetitive after a few minutes, since it was a single song on an endless loop. Sound effects were created in Audacity, editing & mixing sounds downloaded from Freesound.org; All of them were licensed under Creative Commons 0 which allows for commercial use and don’t even require attribution. I do like to credit the authors anyway so the game includes all of them in the “Credits” screen.
About code: From the start, I wanted to have a single code base so future updates could be done across all the build targets at once. That turned out to be a wise decision! The game has seen several updates since its launch and having a single project with all the code for the different targets proved to be a time saving choice.
The game uses several plugins, the most notable ones being NGUI for the user interface, InControl for the controller support, HOTween for interpolations / tweenings, and Exploder for… well, exploding things.
Leaderboards were hosted on Scoreoid when the game was released, but were later changed to a self hosted solution using Combu. Google Play achievements were added using EGPGS. The mobile version, which includes ads that can be removed using a promo code, uses Batch for managing that feature. Finally, I used Game Analytics for tracking all kind of things like where do players die more often, what % of them reaches a given level, etc.
About marketing: I recorded dev videos, wrote blog posts, used Twitter, Google+ and Indie DB. But not enough! Posts were very scarce because I always thought “I have just a bit of time, let’s work on the game instead of showing what’s already done”. That turned out to be a huge mistake, as I’m sure you’ve already read everywhere. I also wrote a lot of emails to the relevant press and youtubers, but only a few answered back; Some of them, like Pocket Gamer, Droid Gamers, AppsZoom, Indie Retro News or GamingOnLinux even wrote a review or a newsbrief! I don’t blame those who didn’t, though; I’m sure they get tons of emails like mine every single day. I’m not sure how I’ll face all this with my next game, but unless you have a killer game, chances are nobody will ever hear of it.
What went wrong:
- Lack of marketing! – This alone outweighs everything in the “What went right” section.
- Using building blocks instead of unique sceneries. This went wrong because it severely hurt visual variety from level to level.
- Having a full time job that left me very little free time to work on this game.
What went right:
- Being realistic, constantly discarding ideas that would only lead to feature creep.
- Using building blocks instead of unique sceneries. This went right because it saved me tons of time, and time has always been my scarcest resource.
- Targeting lower performance devices while building the levels and then adjusting quality at runtime.
- Keeping a single code base for all target platforms.
- Using prefabs everywhere. Very handy!
- Relying on plugins for dealing with tedious tasks and things that otherwise wouldn’t be in the game due to lack of knowledge and/or time.
- Having a full time job that allowed me to eat and pay the bills while working on this game… and to not depend on its earnings either, because otherwise I’d be now starving.
This is it! I hope you found this post useful, or somewhat interesting at least.
Oh, by the way: Twin Robots is currently on sale in OUYA, so you can get it for just $0.99!! If you really can’t spend that dollar and still want to play the game… Here, have a promo code that will get you the game for free in OUYA: NRXHHLDVQY. You’ll have to be both fast & lucky though, since it’s only a single use code! I hope you enjoy the game
Thanks for reading!