Developing a Real-time Android Game - Lessons Learned Part 2

Lessons Learned - Part II

We 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 second post in the 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 has been and will continue to be a mixed bag of topics about coding, project management, agile and marketing.

You can find the first post here and an off-shoot post about optimizing realtime android games here.

Issue Tracking and Sharing the Work

Really important part in any agile project is an efficient way of sharing the workload. Shared tasks should be available in a centralized place and you should try to find the easiest way to manage this task. The more difficult the sharing system is the less you want to use it.

We kept our code at Bitbucket as they now offer Git-repositories and have free private repos for small commercial projects too. In the beginning of our project we also used Bitbucket’s issue tracking. It was simple enough to use and the issue states where relatively easy to change. In the long run though, creating the issues was too slow and too verbose for a small project.

For an agile project it’s typical you add lots of small tasks on one go. These tasks usually contain quite little information. So adding them one by one, each time getting stuck on a page full of options, dropdowns and switches is far from efficient. So we opted for a simpler way, just using a simple Google Docs spreadsheet. It was easy to add lots of tasks, reorder them, mark their owner and then start working, calling dibs for the task you wanted to do in IRC. Simple, easy and fast.

Multi-site Project

Making a real time game itself is hard and needs lots of planning and work. Working with a multi-site team makes it extra hard. Multi-site team communication is the hardest part, you can use IRC and phone but really making them “see what you see” would require a face-to-face meeting.

It is also challenging to argue with equal members of the team with different visions and trying to find a proper consensus. It’s really easy to be misunderstood and sometimes it’s really frustrating to explain something on phone or in IRC.

Getting feedback is also more difficult and may take hours or days compared to instant feedback with onsite team. Feedback from our graphics designer usually took plenty of time since he didn’t have the environment to compile the game.

What we learned was that even if it’s difficult, you need to schedule frequent live meetings when everyone gets together and talks with the whole team. We will also start using video meetings in the future.

Don’t Let Engineers Do Your Graphics

How many times have you thought that the game logic of the game is awesome? Never, but damn those graphics! If you want to look good, get a real artist to do your graphics, graphics by engineers are not a real option. Our early stage versions had graphics that the programmers had salvaged/made and to be honest it really wasn’t pretty.

After we got our graphics designer we took a major leap towards to what the game is today. Cool graphics, awesome backgrounds and menus that were pretty easy to use.

Draw a rough version of your menus and UI designs before you start working with the actual implementation. This will save you plenty of time in development and possibly saves you from rewrites. The most important thing with the rough versions is to let your UI designer do the work! Having a proper UI Designer is more than having good game graphics. UI design is the key to make your game as easy to use as possible.

Keeping a Development Blog

When you are working with a game you should remember that marketing of your game starts from the day one. You should consider to keep a blog, be active on forums and try to create hype around the game.

Keeping a development blog is really hard during the development phase. Before sharing think what was the most important thing you achieved and what is the main idea you want to share. Write your ideas down, even though it’s not as fun as writing all the new cool features for your game, other developers could be working with the same or similar problems. Be professional because all of your publications are also good references in your CV.

Publishing your blog posts is a good start but getting people to find and read your blog is almost as hard as getting people to find your game. To get audience to your blog, you’ll need to forget all the modesty and work hard in Social Media. Share posts from your blog in Facebook, Twitter and on the forums where you are active. Also place a link to Hacker News and Reddit and be creative with the header.

In our case our blog had had around 6 000 page views, in 10 months, before we released the first part of the “Lessons learned”. We had done absolutely no promoting of the blog before that. We got 3 000 page views in 36 hours when we shared the post on Reddit and Hacker News. Sitting down and hoping to get audience is not a good tactic. Be open and work hard. Try to think outside the box and be creative.

Version Control Saves Lives! (Git)

When working with a project, use version control! If you haven’t used version control before, it’s about the time you do! Two main benefits are offsite backup of your source code and easier sharing of up-to-date code with others in the same project.

Use a version control that is flexible and easy to use. We used Git which is one of the best version control systems there is and got our central repository from Bitbucket. The reason we used Bitbucket instead of GitHub was that Bitbucket provided a free private repository that you could share with your fellow developers (4).

When you do development, keep your bleeding edge development in separate branch. Make lots of small working commits and merge your changes to the master branch when you are done. Small working commits are really important when you need to do bug hunting and you want to isolate a new problem in your game (see git bisect).

Always have a workspace without modifications or untracked files when you start working with new modifications and always make sure that your code compiles before you commit your changes. Also, avoid doing refactoring and bug fixing in the same commit.