The source code of all examples is included in the TcpJLib distribution.

Example 3: Development of a multi-room game server

The general network topology for Internet games is the following: A single game server manages several sessions, often called "rooms". In each room a number of players play a specific game. The game may be the same or different in different rooms and the number of players is normally restricted to a maximum number for the particular room. In the following example we will show the design principles for such a situation using the TcpJLib framework. For the sake of simplicity the game in each room is the same and the number of players in each room is restricted to two. For our pleasure, we use the famous "Memory Game", where card pairs with identical pictures are placed picture down on a table. On each move a player turns two cards. If the picture coincides, the player removes the cards and continues to play until there is no match or no cards left. When all cards are taken, the game is over and the player with more card pairs wins.

If the exchange of data in a two-players game is very simple, you may avoid the complexity of developing your own game server and adopt a peer-to-peer strategy using two TcpNodes or a TcpAgent/TcpBridge pair and distinguish the rooms by the session ID of the relay server.

The following topology is implemented:

As seen from this figure every player node and the memory server use the same session ID (for example "xyz"). For the TCP/IP communication every player uses a TcpAgent instance and the memory server uses aTcpBridge instance. Before rushing into coding you must decide how much "game awareness" is delegated to the game server and how much is kept locally within the player programs. Of course the decision depends on the specific game and is a matter of discussion. Some general guidelines are important:

• The management of the rooms (login/logout of players, limiting number of players, start and end of game, etc.) is the duty of the game server. It keeps a collection of all rooms and of all players in each room. Because the relay handles name clashes by appending (n) trailers, it is simple to distinguish players that log in with the same name.
• When the room is complete (two players entered), the game server sends the starting game situation to both of the players and decides that the player entered first will start to play. When the game is finished, the server decides to let start the loser in the next game.
• To avoid a mess, the player's actions (mouse events) are disabled until he/she is allowed to make a move. To avoid uncertainness, the current status is displayed in a status bar.
• During the game, most information is transmitted from one player to the other without intervention of the game server (pass-through). When a card is turned, the card coordinates are transmitted with a REPORT_SHOW command. The partner's callback is responsible for turning the same card.
• After two cards are turned, the success or failure must be checked. There are in principle two possibilities where to do it: Locally (In the mouse callback) or by the game server. Because for complexity reasons we do not want to follow the complete game situation within the game server, we do the check in the mouse callback. On failure, the application thread is "woke up" and, after a short delay, it transmits the card coordinates to the waiting player using the REPORT_HIDE command. (Other solutions: Use the mouse callback or a new thread to transmit the information, or keep the locations of the two cards in memory and transmit only a failure command).
• All command are received in the dataReceived() callback. Typically there is a switch statement to select the different actions:

• When a new player logs in, he/she transmits the user name with a REQUEST_GAME_ENTRY command to the game server. Because TcpAgent/TcpBridge restricts communications to integers, the name string must be coded to an integer array using TcpTools.stringToIntAry() and restored by the game server using TcpTools.intAryToString(). It is a somewhat tedious work to manage the players and the rooms when new players enters and quits, but even if a player disconnects unpolitely by closing the application, the game server is notified by triggering notifyAgentConnection() where a cleanup can be done.
• Often game servers are highly multi-threaded. You should struggle to reduce parallel executions by separate threads as much as you can to avoid concurrency problems and dead-locks when synchronizing. TcpBridge helps you for serializing your code by calling all notification callbacks from the same thread. Evidently the pipeRequest() callback should not execute long lasting code for one specific node because this could starve out requests from other nodes. If you need to execute some longer lasting code, you are forced to do it in an new thread. In this case be very careful to synchronize critical sections to avoid side-effects, race conditions and concurrent access exceptions.

For all other details, consult the source code that is contained in the TcpJLib distribution (or download it from here).

Execute the program locally using WebStart.