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.

Here's part of the controller code that runs when the player using that controller requests a<br />

hit to a square on their opponent's fleet:<br />

void CGameController::ViewCmdHitFleet(TInt aX, TInt aY)<br />

{<br />

__ASSERT_ALWAYS(!(iEngine->iOppFleet.IsKnown(aX, aY)), Panic<br />

(EHitFleetAlreadyKnown));<br />

// hit fleet<br />

iEngine->iOppFleet.SetShipType(aX, aY, iEngine-<br />

>iMyFleet.ShipType<br />

(aX, aY));<br />

TFleet::THitResult result = (TFleet::THitResult)iEngine-><br />

iOppFleet.SetHit(aX,aY);<br />

iEngine->iMyFleet.SetHit(aX,aY);<br />

// update view and play sounds<br />

-<br />

}<br />

The purpose of this code is to:<br />

� find out what was on the opponent's fleet on that square,<br />

� mark the information as found on my view of the opponent's fleet,<br />

� mark the opponent's fleet as hit on that square.<br />

The code simply follows pointers to find the opponent's real fleet:<br />

TFleet& oppFleet = iOtherController->iGameEngine->iMyFleet;<br />

Then, the code calls functions on both my view of the opponent's fleet, and on the<br />

opponent's fleet itself.<br />

From a design point of view, this is all very elegant. I was able to reuse the same engine and<br />

view in Battleships, and testing them here just involved the plumbing above.<br />

16.2.3 Communications is Different<br />

But this implementation of CGameController::ViewCmdHitFleet() simply won't do in<br />

a real communications world. It uses a synchronous, reliable function call, with parameters in<br />

internal format, to find out the state of my opponent's fleet, and to inform my opponent that I<br />

have hit a square.<br />

With real communications, I have to tackle some fundamental issues:<br />

� Communications is asynchronous. I might have to wait an arbitrary time between<br />

sending the hit request, and receiving the response. While I'm waiting, I might change<br />

my mind and decide to abandon the game. So, while I am waiting for the response from<br />

the other player, the game must be able to handle other kinds of input from me.<br />

� Communications is unreliable. I need to use protocols that ensure that either my<br />

message gets to the other player, or that I am reliably informed that it has not got there<br />

for a reason that I can understand. I may need to be able to retry sending my message.<br />

� Communications uses external formats. I will have to decide on the binary format that I<br />

use to communicate between the two games. I will have to change to external format<br />

when sending, and change back into internal format when receiving data. Furthermore,<br />

if I wish to play this game against an implementation running on a non-Symbian OS

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

Saved successfully!

Ooh no, something went wrong!