Game Development Reference
In-Depth Information
consider the player's ship as just a special type of enemy and take it into consideration
as well.
Looking at this feature set, I see three possible approaches. You could create one class
that contains all the code for the ship, the enemies, and the boss monster. Certain parts
of the code would run conditionally, depending on the type of enemy. For example, the
shooting code may have different code paths for each type of game object. With a lim-
ited number of different objects, this approach works reasonably well—but it doesn't
scale. As you add more and more types of game objects, you end up with a bigger and
fatter class containing all the game logic code. Any change to any part of that class has
the potential to cause undesirable side effects in enemies' or even the player ship's be-
havior. Determining which code path to execute depending on a type variable is quite
reminiscent of pure C programming and doesn't make use of the object-oriented nature
of Objective-C. But if used judiciously, it's a very powerful concept even today.
The second approach is to create a class hierarchy with the Entity class as the base
class and then derive a ship, two monsters, and a boss monster class from it. This is
what a lot of programmers actually do, and it also works reasonably well for a small
number of game objects. But in essence, it's little different from the first approach, in
that common code often ends up piling up in the base Entity class when it's needed
by some of the subclasses, but not all of them. It takes a turn for the worse as soon as
that code in the Entity class starts to add switches based on the type of the enemy, to
skip parts of the code or execute code paths specific to that type of enemy. That's the
same problem of the first C-style programming approach. With a little care, you can
make sure the code specific to an enemy is part of that enemy's class, but it's all too
easy to end up making most changes in the Entity class itself.
The third option is to use a component system, also called composition or aggregation .
This means that individual code paths are separated from the class hierarchy and only
added to the subclasses that need the components, such as a healthbar component. Be-
cause component-based development could be a book on its own and is likely overkill
for a small project like this shoot-'em-up game, you'll use a mixture of the class hier-
archy approach and component design to at least give you an idea how compositing
game objects out of individual parts works in principle and what the benefits are.
I do want to point out that there is no one best approach to code design. Certain choices
are entirely subjective and depend on personal preferences and experience. Working
code is often preferable to clean code if you're willing to refactor your codebase often
as you learn more about the game you're making. Experience allows you to make more
Search Nedrilad ::

Custom Search