Class and Module Summary
By now you should have a good idea of how a class hierarchy works. By looking at the following hierarchy, you can see that everything in the game is a descendant of <game-object>, which means that every object has a name and a description. The following hierarchy is quite robust in that you can add functionality to the game by simply extending the hierarchy and perhaps by simply combining features found in different objects by creating a subclass.
Not all classes in the game are included on this picture, but these are by far the most important ones to know.
For organization, the game engine is divided into ten modules, each in a separate file. The modules interact with each other and definitely build upon previous ones. Breaking the game into modules allows for additional modules to be introduced to the game engine for added functionality. The modules below form the essential part of the engine, and you have complete access to these.
Everything that happens in the game is an event. Walking around, moving, fighting, picking up an object, everything. The game runs on an event-queue, which never empties. More information can be found in the engine summary.
It sets up the top levels of the class hierarchy and defines some generic methods to be used on these classes. We're going to have a number of methods for transfer, so keep track of that. It's important to note that everything in the game derives from <game-object>.
Animates defines the set of classes that can move about and hear things. The <automated> class allows for an object to have a plan, which is essentially a loop. Every time the automate object's plan does something, it schedules another event.
In animates, you see initialize for one of the first times. This is a generic method that is called in the instantiation process of an object. It is vitally important that initialize does a call-next-method. After that, initialize has a handle on the object and can do something with it. In our case, we use it to introduce the object to the game, by inserting the objects plan into the event queue.
The command system is probably the most complicated part of the game engine. It is discussed in the command system summary. Essentially, we try and parse user input into something that can be interpreted into some action. When such a match is made, the command executes on the player who gave the command, possibly queuing up some events as a result.
As the premier command-able object, players is a pretty important part of the game engine. It's not so important for the problem set though. Understanding that the events for a player are just requests for input and then executing that input as a command makes players seem fairly digestible. There's a lot of other things involved in creating and destroying player objects though.
Communicate defines all the functions that allow for text to be displayed to the player. Among all the variations of communication, such as say, tell, and shout, you'll find that not only players can hear the messages but also the listening characters. This allows the characters to respond to certain situations such as when an animate enters the room. More about communication is discussed in the communication summary.
Places are the primary container for the game. There's a lot involved with these places, but in essence they form the nodes on a graph. Building connections between these places allows for a map, and by using exit objects we gain a fairly sophisticated map with weights, locks, and keys. And there is also a discussion about places in the place and exit summary.
Inanimates is easy. They're just objects that sit in the game and look pretty. Of course players and animates can carry them and stuff like that, but it's fun to use all the other modules to enhance inanimates. For instance, we can add a command to an object to make it do something interesting. An example would be adding an open command to an exit that looks like a door. You should note how transfer plays a critical role in controlling the game.
