Android Hack Day – Brighton, 23 Jun 2012

Last Saturday (23rd June) was the second hack day I’ve organised. Eight of us (Me, Colin, Dave, Matt, Mike, Naomi, Nathan, Tony) got together in my flat in Brighton for a day to create an Android app.

We all have Android phones but none of us had any experience writing mobile apps for it. So we set ourselves the challenge of creating a game – an online version of shove ha’penny.

The game

The basic premise of the shove ha’penny game is to push a coin along a board so it slides and stops between the lines on the board (called a “bed”). Points are scored if you get a coin in each beds.

So for a mobile game we modified it slightly and came up with the following simplified spec to give a chance to get it working within a day:

  • Coins are launched with a swipe on the screen (speed and length of swipe determine how far the coin goes)
  • Coins move in one direction only (up the screen)
  • Only one coin in play at a time (there is no collision detection)

Development

Following on from what we learnt from the Python hack day I setup a github repository before the day, created a basic outline of the project (loosely based on the Android SDK accelerometer demo) and pestered everyone to ensure they had Eclipse, ADT and the emulator working on their laptop.

I think this made a big difference as everyone was ready to start development when they arrived. It also got everyone excited about what we going to create and thinking about how to use Android.

Starting

Dave coding on the Floor

Everyone arrived around 10ish and we set about dividing out the tasks. Roughly this broke into:

  • Scoring storage, players and high scores
  • Basic physics engine (how the penny moves and stops)
  • Game scoring, turns and players
  • Swipe detection and measurement

We then split into teams of between 1 and 3 people.

Physics Engine

I worked with Dave on the physics engine – which determines how the pennys move on the screen. We decided to use the verlet integration to calculate the position of the penny. This works well because the period between drawing the screen (i.e. calls to the Android view’s onDraw() event) might not be constant, so the verlet integration attempts to correct for this.

We battled with working out how to apply friction to the penny moving. Eventually we settled on the quick solution of applying a negative acceleration to the verlet algorithm, detecting when the penny is about the reverse direction and then preventing it from moving further. A bit hacky, but it does the job.

Git

Like the last hack day and most of my home project development, we used git and github for version control. I have just introduced Mercurial to my team at work, so I wanted to see how git compared in a multi-team environment.

We decided to use branches for each feature so each team had a branch to work in. This worked very well and merging changes together was very easy – any conflicts were encountered were trivial to fix.

Compared with Mercurial, the only thing I liked less in git was that branches are not automatically synced upstream and non-ff branches was a pain as we lost that some commits were part of a feature branch, not master. But the github interface is brilliant and easy to see the changes visualise how branches are merged.

Android

Matt and Dave play the game

The Android SDK is very easy to program for and the tutorials go a long way to explaining how to do the basic stuff. They have done a good job of wrapping up the complexity of the system, and stuff like interacting with the phone hardware (sensors, screen etc) is very easy one you have the right parent classes and listeners registered. And the huge community online makes it very easy to find out the best way of doing something.

As ever, it’s always better to reduce coupling and keep the development framework (i.e. Android in this project) out of as many files as possible. We specially tried to create classes that had no Android imports (they just used the normal Java libraries) so they were easy to test with JUnit or run direct from the command line. Our physics code and storing of game turns and scores were created this way. Doing it this way makes testing easier, development is easier to make concurrent and it’s less likely for development to be slowed waiting for someone else to fix code so you can see yours in operation.

Conclusion

The finished app

By the end of the day we managed to have the game play of the app working, and we finished the day with Dave and Matt having a two player game on a phone (Matt won). We didn’t manage to get the high scores database working on the day, but I managed to fix the main bug with it on the Sunday.

Overall I think everyone had a good time (see all pictures of the day). We had lots of fun, learnt lots about Android and actually got a playable game completed in a day. The next step is to fix a few more bugs, test on more devices, polish the interface and then release it to the world via the Android market. Then we can also think about any more features to add (there are plenty in our heads).

Leave a Reply

Your email address will not be published. Required fields are marked *