These three components are sufficient information to fully describe a message for an object. Any interaction with an object is handled by passing a message. This means that objects anywhere in a system can communicate with other objects solely through messages.

Just so you don't get confused, understand that "message passing" is another way of saying "method calling." When an object sends another object a message, it is really just calling a method of that object. The message parameters are actually the parameters to a method. In object-oriented programming, messages and methods are synonymous.

Because everything that an object can do is expressed through its methods (interface), message passing supports all possible interactions between objects. In fact, interfaces enable objects to send messages to and receive messages from each other even if they reside in different locations on a network. Objects in this scenario are referred to as distributed objects. Java is specifically designed to support distributed objects.

Inheritance

What happens if you want an object that is very similar to one you already have, but with a few extra characteristics? You just derive a new class based on the class of the similar object.

Inheritance is the process of creating a new class with the characteristics of an existing class, along with additional characteristics unique to the new class.

Inheritance provides a powerful and natural mechanism for organizing and structuring programs.

So far, the discussion of classes has been limited to the data and methods that make up a class. Based on this understanding, you build all classes from scratch by defining all of the data and all of the associated methods. Inheritance provides a means to create classes based on other classes. When a class is based on another class, it inherits all of the properties of that class, including the data and methods for the class. The class doing the inheriting is referred to as the subclass (child class) and the class providing the information to inherit is referred to as the superclass (parent class).

Using the car example, gas-powered cars and cars powered by electricity can be child classes inherited from the car class. Both new car classes share common "car" characteristics, but they also have a few characteristics of their own. The gas car would have a fuel tank and a gas cap, and the electric car might have a battery and a plug for recharging. Each subclass inherits state information (in the form of variable declarations) from the superclass. Figure 3.3 shows the car parent class with the gas and electric car child classes.

Figure 3.3 : Inherited car objects.

The real power of inheritance is the ability to inherit properties and add new ones; subclasses can have variables and methods in addition to the ones they inherit from the superclass. Remember, the electric car has an additional battery and a recharging plug. Subclasses also have the capability to override inherited methods and provide different implementations for them. For example, the gas car would probably be able to go much faster than the electric car. The accelerate method for the gas car could reflect this difference.

Class inheritance is designed to allow as much flexibility as possible. You can create inheritance trees as deep as necessary to carry out your design. An inheritance tree, or class hierarchy, looks much like a family tree; it shows the relationships between classes. Unlike a family tree, the classes in an inheritance tree get more specific as you move down the tree. The car classes in Figure 3.3 are a good example of an inheritance tree.

By using inheritance, you've learned how subclasses can allow specialized data and methods in addition to the common ones provided by the superclass. This enables programmers to reuse the code in the superclass many times, thus saving extra coding effort and therefore eliminating potential bugs.

One final point to make in regard to inheritance: It is possible and sometimes useful to create superclasses that act purely as templates for more usable subclasses. In this situation, the superclass serves as nothing more than an abstraction for the common class functionality shared by the subclasses. For this reason, these types of superclasses are referred to as abstract classes. An abstract class cannot be instantiated, meaning that no objects can be created from an abstract class. An abstract class cannot be instantiated because parts of it have been specifically left unimplemented. More specifically, these parts are made up of methods that have yet to be implemented, which are referred to as abstract methods.

Using the car example once more, the accelerate method really can't be defined until the car's acceleration capabilities are known. Of course, how a car accelerates is determined by the type of engine it has. Because the engine type is unknown in the car superclass, the accelerate method could be defined but left unimplemented, which would make both the accelerate method and the car superclass abstract. Then the gas and electric car child classes would implement the accelerate method to reflect the acceleration capabilities of their respective engines or motors.

OOP and Games

So far, I've talked a lot about the general programming advantages of using objects to simplify complex programming tasks, but I haven't talked too much about how they specifically apply to games. To understand how you can benefit from OOP design methods as a game pro-grammer, you must first take a closer look at what a game really is.

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 come up with one that isn't simulating something. All the adventure games and sports games, and even the far-out space games, are modeling some type of objects present in the real world (maybe not our world, but some world nevertheless). Knowing that games are models of worlds, you can make the connection that most of the things (landscapes, creatures, and so on) in games correspond to things in these worlds. And as soon as you can organize a game into a collection of "things," you can apply OOP techniques to the design. This is possible because things can be translated easily into objects in an OOP environment.

Look at an OOP design of a simple adventure game as an example. In this hypothetical adventure game, the player controls a character around a fantasy world and fights creatures, collects treasure, and so on. You can model all the different aspects of the game as objects by creating a hierarchy of classes. After you design the classes, you create them and let them interact with each other just as objects do in real life.

The world itself probably would be the first class you design. The world class would contain information such as its map and images that represent a graphical visualization of the map. The world class also would contain information such as the current time and weather. All other classes in the game would derive from a positional class containing coordinate information specifying where in the world the objects are located. These coordinates would specify the location of objects on the world map.

The main character class would maintain information such as life points and any items picked up during the game, such as weapons, lanterns, keys, and so on. The character class would have methods for moving in different directions based on the player's input. The items carried by the character also would be objects. The lantern class would contain information such as how much fuel is left and whether the lantern is on or off. The lantern would have methods for turning it on and off, which would cause it to use up fuel.

There would be a general creature class from which all creatures would be derived. This creature class would contain information such as life points and how much damage the creature inflicts when fighting. It would have methods for moving in different directions. Unlike the character class, however, the creature's move methods would be based on some type of intelligence programmed into the creature class. The mean creatures might always go after the main character if they are on the same screen together, for example, but passive creatures might just ignore the main character. Derived creature classes would add extra attributes, such as the capability to swim or fly. Figure 3.4 shows the class hierarchy for this hypothetical game.

Figure 3.4 : Class hierarchy for a hypothetical adventure game.

I've obviously left out a lot of detail in the descriptions of these hypothetical objects. This is intentional because I want to highlight the benefit of the object approach, not the details of fully implementing a real example. Although you already might see the benefits of the object design so far, the real gains come when you put all the objects together in the context of the complete game.

After you have designed all the object classes, you just create objects from them and let them go. You already will have established methods that enable the objects to interact with each other, so in a sense the game world is autonomous. The intelligence of any object in the game is hidden in the object implementation, so no external manipulation is required of them. All you really must do is provide a main game loop that updates everything. Each object would have some method for updating its status. For creatures, this update would entail determining the direction in which to move and whether they should attack. For the main character object, an update would involve performing an action based on the user input. The key point to understand here is that the objects are independent entities that know how to maintain themselves.

Of course, this game also could be designed using a procedural approach, but then there would be no concept of an object linked with its actions. You would have to model the objects as data structures and then have a bunch of functions that act on those structures. No function would be more associated with a particular data structure than any other. And more importantly, the data structures would know nothing about the functions. You also would lose all the benefits of deriving similar objects from a common parent object. This means that you would have duplicate code for all these types of objects that would have to be maintained independently.

A more dramatic benefit of using OOP becomes apparent when you develop new games in the future. By following an OOP design in the first game, you will be able to reuse many of the objects for new games. This is not just a side effect of using OOP techniques, it is a fundamental goal of OOP design. Although you can certainly cut and paste code in a procedural approach, this hardly compares to reusing and deriving from entire objects. As an example, the creature class developed in the hypothetical adventure game could be used as a base class for any kind of creature object, even those in other games.

Although this example is brief, it should illustrate the advantages of using an OOP design for games. If nothing else, I wanted to at least get you thinking about how OOP design techniques can make games easier to develop, which ultimately makes your job more fun!

The good news about all this OOP stuff is that Java is designed from the ground up as an OOP language. As a matter of fact, you don't even have the option of writing procedural code in Java. Nevertheless, it still takes effort to maintain a consistent OOP approach when you are writing Java games, which is why I've spent so much time toChapter discussing OOP theory.

Java and Other OOP Languages

You've learned that OOP has obvious advantages over procedural approaches, especially when it comes to games. OOP was conceived from the ground up with the intention of sim-ulating the real world. However, in the world of game programming, the faster language has traditionally always won. This is evident by the amount of assembly language still being written in the commercial game-development community. No one can argue the fact that carefully written assembly language is faster than C, and that even more carefully written C is sometimes faster than C++. And unfortunately, Java ranks a distant last behind all these languages in terms of efficiency and speed.

However, the advantages of using Java to write games stretch far beyond the speed benefits provided by these faster languages. This doesn't mean that Java is poised to sweep the game community as the game development language of choice; far from it! It means that Java provides an unprecedented array of features that scale well to game development. The goal for Java game programmers is to write games in the present within the speed limitations of Java, while planning games for the future that will run well when faster versions of Java are released.

Due to languages such as Smalltalk, which treats everything as an object (an impediment for simple problems), and their built-in memory-allocation handling (a sometimes very slow process), OOP languages have developed a reputation for being slow and inefficient. C++ remedied this situation in many ways but brought with it the pitfalls and complexities of C, which are largely undesirable in a distributed environment such as the Internet. Java includes many of the nicer features of C++, but incorporates them in a more simple and robust language.

The current drawback to using Java for developing games is the speed of Java programs, which is significantly slower than C++ programs because Java programs execute in an interpreted fashion. The just-in-time compilation enhancements promised in future versions of Java should help remedy this problem. You learn about some optimization techniques to help speed up Java code near the end of this guide on Chapter 20, "Optimizing Java Code for Games."

ToChapter, Java is still not ready for prime time when it comes to competing as a game programmer's language. It just isn't possible yet in the current release of Java to handle the high-speed graphics demanded by commercial games. To alleviate this problem, you have the option of integrating native C code to Java programs. This might or might not be a workable solution, based on the particular needs of a game.

Regardless of whether Java can compete as a high-speed gaming language, it is certainly capable of meeting the needs of many other types of games that are less susceptible to speed restrictions. The games you develop throughout this guide are examples of the types of games that can be developed in the current release of Java.

Summary

ToChapter you learned about object-oriented programming and how it relates to Java. You saw that the concept of an object is at the heart of the OOP paradigm and serves as the conceptual basis for all Java code design. You also found out exactly what an object is, along with some of the powerful benefits of following an object-centric design approach.

You learned in toChapter's lesson how OOP design principles can be applied to games. Games are a very natural application of OOP strategies, because they typically resemble simulations. You then learned that OOP game programming in Java is not without its drawbacks. Execution speed is often the killer in game programming, and Java game programming is no exception. However, future enhancements to Java should lessen the performance gap between Java and other popular OOP languages such as C++.

Now that the conceptual groundwork for Java game programming has been laid, you are ready to move on to more specific game programming issues. To be exact, you now are ready to learn about the basics of using graphics in games, which are covered in tomorrow's lesson.

Q&A

Workshop

The Workshop section provides questions and exercises to help solidify the material you learned toChapter. Try to answer the questions and at least study the exercises before moving on to tomorrow's lesson. You'll find the answers to the questions in appendix A, "Quiz Answers."

Quiz

1. What is an object?
2. What is encapsulation?
3. Why is implementation hiding important?
4. What is the major problem with Java in regard to game programming?