At Kerb, the digital agency I work for, we have been doing a lot of mobile work. Most recently we have been commissioned by a large multi-national entertainment brand to produce a multi-lingual ‘match 3’ type game that has to be ported across 33 Android devices and the iphone 4 and iphone 3Gs.
As there is currently no standardized methodology for designing across multiple mobile devices (an assumption based on our own research that was confirmed by various speakers at this years dConstruct conference) I thought I would post up some of our design processes.
This first post is about our initial reaction to the task of converting art and design assets for use on multiple mobile devices.
As is with many projects, time-lines were challenging and we had to get a working version on one particular Android device before we ported the game to the other devices – so we went ahead with the one Android version of the game before we went to work porting the game to other handsets.
The challenge for the design team is to take an existing game that has been designed for one particular handset and then make that design look intentional and considered across 33 other devices which all have different screen dimensions and resolutions.
This process is also particular to our game, other apps and games would not necessarily have the same process; our game is a visually rich experience with lots of animation and illustration all based on our clients IP. Visually simple games and apps would not need the same approach.
So, our initial challenge was to simplify the information we had about the different handsets, and then re-present this information to the design team. This information will help us create a clear strategy for amending our art and design assets with the least amount of impact on time and budget.
We simplified the mobile phone specifications with three simple steps.
Firstly we grouped our device list into their respective screen dimensions. We did not worry about screen resolution at this point as we would deal with resolution as part of the export process (a process I will talk about in a later post).
This grouping helps simplify the list, we can quickly see that there are four different screen dimensions from a list of 33 devices – which means we have four different aspect ratios to consider.
Our first comparison of screen sizes – by anchoring the different screens top left we can see the differences in the aspect ratios and how they will impact our design. We have rich illustrated backgrounds to our game levels – What will be the simplest way to amend our assets to fit these different aspect ratios? Can we keep a consistent grid?
Our next comparison of screen sizes gives us the solution. By giving the four different aspect ratios the same fixed height and aligning the screens on a central vertical axis we can further simplify the amends we have to make – we can now see that the differences in the screens can be restricted to width, and the amends to the relationship of elements within the design (art assets and UI) can be restricted to the vertical edges of the device screen. We are now in a position to make decisions on whether to apply a fixed or a relative structure to our design.
By presenting the information in this way solutions arise, and complex looking tasks appear much simpler and far less daunting.
The next step in our process is the physical amending of the art and design assets and their export to sprite sheets and mobile-ready assets, which we do with both off-the-shelf software and bespoke components we write internally. I will write up these next steps in another post with the help of Kerb’s Technical Director, Pete Hobson.