You are on page 1of 5

Developing and publishing an android game in like three days

Posted on February 28th, 2009 chris No comments Iconic Memory is a fast paced puzzle/memory game using androids touch-screen, a project a friend of me and I have been working on (video). This was our first game for android and we went through the whole ideadesign-development-release process in just about 3 days. After smoothing out the last rough spots late yesterday, we released the game on Android Market at around 2am. In the first 10 hours the game was already downloaded 500 times! We are very happy about the positive feedback and ratings we received, and want to encourage anyone thinking about starting a small project like this. Its a great opportunity to get an understanding of the ins and outs of the whole process. And there is no formal review, thus every submitted app appears in the market and will be rated by android users!

Day 1: Setup, Gameplay and Design


Starting a new Android project in Eclipse takes just a minute, as well as a svn repository and a way to download the development .apk files to the real G1 (be aware that the G1 has problems downloading files with spaces in the filename). We created a symbolic link to a local apache folder and an index.html with a link to that .apk file. That way we can install the development binaries on the G1 over the wireless lan with just a click on the link. We thought the simplest way to get started with a game is using 2d graphics as explained in the android docs. First we created a custom drawable view that we would attach on the window. This view contains a couple of shape drawables (2) like rectangles and circles, which we would color with getPaint().setColor(). After some playing around and trying to understand (finish level 2) the simple game Stroq, we figured we could do a pattern matching game. We created some basic levels (basically bitfields containing 0 or 1) and experimented with different ways of interacting (eg. only one allowed stroke). Finally we stuck with the idea to let the user swap as many fields as they want within a given time. At that point, our game screen looked pretty much like the final version (video).

Capturing the touch events was as simple as placing this code in the games activity class:

view plaincopy to clipboardprint? 1. public boolean onTouchEvent(MotionEvent event) { 2. int eventaction = event.getAction(); 3. switch (eventaction ) { 4. case MotionEvent.ACTION_DOWN: // touch on the screen event 5. PlayField.fieldUpdatePos(event.getX(), event.getY()); 6. PlayField.postInvalidate(); 7. break; 8. case MotionEvent.ACTION_MOVE: // move event 9. PlayField.fieldUpdatePos(event.getX(), event.getY()); 10. PlayField.postInvalidate(); 11. break; 12. case MotionEvent.ACTION_UP: // finger up event 13. PlayField.postInvalidate(); 14. break; 15. } 16. return true; // tells the system that we handled the event and no further processing is required 17. } With the function postInvalidate() we tell the view to redraw all the included shape objects. At this point the basic set of levels became annoying and we decided we want a kind of level generator. We implemented that in an interesting way: for each leve, the system generate 100 totally random levels and evaluates each one for given parameters. Then the highes ranking level will be used and the others are dismissed. Points are received for the number of white spots depending on the level, for spots on the sides as well as for connected fields. This simply algorithm does the job surprisingly well, and produces enjoyable and good-looking levels at an increasing difficulty. Other ways to make the game increasingly difficult are increasing the number of white spots each here and then, and by reducing the preview time (starts with 3 seconds) by 45 ms each level. That does not seem much, but after level 50 youre missing 2.25 seconds out of 3, and thats like really hard :-) At that time weve implemented almost the whole gameplay and finished that hacking afternoon with a cold beer away of the computer :-)

Day 2: Gameplay and High-Scores


The gameplay felt quite good by now, and it was time to make varying difficulties (easy, medium and hard). We created a frontend-activity where users can choose the game-mode.

Training mode has a few explanations on how the game works, quite long preview time and does not gets harder very slowly. Survival - Medium starts with 4 white spots and reduces preview time for 30ms.

Survival - Hard starts on a black screen with 5 spots and gets harder very quickly. During testing we would never pass level 55!

Once that worked, we wanted global rankings for a bit more thrill in the game. Since a game takes just 2 or 3 minutes, high-score would give some meaning to reaching a lot of points! Another side effect of web-based highscore is that you can edit/update/modify it without having to push an update to the app (i.e. if you want to integrate ads or different rankings). The easiest we thought to do that was to create a Django application that consists of one simple Ranking model, one view and a couple of templates. It was as easy as we hoped, and we got the whole thing set up in one hour or so. With a WebView it was extremely easy to embed websites into an android app (be sure to enable JavaScript in case you want to place js ads in there someday): view plaincopy to clipboardprint? 1. WebView wv = (WebView) findViewById(R.id.wv1); 2. wv.getSettings().setJavaScriptEnabled(true); 3. wv.loadUrl("http://iconic.4feets.com/highscore/1"); At the end of that day we had the basic app fully set up: welcome screen, game screen, gameover as well as highscore screens, including the web side of things.

Day 3: Workover, Ads, Update and Release


All three days we did constant testing and bugfixing, until we couldnt find bugs anymore (that didnt mean there were none :). So the app was running very stable, but had a major flaw: There was no pause mode. If a call would come in, or you lost focus in any way, it would kill the game. That would mean one thing: bad ratings! We thought about cheating possibilities, but figured if we didnt show the preview again, a pause mode would just be fine. Implementing pause was quite easy. Following the typical activity lifecycle, we had to handle the onPause and onResume events the window would get. On Pause we save the game state, and on resume we restore that state and show a popup asking to continue or start a new game. Not that difficult; basically extending that code for the specific needs: view plaincopy to clipboardprint? 1. 2. 3. 4. 5. 6. 7. 8. 9. @Override protected void onPause() { super.onPause(); Game.pause(); } @Override protected void onResume() { super.onResume();

10. Game.resume(); 11. } That day we read a post on anddev titles selling games or placing ads in them, which suggested that ad-supported games might be a choice over paid apps in some cases. As we cannot release paid apps by now (in Europe its supposed to start at end of Q1), we wanted to try out AdMob, a mobile ad provider that has ready-to-use plugins for android. We decided to try that out as well and got it up and running in like one hour without any hassle. Once we know about how that works out / how much they pay, well post about that!

Ready to release!
Following the Signing and Publishing guide, the last step now is to integrate an updatechecker into the app. The market does not (yet) notify users about possible updates, thats why apps usually check (daily or so) a website that tells them the current version number. If it is higher than the own one, start a link to the market where users can upgrade manually. The last step before publishing on the android market is to add a nice icon (if you dont already have) and to sign the app with jarsigner. That worked without a problem, as long as we didnt rename the .apk file.

Release
We published the app on the Android Market at around 2am GMT+1 (Europe/Vienna) and took a little break. The game appeared in the market after 2 or 3 minutes, and checking the highscores and comments after 15 minutes we saw that a few people already liked it and played it beyond level 55 A bug appeared there: after level 59, the preview delay was only 0.3 seconds, which was too short for the game to display anything. Hence nobody could pass level 59.

Update to Version 2
We fixed it by decreasing the preview time more slow after level 58, and published version 2 around an hour after the first one. At that point it came to my mind just how much quicker a team of independent developers can act compared to a company that is not that flexible.

Day 4: 20h after the release


Right now, 20 hours after the release, the game was downloaded 1012 times with 885 active installs (87%), 33 ratings (total average: 4.2/5.0) and 15 comments (no flames yet :). About 500 high-scores have been submitted; current #1 in hard is user tats narae alabong with 6167 points on level 104! This is how the android developer dashboard says right now (its updated twice a day or so):

We had to fix one little thing on the web side of things today: Because of that many highscore entires the scrolling was a bit slow in the app, so we split up the high-scores on the web to

show only the top 70 on the front, and let users go to the next pages showing 100 entries each. We are very happy and surprised that this game would reach so many people in the first 24 hours, and that many are actually really liking this little game! We hope you feel encouraged to start your own small game/project!

You might also like