Last week I presented a session at DesertCodeCamp 2008 on Developing Casual Games with Silverlight 2. Excluding some technical difficulties, getting my MacBook to connect to dual projectors, the presentation went well. There is certainly interest in the community to begin using Silverlight as a casual gaming platform.

The goal of this presentation was to create a more “developer” focused exploration into a development architecture one could use for building a casual game. In this example, one which leverages pixel-based movement. As with everything in development, there is no real right or wrong architecture, just proven patterns, that have proven scalability, flexibility and efficiency.

Concept

Build a simple game where a player has to move around a box and avoid a series of randomly moving spheres. Each sphere can collide with both the bounds of the box, each other and the player. The player can only be collided with 5 times or the game is over. Player movement is controlled by hitting a combination of arrow keys which changes the vector angle of the players movement. The players speed is consistent, until that player collides with one of the spheres. The behavior of the collision will change based on the element being collided with..

Framework

Last fall Microsoft released its first version of the Model-View-Controller (MVC) framework for ASP.NET as a way to help developers implement this proven separation pattern into ASPX site design. If you have not got a chance to use I strongly recommend giving it a try.

At a very high level MVC divides an application’s implementation into three components: models, views, and controller. This “separation” is used specifically as a way to improve a developers ability to decouple the presentation layer from the business logic. In game development, MVC is an excellent way to build a foundation which simplifies a developers ability to control state such as movement and collision detection. Unfortunately a formal MVC framework does not exist for Silverlight 2, but implementing the pattern is pretty simple. The image to left illustrates how I have implemented the MCV pattern in my example project.

Exploring further you will see that I do not consider “page.xaml” a view. This is intentional. page.xaml is simply a way to get my controller instantiated. All game elements will be inserted into my “Shell.xaml” view by my controller, and this UserControl will be inserted into the page’s LayoutRoot after the page’s xaml has been loaded. My controller will get a reference to this root UIElement via constructor dependency injection, a common approach seen in MVC implementations. Here is the code found within page.xaml.cs.

public partial class Page : UserControl
{
    private Controllers.Controller _controller
    private Views.Shell _shell = new Views.Shell()
    public Views.Shell Shell
    {
        get { return _shell }
        set { _shell = value }
    }
 
    public Page()
    {
        InitializeComponent()
        this.Loaded += new RoutedEventHandler(Page_Loaded)
    }
 
    void Page_Loaded(object sender, RoutedEventArgs e)
    {
        LayoutRoot.Children.Add(_shell)
        _controller = new Controllers.Controller(this)
        _controller.Initialize()
    }
}

Controller

In this game I have a single controller which acts as the central nervous system of my game. It controls the following:

• Primary game timer (tick)
  • Moves Player, Balls and checks for Collisions
• Inserts the appropriate dialogs and listens to events from each
  • Start, End, Next Level
• Listening for events from my primary model
  • Collision, NextLevel, GameOver and StopMovement
• Captures the approriate keyboard inputs
  • Left, Right, Up, Down, Left-Up, Left-Down, Right-Up, Right-Down

Game Model

The controller instantiates and holds a reference to my primary game model which will maintain the games state and expose any methods used to interact with the “Player” and “Hazards” [ball]). The model is the single places that knows how to start a level, insert the player and place each of the balls into a level. When events occur like the player collides with a ball, the model fires an event to the controller indicating what transpired. The controller decides what this means visually to the game play (updates the “Shell” to indicate a new Hit count). The model maintains state so it will be responsible for deciding when the game is over. A game is over when either time has expired (15 seconds) or five collisions have occurred. As with a collision, the model will fire an event to the controller when the game is over.

Behaviors

Part of building this sample was to build upon some of the previous work I have done on spherical collisions. Is previous posts, I have shown how to react to both an elastic and inelastic collision. In this example I refer to elastic behavior as “Deflect” and inelastic as “Bump”. The idea is that if I build an object oriented methodology of defining collision behavior, one based on inheritance, I can expand the types of hazards as I develop new behaviors. For example, the next behavior I intend to develop is one which hazards chases the player, when the hazard gets within a specified proximity of the player.

Here is the game and source.

Code: CodeCampGame.zip