Now let's break down a full game into all of the moves and steps necessary to carry the play from beginning to end. This will help in understanding how a system could be designed to emulate the same behavior. For this example, we examine the moves when Bob and Laurie play a game of tic-tac-toe (Figure 8.2):

Figure 8.2. Bob and Laurie's game of tic-tac-toe

This is simple enough, especially when it is carried out with pencil and paper. Our challenge is to understand the process so we can translate it to game logic.

Reflecting on what you just saw in the game, you can extract the different stages and the actions necessary to move through the process. With this information you can construct a diagram that defines and illustrates the relationship between your states and actions (Figure 8.3).

Figure 8.3. A turn-based game diagram helps define the relationship between states and actions.

Your application should carry the players through each of these stages. Along the way make sure to keep track of the following game attributes:

In the real-time game world we did not try to store the state as it progressed. That would not have been feasible, but it is also much less valuable in a head-to-head or peer-to-peer game. It's important to save the game state so that your players can pause and resume the game at their leisure. This feature of turn-based games can be a huge draw. Games that players would normally never have time to engage in become feasible. A player can spend a few moments making a move, then stick his iPhone back in his pocket until he is alerted that his opponent has made a countermove. In this way games can last for hours or even days.

Head-to-head is not just for real-time games. Old-school tic-tac-toe played on paper is a perfect demonstration of a head-to-head game in one of its oldest forms. Usually it does not take a lot of additional effort to incorporate this connection style into your game if it makes sense.

Here are some pros and cons of supporting head-to-head:

In Chapter 7 we discussed establishing peer-to-peer connections. Most of the same lessons apply to turn-based games. All you need to do is follow the same steps as you did in the last chapter to establish a connection. The good news is that when you send messages, you don't need to deal with unreliable messages.

Here are some pros and cons of supporting peer-to-peer:

Another option is to connect your players through a central server using Web services. To do this you will need to construct a centralized server that can relay messages between players who are connected. For turn-based games, this can be accomplished with an HTTP server that can serve dynamic content. This should be a straightforward task for anyone who is familiar with hosting dynamic Web pages. To service the needs of a turn-based game, you could use a server side language like PHP, Perl, Java, .NET... and the list goes on and on. Whichever technology you pick, you will need to expose services that your application can consume. We'll go into more depth on this topic later in this chapter.

Here are some pros and cons of using Web services:

Push notification is the newest option you have in your bag of tricks. Using push notification in your game will yield results that are very similar to using Web services. The biggest difference is that you have the ability to send messages to players who do not have your application running. As with Web services, we will cover push notification in more detail when we examine the application later in this chapter.

Here are some pros and cons of using push notification:

In order to establish a connection, you will need a server to relay the messages between the two players. The messaging required by a turn-based game can be managed with a standard HTTP server. HTTP servers are commonplace these days and you can program them to manage the game on the server side. You can develop this server logic using a host of different languages. Developing a Web server is outside the scope of this book, but we'll focus on the client side code necessary to connect to such a server. For more information on server side services, go to our Web site, www.appsamuck.com/gameservices/. There we have links to resources that will help you build and host your own server side services.

Connecting players with the application installed

Once you have access to a server with the services you need, you can start your connection process. If both of the connecting players have the application installed, establishing a connection is a much smoother process than when it is not installed. There are many ways to approach this process, but the way we have chosen to proceed works much like an e-mail server. In fact, we have chosen the e-mail address to be the value that uniquely identifies players. Here are the basics of the process (see Figure 8.6):

• If the application has been launched and no e-mail address has been supplied, prompt the user for his e-mail address. Preferably you would confirm that the e-mail address actually belongs to the user.

• If the e-mail address is available, search the game server with the e-mail for friends who are challenging the user.

• If the user chooses, he can enter the e-mail address of a friend he wishes to play against. When friends search, they'll see that a buddy is asking to play against them.

You should start with this basic process, but you can (and should) expand on this system to make the process more engaging. For example, you could keep track of a friend list for the user and constantly poll to see if the friends are online. Then the user can just click the name of an online friend and ask him to play.

Note

It is paramount that you make it easy for players to connect or your game will fail. If the connection process is difficult, many players will get frustrated, delete your app, and give you a bad rating.

Figure 8.6. The workflow of two players with the application already installed

Push notification is an exciting feature added to the iPhone SDK beginning with version 3.0. Without push notification, you are limited to receiving game requests via e-mail, via SMS, or when your game is open. When you add push notification, you can alert players whenever a friend challenges them to a new game or even when they make a new move. With push notification, you can issue the following alert types:

Adding push notification to your process definitely enriches the user experience. Implementing push notification is a little more of a challenge than setting up a simple Web server. Your server must maintain a connection to the Apple Push Notification server in order to send push notifications. Figure 8.8 shows a modified version of the workflow you saw earlier, but with the Apple Push Notification server included.

Notice in this workflow that player 2 is interrupted with a phone call. Push notification helps you continue the game flow with a user-friendly experience. Again, building the server side of push notification is outside the scope of this book, but there is good documentation on the Apple Developer Connection site, and example implementations of the server can be found in the user forums for several different server side languages. This information is changing daily; for more information, see Appendix A or check our site, www.appsamuck.com/gameservices/.

Figure 8.8. The workflow of the game, including the Apple Push Notification server

Any application begins with a good design. Always take time to write down your ideas, even if you just use a napkin. The game screen for Amuck-Tac-Toe is easy enough to envision. We just need a normal tic-tac-toe board with four cells instead of three (Figure 8.9).

Figure 8.9. Amuck-Tac-Toe game screen mock-up

We like Balsamiq Mockups (www.balsamiq.com). Using this tool, it is almost as easy to make the mock-ups as if you were sketching them by hand. We used Balsamiq to mock up the game screen. This game has a lot of menu options, so it was handy to mock up the menus before committing a design to code.

The following figures show the menu screens that we mocked up. The first one is the main menu screen—this is the screen that you see when the application first loads (Figure 8.10).

Figure 8.10. Amuck-Tac-Toe main menu screen mock-up

This screen organizes all the options the user needs to be presented to begin playing a game:

In this chapter we're focusing on Internet connections, so we will continue with the mock-ups for these screens. Whenever you click New Internet, the player is given the opportunity to invite or challenge another player to play. When this screen loads, it should look like the one shown in Figure 8.11.

Figure 8.11. Amuck-Tac-Toe screen mock-up to invite a friend to play

This is the screen that collects the e-mail address necessary to initiate a game with a friend. Once he clicks the Invite button, the player who initiated the game must wait until the player he challenged accepts the challenge. In the event that the initiator closes the Amuck-Tac-Toe application before the friend accepts the challenge, the game is not aborted. The initiator can click Continue at any time to see if the opponent has accepted the challenge (Figure 8.12).

Figure 8.12. Amuck-Tac-Toe Continue Game screen mock-up

In Amuck-Tac-Toe, we allow players to connect using three different methods. Each of the three methods of connectivity follows a different paradigm. However, the game follows the same rules and workflow regardless of the connection method. For this reason we should abstract the connection details away from the game controller. One way to handle this is to put all of our connectivity logic in a black box that implements the same properties and methods for each of our connectivity types.

To achieve this type of abstraction, a factory pattern works well. You need a factory that instantiates each of your connection types and returns each of them on demand as a common interface. Following is the definition for the base interface and supporting types used in the example:

#import <Foundation/Foundation.h>
typedef enum {
   GameConnectionMessageError = 0,
   GameConnectionMessageConnect,
   GameConnectionMessageDisconnect,

   GameConnectionMessageSessionId,
   GameConnectionMessageData,
   GameConnectionMessageCustom
}  GameConnectionMessageType;
@protocol GameConnectionDelegate <NSObject>
@optional
- (void) receiveMessage:(NSString*)message
      ofType:(GameConnectionMessageType)messageType;
@end
@interface GameConnection: NSObject {
   id <GameConnectionDelegate> _delegate;
}
@property(nonatomic,assign) id /*<GameConnectionDelegate>*/ delegate;
- (void) connectWithPlayerName: (NSString*)playerName;
- (void) connectWithSessionId:(NSString*)sessionId;
- (void) sendMessage:(NSString*)message
      asType:(GameConnectionMessageType)messageType;
+ (GameConnection*) createWithName:(NSString*)gameConnectionClassName delegate:(id)gameConnectionDelegate;
@end

There is very little in the implementation of this interface. This class defines how a game connection should send and receive messages in a common fashion. Now the implementation can be deferred to overloading classes. This gives you the ability to extend your application by adding new implementations of the GameConnection class. Each implementation can introduce a new type of connection without changing the actual code for the Game View.

This class can also create the overloading class by passing in the name of the game connection class you want to create to the method createWithName: delegate:. Here are the details of this powerful method:

+ (GameConnection*) createWithName:(NSString*)gameConnectionClassName
   delegate:(id)gameConnectionDelegate {
   id obj = [[NSClassFromString(gameConnectionClassName) alloc] init];
   if (obj == nil) {
      [NSException raise:@"Invalid game connection class name" format:
         @"The game connection class '%@' was not found and cannot be created",
         gameConnectionClassName];
   }
   GameConnection *gameConnection = (GameConnection*)obj;
   gameConnection.delegate = gameConnectionDelegate;
   return gameConnection;
}

This method uses NSClassFromString to instantiate a GameConnection class from its name. If the class cannot be constructed, the method throws an exception. This method is very nice because now the class GameConnection can be completely oblivious to the implementation of any other GameConnection derivative classes.

Now that you have an understanding of how to separate your connection concerns, you can look at the details of this example that differ from the applications you have reviewed up until now. There are a lot of details to this application, but most should be quite familiar to you by now. You can download the full application source to the completed version (Figure 8.13) of Amuck-Tac-Toe from http://appsamuck.com/gamedevbook/amktactoe.

Figure 8.13. Amuck-Tac-Toe is an example of a multiplayer turn-based game.

Here are a few items that you may not be familiar with:

These items are fairly straightforward to grasp, and they add a tremendous amount of power to your application. We will start by examining the table view.

Presenting options with a table view

Even though we have not covered it, you should be familiar with the appearance of a table view. The UITableView is a very common element in iPhone development. You see it in many of the native apps, such as Settings, Contacts, and Phone. The UITableView is an ideal choice for you to use in your game menus, as shown in Figure 8.14.

In most cases, the UITableView works in close relation to a UINavigationBar. Together these two components create the slide in and out navigation you have become accustomed to on the iPhone. To create this effect, you need to implement the UITableViewDelegate method and push and pop view controllers to the navigation stack. The following listing comes from the main menu screen of Amuck-Tac-Toe, which does just that.

The method viewDidLoad is used to set up a background color that is tiled. This is done by creating a pattern image color:

- (void)viewDidLoad {
    [super viewDidLoad];
   // The title of the main view controller will be used as the title of the
   // navigation bar.
   // This is actually a nice feature of the MVC architecture because if you
   // decide to use a tab view instead it will use the same title.
   self.title = @"Amuck-Tac-Toe Menu";
   UIImage *backgroundImage = [UIImage imageNamed:@"chalkGreen.png"];
   self.view.backgroundColor = [[UIColor alloc]
      initWithPatternImage:backgroundImage];
   self.tableView.sectionHeaderHeight = 30.0f;
   [backgroundImage release];
}

Figure 8.14. Select how to connect to other players in the Amuck-Tac-Toe main menu.

The method numberOfSectionsInTableView: returns the number of sections in a given table view. In our table view we have two. The first is Connection Types and the second is About and Options:

#pragma mark Table view methods
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
    return 2;
}

Next, we need to implement the method tableView:numberOfRowsInSection. In this method we inform the UITableView how many rows to render per section.

// Customize the number of rows in the table view.
- (NSInteger)tableView:(UITableView *)tableView
   numberOfRowsInSection:(NSInteger)section {
   if (section == 0) {
      return 4;
   }
   else {
      return 2;
   }
}

The method tableView:cellForRowAtIndexPath: (Listing 8.1) is more involved, but you will get the hang of it soon enough. In this method you must return a properly initialized cell view for every row that is requested. You are given the section and row that are requested in the form of an NSIndexPath. Also notice that the cell views are being cached. This is very beneficial for performance. Constructing an object for every row takes time and consumes resources. Be sure to use the cache available to speed up your views.

Note

To download Listing 8.1, go to www.wileydevreference.com and click the Downloads link.

Example 8.1. Supplying Cell Data When the tableView:cellForRowAtIndexPath Method Is Called

// Customize the appearance of table view cells.
- (UITableViewCell *)tableView:(UITableView *)tableView
   cellForRowAtIndexPath:(NSIndexPath *)indexPath {
   static NSString *CellIdentifier = @"Cell";
   static NSString *SubtitleCellIdentifier = @"SubtitleCell";
   UITableViewCell *cell = [tableView
      dequeueReusableCellWithIdentifier:CellIdentifier];
   UITableViewCell *subtitleCell = [tableView
      dequeueReusableCellWithIdentifier:SubtitleCellIdentifier];
   if (cell == nil) {
   cell = [[[UITableViewCell alloc]
      initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier]
      autorelease];
    }
   if (subtitleCell == nil) {
      subtitleCell = [[[UITableViewCell alloc]

         initWithStyle:UITableViewCellStyleSubtitle
         reuseIdentifier:SubtitleCellIdentifier] autorelease];
   }

   if (indexPath.section == 0) {
      switch (indexPath.row) {
         case 0:
            cell.textLabel.text = @"Head-to-Head";
            cell.accessoryType = UITableViewCellAccessoryDetailDisclosureButton;
            return cell;
         case 1:
            cell.textLabel.text = @"Nearby";
            cell.accessoryType = UITableViewCellAccessoryDetailDisclosureButton;
            return cell;
         case 2:
            cell.textLabel.text = @"New Internet";
            cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;
            return cell;
         default:
            if (self.activeGameCount > 0) {
               subtitleCell.textLabel.text = @"Continue";
               NSString *gameText =
                  self.activeGameCount > 1 ? @"games" : @"game";
               subtitleCell.detailTextLabel.text = [NSString
                  stringWithFormat:@"%d %@ currently active",
                  self.activeGameCount, gameText];
               subtitleCell.accessoryType =
                  UITableViewCellAccessoryDisclosureIndicator;
               return subtitleCell;
            }
            cell.textLabel.text = @"Continue";
            cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;
            return cell;
      }
   }
   else {
      switch (indexPath.row) {
         case 0:
            cell.textLabel.text = @"Internet Settings";
            cell.detailTextLabel.text = @"Change your connection options";
            cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;
            return cell;
         default:
            cell.textLabel.text = @"About";
            cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;
            return cell;
      }
   }
}

The method tableView:viewForHeaderInSection: has been used to customize the appearance of the head on each of our sections. All we need to do is supply a UIView for each header callback:

- (UIView *)tableView: (UITableView *)tableView viewForHeaderInSection:
  (NSInteger)section {
   UIView *headerView = [[UIView alloc] initWithFrame:CGRectMake(0, 0,
      self.tableView.bounds.size.width, 30)];
   UILabel *headerLabel = [[UILabel alloc] initWithFrame:CGRectMake(10, 0,
      headerView.bounds.size.width, 30)];
   headerLabel.backgroundColor = [UIColor clearColor];
   headerLabel.font = [UIFont boldSystemFontOfSize:18];
   headerLabel.textColor = [UIColor whiteColor];

   if (section == 0)
      headerLabel.text = @"Game";
   else
      headerLabel.text = @"Preferences";

   [headerView addSubview:headerLabel];
   return headerView;
}

There are a handful of methods that push a view on the UINavigationBar. The one here serves as a sample of how to accomplish this. The push occurs when pushViewController:animated: is called:

- (void) startNewInternetGame {
   NewInternetGameMenuViewController *newInternetGameMenuViewController =
      [[NewInternetGameMenuViewController alloc]
         initWithNibName:@"NewInternetGameMenuViewController" bundle:nil];
   [self.navigationController
      pushViewController:newInternetGameMenuViewController animated:YES];
   [newInternetGameMenuViewController release];
}

A little deeper in the code, the Game View is loaded. Following is an example of how this is done. This is where the abstraction we talked about earlier in the chapter comes into play. The GameViewController is created and a game connection is injected into it. This injection type is based on the game class name we pass to GameConnection:createWithName: delegate: as follows:

GameViewController *gameViewController = [[GameViewController alloc] initWithNib
   Name:@"GameViewController" bundle:nil];
gameViewController.gameConnection = [GameConnection
   createWithName:@"InternetGameConnection" delegate:gameViewController];

gameViewController.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal;
self presentModalViewController:gameViewController animated:YES
   [gameViewController release];

Finally, the method tableView:didSelectRowAtIndexPath: is implemented to fire the appropriate response to the main menu selection:

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:
   (NSIndexPath *)indexPath {
    if (indexPath.section == 0) {
       switch (indexPath.row) {
          case 0:
             [self startNewHeadToHeadGame];
             break;
          case 1:
             [self startNewNearbyGame];
             break;
          case 2:
             [self startNewInternetGame];
             break;
          case 3:
             [self continueGame];
             break;
       }
   }
   else {
       switch (indexPath.row) {
          case 0:
             [self showSettings];
             break;
          case 1:
             [self showAbout];
             break;
       }
   }
}

At this point you can handle many of the basics of game development. A new challenge is connecting to other players who are connected to the Internet. We discussed this feature earlier, and fortunately, it is actually a very straightforward process to code on the client.

Earlier you reviewed the GameConnection class and how it is used to abstract the connection details away from the game. We are now going to focus on the class InternetGameConnection that extends the class GameConnection and handles Internet-based connections:

#import <Foundation/Foundation.h>
#import "GameConnection.h"
#define SERVICE_END_POINT @"http://services.appsamuck.com/turnbased/"
@interface InternetGameConnection : GameConnection {

   NSString *serviceEndPoint;
   NSString *responseData;
   NSURLConnection *urlConnection;
}
@property (nonatomic, retain) NSString *responseData;
- (void) apiConnectWithSessionId: (NSString*)sessionId;
- (void) apiConnectWithPlayerName: (NSString*)playerName;
- (void) apiSendMessage:(NSString*)message
      asType:(GameConnectionMessageType)messageType;
@end

In GameConnection, the method connectWithPlayerName: is called when a player wants to initiate a new game with a friend. This method is actually implemented in the class InternetGameConnection. Walking through this call shows you how Internet connectivity is achieved. This method is simply a pass-through with a sentinel. The parameter playerName is checked with the sentinel and the pass-through call to apiConnectWithPlayerName is issued:

- (void) connectWithPlayerName:(NSString*)playerName {
   [super connectWithPlayerName:playerName];
   if ([playerName length] == 0)
      [NSException raise:@"Parameter required"
         format:@"Parameter playerName cannot be null or empty"];
   [self apiConnectWithPlayerName:playerName];
}

The method apiConnectWithPlayerName issues a request to the Internet server, which begins the Web request process. This is the same process that is followed when you start a Google search in your browser.

The method builds an NSMutableURLRequest and uses an NSURLConnection to issue the request with a call to connectionWithRequest. The call to connectionWithRequest is followed by a call to start, which starts the request process. The important thing to observe is that this is only the beginning of the process. InternetGameConnection implements the NSURLConnectionDelegate methods necessary to receive the server response:

- (void) apiConnectWithPlayerName: (NSString*)playerName {
   NSString* content = [NSString stringWithFormat:@"playerName:%@", playerName];
   NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:
      [NSURL URLWithString: [SERVICE_END_POINT stringByAppendingString:
      @"connectWithPlayerName"]]];
   [request setHTTPMethod: @"POST"];
   [request setHTTPBody:[content dataUsingEncoding: NSASCIIStringEncoding]];

   self.responseData = [NSString stringWithString:@""];
   urlConnection = [NSURLConnection connectionWithRequest:request
      delegate:self];
   [urlConnection start];
}

After the request has been sent, NSURLConnection receives a response either in the form of data or an error (hopefully it's data). If you do receive data, it arrives as a call to the delegate method connection didReceiveData:. It is also possible—and likely—that the response will be too large to arrive in one piece. If this happens, the data is broken up and arrives in chunks. This results in multiple calls to connection:didReceiveData:. Each call appends the received chunk to the property responseData. Finally, connectionDidFinishLoading is fired, which informs you that all the pieces of the response are received and the complete reconstituted data can be retrieved from the property responseData:

#pragma mark NSURLConnection delegate methods
- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data {
   NSString *stringReply = [[NSString alloc] initWithData:data
      encoding:NSUTF8StringEncoding];
   self.responseData = [self.responseData stringByAppendingString:stringReply];
}

The data you receive from the server is entirely up to you and depends on how you wish to communicate with your Web server. If you are looking for a standard, REST (representational state transfer) is a good choice for iPhone development because making calls to REST is very straightforward. The class URLConnection is all you need on the client. There is a lot to implementing a Web server, a discussion that is outside the scope of this book. Check out www.appsamuck.com/gameservices/ for more information.

REST is not the only protocol available; Web services come in many different flavors. For example, SOAP (originally defined as Simple Object Access Protocol) is a mature protocol that has been around for a while. However, there is currently no native support for SOAP in the iPhone SDK. You could spend countless hours building a SOAP client from scratch. Fortunately, there are tools available that have already done the work for you. For example, RemObjects Software (www.remobjects.com/iphone) has a SOAP Web service framework that fills this gap. They also offer a free tool for quickly setting up a push notification server. Third-party tools do come with a price, but they can be huge timesavers and the cost is almost always less than what it would cost you to take the time to do it yourself.

As we've mentioned, connectionDidFinishLoading is called whenever the complete response has been received from the server. When this happens, you call receiveMessage:ofType:, which sends the complete message to the delegate GameControllerDelegate:

- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
   GameConnectionMessageType messageType = GameConnectionMessageData;
   [self.delegate receiveMessage:self.responseData ofType:messageType];
}

When an error is encountered, connection:didFailWithError: is called. You retrieve the message description and again call receiveMessage:ofType:, which sends the complete error message to the delegate GameControllerDelegate:

- (void)connection:(NSURLConnection *)connection
   didFailWithError:(NSError *)error {
   GameConnectionMessageType messageType = GameConnectionMessageError;
   NSString *message = [error localizedDescription];
   [self.delegate receiveMessage:message ofType:messageType];
}

- (void)applicationDidFinishLaunching:(UIApplication *)app {
   [[UIApplication sharedApplication]
      registerForRemoteNotificationTypes:(UIRemoteNotificationTypeBadge |
      UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)];
}

- (void)application:(UIApplication *)app
   didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)devToken {
   self.devTokenBytes = [devToken bytes];
   self.registered = YES;
}

- (void)application:(UIApplication *)app
   didFailToRegisterForRemoteNotificationsWithError:(NSError *)err {
   NSString *message = [NSString stringWithFormat:@" Error in registration.
      Error: %@", err];
   UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Error"
      message:message delegate:nil cancelButtonTitle:@"OK"
      otherButtonTitles:nil];
   [alert show];
   [alert release];
}