So, as of the milestone for our iOS and PC exploration and crafting game we hit a couple of weeks ago, we have a character who walks about a world in which plants grow, rocks can be decimated, trees chopped down and all manner of mayhem ensues (there’s even wildlife flying overhead). You can move your little character about, and you can interact with the world.
There’s a full functional inventory system, and it can be filled up with any number of tasty little items from [redacted] to [redacted] all the way up to the popular crowd-pleaser [redacted].
Which meant it was time to take our design document’s user interface section and… well, implement it. There’s one small problem with that: our game is aimed at mobile phones and tablets, and while they use the same kind of APIs and languages, and are even binary compatible with each other in many cases, the difference in screen size between a typical smartphone and a typical tablet is nothing to be sneezed at.
Screen real estate? That stuff’s even dodgier than actual real estate!
There’s an old saying that no battle plan survives first contact with the enemy. In this case, mobile phones were the enemy… sneaky little buggers.
An inventory screen in itself isn’t hard to do – all you’re doing is showing the objects you carry. Whether it’s a list of text or a lot of pictures in boxes, it’s not too hard to simply make this UI object scale based on the screen size. You’ll see less objects at once on your pocket device, but it’ll still work fine.
Our mockups of UI screens were almost all on iPad-sized tablets, and when it came time to actually render some windows on our test phones, I found myself sighing. On paper, our windows would scale fine to smaller devices. But jeeze phones can be small! Even when you’re just targeting iPhones as the smallest, there’s a huge difference between the 3.5″ screen in mockups and a 3.5″ screen when you’re trying to jam your stubby little fingers at them after a full 12 hour day of programming.
Take note, game designers: you may hear the odd joke at the expense of UX/UI professionals, but don’t be fooled – what they do is damn hard. The fact that you so rarely have to stop and think about the interface on a modern smartphone is a testament to years of time finding the best ways to bring a complicated user interface to a tiny, tiny screen – and one which is often partially obscured by your fingers and thumbs.
This doesn’t even factor in that in contrast to a mouse, your fingers could trigger a touch on anywhere up to a 40 pixel circle from where you intended – and that’s if the user if experienced (and with average size fingers and sobriety).
That little ‘X’ on the corner of your window to close it? Yeah, that’s probably a bad idea. There’s a reason that kind of window doesn’t exist much in iOS and Android applications.
Most of this stuff we’d known ahead of time, but it still amazes me how many things we took for granted.
Our inventory has so far been the only thing which is being implemented in almost exactly the same fashion as it was originally described in our first few pub-meetings about the game. Most everything else has been the subject of re-designing or at least a bit of sanity checking.
One thing that proved to be a consideration that I didn’t think would be is actually this: the frame of the windows.
What you’re staring at is a Scale9 sprite – a way of breaking up a single window texture so that it can be used to render almost any size of window, on the fly, using the one sprite.
After implementing this, I realised something – those few pixels which sit in the sides and make your window look nice are all good and well, but even just a 20-or-so pixel margin on your window could be losing up to an eighth of your screen real estate. When I thought of this originally, I’d dismissed it because it’s generally a bad idea to put usable objects too close to the edge of the screen anyway – I’d even read that the edges of screens are the places most likely to die (or lose some touch reactivity) first.
What I hadn’t thought of is that these edges may not be ideal for button placement, but they are useful for displaying information.
So are we going to lose the edges? Probably not, but it’s been an interesting time realising just how much our careful planning needs to be re-evaluated when seen on a tiny little 480×320 screen.