Don’t hide the flow!

Design patterns have their place in C++. Don’t abuse them! Let’s look at one of the most common design patterns used in games- the “strategy” pattern. Games often define an “Entity” base class which specifies an interface that all game objects adhere to. Game objects derive from this Entity class and, via polymorphism,  exhibit different behavior without the underlying engine having to know anything other than the base Entity interface.

It’s tempting to stuff as much common behavior in the base class as possible, and, when that becomes too bloated, create more classes in an inheritance scheme between the base and the final child (for example Entity<---WalkingEntity<---Human).

Don’t get in the habit of stuffing tons of behavior towards base classes! As the behavior is spread out amongst more classes, it’s very hard to track the program flow, and more difficult to anticipate the effects of changing something.

What’s an alternative way to get code reuse? You’ll often hear “use composition” floated. Instead of a deep inheritance chain, you get your reuse via attributes- in the case above, Human would derive from Entity, and then have, as an attribute, an instance of a Walking behavior class. Now, the flow can be more easily tracked at the Human level…there’s no hide and seek with virtual overrides. Components are nice because unintended side effects are low, and program flow can be traced at the Human level more easily.

That being said, in practice I use both. There is some functionality that is *so* widespread and *so* predictable and *so* self-contained that stuffing it in an intermediate class in an inheritance chain makes sense. This is more a walling-off intent- I know that 100% of the children that derive from that class will not override those methods.

Finally, I’ve found a place where neither inheritance nor composition does the trick- AI. I use state machines for AI, and I’ve found two annoyances. One, a lot of boiler-plate code is needed. Two, it’s difficult to get reuse out of state machines. To solve the first problem I rely on macros (yes, #defines, to a hilarious extent- whole state classes in a single macro, and hooking up the states to their owner’s callbacks). The second problem, reuse in state machines, is interesting. There doesn’t seem to be a good solution without destroying the flow. For reuse of actual behavior, I mostly fall back on functional programming. I go oldschool and create functions with no side effects…they operate solely on data passed to them by the AI state execution, and they live independently of everything else. This way, to decipher an AI state’s behavior I at most have to remind myself what those functions do.