I hope you enjoyed this chapter and tried to follow the process of creating a game closely. Pong might not be the most exciting game, but it was a great example to really cover everything from start to finish that would usually happen for any game project. Bigger projects would be impossible to cover in just one chapter and this way you already learned about concepts, unit tests, and the basic terminology of agile development. After learning about the helper classes in the next chapter and then diving into the details of the game class and game components, you will be ready to do a rocking 3D engine with lots of cool effects for the final part of this book to write nice big game with XNA. In the meantime you will see a couple of other small fun game projects.
The most important point of this chapter is the proof that agile programming works great for games, and though you are able to dynamically change things and have a very easy top-down approach to solve problems, it is still very important to make a concept, even if it is just one-page long. Unit tests also helped a lot, but as you will see in the next chapter unit tests can also be automated and they are very useful for the helper classes, which are used all over the place in the projects later in this book.
Take a look what you have learned in this chapter:
It is important to write down your ideas and to develop a small concept.
Just one page of concept can be quite useful.
To solve problems you use a top-down approach and you use unit testing to stay at just the top level without even thinking of the implementation. This way you can quickly adopt ideas from the concept and write them down in unit tests, making it easier to see exactly what methods you have to implement.
You created some textures, loaded them into the project, and displayed them as sprites.
Rendering many sprites at once gives better performance.
Using a clever formula helped you to make the game resolution-independent. This way the game works fine on the Xbox 360 and any resolution that is possible.
You added sound using XACT and learned some basics; you can find more details in Chapter 9.
Handling game input using two gamepads controllers and using the keyboard for multiple players.
Collision testing in 2D with help of the BoundingBox structure.
Using Vector3 instead of Vector2 works fine if you always set the z component to 0.
Using unit tests for collision testing is very important and greatly reduces the amount of testing you have to do. You can also always switch back to the unit test and test the collisions again, even if you are currently working on a completely different part of the game.