Adding the Play in the Gameplay - Learning Windows 8 Game Development - page 87

next if statement we're just checking if the number of enemies currently alive is
within the limit of our pool of enemies so we don't try and add in enemies that haven't
been created.
After that we find the first dead enemy and spawn it past the right side of the screen
( X = ScreenWidth ) with a random Y value. We finish up by resetting the enemy
to ensure it is flagged as Alive and has full health.
So now we have much of the game logic in place. For the rest we need to establish
some sub-systems to manage tasks such as Input, Rendering, and Collision, which
will let us add in the final pieces of the puzzle.
Subsystems
How we structure our game state plays a large role in deciding how the engine is
structured; however, the structure of the subsystems that run all of the logic of the
game is also important.
There are three subsystems that are usually required for all games:
• Rendering
• Audio
• Input
Of course some of these are still optional depending on what your game requires,
so add and remove as needed. For the game we are making we will make use of
rendering and input to get interaction in place.
Now let's take a look at some of the decisions that need to be made when designing
these systems. The first revolves around access and visibility . These systems need
to be accessible from many locations in the game and, depending on how you struc-
ture your game state, you may be able to restrict this, or you may be making it harder
for yourself in the end. A common pattern used in games for these systems is the
singleton pattern. If you haven't encountered this before, the singleton pattern de-
scribes a way to create classes that are accessible through global scope while en-
suring that only one instance exists. We also gain control over the creation and de-
struction of the instance, which is important to ensure we use resources appropri-
ately and initialize in the correct order. This has downsides, of course. The global