https://market.android.com/details?id=com.firedroid.barrrfull

User testing

At some point we thought the game was pretty close to what we wanted for the release, we just had one really important step ahead: User Testing.

Not that it was the first time we handed family and friends our phone and let them play, but that was more a “look what we’re working on”-event. This time we told them to look at the game as a complete game and tell us their experience. We got a lot of useful feedback.

When working on a game for a while you tend to begin overlook a lot of little issues. You know exactly why it works this way and accept it pretty quickly if it seems reasonable. We found a lot of issues that are indeed a little annoying and shouldn’t have gone unnoticed, but while we knew they were there we didn’t find them to be annoying because we knew too much about the game. A few examples:

• Start button at the end of the tutorial doesn’t start the game
• Customers walking to the treasury chest are still selectable, resulting in unnessecary misselections
• Delete button in profiles can’t delete last profile but is not ‘grayed out’
• Occupied indicator flashes shortly on the treasure chest when a customer pays
• Paying is instant (no animation)

The list is a lot longer but we looked at every one of them. Some of them were ignored, most were fixed or we changed the way they were presented to improve the logic. We even did some big changes in giving the user feedback when he clicks and when a pirate is done with an machine and is blocking its usage.

Afterwards I think this phase saved us from a lot of small and some medium-sized issues and it vastly improved Barrr’s ‘flow’. I’d like to point out it’s really important to not only send the .apk to some friends and ask for feedback but also to find some friends, give them the phone and casually look over their shoulder and sit through a few levels. This way a user will tell you the little, fiddly things that aren’t really important but if fixed add to the quality of the game.

Preparing for the release

The week before our release we were quite busy polishing the game but we knew we’d have to call it done sometime since there’s always something to improve and we were already very happy with the overall polish the game had.

So we registered an developer account and began watching the market’s “Just in” section to determine what would be the right moment to release the game. We found the end of the afternoon in the Netherlands (9AM in New York) didn’t have much releases and thought it’d be a good moment to release Barrr.

We prepped the last stuff needed for the release and made a list of stuff that was needed:

• A polished game icon
• Screenshots
• A small promotional graphic for the market
• Check the app’s debug output and remove as much as possible in the release version
• Check the complete install process for the final version
• Testing a full playthrough
• Setting the right version number for the app and the database
• Text for the market description

Releasing

Allright, release time! After the release we did a few things to get it done as smooth as possible:

• Giving a five stars review ourselves and asking a few friends to do the same, to get the app a good starting position (we feel this helped a lot in the first few hours)
• Keeping a close eye on the bugreports in the developer console
• Keeping a close eye on the user reviews in the Android Market
• Rapidly refreshing the downloads page
• In the following days we kept a close eye on our website’s analytics and google to search for reviews
• Feel good about the good comments

Number of downloads

First of all, the number of downloads has been amazing. We knew we had a pretty funny game but didn’t have a clue about how many downloads to expect. Personally I would’ve been very satisfied with a few thousand downloads, as it turns out I didn’t have to wait for long to wait for that goal.

We released the game at 16.22 GMT, after 4 hours the developer console updated and we had 1154 downloads and a 4,5 star rating! We were very, very happy.

Our next mark (10.000 downloads) was reached 4 days after the release and the user feedback blew us away, users seemed to be very happy with the game, demanding more levels already.

Over the next 4 months the number of downloads continued to rise, leading to this graph:

Overall we’re quite happy about how we released the game and we’re very happy people like it! The downloads seem to climb steadily and has given us confidence to continue work on the game, but more on that later.

• We tried using the emulator, it turned out to be really slow when it comes to OpenGL.
• We tried capturing a Android-phone running our game with a camera, but that didn’t turn out very pretty.
• We then experimented with making screenshots really fast, that too wasn’t really an option because it slowed the framerate to a griding halt.

At the end of it all we just made some screenshots and decided to use those and feel bad about not having a video. Or did we?

The emulator revisited

When I tested the emulator I came to the conclusion it was way to slow to run our game, I  got between 5 and 10 frames per second out of it on a decent workstation. Since our engine is framerate-independent the game was playable but just very slow.

We wanted to record a movie at 30fps, about 4 times what the emulator could put out, no way we could boost and tweak it to get the required 30fps.

Playing with time

Someone probably already thought of this, but it only hit me while showering and I think it’s a pretty neat trick. I’ve got a low framerate and framerate-independent game. What about slowing the game down?

Our engine is based on Chris Pruett’s ideas outlined in his Google I/O 2009 presentation Writing Real-Time Games for Android and blog, including the framerate-independentness (which is quite normal in games I guess, I thought it was a neat trick).

Our gameloop takes a delta time, which basically is how much milliseconds went by since the last “step”.

All I had to do was divide that by 4 to get a slow running game:

Recording the video

So now we’ve got our game running 4 times slower than usual, how do we get that into a video? On ubuntu, there’s a very nice tool, recordMyDesktop and after playing a bit with the graphical tool gtk-recordMyDesktop I had a line that recorded the portion of my screen where the emulator’s screen was:

recordmydesktop -o /home/roy/barrr-screencap.ogv --fps 30 --no-sound --no-cursor -x 2000 -y 49 --width 480 --height 320 --channels 1 --freq 22050 --device plughw:1,0 --v_quality 63 --s_quality 10 --workdir /tmp

This outputs a movie at 30fps (it’s a bit much for the 5fps the emulator runs at but the conversion below is clearer this way).

Great, now we’ve got a quite long video showing our game. We’ll need to speed it up. To achieve that we’ll use the tools ffmpeg and yuvfps with this line:

ffmpeg -i barrr-screencap.ogv -f yuv4mpegpipe - | yuvfps -s 120:1 -r 30:1 | ffmpeg -f yuv4mpegpipe -i - -b 28800k -y output.avi

The first part pipes the input movie towards yuvfps. We tell yuvfps to assume the input is 120fps (it’s actually 30 but we want to speed the video up, 4*30=120) and to output it at 30fps. We pipe that to ffmpeg again and tell it to output a .avi file.

Great! We now have a movie showing our gameplay at the correct framerate and captured from the screen.

But won’t the sound be all wrong?

Yes, it will.

RecordMyDesktop can capture audio but it isn’t useful, since the sound effects are at the correct speed but spaced apart. To get sound, the best you can do is put the sounds in again in and editing program.

We’ve chosen to add sounds manually. It’s boring work but the result is rewarding.

The result

So here we have our recorded gameplay-video, after adding pre and post-images and some compositing in Adobe’s Premiere Pro:

Turns out it was a bit of a hassle to get the gameplay-footage in good quality, weve got a blogpost about the process soon.

From February till the end of March we’ve  been working very hard to finish the game in time for our original assignment. Now, the original plan was to release that version to the Android market.

We finished the project and got graded a 10 (the highest grade ) and were very happy with that, but didn’t have the feeling the game was ready to be released just yet. It had full gameplay but lacked levels, everything was random and geared towards showing off the gameplay. It also didn’t support the new Android-phones with bigger displays, since they didn’t exist yet when we started building the game.

So we decided we wanted some extra features:

• Support new screen resolutions
• Multiple (5+) levels
• Per-level hiscores
• Usertesting-driven improvements

After the project was done we both got busy with other assignments so Barrr got a bit side-tracked (also, after putting a lot of hours into the game, especially in the project’s last two weeks we both had enough of it for a while), which is why the changes took some time to implement.

We’re almost there now, so here are some screenshots!

We’re finishing up on the last changes and features at the moment, hoping to release the game in about 1-2 weeks!

Right from the start we both agreed on the mood: light, fun and sort of ridiculous. We planned on making a game that sought only to entertain the user with addictive gameplay and quirky, enticing graphics. The name would be whimsical, the pirates happy and the setting anachronistic.

With this in mind, I settled on a few choices. First, that the style would be cartoony and simplified. Second, that I would use no black (#000) for line work and thirdly, that backgrounds would flow softer and more painterly than important objects.

The very first item I started working on was our menu, since we had a solid idea of the links provided and it would set a good precedent for the art direction of the levels. After making a few quick sketches, we picked out one that echoed our game best.

Counting from the top, we picked the third design. All others had a range of complications, including being unclear, unattractive or deluding about the game’s content. I then made several more sketches with just that design, paying attention to button placement and size of touch surface.

Eventually, I used the last design without the flag, to be replaced with the logo. The menu progressed as follows.

With the menu finished and art direction clear, the design of the pirates, levels and interaction objects would be the next step.

Understanding the platform

I think google has done a good job explaining Android in the first part of the developers guide. The What is Android? page gives a short overview targeted at developers. On the Application Fundamentals page you can find an overview of the core concepts that make up an Android application. It’s a long page, but I really recommend reading it completely, as every important concept is presented and explained.

First experiments with Android

I’m a pretty visual person when it comes to programming. I can get a feel for a programming language or a project like Android a lot faster when I just go and experiment with it.

At this point I installed the Software Development Kit. My main OS is Ubuntu, and it’s really easy to get the SDK up and running with Android’s recommended editor, Eclipse. Just follow the Installation Instructions.

Although Android is a pretty big project and the “just experiment”-approach won’t let me understand everything, it has been helpful for me to do the first two tutorials from the Developers Guide, the Hello World and the Hello Views tutorials.

The Reference

In those two tutorials you’re also presented with some links to the Reference, which is the API Documentation. In the reference you can look up any package, interface or class and find out what its classes, methods, arguments etc. are, mean and do.

The Reference is a really useful resource for finding out more about a certain class or method. It also helps in understanding what is happening in tutorials or code you find online. When writing code I often find myself browsing the Reference to find useful methods or related classes.

More Developers Guide

After reading a bit and getting your feet wet in actually programming for Android, I think it’s useful to watch a few videos in the Video section of the developers site and read a lot more in the Dev Guide. Getting through the Dev Guide is a lot of reading and takes a bit of concentration, it’s much easier when already having some experience.

I just combined the reading with experimenting, being stuck in the following loop for a while:

1. Read about a subject
2. Write some code that does something with the subject, using something you’ve just read about
3. Goto 1

I can’t say I’ve read the whole Dev Guide, nor that I read it in the order you’re supposed to read it, but I think I’ve read most of it and got quite a bit more insight in Android by just doing that.

Next time

Next time I’ll explain how I began developing games for Android and which references I used.

As explained before, we’re two Dutch students developing a game for the Android OS. This project, dubbed Firedroid for now, will count towards our Minor Credits. So this is no mere hobby project, but something enabling us to get our degree in Multimedia. That said, we’ve got five glorious months to make the most kick-ass game we can imagine with very little previous experience. Be sure, we’ve made games before in Java and Flash, but they’re hard to compare to the scale of the game we plan to crank out this time.

So, what have we got planned?

After brainstorming and conceptualizing for about two weeks, we got our hearts set on a time management game.
Our amazing theme will be pirates, because who doesn’t love bearded, rum-guzzling, cussing sailors.

We’ve chosen to develop for Android OS instead of the populair iPhone for a couple of reasons. Firstly, Google is very supportive of developers. They have an excellent Software Development Kit, a useful emulator and update frequently, not to mention Android is nearly completely open source. Secondly, Android runs on a number of devices. When we first started the project, 18 phones were available with the Google software with more being released this year. This means it’s a growing market, especially due to the release of budget models which will enable the less wealthy amongst us to enjoy a good smartphone. This ties in with getting a phone for us to develop on, which Google offers readily. Lastly, we felt Android needed some love too, concerning games.

So there you have it. Currently, I’m spending my time making a paper prototype to test our initial concept, figuring out object placement on the screen and everything else that ties in with preliminary graphic design, while Roy is absorbing as much programming information as he can muster, as this project shifts him from Flash/PHP/Javascript to the mathematically wonderful world of game programming, OpenGL and all the headaches that come with it.

Be sure to follow our twitter for short and fast updates!