<story><title>Game Programming Patterns</title><url>http://gameprogrammingpatterns.com/</url></story><parent_chain></parent_chain><comment><author>Jare</author><text>Most lists of design patterns (including but not limited to the GoF and this site) are written with the noblest of intentions, and contain a lot of insights and interesting solutions. Patterns can provide specific solutions to specific problems, and also a common vocabulary for developers to talk about these problems and solutions.&lt;p&gt;Unfortunately, for the past 18 years I have seen repeatedly (in the game industry and outside) that they tend to be used as shopping lists by developers who can&amp;#x27;t (or don&amp;#x27;t have time to) think, design and architect properly. The result of such approach to development, let&amp;#x27;s call it Pattern Oriented Design, are bloated, overengineered and underperforming systems that are still harder to write, document, test and evolve, than the disorganized messes they replaced.&lt;p&gt;So, nice work, but beware programmers: you must first understand the problem you are trying to solve, before you go shopping for a solution.</text></comment>
<story><title>Game Programming Patterns</title><url>http://gameprogrammingpatterns.com/</url></story><parent_chain></parent_chain><comment><author>krakensden</author><text>I love big long articles on the main loop. It&amp;#x27;s one of those wonderful problems that seems like it ought to be easy but turns out to have lots of subtle (and important) complications.</text></comment>