Game Development Reference
In-Depth Information
destructor. After that, I have my public interface followed by protected and private
internal function definitions. You don
'
t have to follow my scheme, of course, but
you should come up with something that you like and stick with it.
One of the keys to writing good software is designing robust systems that can stand
the test of time. Game programming is extremely volatile. A designer can change the
whole game out from under you, requiring you to rewrite large chunks of your game.
There
s simply the nature of the beast. You can mit-
igate the effect of these kinds of changes by having a strong, flexible architecture.
Isaac Asimov
'
s Foundation series invented an interesting discipline called psycho-
history, a social science that could predict societal trends and macro events with
great certainty. Each historian in the story was required to contribute new formulas
and extend the science. As a programmer, your job is similar. Every new module or
class that you create gives you the opportunity to extend the capabilities and useful-
ness of the code base. But to do this effectively, you must learn how to think ahead
and design code with the goal of keeping it in use for many projects and many years.
Designing good code in an object-oriented language can be more difficult than in a
procedural language such as C or PASCAL. The power and flexibility of an object-
oriented language like C++, for example, allows you to create extremely complicated
systems that look quite simple. This is both good and bad. Simplicity is good, but the
down side is that it
'
s easy to get yourself into trouble without realizing it. A great
example of this is the C++ constructor. Some programmers create code in a con-
structor that can fail
'
s no way around this, because it
'
—
maybe they tried to read data from an initialization file, and
the file doesn
t return any kind of error code,
so the badly constructed object still exists and might get used. While you can use
structured exception handling to catch a failure in a constructor, it is a much better
practice to write constructors that can
'
t exist. A failed constructor doesn
'
'
t fail. Another example is the misuse of virtual
functions. For example, a naive programmer might make every method in the class
virtual, thinking that future expandability for everything was good. Well, he
dbe
wrong. On some platforms, virtual functions can be very expensive. A well thought
through design is more important than blind application of object-oriented program-
ming constructs.
You can make your work much more efficient by improving how you design your
software. With a few keystrokes, you can create interesting adaptations of existing
systems. There
'
s nothing like having such command and control over a body of
code. It makes you more of an artist than a programmer.
'
