Chapter 1

� define getter and setter functions for this struct, which change its members,
� define getter and setter functions for a protocol level, which get a struct from the level's
current settings, or set the settings from the values in a struct.
Clearly, a different struct would be required for each level in the protocol stack.
The capabilities pattern is particularly worthwhile for a protocol layer with many capabilities,
especially if that layer often resides towards the bottom of a stack.
16.6.2 Other Games
TOGS isn't designed for Battleships alone. Any turn-based game could be implemented on a
TOGS stack, using GDP, GSDP, and RGCP unchanged, but replacing BSP and the
Battleships game.
Suitable games would include Chess, Checkers (Draughts), Backgammon, Tic-Tac-Toe
(Noughts and Crosses), Connect Four, Scrabble, and many other games, including twoplayer
card games.
The developer investment required to produce a good game on top of TOGS is not high,
since you don't have to build in the intelligence required for a human-versus-computer
version of these games. You only have to specify and implement the protocols required to
communicate moves, the rules needed to referee attempted moves, and a GUI.
Other games will probably use a variant of BSP. However, the details will be subtly different.
Board games are based on a single shared game state (the board and pieces on it) that is
public to both players. Battleships is a game of two halves, in which each player's initial fleet
disposition is initially unshared, but as the game progresses it is selectively revealed to the
other player.
Many games include some combination of shared state and unshared state. In Scrabble, for
instance, the knowledge of your letters is private to you, the unused letter pool is unknown to
anyone, and the board state is completely public. Many card games rely on guessing
unshared state for much of the interest in the game. The whole intrigue in multiplayer
Diplomacy (though not the two-player version) arises from selective, and not always truthful,
sharing of state between players.
The degree of shared state will have some effects on your game protocol. A key rule in
gaming is to minimize disclosure – that is, don't share things at the protocol level and hide
them at the UI level. For instance, in Battleships, it would be possible to exchange the entire
state of each player's board at the beginning of the game, so that the response to hit
requests could be instant. But then a knowledgeable player could find out the state of the
opponent's game, and win in 20 moves.
16.6.3 Single-player Games
Solo Ships was an attractive and useful single-player version of Battleships – possible
because Battleships is really two half-games.
Another single-player form of Battleships would involve the computer as a genuine
opponent. The basic game design would use two CGameEngines, and two CFleetViews
(one for my fleet and one for the opponent fleet). Instead of having an app view, the other
engine would have a CGameComputerPlayer, which would make hit requests on behalf of
the computer.