When I was growing up, one of the philosophies I was taught for solving problems was to formulate a plan. This involved understanding what needed solving, calculating the time allowed, and my and/or my teammates abilities. It is a great philosophy with a wide range of applications. Suprisingly, one field I find myself applying it to is gaming.
Games, to me, are very specific problems that the player goes about solving. A game provides the player with a set of established tools to reach a specific goal. Some may pressure the player with a time-limit; others try to challenge the player’s abilities. The interesting thing about games is that they can be divided into categories or genres. Each genre has a general gameplan that the player can follow to conquer the game. Platforming involves figuring out the physics, turn-based games requires understanding the battle system, first-person shooters requires knowing the equipment, map layout, and possibly team tactics. The player knows that this is a good way to proceed because they’ve played similar games before; they’ve encountered games that present similar problems. In other words, you can start playing a game in a specific genre with a general gameplan in mind, and then fine-tune that plan to the intricacies of that game.
Design patterns are similar in that sense. First, you ask yourself what type (genre) of problem is it and what’s the goal? If you know that there is a user aspect, then you’ll probably want a controller of some sort that organizes the data being shown. If the problem entails making lots of dependent objects that aren’t seen, proceeding with a factory design pattern is a good starting point. Then, once you have a base design (gameplan) set, you can start to work out the intricacies of the unique problem on hand. Solving problems in this way saves time by incorporating prior solutions to similar previous problems. The problems may not be the same, but the general case of what they’re trying to solve is the same.