TweetFollow Us on Twitter

Happy Face CTB Game

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


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.


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.


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.


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().


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 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.


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!


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.

Community Search:
MacTech Search:

Software Updates via MacUpdate

Day One 2.3 - Maintain a daily journal.
Day One is the easiest and best-looking way to use a journal / diary / text-logging application for the Mac. Day One is well designed and extremely focused to encourage you to write more through... Read more
Carbon Copy Cloner 4.1.16 - Easy-to-use...
Carbon Copy Cloner backups are better than ordinary backups. Suppose the unthinkable happens while you're under deadline to finish a project: your Mac is unresponsive and all you hear is an ominous,... Read more
Sketch 45 - Design app for UX/UI for iOS...
Sketch is an innovative and fresh look at vector drawing. Its intentionally minimalist design is based upon a drawing space of unlimited size and layers, free of palettes, panels, menus, windows, and... Read more
NeoFinder 7.1 - Catalog your external me...
NeoFinder (formerly CDFinder) rapidly organizes your data, either on external or internal disks, or any other volumes. It catalogs all your data, so you stay in control of your data archive or disk... Read more
TunnelBear 3.0.15 - Subscription-based p...
TunnelBear is a subscription-based virtual private network (VPN) service and companion app, enabling you to browse the internet privately and securely. Features Browse privately - Secure your data... Read more
Hopper Disassembler 4.2.5- - Binary disa...
Hopper Disassembler is a binary disassembler, decompiler, and debugger for 32-bit and 64-bit executables. It will let you disassemble any binary you want, and provide you all the information about... Read more
BetterTouchTool 2.261 - Customize Multi-...
BetterTouchTool adds many new, fully customizable gestures to the Magic Mouse, Multi-Touch MacBook trackpad, and Magic Trackpad. These gestures are customizable: Magic Mouse: Pinch in / out (zoom... Read more
Sketch 44.1 - Design app for UX/UI for i...
Sketch is an innovative and fresh look at vector drawing. Its intentionally minimalist design is based upon a drawing space of unlimited size and layers, free of palettes, panels, menus, windows, and... Read more
BetterTouchTool 2.260 - Customize Multi-...
BetterTouchTool adds many new, fully customizable gestures to the Magic Mouse, Multi-Touch MacBook trackpad, and Magic Trackpad. These gestures are customizable: Magic Mouse: Pinch in / out (zoom... Read more
Chromium 59.0.3071.115 - Fast and stable...
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all Internet users to experience the web. Version 59.0.3071.115: This update has no Flash plug... Read more

Latest Forum Discussions

See All

You can now travel to Skyrim in The Elde...
The Elder Scrolls: Legends' new expansion has opened up Skyrim's craggy mountains and snowy plains for exploration today. Heroes of Skyrim is out now, adding a bunch of new Skyrim content to Bethesda's recent CCG. [Read more] | Read more »
High-stakes solitaire game 'Missile...
Missile Command and Solitaire might seem like an odd couple, but indie developer Nathan Meunier has brought them together to create his first game, Missile Cards, which launched on the App Store today. [Read more] | Read more »
Eos 2 (Music)
Eos 2 2.0.2 Device: iOS Universal Category: Music Price: $5.99, Version: 2.0.2 (iTunes) Description: | Read more »
Supercell celebrates Hay Day's comm...
Before there was Clash Royale or Clash of Clans, there was Hay Day. Now, Supercell's first game is celebrating its fifth anniversary, and the developer is commemorating the event with this touching new video. Supercell picked one long-running Hay... | Read more »
Dive into epic summer adventure with Oce...
Summer may be the best time to enjoy ocean adventures, and now you don’t even have to leave the comfort of your own home, thanks to the folks at Joycity, creators of Oceans & Empires. The old-timey naval MMO is getting a sizable new June Grand... | Read more »
Missile Cards (Games)
Missile Cards 1.0.9 Device: iOS Universal Category: Games Price: $2.99, Version: 1.0.9 (iTunes) Description: "Missile Command meets Solitaire...only with more doomlasers, death, and explosions." | Read more »
Collect mini assassins in 'Assassin...
Assassin's Creed is traveling back in time to the Spanish Inquisition for its latest mobile entry, Assassin's Creed Rebellion. The game is giving the series a look that's a huge departure from its past design, recreating classic characters in a... | Read more »
Animal Crossing is still coming to mobil...
Animal Crossing is still coming to mobile in 2017, according to aWaypointinterview with Nintendo. Announced in 2016, the game was delayed without a defined release window. However, fans of Nintendo's fantasy slice of life game won't have to wait... | Read more »
Ravenscroft 275 Piano (Music)
Ravenscroft 275 Piano 1.0.0 Device: iOS Universal Category: Music Price: $35.99, Version: 1.0.0 (iTunes) Description: Experience the splendor of a Ravenscroft Grand with the most realistic sounding piano ever created for iOS. Launch... | Read more »
This War of Mine gets a new ending and m...
This War of Mine just got a big new update, featuring free DLC that adds a new ending to the game, among other exciting changes. The update is celebrating the game's two-year release anniversary. Apart from the new ending, which will be quite... | Read more »

Price Scanner via

Will iPad Running iOS 11 Be The ‘Ute’ Of The...
Steve Jobs’ analogy comparing iPads and PCs to cars and trucks respectively is seven years old but still stimulates discussion and debate. Appearing on an All Things D panel in 2010 shortly after the... Read more
Free CarePassport App gives Patients control...
Boston based CarePassport is on a mission to enable patients to take control of their medical records by allowing patients to aggregate, store, share and manage all their medical data including... Read more
Western Digital Launches New My Passport Ultr...
Western Digital Corporation has expanded its WD brand My Passport portable drive line with the redesigned My Passport Ultra drive. In addition to a new metallic look, the drive offers intuitive WD... Read more
Clearance 2016 13-inch MacBook Pros available...
B&H Photo has clearance 2016 13″ MacBook Pros in stock today for up to $210 off original MSRP. Shipping is free, and B&H charges NY & NJ sales tax only: - 13″ 2.9GHz/512GB Touch Bar... Read more
Apple Releases iOS 11 Public Beta; How To Get...
The official release of Apple’s latest mobile operating system iOS 11 is vaguely slated for the fall, but as of June 26, ordinary users can download an iOS 11 public beta. To download the iOS 11... Read more
Extend Life of MacBook Pro Retina 2.0TB With... World Computing has announced availability of the new OWC 2.0TB Aura Pro Solid State Drive for mid-2012 to early 2013 Apple MacBook Pro with Retina display. One of the fastest... Read more
BBEdit SummerFest 2017 Discount Ends Friday,...
You can get 20% off BBEdit for a limited time in Bare Bones Software’s[UNIQID]SummerFest 2017 sale and... Read more
Use Apple’s Education discount to save up to...
Purchase a new Mac using Apple’s Education discount, and take up to $300 off MSRP. All teachers, students, and staff of any educational institution qualify for the discount. Shipping is free: - 15″ 2... Read more
Clearance 27-inch 3.3GHz 5K iMac available fo...
Amazon clearance 27″ 3.3GHz 5K iMacs (MK482LL/A) available for $1799.90 including free shipping. Their price is $500 off original MSRP, and it’s the lowest price available for this model from any... Read more
13-inch 1.8GHz/256GB MacBook Air on sale for...
B&H Photo has the updated 2017 13″ 1.8GHz/256GB MacBook Air (MQD42LL/A) in stock and on sale for $1129 including free shipping plus NY & NJ tax only. Their price is $70 off MSRP. Read more

Jobs Board

*Apple* Online Store WW Customer Insights -...
…with data mining tools: R, SAS, etc.Experience with common shell scripting tools: unix, python, apple script, Swift etc. Apple Online is one of the largest and Read more
Engineering Project Manager, *Apple* Online...
…the electronic commerce (eCommerce) systems and solutions that enable and support the Apple Online Store (AOS) - one of world's largest online retail businesses, Read more
*Apple* News Product Marketing Mgr., Publish...
…organizational consensus on strategy and vision for publisher tools, authoring, and Apple News Format.Carries this strategy and vision across the organization to Read more
*Apple* Retail - Multiple Positions - Apple,...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
Security Data Analyst - *Apple* Information...
…data sources need to be collected to allow Information Security to better protect Apple employees and customers from a wide range of threats.Act as the subject matter Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.