iDevGames Forums

Full Version: ViewController vs. GLView
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

I've finished about 30% of my game and stumbled across the thread regarding GLView and adding additional ViewControllers. In my usual reactionary way, I began to split my game code into two parts - one part remaining in the view, the other moved to the ViewController.

I then realised I didn't have the first clue what the hell I was doing (see Zombies shopping in Dawn of the Dead for others performing a similar mindless going-through-the-motions).

I have a fundamental gap in my knowledge: I have no idea whatsoever what code should live in the View, and what should live in the ViewController.

My guess is:

All general GL stuff (i.e. all openGL calls, texture loading, general sprite class stuff and so on) lives in the GLView. The remainder of my game logic should live in a ViewController so it can be killed off when I switch to - say - a high score table, or front end.

Others I've spoken to personally don't use a ViewController at all. Despite going through the various books, I'm not sure I see the point in them, nor how one decides what to put where. Any thoughts?
For games:

I don't use a view controller for anything except certain system level things like refusing device rotation.

The glView is just the OS level abstraction for your OpenGL context. Just use it to grab input and other system level stuff, then hand off to your game for updating and drawing. My advice would be to simply stay away from the OS level concepts of views and controllers and such (not that they're bad, but they're not necessary for games). I wouldn't at all worry about "where" things should go; just do what works for you. In effect, my games live entirely within the glView, if you want to look at it like that. I got my own little ecosystem going on there...
AnotherJake Wrote:The glView is just the OS level abstraction for your OpenGL context.

Strictly speaking, that's wrong. The view is an abstraction for a buffer that the GL context will write pixels into.
The context is a big bucket of state, not pixels. There can be a many-to-many relationship between contexts and views.

In general though, yes, you can do whatever works best for your game design.
I always set mine up so that other objects only ever have a reference to the view controller. All the controls on the view call their action on the controller too. It helps a bit when you're trying to follow MVC, but I'm never very strict with that.

The reason they make particular sense on the iPhone is that you can let the controller hold all the state information, but the view doesn't have to be created until it needs to be displayed. Likewise, it can be released easily when it's no longer needed. Just make sure the view controller's view property can make a new one when required. (Which is automatic if you use a XIB).

I don't know how appropriate this is for the in-game views. But the menu hierarchy, I find it really helpful.
Reference URL's