[1GAM-May] Tic Tac Head: Progress Log #2

WARNING: Some technical programming stuff ahead.
1GAM Banner

A quick spoiler before we go on, despite this being the second log, the game has been released and is working. But yes, there will be a third log, read on to find out the reasoning.

Anyway, hello people of Earth! It’s the second progress log for Tic Tac Head, my fifth entry for OneGameAMonth, a community that encourages people to create a game every month. Check out the first log here, or check out the logs for my other entries here.

As I have said in the previous log, Tic Tac Head is an online, multiplayer Tic Tac Toe game for your Android devices. It’s nothing revolutionary or ground breaking, but it’s a good exercise for learning about how to build a multiplayer game. And truth be told, I did learn all the hassles about building a multplayer experience.

So, how did my endeavour go? Did it end well?

The Game

To save you all from reading this wall of text even further, let me just say upfront that the ending is a happy one. Well, sort of 😉

Don’t rush now, let’s do this chronologically. The last time I did say that the game can already be played and the player can win or lose. So I continued from that point and built all the missing pieces like the friend list, multiple games, and even some sort of bot that player can play against. And while I was doing all that, the server app was slowly getting into shape as well.

Keep in mind that while building those features, I didn’t connect the app to the server at all. I simply simulated internet connection by having some game process running in a different thread with 1 second delay. Looking back, that was a really good decision. I managed to build an app that is structured for the internet, so I don’t need to change a lot of stuff later. Or so I thought.

So yeah, I left all the internet stuff to the last day. I spent the first part of that day setting up the connection to Google Cloud Endpoints, and fortunately, once I got it functioning, it just worked beautifully . However, the data I got from the server have a different structure from the ones I used in the app, so we spent the second part of the last day hacking things to make the game works.

In the end, with around 30 minutes to spare, we managed to get a working game where 2 players can play Tic-Tac-Toe back and forth. At that point, I simply uploaded the game and called it a day.

Account picker

The game uses a lot of interesting technologies, which unfortunately wouldn’t be written in this post. But let me highlight just one them, shown above, which is the Account Picker.

As you can see, with the Android Account Picker player can choose a Gmail account (or Hotmail) associated with the phone and use it as the login alias. The original idea behind this is that we don’t want players to create yet another account to play the game. We also don’t want to deal with the hassle of keeping another social network session and token data, so we simply use those emails as the login ID for the players.

The development is not all bright and sunny though, one thing that really annoys me is the amount of loading indicator needed to be displayed. Getting a game needs a loading indicator, waiting for opponent’s move needs an indicator, sending a move needs an indicator, etc etc. Seriously, writing “if (isLoading()) showLoading() else showGame()” all over the place really complicated the codebase, and writing to a messy source code is the total opposite of fun.

The pain of building an internet-connected game doesn’t stop at that unfortunately. There’s also the problem that being connected added various possible cases to the app that I need to anticipate. For example, I had to starting thinking abouse cases when a request failed, or when the device got disconnected, or when the request is finished but the user isn’t viewing the app.

All those cases added further to the complexity of the app, and coupled with the last minute hacking we did, it made the game codebase one hell of a mess.

Messy or not, the game works. See it in action for yourself in the Vine capture below.

So now it’s all done, where’s the game link?

Unfortunately, the game isn’t ready for public consumption yet. Like I said earlier, there are a lot of cases that I have to think about, and I haven’t tested them all. For instance, I don’t think right now (as the time this post is being written) players can receive a challenge from a player who is not stored on their player list. And I’m sure there are other non-functioning cases like this, so I decided to withhold the game until it’s fully functional.

That said, I have put the game somewhere on the internet. If you’re smart and creative enough, you should be able to find it 😉

(apparently someone already found it before I even posted this log 😄)

All that is the reason why I decided to have another progress log for this game. I planned to keep working on this for a bit more since I wanted to ensure the game is fully functional before making it available to more people. That said, right now I’m aiming to clean up and refactor the whose codebase so it will be easier for me to fix stuff.

And since I left out all the technology stack used from this post, I think I’ll include that in the next log. So stay tuned, people!

[1GAM-May] Tic Tac Head: Progress Log #1

Please forgive my l33t Photoshop skillz >.<
1GAM Banner
Uh oh, we’re approaching the end of May and I haven’t written anything about my OneGameAMonth entry. Well, I’m still trying to make the deadline here, so I’ll keep this post short.

Before we go further, a quick introduction is in order. I’m participating in OneGameAMonth, a community that encourages people to create a game each month during this year. It’s May, so right now I’m working my on my fifth entry, and you can check out my games for the previous months right here.

First, let’s get the cat out of the bag. I suck at doing anything related to the internet. I can’t write a good website, all those HTTP POST GET mumbo jumbo confuses me, and I hate JavaScript. Yet, the internet is fundamental to everything these days, and even games with all those leader boards, cloud save, and social things. So I secretly wish I could get better at doing this internet stuff.

Then, around two months ago, a chance came by.

Chat Head

A chance by the name of Chat Head. Chat Head is the new interface for Facebook Messenger featuring a draggable profile image that is floating on top of the phone UI. Me and a friend of mine really liked this new interface, and during our discussion, we came to a realization that this kind of interface is a really good fit for multiplayer games. Imagine being able to easily goes into and out from a turn of Letterpress. Or Words With Friends. Or Poker.

But building Letterpress, Poker, or even Chess is a tad too big for us. We (well, at least I) don’t really have the experience to build a proper multiplayer game. So we start small. We start by building a really simple multiplayer Tic Tac Toe. That way, we would understand the underlying infrastructure of a turn-based multiplayer game which hopefully can be useful for building another multiplayer game.

We decided to postpone that plan a bit so I can use it for my May OneGameAMonth entry. We also decided that I will deal with the client stuff and he will deal with the server stuff. To be honest, I’d rather learn how to do the server codes, but eh, building that floating interface should be an interesting challenge as well. While for my friend, he hopes to be able to learn server development with Python from this project.

And here we are. So how did it go?

Well, it went… badly. Me and my friend got a bit busy this month with some school stuff so we barely wrote any code at all. Fortunately, I managed to sneak in a bit of time to work on the floating head interface (and exploring the deep end of Android app development) while my friend managed to get some Python codes running on Google App Engine.


Right now I don’t have any school work to worry about for around a week, so I managed to go full throttle on this project for the last few days. I’ve been adding more functionality like the game logic and the game interface, and I’m writing this post while in the middle of working on the game friend list. Working on apps is a bit different than working with games since I have to adhere to a lot of the operating system architecture. Fortunately, it’s still fun.

While now the game is sort of working (you can win or lose a game), I’ve been avoiding some of the more difficult issues like managing friend list or even notification. These are the issues that need to be dealt with a great amount of consideration and I don’t really have the time for that. That said, I’m positive that I can do the core functionalities of the client app in the remaining 3 days.

Meanwhile, my friend hit a snag on the server side of things. Apparently his little adventure with Python is too much for him to handle, so now he’s reverting back to Java, his usual weapon of choice. There’s also the fact that he has another school stuff coming up soon, so he’s in a bit of mess right now. With less than 3 days until the end of May, who knows if he could pull it off.

And at that cliffhanger, I’ll end this log. Stay tuned for the next post to see whether our ending is happy or not 😉

A Look Back on 2012: AdMob Edition

Planning to close 2012 by looking back on advertisement in my game, got delayed though 😄

openingDon’t have time for this wall of text? Head to the end of the post for the conclusion.

Anyway, a couple of days ago there’s a discussion about paying tax in one of my Facebook groups. And well, the topic is sort of interesting to me since I have zero idea about tax and stuff (seriously, where do people learn it?). That discussion prompts me to think about the revenue I’ve earned so far from my game. I know I haven’t earned anything worthy of being taxed, but I have never really analyzed how it does. So I think this would be the perfect chance to do it.

A little background is in order. Android platform, unlike iOS, has several places where users can download app for their device. As a developer, of course I put my game across various Android app stores to maximise my reach. One of the app store I used to provide my game is Samsung Apps, which is pre-installed in all (well, most) Samsung mobile devices.

Most of these 3rd-party stores perform okay-ish, nothing really different from Google Play. However, at the end of July, it looks like the game on Samsung Apps got featured or something because it suddenly got hundreds of download each day. Seeing all those downloads made me think that I should try to monetize it while the download count is still high. And so I signed up for AdMob.

To be honest, I never liked having banner ads on games, they ruin the overall aesthetic (exhibit 1). Fullscreen ads or offerwall is much preferred since they occupy a separate screen. However, Samsung Apps doesn’t allow games to link to Google Play (most offerwalls advertise apps that’s on Google Play), so banner ads is the only advertisement option I have.


Here’s an example of an offerwall

At the beginning of August I quickly integrated AdMob and added a banner ad on Project Claw. I chose to put the ad on the result screen since I think that’s the perfect time and place for people to take a look and click it (putting it on the game screen would be a good target for accidental click though =p). After passing the approval process for Samsung Apps, the game with ads is finally available around mid-august.

Well, as of mid-december, it’s been 4 months since I tried to generate revenue from advertising, how does it do?

summaryYep, it has generated less than $14 during those 4 months. For reference, the game has been downloaded over 10,000 times from Samsung Apps during those months as well. To be honest, I was expecting more since I thought 10,000 downloads is quite a lot. It is possible that advertising on games isn’t as good as advertising on non-game apps. After all, unlike games, people use Twitter clients or manga readers almost all the time.

Wait, before we go further, let me give a quick explanation on all those weird terms. Let’s start with something easy, impressions. Impressions is how many times an ad is displayed, while fill rate is the percentage of how often an ad is requested and successfully displayed. Easy right? Let’s move to eCPM. eCPM is effective Cost Per Mille impression, that is your earning for every 1,000 impressions. In human language, it is how much each impression is valued. Last term, CTR stands for Click Through Rate, which shows how often an ad is clicked.

Now we know what those term means, let’s check them out. But before we do that, we need data from other apps so we can make a valid comparison. There isn’t any official data that can be used, so these various posts by anonymous people will have to suffice. For example, based on those reports, we could say that 98.8% fill rate is totally normal.

The first thing that came to mind that could be causing low revenue is low eCPM value, which is only $0.32 in this case. Most of the game downloads came from India and China, so it’s not really surprising to see low eCPM value. After all, it must be cheaper to advertise in those countries compared to advertising in the USA. The data speaks differently though. Apparently $0.32 eCPM value is quite normal for AdMob!

Another interesting point is that the game has a really decent CTR (almost 2%, compared to other people 0.5% CTR) despite only showing the ad on the result screen. May be it’s proof that you don’t need to to put banner ad aggressively to get people to click it. Or… it could be proof that my ad doesn’t get refreshed often enough (4-5 impressions per download seems low) =/

Unfortunately, hard, static data only shows so much. I think it’s time to add time dimension to those numbers.

ChartOkay, so this chart above shows several data about my game on Samsung Apps from August 15th to December 15th. The data depicted are revenue, number of impressions, and eCPM. Note that each data has different unit, so their value shouldn’t be compared, I put it close to each other so it’s easier to compare the shape of one graph to another.

The first striking thing to me is how the revenue graph doesn’t really mirror the impressions graph. After all, it’s only natural to assume that the more usage your app has, the more ad clicks (and revenue) it will get. That doesn’t seem to be the case here. You can see that even though the number of impressions shrunk after September, the ad revenue actually went up. And when the impressions suddenly goes up at the end of October, the ad revenue doesn’t go up as much.

It’s kinda perplexing, but things become clearer once we consider the eCPM graph. As you can see, the eCPM graph has a totally different shape compared to other graphs, because it doesn’t depend on download count or even the progress of time. So when the eCPM has high value, even with the number of impression going down, the revenue managed to go up because each ad has higher value.

You can say that impression is really similar to usage or download count. So, I think it’s safe to say that not all usage/download has the same value. As shown by the graph: the usage in October, despite being much higher than the preceding months, don’t bring as much revenue per download as before. I’m sure things will be different if the high usage number occurs earlier.

Since it seems like eCPM plays so much role in determining advertising revenue, I think it’s worth the time to take a look at it from a different perspective. Enter geography:

Taiwan download data doesn't show up =/

Somehow download count from Taiwan doesn’t show up on Samsung Apps report.

Several things are noticeable from the table. For one, there’s a strong correlation between the number of download in a certain country and the number of ad impressions that originated from that country. Another noticeable thing is how the CTR doesn’t really vary between countries, I suppose there isn’t any culture that encourage people to click on ads or something 😄

Things become interesting once we observe the revenue column. Apparently, almost half of my revenue is generated only from 5 European countries, France, Russia, United Kingdom, Italy, and Germany. Aside from Russia, these countries don’t contribute much to the game’s download number.

You may notice that the countries which generate high revenue have mostly high eCPM values. However, if you sort the countries by the number of impressions, you will notice that these high-impression countries have really low eCPM values. France is probably the only exception here. No wonder I only earned $14 despite having more than 10,000 downloads.

Seems like my initial theory that the low revenue is caused by the low eCPM, which in turn is caused by the user base location, is correct after all.

First thing first, let me remind you that that this whole stuff is done using only AdMob and distributed via Samsung Apps. So apps on Google Play might have a different case than this one. Anyway, in 4 months, Project Claw has gained over 10,000 downloads and has generated $14 from advertising. Apparently eCPM matters a lot when it comes to advertising revenue, and most of the time, eCPM is determined by the user’s country. So apps with users mostly coming from developed countries will have higher eCPM (thus, better revenue) than the one with users coming from developing countries.

That said, even if all 10,000 downloads came from France (the country that generates most revenue), by extrapolation, it would only raise the revenue to $35. Just enough to cover Google Play registration fee.

What’s next?
As I’ve said earlier, I never liked using banner ads, and since those ads haven’t been performing so great, it’s safe to say that I will abandon such method (the latest version doesn’t have enough space for ads anyway). My ideal monetization method would be using In-App Purchase so people can easily unlock items. Unfortunately it isn’t available here in my country, so right now I’m trying out Tapjoy offerwall in place of a real IAP menu. I was hoping a combination of unlockable items, popups, and offerwall could bring in a decent revenue.

And also, a little teaser, I used AppBrain offerwall to generate revenue from my app on Google Play previously, and despite the much lower download count, the revenue it generated isn’t that much different!

Special thanks to @lwastuargo for proofreading!

Project Claw v0.1.8

This is supposed to be posted a couple of months ago, but meh, better late than never =D


So yeah, Project Claw version 0.1.8 has now been out for a while in Google Play and can be downloaded right here! This update is quite quick in the making, it only took less than 10 days for me to work on it. But don’t worry, it still packs quite a lot of content!

Anyway, let’s see what additions does this update bring to Project Claw:

  • A brand new orb, the Mystery Orb!
    (check it out at 400 M or more height)
  • Extra ability for the Red Orb.
    (I found the red orb kinda boring, so hopefully this will spice things up)
  • Game difficulty refinement.
    (the addition of Mystery Orb changes things up a bit)
  • More visual elements.
    (now featuring more clouds!)
  • Added More Apps option.
    (using AppBrain service)
  • Analytics improvement.
    (so I can understand the players better)

As you can see, this update is mostly about adding new contents to the game, both for the gameplay as well as the visual. I felt that the main gameplay mechanism has been quite enjoyable and doesn’t need much polish anymore, so I started to look on what I can do to made the game even more fun, and that is variety. So in the end I tried to improve the variety on the gameplay by adding 2 new orb effect and also variety on the visual by adding more objects in the background. I really hope players will enjoy these new additions.

There’s also a really minor update I released before this version
Version 0.1.6

  • Added some API calls to other services.

So, what’s next?
The next version is almost ready to be unveiled, and it’s a big, big update. For one, I’ve decided to redo the engine for the main gameplay mechanism! You see, the old engine has a lot of limitations to what I can do with the gameplay, for example, having powerups is totally out of the question since the player don’t have the ability to control their positioning. This new engine hopes to remedy that and brings you those power ups to make things more fun.

Stay tuned for the next version of Project Claw!

Difficulty Level: An observation

Lately I’ve been frustrated while trying to tweak the difficulty level of my game, Project Claw. You see, the people whom I tested the game on showed varying degree of responses. Some guys are very good at playing the game that I feel like I need to introduce new challenge very often so they don’t get bored, while some other guys encountered difficulty really early in the game. Without any reliable player level that I can base on, how should I adjust the difficulty?

Fortunately I have set up some analytics in the game so I can actually measure up user’s progress level. And since the game has been released for some time in Google Play, it should have accumulated enough data to accurately reflect user’s behaviour. This data about user’s progress will hopefully shed some light on how I should adjust the difficulty level of Project Claw.

So here’s a little chart based on that progress data.
(Some absolute data have been omitted though)

User progress chart

Some explanations are in order I suppose. This chart shows the percentage of users who has reached a certain height in Project Claw (remember that the game is about going as high as possible). For example, we can see that all (100%) users has reached 0-65 m height while only 99% users managed to get past 65 m (and only 70% reached 150 m, and so on). This chart is made based on the data taken using Flurry Analytics from of a couple hundreds users who play the game in October. While I’m sure the analytics doesn’t record all users, I think the sample size is big enough that any difference with the actual data can safely be ignored.

Well, how could we understand the difficulty of Project Claw from this chart? I think it’s safe to say that the difficulty level of a game is proportional to the amount of player who reached the end of the game. So the harder a game is, the less amount of players who would reach the end of that game and vice versa. What about Project Claw then?

Well, we’ve got some really nice number on the start, 99% of the users managed to reach 65 m, which is pretty understandable, that section was designed to be a safe area with reduced falling speed where users can learn and experiment with the game mechanism. But then we got a sudden drop, only 72% of users managed to reach 150 m, apparently there’s something before that mark which some users found quite challenging.

Another sudden drop is encountered before users reached 400 m since only 38% of users managed to reach that point. This second drop is much more mysterious. The reason for the first drop can be attributed to the falling speed being restored to normal, while the second drop has none of that and only introduced new type of orbs. Of course it is possible that some users have a hard time with these new orbs.

Then we have another interesting point, apparently 80% of the users who reached 400 m also reached 800 m which is the last height level (since beyond that point the falling speed will start to increase). Based on that, I think it’s safe to assume that most users who reached 400 m has got a good grasp on how to play the game. But then again, only 30% of users has managed to get to the endgame, which I suppose is okay for a true endless game (like Temple Run), but it’s a big problem for a level-based game (which I intended Project Claw to be).

Wait, so what does all that say about the difficulty of Project Claw? Well, since the data shows that almost all users manage to pass the first section and only 30% of them reach the endgame, we can say that Project Claw is easy to understand, hard to get the hang of, and hard to master. The “hard to get the hang of” part is the problem here since casual gamers need to quickly be able to do well to be engaged with a game.

Based on all that information, there are several actions that can be done to improve user’s progress in the game (that is, adjusting the difficulty level so more users will be engaged). One of them is to expand the safe area so users would have more time to learn and master the game mechanic. This is supported by the data which shows that users who have understood what to do would progress far into the game.

Another stuff that can be done is to lower the overall difficulty, which can be achieved either by decreasing the maximum falling speed or by decreasing the gravitational acceleration. I don’t really like this option though, since I designed most stuff based on those values. Not to mention that  some movements might feel unreal if they’re slowed down too much.

I don’t know if I would do all of them, I think I will just pick one or two actions and see how it affects the progress level. I think aiming for 85% of users to reach 150 m and 50% of users to reach 400 m is a nice goal =)

Project Claw v0.1.5 is Out!

Ah, finally got the time to announce an update for Project Claw =D


Project Claw version 0.1.5 is now live on Google Play and can be downloaded right here!

This update has been in the works for some times, but I’ve been busy (with various events, one of them is a hackathon =D), so it’s only now I finally got the time to finish this update and release it. Fortunately, it looks like now is the perfect time to release an update, since it’s weekend and it’s right before Google I/O 2012, where there will be a lot of attention to Android. Oh, and isn’t it summer holiday or something right now?

So, what does this update bring to the game?

  • A new type of orb, the black orb.
    (reach 250 M height to check it out)
  • A change to the grapple hook‘s visualization.
    (a lot of people takes some times to fully understand the mechanism of the hook, this change will hopefully make it clearer)
  • Gradually increasing falling speed.
    (there’s a lot of thought behind this one, in another post I suppose)
  • Now the game will be paused when interrupted.
    (a couple of times I died because I received a message while playing)
  • Flurry analytics.
    (I really want to compare it to Google Analytics)
  • And some general improvements!

This was supposed to be in the update, but…

A little trivia, originally I planned to add a little eye candy with this update, a moon. Nothing too fancy, just something to add to an otherwise bland, starry night sky. After a couple of tries I decided to scrap it though, adding a moon means slowing down the background, and slowing down the background makes the game lose a bit of it’s “speedy” feeling, something that I felt important to the game.

As some of you might have known, there have been 2 unannounced previous updates to the game, they are:
Version 0.1.2

  • Added better support for various resolutions.
  • Added more tracking with Google Analytics.
  • Added a “what’s new” dialog.
  • Fixed some bugs when falling.

Version 0.1.3

  • Added a highscore effect.
  • Fixed an issues with Google Analytics.
  • Fixed an issue with limited number of orbs.
    (seriously, this problem only appears if you have reached like 1500 m height, and I thought no one would play the game that much to ever reach it)

So, what’s next?
For the next update I was thinking of adding another type of orb, since the purpose of releasing this prototype is to experiment with various gameplay element. Another thing I’d like to achieve is to get user to keep coming back to the game instead of playing it in just one go, so may be I’ll add some sort of daily mission or just a simple leaderboard, though they may not get included in the next update, but we’ll see.

Project Claw is Released!


And without further ado, I announced that Project Claw v0.1 has been released and is now live on Google Play!

So, what is Project Claw? Well, here’s a description from Google Play

In Project Claw, you possess the ability to grapple to floating magic orbs and catapult yourself into the air. Fly high into the night sky by using these magical orbs, each with their own power and characteristic you have to master.

Have fun in this endless arcade game and try to fly as high as possible!

Screenshot 1  Screenshot 2

Project Claw is your usual endless arcade game where you need to fly as high as possible and try getting highscores. What’s different is the mechanism to get higher, in this game you have to touch these floating orbs to attach your character and release them to make him launches upward. You’re constantly moving up and down, so you need to have good reflexes to tap those orbs accurately. To prevent you from getting bored, there are several types of orb that you can use, each having their own special effect when used.

Here’s a video showing the detailed mechanism of the game:

Anyway, keen-eyed readers might have noticed that it’s Project Claw v0.1. Yep, it’s still version 0.1, in fact, it’s still pretty much a prototype, hence the version number. It really is something I put together over the week, most of the graphics is drawn over a single night, and the coding is one big mess with no architecture.

So, why did I release it? Funnily, it all begun when I was playing Mega Jump in the bathroom. I was frustrated with the inaccuracy of accelerometer-based control, and tried to think of how I would tackle the control for a similar game. A friend of mine tried to implement a left-and-right-side-touch scheme to control the character in his game, but while it’s accurate and simple, I felt that it’s not fun enough. Then an idea dawned on me: a control scheme based on grappling hook where the character moves upward by grabbing various objects using it.

I really liked the idea since it seems fun and it has a lot of possible additional mechanism to be incorporated. However, at that point, I had 2 other Android projects I was working on, and I didn’t like the idea of tackling  more than 2 projects at a time, so I can’t really work on that idea. So I just write down the idea on a piece post-it note and stick it to the wall so I didn’t forget. Several moments later I had an idea that I should just create a prototype to test the concept and release it as it is. Since I can easily measure the market response, get a lot of feedbacks, and learn first-hand about releasing an application that way, I decided to go for it

Post-it Notes

The post-it notes grew along the project 😄

So, a week later, after several iterations of testing and development, it was kinda done. I simply slapped a pause and gameover menu over the original gameplay and it was ready. I’m glad that this time the gameplay I imagined is truly fun, most of the testers easily get absorbed into playing the game and they didn’t really have a problem with retrying the game when they died.

Anyway, I originally planned to release the game by Monday, but it got delayed and I ended up releasing it on Wednesday (imagine, even a prototype can get delayed). One big reason for that delay is that I wanted to have a gameplay video so I could show it to people that doesn’t have an Android phone. Since my game wass too fast for emulator (yes, even for that new gpu-enabled emulator), I had to record a video of the game running on a real device. But controlling a fast-paced game in one hand and holding a phone for recording in another hand is really difficult, I ended up using some special equipments to stabilize the camera.

Behold my professional video recording equipment:

Video equipment

Yes, it’s a Galaxy Nexus on top of… some stuff

Anyway, since the game is now available, go download and play it!
Don’t forget to rate it on Google Play and hit the in-game feedback button =D

Get it on Google Play