Game Development Reference
of these decisions up front in the planning stage and enables you to create more com-
plex games faster. So if that's your goal, start by making and completing smaller games
and slowly push yourself to new limits and new challenges. It's a learning process, and
unfortunately the easiest way to kill your motivation is to be over-ambitious. There's a
reason why every seasoned game programmer will tell a beginner to start simple and to
re-create classic arcade games like Tetris, Pac-Man, or Asteroids first.
Tip About beginner's enthusiasm: it's good to have it. You'll need it! But also
be realistic about your expectations and what you'll be able to pull off on your
own or with a very small team. The web site “Your Game Idea Is Too Big” of-
fers one very simple, fun, and thought-provoking way to make sure your game
idea remains realistic. Test yourself: ht-
bottom for excellent and inspirational advice.
The Enemy Class
Whether you create one class for each enemy type or write all the enemy code in one
class depends a lot on the number of enemies. Typically neither approach is ideal be-
cause many classes may mean a lot of duplicate code or a deep class hierarchy. All en-
emy code in one class, however, can easily bloat that class and make it cumbersome to
work with, especially if enemies have very diverse abilities. Using components to ex-
tend and modify classes is one solution to this problem, as I explain later. For now, be-
cause there will only be three enemy types and they aren't very different in their beha-
vior, a single class is just fine.
The Enemy class introduced in the ShootEmUp02 project derives from CCSprite for
simplicity's sake, and that will make it easier to work with sprite batching. And it de-
clares an enum for the three enemy types that it should control. The interface in the
header file is shown in Listing 8-7 .
Listing 8-7. The @interface of the Enemy Class