In the second part in this series, I’d like to talk about some of the struggles I had with the menus of Play The Field when porting from iPad to iPhone.
In the game there are two types of menus: interface builder designed menus and custom menus.
The interface builder menus are where I dragged and dropped various components (mostly UILabel and UIButton) onto the relevant view from within Xcode’s interface builder. This main menu, credits menu, and help menu were all done this way. As these menus don’t need to be shown in any of the app previews or screenshots, I kept them extremely simple and functional.
When I first made the iPad version I’d played around with the location of the elements and got things looking nice on a live device, but then when I eventually tried the same menus on an iPhone, things were totally messed up. I’ve found for the purposes of layout, it’s safe to use the simulator for the most part.
From the beginning I had tried to use Xcode Interface Builder’s constraints system to help with layout of the various components. The system works by providing logical constraints like “I want this element in the middle of the screen horizontally”, and then Xcode figures out where that should be depending on the size of the device. Sounds pretty neat, but there are wrong and right ways to use it, and I’m still in the early learning stages.
One of the things I had done wrong was give some buttons constraints so that they were spaced a certain number of pixels from the top of the screen, and some from the bottom. The problem with this was that when the vertical pixel count changed (since iPhone has a smaller resolution than iPad), the positioning of these elements got totally out of whack and the result was a jumbled mess of buttons and labels.
In my case I ended up giving up on perfect vertical centering of elements on both iPhone and iPad, and changed most of the elements so they were relative to the top of the screen. For the end result things looked much cleaner, though there was a larger empty space between the bottom most element when using the iPad.
I’m not trying to convince you to use any specific technique here for layout – there are many articles on this stuff all over the net. But I do think it’s important to have a good understanding of what each devices resolution is before you start making any of the menus. And once you start adding elements to a menu, consider checking on different device types (using the simulator) several times through the process. Try to avoid what I went through which was basically redesigning all of the menu screens from scratch to get the game usable on iPhone. Depending on how complex your menus are, another option is to use completely different view controllers for two or more device types. I ended up doing that for one of my menus.
The in-game menu (showing the available units to create) as well as the level menu both used a set of custom buttons I designed. These gave me full control of the visuals and control processing, but I was not able to use constraints and had to set the button’s locations all manually in code.
For best experience, on iPad I had expanded the level map so it nearly filled the screen, coming close to the right edge. However, when running this on the iPad, since the resolution was significantly less the menu now ran off the side. The way I handled this was by creating a constant that was multiplied against the button sizes and spaces. The constant was set conditionally based on the device type.
For the in game menu bar I used a similar technique, though there wasn’t enough room unless I made the buttons really small, so I removed the “select all button” and moved the help button to the main menu. This gave enough space for reasonably sized buttons. I also tweaked the way the level number, score, and remaining money was displayed so it fit on all device types.
Regardless of what type of menus you use, in order to have things look acceptable on multiple devices it’s best to do a certain amount of planning and research from the beginning.