
A trip down memory lane: My first commercial Android game
Earlier this week, I met up with a friend and old colleague of mine to talk game dev and other stuff, and we ended up looking at a backup folder he had with the code of games and apps we worked on almost a decade ago. For some reason, he happened to have the source code of Tito Pececito, the very first Unity-powered Android game I ever made, and so I saw this as the perfect opportunity to discuss the game’s development, as a sorts of a belated postmortem.
Background
So, the year was 2012, and I was working at a company focused on making mobile games and applications for J2ME and Blackberry phones. However, the Android market had been growing by leaps and bounds at the time, and the company finally decided to develop a game for the platform.
The original plan our bosses had was to remake an old game of theirs that was basically a sprite swap of Space Invaders. However, we knew that such a project wasn’t going to cut it, and somehow managed to convince the higher-ups to give us some creative freedom for the adaptation. A fellow artist, programmer and I then worked around the clock to come up with and implement whichever changes we could to the base game.

probably wren’t a coincidence at all.
From the ground up
Since we had to rebuild the game from the ground up, it meant we could actually change parts of the gameplay, and so we did. On top of giving each enemy type distinctive attack patterns, we also decided to give the titular bubble fish an ability that was pretty on-theme: blowing bubbles of different sizes.

Larger bubbles dealt more damage, but moved more slowly.
Our artist quickly managed to take the miniature pixelated enemies and model them in 3D, with a fellow programmer learning enough Blender to make simple animations for each of them. Meanwhile, I had to deal with a huge bottleneck: the game was having awful framerate issues when deployed to Android devices due to the number of animated enemies that were on-screen at any given time. That was a part of the old Space Invaders experience that we definitely didn’t want to emulate!
Unity back then had a much smaller community than it does nowadays, so finding a solution to the problem was pretty hard. I finally did come across a way to animate a single skinned mesh renderer, bake its vertex data, and then have all on-screen enemies merely reference that data. With that, the game was back to being playable, yay!

Answer: only three! (fish, crab and swordfish, since jellyfish only had their scale animated)
Another nifty dynamic we noticed was that the simple AI I made, which had all enemies decide attack intervals by themselves instead of having them all managed by a single system, meant that the game’s difficulty escalated seamlessly as we created waves with more and more enemies for the later levels. This could result in danmaku-style patterns randomly showing up every now and then, but we felt it added enough difficulty without being overly punishing, so we ended up leaving it as-is.

meant players often had enough time to try and avoid them.
Pushing the envelope
The game was intended to have ten levels in total, only recycling the three types of enemies we had (red crabs, jellyfish and blue crabs). However, that really didn’t feel like it was enough for us, and since we were pretty ahead of schedule, we went ahead and planned for something new and exciting: a final boss!

they immediarely gave us green light to complete the boss and add it to the game.
The giant octopus was the single entity in the game with multiple attacks: It could swing its front tentacles, shoot projectiles at the player’s current position, and also had a spread attack that covered the center of the screen. Back then, we didn’t even have Unity’s current animator controller system, so the AI and its animations had to be managed from scripts alone, which was pretty confusing and resulted in a couple bugs popping up along the way. Still, we were really happy with the end result, as the giant octopus made for a fun and satisfying fight.
GUI hell
Finally, I’d like to address the elephant in the room: the game GUI. Back in Unity 3.5, there was no scalable UI or sprite renderers, so all UI elements had to be drawn on the viewport using pixel values.

This meant that adapting UI elements across multiple display resolutions had to be done by hand, and we simply weren’t up to the task back then.
The only phone our bosses had set as a target for the game was the Motorola Milestone, which had a much larger screen resolution (480×854) than any other Android phones we were using at the time. The results of making our GUI target such a high resolution when Unity didn’t have any tools for scaling UI elements were… well, simply catastrophic:

Conclusion
Looking back, it’s a real shame that we ended up shipping an APK that downright didn’t work on cheaper cellphone models, but I simply wasn’t up to the task of handling UI scaling all by myself back then. These kinds of things really make me glad that we no longer have to deal with all those complications nowadays, mostly thanks to the community’s continued efforts to make up for Unity’s shortcomings.
Now, seven years after the game’s released, neither the APK nor the company that created it exist outside of archive or mirror sites anymore. Even in spite of it still being a Space Invaders clone, having lousy code and some questionable design choices, it was really neat to come across the source files after all these years, like a time capsule of sorts. It might not have ammounted to anything in the end, but the passion the three of us poured into the game is something I definitely will never forget.