There was a problem sending you an sms. Check your phone number or try again later.
We've sent a link to the Scribd app. If you didn't receive it, try again.
This chapter is another that presents just a single example program illustrating how to apply features of the C++ language. In this case, the focus is on class inheritance and the use of polymorphism. The application program is a simple game.
In the days before "Doom", "Marathon", and "Dark Forces", people had to be content with more limited games! The basic game ideas were actually rather similar. The player had to "explore a maze", "find items", and avoid being eliminated by the "monsters" that inhabited the maze. However, details of graphics and modes of interaction were more limited than the modern games. A maze would be represented as an array of characters on the screen (walls represented by '#' marks, staircases between levels by characters like '<' and so forth). Single character commands allowed the player to move the maze-explorer around within the boundaries of the maze. "Rogue" and "Moria" are typical examples of such games; you may find that you have copies on old floppies somewhere.
You aren't quite ready to put Lucas Arts out of business by writing a replacement for "Dark Forces", but if you have got this far you can write your own version of Moria.
The example code given here is simplified with lots of scope for elaboration. It employs a single level maze (or "dungeon"). A map of the dungeon is always displayed, in full, on the screen. The screen size limits the size of the map; having the complete map displayed simplifies play. (Possible elaborations include showing only those parts of the map already explored and "scrolling" maps that are too large to fit on a screen.) The map and other data are displayed using the same system features as used in the "cursor graphics" examples from Chapter 12.
The map, details of the items to be found, and the monsters that are to be avoided (or destroyed) are taken from text file input. Again, this is a simplification. Games like Moria usually generate new maps for every game played.
The playing mechanism is limited. The user is prompted for a command. After a user command has been processed, all the "monsters" get a chance to "run". A "Monster:: Run()" function captures the essence of "monsterdom" i.e. a desire to eliminate the human player.
object itself. In addition there will have to be various forms of "window" object used to display other information. Since there will be many "monsters" and many "items", standard collection classes will be needed.
There are two separate class hierarchies as well as a number of independent classes. One limited class hierarchy defines "windows". There is a basic "window" class for display of data with a couple of specializations such as a window used to output numeric data (e.g. player's "health") and a window to get input. (These "window" classes are further elaborated in the next chapter.)
There is also a hierarchy of "things found in the dungeon". Some, like the "items" that must be collected, are passive, they sit waiting until an action is performed on them. Others, like the player and the monsters, are active. At each cycle of the game, they perform some action.
Naturally, there are many different kinds of monster. Each different kind (subclass) employs a slightly different strategy when trying to achieve their common objective of "eliminating the player". This is where the polymorphism comes in. The "dungeon" object will work with a collection of monsters. When it is the monsters' turn, the code has a loop that lets each monster "run" (Monster *m;
Read game details from a text file. These details are to include the map layout, the initial positions and other data defining collectable items, the monsters, and the player.
Provide a display similar to that shown in Figure 29.1. This display is to
include the main map window (showing fixed features like walls, position of
collectable items, and current positions of active items) and other windows that
show the player's status.
Operate a "run cycle" where the user enters a movement command (or "magic
action" command \u2013 see below), the command is executed, and then all other
active items get a chance to run.
Arrange that the player object acquire a collectable item by moving over the point where the item is located. Acquisition of a collectable item will change one or more of the player object's "health", "wealth", or "manna" attributes. Once taken by the player object, collectable items are to be deleted from the game.
| +----------------------------------------------------------------+ |Health
Handle attacks by monster objects on the player. A monster object adjacent to
the player will inflict damage proportional to its strength. This amount of
damage is deducted from the player object's health rating. Some monster
objects have the option of using a projectile weapon when not immediately
adjacent to the player.
Handle attacks by the player on a monster object. A movement command that
would place the player object on a point occupied by a monster is to be
interpreted as an attack on that monster. The player inflicts a fixed amount of
damage. Such an attack reduces the monster's health attribute. If a monster
object's health attribute falls to zero, it is to be deleted from the game.
Handle movements. The player and most types of monster are limited in their
scope for movement and cannot pass through walls or outside of the map area.
More than one monster may be located on the same point of the map; monsters
are allowed to occupy the same points as collectable items. When several
dungeon items are located at the same point, only one is shown on the map.
Now bringing you back...
Does that email address look wrong? Try again with a different email.