Shared publicly  - 
 
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.
Danc.
54
19
Maximo Balestrini's profile photoMatthew Ho's profile photoBert Snow's profile photoJP Chen's profile photo
11 comments
 
I like the tip about buttons. Good one :)

The flip side to your advice is, if you are making a game that only works on one of the platforms because of a deep integration point or other platform constraint, take full advantage of the unique user experiences that your platform provides and use them to your advantage on that platform.
 
Sounds like you've been developing in Unity3D too, where UI is the biggest stumbling block to the overall end result - being cross platform means you end up spending more time dealing with UI/Aspect ratio issues than game mechanics! And being an indie developer multiple that by heaps!

Totally agree with you thoughts, not bothered about the 300dpi thing - spent over 15 years doing that for print so doing it now for devices is not a big deal ;)
 
I completely agree that designing your UI in cross-platform ways as much as possible is critical (such as the "icon+background buttons") but my experience is that interface is the most defining aspect of a port. I'm extremely wary of trying too hard to make a "cross-platform UI" -- in fact, I believe that the UI should be designed for each major class of device anyways, and implementing that design often means rebuilding a lot of UI anyways.

Because as you say, in many cases the UI is the only that stands between you and making money (or as I always say, the interface is the product), and trying to find a one-size-fits-all solution seems like dooming yourself to mediocrity.

I agree with all the advice you listed there, but I worry that someone may be inclined to take it too far, so this is the other side of the coin.
 
I use XSL/SVG to generate resources at the appropriate resolution for the device. Personally I think it's a nicer approach than scaling high-resolution images down (or up) and it has other benefits in that you can parameterise commonly changed attributes like colours, fonts, text, etc... The down side is that you basically need a programmer to make the graphics (not a big problem for me since I do my own art), up side is once they are done, it's very easy to produce lots of variations of the same asset.

I have a very basic command line tool that I've written to help with this. At the time I wrote it I was only thinking about image generation, but it can be used to produce text assets (eg. layout definition files) as well.

http://code.google.com/p/batchsvg/
 
I don't think that make bigger buttons is the solution. We are using our own HTML-like layout system to speed up the process of making different layouts for different devices. We have a standalone player to let layout designers test the UI without the need of compiling every time, so we can iterate faster the UI designing process. This way we can target PCs and mobile, adapting the UI properly for each one, without increasing too much the development costs.

* Promotion mode ON *
This tools are part of our app & game cross-platform framework called Strawberry. We are in private beta now and we have planned to launch public this september.
You can find more info of our platform in this study of Telefonica R&D: http://www.slideshare.net/telefonicaid/cross-platform-mobile-dev-tools#
 
Having lived with both HTML layout and XAML (of which I was one of the monkeys tasked with creating tools for the do-everything-layout-engine-from-a-programmers-wet-dream), I've come to the personal conclusion that amazing and awesome UI tools / frameworks are often the last thing that is needed. They are often surprisingly fragile, tightly special cased and have a substantial learning curve.

The rule of thumb for where these things end up is usually rather obvious. UI frameworks: great for programmers, horrible for UI designers and artists. And good UI is almost always a combination of all three disciplines. (And not surprisingly, behind most good UIs are programer/artist/designer hybrids. Who sadly are very, very rare. Usually like 1 per company of 30-50 people in organizations that actively hire for such skills last time I did the research)

UI is a problem area that has proven surprisingly resilient to being solved completely by the tech. Do you realize just how much time and money has been dumped into these over the years? Arguably Microsoft's WPF and XAML were completely focused on this problem and they couldn't solve it elegantly even after an insane amount of money and research. Even Adobe, who actually has a decent toolset compared to most tech-centric groups, does almost nothing to deal nicely with dynamic layout. This problem has been around for at least 20-30 years. Ever wonder why there isn't a good technical solution?

When you have a crazy hard problem that requires a complex toolchain, multiple disciplines, loads of QA and expensive porting costs, maybe it is better to just pick a simpler problem to solve. What is the 20% effort that gets you 80% of the benefit?
 
Your point about simple problems is emerging from this thread as the most important thing for me as well. The comment to use basic layout techniques instead of complex ones is probably the single biggest timesaver for all aspects of UI implementation in all cases. :P
 
I've tried to build this scaleable GUI layout system / tool several times and have found lots of ways that almost work, but don't quite. The parts that don't quite are often a constraint imposed by the systems that do work so there are no easy solutions.
 
I don't say that using a UI framework is the magical solution, it is just a tool. I think that the bigger problem we have to solve is to think that the same UI has to fit on different devices.
I've seen in many game & software companies that people in charge of the UI design are programmers, using tools made and designed for and from programmers. I don't believe in "magical" drag & drop tools or "flexible" GUI systems.
Our in house UI/UX designer doesn't know anything about HTML/CSS layout, because this is not part of his job. We have a layout designer following the directions of our UI/UX expert, they working together can layout changes in minutes, so we can design, test, rinse & repeat.

To show you an example of what we do, look at this app (is not a game): http://itunes.apple.com/us/app/zen-battery/id466431322?mt=8
We use the same logic but a different layout for iPad and iPhone.
 
These days I try to build UI's with the least amount of code possible. Instead of making them data driven and flexible (more code and data). I like to build them them entirely with code with very few systems or abstractions, that tends to make them easier to manage and less frustrating to throw away when I get inspiration for an improved user flow.
 
And that's how you end up with a bad implementation which makes a simple static 2D game eat your phone's battery faster than the latest 3D graphic intensive game!

Yes I'm looking at you triple town on iphone :-( phone runs so hot and battery dies so fast that I just stopped playing the game and stopped recommending it.
Add a comment...