iPhone Game Development - Chris Craft [116]
Designing the application
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.balsamiqcom). 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:
Head-to-Head. Choose this option if a player wishes to play a friend sitting next to him using the same device.
Nearby. Choose this option if a player wishes to play a friend nearby on a second device.
Internet. Choose this option if a player wishes to play a friend remotely over the Internet.
Continue. Choose this option if a player wishes to continue a previous game that has not been completed. This allows for a game to be played over the course of days or weeks.
Internet Settings. This option allows the player to change his e-mail address used for identification.
About. This option loads a standard About screen with information about the creators of the 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).
Note
If you are clever in your implementation, you can allow your players to manage several games at once with different friends. This is a great advantage of turn-based games that may not always be feasible in real-time games. When you add push notification to your game, the process gets really powerful. Now, when your friend accepts the challenge, the notification can display as an alert even when the Amuck-Tac-Toe application is closed.
FIGURE 8.12
Amuck-Tac-Toe Continue Game screen mock-up
Abstracting for separation and reuse
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 typedef enum { GameConnectionMessageError = 0, GameConnectionMessageConnect, GameConnectionMessageDisconnect,