Structure of A Game Wide
Game Framework for RubyCocoa > Structure of A Game

The basic structure of a game is based on both MVC pattern and State pattern. First, this chapter illustrates the patterns used in the framework. Second, it shows the basic structures and behaviors of a game.

Patterns in the game framework

MVC pattern

The MVC pattern is a classic architecture pattern that is frequently used for separating data from their presentation. MVC stands for Model, View, and Controller. The basic concept of the MVC pattern is to separate roles of your application into three different categories - Model, View, and Controller. See Pattern Oriented Software Architecture for more details. You can also see on-line resources such as http://www.enode.com/x/markup/tutorial/mvc.html and http://ootips.org/mvc-pattern.html.

Differences between pure MVC and the one in the game framework

As the game framework actively separates Model and View, there is no means for Models to know their relevant Views. The Controller in MVC automatically requests an update to a View when a model manipulates its data.

MVC-pattern.png SIZE:363x219(?KB)

State pattern

The State pattern, introduced in [[Design Patterns>]] by GoF, changes a behavior of a model for the same event or method call, depending on a situation.

In a game, for example, pressing the space key in different situations makes different results. It may fires a cannon while playing, and it may change the user preferences while changing configuration. When a certain condition becomes true, the current state transits to another state so the game can change its behavior.

In the game framework, there are one or more states in your game. The Controller in MVC, which is hidden in the framework, delegates events to the current state. The current state, then, manipulates a Model. When the current state finishes its process, the Controller updates a View that is relevant to the Model.

State-pattern.png SIZE:398x282(?KB)

The structure of a game

The game template provides a subclass of a View, a State, and a Model. The subclass of Game contains the sets of these three classes just like a game package for mapping these classes. The Controller is already implemented in the game framework so you don't have to implement it. This chapter explains the structures and behaviors of State, Model, and View in this order.

GameStructure.png SIZE:330x160(?KB)

Typical Scenario in a game

The typical scenario in a game is shown as the figure below. When an event occurs, the Controller delegates it to the current state. The current state, then, manipulates a Model by invoking a method related to the event. After the manipulation is finished, the Controller requests a View to update the drawing rectangle by invoking View.drawRect(). The View asks its relevant Model to obtain the data for drawing the world of the game.

Typical-sequence.png SIZE:484x261(?KB)

See also State class and View class for more detail information about these classes.

Leave a comment

Begin the comment with //pukiwiki if you want to write a comment in PukiWiki format.

You must be logged in to post a comment.