C++ Tutorial - Chapter 12

FLYAWAY ADVENTURE GAME

Now that you have learned lots of things about C++, and know how to write and use a single isolated class, you have the problem of how to build a program with several classes that work together to accomplish some task. After some amount of thought, it seems that an adventure game is a good candidate for a relatively large example program. It has lots of input and output and requires a good deal of flexibility while running since there are so many things that can be included in the game as obstacles, mazes, items to find, and puzzles to solve.

The adventure game presented in this chapter is unique as far as I know, since I have never heard of another adventure game featuring an airport. The location is not nearly as important as the code used to get through the airport. You are advised to play the game to get familiar with what the code does, then study the code to see how it works. Finally, you are given an assignment to extend the code which will be the real test of whether you understand its operation.

A FEW SPECIAL CONSTANTS

Example program ------> FLYAWAY.H

The file named FLYAWAY.H contains the definitions for TRUE and FALSE as well as the enumerated type defining the legal dictionary of words for use in playing the game. The list was started at a value of 1 so the value of zero can be used to indicate that the word in question was not in the library and hence not a legal word for use with the game.

The #ifndef in line 4 is required because this header file is included in many of the other files and if it is included more than once, there will be a multiple definition, and hence an error. A class only needs to be defined once, so after it is defined by one of the includes, the name FLYAWAY_H will be defined and any other defines will be ignored. This is necessary because of the separate compilation capability of C++. This was described in more detail near the end of chapter 7.

THE FIRST CLASS - clock

Example program ------> CLOCK.H

Examine the file named CLOCK.H for the definition of the clock class. This is the class for the game clock, and only one instance of this class will be used. It will be used for the object time_of_day defined in line 23 of FLYAWAY.CPP.

The class is very simple, consisting of only two variables, the hour and the minute, and four methods. The first method is the constructor used to initialize the clock to 8:51 as you can see if you refer to the implementation of this class in the file named CLOCK.CPP. The next two methods are used to get the current values of the two variables. The final method is much more interesting since it does more. It updates the time of day clock and outputs the user prompt to ask for the next command. This may not be the best place to output the user prompt since this class is devoted to the time of day and associated operations, but this was chosen as the place to do it since the time of day is part of the user prompt. You will notice that the clock was initialized to 8:51, but the first time output was 8:52 when you played the game. In order to simplify the coding later, when we need to decide if we made it to the plane on time, the time was incremented at the beginning of each game move. The time is therefore the same when the command is entered and when it is executed, hence the time is incremented prior to even the first output. The clock class is by far the simplest class in the adventure game and should be simple for you to understand. After you are sure you understand it, we will go on to the next class.

INPUT COMMAND PARSING

Example program ------> WORDS.H

The input command parsing routines are defined within the words class and the code for the class is in WORDS.CPP. The code is straightforward and simple to understand if you study it, so only a few comments will be made about this class.

The method get_command() reads two words from the keyboard by calling the function read_a_line() and stores the words in the class members verb and noun. It stores zero for either or both of the words if it does not find a valid noun and a valid verb.

Two methods are included to provide the verb or noun which was input as the last user input. This allows any code that has visibility of the object based on this class to find out what the player would like to do.

There are four methods beginning with is_ in this class that are used to determine if a word is a verb, a noun, a direction, or an operation. These are called upon from various places within the program. What they do should be easy for you to understand, but it will take a little thought on your part to see why these are needed in other parts of the code.

Finally the simple method named stop_game() is used to set the verb to the value of quit so the game will be ended by the control logic in the main program FLYAWAY.CPP.

All of the source code for the implementation is given in the file named WORDS.CPP. Since this code is fairly simple and well commented, you will be left on your own to study it to whatever depth you desire.

THE SECOND CLASS - items

Example program ------> ITEMS.H

If you examine the files named ITEMS.H and ITEMS.CPP, you will find the complete definitions of the handling of the items that you carried around the airport in the game. There were exactly four transportable items that could be located in each room or carried by yourself, the keys, the candy, the ticket, and the money. The keys and the money keep you from getting through security and the ticket and candy are required to get you safely on the plane and enroute to your destination.

The four items are stored in the class named items in the form of TRUE or FALSE since that is the only required indication. A TRUE means the item is located here, and a FALSE means the item is not here. The values of TRUE and FALSE are defined in FLYAWAY.H. Finally, there are six methods to operate on these items.

The first method is a constructor to set all items to FALSE, and the next two are used to either get a specific item, or drop one. The fourth method is used to tell us if the item is located here and the last two are used to tell us what items are on hand in this location. You will notice that the final two are different because different text was desired depending on whether you are carrying the items, or they are located in a room somewhere.

This file, like all other header files, is protected from multiple inclusion by the #ifndef construct discussed earlier.

This class is used in line 24 of FLYAWAY.CPP to define an object for the player named personal_items which stores the list of items the player is carrying around. It is also used in the class location as an embedded or nested object to store the items that are located in each of the 19 locations in the game.

Once again, the implementation for this class is so simple that you will have no difficulty in understanding it.

THE FLIGHT AND GATE CLASS - schedule

Example program ------> SCHEDULE.H

Examine the example files named SCHEDULE.H and SCHEDULE.CPP for our first example of a rather large class, the one that does the flight and gate scheduling. You will find a large number of variables in this class, and eight methods to handle the variables. Instead of a detailed description of each variable and method, we will only give a brief overview of the class.

Only one object of this class is declared named flight_info in line 22 of the main program named FLYAWAY.CPP. The constructor initializes the flight possibilities, and the method named shuffle_gates() shuffles all gates around if the player arrives at his correct gate without reading the monitor in the waiting area. Once the monitor in the waiting area is read, the flights_frozen variable is made TRUE. Likewise, the players destination is changed during every move by the method named shuffle_flights() until the player reads his ticket invoking the method named list_actual_destination().

This class contains the methods to list the data seen on the monitor, as well as the data seen when invoking the command look at one of the gates. Finally, this class contains the method named check_flight() which searches through the list of requirements to see if the player has completed all requirements to successfully reach the final destination for his vacation.

You will notice that several of the location objects were required to be available within this code and are listed as extern in lines 12 through 21 of the implementation of the class. The only other thing to point out is the rest room requirement prior to boarding the flight. Line 28 is where the global variable is defined and initialized, then in line 77 it is set TRUE if the current location is the rest room, since this is called once during each player move. Finally, the state of this variable is checked in line 230 of this file and the appropriate action taken. You will note that the main program is not aware that the rest room variable exists or that anything happens as a result of this variable. In addition to information hiding, we may coin a new term, something like "Information Ignorance", since the main program did not even need to be aware that there was a requirement to visit the rest room.

Even though this is a relatively large and complex class, it is well commented so no further information will be given concerning the implementation.

THE MOST USED CLASS - location

Example program ------> LOCATION.H

The file named LOCATION.H is the header file for the class named location. It is the class that controls all of the moves from location to location.

This class is a bit unusual in that most of the stored data is in the form of pointers to the various entities. The first four are the locations to which we will go if we move in one of the four directions from the current location. You will note that they are pointers to those four locations. Next we have pointers to two different character strings associated with this room. Finally in line 22, we declare the object named list_of_items which is an object of class items defined earlier. Note that this is an embedded class, a class embedded within the location class. It is not a parent class which we are inheriting something from. In fact we are instantiating an object of class items for use within the room since the room is allowed to store any combination of the four items contained in the class named items.

There is no constructor used with this class since we choose to initialize the locations one by one. The method named init() has 6 variable parameters, all of which are pointers, associated with it which it uses to initialize the first six variables of this object. The last variable, an object of class items, is initialized through use of the constructor associated with its class. Referring to lines 40 through 171 of the implementation for the map class, you will find all of the initialization code for the 19 objects of class location. If you drew a map when you played the game, you will see the interconnections between the various locations embedded in the initialization statements. Notice there is no way to get back to the car from the passenger drop off area, because presumably the car leaves when you get out of it.

The next method, named move(), returns a pointer to the new location if a move was legal, otherwise it returns a NULL value. The observant student will also notice that there are special cases involved with getting out of the snack bar and getting through security. These are located here because they are part of the move logic. If you played the game to the complete conclusion, you surely had trouble with at least one of these situations.

The rest of the methods in this class should be self explanatory and will not be discussed any further.

THE LOCATION MESSAGES

Example program ------> MESSAGE.TXT

Examine the file named MESSAGE.TXT for a complete listing of the messages output to the monitor when each location was entered. You will also find the text for each of the messages output in response to a look command in this file. These were put into a separate file only for the purpose of reducing the size of the map class implementation file. It does not reduce the compile time since these messages are not separately compiled. They are included into the file and compiled each time the map file MAP.CPP is compiled. You will note that a few of the messages have no text at all, only the empty quote marks, but are included in order to have something for the initialization code to work with.

Three other messages are stored here for convenience in lines 5 through 40. Their use and meaning should be self-evident.

THE MAIN PROGRAM

Example program ------> FLYAWAY.CPP

We finally reach the main program, the one that actually does the top level control. Examine the program named FLYAWAY.CPP and we will look at some of its interesting characteristics.

Beginning with the main() entry point itself, we see that following a call to airport.initialize(), we enter a single do while loop which terminates when the player enters the word quit or when the verb quit comes up some other way. There are other ways to set the verb to quit because it is generated internally in some cases such as at end of game.

The loop itself consists of 5 method calls. First we call the function named input_words.get_command() to get the players input command in line 30. Next we send two messages to the object named flight_info to shuffle the flights and gates if the proper actions have not been performed, then we call airport.perform_action() which we will describe in a few paragraphs. Finally, we send a messages to the object named flight_info to check if the player has reached one of the gates. Remember that within most of the methods we perform checks to see if we need to do the thing requested in the message, then either perform the action or simply return to the caller or message sender.

THE WORKING METHOD

Example program ------> MAP.H

The only function we have not mentioned yet is the one that does most of the interesting work, the function named perform_action() which begins in line 183 of the MAP.CPP file. This function looks at the verb and noun, if there is one, and causes the correct action to be performed. Because of the way we packaged all of the other routines, this function is a snap to implement and to study. If you go through each of the else if clauses in this function, you will have no trouble understanding what action is taken for each of the input commands. You will notice that many of the actions have conditional clauses before the action is taken. For example, it is illegal to buy candy unless the player has money, the location has candy, and the location must be the snack_bar according to the rules of the game.

Finally, at the end of this method in line 277, we have the default case if nothing else was accomplished. It is assumed that there was something funny requested such as a request to get a monitor. Both of these are legal words but they make no sense together.

FINAL COMMENTS ON FLYAWAY

Now that you have played the game for awhile and studied the game in detail, you should have an appreciation for how this game can be written. Of course, it could be written in any of several thousand different ways of packaging and definition. This has been only one of the ways.

Because the student may be left with the sinking feeling that this method simply fell out of the sky or was arrived at in some other esoteric way, it would only be fair to point out that several earlier attempts at outlining this project were attempted and rejected prior to this arrangement. Also, when this tutorial was being updated from version 2.0 to 2.2, the entire program was restructured. In version 2.0 and prior versions, about 50% of the code was in classes, but due to additional programming experience, about 98% of the flyaway program is now encapsulated in classes.

Object oriented programming requires the same forethought as non-object oriented programming, but the object oriented compiler will help you in the coding and debugging phase since the compiler will find and flag many of the oversight errors we are so good at introducing into our code. It was observed during the coding and debugging phase of this project that in nearly every case, when the program finally got through the compiler, the program would actually run without bombing out the system. This is not always the case using any standard procedural programming language.

YOUR PROGRAMMING PROJECT

This programming assignment is intended to give you a little experience in working with a relatively large project as opposed to the very small programs we have been working with in this tutorial.

Add a suitcase to the game, to be found in the car at arrival, and which must be checked in at the ticket counter prior to attempting to get through airport security. This will not be trivial since several classes will be affected. Some of the operations you will have to do are listed below.

  1. Add the noun "suitcase" and the verb "check" to the word list. Of course, they must be entered at the right place in the list.
  2. Add the suitcase to the items class, including additional code to each of its methods.
  3. Initialize the items at location your_car to include the suitcase.
  4. Add an additional check when passing through security to check that the player is not carrying the suitcase. You can add any sort of penalty desired, including death by firing squad for attempting such an obviously crooked deed.
  5. You will need to add a check when the player finally gets on his correct airplane to see that he checked his suitcase. If he did not, you could output any desired text indicating stupidity or forgetfulness.

Since I have not actually added the suitcase to the game and tested it, I am not sure that this is all that will be required, but it should be the majority of effort required. The bottom line of this effort is that if you understand this program enough to perform this modification, you have a good understanding of how the program works and how objects work together to perform a task.

Once you understand this program, you should define a programming project for yourself that will use object oriented programming techniques and begin designing and programming it. The best way to learn to use OOP is to actually use it.

Good luck in your OOP endeavors.

Return to Table of Contents


Copyright © 1998 David Alan Quick - Last update, 16 April 1998
David Alan Quick - sundog97@hotmail.com -
Please email any comments or suggestions.