Google IO for game developers

These are the events that I have selected to watch live in Google developer's conference 2013 as an Android game developer.

Day 1

• What's New in Android Developer Tools
• New Developments in Mobile Gaming
• Practical Android Games Development
• Mobile Multiplayer Made Manageable
• Level Up Your Android Game

Day 2

• What's New in Google Play Services
• Android Graphics Performance
• From Nothing to Nirvana in Minutes: Cloud Backend for Your Android Application
• Level Up Your Android Game

Day 3

• What’s new for Developers in Google Play
• Making Money on Google Play

There are a lot of interesting things, but our time is limited. I hope I could be able to watch others further.

Google Play inapp testing procedure should be improved

I am trying to incorporate Google Play inapp v3 to my most popular game. In a first version, I just one to add an inapp item so the ads could be disabled, thus I can remove the pay version of my app and have only one unificated.

The inapp documentation from Google is good enough for making most of the basic things, although the procedure is kind of complicated if you want to be picky with security, but it is something natural.

What I really hate and I think they should improve, is the testing process. There are two ways of testing: with static responses, or using your own products identifiers. The static responses just uses a series of reserved product ids that lets you force several different responses from Google Play app so you can check that all of them are managed as expected.

The problem start when you want to test things using your own products identifiers, i.e., when you want to do real testing.

You will need a testing account because you cannot make actual inapp purchases of your own products with your actual developer account. So if you do not have already one, you should create a new gmail account for these things. This is not a major problem: creating a Gmail account is free, and easy. The real problem is that, as far as you cannot test inapp from an emulator, you need to use an actual device and set your testing account as the primary account of such device, what implies a factory reset of the used device.

So you will surely need a dedicated device for testing inapp, which is not a major problem for a company with a reasonable budget, but sure it is a problem for many indie developers. Not to talk about testing it in several different devices...

You will need to upload your apk as a draft to Google Play, and you will only be able to use inapp with that same apk installed on your testing(s) device(s). That means that for every change you want to do during testing, you will need to export a new signed apk and upload it to Google Play.

I think Google Play engineers could improve this testing process a lot, helping a lot of independent developers to incorporate Google Play inapp to their apps without spending a lot of time in testing administrative tasks, and without the necessity of a dedicated device. And I hope they will do it...

Microsoft bursts the hypocrisymeter

According to Reuters, Microsoft and Nokia (sorry for being redundant) has demanded Google on the European Commission for antitrust reasons:

Microsoft, Nokia demand EU action over Google's Android

I had the intention to write something criticizing Microsoft, but I haven't words for this felony, and also I think they disqualified themselves enough with their acts. I won't argue about the absurdness of their demand against Android neither, it is obvious for any developer able to see the difference between proprietary and free software. 

What I want to do is to look at the bright side of life this maneuver: it puts on evidence how desperate is Microsoft. And these are good news.

Now, STFU and keep jumping!

Developers gagged at Google Play

Can you imagine a shop in which the shop assistants were gagged so they could not talk with customers, and neither argue about customers complaints nor answer their questions about products?

Sounds great, isn't it? So stop looking for, that shop is right here!

http://play.google.com/

Even better: a few privileged developers has been blessed with the power of answering their users, so some users that had talked with these, tend to thought that if any developer does not answer their questions is because he has no interests on doing it, when it is actually because Google Play won't let the developer submit an answer.

This limitation has been here for too much time and it is plain stupid.

And btw, it is one of the few advantages Amazon Appstore has over Google Play.

Update April, 18: I am already able to answering user's reviews. It seems they are rolling this functionality faster. Thanks to Ellie Powers for getting involved.

Dragonplay or Daiwontpay?

UPDATE (April, 5th): 
A few hours after publishing this blog entry, Dragonplay contacted me asking for this post removal, and with the promise that he will actually pay. I have finally received the payment in my account today.

If you have been in Android for a while, you probably have listen about a company called Dragonplay. They have had a quite successful Texas Hold'em game on Google Play, and I know about them because I myself used to play it.

This post is about why you should NOT make deals with Dragonplay, if you are an indie developer with the very reasonable expectation that they will actually pay you for your work.

I contacted them through Chartboost on November of past year, 2012. I had a conversation with a guy called R.G. that presented "Head of Mobile Marketing at Dragonplay". We both agreed a direct deal so I promote their poker app within mine, and they will pay me a fee for each install, with a total budget limit of $3000. So we start a campaign on November, 20th.

The first problem was that he set the "Campaign End" date in Chartboost to November, 31st. I have warned him it was unlikely we could reach $3000 in delivered installs for that time, so as soon as the campaign stopped, I sent him another email explaining the problem again. He didn't answered me, but instead silently moved the "Campaign End" date to December, 31.

Unluckily, by the end of December we reached just about $400 and campaign stopped again due the end date they set.

This could be explained because the campaign target was very restricted. Among other things, it was focused on USA, and my app is most downloaded and installed in other countries, like Spain and Italy. But whatever the reason is, the point is that we have a deal that did not included an end date, but a budget limit of $3000, and it wasn't reached yet.

I tried to contact him from that date without success, sending him several emails, also through their webpage contact form, and I have even contact him publicly in Twitter. Well, not only he was active in his twitter account before I post that, but also has been very active after, but didn't answered me no way. So for me it is pretty clear that he was just ignoring me on purpose.

So, given the impossibility of contacting him, and that Dragonplay didn't neither answer me although I contacted them through their website contact form, and that they implicitly broke our agreement by stopping the campaign before reaching the budget, I decided to archive the campaign by the end of January.

Unexpectedly, I was contacted by another guy called D.A. the 27th of January who told me that he was taking care of R.G.'s position at Dragonplay, and he wants to arrange a meeting for talk about some dealing. I told him the situation, and that before making any other deal they should pay me at least the ~$400 they owe me. He agree with that, so we meet on Skype a few days later and talk about such things, and also I sent him the invoice for the installs already done. I was very confident after that meeting that they will finally being paying what they owed me. Wrong.

We are already on April, 1st, and I have no seen any single cent from Dragonplay. I have contacted D.A. several times since our meeting, some of them he simply ignored my emails, and each time they have answered me, their justifications for the payment delay are worse than before: He has asked me to resubmit the invoice at least three times, he has asked me information that either was already sent, or was even included in the invoice. The very last time I contacted him, about two weeks ago, he asked me who I were and when I worked with them... giving that answer I told him that I cannot believe they asked me that at this point, and that I was starting to be tired of such situation, and he answer me that if I was tired I should have a nap.

After that, I tried to contact their CEO through Google+ and email, but I didn't get an answer at all.

I have already lost all hope of being payed by these defaulters, but at least I think I could share my own experience so others can learn from it and take care.

Related: Be careful with Chartboost direct deals

Rollback your app on Google Play

As an Android developer you may find sometimes in the situation that you have released a new version of your app that seems to work fine on your devices, but once published you started to get crash reports from may users.

The fastest workaround for this problem should be to change your published apk by the previous one, so while you study the issue and give it an actual solution, no more users experience such problem.

But this is not possible on Google Play: once you have published a new version of your app apk file, you cannot disable it and enable an older one.

So, you need to create a new apk, and thus you should increase its version number, since you cannot publish two apk packages for your app with the same version number.

E.g., if you have for example a version 50 that's working ok, then a 51 that's starting to fail, you should publish again the version 50 but it should be numbered as 52.

Enough? If your app doesn't changed data format between 50 and 51, it may be, otherwise you should take care that either, version 52 is able to deal with data as in 51 or your database is downgraded again to the same version it was on 50. In most of cases this last method will be safer.

For example, if you use a SQLite database version 1.0 on 50, and upgraded it in 51 to version 2.0, then you should write the helper functions for a DB "downgrade" on the 52 so database is transformed again from 2.0 to 1.0. You can use the OnDowngrade function on SQLiteOpenHelper for this purpose.

Additionally, if you have data files which format has changed from 50 to 51, you should also take care of making the needed changes to leave them as they were on 50 in the 51 to 52 "upgrade".

As you see a rollback could be actually complex, so my advice is:

a) Minimize the chances by testing your code a lot in several different devices and/or emulators before publishing a new apk.

b) Release a new apk only when you are reasonably sure that, in case of disaster, you will have time to deal with a big issue that could require a rollback. I.e., don't release a new version the day before go on vacation.

A succesful GIT model

I have used several control version systems in the past, including the infamous Visual Source Safe. I was using CVS many years, but when I found Subversion I soon changed.

But you know, in this programming world you have to renew yourself pretty often, so several weeks ago I started to think about moving to a distributed control version system. Finally I have chosen GIT over Mercurial, mainly -but not only- because GIT seems to be more popular.

It took me a bit to move all my projects from Subversion to GIT, because my workflow wasn't very standard. E.g. I have been creating branches for project's forks. It used to look like a good idea first, because it keeps together all the forks of a project within the same folder, and also because it makes easier to merge changes that affects all the forks.

But finally it means to have lots of branches within the same project, what makes it too intricate: you know, you may have a standard branch, then a xmasspecial branch, but for those you may need another branches, e.g. devel-standard, devel-xmassspecial... not to talk about tagging. 

So I am right now in the way of creating one different project -and thus git repository- for each fork. And thus, as a newbie to GIT, I appreciate to learn from others experience, and after googling a bit I have found this branch scheme and workflow to look really interesting, so I want to use the same for my projects:

http://nvie.com/posts/a-successful-git-branching-model/

Some have argue that this model could introduce some overhead, but I think it is worth for the advantages.