The singleton is probably one of the most controversial design patterns, sparking perennial debate on forums and discussion boards, and prompting analysis and dissection in many articles and papers. It is a bastardized design pattern, almost always misused, that causes a number of problems without really providing any benefits. Singletons ruin code. →

To begin with, the term “engine” (specifically as it related to the game development world) has no strict definition. Therefore, in the interests of keeping everybody on the same page, I’ll define the term as I intend to use it in this article. An “engine” is a collection of robust, reusable software subsystems (possibly including both code libraries and tools) designed to facilitate the development of actual games by addressing specific requirements. The requirements tend to be broadly-defined: rendering, audio, physics, et cetera. Particularly ambitious engines that address multiple broad requirement groups tend be to known as “game engines” rather than just “graphics engines” or “physics engines.”

Now that that’s out of the way, let’s turn to the real issue: how to build game engines. →

Jack and Jill run a race. They’re both the same age, wearing the same track shoes and other similar running attire. The weather is favorable — a pleasant, windless summer afternoon, and they’re running on that fancy red rubberized track. Jill soundly beats Jack by a margin of about half a second. Therefore, girls are faster than boys.

Obviously there’s a problem here. The race was as fair and controlled as it could be, and the results indisputable. The conclusion drawn from those results, however, is obviously bogus. It seems painfully apparent in this case, but strangely when you change “Jack” and “Jill” to “C++” and “C#” (or any two arbitrary languages), people happily accept the drawn conclusions even if they are just as bogus as the conclusion about the superiority of the female form on the racetrack. →

Often, inexperienced programmers will reach a point where they decide that their existing code base is fatally flawed in some way. Perhaps they’ve learned some new techniques that cannot be cleanly integrated into the code, perhaps they’ve stumbled across a requirement they cannot address, or perhaps they simply don’t like the naming conventions they used.

Whatever the reason, the programmer will often decide that the solution is a complete re-write of her code base. “This time,” she says, “I’ll get the design right the first time! My new code will be better, cleaner, more robust, more generic, and overall more powerful and less buggy!”

Unfortunately, rewriting your code from scratch is very often a bad idea. →