So many Android devices to cater to...

In follow up to my earlier post about being envious of software houses of yesteryear, I have to admit that in a sense, they had it easier.

When they made their games and products, they had a single target system with known specs and limitations.  Code that relied on *timing* of events and things like this can be planned for meticulously.  Developers also knew 100% ahead of time what features a system did or did not have.  Yet, they also dealt with 8-bit / 16-bit processors, no FPU, no advanced graphics pipeline, and all sorts of "limitations", and they still cranked out great products after great products all without needing all these patches and what not.

Well, fast forward a bunch of years, and here we're in the age of the smartphone.  In some regards, we have it easy - a powerful CPU (relatively speaking), an amazing graphics processor, and sometimes a FPU.  Wait, sometimes?!  Yes, that's right, if you're a developer for the Android platform, you can't be guaranteed to have a floating point unit.  You also have no guarantee of having any given amount of RAM, disk space, or really much of anything.  Sure, you can *use* float data types, but on devices with no dedicated float processor, it is software emulated!!! Talk about a massive performance hit if you want to do updates and renders at any sane framerate!

Our earlier game, Bubble Zing, ran amazingly awesome on newer Android phones, but on older phones, it ran terribly.  With the 1.0.3 release of the game last month, we thought all major compatibility issues were resolved; well, that was only partially correct.  The major bugs seemingly were ironed out, and the core game "worked", but with no guarantee of how well it would work - sometimes outright unplayable on some devices!

So, we delve further in to the "why is this running like terrible on x,y,z,q,f devices, but great on others".  Well, this is where the things Android does is both great and bad at the same time.  We coded 1.0.3 in 100% Java as this was seemingly the correct way to make any app on Android devices.  In theory, it sounded good since Java apps are suppose to work 100% on devices with a compatible JVM (ie, all Android devices) - clearly something we wanted, and it is fairly easy to crank a Java program much faster than an equivalent C/C++ program, so it sounded like a great idea at the time.

Our test system was a Droid RAZR with Android 2.3.6.  Our initial testing was running well, FPS was over 40 and everything seemed great.  The emulator running an AVD 1.5 seemed sluggish but that could be written off as being an emulator and running not on the most powerful host computer.

Things got really confusing and exciting when we tested 1.0.1 and 1.0.2 on a Samsung Galaxy tablet -- that's when all hell broke loose.  Everything that should have been working in theory wasn't.  On top of that, the frame rate was a dismal 10 to 15!  What the flying expletive!  How can a program go from 40+ FPS to 10!  It wasn't an issue with the version of the Android OS, it must have been something device specific.

I ran a traceview to track what was eating all the processing time and it came down to rendering a full screen background PNG file.  On the phone, this wasn't such a big deal, but on the tablet, it was eating almost 60% of all CPU time!

We're sitting here with a complete Java game that worked ok on an emulator and great on our target test phone, yet are dumbfounded with why the same exact Java code on the tablet ran so terribly.

A lot of trial and error later we figured that to get things working faster and better, the only way was to ditch Java and start programming on a closer-to-the-hardware level as we could to squeeze out a lot more performance and manage memory more effectively.  Java made it very frustrating with garbage collecting at some fairly inconvenient times and this compounded other issues making the game run very badly at certain instances.  It was time to bring on the NDK.

Frustration is what is in store for Android developers.  It can be done, but good apps will need a very persistent set of people to make these products and make them well.

Oh, and I'm still in awe of game programmers from decades ago on consoles, but at the same time, I'm jealous of their "single architecture" deployment platform as that probably simplified a lot of these problems thousands fold.  I suppose this is another reason Apple is winning the smartphone wars with developers as it is "easier" to make apps on iOS with very heavily controlled hardware features by Apple.

Awe at software development houses of yesteryear

After making another small game, I can't help but be in total stupor over how... easy software houses have it today.  I mean, seriously, back in the day when I was playing things like Nintendo way more often than I should have been, I never even thought about how much time was invested in to making all those games I played.

Back then, it's not like game dev houses could just send out a patch to fix things over the Internet.  When products were shipped, they were shipped for real!  Imagine, this had to be the final product, no going back; we're about to manufacture millions of cartridges and customers will get their hands on all our hard work, period, no going back.  Dev houses had to be pretty damn sure that what they were packaging up was 99.99% perfect.

Ok, a company probably could have done a product recall if the game was horrendously broken, but honestly, we just "shipped" Bubble Zing yesterday, and I already found 2 or 3 small bugs that should be fixed!  Talk about maddening for the devs of yesteryear!  Now granted, we made that game in 3 weeks with a really small team, but still... it is mind boggling to know that these guys did it, and did it well is stupendous... well, for the most part... games like Action 52 did exist, and that was... well... a broken down mess incurring the wrath of gamers lucky enough to play it.

If you're unsure about Action 52, check out James Rolfe's review of it on cinemassacre, it is pretty funny.  James, being the "angry video game nerd", can be a tad vulgar (just a little), so if bad words offend you, you might want to stay away from his review.

On a side note, I guess this would help explain why no version numbers were prevalent in old games, no such thing was important because what you got was it!  In rare cases, a second or third production run was accomplished and it was during this time a dev house could slip in a revision copy of the game, fixing a couple things, but still, we almost never saw any indication of what version number our copies were running.

So yea, one of our products just shipped and I'm already getting a laundry list of things to put in to a patch within the first day of release!