Evolving Smiles

Alright, I don’t see a reason not to talk about this publicly. So if I’m a good boy, I’ll be walking through my process of up-scaling, converting, and porting Smiles as it happens. Ideally, I’d like to have the game available for all 3 desktop platforms (Windows, Mac, Linux).

Quickly, Smiles is an IGF Mobile nominated collection of puzzle games for iPhone. You can learn more about the game at smiles-game.com, or try it for free by grabbing “Free Smiles” from the App Store.


The irony of an HD matching game amuses me, so that’s something I really would like to push with Smiles. At this stage, it’s not really much more work going straight to HD, so why not?

This new product tentatively called “Smiles HD” I’d like to be completely true to the original. That might sound like nothing special if all you’ve seen is the screenshot above. But what should be noted is that Smiles uses the iPhone’s accelerometer to follow gravity. In other words, as you tilt an iPhone, things now fall the direction the system is oriented. For some games it’s a gimmick, but a very real part of advanced play involves rock breaking. Sometimes, an easier falling/breaking scenario is 90 degrees away.

There’s certain much more to say on the subject, but I’ll save that for later.

The first step as I saw it was to up the resolution of the game art. When I started Smiles back in June 2008, I was sure to make my original art large enough that I could fit it in to textures suitable for HD. The first demonstration of this in action was a screenshot I posted over the weekend.


This involved rebuilding the texture atlas’ the game uses, as the original iPhone one was a fraction of the size.


This actually works out quite nice. The iPhone version fit enough detail nicely in to a 512×512 texture. Doubling that to 1024×1024 gives enough for SD and HD 720p.  Doubling again to 2048×2048 gives enough for HD 1080p displays, and a little extra for those running a monstrous 2560×1600 30″ display. Weather there is a market or not, I have no idea. But you just know there will be that 1 guy or gal who wants to brag. 😀

In actuality, the game board of Smiles doesn’t need this high resolution of art. However, there are a few places in game where the art is scaled (clicking, or on the side bar). I’ve been running a PC development version of Smiles at 2x iPhone since the beginning, and well, the low-res side bar art bothered me. ;).  So I want what’s considered the HD version of the game to be entirely of the resolution, or better.

As of right now, many of the assets are converted. All the buttons and fonts are vector art, so they were a simple matter of setting the new resolution and exporting. There’s still a few little things that were raster, or snapped from vector. I don’t unload textures, since there was enough memory to store them all. Amusingly, a fresh start of the game currently uses about 160 MB of video RAM. If I change the theme, we hit 210 MB.  By the time I finish, I’d estimate the uncompressed textures to take between 260 MB and 300 MB.  Wow! 😀

That’s… a lot.  All assets are uncompressed 32bit textures, so an easy fix would be to start using DXT/S3TC texture compression. That’s something I’ll probably try out today.  If I was to port this to an Xbox 360 or PS3, I’d pretty much have no choice (well, some choice).  The last thing anyone wants is to constantly have to decompress (not crazy enough to ship raw), push in and out huge 2048×2048 uncompressed textures between RAM and VRAM every frame.  Ideally, put ’em in, and let the system perform like the monsters they are.

Still, for PC’s, I’m thinking it may be worth having 2 sets of assets around.  DXT/S3TC compressed ones, and uncompressed.  That way if you do have a 512 MB+ video card around, and a huge 30″ Dell or Apple Cinema display, you can flaunt your computer envy in glorious uncompressed full resolution… with a matching game. 😉

An under served niche? 🙂

Next on the on the agenda, dealing with aspect ratios.