On: Game Programming Patterns

[tieTYT]

I've have to make a confession: Almost every time I use a pattern it makes my code more complex and harder to understand. I've used visitor, composite, singleton, all sorts of factories, decorator, proxy, state, strategy, etc.

You have a problem, then you realize, "I think this is what the x pattern is for. How does that pattern work, again?" You then google it and try to implement it correctly. Almost by definition, you're not implementing the most obvious solution. If you were, you probably wouldn't have to google it. It'd be better to implement the simplest solution that could possibly work.

I think design patterns may be good as a communication tool, and no more. It's faster to say, "factory" than to describe the pattern's implementation. But code maintainability is way higher priority than using a pattern and in my experience pattern implementation and code maintainability are mutually exclusive.

[GuiA → tieTYT]

Design patterns are a thing that are useful only when you've essentially rediscovered them for yourself in natural solutions.

I developed games as a kid for many years, and I developed solutions to some problems that I identified later as patterns while reading the GoF book.

However, if I had read the GoF book in the first place and tried to forcefully implement patterns just based on reading about them in a book, I'd have done a miserable job.

[lifeisstillgood → tieTYT]

I actually had to tweet this:

  Almost by definition, you're not implementing the most 
  obvious solution. If you were, you probably wouldn't have 
  to google it

Thank you