ActionScript 3.0 Design Patterns

(Chris Devlin) #1

476 | Chapter 13: Symmetric Proxy Pattern


were reviewed, we’d like to focus on a more general key OOP concept for the Sym-


metric Proxy design pattern—flexibility.


Because the Symmetric Proxy design focuses on interaction over the Internet, we


need to look at two different kinds of flexibility. First, we need to look at communi-


cation flexibility. That is, can the model be used with different communication tech-


nologies over the Internet? Second, we must consider game flexibility. To what


extent can different games be employed with the design?


Communication Flexibility


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 fea-


tures 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 hav-


ing 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 out-


come 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 commu-


nication flexibility.


Game 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 ref-


eree only inspects the moves after both moves have been made in a game. Because


each round in a game ofRPSis 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 comple xgame with a wider selection of moves, either more responsibili-


ties would be delegated to the referee or the UI would take care of allowing a wider


but still limited move set.

Free download pdf