Game Development Reference
In-Depth Information
Summary
In this chapter we took what we learned in the previous two chapters and built up a
collection of systems that allow us to implement the actual gameplay of the game.
We went from some sample code to test out rendering and input, and added structure
so that we can easily define input actions that can be triggered by multiple devices.
We restructured our rendering so that the textures can be re-used and centralized the
drawing functionality so that with one call we can draw every sprite and piece of text
required.
From there we added in gameplay by adding in the
Player
,
Enemy
, and
Bullet
classes and the supporting
Ship
class. We added the code required to spawn new
enemies and fire new bullets, an also looked at the caching techniques we could use
to manage both of those.
Then we added destruction with a simple collision system that allowed us to easily
manage collision shapes that allow us to make collision detection faster. This was the
big piece of the puzzle needed to lock in the gameplay and allow the player to have
an effect on the enemy, as well as a consequence for not dealing with them.
Through all of this you have hopefully gained an understanding of just some of the
systems required for games, and the plentiful set of tools and options available to
you when building them. Remember that there is no single way to do it. Every game
is unique and choosing the best tool for the job, even if it means new code, is the
best way to go. Consider performance, but be realistic. You may have some inefficient
code, but if it is only called once a frame then it might not be worth wasting time on it.
Also consider that implementing complex but "efficient" algorithms can often perform
worse if you've got a controlled small set of objects.
There are hundreds of ways to make a game, and thousands upon thousands of re-
sources available in print and online to help you. As you build you will refine and learn,
but remember that the heart of the game is in the gameplay and the fun, not the amaz-
ing memory manager that takes 5 days to implement. (Although that's a cool thing to
work on as well.)
Next steps
