IPhone OpenGL ES single or multiple views?

I'm confused on what the best approach is when writing a game for the iphone. The game will be rendered with OpenGL , but im curious when creating the Start Screen, Menu's, High Score page, etc. Do you do all of that with OpenGL or do you create additional UIViews and use the UIKit?

From stackoverflow

• I don't think there is a right answer for this. I personally use opengl for everything, for example in menu structures I use textures for the text. I guess it depends on what you want to display, I think it would be easier to create a custom look and feel that goes well with your game if you stick with opengl.

  chicken : Yes i think i will take this approach, but i just didnt know if it was better practice to let apples uikit handle the basic's.

• I've heard contradictory things about this. I've heard it's slow when you render UIKit over the OES.

  I say, if you see another app doing it that performs okay, follow suit.

  Some of the more popular games do everything in OES - e.g. Rolando. Maybe it's best to follow that pattern.

  U62 : I don't think he's asking about layering UIKit over OpenGLES views, just whether to use it for other 'modes' of the game.

  chicken : Yes like u62 said, basically i would have in that example a bunch of view controllers and pushing/poping views based on the proper one to display.

• I don't think there is a best approach. If you have the time to code up menus and high score tables in OpenGL the you have a lot more flexibility - you could for example have a 3d animation going on in the background.

  If you code menus, high score tables, etc. using standard UIKit views and switch out the OpenGL view while they are shown then this has the advantage that it's very quick to code (esp. if you took the time to learn to use Interface Builder), but it is inherently 2d. Even though you can still use custom button graphics and fonts to make it look less like a business app, it's still going to look less polished compared to other games in the app store.

  What you don't want to do is to layer a transparent UIView over the top of you OpenGL view - this will be very slow.

  I personally use Interface Builder generated views to get stuff like menus in while I'm building the rest of the program. The intention is to replace that with OpenGL animated code later. In the end though, it's really down to how much time you have available.

  chicken : Thanks, i think i will just go the ES route to do all of this.

  José Joel. : But, what You do about the text ?...I can make my buttons and interfaces in openGL, but how do You deal with the text ?...if all of my game is in english for example I only write It over my graphic assets, but what if i need to localize It ?, seems kinda of complicated

  U62 : Usually in a game you have two situations: a small amount of text and a large amount. If it's a small amount you'd probably burn the text into a bitmap and in the case of localisation, just have multiple copies of the bitmap. Where you have large amounts of text, it's not practical to store it in a bitmap anyway, you need to render the text at runtime. You can create a graphics context on an off-screen bitmap, use Quartz APIs to render whatever (including text) and then use that bitmap as an OpenGL texture.

• In addition to what others have said, consider that it's a bit easier on you to stick with OpenGL since that's going to be the bulk of your codebase.