TweetFollow Us on Twitter

Happy Face CTB Game

Volume Number: 13 (1997)
Issue Number: 2
Column Tag: Communications Toolbox

HappyFace

By Mark Chally, Covina, California

Using the Communications Toolbox to build an interactive, two-player game

The purpose of this article is to implement a simple, two-player, interactive game as a means to explore Apple's Macintosh Communications Toolbox. It includes methods for using the Connection Manager to send and receive information. This article builds on the fundamentals learned in the DebugTerm article, found in MacTech 12.10 (October, 1996).

Introduction to HappyFace. Where did it come from?

After DebugTerm went to press, I suggested a follow-up article to further exploit the CTB. I thought a simple game would be entertaining and instructive. Time was short, but the challenge was exciting. Of several possible game ideas, HappyFace was the clear choice, having the advantages of simplicity and entertainment value.

Long before Barney the dinosaur would be loathed by adults everywhere, there were happy faces. Surely you remember the little yellow pill-shaped guys with Kool-Aid grins, found on T-shirts, pins, and bumper stickers accompanied by "Have a Nice Day." Soon, T-shirts displayed happy faces with bullet holes in their foreheads from which blood oozed. Later, arcade games appeared in which players would use mallets to strike gophers' heads as they poked up through holes. Finally, Mike Darweesh wrote the Macintosh game "Bonk," based on the gopher games. In Bonk, players click on silly heads as they appear in a grid, before they disappear - at progressively shorter intervals. HappyFace was inspired by that weird combination of sarcasm and gaming.

How do you play it?

HappyFace is a two-player game that gives you the opportunity to smack those little yellow critters. You use the CTB to connect with your opponent. HappyFace does not care what tool is used to establish the connection, but it does expect the tool to support a means to simultaneously send and receive data using the standard CTB functions. Most, if not all connection tools do this. You earn points by striking the faces as they appear on a grid. The first player having 25 points wins.

When launched, if HappyFace cannot find the preferences file in the program's folder it poses the Connection Settings dialog (Figure 1).

Figure 1. Connection Settings Dialog with Apple Modem Tool's default options.

If the user cancels the dialog, the program beeps and aborts. Otherwise, it creates a game window with 64 squares, eight rows and eight columns. HappyFace then waits for the user to establish a connection, which is initiated using the Connect, Listen, and Settings items on the Connection menu.

Once a connection has been established, either player may select New Game from the File menu. When the game begins, each player's copy creates five happy faces which inhabit randomly selected squares in both players' windows (Figure 2).

Figure 2. The HappyFace window with no faces struck.

Each player may then strike happy faces by clicking on them using the cursor - which becomes a mallet whenever it is positioned over the window. As the faces are struck, their features (eyes and mouths) change color and shape. Faces which have not been struck have blue features. Those struck by the player using the local copy receive green features, and those struck by the opponent receive red ones (Figure 3).

Figure 3. The HappyFace window with faces struck by both players.

One second after each face has been struck it dies and vanishes. The copy of HappyFace which created the face (the local copy or the opponent's) replaces it with a new one that inhabits another randomly selected square. The first player to strike 25 faces wins, at which time a dialog is displayed by each copy to inform the users of the good or bad news. When no game is in progress there is no mallet, and any faces remaining do not respond to being clicked. At any time during the connection a new game can be started, including while one is in progress. If a user quits while connected, the connection is closed. If a connection is closed, any game in progress ends.

CTB Recap and Comparison to DebugTerm

What is DebugTerm, and why read about it?

In the DebugTerm article, I implemented a C source file that could be compiled into a program under development to export debugging information through a CTB connection. It made a good introductory project because it required minimal CTB services. If you have not read it, I strongly suggest that you do since it provides an introduction to the CTB and some base code for HappyFace. In short, this article builds on that one.

Where did DebugTerm fall short?

DebugTerm is a good start, but not a complete program. Serving as a debugging tool, it takes shortcuts in opening and closing a connection that a user-friendly program should not. Secondly, it only sends information, it does not know how to receive it. Additionally, it only initiates a connection using CMOpen() to connect with another device or program; it does not know how to use CMListen(). Finally, it asks the connection tool not to use windows or menus, thus requiring no event processing. HappyFace addresses these new issues.

Making a Complete Application

Isolating connection logic

HappyFace behaves as a CTB program should. It initializes the CTB and creates and configures a connection record at launch time. However, CMOpen() is not executed until the user wishes to open a connection. In contrast, DebugTerm executes CMOpen() immediately after creating and configuring the connection record. DebugTerm also disposes of the connection record at the same time that it closes the connection. HappyFace waits until quitting time to dispose of the connection record, at which time it also saves the configuration. For this reason, the process of opening and closing connections is simple and reliable.

It pays to CMListen

Besides isolating the initialization from opening and the disposal from closing, HappyFace also adds a new and important way to connect: CMListen(). Some tools require one party to use CMListen() while waiting for the other to initiate the connection using CMOpen(). For example, in response to CMListen(), the Apple Modem Tool waits for a telephone call from another modem. The AppleTalk ADSP Tool registers itself on the network and waits for a connection request from an ADSP Tool using CMOpen(). Both expect the application to respond to CMOpen() by accepting the connection using CMAccept(). The Serial Tool does not support CMListen(). It uses CMOpen() to establish a connection through the serial port you choose. Unlike most tools, it does not care about whether anything is at the other end of the serial cable. HappyFace does another important thing that DebugTerm did not do - it polls the connection for incoming messages using CMRead().

Handling the interface

In addition to those details, HappyFace also accepts a new realm of responsibilities. It maintains a Connection menu that allows the user to decide when and how to choose and configure a tool, and establish a connection. This means that HappyFace has the duty of maintaining these menus, in addition to the events, most of which it passes along to the connection tool via CMEvent(), CMActivate() and CMResume(). These events may also be generated for additional windows or menus that HappyFace permits the tool to create and maintain. Certain events can be identified as belonging to the tool and passed along. HappyFace detects and delegates these.

Encapsulating CTB code

Virtually all of these activities, which relate solely to maintaining a CTB connection, are contained within CTB.c. HappyFace, merely an example of a CTB application, can take advantage of this by installing a few MENUs, passing along important events, and making a few simple function calls. The ease with which CTB.c can be used is apparent since CTB.h profiles only a few simple function calls.

Encoding a game message

There are three game actions requiring messages: start a new game, create a face, and strike a face. Communication logic is simplified by stuffing an entire message into a single byte of the form AAHHHVVV.

The first two bits represent the game action, the next three represent the horizontal position if applicable, and the last three represent the vertical position if applicable. Some bitwise manipulation is required when sending and receiving the message, but the utility of treating a single incoming character as an entire message greatly simplifies things.

Test Spin

Before exploring the workings of HappyFace, let's watch the game in action. There are many ways to connect using the CTB, but you should consider the following points that you may find remarkably similar to those of the DebugTerm article.

Means of Connection

If you have an AppleTalk network or intend to demo HappyFace on a single Mac, I recommend that you connect using the AppleTalk ADSP Tool. Otherwise, I recommend the Serial Tool. If you choose the Apple Modem Tool you can connect by modem, but probably will not have the opportunity to see both copies of HappyFace side-by-side. You may choose to use another tool, in which case I am interested in hearing about your experiences.

Using the Serial Tool you can connect two Macs, or even connect a Mac's modem port to the same Mac's printer port. To use the Serial Tool, you will require a null modem cable. This is the cable used for most printers and to communicate with a Newton by serial port. It is up to you to get the connection right, but if it works between terminal programs, it should work for HappyFace.

If you choose the AppleTalk ADSP Tool, you can connect between two Macs on a network, or from one Mac to itself. To connect a Mac to itself with the AppleTalk ADSP Tool no physical connection is necessary, but be sure AppleTalk is turned on in the Chooser or the tool will not load. If you need a copy of the AppleTalk ADSP Tool, you can find it on one of Apple's FTP sites. You may also find what you need on ETO or the CTB SDK. HappyFace needs the Communications Toolbox, 32-bit QuickDraw with at least a 16-color monitor setting, and the Sound Manager. It would be a good idea to use System 7.5 or later since HappyFace does not use Gestalt to check these.

Connecting to Yourself

If you choose to connect the Macintosh to itself, either by using the AppleTalk ADSP Tool for a virtual hookup, or Serial Tool from modem to printer port, you should keep one thing in mind. To connect a Macintosh to itself, you must use asynchronous calls. See the diatribes in the DebugTerm article about asynchronous calls and completion routines. HappyFace also has an "empty" completion routine. To allow a connection between two copies on the same machine, I compiled HappyFace using asynchronous calls. Though many readers without two Macs may wish to take advantage of this feature, you will find HappyFace awkward to play as a two-player game when both copies are on the same machine. Also, the HappyFace I compiled is a fat binary so that it will run native on PowerPC machines.

Bang Away!

You will need to use two instances of HappyFace. Ideally, these instances would be run on separate machines. However, if you want to run both copies on the same machine, simply make an additional copy in another folder and launch each separately. Preferences are stored in the application's folder. If you have already run HappyFace, you may wish to throw away the file named "HappyFace Prefs."

Launch one copy of HappyFace. If it finds no preferences file, it poses the Connection Settings Dialog before allowing you to do anything else. If not, select Settings from the Connection menu. In the dialog, use the Method popup to choose the connection tool you wish, such as the Serial Tool or the AppleTalk ADSP Tool (Figure 4).

Figure 4. Connection Settings Dialog with the AppleTalk ADSP Tool's options.

If you chose the AppleTalk ADSP Tool, you may choose a name for the machine by typing what you wish into the Local Name: field in the lower-right-hand corner. It is probably best not to change the Connection Type field, but if you do, both instances of HappyFace must have the same type. Press the OK button.

If you chose the Serial Tool, you can select the port settings that you require. The ones displayed are probably the best (Figure 5).

Figure 5. Connection Settings Dialog with the Serial Tool's options.

Regardless of how you set them, they should all be set the same for both copies of HappyFace, and the Current Port should be set to whichever port your cable is plugged into. Press the OK button.

If you chose the AppleTalk ADSP Tool, choose the Listen item from the Connection menu. You can tell that HappyFace is listening for a connection because the Listen item now reads Stop Listening, and the other items on the Connection menu are dimmed.

If you chose the Serial Tool, choose the Connect item from the Connection menu. You can tell that you are connected (to the serial cable) because the Disconnect item is now enabled and the other items on the Connection menu are dimmed.

Now you are ready to connect the second copy of HappyFace to the first. Launch the second copy. If you chose the AppleTalk ADSP Tool, choose it again from the second copy. You should see the name of the first, listening copy in the scrollable list on the right-hand side under the Name field. You may need to find the AppleTalk Zone that the first copy is in from the list on the left-hand side, under the Zone field. Select the name of the first copy, and press the OK button.

If you chose the Serial Tool, select the same settings as in the first copy, except the modem or printer port as necessary. Press the OK button.

Now select Connect from the Connection menu. The two copies of HappyFace should be ready to start a game. You can tell they are connected because the New Game item on the File menu, and the Disconnect item on the Connection menu are now enabled, and all the other items on the Connection menu are dimmed. If you select New Game from the File menu ten happy faces should appear in each window.

Use the cursor (mallet) to strike faces in each copy. You should see something like Figure 3 when faces are being struck from both copies. Notice how the features of a face struck locally become green, but those of one struck by an opponent turn red. Notice that HappyFace allows one second to pass before the face you struck "dies."

Normally the game ends when a player strikes 25 faces. Quitting either copy by selecting Quit from the File menu or closing the HappyFace window breaks the connection. Selecting Disconnect from the Connection menu also ends any game in progress. Continue to play as many games as it takes to get a feel for it.

Source Code Walk-through

HappyFace was written in C, using Metrowerks CodeWarrior Integrated Development Environment (IDE) 1.7. I used two project files - one for 68k, and one for PowerPC. If you use Symantec, MPW, or some other development system, you should not have much trouble creating project files. You will either want to print a copy of the source code or view it on your monitor alongside the article.

Overview

This project is divided into three separate code domains. The file CTB.c isolates the CTB code so that it can be used, much as a library would, along with CTB.h. It should require little modification to be included within another project. It contains private data structures and functions specific to the operation of the CTB. CTB.h contains useful constants and function prototypes to #include in other source files. Game.c contains functions and private data structures that are specific to the game logic, but have no specific knowledge of the CTB. Game.h contains prototypes for the Game.c functions that Main.c needs to call. Main.c contains the "boilerplate" code necessary to launch the program, handle simple events, maintain the cursor and menus, and quit.

Header files

CTB.h is similar to DebugTerm.h. In addition to function prototypes, it contains shared resource ID's, and literals for parameters and common error codes. I shamelessly kept the error codes from DebugTerm, although I could have developed a more extensive set. The literals, such as kAsync, help make the code readable. Game.h has prototypes to game functions that are called by Main.c.

CTB.c

This file contains C code necessary for Communications Toolbox connections. You are already familiar with most of it, having read about DebugTerm which was extended from DebugTerm.c. We now concentrate on new or modified functions.

It begins with a #include to CTB.h, then defines its literals and globals. One of the "new" features is a group of Universal Procedure Pointers (UPP), such as gCMCompletion, for PowerPC compatibility.

CMWriteProc(), formerly CMSendProc(), is unmodified. However, you should inspect it closely since I originally uploaded an outdated version of CMSendProc(), which I have since replaced with a more correct version.

ConnEvent() handles events for a connection tool window. It is called from the event loop to give the connection tool the first opportunity to handle the event. CTB tools poke their own handles (e.g. ConnHandle) into the refcon fields of their windows. Therefore, ConnEvent() finds the window associated to theEvent. Next, it makes sure it has a valid WindowPtr and ConnHandle. If not, it returns false, else it checks to see if the window's refcon is the same as the ConnHandle. If they are not the same, it returns false. Otherwise it returns true, indicating that the event was handled, after calling CMEvent() to delegate the event to the connection tool, which handles the event if appropriate.

ConnActivate() informs a connection tool of an activate event. Called from the place in the event loop where activate events are trapped, it passes the message on to the connection tool, indicating whether the window is being activated or deactivated. ConnActivate() saves the current GrafPort and sets it to the given window before calling CMActivate(), then restores the current GrafPort. I found this behavior, taken from sample code in Inside CTB, odd. I would have expected the WindowPtr to be passed as a parameter instead.

ConnResume() is structurally identical to ConnActivate(). It informs the connection tool of a resume (or suspend) event. The resuming parameter indicates whether the application is being suspended or resumed.

putc(), provided for simplicity, calls CMWriteProc() to send the character it receives as a parameter. It returns whatever value it receives from CMWriteProc().

CMReadProc() attempts to read *theSize characters by calling CMRead(). If gConn is not nil, it returns the value obtained by calling CMRead(). If there is no connection record, it passes back 0 as *theSize. This version of HappyFace always issues CMRead() calls synchronously to make the article simpler. Next time, we will need to expand its capability. CMReadProc() is a Pascal function so it can be called by the Terminal Manager or the File Transfer Manager in a broader implementation.

getc() tries to read a single character by calling CMReadProc(). If it finds none, it places a NULL in c. It returns whatever error CMReadProc() encounters.

InitCTBStuff(), essentially the same function as its DebugTerm counterpart, additionally generates UPPs for the CMCompletion(), CMWriteProc(), and CMReadProc() by calling the appropriate managers' functions.

ChooseConnection() has been modified to behave better in a modeless program environment. Now kNothingChosenErr is only returned if cancel is pressed (so that it can be trapped at startup when no preferences are found). It still returns noErr if the current tool is reconfigured or a different tool is selected, since we do not need to care because we never allow this dialog to be posed while connected. In all other cases, it returns whatever CMChoose() does.

NewConn() is one of three functions that replaces the functionality of DebugTerm's OpenDebugTerm(). NewConn() handles most of its functionality, making it almost identical. NewConn() does not call WritePrefs() or CMOpen() where OpenDebugTerm() did. These tasks are left to DisposeConn() and OpenConn(), respectively. It does a few additional things, however. It initializes gFlags to false, which, when passed to CTB functions, (currently, according to Inside CTB) indicates that we do not wish to send end-of-block indicators. It also passes the async parameter through to the global variable gAsyncCalls and sets gPrevStatus to an impossible token value, which will cause the status to be re-evaluated in IdleConn(). Finally, it calls GetMenu() for the handle to the Connection menu, which was installed in the main program. If NewConn() encounters an error, it returns it, else it returns noErr.

OpenConn(), called when the Connect item is selected from the Connection menu, calls CMOpen() to open a connection. First, however, it verifies that the connection record exists. It returns whatever value CMOpen() returns.

ListenConn() is called when the Listen item (or Stop Listening) is selected from the Connection menu. It first verifies that a connection record actually exists, and if so, it calls CMStatus(). If CMStatus() indicates that the tool is already listening for a connection, it calls CMAbort() to stop listening, else it calls CMListen(), instructing the tool to wait indefinitely (-1) for a connection. Unlike most functions which can be called synchronously or asynchronously, HappyFace calls CMListen() asynchronously regardless of the value of gAsyncCalls. It does this because some tools, such as the AppleTalk ADSP Tool, provide no opportunity to stop listening when asked to wait indefinitely. Using the asynchronous call allows the user to select Stop Listening, which causes ListenConn() to call CMAbort(). Some tools, such as the Serial Tool, do not support CMListen() at all, and return cmNotSupported. If an error occurs, the error is returned, else noErr is returned.

CloseConn() is one of two functions that split the duties previously performed by CloseDebugTerm(). When the user selects Disconnect from the Connection menu, it first verifies that the connection record exists, then verifies that the connection is open or opening. If so, it calls CMClose() to drop the connection.

DisposeConn() is the second of the two functions that split CloseDebugTerm()'s duties. Called before HappyFace exits, it first verifies that the connection record exists, then calls WritePrefs(). Once the preferences have been written, it closes the connection by calling CloseConn(), unlocks the connection handle, and calls CMDispose() to deallocate the connection record and any other data the tool may be using. Finally, it sets the connection handle to nil, and reports noErr. DisposeConn() does not report any error unless there is no connection record, because it is only called at application exit. In fact, it calls CloseConn() without checking to see if connected. It could check that first, and it could also report any errors returned by CloseConn() or CMDispose().

IdleConn(), called during each iteration of the event loop, performs periodic tasks necessary to support a connection tool. It begins by verifying that a connection record exists, and if not, it disables the connection menu items. Otherwise, it begins by calling CMIdle(), which gives the connection tool its housekeeping opportunity. Next, it checks the connection status. If an error occurs, it returns it, else if the tool has sensed an incoming call (cmStatusIncomingCallPresent) it calls CMAccept() to establish a connection. If the connection status has changed, it updates the Connection menu accordingly, updates the online parameter, updates gPrevStatus and returns any error that occurred.

DoConnMenu(), called by the main application's DoMenu() function when a connection menu item is selected, calls the appropriate CTB.c function. It doesn't bother to report or return errors, though you may wish to. It beeps in the case of an error, except kNothingChosenErr, returned by ChooseConn(). This is because kNothingChosenErr results from pressing the Cancel button, which is fine when resulting from a menu selection.

Game.c

This file contains functions to control the game activity, but no code specific to the CTB. It begins with a few groups of literals. Those in the first group denote spacing and graphics proportions. Those of the second indicate whether a square is occupied, and if so, what condition the occupying face is in. Those in the next control the bounds of the game logic. Following that are the codes for the possible game actions. Messages sent through the connection have these codes in the first two bits to indicate that a face has been made or struck, or that a new game has been started. Being a two-bit code, the possibilities are 0-3; 0 is skipped to avoid confusion with the NULL character. The literals in the last group are resource IDs.

Next in Game.c is the struct used to store information for a square.

typedef struct {
 short occupant; // kEmpty, kHealthy, kStruckLocally, kStruckByOpponent
    long age;               // TickCount() at status change
    Rect boundsRect;    // Bounding rectangle for gSquare
    Boolean madeLocally;// Keep track of whether made locally
} contents;

The occupant field contains a square's status. The age indicates at what TickCount() the square's status last changed. We want a face to take one second to die, so we have to watch the time. boundsRect holds the local coordinates of the square's rectangle. madeLocally indicates whether the local copy or opponent's copy created the face.

In the interest of fairness, we make sure that each copy maintains a fixed number of faces. When a face is created, it takes a variable amount of time to transmit the creation message to the opponent's copy. Using the convention introduced here, the players' individual copies effectively take turns. Thus, each player has a "net equal time delay" in the sum of the differences between the times at which faces are created and become visible.

Next is a group of globals, kept private to game.c using the static keyword. These are some of the most notable globals: gPixMapHand is an array of the pixmaps used to store the different drawn faces so that they can be copied to the game window. gMadeCount is used to represent the number of currently-living faces a copy has created. gLocalStruckCount and gOpponentStruckCount are used for keeping score. gSquare is the array of square contents. gStrikeHand and gSndChannelPtr are used to play the striking sound. gPicRect is a Rect with its top-left corner at the origin and the height and width of a square.

PlayStrikeSound(), called when a face is struck, verifies that the handle to the sound and pointer to the sound channel are valid, then calls SndPlay() asynchronously.

ShowScores() is called when a game ends to display the scores to each user. It counts the points up first to see if the game was actually played. If faces have been struck, it converts the numbers to strings using NumToString(), uses ParamText() to preload text for the Dialog Manager, then calls Alert().

DrawSquare() draws the appropriate image in the appropriate place on the game window. First it assures that the parameters, h and v, are within the valid range of rows and columns, then it sets the current GrafPort to the game window after saving the old GrafPort. It calls CopyBits() to copy the contents from the appropriate pixel map we already created to the appropriate place in the window. Finally, it restores the current GrafPort.

NewGame(), indirectly called when either player selects New from the File menu, initializes the game status variables, sets each square's contents as empty, and draws each square.

MakeGWorld(), borrowed from the Dave Mark article, calls NewGWorld() to allocate a fresh default GWorld to store squares' graphics in.

NewGameWindow(), called at application launch, initializes everything on which the game's logic rests. It begins by seeding the random number generator with the long integer which represents the current date and time. Then it attempts to create a new sound channel and load the SND resource for the strike sound, which it moves into high memory and locks if successful. Note that the sound playing code does not attempt to play the sound if either of these could not be allocated. Next, it calculates the size and position of the window, calls NewCWindow(), fills the gSquare array with empty squares, and calculates their rectangles. For each of the four graphics used to draw squares, it loads the pixel maps and draws them into their own separate GWorlds. Most of this was also taken from Dave Mark. Finally, it calls ShowWindow() to make the new window appear on the screen.

KillStruckFaces() is called by the IdleGame() function each time through the event loop. It looks at each square and determines if the square contains a face that has been struck by a player. If so, and if it was struck more than one second ago (kDyingTime), it makes the square empty, assigns the time of vacancy, redraws the square, and if the face was made by this copy it decrements the number of living faces made by this copy. Because gMadeCount will be less than kMaxMade, this will result in the eventual creation of a new face.

UpdateGameWindow(), called in response to an update event, saves the current GrafPort and sets it to the game window. Next it finds the Rect bounding the update region and uses it to decide which squares are in the region. After it has determined what range of rows and columns it needs to draw, it calls BeginUpdate() to keep from generating additional events, and draws them top-left to bottom-right. It calls EndUpdate() to cancel BeginUpdate() and sets the current GrafPort back to the saved one.

ShowStruckFace() is called when a face has been struck. It receives the horizontal and vertical location of the face, and whether the strike was local or by the opponent. It uses those parameters to update the square's information and redraw the square. Before returning, it plays the strike sound.

SendGameAction() assembles a game message and sends it. The message has three parts. The rest of the communication logic is greatly simplified by stuffing an entire message into a single byte. The first part is a two-bit action indicator, the next three bits indicate the horizontal component of the square's location, and the final three indicate the vertical component of the square's location.

First it loads the action indicator into the character, then shifts three bits to the left so that it can add in the horizontal component. Then it shifts three more bits to the left and adds the vertical component. Finally, it calls putc(), whose return value it also returns, to send the character.

SendNewGame() asks SendGameAction() to send a message with the kActionNewGame indicator through the connection (the horizontal and vertical components do not matter).

HandleOpponentStrike() is called in response to having received a message which indicates that the opponent has struck a face. First, it increments the opponent's score. Next, if the opponent has reached the winning score, it stops the game. Then, if the face is actually healthy, it calls ShowStruckFace() to change its status and redraw it. It always gives the opponent credit, but does not always change the square's status. It is theoretically possible for both players to strike a face "at the same time" and for the messages to "cross in the mail." Instead of using a tie-breaker to resolve the conflict, it gives both players credit. It does not draw in response to this case, because that would cause a face to change from green to red or red to green.

HandleWindowClick() is called when a mouse click in the game window is detected. First it determines which square, if any, was clicked, by reducing the Point to local coordinates and dividing by the pixel offset between squares. As an added protection, it verifies that the calculated value is in range, to avoid addressing a non-existent array member. If the row and column are valid and there is a healthy face in the indicated square, it uses SendGameAction() to inform the opponent of the successful strike. If no error is returned, it increments the player's score and compares it to kWinningScore. If the score has exceeded the winning score, the game will be stopped. It calls ShowStruckFace() to indicate to the user that the face has been struck.

ShowFace() puts a healthy face on a given square. It sets the square's status to indicate a healthy face, sets the age to TickCount(), and sets madeLocally according to the parameter that it receives. Finally, it calls DrawSquare() to draw the face in the game window.

MakeFace() is called when IdleGame() determines that it must place another face on the window to meet its quota, kMaxMade. First it randomly chooses a row and column, repeatedly, until an empty square is found. Next it informs the opponent's copy that it has created the face, and calls ShowFace() to show the user. Finally, it increments gMadeCount, the number of currently-living faces that have been made by the local copy.

HandleGameAction() dispatches game actions which have been received to the appropriate function, according to the action type. In some cases it starts or stops a game. Therefore, it passes back the resulting value of inProgress.

GetGameAction() is called by IdleGame() each time through the event loop. It determines whether a game message is waiting, and if so, dispatches it. First it calls getc() to read the character. If the character is not NULL and there is no error reading, it processes it. It extracts the action indicator by rotating a copy of the byte 6 bits to the right. Next it rotates another copy three bits to the right and looks at the least-significant three bits, which become the horizontal component. The least-significant three bits of the original become the vertical component. Finally, it delegates the interpretation of the message to HandleGameAction().

IdleGame() gets called once from each iteration of the event loop. It first calls GetGameAction() to dispatch any opponent actions waiting. Next it calls KillStruckFaces() to remove any faces struck more than one second before. If the game is still in progress and the number of faces is less than the quota, it calls MakeFace().

Main.c

Activities not specific to communications or game logic are conducted within this file. That leaves calling the procedures necessary for initializing the program, dispatching events, and quitting. Since most of us have seen this repeatedly, we will brush over the bulk of the code, discussing only the unusual or confusing parts of this file.

It begins by defining literals and usual globals. Some globals of note are gHammerHand, which points to the mallet cursor; gGameInProgress, which indicates whether a game is being played; and gOnline, which indicates that a connection is open.

ExitNow() is used as an emergency exit, while DoQuit() is called when a user chooses Quit from the File menu. Both call DisposeConn(), which makes sure the connection is closed if possible. DoQuit() also shows the scores if a game was in progress, because there will be no chance for the event loop to detect that the game ended.

InitApp(), in addition to calling SetupMenus(), also does a few other things. It allocates the hammer cursor's structure, moves it in to high memory, and locks it. It calls NewConn() to install a connection record, and if it fails, beeps and quits. It calls NewGameWindow() to create the game window and initialize supporting game logic, then finally initializes Main.c's own globals, gOnline and gGameInProgress.

DoMenu() handles menu selections in the usual way, with some exceptions. Since HappyFace adjusts the cursor, it provides an arrow cursor before putting up the About box. It sets gGameInProgress to true when a new game is started. Notice that it calls DoConnMenu() to delegate a selection from the Connection menu. It does this because it knows the menu's ID. There may be a less application-specific way to sense and handle Connection menu selections. Perhaps ConnEvent() could sniff them out instead.

AdjustCursor() was one of the more pesky details of this project. Called from various places in the event loop, it changes the cursor, if appropriate. According to some Apple documentation, you can set it up so that it only gets called when the mouse travels outside a given region, which is how HappyFace was written. You may notice that it gets called in a couple other places to work around various interface problems apparently not anticipated when MultiFinder was developed. I recommend maintaining the cursor at every opportunity from the event loop, which is what later Apple documentation seems to suggest. This seems to spread less code around without effecting performance.

Main() calls the initialization functions and runs the event loop. It uses gameWasInProgress to detect when gGameInProgress changes, and mouseRgn to pass to WaitNextEvent(). It calls AdjustCursor() if a game starts or stops, because we do not want to show the mallet if a game is not in progress. When a game ends, it calls ShowScores().

Next, it calls IdleConn() to give time to the connection tool. If it finds that the connection has been severed, it stops any game in progress, because a game cannot be played with no connection. It calls IdleGame(), regardless of whether a game is currently in progress, to allow Game.c to handle its own details, including removing dead faces.

For each event returned by WaitNextEvent(), it first gives ConnEvent() an opportunity to handle it by passing it to the connection tool if appropriate. If ConnEvent() cannot handle the event, IdleConn() continues its attempt to dispatch the event. Any activate event is delegated to ConnActivate(). If an update event is for a window other than the game window, it is ignored, otherwise it is passed to UpdateGameWindow(). A keypress means nothing to HappyFace unless it is a command-key combination, which is passed to DoMenu().

The mouse events are handled in the usual way. HandleWindowClick() is called for any click in the game window's content region, if a game is in progress. This responds to the user striking a face. Suspend and resume events are trapped and passed to the connection tool through ConnResume().

HappyFace.rsrc

HappyFace.rsrc features the usual cast of characters. Star roles are filled, such as the ALRT and DITL resources used by ShowScores(), the PICT resources used to draw happy faces, and the menus used both by CTB.c and Main.c. Supporting characters are such as the SND resource that plays when a face is struck, SICN resources that spice up CTB menus, and the CURS resource used to show the hammer when faces can be struck. Atmosphere is provided by still other resources that provide icons and bundle-oriented information, version information, and the about box props.

With the exception of MBAR, MENU, PICT, SND and ALRT IDs the application source code is oblivious to the resource file's contents - not that I recommend ripping out DITL resources or doing anything else that would confuse the resource manager or the Finder.

Conclusion

What have we learned?

In this article, we explored a complete application using Apple's Communications Toolbox. We created a simple, yet entertaining game to exploit key features of the Connection Manager. Building on a previous article, we have learned to listen for a connection, poll for data, and handle interface-related concerns such as building and maintaining a connection menu and delegating the appropriate events to the connection tool. We found that most of the tasks of maintaining a connection can be hidden from the main program. We scratched the surface of creating an interactive game, though elements of a serious, error checking application have been omitted.

Where do we go from here?

The next step is to develop a formal protocol. Such a protocol would detect transmission errors such as messages that do not reach their destinations, arrive incomplete, or arrive garbled. Such an undertaking will be the subject of the next article.

If you have comments or questions regarding this article, feel free to send them!

References

The following is a list of publications used to produce HappyFace.

  • Chally - Chally, Mark. "DebugTerm: A Poor Man's Debugging Terminal." MacTech Magazine 12:10, October, 1996.
  • Inside CTB - Apple Computer, Inc. Inside Macintosh® Communications Toolbox. Addison Wesley, 1991.
  • Inside Mac Files - Apple Computer, Inc. Inside Macintosh® Files. Addison Wesley, 1992.
  • Mark - Mark, Dave. "Color Animation, Part II." MacTech Magazine 11:05, May, 1994.
  • Surfer - Alex Kazim. "Surfer" (Sample application program with Pascal source code) Essentials•Tools•Objects Vol 13. Apple Computer, 1989.
 
AAPL
$97.03
Apple Inc.
-0.16
MSFT
$44.40
Microsoft Corpora
-0.47
GOOG
$593.35
Google Inc.
-2.63

MacTech Search:
Community Search:

Software Updates via MacUpdate

Audio Hijack Pro 2.11.0 - Record and enh...
Audio Hijack Pro drastically changes the way you use audio on your computer, giving you the freedom to listen to audio when you want and how you want. Record and enhance any audio with Audio Hijack... Read more
Intermission 1.1.1 - Pause and rewind li...
Intermission allows you to pause and rewind live audio from any application on your Mac. Intermission will buffer up to 3 hours of audio, allowing users to skip through any assortment of audio... Read more
Airfoil 4.8.7 - Send audio from any app...
Airfoil allows you to send any audio to AirPort Express units, Apple TVs, and even other Macs and PCs, all in sync! It's your audio - everywhere. With Airfoil you can take audio from any... Read more
Microsoft Remote Desktop 8.0.8 - Connect...
With Microsoft Remote Desktop, you can connect to a remote PC and your work resources from almost anywhere. Experience the power of Windows with RemoteFX in a Remote Desktop client designed to help... Read more
xACT 2.30 - Audio compression toolkit. (...
xACT stands for X Aaudio Compression Toolkit, an application that encodes and decodes FLAC, SHN, Monkey’s Audio, TTA, Wavpack, and Apple Lossless files. It also can encode these formats to MP3, AAC... Read more
Firefox 31.0 - Fast, safe Web browser. (...
Firefox for Mac offers a fast, safe Web browsing experience. Browse quickly, securely, and effortlessly. With its industry-leading features, Firefox is the choice of Web development professionals... Read more
Little Snitch 3.3.3 - Alerts you to outg...
Little Snitch gives you control over your private outgoing data. Track background activityAs soon as your computer connects to the Internet, applications often have permission to send any... Read more
Thunderbird 31.0 - Email client from Moz...
As of July 2012, Thunderbird has transitioned to a new governance model, with new features being developed by the broader free software and open source community, and security fixes and improvements... Read more
Together 3.2 - Store and organize all of...
Together helps you organize your Mac, giving you the ability to store, edit and preview your files in a single clean, uncluttered interface. Smart storage. With simple drag-and-drop functionality,... Read more
Cyberduck 4.5 - FTP and SFTP browser. (F...
Cyberduck is a robust FTP/FTP-TLS/SFTP browser for the Mac whose lack of visual clutter and cleverly intuitive features make it easy to use. Support for external editors and system technologies such... Read more

Latest Forum Discussions

See All

LEX Goes Free For One Day In Honor of Ne...
LEX Goes Free For One Day In Honor of New Update Posted by Jennifer Allen on July 24th, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Thomas Was Alone Goes Universal, Slashes...
Thomas Was Alone Goes Universal, Slashes Price to $3.99 Posted by Ellis Spice on July 24th, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Meerkatz Challenge Review
Meerkatz Challenge Review By Jennifer Allen on July 24th, 2014 Our Rating: :: FONDLY PUZZLINGUniversal App - Designed for iPhone and iPad Cute and challenging, Meerkatz Challenge is a fun puzzle game, particularly for fans of... | Read more »
Book Your Appointment with F.E.A.R. this...
Book Your Appointment with F.E.A.R. | Read more »
It Came From Canada: Epic Skater
For all the hate that it gets for being a pastime for slackers, skateboarding really does require a lot of skill. All those flips and spins take real athleticism, and there’s all the jargon to memorize. Fortunately for us less extreme individuals,... | Read more »
Cultures Review
Cultures Review By Jennifer Allen on July 24th, 2014 Our Rating: :: SLOW-PACED EMPIRE BUILDINGiPad Only App - Designed for the iPad Cute it might seem, but Cultures is a bit too slow paced when it comes to those pesky timers to... | Read more »
More Paintings Have Been Added to Paint...
More Paintings Have Been Added to Paint it Back! Posted by Jessica Fisher on July 24th, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
The Order of Souls Review
The Order of Souls Review By Campbell Bird on July 24th, 2014 Our Rating: :: STORY GRINDUniversal App - Designed for iPhone and iPad The Order of Souls is a free-to-play, turn-based RPG with a genre-mixing art style, interesting... | Read more »
Revolution 60 Review
Revolution 60 Review By Jordan Minor on July 24th, 2014 Our Rating: :: LASS EFFECTUniversal App - Designed for iPhone and iPad Revolution 60 is a bold, cinematic action game with ambition to spare.   | Read more »
Matter (Photography)
Matter 1.0.1 Device: iOS Universal Category: Photography Price: $1.99, Version: 1.0.1 (iTunes) Description: Add stunning 3D effects to your photos with real-time shadows and reflections. Export your creations as photos or video loops... | Read more »

Price Scanner via MacPrices.net

Save on 5th generation refurbished iPod touch...
The Apple Store has Apple Certified Refurbished 5th generation iPod touches available starting at $149. Apple’s one-year warranty is included with each model, and shipping is free. Many, but not all... Read more
What Should Apple’s Next MacBook Priority Be;...
Stabley Times’ Phil Moore says that after expanding its iMac lineup with a new low end model, Apple’s next Mac hardware decision will be how it wants to approach expanding its MacBook lineup as well... Read more
ArtRage For iPhone Painting App Free During C...
ArtRage for iPhone is currently being offered for free (regularly $1.99) during Comic-Con San Diego #SDCC, July 24-27, in celebration of the upcoming ArtRage 4.5 and other 64-bit versions of the... Read more
With The Apple/IBM Alliance, Is The iPad Now...
Almost since the iPad was rolled out in 2010, and especially after Apple made a 128 GB storage configuration available in 2012, there’s been debate over whether the iPad is a serious tool for... Read more
MacBook Airs on sale starting at $799, free s...
B&H Photo has the new 2014 MacBook Airs on sale for up to $100 off MSRP for a limited time. Shipping is free, and B&H charges NY sales tax only. They also include free copies of Parallels... Read more
Apple 27″ Thunderbolt Display (refurbished) a...
The Apple Store has Apple Certified Refurbished 27″ Thunderbolt Displays available for $799 including free shipping. That’s $200 off the cost of new models. Read more
WaterField Designs Unveils Cycling Ride Pouch...
High end computer case and bag maker WaterField Designs of San Francisco now enters the cycling market with the introduction of the Cycling Ride Pouch – an upscale toolkit with a scratch-free iPhone... Read more
Kingston Digital Ships Large Capacity Near 1T...
Kingston Digital, Inc., the Flash memory affiliate of Kingston Technology Company, Inc.,has announced its latest addition to the SSDNow V300 series, the V310. The Kingston SSDNow V310 solid-state... Read more
Apple’s Fiscal Third Quarter Results; Record...
Apple has announced financial results for its fiscal 2014 third quarter ended June 28, 2014, racking up quarterly revenue of $37.4 billion and quarterly net profit of $7.7 billion, or $1.28 per... Read more
15-inch 2.0GHz MacBook Pro Retina on sale for...
B&H Photo has the 15″ 2.0GHz Retina MacBook Pro on sale for $1829 including free shipping plus NY sales tax only. Their price is $170 off MSRP. B&H will also include free copies of Parallels... Read more

Jobs Board

Sr Software Lead Engineer, *Apple* Online S...
Sr Software Lead Engineer, Apple Online Store Publishing Systems Keywords: Company: Apple Job Code: E3PCAK8MgYYkw Location (City or ZIP): Santa Clara Status: Full Read more
Senior Interaction Designer, *Apple* Online...
**Job Summary** Apple is looking for a hands on Senior…will be a key player in designing for the Apple Online Store. The ideal designer will have a Read more
*Apple* Sales Chat Rep - Apple (United State...
…is looking for motivated, outgoing, and tech savvy individuals who want to offer Apple Customers an unparalleled customer experience over chat. At Apple , we believe Read more
Mac Expert - *Apple* Online Store Mexico -...
…MUST be fluent in English and Spanish to be considered for this position At Apple , we believe that hard work, a fun environment, creativity and innovation fuel the Read more
*Apple* Industrial Design CAD Sculptor - App...
**Job Summary** The Apple Industrial Design team is looking for a CAD sculptor/Digital 3D modeler to create high quality CAD models used in the industrial design process Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.