03.01.2013 Views

Chapter 1

Chapter 1

Chapter 1

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Command Description<br />

Terminate Stops game session. Valid in any state.<br />

Resend Resend last RGCP response/request packet. Valid inRGCP initiating or<br />

waiting states.<br />

Receive all Initiates receive of any packets. Valid in any state except BSP blank.<br />

Program Structure<br />

In the Battleships program, the CGameController handles all the BSP protocol, including<br />

functions called by the UI and RGCP handler functions. The controller also implements all<br />

send-request and send- response functions implied by BSP and maintains state transitions<br />

in accord with the design above.<br />

A key aspect of the controller design is that every public function and many private functions<br />

assert the validity of the requested operation, given current BSP and RGCP states. The app<br />

UI and views are responsible for prechecking user-initiated commands, so that no invalid<br />

command can be issued to the controller.<br />

Taking BSP Forward<br />

BSP combines a multigame session protocol with the specifics of the Battleships game. It<br />

would be possible to separate these aspects into two layers.<br />

A truly general protocol may or may not be worthwhile: other games could reuse BSP's<br />

patterns without reusing its code. In any case, patterns differ between games. A game that<br />

can be tied, for instance (as opposed to only won or lost), may require a different approach.<br />

It would be possible to improve on the first-move selection here, by changing only the UI, to<br />

select random first-move preferences. BSP itself would not have to be altered.<br />

Summary<br />

We've now seen TOGS components described in detail – with the exception of the Bluetooth<br />

and SMS GDP protocol implementations that are described in <strong>Chapter</strong> 20.<br />

The content of this appendix is heavier and more precise than that of many of the chapters<br />

in this book. I wrote it before I wrote most of the code it describes, and have not changed it<br />

substantially since – except that I've maintained some parts as the code has evolved. That's<br />

a healthy (if unusual!) software engineering practice. In this case, doing the documentation<br />

before the code saved me a lot of time.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!