Small is much, much better

I’ve been making mobile phone and tablet apps for a few years now and have had so many face-palm moments - watching my peers repeat the same mistakes - that I’m sure my forehead is permanently flattened. In this post I’m going to discuss how we addressed one of these: resource-bloat; in our new phone app 'Art of Perception – Ravioli'.

Ravioli is a visual puzzle game.  It combines 144 unique basic shapes to make 225 puzzles in 15 levels of difficulty. The game play is entirely graphical so the assets have to be the absolute highest quality and render extremely quickly.

I know most readers of this post will have multi-core, monster-memory, 4G, power houses in their pockets, and tendency is to develop for what you have. Our target was to make Ravioli work really well on little slow phones – and it does. Why make it work on little stuff? Well there’s a lot of people on entry-level phones, and if Ravioli works well on those it work really well on better hardware. Bit of a no-brainer there.

One of the things we did was to make the game resources as compact and efficient as possible without reducing quality and flexibility. This we achieved in spades; the assets for the 225 puzzles are ~30KB compressed / ~150KB uncompressed. The other core graphic assets: icons, badges etc. are ~44KB / ~240KB. The splash screen is ~25KB. All graphical assets, except the splash screen, are held in our proprietary object databases.

This is possible because Ravioli uses our own custom 2D renderer and a binary vector asset format. This means we own the whole graphics pipeline, across platforms. The normal alternatives would have been to rely on either a huge pile of pre-rendered PNGs, which would have been a major asset bloat and a monstrous asset management headache. Or to render SVG assets to PNGs when the app starts, which is often a better technique. Using PNGs just wouldn’t work for us at all and standard SVG rendering lacks the micro-control Ravioli needs. Both alternatives would have made our Mac/OSX game editor more or less impossible and probably would mean that Ravioli would never work properly.

Audio assets were easier to deal with. We standardised on 64kbps, as audio in Ravioli is either background or transient effects - any lower quality than this and it became noticeable. This keeps the audio sizes small, but at about 10% of the package size they still dwarf the graphic assets .

OK, what benefits do we get from this?

All this makes Ravioli a good citizen; an easy and reliable download; a fast install and it looks great on all devices.

Ravioli is currently in beta for iOS. You can register for TestFlight at http://www.q4technologies.com.

There is more about Ravioli, its history and how we assess problem solving skills at our blog: https://q4technologies.wordpress.com/.