Game programming patterns
published on 2013/12/23
We don’t really do game programming patter ourselves at work (at least not yet) however it is an interesting field of software engineering especially since in many cases it requires managing huge complex digital assets and fulfilling a pretty high bar of performance requirement.
It can also offers a lot of lessons for people like us who deals with more general business software applications.
This book aims to collect and explain various game programming patterns.
Here’s an example on the topic of Component
Hold on a minute; this is getting out of control. Software Architecture 101 tells us that different domains in a program should be kept isolated from each other. If we’re making a word processor, the code that handles printing shouldn’t be affected by the code that loads and saves documents. A game doesn’t have the same domains as a business app, but the rule still applies.
As much as possible, we don’t want AI, physics, rendering, sound and other domains to know about each other, but now we’ve got all of that crammed into one class. We’ve seen where this road leads to: a 5,000 line dumping ground source file so big that only the bravest ninja coders on your team even dare to go in there.
This is great job security for the few who can tame it, but hell for the rest of us. A class that big means even the most seemingly trivial changes can have far-reaching implications. Soon the class collects bugs faster than it collects features.