Check out this screenshot:
So we’re number one in the Top New Paid, Games/Casual section in Google Play in Canada. But still. Yay!
To promote the game I’ve been working on a short gameplay trailer. I tried to capture the essence of the game without being bogged down with specifics, and make it happy and attractive.
I used Fraps to capture the in-game footage, and assembled it all together using Windows Movie Maker. It’s a nice compromise because I never learned Adobe After Effects, and Movie Maker is simple enough to use.
The music is Alchemists Tower, from Kevin MacLeod, downloaded from here: http://incompetech.com/music/royalty-free/index.html?isrc=USUAN1100632
You’re a Bank shipped on Android on Thursday night (the iOS version is still under review). On Friday morning I was getting reports that the game wasn’t working on certain phones: people were seeing just a black screen, and no game.
I instantly went into a panic. How could this be? I had tested the game in several devices, and it was working perfectly well, without a hitch. Besides, I was using Moai, which is a stable engine with several games shipped and working without issue.
The first thing I did was to locate a phone were I could work on the issue. My initial report was that the problem was occurring in a Galaxy Nexus, so I borrowed one to test. I was immediately able to reproduce it. To my surprise, uninstalling the game and reinstalling the APK seemed to fix the problem. It had something to do with actually shipping the game on Google Play. Great.
As a curiosity, I discovered right after publishing the game that you can’t buy from yourself on Google Play. I had to actually use a different account to buy the game, and was then able to observe the problem both on my phone (a Nexus S) and my tablet (a Galaxy Tab 10.1). Then I started putting some serious time into debugging it.
The submission process for Google Play is very straightforward. You upload a new APK with an updated version, hit Publish and you’re done. It takes about 2 hours for the update to go through the process that ends with it showing up in the market. So that was my turnaround time for trying things.
I added a bunch of logs to figure out what the problem was, and submitted an update. At the same time, I compiled Moai from source so I could add more logs into the engine itself; prior to this I had been using the stock 1.3 version, as I didn’t need to make any changes.
Little by little the picture got a little clearer. Moai was unable to run the file main.lua, the entry point of the game. Also, I found out about some changes that Jelly Bean introduced into how Google Play handled paid app files (more details than you care for here). It clicked. The game was working fine on previous versions of Android, like Ice Cream Sandwich, but failing on Jelly Bean.
Another submission and some more logs revealed that the problem was that Moai couldn’t find the file main.lua. Something that Google Play was doing to the app made Moai unable to open my files.
A deep dive into the Moai source code exposed how their file handling works. Android packages (APK files) are actually simple zip files. When you download an app, the system doesn’t bother to decompress it; instead, it stores the APK as is, and decompresses the files on the fly, as needed. Moai uses this fact to read directly from the APK using zlib, which is a nice, efficient way of doing it, as you’re talking directly to the underlying operating system, eliminating the overhead of going through the Java layer.
This is still possible after the Jelly Bean update, but there is a problem. Instead of a single file containing the APK, Google Play will now create two files. The first one, called “res.zip”, contains just the resources for the app (everything under the “res” folder). The second one, called “pkg.apk” is the actual APK.
Moai was successfully mounting the first file, but all of my scripts, images and sounds were in the “assets” folder, as they should, according to the Android pipeline.
The solution, it turns out, is to tell Moai to mount the other file. This is the change to the file MoaiActivity.java (highlighted):
ApplicationInfo myApp = getPackageManager ().getApplicationInfo ( getPackageName (), 0 );
Moai.mount ( "bundle", myApp.sourceDir );
Moai.setWorkingDirectory ( "bundle/assets/@WORKING_DIR@" );
I’m in contact with the Moai developers to get this fix into the official repository.
For reference, this is the documentation for the “publicSourceDir” variable, in the ApplicationInfo class, that explains what the difference is with “sourceDir”. This only applies to forward-locked apps (a nice tip that I wish I’d known is that you can test forward-locked apps with adb by using the -l option )
And that’s it. A small change, with a big impact. A potential concern is that, moving forward the Moai implementation is still non-standard, in that it bypasses the official API to access file resources on Android, so the potential is there for it to break again in the future. But for now, my game looks like this again in Jelly Bean devices:
I just pushed the game to Google Play, Apple’s App Store and Amazon’s App Store.
Google Play has been the first to make it available: It’s here: https://play.google.com/store/apps/details?id=com.sgarces.bank
Much to say about the project, but for now, a screenshot. Go get it if you have an Android phone!
In the games industry, there is no question that Perforce is king. Most studios use it, it’s fast and it works well. I’m pretty comfortable with Perforce, so it was tempting to install a server, especially now that they offer it for free for up to 20 users (it used to be just 2). However I wanted to try something new.
One thing with Perforce is that before you attempt to modify a file, you need to let the server know (files are marked as read-only as a way to help manage this). If you add a new file or delete an old one, you need to let the server know. This is usually fine and you can work with it by integrating Perforce in your tools, like your source code editor. It’s very explicit.
Git works the other way around. You do whatever work you need to do, and when you’re ready to commit it to the server, git will compare your local directory with the repository and automatically detect all the changes you made. This, at least for relatively small projects, is not as slow as it seems. One big advantage is that it’s now possible to work while completely disconnected from the server; you only need a connection when you’re trying to commit. And technically, not even then, as git keeps a local repository, and only syncs it with the global server when you tell it to, so you can make several local commits and only sync to the server after everything works the way you want it to.
The main sticking point with git was finding a visual environment. I would probably get eventually used to the command-line interface but, when all is said and done, I prefer committing my changes with one click. The search turned out a surprising option. Github is not only a popular online git repository, it also provides a polished client. Albeit a bit simple, the interface is clean, and it integrates with the online repository, which makes keeping a backup copy of your files really straightforward.
A nice side effect of going with Github is that it came complete with an issues database. That’s an invaluable tool to keep track of what needs to be done and beats the heck out of a bunch of .txt files or, even worse, a collection of scribbled post-it notes. I’ve used several of these over the years, including Devtrack, Mantis, JIRA, Trac and even Trello. I have a feeling that Github might be a bit too basic for real life work with a moderate team size, but it was just fine for my needs.
The final conclusion, after using it for a couple of months, is that I have to admit I’m only moderately happy with it.
When it works, it works seamlessly. I did run into a recurring problem for a while however, and it was the scariest thing. I would be ready to commit, and the Github tool would tell me that my local repository was corrupt and I had to use the command-line interface to try to fix it. It turns out that you can go down a pretty deep rabbit hole with git, when you run into problems. The internet and patience are your friends and, when everything else fails, you can just clone the online repository and replace your local one (I had to resort to that once or twice).
I couldn’t fully figure out the cause of my woes, but I know it was due to the way I was working between my Windows PC and my MacBook. At first I thought it would be easiest to simply share from my PC the folder I was using to work, and mount it in the Mac. In this way, I could edit files on the PC, where I’m more comfortable, and compile and test the iOS build in the Mac. This is when Github started running into issues. The solution turned out to be like the old joke: if git breaks when I share a folder, I won’t do that. Instead, I installed the Github client in the MacBook and cloned the repository. I still get to share files, although not as easily, and it seems like the issues have gone away.
Finally, a teaser. I added two repositories to Github. One for my project, the other for the throw away prototype I wrote in C# and WPF to test the concept. This one is public, so go ahead and grab it here. You’ll need to compile it, but you can use Visual Studio 2010 Express for that. Enjoy!
I’m working on expanding a personal prototype into a game that can be played on current mobile devices, including iOS and Android.
I decided to try my hand with Moai, even though their focus on Lua goes a bit against my background in C++. At the end of the day though, I wanted something I could get started with right away.