Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm asking this to get everyone's opinion -- I realize there isn't one "right way" to do this. I've tried a few ways myself, including using Cocoa for everything including the game itself (good for simpler games, like card games for example), using Cocoa for the screens outside of the game and using my game engine to present game objects on the screen as UI.

What do people prefer to use for game UI? I'm particularly interested in hearing about why you chose to go that way and if you found that your choice was a good one after implementing it.

share|improve this question

closed as off-topic by Anko, bummzack, Seth Battin, Sean Middleditch, Vaughan Hilts Apr 7 at 3:58

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions about "how to get started," "what to learn next," or "which technology to use" are discussion-oriented questions which involve answers that are either based on opinion, or which are all equally valid. Those kinds of questions are outside the scope of this site. Visit our help center for more information." – Anko, bummzack, Sean Middleditch
If this question can be reworded to fit the rules in the help center, please edit the question.

add comment

3 Answers 3

I have taken advantage of what apple has provided with UIKit. My last few projects have abused Core Animation/UIKit instead of OpenGL ES. For my case it worked perfectly well. My next project will use OpenGL ES and I'm not quite sure how I will manage the UI yet. I will likely still abuse UIKit.

I've seen a few developers use OpenGL ES to push their graphics and actually integrate UIKit into the scene to handle the User Interface. If you're interested in hearing a developer talk about the integration check out this article he wrote. Great guy.

share|improve this answer
add comment

We chose to use our own in-game UI for a few reasons, the main one being it enables easy ports to the Android platform (hardware diversity issues aside), as well as windows-based builds (very handy for testing), and it allows a great deal of flexibility in terms of bringing game elements into the UI (for example, our particle system was reused to add a bit of flair to the UI).

Overall I'm very happy with the decision, though it's not without it's caveats. Namely, UI building is much more expensive than it would have been with IB, and the initial time required to build a usable UI system was considerable.

share|improve this answer
add comment

For my last iPhone (Dr. Awesome), all the menus before the game started were in UIKit. I didn't even create the OpenGL context until the game was started. In our case, it worked out really well as the menus were created really quickly and with a GUI and didn't require a bunch of game-specific UI code. It's important to note, though, that the design of our game was such that we didn't need to have menus integrated with game art, and the game itself had no buttons (other than a dialog box for the pause menu).

In retrospect, doing everything in GL and rolling our own UI system would've allowed for more flexibility and portability. In our case portability wasn't a concern (and I really wanted to learn/abuse Objective-C), and the cost of adding menu code wasn't really worth the added flexibility. And we weren't in a position to really need to use the code base after that project to amortize the cost of doing our own UI system (since we've switched to Unity as our iPhone engine).

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.