In this chapter, we covered a lot of best-practice information, which we hope will give you a good foundation when building your own projects in the future. We touched on why hardcoding values is a bad idea, in addition to making a number of other code-quality suggestions, to ensure that your code is easy to understand and easy to extend from in the future, when it needs to be.

We also learned how iteration is useful in game development, talking about the traditional game development cycle, with tips and tricks about playtesting and how it can be immensely useful when developing your projects.

We also looked into low-level and high-level programming languages, learning about how scripting languages run inside another program that we have to build into our project. They are not compiled but rather interpreted, and are generally easier to use and write code for than a compiled language, but come at the cost of performance. Depending on how complex your game is, it may be a good idea to stick to just C++, but if you are working with designers, it can be quite useful to give them the tools to do things on their own.

With that, we've reached the end of the book. We hope that you found the information both interesting and useful. As you go out there and build your own projects, make use of the design patterns and best practices that we've talked about over the past 12 chapters, and make the best games that you can!