• Module 1: Getting Started – Architecture / framework
• Module 2: Movement and collision detection
• Module 3: Design – Sprites, boards and dialogs
• Module 4: Animations and sound
• Module 5: Initialization and Deployment
• Module 6: Advanced concepts (Physics, Multiplayer, Optimization)

Make sure to check out the article at http://www.microsoft.com/expression/news-press/newsletter/

Code: COMING SOON

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

Just as in my previous example I use a single DispatcherTimer and a generic collection of UserConrols. To keep track of the direction that each ball is traveling I added a boolean property to my “Ball” user control to determine if it was rotating clockwise.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

void _timer_Tick(object sender, EventArgs e)
{
    foreach (Ball ball in _balls)
    {
        double x = 0.0;
        double y = 0.0;
        double angle = ball.Rotate.Angle;
 
        CalculatePosition(ball.Clockwise, ref x, ref y, ref angle, 1);
        //update the position of the ball
        ball.Rotate.Angle = angle;
        ball.Translate.X = x;
        ball.Translate.Y = y;
 
        //check to see if a collision has occured
        if (ball.CollisionType == Ball.CollisionTypes.Deflect)
        {
            foreach (Ball ball2 in _balls)
            {
                if (!ball.Equals(ball2))
                {
                    double b2X = 0.0;
                    double b2Y = 0.0;
                    double b2A = ball2.Rotate.Angle;
                    //if we wait until the two balls are at the same X/Y then the balls
                    //will have overlapped.  Instead, predict by looking 5 degrees ahead 
                    //then switching direction.
                    CalculatePosition(ball2.Clockwise, ref b2X, ref b2Y, ref b2A, 5);
                    if (Math.Ceiling(x).Equals(Math.Ceiling(b2X))
                        && Math.Ceiling(y).Equals(Math.Ceiling(b2Y)))
                    {
                        ball.Clockwise = !ball.Clockwise;
                        ball2.Clockwise = !ball2.Clockwise;
                        //ball.sound.Position = TimeSpan.FromMilliseconds(0);
                        //ball.sound.Play();
                        break;
                    }
                }
            }
        }
    }
}

As you can see in the code above, I am doing a quick check to see if my rotating ball is defined to deflect upon collision. In this example, this is the only type of collision supported. In the future, I might add things like exploding on impact or magnetism upon the collision.

The first step in the circular rotation is to move each ball to its new X/Y position. Once moved, I check to see if any other balls overlap its current X/Y location. To make the collision more realistic (no overlap), I predict where each additional ball will exist 5 degrees forward of its current angle. This allows me to simulate the ball just touching each other before reversing directions.

Code: CircularCollision.zip