Developing a Realtime Android Game - Lessons Learned - Part I

Lessons Learned - Part I

We just completed our 11 month journey of creating a realtime space shooter for Android using Scala programming language. We did the project in our freetime and you can check out the end result at www.scawargame.com.

We learned a lot during these 11 months. This is the beginning of a series of blog posts about things we think went well and things we would definitely do differently if we were to start again from the beginning. It will be a mixture of topics about coding, project management, agile and marketing.

Plan Well

We did pretty much everything in our project in an agile way: very low bureaucracy, development in sprints, work lists in backlogs, used pair programming and weekend hackathons. We also did stuff in the usual way, wrote production code while still very much in learning phase. All this is well and good, but what we forgot and paid dearly for is that design decisions have a so-called last responsible moment of making.

Planning too much ahead is risky but if you delay your design decisions past the last responsible moment, the decisions are made by default. So instead of a concious group decision, you just implement what think is needed. Soon after you realize you just implemented something that was just your reflex and if you would have thought this through with your team earlier, you would have come up with a better way of doing it. Now, you will come up with the better idea but it’s too late to avoid rewriting major part of your work. Repeat this often enough and it will get frustrating.

So plan well here means: plan enough, just early enough and plan it with your whole team, don’t just make quick decisions to get on with your implementation.

Hard Work Makes You Hate Your Game

One thing about projects that take a long time: you are going to hate them! They eat all of your free time and make your significant other mad. Working with the same thing for months get really boring very easily. And since we were using our free time, it was sometimes really hard to get motivation to start working again after a long day at work.

Best solution what we discovered was don’t work alone! When you have pressure from other developers, the pressure is the best motivation to make you work harder. Nothing makes you feel better than getting feedback from your fellow developer saying “Shit, that is awesome!”

Also remember to take some time off from your project. Fresh mind and body will give you new ideas and perspective on what should be done. Spend time with your family, they seem to nag less if you do so.

Motivation from Goals (SPEC)

Well planned goals are a key in enabling you to finish your game someday. In the very begining of our project, we didn’t really make goals, we just did stuff. Doing stuff without goals is a good way for getting to know your tools and platform, but for advancing your project, not so much. Better way to do proof-of-concept is to do Spikes: time-boxed research / development tasks that should be thrown away. You’ll avoid plenty of mistakes in your project code and design this way.

After a while in to our project we started planning what we should do and tried to prioritize what was important and what wasn’t. Working with the prioritized list made it easier to get the important features completed. Completing an important feature will boost your motivation through the roof. Prioritizing is a good way to help you create goals. Also when working with a team it’s easier to divide tasks with your fellow developers when you know where you need to focus.

Our first release version, which actually wasn’t released, changed our way of working more dramatically. We got a huge motivation boost from squeezing the first release candidate ready, or should I say the first actual beta. We had good features but... not enough content, not very polished version and loads of optimizing to be done.

This was the point where we started to do actual “sprints” with features that needed to be completed. We already had done the Spikes and the prioritizing, now all we needed was some planning poker and set of features to agree on. When planning and doing the estimation, it is really important to get your team into the same place. Talk about the features and do the estimations as a group. Every member of the team has to participate in the planning poker! It’s not important if every member knows how long it takes to program a feature, but they can and will provide some other useful information to the planning.

Finish your goals. Make plenty of release candidates. When you complete a full list of planned and estimated feature, you get a motivation boost. Completing a “release” ready product boosts your motivation even more.

So here’s our mantra on how you should do your stuff.

Spike - Prioritize - Estimate - Complete = SPEC

Make Builds Fast

Make your builds as fast as possible. This chapter might as well be known as “do what we say, not what we did”.

Your build times affect your productivity. If your build times go up, you spend longer periods coding blind and this way you’ll also spend more time debugging. More debugging means more test builds. You get the picture, it’s a nasty circle.

But we were building an Android game with Scala. And as long-time enterprise programmers, we were building with Maven. So we had few problems, namely:

• Scala is bad for your build times
• Android is bad for your build times
• Maven is bad for your build times

We should have never chosen Maven. But then again, building for Android involves lot of extra steps, dexing, signing your code and zipaligning your packages etc. So you definitely need automated builds. By the time we started our project, SBT, Scala’s not-so-aptly-named Simple Build Tool was constantly and completely rewritten, it seems, every few days or so. Well not quite, but enough to encourage us to stay away.

Scala’s library is pretty big. And maven scala plugin stopped supporting incremental builds. So compile times are pretty bad as you always load the whole language library and always compile your whole project. Dalvik, Android’s JVM, can not survive the amount of classes included in the Scala library. So you need to run Proguard, to shake off all classes that are not really needed by your application. On our machines this takes as long as compiling.

We tried several things to shorten the build time. Mainly how to skip the proguard phase. After proguarding your application, you can grab scala-part of the resulting classes, put them in jar and use that package as a dependency instead of the full scala library. We wrote a short blog entry about this a while ago. This allows you to skip the proguarding entirely, but every time you use a new API from Scala, or a new implicit conversion or something subtle like that, you need to create a new jar with the new required classes included. So this might have some uses in a stable and mature project project but it will get tedious really easy.

Other option was to hack the Android bootloader to load Scala libraries on startup along with other libs provided by the OS. We did this on the Android Emulator but were reluctant to do it on real devices. Partly because it’s a bit sketchy and partly because we then would not have had regular devices to test on.

To top things off, once your package is done, you need to uninstall the previous version from your phone and install the new package. You can’t use Android Emulator as it’s pretty much one of the worst pieces of software known to man.

End of Part I

Well that's it for part I. We got plenty of topics lined of next parts. As always, comments, diggs, +1:s etc are very welcome.