Chapter 1

As it's presently implemented, Battleships is really two single-player games. The computer
sets up both users' games, and the moves I make are largely independent of the moves of
my opponent. Result: we're really playing two games against the clock, and the one who
completes the game first is not really so much the winner, as the best (or luckiest) player. In
fact if we took this view to an extreme, we could considerably save on the messaging
involved in a game of Battleships.
In a real Battleships game, fleet layout is what really enables each player to test the
psychology of the other. Adding an option for user- specified layout would make a good
addition to the interest in playing the game. The code required to support this, in engine, app
UI and view, would be nontrivial.
Random first-move preferences
The first-move preference specification is awkward, and gives the users one more thing to
think about. There's a strong argument for removing it from the UI and replacing it with a
randomly set first-move preference. This could be done without changing BSP: the firstmove
calculation is still done from within the controller when the initiating player receives the
listening player's initiate-response.
This is a good example of how to make a UI simpler, by removing choices that generate
more confusion than flexibility.
To remove the choice about initiate/listen from the UI isn't possible with SMS, or even
desirable. But the idea of making a call or sending a message is well enough understood.
Perhaps the terminology could be better – Send First Message and Receive First Message –
but this terminology doesn't suit protocols like Bluetooth.
Little things maybe, but these are among the first UI features our end users will see, and if
they appear hard to use, some would-be users won't take a second look.
Chat channel
BSP is sufficient to implement the rules of Battleships and to make the game playable. But a
game of Battleships played between two players in a room, using old-style paper-and-pencil
methods, wouldn't be simply a set of hit requests and responses. There would be comments,
taunts, discussions about when to play the next game, and so on. Chat adds to the
psychology and interest of a real Battleships game, just as much as user-controlled fleet
layout.
It would be nice to build in a chat channel to Battleships to support this kind of chat.
However, BSP is built on RGCP – a conversational protocol in which players take it in turn to
send and receive messages. That's basically unsuitable for chat.
My favorite scheme to implement a chat channel would be to implement it at the GSDP level,
so that the Battleships game has another connection to the GSDP server. That's easy – the
Symbian OS client-server architecture supports multiple independent connections from any
thread.
At the UI level, there would be no need to alter the start-new-game dialog (chat initiate/listen
details are the same as for the game). The view would have to be altered to include chat
data – or, as in tp-ships, a multiview approach could be used. The persistent form of the
game would have to be altered to include a log of chat – perhaps on a different stream from
the main game data, so that chat could be added optionally without breaking the format of
existing games.