Clarity Battleship

At Clarity Consulting we’re always looking for a little friendly competition. That’s why a few times a year we hold coding competitions that we call Tech Challenges. I recently organized one based on the classic board game Battleship.

The flow of the game is based loosely on the board game. The simple goal is to sink all of your opponents’ ships. Since we’re writing code though, I decided to step up the game play and make it a more interesting, requiring more strategy than luck.  Just like the board game, the battlefield is a grid. Unlike the classic, however, multiple teams can battle at the same time. Each team’s fleet is assigned to a region of the Battlefield.

In our tournament we had six teams battle at a time and held one “Battle Royale” with eleven teams.  Below you can see a sample screen shot of a game with three teams. Blocks in red indicate damage. The bottom of the screen displays messages broadcast or information about fleets that have been sunk. 

Teams position ships at the beginning of the game and give ships orders to execute including:

• Attacking locations on the battlefield
• Performing reconnaissance on an area of the battlefield
• Broadcasting messages to opponents or conspirators via an “open radio frequency” (collusion and deception are allowed and encouraged!)

Game play is pseudo turn-based. Teams are notified by the game when their ships are ready to execute an order. Teams are also notified as ships are damaged or sunk. The game ends when only one team remains.

Application Architecture

Now that you have a feel for the game play, let’s talk about the code. One reason for building this game was to give myself a fun way to learn more about Windows Communication Foundation (WCF) and Windows Presentation Foundation (WPF), new features of the .NET Framework 3.0.

WCF provides a new unified mechanism for client-server communication that greatly simplifies that amount of work necessary to by standardizing the way you build your communication pieces. I recommend reading this article as a good place to start learning about WCF.

WPF enables richer user interfaces and better integration between developer and designer through the use of XAML. As you can see by my simple (though I think pretty cool) UI, I focused my interest on WCF, but did take advantage of a bit of what WPF has to offer.

Overview

The Battleship application is divided into three parts. The Battleship.Components project is a shared assembly that contains the classes which manage the communication and the logic of the game as well as class definitions for all of the ships (i.e. AircraftCarrier, Battleship, etc.). The Battleship.Gameboard uses WPF to display the action on the battlefield. Finally, console applications are built by each team wishing to compete.

The diagram below shows how the pieces fit together.

WCF Communication

As I mentioned, my focus in development was using WCF to manage the communication between the fleets and the game. I was very interested in exploring the bidirectional communication that can be achieved with WCF because it seemed like a perfect fit for the scenario. A traditional web service can receive messages from clients and send back responses. However, it can’t originate a message on its own to send to the client. For example, with a web service I could easily have a fleet tell the game about an order to execute (i.e. “I want my Battleship to attack 7,2”). However, I can’t have that web service inform another team that its ship was just sunk.

With WCF I was able to achieve this without writing a lot of custom code. There is some complexity in the code, but most of that is because my goal was to hide the communication layer from the building of a fleet so that players could simply focus on writing the code to implement their strategy. The following sections will walk through the flow of the communication.

Server Side

While the Battleship.GameBoard is Windows Forms App, it actually should be considered the server in this application. That’s because it hosts the WCF service that the Fleets call.

To define a WCF service, you start by defining the interface for the service. Similar to the WSDL of a web service, this is going to tell consumers what the contract, or inputs and outputs, of the service are. Callers will call the different operations exposed by the service.

In this application, the IBattleshipGameService interface seen below defines the contract for the service.

[ServiceContract(CallbackContract=typeof(IBattleshipGameServiceCallback))]
public interface IBattleshipGameService
{
    [OperationContract(IsOneWay = true)]
    void RegisterFleet(Fleet fleet);

    [OperationContract(IsOneWay = true)]
    void ExecuteOrder(string shipID, Order order);
}

The interface shows that there are two methods for consumers to call, RegisterFleet and ExecuteOrder. The OperationContract attribute indicates that these are methods. The IsOneWay parameter of the attributes indicates that no response is sent back to callers. That probably seems straightforward for the RegsterFleet call, but you might expect that ExecuteOrder might return a result.

Actually what happens is that when a fleet is registered, the service holds on to a channel for calling back to the fleets. And the ExecuteOrder method only queues up an order for processing, but doesn’t immediately execute it. Before queuing it up, the game logic ensures that there aren’t already too many pending orders in the queue for the ship. This prevents a team from cheating by blasting the server with orders. We’ll delve more into how the communication back to the client is achieved later.

With the interface to the service defined, let’s turn our attention to a portion of the application configuration file.

<configuration>
  <system.serviceModel>
    <services>
      <service name="Clarity.Battleship.Components.GameSide.BattleshipGameService" 
                    behaviorConfiguration="BattleshipGameServiceBehavior">
        <endpoint address="http://localhost:8088/BattleshipGameService"
                  binding="wsDualHttpBinding"
                  contract="Clarity.Battleship.Components.GameSide.IBattleshipGameService"/>
      </service>

This shows the definition of the service. The contract attribute indicates the service will adhere to the IBattleshipGameService interface. The binding attribute indicates that the WSDualHttpBinding will be used. This is the plumbing that allows both services and clients to send and receive messages.

With the interface and configuration in place, a concrete implementation has to be built. The BattleshipGameService class provides this. This class implements the IBattleshipGameService interface described above. The actual code for registering a fleet and executing an order are therefore defined here.

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single,UseSynchronizationContext = false)]
public class BattleshipGameService : IBattleshipGameService

Note the ServiceBehavior attribute and its InstanceContextMode property that decorate the BattleshipGameService class. WCF uses this attribute to decide how to execute the operation when a call comes into the service. In this case, the attributes indicate that the service should run as a singleton. In other words, all calls will be executed by a single instance of the BattleshipGameService. You can further see this in the following code taken from the constructor of the Game class that shows how the service is actually brought to life.

Uri u = new Uri("http://localhost:8088/BattleshipService");
_gameHost = new ServiceHost(new BattleshipGameService(), new Uri[] { u });
_gameHost.Open();

The ServiceHost (which does what it sounds like and hosts the service) is created by passing in an instance of our service object and the uri for the address of the service (I know the uri seems redundant since it’s in the config, but as far as I saw I had to use this constructor). Since we know the service host will just use the single instance of the BattleShipGameService, we can track that instance through a private property for convenience and hook its events as seen in the code snippets below.

private BattleshipGameService BattleshipGameService
{
    get
    {
        return (BattleshipGameService)_gameHost.SingletonInstance;
    }
}

this.BattleshipGameService.FleetRegistered +=
   new FleetRegisteredEventHandler(BattleshipGameService_FleetRegistered);
this.BattleshipGameService.OrderExecuted += 
   new OrderExecutedEventHandler(BattleshipGameService_OrderExecuted);

This allows us to elegantly pass off the calls to the Game class. The service then acts as a simple pass through and leaves the Game class to manage the game.

Client Side

Now that we’ve covered the basics of the server side, let’s look at what happens on the client side. In each console app, a class is created that derives from the FleetCommander class (there are complete directions on how to do this with the downloadable source). The FleetCommander class exposes all of the ships of the Fleet for the team to program against.

To avoid cheating, (some would call it creative programming) each ship gets a unique identifier set by the Game at startup. That way the Game knows which orders are legitimate. To hide that id and details from the FleetCommander and make a very simple and intuitive interface, the method for executing an order is exposed off of the ship classes. The code snippet below shows how FleetCommander could react to an event indicating that a ship is ready for orders. In this case it is saying that the ship should attack the coordinate at location _targetX, _targetY.

public override void OnShipAwaitingOrders(Ship ship, Order lastOrder)
{
      Order orderToExecute = new Order();
      orderToExecute.Coordinate = new Coordinate(_targetX, _targetY);
      orderToExecute.Type = OrderType.Attack;
      ship.ExecuteOrder(orderToExecute);

Under the covers, the Ship.ExecuteOrder method raises an event which is handled by the base FleetCommander class. The FleetCommander calls the appropriate method on a WCF client class which makes the call to the BattleshipGameService.

A portion of the definition of the WCF client can be seen below. You’ll see that it is a class that derives from the DuplexClientBase. This class manages the channels that pass messages back and forth. You can think of it as similar to a web service proxy class.

public partial class BattleshipGameServiceClient : 
    System.ServiceModel.DuplexClientBase<IBattleshipGameService>, IBattleshipGameService
{

So that covers how messages are sent to the server, but you may be asking yourself “How did a FleetCommander find out it that a ship was awaiting orders?” or for that matter “How does it get notified about anything?”

Well, each FleetCommander has an instance of a listener class which receives callbacks from the game service. The way this is set up for the listener is very similarly to how we set up the service. Once again we start with an interface, in this case the IBattleshipGameServiceCallback interface.

public interface IBattleshipGameServiceCallback
{
    [OperationContract(IsOneWay = true)]
    void OnFleetUpdated(Fleet fleet, FleetUpdateReason reason);

    [OperationContract(IsOneWay = true)]
    void OnGameStateChanged(GameInfo gameInfo);

    [OperationContract(IsOneWay=true)]
    void OnOrderExecuted(string shipID, Order lastOrder);

    [OperationContract(IsOneWay = true)]
    void OnMessageReceived(string data, Coordinate c);

    [OperationContract(IsOneWay = true)]
    void OnFleetSunk(string fleetName);
}

Just like before the OperationContract attributes are used to indicate the methods available. And just like before we need a concrete implementation of the interface. Enter the FleetCommanderListener.

public class FleetCommanderListener : IBattleshipGameServiceCallback

The FleetCommanderListener is used when creating the BattleshipGameServiceClient. As you can see in the constructor definition below, a callbackInstance parameter must be passed in. The BattleshipGameServiceClient can then handle communication to the server via the IBattleshipGameService interface and also listen for communication back that adheres to the IBattleshipGameServiceCallback interface!

public BattleshipGameServiceClient(System.ServiceModel.InstanceContext callbackInstance) :
     base(callbackInstance)

The last little piece of the puzzle is the client configuration file.

  <system.serviceModel>
    <client>
      <endpoint name="Clarity.Battleship.Components.IBattleshipGameService"
                address="http://localhost:8088/BattleshipGameService"
                binding="wsDualHttpBinding"
                bindingConfiguration="BattleshipBinding"
                contract="Clarity.Battleship.Components.GameSide.IBattleshipGameService" />
    </client>
    <bindings>
      <!-- configure a binding that support duplex communication -->
      <wsDualHttpBinding>
        <binding name="BattleshipBinding"
                 clientBaseAddress="http://localhost:6088/BattleshipGameClient/">
        </binding>
      </wsDualHttpBinding>
    </bindings>
  </system.serviceModel>

As you can see from the example above, the configuration is fairly straightforward. Just like in the server config, we say we’re using the wsDualHttpBinding. The one additional piece of info is the clientBaseAddress which tell the server how to call back into the client.

The Complete Picture

So after reading all of this, you might be thinking “I thought he said there wasn’t much custom code needed.” I think that is still true in terms of the WCF. While certainly not trivial, it really boils down to building a couple interfaces, their concrete implementations, and filling out some config files. Most of the complexity came in was in building out the eventing model to simplify the interface for teams.

The following diagram helps pull everything together by showing an example of the flow of the communication for execution of an order.

1. The derived FleetCommander makes calls the ExecuteOrder method on a Ship (i.e. “I want my Battleship to attack 7,2”)

2. The Ship raises an event which is handled by the FleetCommander base class which in turn calls to the BattleshipGameServiceClient

3. This WCF client class makes the WCF call to execute the order

4. The single instance of the service raises an event to the Game class with the order information

5. The Game class which controls all the game flow enqueues the order

6. After processing an order from the queue, the Game calls the OnOrderExecuted WCF callback which gets invoked on the FleetCommanderListener

7. Finally the FleetCommanderListener raises an OrderExecuted event to the derived FleetCommander class (i.e. “Your Battleship’s attack at 7,2 resulted in a Hit”) which is turned calls the OnShipAwaitingOrders method and the cycle starts over

WPF User Interface

The last thing to cover with the architecture is the UI. It is pretty simple, but I wanted to experiment a little with WPF. The Gameboard assembly contains a class called Battlefield that is a WPF Window (comparable to a Winform Form). A Grid control makes up the main component of the gameboard. The grid lent itself to building the UI since everything stretches nicely to fit the screen, regardless of the number of teams competing.

Once the game starts, the game board is setup by adding rectangles and images to the grid control. Throughout the game, the colors of the rectangles are changed to indicate shots, recon, or hit targets.

Below is an example of some of the Battlefield code behind in which the rectangle for the location of the order is painted a different color depending on the result of an order.

Rectangle r = _rectangles[_lastOrderStarted.Order.Coordinate];
if (e.Order.Result == OrderResult.ShipHit)
{
    r.Fill = Brushes.Red;
    _rectangleFills[e.Order.Coordinate] = r.Fill;
}
else if (e.Order.Result == OrderResult.ShipSunk)
{
    r.Fill = Brushes.Red;
    _rectangleFills[e.Order.Coordinate] = r.Fill;
}
else if (e.Order.Result == OrderResult.Miss)
{
    r.Fill = _rectangleFills[e.Order.Coordinate];
}
else
{
    r.Fill = _rectangleFills[e.Order.Coordinate];
}

Conclusion

Hopefully you enjoyed this game and learned a little in process. I encourage you to download the code and build your own fleet. The download includes a document called “Clarity Battleship – Building a FleetCommander” which gives you step by step instructions. Feel free to post your own builds here for other people to challenge and good luck with your battles!

Bryan Dougherty is a Principal with Clarity Consulting, a software development consulting firm based in Chicago, IL. He is an MCP with several years of professional software engineering experience. Bryan earned a B.S. in Computer Science from Northwestern University and writes about topics related to software development on his blog.

Introduction

I've always loved mobile technology and I wanted to try my hand at mobile development. So a little ways back I bought a Smartphone, the Motorola MPX220, which runs the Windows Mobile 2003 OS. I hope to upgrade to a new Smartphone soon, so this article will discuss building an application targeting the Windows Mobile 5.0 Smartphone platform.

When deciding what to do, I thought of a variety of useful applications I could build. Then I decided that making a game would be more fun. I settled on a classic: Pac-Man.

Figure 1: Pac-Man running on Windows Mobile 5.0 Smartphone Emulator

Getting Started

Before diving into code, I thought I'd mention some of the pieces involved in developing for the Smartphone.

Development Environment

In order to create applications for the Windows Mobile 5.0 Smartphone platform, the following applications need to be installed:

• Visual Studio .NET 2005 Professional Edition
  
  
• Windows Mobile 5.0 Smartphone SDK
  
  
• ActiveSync Version 4.1.0

New Project

Once the development environment is set up, the new Mobile 5.0 Smartphone templates appear under the New Project dialog in Visual Studio.

Figure 2: New Project dialog in Visual Studio (click image to zoom)

Note that you choose which version of the Compact Framework you are targeting when you select the project template. Those targeting CF1.0 have 1.0 after the name, while the others target the 2.0 Framework.

Development, in general, feels just like development of any WinForm application. You do need to keep in mind, however, that some functionality supported by the standard .NET Framework is not supported by the Compact Framework. For more on support for classes you can look in the MSDN Library.

The Emulator

While developing, you don't have to deploy your application to an actual phone when you want to test. Instead, a built-in emulator, as seen in the Figure 1, is available. With the click of a button, you can deploy to the emulator and test your application with full debugging capability, just like you would a WinForm application. The behavior and speed of the emulator seemed to provide a reasonable indication of how the application would perform on an actual phone.

Development

Instead of rushing in and trying to crank out the code for Pac-Man, I took a more structured approach. With a few proof of concepts under my belt, I decided to build a framework that would provide the common building blocks needed to create 2-D games for a Smartphone. I tried to focus on the following functionality as goals:

• A game board that controls efficient painting and game flow
  
  
• A basis for defining game characters supported by the game board
  
  
• Built-in support for common interactions between characters

A basic litmus test for success would be whether someone (like you) could use this framework to build a classic 2-D video game, like Frogger, by only writing the new code managing interactions between the characters specific to the game.

The remainder of the article will highlight a few of the key concepts I built into the framework.

Sprites

The Sprite class provides the basis for all characters in the game. In Pac-Man, this includes ghosts, dots, walls, and Pac-Man himself. The class is abstract, forcing all derived classes to implement two methods:

public abstract void Update();
public abstract void Draw(Graphics gameSurface);

Not surprisingly, they expect the derived class to update their state and draw themselves to the game board, respectively. Methods are provided for getting the instance of the GameBoard the Sprite has been added to, and detecting collisions between one Sprite and a list of other Sprites. In addition, a Sprite instance is expected to manage several state properties:

• ID—must be unique per GameBoard
  
  
• Bounds—a rectangle that defines the perimeter of the object. A future version could use a Region or other construct to more accurately track the area taken up by the Sprite. This property is used for collision detection and drawing.
  
  
• Invalid—a boolean that tells the GameBoard whether a Sprite needs to be redrawn
  
  
• Visible—a boolean that determines whether a Sprite should be drawn or not

GameBoard

The GameBoard class controls the flow of the game. It derives from System.Windows.Forms.Form, and like the Sprite class, it is not creatable. This inheritance structure allows the developer to handle any Form events needed for his game. Below is an example in which the Pac-Man application's GameBoard class listens to user input by overriding the OnKeyDown method.

protected override void OnKeyDown(KeyEventArgs e)
{
    _KeyPressed = true;
    base.OnKeyDown (e);
    if(e.KeyCode == Keys.Right || e.KeyCode == Keys.Left || e.KeyCode == Keys.Up || e.KeyCode == Keys.Down)
    {
        switch(e.KeyCode)
        {
            case Keys.Right:
            {
                _Pacman.MovementDirection = MovementDirections.Right;
                break;
            }
            case Keys.Left:
            {
                _Pacman.MovementDirection = MovementDirections.Left;
                break;
            }
            case Keys.Down:
            {
                _Pacman.MovementDirection = MovementDirections.Down;
                break;
            }
            case Keys.Up:
            {
                _Pacman.MovementDirection = MovementDirections.Up;
                break;
            }
        }
    }
}

Each game application needs to create its own game board class that derives from GameBoard. All character Sprites should then be created and added to the GameBoard's list of Sprites. Then, after the GameBoard loads, a Timer is used to call the Update and Draw methods on Sprites as mentioned above.

Painting

So how exactly does the drawing of the Sprites work? From a Sprite's perspective, it's simple. All a Sprite needs to know is how to draw itself. A Dot Sprite for example, simply draws a rectangle to the game board graphics object.

public override void Draw(Graphics gameBoard)
{
    if(!_IsEaten)
    {
        gameBoard.FillRectangle(new SolidBrush(Color.LightBlue), _Bounds);
    }
}

The Draw methods for Pac-Man and Ghost Sprites are more complicated and draw one of a series of bitmap images to the game board. The changing images, along with updated Bounds create animation. When drawn, a color is chosen (magenta in the Figure 3 below) to indicate portions of the image that should be treated as transparent.

Figure 3: Ghost Sprite image enlarged

The GameBoard class makes the screen painting as efficient as possible. It overrides the Form OnPaint and OnPaintBackground methods since it controls all the updating of the screen. The OnPaint method makes sure that only the portions of the screen that have changed get repainted. In addition, it uses a back buffer to minimize any flicker.

protected override void OnPaint(PaintEventArgs e)
{
    if(_BackBuffer == null) 
    { 
        return;
    }

    Graphics g = Graphics.FromImage(_BackBuffer);

    ArrayList changedSprites = new ArrayList();
    // blank out any invalid Sprites previous position in the back buffer
    foreach(Sprite sprite in _SpritesByZIndex)
    {
        if(sprite.Invalid)
        {
            g.FillRectangle(new SolidBrush(_BackgroundColor), sprite.PreviousBounds);
            changedSprites.Add(sprite);
        }
    }

    // now draw them to the back buffer
    foreach(Sprite sprite in changedSprites)
    {
        if(sprite.Visible)
        {
            sprite.Draw(g);
        }
    }

    if(_FullRepaint)
    {
        // draw the entire back buffer 
        e.Graphics.DrawImage(_BackBuffer, 0, 0);
        _FullRepaint = false;

        foreach(Sprite sprite in _SpritesByZIndex)
        {
            // reset Invalid flag
            sprite.Invalid = false;
        }
    }
    else
    {
        // only draw the parts that have changed
        foreach(Sprite sprite in changedSprites)
        {
            e.Graphics.DrawImage(_BackBuffer, sprite.Bounds, sprite.Bounds, GraphicsUnit.Pixel);
            e.Graphics.DrawImage(_BackBuffer, sprite.PreviousBounds, sprite.PreviousBounds, GraphicsUnit.Pixel);

            // reset Invalid flag
            sprite.Invalid = false;
        }
    }
}

Mobile Development Considerations

As I've said, from a coding perspective, developing mobile applications in .NET is very similar to building standard WinForm apps. However, this little project did bring to light a number of things you have to keep in mind with mobile applications, most centering around the word "small".

The most obvious consideration is that the device has a small screen. That means you have to design a user interface that is easy to use within the minimal real estate. That tends to translate into keeping things simple. One other screen consideration is that from phone to phone, screen size and resolution may change. I didn't address that with my first cut of Pac-Man, but it's on the list. In my testing I targeted a lower resolution that would work on my phone.

With any type of application, but especially with a game, you have to think about how a user will interact with the small keys of his phone, possibly using no more that a thumb! I consciously made controlling Pac-Man a little different than the typical arcade feel to make up for some of the clumsiness of using the phone's directional pad. That change has received mixed reviews from the people who have tried it out. That's what testing is for, though, right?

The other "small" consideration is the phone's horsepower. While a Smartphone blows away my old Tandy 64K Color Computer, the computer I started playing games on, I definitely found myself needing to tweak the code for performance. I was sure ahead of time that highly efficient painting logic would be necessary. I was surprised, however, to find that the code that prepares the possible travel paths for ghosts takes a considerable amount of time to crunch. For that reason, I made sure that this logic is only processed the first time the splash screen is displayed. It is then cached for later reuse.

Conclusion

So there it is...well, the first version, at least. I plan to periodically update the game making it more efficient and more fun—smarter ghosts for starters. Maybe I'll even eat my own dog food and try building Frogger to see if that little framework I put together holds water. I really want to add a feature to report high scores to a web site. What's a game with out a little healthy competition, right?

I recently started a blog about this and other topics related to software development on my company's blog site. The code and compiled game for the all platforms will be available there, too. Feel free to check for updates and post any feedback you may have.