Game Development Reference
In-Depth Information
hard to find time to use the bathroom. I have built the core mechanics
for a game in less (but not much less) than 24 hours; it wasn
pretty but it got the job done. I believe most reasonable people
could agree that a day or two turnaround for any game, regardless of
complexity, is utterly absurd, and any project manager or account
executive who agrees to such a timeline should be flogged publicly.
Despite all of this, I do think that abandoning all sense of stan-
dards, forward thinking, or just reasonable programming principles
because you were given a ridiculous schedule is not a good prac-
tice. In my experience, coding a game rigidly and badly saves no
more real time than coding it in a halfway decent way, so why not
strive for the higher standard? In this chapter, I
ll outline some
examples of
much time on your hands. If you follow these basic principles
when you
the least you can do,
even when you don
re in crunch time, you (and anyone else who has to look
at your code) will be thanking yourself later on down the road.
Basic Encapsulation: Classes and
I once had to make edits to a game in which the developer had, for
the supposed sake of simplicity and speed, put virtually all of the
codes for the game, menu screens, and results screen in the same
document class. Needless to say, it was an organizational night-
mare. There was absolutely nothing separating game logic from the
navigational structure or the leaderboard code. I
time, this kept the developer from switching between files, but at
an ultimately very high cost. The code was an ugly step up from
just having it all tossed on the first frame of the timeline. Here are
the steps the developer should have taken to improve the readabil-
ity and editability of his or her code, in order of importance:
Move all game logics to its own class. At the bare minimum,
any code that controls the mechanics of a game should be
encapsulated by itself, away from irrelevant information. This is
the core of the game, and the most likely candidate for re-use
should not be lumped in with everything else.
Move code for each discrete screen or state of the game to its
respective class. If the game has a title screen, rules screen,
gameplay screen, and results screen, there should be a class for
each. In addition, the document class should be used to move
between them and manage which one is active.
This doesn
structure, but it can be up to far more scrutiny than the previous
t sound unreasonable, does it? It
Search Nedrilad ::

Custom Search