Bullet Flight mini Postmortem: Making small while thinking big

Bullet Flight

In the summer of 2014 during some weekend I’ve made a simple game for Android called Bullet Flight. I wanted to make something small, but with a strictly defined theme. On 9th March I’ve published it on AppStore (Android recived an update) and while it is a very small game I think there are some valuable lessons that could be learned from it.

What went right

1. Defined theme

Before I even knew what the game would be about (from mechanical point of view) I’ve set a strict and clear theme to keep my mind wrapped around while designing it. The theme was of course a ’bullet’. Next I’ve moved into making it fly, so shot from a gun was obvious step and because it is convenient start designing it as endless runner game. The theme was really helpfull not only during that stage, but also during assets creation: all parts of the game were very clear right from the beginning. That saved me a lot of time and headaches.

2. Redesign if necessary

First version was quite simple, there were no other mechanics than just trying to avoid obstacles, next I’ve added boost mechanic and tokens (you could buy continue for one token). However the tokens mechanic didn’t quit worked as I wanted to. Players didn’t cared much about collecting them, heck they didn’t cared at all about tokens so I get rid of them. The boost on the other hand was really dull, but I didn’t wanted to remove it just make it more dynamic, built into the gameplay. I’ve improved it by giving the player the possibility to extend boost duration by bursting through walls. It really engaded players into caring about collecting the boost more than before and what’s more important during boost they were focused even more than usually because they knew that maintaining boost could really improve their score.

Boosting

3. Localize early

Bullet Flight has very little text so I’ve decided to localize it … with translator. I’ve used translator because there were very few senteces, mostly single words, phrases and I think that having even translator made localization is better than not having it at all (at least for games where the text doesn’t matter that much). The most important thing was that from the begining I’ve build into the game localization tools. Later on I’ve just extended my dictionary and made a language selection screen. I didn’t spend much time on it and I think it was worh it as users tend to appreciate more your app if it speaks to them in their local language. Oh yeah, and the language selection screen: it’s better to have one instead forcing OS language in case someone enjoys playing games in english.

Language Selection

What went wrong

1. Keep your code clean

It was a game made in two days (the first version), so obviously the code was not so pretty, it was ment to work and it did, some changes could be made, some things added, but it wasn’t flexible enough. When I’ve decided to make a port to iOS I’ve refactored the code so any changes could be made and adding new features would be easy and fast. Of course the updated version took twice the time to create than the first version, but it was worth it. Keep code clean and refactor often even for small projects.

2. Improve prototype instead of redesign

Redesigning the games was really beneficail for its ’fun’ factor, however it should have been done during prototyping / beta phase before it was released. I think this game launch could have gone better for Android initially if it has those features that are present in the current version. It could also save me more time during the production phase and porting of the game. I've seen such struggle during the production of commercial games and it wasn't pretty. People get frustrated when suddenly the project design is shifting, some major features that supposed to be core of the game gets cut, new out of place features are added. That's bad for the project and morale of your team.

3. Mobiles aren't social from nature

You have to make it clear for yourself if you really want to include social features in your game, because it will cost you some time, time that you probably overestimated, because of some 3rd party sdk’s not working correctly or time you have to spend on proper testing. That could really mess with your schedule and take your time that you could spend more of into polishing your game. I’m not saying that you shouldn’t do it, just to have a place for it in your schedule and probably do some research and get simple yet elegant solution that would not cause any trouble during integration. I failed on that field: right after adding leaderboards and achievements to the game I’ve decided that I should include share button – it will be simple and quick right? Nope, I’ve overestimated the time it would take and I don’t think it was that important for Bullet Flight to include it. I’m glad I didn’t decided on adding facebook friends list…

Conclusion

Bullet Flight is a simple game from which I’ve learned quite few lessons. These lessons applied to bigger projects could save me lot of time in the future. I think it’s most important to have a clear vision from the begining and keep your game as prototype until you’re certain that it is fun. If not you should either change your point of view or move to another project, just don't force it.

Data:

Release Date: summer 2014 (Android), 9th March 2015 (iOS + Android update)

Development length: 2 days initial game + 2-3 days first updates, current update and iOS port took 5 days

Development tools: Unity3D, coded in C#, Inkscape and Gimp used for graphics

Download from: AppStore, Google Play