Chapter 13. Games
This final chapter of the book demonstrates the example game projects provided on the CD-ROM that make use of the Advanced2D engine. It’s been a long haul since the first chapter, and we’ve created a lot of fascinating code along the way. Now we need to put it to good use. There are two important points that I want to communicate to you before we take a look at the examples.
The first point that I want to drive home is to help you to understand the nature of the Advanced2D engine: It is an ever-evolving engine that continues to see improvement day by day. The example games in this chapter were developed as prototypes before the Advanced2D engine was developed and indeed were used as a trial run for the earliest entity management and collision detection tests. Now that the engine is fully developed, these two games were upgraded to take advantage of new features that I did not imagine originally. The result was a feedback loop that manifested while upgrading to the latest engine specs. While doing so, I found a need for new features (class properties and methods) in the engine, either to simplify the front-end code or to improve performance.
The second point follows up on the first: A game engine is never finished; there are only levels of functionality. Early in the project—back around Chapter 3—it was possible to create a game with animation and crude keyboard input. It did function, and the Sprite class worked. However, over the next 10 chapters, that class (as well as others) saw continual improvements, bug fixes, and optimizations. Like a novelist or a film director, a game developer may feel that his or her work is never truly finished, but due to deadlines and the fact that life must go on, one must find a good stopping point. There, at that snapshot in time, you deliver what outsiders might consider a finished product—but you feel that it is never truly finished. I feel that I am nowhere near finished with the Advanced2D engine! But what is in print need not stymie the game’s further development online.
As you may learn from exploring the book’s CD-ROM, I have provided examples of research that I was conducting just prior to the book going to print—code that might have become another engine class or example game. But the important thing is that the engine works and is rock solid. Which brings me back to a topic of iterative programming—a technique that resulted in a good measure of stability in this engine. If at any time you introduce a feature to a game that is really cool but ultimately makes the program unstable, you must find a way to make it stable or you must remove that feature. Such was the case with the threaded garbage collector introduced into the engine back in Chapter 11.
In theory, threading provides enormous performance gains for a game engine (just as more pistons in an automobile engine result in more power). However, there are alternatives to the brute-force approach to performance. In the automobile-racing realm, a turbocharger provides more power than additional pistons, but it’s a complex technology that requires maintenance. For a one-shot drag-racing engine, that’s a great solution because the engine will be rebuilt after every run down the quarter mile. But for a NASCAR race, teams need moderate power with great reliability, so they build race engines with hardened internals but no power adders.
The thread-based code works great on its own, but more research will need to be done to determine how to best support multiple-core processors while maintaining stability in the engine.
What approach do you need to take for your engine? That will depend on your design goals. I prefer strong stability over raw performance. There are many game studios producing stable, high-quality games, but the one studio that stands out every time is Blizzard Entertainment (developers of the Warcraft and Starcraft series). Dating back to the early 1990s, Blizzard’s games have always maintained an exceptionally high standard of quality, both in their code and artwork, and the success of the company’s products is an obvious result. By focusing on quality and stability first and basing your games on that foundation, you can introduce new performance and visual upgrades later. I won’t single out any case examples, but there are many games released today for both PC and console that look terrific, with all the latest fancy buzzwords built in (which marketing people love!), and yet some games are riddled with bugs. Consider these issues while developing your own games. What would improve the gameplay more—a normal mapping shader or a more fluid animation system?