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.
<P>
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.
<P>
<A HREF="f3-4.gif" ><B>Figure 3.4 : </B><I>Class hierarchy for a hypothetical adventure game.</I></A>
<P>
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.
<P>
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.
<P>
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.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
Procedural programming is the precursor to object oriented programming. In procedural programming, the focus to solving programmatic problems is on using blocks of code called procedures that independently act on data. This is in direct contrast to object 
oriented programming, in which procedures and data are combined in a single unit: the object.</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
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.
<P>
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!
<P>
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 today discussing OOP theory.
<H2><A NAME="JavaandOtherOOPLanguages"><B><FONT SIZE=5 COLOR=#FF0000>Java
and Other OOP Languages</FONT></B></A></H2>
<P>
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.
<P>
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.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
In fact two separate speed issues are involved in Java game programming. The first is the issue of the speed of the Java language and runtime environment which will no doubt improve as better compilers and more efficient versions of the runtime environment 
are released. The second issue is that of Internet connection speed which is limited by the speed of the modem or physical line used to connect to the Internet. Both of these issues are important but they impact Java games in different ways: The first 
speed limitation affects how fast a game runs while the second limitation affects how fast a game loads.</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
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.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
For more information about exactly how Java improves C++ see appendix C &quot;Differences Between Java and C/C++.&quot;</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
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 book on <A HREF="ch20.htm" >Day 20</A>, &quot;Optimizing
Java Code for Games.&quot;
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
Currently, Java programs are interpreted, meaning that they go through a conversion process as they are being run. Although this interpreted approach is beneficial because it allows Java programs to run on different types of computers, it greatly affects 
the speed of the programs. A promising solution to this problem is just in time compilation, which is a technique in which a Java program is compiled into an executable native to a particular type of computer before being run.</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
Today, 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.
<P>
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 book are examples of the
types of games that can be developed in the current release of
Java.
<H2><A NAME="Summary"><B><FONT SIZE=5 COLOR=#FF0000>Summary</FONT></B></A>
</H2>
<P>
Today 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.
<P>
You learned in today'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++.
<P>
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.
<H2><A NAME="QA"><B><FONT SIZE=5 COLOR=#FF0000>Q&amp;A</FONT></B></A>
<BR>
</H2>

<TABLE>
<TR VALIGN=TOP><TD WIDTH=50><B>Q</B></TD><TD><B>What is an object-oriented language?</B>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=50><B>A</B></TD><TD>A language that supports the concept of an object, which is the merger of data and methods into a logically single element. Furthermore, object-oriented languages typically support features such as 
encapsulation, inheritance, and polymorphism, which combine to encourage code reuse.
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=50><B>Q</B></TD><TD><B>What is the difference between a class and an object?</B>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=50><B>A</B></TD><TD>A class is a blueprint, or template, that defines the data and methods necessary to model a &quot;thing.&quot; An object is an instance of a class that exists in the computer's memory and can be interacted with 
much like a &quot;thing&quot; in the real world. You can create as many objects from a single class as memory will allow.
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=50><B>Q</B></TD><TD><B>What's the difference between a message and a method?</B>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=50><B>A</B></TD><TD>Nothing, really. &quot;Sending a message&quot; is another way of saying &quot;calling a method&quot; and is often used in more general OOP discussions.
</TD></TR>
</TABLE>
<H2><A NAME="Workshop"><B><FONT SIZE=5 COLOR=#FF0000>Workshop</FONT></B></A>
</H2>
<P>
The Workshop section provides questions and exercises to help
solidify the material you learned today. 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,
&quot;Quiz Answers.&quot;
<H3><A NAME="Quiz"><B>Quiz</B></A></H3>
<OL>
<LI>What is an object?
<LI>What is encapsulation?
<LI>Why is implementation hiding important?
<LI>What is the major problem with Java in regard to game programming?
</OL>
<H3><A NAME="Exercises"><B>Exercises</B></A></H3>
<OL>
<LI>Develop a class hierarchy for a game idea of your own, similar
to the one created for the hypothetical adventure game.
<LI>Play some computer games, paying particular attention to how
they can each be broken down into groups of objects.
<LI>If you are a C or C++ programmer new to Java, read appendix
C, &quot;Differences Between Java and C/C++.&quot;
</OL>
<P>
<HR WIDTH="100%"></P>

<CENTER><P><A HREF="ch2.htm"><IMG SRC="pc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="index.htm"><IMG SRC="hb.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="#CONTENTS"><IMG SRC="cc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="ch4.htm"><IMG 
SRC="nc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A></P></CENTER>

<P>
<HR WIDTH="100%"></P>

</BODY>
</HTML>