Models and Views Wide
Game Framework for RubyCocoa > Models and Views

Model - The world of a game

A Model represents the data that are needed to play a game. A shooting game, for example, may have a fighter, enemies, missiles, and maps of stages. It may also contain the number of fighters, difficulties (level), and rules of the game. These data are stored in a Model.

While a user is playing a game, the characters in the world of your game should move. A fighter and the enemies move around the window. The user will fire some missiles to attack his enemies. A fighter will be destroyed when an enemy hits it. One or a few Models in a game represent all these movements and actions.

Roles of Model

  • Creates and delete the characters in a game (fighters, enemies, etc..)
  • Manipulates the characters (moves, launches, etc)
  • Possesses all the characters in a game
  • Provides the data for the characters (or the objects of characters)
    • so a View can draw these objects

How a State manipulates a Model

When the current State object receives an event such as a key event and a timer, it manipulates a Model by invoking some method. This means that a Model must provide the methods so the State object can manipulate it. Possible method names for a shooting game are:

  • moveFighter (for key events)
  • launch (for a key event)
  • moveEnemies (for timer events)

Unlike methods in a State, you should not use tick or keyDown for the names of the methods in a Model since these names are very unclear for data manipulation methods. It's always good to use concrete names for method names so that other developers can easily understand what a model does in those methods.

Only several rules

There is no super class for a model. However, a Model needs to have a method named init. This method is invoked:

  • when a game is selected at the main window
  • when a State needs to initialize the Model at its enter method.

Other than this method, you may write whatever you want in a Model as long as you keep the following rules:

  • Do not draw anything
  • Do not play sounds
  • Do not call methods in a View
  • Do not call methods in a State
  • Do not quit a game

That's it. You might have many questions about writing your own Model classes, take a look at the code of the games that are included in MiniKidsGames.

View - Present the world

A View draws all the worlds in a Model, depending on a situation. When a user is playing a game, a View draws a fighter, enemies and background images. It obtains the data from its relevant Model through the methods that the Model provides.

Roles of View

The roles of View are very obvious, it:

  • Present the data in one or more Models
    • by drawing something on the window
  • Play sounds
  • Approve a state transition
    • A view can delay a state transition if it needs to do something before the transition
      such as drawing an animation

Important methods in a View class

Though some methods are defined in View, the super class of all View classes, all you have to care is the following three methods:

  • drawRect()
  • notifyStateWillChange(state)
  • notifyStateDidChange()

The drawRect method, which is invoked after every event process, draws the world of your game. In the drawRect method, you will draw the window by requesting the data from its relevant Model. The relevant Model object is assigned as an instance variable @model.

The notifyStateWillChange method is invoked when the current state attempts to make a state transition. View.notifyStateWillChange invokes state.approveStateChange so that the state can actually make a transition. Overriding this method in a subclass enables the class to clean up some data in it.

Leaving this method without invoking state.approveStateChange can delay a state transition. Typical use of this delay is drawing some animation in between the state transition. When a View finishes animation, it invokes state.approveStateChange at drawRect method.

The notifyStateDidChange is invoked when a state is changed. Overriding this method enables a subclass of View to initialize some data. It also gives a subclass to detect the state transition when it is related to more than one subclass of State. Typical uses of this method are:

  • creating and/or playing sound objects
  • creating image objects
  • initializing other objects that help in drawing.
  • switching drawing routines depending on the current state.

See View class reference for more detail.

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.