Game Development Reference
The Model-View-Controller Pattern
Probably the first and biggest difference for programmers coming from a Cocoa Touch
background is that cocos2d doesn't strictly adhere to the Model-View-Controller
(MVC) pattern, which is commonplace in Cocoa and Cocoa Touch.
The MVC pattern divides the programming tasks into the three subsets: model, view,
and controller. The model contains any algorithms that run behind the scenes and main-
tains the state of the world; in essence, the model represents knowledge. The view is
the visual representation of the model and renders the current state of the world based
on the model data. And the controller essentially provides a means for the user to inter-
act with the world through user input, but it's also used to react to other external events
such as receiving data over the network. The model, view, and controller are each sep-
arate classes to decouple the user interface from business (or game) logic.
In games, you can apply the MVC pattern, and many have attempted to do so with
cocos2d. You'll find a good number of articles on the subject if you search for cocos2d
mvc , and my personal favorite treatment of the subject is this two-part article by Bartek
For Cocoa Touch programmers, the fact that cocos2d doesn't follow the MVC pattern
may come as a culture shock. But it's one you can work around. On the other hand, as a
cocos2d programmer, you likely won't even notice that you're using MVC because the
entire Cocoa Touch framework is designed for the MVC pattern. You'll happily use the
controllers and views provided to you, and you'll find no problem adding the logic and
algorithms (the model) into either controller or view, or both. That's also a valid pat-
tern, albeit more tightly coupled and less maintainable in large projects.
Cocos2d's View Uses OpenGL ES
Instead of relying on UIKit for displaying its graphics, cocos2d creates an OpenGL ES
view. This means cocos2d has more direct access to graphics resources and can render
its view much faster.