SampleClient

SampleController
This class extends GameController and manages the flow of the game on the client. It acts as the controller in the standard model/view/controller paradigm where the model in this case is the SampleObject and the view will be explained momentarily. As the controller, it reacts to changes in the model and to user input. Like in the manager, there are calldown methods provided to allow the controller to take action when the game state changes:

gameDidStart
This is called when the client receives notification from the server that the game has started. This is the place where the user interface would be enabled and the client would prepare for play.

gameDidEnd
This is called when the client receives notification from the server that the game has ended. Here the user interface would likely be disabled and any appropriate game over messages (like the winner, etc.) would be displayed.

gameWasCancelled
If the game was cancelled rather than ended through normal play, this method will be called. The client may wish to display a special cancelled message and otherwise do the same cleanup it would do during normal game ending.

resetGame
This is a less commonly used method designed to allow the client to behave fluidly in the face of network latency. Frequently, when a game uses resetting, the client knows that the game will reset (perhaps the user made the request to reset the game) before the server does and it is useful to temporarily disable the user interface and otherwise behave as if the game has ended until a new game start notification is received from the server (which will result in gameDidStart being called again). In such cases, the client can call resetGame which will result in a call to gameWillReset which they can override and clear things out in preparation for the new game.

Note: the resetGame method does not actually send a request to the server to reset the game. It is assumed that the server either knows the game will reset through the normal operation of the game or that the client explicitly requested a reset (through some game-specific mechanism) prior to calling reset game. For example, perhaps a client submits a request for each move, then it computes the available moves for the next turn and if the player has run out of moves, the game is reset (rather than ended) and they start over. The client would submit a move to the server in the normal course of play, and the game manager would know after it received that move that the player had no moves left and that the game needed to be reset, so it would call resetGame on the server. Meanwhile, the client, after submitting its move, also determines that there are no moves left to play, so it calls resetGame on the client which results in the interface being reset immediately rather than waiting for a round-trip to the server to hear what it already knows.

gameWillReset
This is the calldown method that a game controller would override to reset things in preparation for the game to restart.

The controller also handles input from the user which is generally first processed by the view and converted into actions that are meaningful in the context of the game. For example, the view might allow the player to place pieces on a board, in which case it would process mouse movement and mouse click events and eventually communicate to the controller a request like "place piece P at coordinates C".

Most likely the view will simply maintain a reference to the controller and call methods on it, but a mechanism is also provided to package up those requests and deliver them as events on the AWT thread to be handled by the controller in the same stream as the network events (which are also dispatched on the AWT thread). This is particularly useful if the event comes as a result of, say, a timer expiring rather than some underlying AWT event like a mouse click. To find out more about this mechanism take a look at Controller and specifically handleAction.

SamplePanel
This panel contains the various interface elements used by the game. It usually doesn't do much except combine all the needed elements into a single display that can be easily instantiated by the controller.

SampleBoardView
This interface element does the main work of displaying the game and collecting user input and communicating it in a meaningful way to the controller. In the sample game, there's not much to do, but look at the code for the other included games to see the sorts of things done by the view.

The board view, like any other user interface element that wishes to display distributed object state associated with the game "room", implements PlaceView. By implementing this interface, it will automatically be notified when the client has "entered" the game room and later when it has left. That is accomplished with the following methods:

willEnterPlace
This is called once we have subscribed to the game object (it is passed as a PlaceObject reference but it is indeed your game object and can be casted appropriately), and is a good place to add listeners to the game object and initialize the user interface based on information therein.

Note: if the view wants to respond to changes in the game state, there are a couple of options. It might add itself as an AttributeChangeListener and respond to changes to the GameObject.state attribute, or the game controller can call down to the view to let it know when the game starts or ends or whatever it needs to communicate. It is pretty likely that the view will need to listen to the game object to hear about game-specific changes, so additional handling of changes to the state attribute are pretty easy to incorporate.

didLeavePlace
This is called when the client has left the game room (generally a player is not forced out of the room when the game ends, so this will generally happen when the player clicks a "Back to lobby" button or something similar and the client requests to leave the game room and head back to the lobby room). Here any listeners added to the game object should be removed and any other cleanup that is desired can be performed.

Back to tutorial.