Coding4Fun : card and board games

Building Multiplayer Texas Holdem Poker For The Zune

Coding4Fun — Tue, 05 May 2009 22:06:00 GMT

Have you ever been interested in creating a game that harnesses XNA’s powerful network library to create multiplayer experiences for the Zune device?

The Zune firmware version 3.1 brought us a professionally built incarnation of Texas Holdem that supports network play. Understanding how to send and receive data with the Zune can be a little daunting at first, but once you understand the pattern, it’s easy.

To build out the entire game, you probably need about a week, but you can build some simpler examples in far less time.

This is an earlier project from before the release of my Zune game development book. Accordingly, some of the code samples you see in this article may be inconsistent with what you find in the download. The code in the article is the “correct” way to do things. The code in the download is still a work in progress.

Source Code: Download
Difficulty Intermediate|Advanced
Time Required: 40 hours
Hardware: 2x Zune devices ($170 ea)
Software Needed: Visual C# Express, XNA Game Studio 3.0

The Workflow

Developing multiplayer games for the Zune is interesting because you have to deploy to each device individually. Once you have a build that works for you, it’s helpful to run-deploy (Control+F5) to one device, leave it running there, and then plug in the other Zune and debug-deploy (F5) to it. This way you have one debuggable instance of the game running. Make sure to set the appropriate Zune device as the default in the XNA Game Studio Device Center (accessible from the Tools menu).

Starting A Network Session

Because the Zunes connect over an ad-hoc, peer-to-peer connection rather than through an access point, you will have to designate one Zune as the host device. The host is usually determined to be the one that creates a new game. Therefore, all Zunes that join the host’s network session are simply peers. The difference between the host and the peers is that the host usually maintains the game state on top of executing the game as well, because the game data has to be centralized somewhere. Keep that in mind, because if one Zune is doing substantially more processing, it can lag behind and mess up your network session. Also, remember that all Zunes are running the exact same copy of the game, so the game must support both host and peer scenarios.

Create / Join / Lobby Model

Most peer-to-peer connected games allow a user to create or join a game. After doing so, the player is funneled into an area called the Lobby where they can specify their readiness. When all players are ready, the host can start the game. Some of this functionality is provided directly by the XNA Framework’s Net and GamerServices libraries.

I normally create three separate screens based on the Network Game State Management sample from the Creators Club website. The first is the Create screen, which looks exactly like a lobby. It starts up a network session and waits for players to join and become ready. The code to create a network session looks like this (note that I have employed some abstraction to make my code a little more cohesive):

public void CreateZuneSession(int maxNetworkPlayers)
{
    KillSession();

    try
    {
        Session = NetworkSession.Create(NetworkSessionType.SystemLink, 1,      
            maxNetworkPlayers); 
        Me = Session.LocalGamers[0];
    }
    catch (NetworkNotAvailableException)
    {
        throw new NetworkNotAvailableException("Zune wireless is not 
            enabled.");
    }
    catch (NetworkException ne)
    {
        throw ne;
    }

    if (Session == null)
        throw new NetworkException("The network session could not be 
            created.");
}

All Zune network sessions are of the type SystemLink, much like LAN-networked Xbox consoles. The ‘1’ parameter specifies the number of local players – of course, on a Zune, there can only be one.

This line of code sets the Session property to a newly created network session. The Join screen, running on another Zune, will find this session asynchronously as an available network session and attempt to join it. The first step is to enumerate available network sessions:

/// <summary>
/// Asynchronous: Begins to discover network sessions.
/// </summary>
public void BeginGetAvailableSessions()
{
    // Destroy any existing connections
    KillSession();

    NetworkSession.BeginFind(NetworkSessionType.SystemLink, 1, null, new 
        AsyncCallback(SessionsFoundCallback), null);
}

This code looks for SystemLink sessions and calls the callback method SessionsFoundCallback when the operation completes (successfully or unsuccessfully). If sessions are found, an event is fired. Other screens can subscribe to this event and transition to other screens or do other processing with the network session.

/// <summary>
/// Called when network sessions are found.
/// </summary>
/// <param name="result"></param>
public void SessionsFoundCallback(IAsyncResult result)
{
    AvailableNetworkSessionCollection availableSessions = null;
    availableSessions = NetworkSession.EndFind(result);

    if (NetworkSessionsFound != null)
        NetworkSessionsFound(availableSessions);
}

When all players are ready and the host presses the middle button, the network session’s StartGame() method is called, which will cause all connected peers to receive a GameStarted event. This loads up the playing screen.

if (allPlayersReady && atLeastTwoPlayers)
{
    if (ScreenManager.Network.Session != null)
        ScreenManager.Network.Session.StartGame();
}

That’s basically how to connect up two Zunes in a network session. See my book for a much more detailed explanation.

Dealing With Cards

As Poker is a card game, you might want to develop a testable, standalone library that you can use not only to house your objects, but also to write out all the intense logic required for a game like poker. The task of determining what a player’s best hand is out of seven cards (and whether it beats another player’s hand) is more in-depth than you might expect.

An easy way to go about this is to create a Zune game library. I called mine CardLib. CardLib has objects such as these:

Card which has a suit, a value, some comparers and some utility methods)
Deck, which has a collection of cards and methods like Shuffle, ResetDeck, etc.
Dealer, which has a deck, a list of the five community cards, and methods like Shuffle, DealCard, Burn, DealFlop, DealTurn, etc.
HoldemHand, which contains all of the logic for determining what a hand is (always 7 cards)
BestHand, which takes a HoldemHand and determines what the best possible hand is within that hand

Shuffling Cards

Shuffling cards is surprisingly easy. I use the Knuth-Fisher-Yates shuffling algorithm, which takes every card in the deck and randomly swaps it with another.

/// <summary>
/// Knuth-Fisher-Yates shuffling algorithm:
/// http://www.codinghorror.com/blog/archives/001015.html
/// </summary>
public void Shuffle()
{
    Random rand = new Random();
    for (int cardIndex = _cards.Count - 1; cardIndex > 0; cardIndex--)
    {
        int randomIndex = rand.Next(cardIndex + 1);
        SwapCardsByIndex(cardIndex, randomIndex);
    }
    _dealIndex = 0;
}

Poker Logic

An example method you’ll see in this library is this snippet to check if the hand is a royal flush:

public bool IsRoyalFlush(out List<Card> winningCards)
{
    List<Card> straightFlushCards;

    if (IsStraightFlush(out straightFlushCards))
    {                
        // Check to make sure the straight flush cards are: 10 J Q K A
        straightFlushCards.Sort();

        if (straightFlushCards[0].Value == 10 &&
            straightFlushCards[1].Value == Card.Jack &&
            straightFlushCards[2].Value == Card.Queen &&
            straightFlushCards[3].Value == Card.King &&
            straightFlushCards[4].Value == Card.Ace)
        {
            winningCards = straightFlushCards;
            return true;
        }

        else
        {
            winningCards = null;
            return false;
        }
    }
    else
    {
        winningCards = null;
        return false;
    }
}

There is a ton of similar and even more disgusting logic to peruse in the HoldemHand.cs file in the region entitled “Poker Logic Fun Times.” This logic covers every possible poker hand and could probably be refactored to be way more elegant.

When it comes time to evaluate the winner, each player’s best hand is determined and they are evaluated against each other to determine the winner. This code returns a list of WinnerInfo objects, which returns the player info and a list of the cards they won with.

public List<WinnerInfo> DetermineWinners()
{
    BestHand overallBestHand = null;
    HoldemPlayer winner = null;

    List<WinnerInfo> winners = new List<WinnerInfo>();

    foreach (HoldemPlayer player in _players)
    {
        if (player.Status != PlayerStatus.Folded)
        {
            HoldemHand tempHand = new HoldemHand(player.Pocket, _communityCards);
            BestHand bestHand = tempHand.GetBestHand();

            if (overallBestHand == null) // if there is no best hand yet
            {
                overallBestHand = bestHand;
                winner = player;
                winners.Add(new WinnerInfo(overallBestHand, winner, Me));
            }
            else
            {
                // if this hand beats the current best hand
                if (BestHand.Beats(bestHand, overallBestHand))
                {
                    winners.Clear();
                    overallBestHand = bestHand;
                    winner = player;
                    winners.Add(new WinnerInfo(overallBestHand, winner, Me));
                }
                else
                {
                    if (BestHand.IsEquivalentTo(bestHand, overallBestHand))
                    {
                        winners.Add(new WinnerInfo(bestHand, player, Me));
                    }
                }
            }
        }
    }

    _winners = winners;
    return winners;
}

Drawing Cards On The Screen

Rather than have 52 different sprites that represent each possible card, I just made my own sheet of Zune-sized playing cards. Horizontally, they are ordered by value (1-13) and vertically they are ordered by suit (both alphabetically and corresponding to the numeric value of the Suit enumeration in the project, 1-4).

When a specific card is requested to be drawn, a formula is used to calculate the source rectangle from this larger image. This is very similar to how fonts worked before spritefonts were introduced into XNA. This allows us to strip out the graphic of a specific card and draw it onscreen at some other location.

private void DrawCard(Card card, Vector2 position)
{
    if (card != Card.Undefined && card.Suit != Suit.Unassigned)
        ScreenManager.SpriteBatch.Draw(_texDeck, position, GetCardSourceRect(card), Color.White);
}

private Rectangle GetCardSourceRect(Card card)
{
    if (card.Suit == Suit.Unassigned)
        throw new ArgumentException("Unassigned cards cannot be drawn.");

    int cardColumn = card.Value - 1;
    int cardRow = (int)card.Suit - 1;

    int x = cardColumn * MainScreenElements.CARD_WIDTH;
    int y = cardRow * MainScreenElements.CARD_HEIGHT;

    return new Rectangle(x, y, MainScreenElements.CARD_WIDTH, MainScreenElements.CARD_HEIGHT);
}

Managing Network Data

One thing that increases the complexity of this game (in no small way) is the management of network data. First of all, the host’s actions are a superset of the peer’s actions (a host is also a peer, but it also has to manage the game and network state). For example, when a peer decides to bet, it has to send a message to the host saying “I would like to bet,” and then the host will process that message and relay it to the other peers. The host is also responsible for managing whose turn it is and determining who the winner is. Theoretically, you could do a lot of this with every peer acting equally but it feels safer to me to have the host responsible for important activities like dealing cards. In fact, the host has to be the only one who can deal cards, because if each client maintained its own deck, it would be randomized for every peer when the deck is shuffled.

How Data Is Sent And Received

I will usually create a static class called NetworkMessageSender that is responsible for sending various messages. I keep an enumeration of type byte that holds the possible network messages.

I always send the byte indicating the message type first, so that when the peer receives a byte, it knows how to respond. For example, if the peer receives a CardDealt message, it can pop off a string and a card from the incoming packets. If the card is not intended for the peer, it can simply discard the message.

Data you want to send is written to a packet writer object. When the data is ready to be sent, you call the SendData method of the LocalGamer object. Depending on how important packet receipt is, you can specify the type of transmission. I use ReliableInOrder during poker because network data is exchanged relatively infrequently. Although there is only one local network gamer, you can use a foreach loop to ensure this code will work on other platforms.

private static void SendData()
{
    foreach (LocalNetworkGamer gamer in NetworkSessionManager.Session.LocalGamers)
        gamer.SendData(NetworkSessionManager.PacketWriter, SendDataOptions.ReliableInOrder);
}

Specific chunks of data are then sent using various static methods. Each piece of information is written sequentially. The card is serialized into a string format before being sent. The following chunk of code is used to send a card to a player.

public static void DealCards(HoldemPlayer player)
{
    NetworkSessionManager.PacketWriter.Write((byte)NetworkMessageType.Deal);
    NetworkSessionManager.PacketWriter.Write(player.Name);
    NetworkSessionManager.PacketWriter.Write(player.Pocket.Card1.Serialize());
    NetworkSessionManager.PacketWriter.Write(player.Pocket.Card2.Serialize());
    SendData();
}

On the other side of that, whenever the screen updates, the game is constantly checking for new network data. The following code is part of a method that is called from the game screen’s Update loop.

private void UpdateNetworkSession()
{
    NetworkSessionManager.Update();

    foreach (LocalNetworkGamer localGamer in 
        NetworkSessionManager.Session.LocalGamers)
    {
        while (localGamer.IsDataAvailable)
        {
            NetworkGamer sender;
            localGamer.ReceiveData(NetworkSessionManager.PacketReader, 
                out sender);

            // Interpret the first piece of information, the message.
            NetworkMessageType message = (NetworkMessageType)NetworkSessionManager.PacketReader.ReadByte();

            // Determine what to read and what to do based on this message type
            switch (message)
            {
                // major snippage
                case NetworkMessageType.Deal: // Happens when a card is dealt
                {
                    string playerName = NetworkSessionManager.PacketReader.ReadString();
                    string card1 = NetworkSessionManager.PacketReader.ReadString();
                    string card2 = NetworkSessionManager.PacketReader.ReadString();

                 _gameplayManager.Players[playerName].Pocket.Set(PlayerPocket.FIRST_CARD_INDEX, new 
                    Card(card1));
                 _gameplayManager.Players[playerName].Pocket.Set(PlayerPocket.SECOND_CARD_INDEX, new 
                    Card(card2));
                }
                break;
            }
        }
    }
}

There is a whole bunch of similar code that underlies how the game executes. When a message needs to be sent, the NetworkMessageSender class is used. To determine what happens when a message is received, we look at that ginormous switch statement that gets called in the screen update loop.

Remember that the host is also a peer and it will receive the very same messages it sends (unless you specify otherwise). Be careful not to double-process messages if they are sent by the host. In some cases you will need to check that the current device is or is not the host. In the sample download, this is achieved just by checking a Boolean value that is set early on in the game.

Conclusion

Building Poker for the Zune, from the ground up, is no small feat! Networked Zune games are far simpler when you have a much more limited set of possible data and messages that could be sent. For example, networked Pong, Battleship or Tetris would be pretty easy compared to poker. Turn-based games on the Zune also provide an interesting challenge in terms of what happens when a Zune drops from the network session.

This is just a small dip into networked Zune game development. For a deep dive, check out my book, Zune Game Development using XNA 3.0, also available on Apress.com as an eBook. The final chapter is a sprawling 120 pages covering how to build Crazy Eights for the Zune from the ground up.

About The Author

Dan Waters is an Academic Developer Evangelist at Microsoft, based in Tampa, FL. When he’s not out showing the latest and greatest MS technology to students and faculty, he’s spending time with his wife and young daughter or rocking out on one of his (far too numerous) guitars. Follow Dan on Twitter or check out his blog.

Your Code Sunk My Battleship!

Coding4Fun — Sun, 24 Aug 2008 21:00:14 GMT

Clarity Battleship is a multi-player game in which players code the "artificial intelligence" needed to command their fleet to victory on the high seas. The game is built using WPF and WCF.
Bryan Dougherty Bryan's Blog Difficulty: Intermediate Time Required: 1-3 hours to create your own fleet Cost: Free Software: Visual Basic or Visual C# Express Editions Hardware: Download: Download

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.

YeahTrivia: Creating a Trivia Server/Client with WPF and WCF

Coding4Fun — Tue, 30 Oct 2007 03:01:00 GMT

In this article I'll take you along for the ride as I attack the learning curve required to create a fun, interactive application using both the Microsoft Windows Presentation Foundation (WPF) and the Windows Communication Foundation (WCF). Afterwards, you'll have a flexible trivia client/server game ready to play by yourself or against friends, coworkers and your local know-it-all. And in honor of Halloween, I've included three games of horror movie trivia.

Steve Holstad

The Bright Lights

Difficulty: Advanced

Time Required: 6-10 hours

Cost: Free

Software: Visual Studio Express, 2005, 2008 Beta 2 Microsoft .NET Framework 3.0

Hardware:

Download: Download Source

What can YeahTrivia do for me?

Glad you asked. This project started when I decided I wanted to dive headfirst into learning WPF and WCF, without hacking through countless Hello World examples. And I wanted something fun that I could improve over time as my skills developed in these new technologies. In this article I'll take you along for the ride as I attack the learning curve required to create a fun, interactive application using both the Microsoft Windows Presentation Foundation (WPF) and the Windows Communication Foundation (WCF). Afterwards, you'll have a flexible trivia client/server game ready to play by yourself or against friends, coworkers and your local know-it-all. And in honor of Halloween, I've included three games of horror movie trivia.

In case you were wondering, the "YeahTrivia" name honors my new bride & her favorite prefix. Think of it as YeeeeaaaaahhTrivia!

Basic Setup

This demo project was built using Visual Studio 2008 Beta 2, and is based on the Microsoft .NET Framework version 3.0. The game is fed by a small windows app that acts as a game server, providing game selection, user registration, question loading, response times, chat messaging and scorekeeping. The server loads a game by reading a predefined XML format, which we will look at a bit later. This dynamic load lets anyone create their own flavor of trivia game, with any number of questions.

The server app exposes one WCF endpoint, a wsDualHttpBinding channel that supports duplex (two-way) communication between the server and any number of game clients. Clients attach themselves to this endpoint and provide a callback address to the server. The server saves an instance of this callback channel and uses each client's instance to contact the clients en masse during general game flow. Enough talk, here's how to build one yourself.

Trivia Common and WCF Service Interfaces

The TriviaCommon project provides both the server and client projects access to shared objects. To keep things simple the Common project only contains two classes:

Constants.cs defines the AnswerItem enumeration, which gives easy access to the five answer options (None, A, B, C, D), and the QuestionItem struct. This structure is delivered to the client and contains question text, answer text, and the correct answer object of type AnswerItem. Notice that objects being directly passed over the wire need to be marked with the [DataContract] attribute.

The second class, Interfaces.cs is where our WCF fun begins. Take a look:

C#:

using System;
using System.Collections.Generic;
using System.ServiceModel;
using System.Text;

namespace Trivia.Common
{
    #region Interfaces

    #region Service Interface

    /// <summary>
    /// Interface that defines Trivia service contract.
    /// </summary>
    [ServiceContract(CallbackContract = typeof(ITriviaCallback))]
    public interface ITrivia
    {
        [OperationContract(IsOneWay = true)]
        void RegisterUser(string userName);

        [OperationContract(IsOneWay = true)]
        void AcceptAnswer(string userName, string answerValue);

        [OperationContract(IsOneWay = true)]
        void ChatPublish(string userName, string message);
    }

    #endregion Service Interface

    #region Client Callback Interface

    /// <summary>
    /// Interface that defines Trivia client callback contract.
    /// </summary>
    public interface ITriviaCallback
    {        
        [OperationContract(IsOneWay = true)]
        void OnGameStart(int questionCount);

        [OperationContract(IsOneWay = true)]
        void OnGameEnd();

        [OperationContract(IsOneWay = true)]
        void OnUserRegistered(string userName);

        [OperationContract(IsOneWay = true)]
        void OnPublishChat(string userName, string chatMessage);

        [OperationContract(IsOneWay = true)]
        void OnQuestionLoad(int questionIndex, QuestionItem questionItem);

        [OperationContract(IsOneWay = true)]
        void OnQuestionEnd();

        [OperationContract(IsOneWay = true)]
        void OnQuestionStatusUpdate(Int64 questionTimeRemaining);

        [OperationContract(IsOneWay = true)]
        void OnScoreboardUpdate(Dictionary<string, Int64> scoreboard);

        [OperationContract(IsOneWay = true)]
        void OnGameServerStopped();
    }

    #endregion Client Callback Interface

    #endregion Interfaces
}

VB:

Imports System
Imports System.Collections.Generic
Imports System.ServiceModel
Imports System.Text

Namespace Trivia.Common

#Region "Interfaces"

#Region "Service Interface"
    
    ''' <summary>
    ''' Interface that defines Trivia service contract.
    ''' </summary>
    <ServiceContract(CallbackContract:=GetType(ITriviaCallback))> _
    Public Interface ITrivia
        <OperationContract(IsOneWay:=True)> _
        Sub RegisterUser(ByVal userName As String)

        <OperationContract(IsOneWay:=True)> _
        Sub AcceptAnswer(ByVal userName As String, ByVal answerValue As String)

        <OperationContract(IsOneWay:=True)> _
        Sub ChatPublish(ByVal userName As String, ByVal message As String)
    End Interface
        
#End Region

#Region "Client Callback Interface"

    ''' <summary>
    ''' Interface that defines Trivia client callback contract.
    ''' </summary>
    ''' <remarks></remarks>
    Public Interface ITriviaCallback
        <OperationContract(IsOneWay:=True)> _
      Sub OnGameStart(ByVal questionCount As Integer)

        <OperationContract(IsOneWay:=True)> _
        Sub OnGameEnd()

        <OperationContract(IsOneWay:=True)> _
        Sub OnUserRegistered(ByVal userName As String)

        <OperationContract(IsOneWay:=True)> _
        Sub OnPublishChat(ByVal userName As String, ByVal chatMessage As String)

        <OperationContract(IsOneWay:=True)> _
        Sub OnQuestionLoad(ByVal questionIndex As Integer, ByVal questionItem As QuestionItem)

        <OperationContract(IsOneWay:=True)> _
        Sub OnQuestionEnd()

        <OperationContract(IsOneWay:=True)> _
        Sub OnQuestionStatusUpdate(ByVal questionTimeRemaining As Long)

        <OperationContract(IsOneWay:=True)> _
        Sub OnScoreboardUpdate(ByVal scoreboard As Dictionary(Of String, Long))

        <OperationContract(IsOneWay:=True)> _
        Sub OnGameServerStopped()

    End Interface

#End Region

#End Region

End Namespace

A few items of interest here. Notice we're importing the System.ServiceModel namespace. This is the key assembly when using WCF, so don't forget to add a reference to your project. The first interface, ITrivia, defines the operations the server is required to implement, which handle basic user actions: Register a team, accept an answer and accept a chat message. Easy.

The second interface, cleverly named ITriviaCallback, lays out the callback contract a client must fulfill in order to play nicely with our server. The operations listed here describe events the server will publish. These aren't actual events, but the naming convention "OnX..." helps you remember that these are server published activities.

Notice that the [OperationContract] attribute notifies WCF that each method is part of a service contract. The IsOneWay flag gives us "fire-and-forget" behavior (the app shouldn't wait around for a response). So now that the common objects are ready, let's move on to...

Building the Trivia Server

The YeahTrivia Server is a simple utility app, but don't let the plain looks fool you; I thought about calling this the BrainStumper Pumper, but this is a family site. This app lets a user (anyone acting as game admin) start the service, select the desired game, await team registrations, and then start the game. If this were to become a larger scale project, I would make this an IIS hosted service that manages multiple games and provides more autonomy. Until those sports bar royalty checks start rolling in, however, a utility app will do just fine.

The only form, GameServerDashboard, simply provides user interaction with the GameServer class. On startup, the form inits an instance of GameServer and tells it to start the service. It also loads all trivia question sets from the Games directory, and displays them in the list.

GameServer is the brain behind YeahTrivia. The attributes below set up the GameServer for action:

C#:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant
        ,InstanceContextMode = InstanceContextMode.Single)]
    public class GameServer : ITrivia

VB:

<ServiceBehavior(ConcurrencyMode:=ConcurrencyMode.Reentrant, InstanceContextMode:=InstanceContextMode.Single)> _
    Public Class GameServer
        Implements ITrivia

ConcurrencyMode.Reentrant prevents deadlocks between the apps by stating that while this service is single-threaded, callbacks are allowed to invoke new operations.

InstanceContextMode.Single sets the service as a singleton, so that all messages are delivered to the same object instance.

These are advanced topics if you're new to WCF, so I'll include some links at the end that helped clarify some of this for me. Let's keep moving forward by looking at a few activities of the game server:

Start the Service: Passes in the configured base address as a Uri, inits and opens a new ServiceHost.

C#:

public void StartService()
{
   // Set base address and open service host
   Uri baseAddress = new Uri(ConfigurationManager.AppSettings[CONFIG_KEY_BASEURI]);
   _serviceHost = new ServiceHost(new GameServer(), baseAddress);
   _serviceHost.Open();
}

VB:

  Public Sub StartService()
     'Set base address and open service host
     Dim baseAddress As New Uri(ConfigurationManager.AppSettings(CONFIG_KEY_BASEURI))
     _serviceHost = New ServiceHost(New GameServer(), baseAddress)
     _serviceHost.Open()
  End Sub

Register a new team: Saves off the callback, adds it to the callback collection and scoreboard containers, notifies the user of a successful registration, and notifies all game clients of the new team.

C#:

 public void RegisterUser(string userName)
 {
     _currentCallback = OperationContext.Current.GetCallbackChannel<ITriviaCallback>();

     // Store callback
     if (!_callbacks.ContainsKey(userName))
     {
         _callbacks.Add(userName, _currentCallback);
         _scoreboard.Add(userName, 0);

         // Notify user of registration
         _currentCallback.OnUserRegistered(userName);

         // Notify clients of new user
         foreach (string userKey in _callbacks.Keys)
         {
            _currentCallback = _callbacks[userKey];
            _currentCallback.OnPublishChat(GAME_USERKEY, string.Format(FORMAT_USER_REGISTERED, userName));
         }                
     }
     else
     {
         // User already registered, throw exception
         throw new Exception(ERROR_USER_ALREADY_EXISTS);
     }
 }

VB:

Public Sub RegisterUser(ByVal userName As String) Implements ITrivia.RegisterUser
   _currentCallback = OperationContext.Current.GetCallbackChannel(Of ITriviaCallback)()

   'Store callback
   If Not _callbacks.ContainsKey(userName) Then
      _callbacks.Add(userName, _currentCallback)
      _scoreboard.Add(userName, 0)

      'Notify user of registration
      _currentCallback.OnUserRegistered(userName)

      'Notify clients of new user
      For Each userKey As String In _callbacks.Keys
         _currentCallback = _callbacks(userKey)
         _currentCallback.OnPublishChat(GAME_USERKEY, String.Format(FORMAT_USER_REGISTERED, userName))
      Next
   Else
      'User already registered, throw exception
      Throw New Exception(ERROR_USER_ALREADY_EXISTS)
   End If
End Sub

You can start to see how the server is able to handle incoming calls and process them back to the clients using the duplex channel. I'll leave the rest of the server actions for you to examine on your own.

Building the Game Client (WCF)

Address, Binding, Contract. These are the ABC's of WCF. The client's app.config file handles connecting to the service and specifying the channel and contract used to interact with it. Examine the client portion of the client .config:

<client>
   <endpoint address="http://localhost:8088/Trivia" binding="wsDualHttpBinding"
      bindingConfiguration="WSDualHttpBinding_ITrivia" contract="Trivia.Common.ITrivia"
      name="WSDualHttpBinding_ITrivia">
   </endpoint>
</client>

The address points to the exposed service endpoint. The binding sets the channel as "wsDualHttpBinding" (our http duplex channel). The bindingConfiguration attribute is an optional pointer to another group of configurations for the binding, and finally, the contract sets the interface with which our client will be interacting.

Next it's time to generate a proxy class. Memorize this: Svcutil.exe is your friend. The client needs a proxy class that it can use to interact with the service model. The utility is a bit tricky at first, because of the wealth of optional flags, but stick with it, it's better than coding the proxy class by hand! You can generate your client code by starting the service and running a command line similar to this:

svcutil /language:cs /out:ServerProxy.cs http://localhost:8088/Trivia

Add the generated class to the client project and you can begin to interact with the service. The svcutil is available as part of the Windows SDK. Check out the referenced site below for more information on this handy utility.

Building the Game Client (WPF)

Building the WPF portion of the client app was really a learning experience, and it will be the priority for me to improve in a later version. Learning to program in XAML markup can seem daunting, and it requires a large paradigm shift on your part in order to grasp the new concepts. Microsoft Expression is powerful tool for XAML work, but this time I coded all of the XAML by hand in order to fully see what was taking place inside.

A deep discussion of WPF is beyond the scope of this article, but take a look at the example code to get an idea of the layout. An excellent book to start with is WPF Unleashed by Adam Nathan. An easy read (for a programming book), and solid examples to get you rolling.

I've set up the client using a instance of the Window class, which is shown below:

<Window x:Class="Trivia.Client.GameClient"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="YeahTrivia" MinHeight="620" MinWidth="620" 
    WindowStartupLocation="CenterScreen" WindowState="Normal"  Style="{DynamicResource MainWindowStyle}"
    Background="{DynamicResource MainWindowBackgroundBrush}">

The window class sets up the outermost container of the app, and includes two default namespaces. I've also set a few other properties here: a min height and width, window startup location & state, and two styling attributes set by dynamic resources.

Resources are a great way to further separate form & function, allowing a programmer to handle the behavior of an app, while a designer can work simultaneously on the look, all without stepping on too many toes. As a 2.0 task for this project, I would remove all inline styling and move them into resource dictionaries. A dictionary contains styles and control templates (a skin) that can be loaded & switched at runtime.

ResourceDictionaries are linked to your XAML in the App.Xaml file. Once you've set up the reference, the example above show how to reference the current dictionary: The Background and Style properties are set as dynamic resources by naming the Keys specified in the ResourceDictionary (DefaultResources.xaml):

<LinearGradientBrush x:Key="MainWindowBackgroundBrush" StartPoint=".45,.45" EndPoint=".55,.55" SpreadMethod="Reflect">
   <GradientStop Offset="0" Color="DodgerBlue"/>
   <GradientStop Offset=".8" Color="DarkSlateBlue"/>
</LinearGradientBrush>

<Style TargetType="{x:Type Window}" x:Key="MainWindowStyle">
   <Setter Property="FontFamily" Value="Trebuchet MS"/>
</Style>

Not quite as easy as CSS, but for a Forms project, it's a nice feature. The sample ResourceDictionary includes a button control template for all of my buttons, based on Rob Eisenberg's excellent article (link below).

One other interesting feature to point out: Take a look at the code-behind class MarshalToUIThread method, which accepts a SendOrPostCallback parameter. This is where the client is transferring actions from the sync thread back to the UI thread. In each interface method implementation (OnX..), you can see how I wrap any UI-directed code and assign it to the postCallback field. Passing this to the MarshalToUIThread method simply issues a SynchronizationContext.Post call, and the UI thread executes as expected.

Creating a New Trivia Game (XML)

New trivia games can be added at any time using the simple XML format shown here. After installing the server application, simply drop the new .XML file into the Games directory ([Server Install Location]\Yeah Trivia Server\Games). This demo comes pre-loaded with Geek Trivia, and a special Halloween Trivia version in case you're feeling festive.

<TriviaQuestionDataSet xmlns="http://tempuri.org/TriviaQuestionDataSet.xsd">
  <TriviaQuestion>
    <QuestionText>Name the highest grossing Monty Python creation.</QuestionText>
    <AnswerTextA>A) Holy Grail</AnswerTextA>
    <AnswerTextB>B) The Life of Brian</AnswerTextB>
    <AnswerTextC>C) Shrubbery</AnswerTextC>
    <AnswerTextD>D) The Meaning of Life</AnswerTextD>
    <CorrectAnswerKey>A</CorrectAnswerKey>
  </TriviaQuestion>
  <TriviaQuestion>
    <QuestionText>Ferris Bueller's best friend was _________.</QuestionText>
    <AnswerTextA>A) Sloane Peterson</AnswerTextA>
    <AnswerTextB>B) Edward R. Rooney</AnswerTextB>
    <AnswerTextC>C) Charlie Sheen</AnswerTextC>
    <AnswerTextD>D) Cameron Frye</AnswerTextD>
    <CorrectAnswerKey>D</CorrectAnswerKey>
  </TriviaQuestion>
</TriviaQuestionDataSet>

It's Time to Play YeahTrivia

Install both the Server and Client applications. First, fire up the server, and then start your game client(s). Once everyone has registered a team, select your game and hit "Start Game". You're off...

Game Over

So there you have it. We've seen how WCF manages communication between objects, extracting complicated service protocols away from your code. And just a small subset of the WPF functionality has shown us how quickly a rich, XAML-based UI can come together. And maybe, just maybe, you've learned why a CD is 74 minutes long... but I'm not telling.

I challenge you to improve on this initial version of YeahTrivia: Crack open the XAML and add animations, images, video, music & more. Create a self-maintaining server to run multiple games at once. Add a High Score storage system. Extend the WCF settings to enable other communication channels. Add a new skin. Create new question files to share with us. Whatever you do, have fun and go nuts. YeahCoding4Fun.

Download source files

Download compiled demo (C# and VB)

About The Author

Steve Holstad works as a software consultant for Clarity Consulting in Chicago. He blogs at The Bright Lights, and is available via email at sholstad@claritycon.com

References

wcf.netfx3.com/
wpf.netfx3.com/
Generating a client proxy class
ConcurrencyMode
SvcUtil.exe Tutorial
Rob Eisenberg's WPF control template

Special thanks to Bryan Dougherty for the WCF jumpstart, Kevin Marshall for the Halloween Trivia and Jay Garmon, creator of TechRepublic's Geek Trivia.

Designing FreeCell using Expression and Visual Studio Toolsets

Coding4Fun — Tue, 31 Oct 2006 16:49:00 GMT

	This article re-creates the game FreeCell using the January CTP and Visual Studio 2005 Express.
Unni Ravindranathan Unni's Blog Difficulty: Intermediate Time Required: 3-6 hours Cost: $50-$100 Software: Visual Studio Express Editions, Microsoft Expression Interactive Designer, Windows Vista, .NET Framework 3.0 Runtime and Windows SDK Downloads Hardware: Download: C# Download

Microsoft is starting to make some of the new development technology for Windows Vista available to programmers through Community Technology Preview (CTP) releases. To start introducing this technology to you (and have a little fun with it myself), I decided to recreate the game FreeCell using the January CTP and Visual Studio 2005 Express. In this article, I will try and describe my experiences on this brief one-day journey and how much fun it turned out to be!

About the technology used

"Windows Presentation Foundation", "Windows Communication Foundation", and "Windows Workflow Foundation" are the names for three strategic developer technologies that Microsoft plans to ship in 2006 as part of the Windows Vista operating system. In addition, Microsoft is making these technologies available on Windows XP and Windows Server 2003. The WinFX Runtime Components January CTP enables developers to continue experimenting with early builds of these technologies, get acquainted with the development experience, and provide Microsoft with feedback.

"Windows Presentation Foundation" is the name for Microsoft's unified presentation subsystem for Windows, formerly known as "Avalon". It consists of a display engine and a managed-code framework. "Windows Presentation Foundation" unifies how Windows creates, displays, and manipulates documents, media, and user interface. This enables developers and designers to create visually-stunning, differentiated user experiences that improve customer connection. When delivered, "Windows Presentation Foundation" will become Microsoft's strategic user interface (UI) technology.

Microsoft Expression Interactive Designer allows you to create engaging, cinematic user interfaces with a rich design environment that combines multiple media elements including vectors, pixel images, 3D content, video and audio, high-quality text, and animation. It allows you to drive seamless collaboration with developers using Visual Studio and maximize the integrity of designs by sharing the common WinFX platform during prototype, design, and development stages of building advanced UI and applications. For more information, visit http://www.microsoft.com/expression.

Creating the Game

When I set out on this project, I only had one goal in mind: I wanted to understand the workflow in designing an application in collaboration with a developer.

The first thing I did was to create all the card visuals once I knew I was doing FreeCell. All of the visuals are vectors done in Interactive Designer. Essentially, there are four drawing brushes for the four suites (created using the Tools | Make Tile Brush | Make Drawing Brush option in Interactive Designer).

FreeCell uses the Model View Controller (MVC) pattern that WPF makes very easy to implement using its powerful data-binding feature. The model for the card game resides in 4 classes:

Card.cs defines Card, which is your regular card data structure.
Cell.cs defines Cell. FreeCell has two kinds of cells: Home and Free.
GameModel.cs defines GameModel, which is the main game engine and holds the data structures for the various card stacks and cells.
RandomCardGenerator.cs defines a helper class that helps generate cards in random order using Enumeration – I brought this type in from a previous card game I wrote.

GameModel exposes all the data-structures as properties, such as HomeCells (which is a collection of home cells), FreeCells and CardStacks. CardStacks is a collection of collections, each of which is collection of Cards. Using ObservableCollection (which is derived from IList) allows you to simply tweak the model (such as moving a card from one stack to another whenever a game event happens) and this will update the UI. All of this requires no UI manipulation code. GameModel also exposes a string for displaying the time on the game board. For ensuring that the UI updates each time a timer in the model ticks, you need to implement an Interface called INotifyPropertyChanged, which will fire a PropertyChanged event whenever a property changes. You can then bind against this property in the view and forget about it. Isn't that a sweet separation between model and view?

So much for the code. An Expression project flows smoothly into Visual Studio and back since they share the same infrastructure underneath – any changes you make in Expression are visible in Visual Studio and vice versa!

The next step was to get back into Expression Interactive Designer and make this thing look cool. I used a ViewBox at the root of the game board (minus the status-bar-like thing) so that things would scale correctly when the app was resized—one of the biggest complaints I have with the FreeCell that ships with Windows. Expression has powerful layout capabilities that make it every easy to control behavior when the app is resized, and you can do this without it being your main concern.

A custom Panel was required for stacking the various cards, so I put my developer hat back on and created CardStackPanel.cs. It exposes an Offset property that allows the designer to control the Offset on the design surface. The code for this type is shown below and shows how easy it is to extend functionality of pre-existing controls in WPF:

Visual C#

public class CardStackPanel : StackPanel
{
    public double ArrangeOffset
    {
        get { return (double)base.GetValue(ArrangeOffsetProperty); }
        set { base.SetValue(ArrangeOffsetProperty, value); }
    }

    public static readonly DependencyProperty ArrangeOffsetProperty = 
        DependencyProperty.Register("ArrangeOffset", 
        typeof(double), typeof(CardStackPanel), new PropertyMetadata(10.0));

    protected override Size ArrangeOverride(Size arrangeSize)
    {
        Rect childArrangeRect = new Rect(arrangeSize);
        childArrangeRect.Y = -1 * this.ArrangeOffset;

        for (int i = 0; i < this.InternalChildren.Count; i++)
        {
            UIElement child = this.InternalChildren[i];
            childArrangeRect.Y += this.ArrangeOffset;
            childArrangeRect.Height = child.DesiredSize.Height;
            child.Arrange(childArrangeRect);
        }

        return arrangeSize;
    }
}

Visual Basic

Public Class CardStackPanel Inherits StackPanel
    Public Property ArrangeOffset() As Double
        Get
            Return CDbl(MyBase.GetValue(CardStackPanel.ArrangeOffsetProperty))
        End Get
        Set(ByVal value As Double)
            MyBase.SetValue(CardStackPanel.ArrangeOffsetProperty, value)
        End Set
    End Property

    Public Shared ReadOnly ArrangeOffsetProperty As DependencyProperty

    Shared Sub New()
        CardStackPanel.ArrangeOffsetProperty = _
            DependencyProperty.Register("ArrangeOffset", GetType(Double), _
            GetType(CardStackPanel), New PropertyMetadata(10.0))
    End Sub

    Protected Overrides Function ArrangeOverride(ByVal arrangeSize As Size) _
            As Size
        Dim childArrangeRect As New Rect(arrangeSize)
        childArrangeRect.Y = (-1 * Me.ArrangeOffset)
        Dim childIdx As Integer = 0
        Do While (childIdx < MyBase.InternalChildren.Count)
            Dim child As UIElement = MyBase.InternalChildren.Item(childIdx)
            childArrangeRect.Y = (childArrangeRect.Y + Me.ArrangeOffset)
            childArrangeRect.Height = child.DesiredSize.Height
            child.Arrange(childArrangeRect)
            childIdx += 1
        Loop
        Return arrangeSize
End Function

The rest of the UI creation was a breeze using Expression's powerful data-binding feature: just drag and drop data (like the time string that you created previously in your model), choose the control that you want to display the data (in this case a TextBlock), select the property you want to bind to (Text in our case), and finally, for more complex data fields, customize the look. To create a stack of stacks for the various cards on the game board, I used the default StackPanel that WPF provides (in horizontal mode) and each collection within it was laid out using the custom panel I wrote (and I set the Offset property to a value that made this look good).

One of the tricky things is that there really are no cards in these various data structures until the game actually beings; so, to workaround that, I wrote some temporary code in the constructor of my GameModel to populate them—that way I could visualize the cards and design them. We are working on providing a better solution to this problem so that you really won't have to write this kind of temporary code in the future.

There are two more interesting things: the design for the cards and the interactivity. At this point, you have four drawing brushes. How do you convert this to form fifty-two cards? The solution is to use the very powerful DataTrigger feature that WPF exposes. Data triggers allow you to specify the look of the visual based on a property in the model (in this case the Suite and Card number information). So I created thirteen data triggers for the thirteen possible cards, and four additional data triggers for the four suites. Each card template uses the Brush set on the control that represents it and thus you have 13 * 4 cards—cool, eh? Unfortunately, you cannot create DataTriggers in Interactive Designer as of now, so it has to be done by editing the markup. However, once this is done, you can then leverage the power of Interactive Designer to figure out what your Queen of Hearts or Ace of Spades should look like.

Here is what the structure of the DataTemplate for a Card looks like:

<DataTemplate x:Key="CardTemplate">
    <Grid x:Name="Grid1" Width="72" Height="100">
        <ColumnDefinition/>
        <RowDefinition/>
        <Control x:Name="CardDisplayControl" Margin="2,0,2,0" 
            HorizontalAlignment="Stretch" VerticalAlignment="Stretch" 
            Width="Auto" Height="Auto" />
            ....
    </Grid>
    <DataTemplate.Triggers>
        <DataTrigger Binding="{Binding Suite}">
            <DataTrigger.Value>
                <FreeCell:Suite>Hearts</FreeCell:Suite>
            </DataTrigger.Value>
            <Setter Property="Foreground" TargetName="CardDisplayControl"
                Value="{StaticResource HeartsDrawingBrush}" />
        </DataTrigger>
        ....
        <DataTrigger Binding="{Binding SuiteIndependentCardNumber}">
            <DataTrigger.Value>
                <system:Int32>1</system:Int32>
            </DataTrigger.Value>
            <Setter Property="Template" TargetName="CardDisplayControl" 
                Value="{StaticResource AceTemplate}"/>
        </DataTrigger>
          ....
    </DataTemplate.Triggers>
</DataTemplate>

There are two kinds of interactivity possible in this game: starting the game and selecting cards. To start the game, I used yet another WPF feature called command binding. Command binding allows your command implementation to be in your model (which in this case involves resetting the data structures, timers, etc.) without have to worry about how the command will be exposed. To hook up the command, you again use—guess what—data-binding using drag-drop in Interactive Designer: you can hook up the command to a button, menu item or both if you like. If the command is not available, then these various UI elements appear disabled—all without a line of UI code.

Finally to figure out which card or cell was hit by the user, all one has to do is to add a MouseDown event. Look at the DataContext property on the sender of the event. If the DataContext is not null and is an object in your model, you know exactly what was hit (at this point, all you do is call a function into your model to execute the game logic).

Check it out! It sure is fun!

Prize Winning Chess Game in C# Express

Coding4Fun — Tue, 24 Jan 2006 21:58:00 GMT

Kudos to Valentin Iliescu for his Valil.Chess game on Code Project written with Visual C# 2005 Express Edition. Valentin's work is appreciated by the coding community as evidenced by 1) a 4.85 out of 5.00 rating on Code Project (impressed much), 2) nearly 82,000 views, and 3) the November 2004 Submission Prize at Code Project! Check out this fantastic contribution by one of our Coding4Fun readers by downloading the code yourself. The application is impressive for both it's completeness and features. Way to go, Valentin! [:)]