The hidden cost of cross platform layout
So I am looking at the launch window and the subsequent couple years of the new game designs I'm working on. Here are the constraints.
Launching rapidly across multiple platforms
I don't want cloners establishing a brand for one of my original game mechanics first. One way to reduce this is to fast follow your own products and be first into a variety of markets. For us, this means being on the open web, social, iPhone, Android Phone, iPad and Android Tablet.
Many platforms yield many different screen sizes and orientations.
iOS alone has landscape, portrait, small & large screens. Android adds in widescreen aspect ratios. Web portals give broadest distribution at 640x480. Social portals allow up to 760 pixel wide screens. Steam users want to play full screen.
Small touch devices have very different UI needs than either web or tablet.
The buttons need to be much larger. The number of elements on the screen needs to be less. 4 or 5 items is all the fits. You can't just shrink the UI down.
Frequent updates often involving the interface
One of the most common elements to tweak in a game after it goes out the door are the flows in various areas like tutorial, merchandising, viral promotion systems, reengagement systems, and of course the store. These have a direct impact on whether or not the game makes money (and whether or not you can keep developing the project long term).
In practical terms this means you are making lots of small changes on a rapid basis. And those changes need to be replicated across dozens of different UI layouts.
Ideas for streamlining cross platform development
Making bigger chunkier buttons
The most I can translate directly between platforms without redrawing everything the better. Just as PC titles suffered from consolitis, they will also suffer from mobilitis.
Using more lists
Lists scroll nicely when reduced down to small screens. They also work on larger screens.
Giving up on portrait aspect ratio
By making all the games landscape, you save an enormous amount of UI work.
Changing the style of buttons
Instead of having a small buy button next to an item, I make the entire item and the background of the item into the button. This still ends up being aesthetically pleasing, but works much better on mobile.
Making more use of basic dynamic layout
9-grids, snapping UI to corners of the screen and other basic tricks mean you can scale the UI without distorting it. In general, I'm finding it best to avoid fixed layouts where UI pieces are tightly connect as if part of a Tetris puzzle. Floating dialogs, widgets and palettes are a godsend.
Avoid hierarchical dynamic layout when possible
This is when a UI element inside another UI element scales based off the scaling of its parent. Web pages do this. Desktop applications do this. It is a huge pain and often adds as much time to the QA process as it saves. Also the layout systems underlying it are typically not available between platforms and writing your own from scratch becomes more than a little expensive. 9 times out of 10, simplifying your UI is the better solution.
Working at 300 DPI first
This is the big change prompted by the iPad 3. The good news is that even if devices go higher than this, it won't be easily perceptible to the user. This suggests the strategy of starting with the highest resolution assets and then downscale everything in code. This lets you build the UI once on the art side of the asset pipeline. It is an expense, but not so bad if you work in vectors or 3D.
Curious what other folks are doing.