Book Image

Game Development Patterns and Best Practices

By : John P. Doran, Matt Casanova
Book Image

Game Development Patterns and Best Practices

By: John P. Doran, Matt Casanova

Overview of this book

You’ve learned how to program, and you’ve probably created some simple games at some point, but now you want to build larger projects and find out how to resolve your problems. So instead of a coder, you might now want to think like a game developer or software engineer. To organize your code well, you need certain tools to do so, and that’s what this book is all about. You will learn techniques to code quickly and correctly, while ensuring your code is modular and easily understandable. To begin, we will start with the core game programming patterns, but not the usual way. We will take the use case strategy with this book. We will take an AAA standard game and show you the hurdles at multiple stages of development. Similarly, various use cases are used to showcase other patterns such as the adapter pattern, prototype pattern, flyweight pattern, and observer pattern. Lastly, we’ll go over some tips and tricks on how to refactor your code to remove common code smells and make it easier for others to work with you. By the end of the book you will be proficient in using the most popular and frequently used patterns with the best practices.
Table of Contents (19 chapters)
Title Page
About the Authors
About the Reviewers
Customer Feedback
Artificial Intelligence Using the State Pattern

Loading archetypes from a file

Now that we have seen the Prototype pattern in detail and discussed how it is used with the components of the Mach5 Engine, let's look at how we can use it to load object data from a file. To do that, we will need to first look at the object files, then look at specific methods in the M5ObjectManager used to load and create these objects.

Archetype files

The first thing we need to do is look at how we define our object archetype within a file. The Mach5 Engine uses .ini files for archetypes, levels, and anything related to initialization of the engine. A more standard file format would be XML or JSON if you wanted to keep them as human readable and modifiable. If you didn't want them to be modified by users, the files could always be saved as binary.

We have chosen .ini files because they are easy to read by both humans and a computer program. They only have a few simple rules, so they are easy to explain in just a few sentences. They only contain named sections...