Object-Oriented Programming and Games

Object-Oriented Programming and Games

Because you have some experience with C++, you've no doubt heard of object-oriented programming. Object-oriented programming , or OOP , is a programming technique in which you treat parts of a program as objects , as opposed to chunks of programming code. OOP is particularly useful in games because games are actually easier to understand when you break them down into objects. For this reason, programming languages such as C++ are ideal for developing games. The next two sections provide you with an OOP refresher and then put OOP in the context of game development.

Understanding OOP

The idea behind OOP is to make programming more akin to the way people think, as compared to the way computers think. People tend to think in terms of meaningful things (objects). As an example, if you were to describe a hockey game, you might talk about the rink, the players, the nets , and the puck. From a computer's perspective, a computer hockey game is no different from any other program ”it's just a bunch of ones and zeros. Programming languages free programmers from having to think in terms of ones and zeros. OOP languages take things a step further by allowing you to think in terms of objects.

Classes of objects are an important part of OOP. A class is a category of objects. Another way to say this is that an object is an instance of a class. If you were creating a computer hockey game, you might create a single hockey player class; the actual players in the game are instances of this class. Figure 1.2 shows how the hockey player objects are related to the single player class.

Figure 1.2. Several hockey player objects can be created from a single player class.

The figure reveals how several objects are created from a single class, which serves as a template for the objects. Using a food analogy instead of hockey, you can think of the class as a cookie cutter and the objects as the cookies. Another important feature of classes is that they allow you to create subclasses , which add to the properties and features in a class to make it more specific. A subclass inherits the properties and features from its parent class , and then adds some of its own. In this way, a subclass is similar to a human child in that it inherits traits from its parent, but also has its own new traits.

Applying OOP to Games

In order to understand the benefits that OOP offers in terms of game development, it's helpful to think of a game as a type of abstract simulation. If you think about most of the games you've seen or played , it's almost impossible to think of one that doesn't simulate something. All the adventure games and sports games are clearly simulations, and even the most far-out space games are modeling objects that exist in some kind of virtual world. Knowing that games are models of worlds, you can make the connection that most of the things in games ( landscapes , creatures , and so on) correspond to things in these worlds . And once you can resolve a game into a collection of "things," you can apply OOP techniques to the design. This is possible because things can easily be translated into objects in an OOP environment.

To better understand what I'm talking about, consider the OOP design of a simple fantasy adventure game. The object representing the world for this game might contain information such as its map and images that represent the visualization of the map, as well as time and weather. All other objects in the game would include positional information that describes where in the world they are located. This positional information could be a simple XY value that pinpoints the object's location on the world map.

The object for the main character in the game would include information such as life points and any items picked up during the game (weapons, lanterns, keys, and so on). The game itself would interact with the character object by telling it to move in different directions based on user input. The items carried by the character would also be created as objects. For example, the lantern object would probably keep track of how much fuel is left in the lantern, and whether it is on or off. Interactions with the lantern would simply include turning it on or off; the lantern object would be smart enough to reduce its fuel supply when the lantern is turned on.

Creatures in the game could all be based on a single creature class that describes general characteristics shared by all creatures such as life points, aggression, and how much damage they inflict when fighting. Specific creature objects would then be created and turned loose in the virtual world. The creature objects and the main character object could all be subclassed from the same organism object. Unlike the character object, which is driven by user interactions, the creature objects would be controlled by some type of intelligence programmed into the game. For example, more aggressive creatures might always chase after the main character when they are on the screen together, whereas passive creatures might have a tendency to hide and avoid contact. You could create creature subclasses that enhance the basic creature with unique capabilities such as the ability to fly, swim, or breathe fire. Figure 1.3 shows how the different classes in this hypothetical adventure game might be organized.

Figure 1.3. Classes in a hypothetical adventure game are built on one another to establish a virtual world of objects.

Don't forget that classes are templates for objects, which means that the classes shown in the figure are designed as a blueprint for creating objects in the game. However, it's not until you actually create the objects themselves that they are able to exist in the virtual world and interact with one another. Again, the class is the cookie cutter, and the object is the cookie. So, the development of a game using OOP first involves designing classes for the various "things" in the game, and then creating objects using those classes.

The beauty of the OOP approach to game development is that the game more or less runs itself once everything is in place. In other words, each object is responsible for handling its own business, so the game doesn't have to concern itself too much with what each object is doing; the game is just providing a framework for the objects to exist in. This framework primarily consists of a game screen for the objects to be drawn on, and an update loop that tells the objects some time has passed. For creatures, this update would entail determining the direction to move in and whether they should attack or run. For the main character, an update involves performing an action based on user input. The main point I'm trying to make is that objects are independent entities that basically know how to take care of themselves.

A more practical benefit of OOP design in games has to do with reusing code. Let's say that you've completed your fantasy adventure game we just talked about and would like to create a similar game set in outer space. Instead of starting over from scratch, you could take the objects you developed for the first game and reuse them in the new game. Granted, some changes would be in order, but many of the changes could be made by creating new subclasses, as opposed to rewriting the originals . Code reuse is certainly one of the most dramatic benefits to using an OOP approach to game development .