Social gaming in Jewels 2?

In my (hideously lengthy, apologies) last post, I briefly mentioned about the social integration options for Jewels 2. For this one, I'd like to you — dear readers (if any! :P) — to chime in, as to what would you like to see for the social gaming options in Jewels 2. This means score sharing, leaderboards, possibly achievements (should I think of any worth adding), etc. (Side note: the game will have a local high score tables in any case.)

First of all: does the game actually need to have a social component? As I was thinking about the possible options, I started leaning towards including only the basics: score sharing and nothing else. No leaderboards (fact is: they are bound to get hacked sooner than later). The player would be able to share their score to, say, Facebook and Twitter, if they wanted to. What do you think, as players? Would you miss the online leaderboards (even if they're about to be filled with fake scores)? Let me know in comments.

Alright, for discussion's sake, let's assume the majority of you would prefer to have online leaderboards. Never mind the fake scores problem. As I see it, I have three options for Jewels 2:

  1. Use the built-in (1st party) gaming integration for each target platform. For example Game Center on Apple devices.
  2. Use a cross-platform social gaming component (3rd party), that works on majority of the target devices. For example Scoreloop.
  3. Don't use anything (i.e. just the basic score sharing as outlined above)

Options #1 and #3 are currently my favorites. Using built-in platform features would equal to less problems than with 3rd party options. This would be ideal, right? We have Game Center, we have Game Circle for Amazon Kindle devices, we have Scoreloop for BlackBerry devices… Notice anything missing? Google! Whoah! What the hell, why is there not a built-in gaming component on Android? I don't know. Hopefully Google will announce something next year; it would be great to have a built-in one (as long as it's optional and not intrusive).

Android users, what do you think if Jewels 2 (for Android) didn't have online leaderboards, but the version on all the other platforms did? Naturally I would support Google's own solution should it emerge.

As for option #2: I'd really rather not add 3rd party components unless I have to, but assuming you players would want to have cross-platform leaderboards, there would be no other option but integrate a 3rd party service. What would it be? Scoreloop? OpenFeint is no more. What about HeyZap? Any ideas?

Option #3 I already explained at the beginning of this post. This would be the most pain free solution from developers point of view, but obviously if the players want something, I do my best to provide. Hence this post. :)

Oh, almost forgot the achievements! Anybody want those?

Feel free to.., no, actually I encourage you to comment if you have something to say regarding this topic! I'm very interested in hearing from you, otherwise I have to decide it myself and probably get buried in complaints… ;)


The tech talk: Jewels edition

As promised in my last post: let's dive in to find out what makes Jewels 2 tick (up to 60 times per second ;)). To better understand where we are coming from, here is a "brief" recap on how Jewels (the original) came to be, and frankly — why it sucks on technical level:

History of original Jewels

Back in late 2007 (or was it 2006? Not even sure any more!) I decided to try C# and XNA programming, just for fun. I needed something simple to try, and I didn't want to do Asteroids yet again (I've done at least three versions, the best of which is Ultimate Steroids, from 2001), so I picked a match-three gem swapping game. After a month or so Jewels was released as an alpha version (I finished it about 5-6 months later). That was for the XNA platform, PC only.

Alright, fast forward to 2009. I wanted to try Android programming and got myself a brand new HTC Hero. After a few weeks of hacking I had ported the XNA game to Java and Android 2D Canvas APIs (in retrospect, should have used OpenGL ES from the get go). The game was released to Android Market (nowadays known as the Google Play Store) and became a surprise hit.

I kept fiddling with the game, adding new things, fixing bugs, but there was no denying it had become a bit of a mess, code-wise. The thing was never designed to work in such an environment where the game could be suspended at any time and later resumed. Or be killed. Also, when I was working on the game Cupcake (Android 1.5) was the norm and I had of course not prepared to support resolutions other than 320×480 (remember it was a practise project), that came with Donut (Android 1.6). That has haunted me all these years: the support for various resolutions and aspect rations in Jewels was — and still is — horrible! And yes, I have done it better for the sequel. ;)

To further explain why the Android-Jewels is so lame: when you port existing code base from platform A to (very different) platform B, there is great potential for awakening some serious bugs and problems. This probably happened with Jewels: somewhat hacky XNA written-for-practise code, hastily converted to shady Java code.. Let's just say it would not necessarily yield the most stablest of code bases to build upon. :P

Personally I had tested the game on several devices without much problems (excluding obvious bugs I have fixed), yet there is loads of people with these same (as well as different) devices having all kinds of problems, crashes (force closes as they're called in Android), freezes and what not. I do take the blame for these problems, the code being the mess it is, and me having to learn all these mobile programming things/quirks that I have not encountered when coding for the PC. It's been a huge learning process for me, but there is light at the end of this tunnel: all the hair pulling has forced me to write more robust systems for the sequel. :)

* * *

Onwards to the sequel!

Now that we've "briefly" covered the murky origins of Jewels, we can talk about what I did for Jewels 2, to avoid many of the problems listed above.

Somebody may wonder: what about iJewels (the iOS-version, that is)? Wasn't that rewritten in C++ and much better than the Android-version? Yes, it was rewritten and used OpenGL ES as the original should have used as well. The game was much better performer, and quite stable, but the actual game play logic code is still the same (although ported from Java). For Jewels 2 99% of the code is new.

For the sequel, I had some (technical) design goals:

  1. The game should work across variety of resolutions and aspect ratios.
  2. The game should work across variety of devices: phones, tablets, budget devices, high-end flagship devices.
  3. The game should work across different operating systems with least amount of effort: Android, iOS, QNX (Blackberry Playbook), …
  4. The number of 3rd party components kept as minimal as possible
  5. The game should start up as quickly as possible
  6. Particle effects. :D Gotta have particles!
  7. The game should be robust and stable, and preferably not crash too often, losing player progress. I've reduced repeating memory allocations and used pools, which help avoid trashing the heap as much.
  8. Probably more goals that escape my mind at the moment. (I hadn't written these down before.)

Let's open up some of those points.

Number 1. Resolution independence. This is must for any game, and something the original clearly lacked. I've spent quite a bit of time making sure the game scales up properly from 240×320 to 1536×2048, for example. I had to give up being pixel perfect (like iJewels is on Retina-display), though, due to long list of resolutions in use in today's devices. It is not perfect by any means: I don't really support landscape mode, since the game just works and looks better in portrait, but I do have some compatibility code in place to have it run letter-boxed on landscape (tablet) devices. This is mainly for things like keyboard docked Android-tablets.

Number 2. Device compatibility. Partly covered in point #1, but I have also tried to keep the code fast enough to run on lower end devices as well as higher specced devices. I test the game regularly across 15+ devices and it just works on all of them. For example the game runs (and is playable, >30 fps) on Samsung Galaxy Pocket and HTC Explorer (about ~100 EUR devices), all the way up to Galaxy S3, HTC One X and 3rd gen. iPad! The only requirement is support for OpenGL ES 2.0, which rules out some older devices (including iPhone 3G, and my old HTC Hero), but even most of the budget devices support GLES 2 these days. (I could probably work in support for GLES 1.1, but currently I'm not doing it since it is lots of extra work and well, it's 2012 after all.. :P)

Number 3. Supported operating systems. Instead of having separate and different looking versions for different platforms, I wanted to have a common code base with as little platform-specific code as possible. For the base I chose to use BatteryTech (v1.1), which helped getting the Android and iOS projects up quickly. I actually ended up not using much from BT but the platform specific game loops (with modifications), (some of) the audio code, asset loading for iOS (for Android I rewrote the asset loading in native code to avoid JNI usage) and some utils, like a hash table implementation (again with some modifications).

So currently I have Android and iOS versions working nicely, and these are the main platforms I am going to release for, when the time comes. I'm hoping to integrate the Blackberry Playbook OS support from the next BT so I could release for the Playbook as well.

What about Windows Phone? Well, WP7.x is out of the question as it will not support native code (C++). WP8 is an option, but it is not a trivial port since I'd need to rewrite the rendering to utilise Direct3D instead of OpenGL ES. Not a show stopper though. Should the good people at Microsoft, Nokia or HTC be reading: I'd love to have a WP8 device for testing (say, a Lumia 920 or HTC 8X) — I would definitely want to have Jewels 2 for Windows Phone as well! :)

Number 4. 3rd party components. I've had a fair amount of problems with various 3rd party libraries: ad libraries, social components, etc. So I will try to integrate as little 3rd party stuff as possible. As for ads: I plan on releasing a paid version (or an in-app purchase) to get rid of the ads, as I know many people don't like them and would rather pay for the game.

For social component (i.e. online leaderboards, score sharing, perhaps achievements), I'm still unsure what to do. At the moment I'm planning to use only the platforms own service: that would be Game Center for iOS, Game Circle for Amazon Kindle, Scoreloop for Playbook, etc. There is one huge problem though: unfortunately Google doesn't have any game services to offer as of this moment, which is quite peculiar if you ask me. I feel that tightly integrated gaming service will only do good for the platform, as long as it's optional and not intrusive. I have my hopes up for Google to unveil something eventually, just not sure if I get the game out before that! Feel free to comment: should I use platform specific services (will lead to better UX and more stability IMHO), or should I utilise Scoreloop or Gree or something else that is common across platforms?

Number 5. Quick start up. With this kind of casual games I feel it's important to get the player quick into the actual game play (something that certainly is not the case with original Jewels), so I have tried to make the game start up faster. I implemented a multi-threaded resource loading system that offloads texture and sound loading to another CPU core, added some custom texture formats that load faster etc. Granted, the game is not yet done (not all of the resources are there yet), but so far the start up is quite fast even on lower end devices.

Number 6. Particle effects. Do I really need to expand upon this? I have some cool particle systems just recently implemented and they're awesome! :D

* * *

So that was some of the ways I've tried to improve the tech behind the game since the first one. I must say I'm really happy how the game "just works" now; I try various low-end devices with weird CPU/GPU combos expecting it to crash, but instead it works, shaders and all! :)

I'm confident Jewels 2 will be much better experience for lots of people with wide range of different devices, compared to the first one. Technically speaking (i.e. the game working and not crashing/freezing all the time). Not to mention there's loads of game play, sound and graphics improvements coming as well, so stay tuned for more! :)

* * *

TL;DR: The original Jewels was crappy, Jewels 2 is better! :D Also, someone at Microsoft/Nokia/HTC: please send me a Windows Phone 8 device! ;)


Of little games and their sequels…

Ooo, a mysterious title; what on Earth could it be..!? ;)

As you might be aware, I am indeed working on a new project — a game to be specific — that should appeal to anyone who has enjoyed playing Jewels / iJewels.. Originally I wanted to sit silently on this game, right until it was ready for prime time. However, as that point is still quite some time away unfortunately, I wanted to at least talk about what I'm working on. Otherwise there is not much to blog about, right?

So yes, I am working on a game, and no, it is not done yet, but yes: it is a sequel to Jewels and will be called… wait for it: Jewels 2:) There. I said it. Now what? I guess I keep working on it some more. ;)

. . . < insert some cool screenshots and videos here > . . .

Yeah. I realise this would be much more exciting announcement had I something to show, but alas, I don't want to show the game quite yet. Still much graphics to be done not to mention all the effects and stuff. To be honest not all of the (new) game-play features are done either, so there is still much work to be done. The basics do work and I can say with confidence that it plays sooo much better than the original game, and I really look forward to sharing more with you. :D

While I'm not yet at the level where I could show screenshots from the game, I surely can talk about the tech behind it. This is (mostly) a development blog after all. I've been thinking about the Jewels post mortem I talked about earlier, but realised I didn't have much to say about it without mentioning the new tech I've been working on. In that way, it makes sense to just talk about Jewels 2 — from the programmers perspective (and yes, I'm still wearing all the other hats myself!). The next post topic is decided, then.

* * *

In case anyone is wondering: why it has taken this long to make one little casual game? First of all, there is quite a lot of work involved in making even the smallest of games, especially if you want to have certain level of polish in there. And especially when you are not using a ready-to-roll game engine. When you have to do all that work by yourself, that takes even more time. Here's to all the indie developers, working alone or in small teams! Many of you make games way bigger than I have ever completed (even during the then-seemingly-infinite free time during teenage years), which is mind boggling to me, as it takes me a lot of effort to churn out even a small, casual title. :)

Still the biggest reason for me, at this time, is that I'm working at home with my ~2.5 years old daughter roaming around and about. There is just not that much of (focused) development time to be had, that's for sure! :) And of course personally I have a tendency to be a little lazy from time to time, which doesn't help.

But fear not: I have been slowly chipping away at this project for about a year now, have reached the important (if arbitary) milestone of being "halfway done", and the game is starting to look great. I was hoping to get this done by the end of this year, but it seems I'm going to miss that one. Definitely next year then!

Next time I will be talking about the nuts and bolts behind Jewels 2, stay tuned for that one if it tickles your fancy in any way. :)


Android development: Loading ETC1 textures from NDK

This post is probably irrelevant to anyone but Android NDK game developers, nevertheless I wanted to share my findings to help out those with the same problem. (Yes, this is not the Jewels post-mortem I promised, it is still coming :))

As you may know, ETC1 is the common texture compression technique on all Android devices supporting OpenGL ES 2.0. Android SDK comes with this aptly named tool etc1tool, that allows compressing PNG images to the ETC1 format. Android SDK has couple of APIs for loading these textures from the Java side (ETC1Util), but what about the NDK (i.e. the native side, with C or C++)? I was adding ETC1 texture support to my project and wanted to load them from native code.

The tool packages the compressed ETC1 data into a container format called PKM. The problem is that the specs of that format are nowhere to be found! At least, I did not find them despite spending quite a bit of time searching. The docs state that "The PKM file format is of a 16-byte header that describes the image bounds followed by the encoded ETC1 texture data", which is the best I could find.

My first guess was that there would be a tag/id, two 32-bit integers for the bounds and some padding in those 16 bytes. That was close, but not quite. I had to actually install a hex editor (haven't needed one in years) and take a look at the file to see what actually was going on!

Indeed the identifier "PKM 10" was there, but I was puzzled about the bounds. Only after I read somewhere that the image dimensions for ETC1 must be multiplies of 4, it started to make sense. The bounds were not in two 32-bit numbers but in four 16-bit shorts. The bounds appeared twice: first rounded up to the nearest multiple of 4, and then in the original dimensions.

UPDATE: There is actually a format specifier after the "PKM 10" string (not padding), which specifies the number of mip maps (always zero). It is important to note that all the values are saved in big endian encoding.

So here is the format I used, in pseudoish-code:

struct ETC1Header {
    char tag[6];        // "PKM 10"
    U16 format;         // Format == number of mips (== zero)
    U16 texWidth;       // Texture dimensions, multiple of 4 (big-endian)
    U16 texHeight;
    U16 origWidth;      // Original dimensions (big-endian)
    U16 origHeight;
}

That totals to 16 bytes as stated in the docs. Hopefully this helps loading those textures from native code! :)

Disclaimer: all this is based on my findings and the code does work for the textures I currently use, but I take no responsibility if the specs are wrong or bound to change.


The End Of The Road

…for Jewels, that is. Okay, that was overly dramatic, I'll be the first to admit it! :D

Anyway, all jesting aside, it is time to move on. What I'm announcing is that I will not be actively supporting Jewels (nor iJewels) from this point onwards. Not to say that I've been very active lately in any case, but better set it straight out.

Instead I will be focusing my development efforts (time limited for various reasons — not the least of which is the fact that I'm working at home with a little child roaming around.. :)) toward my next game. Not to worry though, I have a feeling that if you liked Jewels, you'll going to like the next game even more… ;) The project is advancing slowly but steadily; I've written most of the technical back-end code and can focus on building the actual game play on top of the thing. I do have to draw all the artwork as well, so it is not going to be finished any time soon — hopefully sooner than later, though!

And no reason to worry, my dear Android users, despite my venting earlier I will be releasing for Android as well, and making sure both versions (Android and iOS) are on even ground this time. To be honest I've been using an Android device as my daily driver for almost a year now, it's good to be back! :D

* * *

Speaking of Android: the first mobile version of Jewels was released in late 2009 for Android, so I've been supporting this one game for over two years now (you could count the original PC-version from 2007 as well, but I didn't work on that but a few months in total). One thing is certain: mobile devices sure have changed a lot since 2009, my ancient by today's standards HTC Hero running Android 1.5 was cutting edge tech back then!

If you think the Android-version of Jewels is really crappy compared to the iOS-version (released in late September of 2010), you are entirely correct — after all it was the first thing I wrote after I got my Hero, and it was hastily ported from the earlier XNA-test project I had done (a.k.a the Jewels PC-version).

It would be interesting to take a look at the horrible internals of the Android-Jewels and see what I would do (and will do, for the next game!) better this time around. So that is precisely what I shall do: when I get the chance I'll write a post-mortem about Jewels.

* * *

To close this post, let's have a look at a few statistics for Jewels:

That one is the for Android-version. 21 million total installs during these two+ years. Only 6.26 million currently active (i.e. on users devices), though. The largest active installs I've seen was between 8-9 million. ~150 thousand ratings with average rating of 4.4 stars. For the iOS-version (courtesy of AppFigures):

About 4.25 million downloads. I couldn't get the average rating across all countries, so the stats above reflect US only (easily the largest of my user bases). Still pretty good. :)

Looking at the volumes, I'd hazard a guess that Jewels is the second most downloaded mobile game from Finland, after that one franchise involving pissed-off birds… (Do correct me if I'm wrong!) Not too shabby for a crappy first attempt at doing a mobile game. ;)

See you for the Jewels post-mortem later, bye!