Are there any design-patterns specifically useful for game-development?

This question's been bugging me for a long time. I've always wonde开发者_如何学编程red how game developers were solving certain problems or situations that are quite common in certain genres.

For example, how would one implement the quests of a typical role-playing game (e.g. BG or TES)? Or how would you implement weapons with multiple stacking effects in a first-person shooter (e.g. the Shrink-gun or Freezer from DN3D)? How would you implement multiple choice options with a possibly intricate decision tree leading to several different outcomes (e.g. the mission trees in WC)?

---

Visitor.

Observer.

Command.

Proxy (for network games).

Just about any of the creational patterns.

Think, "scenegraph."

Games aren't really that different from other types of apps, at least not to the extent that people think they are. I say this having been a professional game developer as well as a professional non-game developer :)

---

Remember that these aren't the typical software architecture problems that the usual 'design pattern' sets out to solve - they are game design problems, ie. a set of requirements for the end software. As such the typical software patterns don't really apply. And for that reason, there aren't really software patterns for the type of thing you describe because in most cases there is no agreed set of specifications and requirements across multiple games. These features typically depend heavily on the game design and the program structure follows from there. There are certainly examples given in various books - eg. the Game Programming Gems series is highly recommended - but they are just starting points which you must customise for your specific requirements.

eg. Quests - Can they be repeated? Can a quest be 'failed' or do they remain incomplete? Do they contain multiple stages? Are there criteria that must be met before the quest can even be offered? Is there a journal that needs updating? Is there an automatic reward at the end? What are the conditions for completion, and how and when are they checked? Are certain events triggered by acceptance of the quest, or by its completion? Is there a notion of a player's progress within a quest? Are some quests mandatory? Are quests ordered in some way? All this will differ massively from game to game, based on the design.

Now, there are a few techniques and approaches that game programmers find themselves using quite a lot, eg. embedding of a scripting language, spatial databases using 2D hashing or partitioning, finite state machines, etc., but these are really just generic tools that happen to map quite well to the problems game developers face.

---

If you read the Gang of Four, the entire creational patterns sections is geared towards creating a maze.

---

My humble opinion is that all patterns can be useful in games but that generally speaking the most powerful usage of patterns are the ones that emerge from development without targeting a specific goal up front.

In other words, patterns are a great vernacular for what is. They are terrible to use as implementation strategy, however, as their use in this way often leads to complicated, bloated, and slow code.

---

I would say that most of them can be heavily used, depending on the kind of game some might be more useful than ohers.

If I had to choose some of the most influential in a game's design:

• Observer: most of the logic is based in events and reactions.
• ChainOfResponsibility: changing behaviours at runtime (powerups, etc.).
• State: for obvious reasons.
• Composite: inventory management, or a scene graph, for example.