At the very base of the idea of a symmetric proxy is the concept of a player interface containing methods for playing a game, any game, not just RPS, that can be conducted over the Internet. Our list is slightly different from that presented by Heliotis and Schreiner, but the core concepts are borrowed from their work.

By first working out the basics of a move and a turn, we’ve laid the basis for turn-based games. The next step is putting the moves into a game context.

In order to keep everything fair and fun, we need a referee. The class diagram for the referee in relationship to the player can be seen in Figure 13-1:

Figure 13-1. Referee and Player class diagram

Essentially, the referee will be a class containing the rules of the game encased in a template method. As a design pattern, the methods need to be fairly general, in case we want to reuse the same Referee class for another game. Using a template method, we can order the operations in the methods to launch in sequence, but we want flexibility for other games. So, we begin with a list of operations for the referee that applies to all games:

Each operation will be cast as a method and then arranged into an order that constitutes the template method. Following the Hollywood Principle (see Chapter 9), the Referee instance will make calls on the Player objects.

Now that we have a referee, we need to look at the relationship between the players and the referee. Figure 13-2 is an object diagram for a two-player game with a referee:

Figure 13-2. Referee and players

Just like a non-virtual game, the single referee makes decisions about the game outcome for two or more players. At this point, the game is immaterial—it could be any game. Looking at the object diagram, it’s not difficult to imagine two or more players interacting on a single host (computer). In fact, if the goal were to create a game where one of the players is the computer and the other’s a user interacting through a UI, our job would be done. In a game of Rock, Paper, Scissors, a random move generator could easily be one of the two players. However, because we want to play the game over the Internet, we have a few more steps.

As soon as we introduce remote players over the Internet, everything changes. Each player makes a move, that move is sent over the Internet, and the referee decides the outcome, displays it, and then cleans everything up. With serial turn taking, the problem may not be as daunting because after each move, both players can see the other’s move. The referee can wait until the first win condition is met and then send messages to all players. However, this can get messy because you have to decide where the referee’s going to reside. The referee could be placed on the host with the first player to start. The second player would be referenced through a proxy.

Another solution would be to place the referee on its own server, and, while workable, this requires that the moves travel over the Internet twice. Also, depending on the server, the basic game design may have to be changed to accommodate what the referee looks like.

Even though both of the solutions are workable, they may lack the flexibility and reusability desired in good design patterns. We need to look further.

Most of the key features of the Symmetric Proxy pattern have been described, but there are a few more. In this section we’ll summarize both.

Having discussed the player interface and referee concepts, we are left with two key elements to discuss before going on to look at key OOP concepts in this design pattern. First, we need to take a closer look at the synchronizing cell, and where the cell goes in the overall scheme of things. Second, we need to look more closely at the concept of a proxy object.

The proxy

Because using FMS2 takes care of the synchronizing problems and is immediately available to connected clients through a client-side method, we end up with a situation where we have to ask whether we really need a separate object for the proxies. Instead of creating four player objects, would it be possible to create two? Each player object, based on a common interface, would contain both the real player and the proxy player. This is an androgynous variation of the Symmetric Proxy design pattern, but conceptually, it’s virtually identical. Figure 13-4 shows an object diagram of this variation.

Figure 13-4. Androgynous variation of Symmetric Proxy

The only real difference between Figure 13-4 and Figure 13-3 is that the proxy and players are placed into single objects and the details of the Internet are spelled out a bit more in the latter. The same model could be used another way to send the proxy’s move such as PHP, ColdFusion, or any other mechanism for sending information over the Internet. (Axel Schreiner commented that you could use smoke signals—the method of sending information over the network is immaterial.)

The one thing we don’t particularly like about the androgynous variation on the Symmetric Proxy is the loss of granularity in the model. By placing the proxy move method in the same object as the real player, we collapse the real and proxy in a way that may not be easily adaptable to other games. At this point, though, no clear disadvantage is apparent. Both players are perfectly symmetrical, and the variation maintains the role of the referee.

The first question to address is whether or not any trans-Internet communication can work with the Symmetric Proxy pattern. Because of its ease of use and built-in features like remote shared objects, using an application such as Flash Media Server 2 has a built-in disadvantage as a communication testing and development platform for a general communication design pattern. The server-side script automatically informs all players of the current game state in the form of one or both players having moved. Once both players have moved, the referee determines who has won and resets the game for another round.

In the original model of the Symmetric Proxy and the Androgynous variation, as long as the proxy player makes the same move as the original player, whether FMS, another open socket technology, or middleware such as PHP, C#, Perl, ColdFusion, or VB.NET, is not important. The move for the proxy is the only state that really needs to be sent over the Internet. The proxy plays the move, and the referee takes care of deciding whether the proxy or its player opponent wins, displaying the outcome and resetting the variables for a new game. So any communication system that can send the player’s state to its proxy is acceptable, meeting the criteria of communication flexibility.

In the implementation you will see in this chapter, the referee’s not quite as active as the one envisioned by Heliotis and Schreiner. The primary difference is that the referee only inspects the moves after both moves have been made in a game. Because each round in a game of RPS is a complete game, each game is over as soon as both players have moved. At this point, the referee kicks in with its template method, decides who won, displays the outcome, and resets the values to the start states.

One way of reducing the referee’s work is in the UI. Players can only enter one of three different moves displayed on the buttons. The real player blocks any attempt to make any other move, such as one where the player has not made a move selection. In a more complex game with a wider selection of moves, either more responsibilities would be delegated to the referee or the UI would take care of allowing a wider but still limited move set.

With a single template method, and three methods that make up the template method within an abstract class, the Referee class has both flexibility and utility. In the example application in this chapter, the implementation of the Referee class subclasses RPS. The RPS class provides the specific details for the RPS game. The measure of flexibility is whether a different game could be subclassed from the Referee class to create a whole different game.

Of the three functions that make up the template method, flexibility is most important in the function that determines who won or if the play results in a tie. The following shows that function in the Referee class:

function doWinner(p1Move:String,p2Move:String):String
{
    return winner;
}

Because the method resides in an abstract class, we can expect it to be overridden for different games. It takes the move of players 1 and 2, having no idea whether the move is by the proxy or not, and returns a string with the winner or a tie result. Because it is abstract in a literal sense, it simply waits until one of the two moves results in a win or tie condition. With the RPS game, this is relatively easy because each round of moves is a complete game.

However, what about games like Tic Tac Toe? It’s a game of several different rounds and a wider range of outcomes. Because the doWinner method includes parameters for both players, all moves can be calculated. Each move can be described in terms of the 3-by-3 matrix as C1R1 to C3R3 (Column#/Row#). Once either player has met the win conditions or the play has reached a point where neither can win (a draw), the entire template method can launch.

Alternatively, each move can be delegated to a Referee class, including a Referee subclass. This alternative is the original intention of Heliotis and Schreiner, and the flexibility of the Symmetric Proxy design allows either alternative. In games with more than two players, teams, or some other combination of individual players or teams, only a few changes in the doWinner method parameters could set it up for more complex alternatives.

The key to game flexibility in the Symmetric Proxy class lies in the ability to override the methods in the original template method in the Referee class. Creating multiplayer games beyond two players is quite easy as long as each has a “home” referee, immediately sends all moves to all players and/or referees, but does not have to make adjustments to the basic design pattern.

Of the three methods in the Referee class, the first needs to be very flexible because it will return the winner of the game. The real implementation of the method will lie in any subclass that describes a game. The doWinner method is most likely to be part of a subclass specifying the rules of the game.

function doWinner(p1Move:String,p2Move:String):String
{
    return winner;
}

It includes parameters for moves by both players. In the context of RPS, where the game has only a single move by each player, the moves represent the endgame conditions. In other games, though, the Referee may need to call for moves every round to accumulate information about win conditions.

The next method is designed to display outcomes, requesting both a reference to a text field and a string.

function displayResults(displayWindow:DynamicText,outcome:String):void
{
    displayWindow.setMove(outcome);
}

In the context of RPS and most games, this method has two different roles. On one hand, as part of the template method, it displays who has won. However, it can also be used to display information independent of the template method. Keeping in mind that moves in RPS are simultaneous, neither player can see the other player’s move until both have made their moves. So this method can also be used to display other information such as the opponent’s move any time it’s appropriate to do so.

The third method in the Referee class is to reset all of the values to the start conditions—setting up the chess pieces in their original positions, so to speak. This method has a housekeeping character, but it’s essential if you’re going to play the game more than once without reloading it.

function resetGame(movecheck:Array):void
{
    for (var r:uint =0; r< movecheck.length; r++)
    {
        movecheck[r]=false;
    }
}

By keeping track of the moves in an array, resetting a game is made both easier and more flexible. With only two moves, the function could be written to reset two Boolean variables to false. (The false state means that the move has not been made.) Because the method uses an array, it doesn’t care how many moves have to be reset. It’s far more flexible and reusable than using non-array variables.

The final method is constructed from the three methods that currently exist in the Referee class. As a template method, it is locked using the final statement. As a reminder, the final statement disallows any overrides of the method; however, the methods that make up the template method can be overridden, and we generally expect that at least some methods in the template method will be.

final function moveComplete(p1Move,p2Move,displayWindow,movecheck):void
{
    outcome=doWinner(p1Move,p2Move);
    displayResults(displayWindow,outcome);
    resetGame(movecheck);
}

In this particular template method, the first method passes the game outcome, a String variable. This variable is then used as a parameter in the second method to display the outcome to a specified output object. Finally, the template method resets the game to the start state. Simplified, the template does the following:

By invoking the Referee, all the information is neatly packaged and ready to resolve the game outcome, display the results, and reset the game.

The Referee class is set up to be subclassed and its methods overridden so that developers can reuse the design pattern for more than a single type of game. Example 13-3 shows the Referee subclass, RPS, designed to determine the outcome of a Rock, Paper, Scissors game.

package
{
    //Rock, Paper, Scissors
    public class RPS extends Referee
    {
        private var winner:uint;
        private var gameOver:Array;
        private var winNow:String;
        //
        override protected function doWinner(p1Move:String,
             p2Move:String):String
        {
            if (p1Move=="rock")
            {
                switch (p2Move)
                {
                    case "rock" :
                        winner=2;
                        break;

                    case "paper" :
                        winner=1;
                        break;

                    default :
                        winner=0;
                }
            }
            else if (p1Move=="paper")
            {
                switch (p2Move)
                {
                    case "rock" :
                        winner=0;
                        break;

                    case "paper" :
                        winner=2;
                        break;

                    default :
                        winner=1;
                }
            }
            else
            {
                switch (p2Move)
                {
                    case "rock" :
                        winner=1;
                        break;

                    case "paper" :
                        winner=0;
                        break;

                    default :
                        winner=2;
                }
            }
            gameOver=new Array("p1 Wins!","p2 Wins!","Tie!");
            winNow=gameOver[winner];
            return winNow;
        }
    }
}

The RPS class overrides the doWinner method developed in the Referee class. The other two methods in the Referee class are usable without any changes. A single algorithm determines which side has won or if a tie occurred, and then transfers the information into an array element that is then stored in a String variable and returned.

When employing the RPS class, we will observe the dictum to program to the interface and not the implementation. So, in typing any instance where we would use the RPS class, we will type it as Referee and instantiate it as RPS. (Look for this instantiation of the RPS class in the SymPlayer1 and SymPlayer2 classes.)

While the player class may seem fairly long and unwieldy, its key elements are quite simple. Everything is focused on making one of three moves—rock, paper, or scissors. Each move is nothing more than a string.

rps.moveComplete(p1move,p2move,playerText,monitor);

The second player class also implements the ISymPlayer interface, but it’s slightly different, and a few parameter values have changed. All you need to do is make a few changes in SymPlayer1. Begin by saving the SymPlayer1.as file as SymPlayer2.as, and then make the changes in bold in the following segments:

    public class SymPlayer2 extends Sprite implements ISymPlayer
....
    public function SymPlayer2()
....
        //
        //makeMove: Make Move
        //
        public function makeMove(event:Event):void
        ....
            moveVal=event.currentTarget.name;
            if (!monitor[1] && mcheck)
            ....
                        var m:String=showText.getMove();
                        if (m != "ready" && m != "Error!")
                        {
                            //Proxy 2 move
                            doMove(m);
                            //Player 2 move
                            localMove(m);
                        }
                        ....

        //
        //localMove Player Move
        //
        public function localMove(locMove:String):void
        {
            playerText.setMove("player2");
            if (!monitor[1])
            {
                p2move=locMove;
                monitor[1]=true;
            }
....
        //
        //onProxyMove: Info from server
        //
        public function onProxyMove(proxMove:String):void
        {
            playerNow=proxMove.substring(proxMove.indexOf("~")+1);
            proxMove=proxMove.substring(0, proxMove.indexOf("~"));
            if (playerNow=="player1" && !monitor[0])
            {
                playerText.setMove(playerNow);
                p1move=proxMove;
                monitor[0]=true;
....
public function takeTurn():void
        {
            rps=new RPS();
            rps.moveComplete(p1move,p2move,playerText,monitor);
            rps.displayResults(oppText,p2move);
            showText.setMove("ready");
        }
....

Simply change a few 1s to 2s and some 0s to 1s in the key methods in the SymPlayer1 class, and you’re good to go.

Because all the data input is done with button entries, the text fields for displaying data is all typed as DYNAMIC. Example 13-6 shows the class for the text fields.

package
{
    import flash.text.TextField;
    import flash.text.TextFieldType;
    import flash.text.TextFormat;
    import flash.display.Sprite;

    public class DynamicText extends Sprite
    {
        private var gameInfo:TextField;
        private var gameFormat:TextFormat;

        public function DynamicText():void
        {
            gameInfo=new TextField();
            addChild(gameInfo);
            gameInfo.border=false;
            gameInfo.background=true;
            gameInfo.type=TextFieldType.DYNAMIC;
            gameInfo.width=70;
            gameInfo.height=20;
            gameFormat=new TextFormat();
            gameFormat.color=0xcc0000;
            gameFormat.font="Verdana";
            gameFormat.size=10;
            gameInfo.defaultTextFormat=gameFormat;
        }
        public function setMove(pMove:String)
        {
            gameInfo.text=pMove;
        }
        public function getMove():String
        {
            return gameInfo.text;
        }
    }
}

The getter/setter functions make it far easier to access and display the available moves. At the same time, the text fields act as temporary storage of values that can be placed into variables or parameters.

The class for buttons is made up of Sprite, TextField and TextFieldType classes. Example 13-7 shows the script for the class.

package
{
    import flash.text.TextField;
    import flash.text.TextFieldType;
    import flash.display.Sprite;

    public class MoveButton extends Sprite
    {
        private var mvBtn:Sprite;
        private var id:String;

        public function MoveButton(mover:String,btncolor:int)
        {
            mvBtn=new Sprite();
            this.id=id;
            addChild(mvBtn);
            mvBtn.buttonMode=true;
            mvBtn.useHandCursor=true;
            mvBtn.graphics.beginFill(btncolor);
            mvBtn.graphics.drawRoundRect(0,0,(mover.length*8),20,5,5);
            var mvLbl:TextField=new TextField();
            mvBtn.addChild(mvLbl);
            mvLbl.text=mover;
            mvLbl.selectable=false;
        }
    }
}

The combined sprite and text provide a bit more information than just using a SimpleButton class would. Because we wanted the information in the text to be the information sent as moves, and the interactive aspects to be displayed in the dynamic text field rather than changes in the button’s appearance, the choice was not a difficult one. Also, we experimented with different colors for the buttons, decided to let the designer pass his own color scheme, and so included a color parameter (btncolor).

The final aspects of the application include static text placed directly on the stage and a movie clip created to serve as a connection light. Figure 13-5 shows the static text placement in the right portion on the stage, and what the application looks like when running on the left.

Figure 13-5. Stage and SWF file views

The following steps show how to create the last part of the application:

This application is designed to have two different players accessed from two different Flash files. To create the second file, use the following steps.

That’s it. Place both HTML and SWF files on a web server, one player selects Player 1 and the other Player 2, and you’re good to go. You might want to set up a little HTML file that allows the user to choose either Player 1 or Player 2, and then links to the players through the HTML file. If one is in use, indicated by a red connect button, then the user can just switch back and use the other.