在游戏开发中有用的编程设计模式有哪些？[关闭]

我有几本关于“设计模式”的书，并且阅读了一些文章，但是无法直观地指出哪种编程设计模式对游戏开发有用。

例如，我有一本名为《 ActionScript 3》（带有设计模式）的书，其中详细介绍了几种设计模式，例如“模型视图控制器”，“单例”，“工厂”，“命令”等。

作为对此不熟悉的人，我无法弄清楚其中哪一个有用，或者实际上，如果其中任何一个是我应该学习并尝试使用的设计模式。也许还有我什至不知道的其他针对游戏编程的设计模式？

如果您有在游戏开发中使用某种设计模式的经验，我很想听听。如果有理由说明使用它的原因，代码示例或在线资源也将非常有帮助。目前，我对ActionScript 3和C ++实现最感兴趣，但是一定可以从任何语言的经验和示例中受益。

谢谢！

现在给出一些不太建议的回应。不要将这些作为实施建议，更多地作为可能使用的示例。

• 构建器：基于数据一次将一个组件的基于组件的实体设置为一个
• 工厂方法：基于从文件中读取的字符串创建NPC或GUI小部件
• 原型：存储一个具有初始属性的通用“ Elf”字符，并通过克隆来创建Elf实例。
• 辛格尔顿（Singleton）：这个空间故意留为空白。
• 适配器：通过将其包装在看起来像您现有代码的层中来合并可选的第三方库。对于DLL非常有用。
• 合成：制作可渲染对象的场景图，或使用小部件树制作GUI
• 外观：通过提供更简单的界面来简化以后的生活，从而简化了复杂的第三方库。
• Flyweight：以几乎透明的方式将NPC的共享方面（例如模型，纹理，动画）与各个方面（例如位置，健康状况）分开存储
• 代理：在客户端上创建代表服务器上更大，更复杂的类的小类，并通过网络转发请求。
• 责任链：将输入作为处理程序链进行处理，例如。全局键（例如，用于屏幕截图），然后是GUI（例如，在文本框被聚焦或菜单打开的情况下），然后是游戏（例如，用于移动角色）
• 命令：将游戏功能封装为命令，可以将其键入控制台，进行存储和重播，甚至编写脚本来帮助测试游戏
• 中介程序：将游戏实体实现为在不同组件上运行的小型中介程序类（例如，从运行状况组件读取以将数据传递给AI组件）
• 观察者：让角色的可渲染表示侦听逻辑表示中的事件，以便在必要时更改视觉表示，而游戏逻辑无需了解任何有关渲染代码的知识
• 状态：将NPC AI存储为多个状态之一，例如。进攻，徘徊，逃跑。每个人都可以拥有自己的update（）方法以及所需的其他任何数据（例如，存储正在攻击或逃离哪个角色，在其徘徊的区域等）
• 策略：根据您所处的地形，在不同的启发式搜索之间进行切换，或者甚至使用相同的A *框架进行寻路和更通用的规划
• 模板方法：建立通用的“战斗”例程，并具有各种钩子函数来处理每个步骤，例如。减少弹药，计算命中几率，解决命中或未命中，计算伤害，每种攻击技能将以自己的特定方式实施这些方法

由于缺乏灵感而遗漏了一些模式。

我写了关于该主题的书：游戏编程模式。那里的章节可能对您有所帮助。

布兰登·艾希（Brandon Eich）在“ 编码员的工作”中提出的一个很好的想法是，模式是黑客和变通办法：[模式]显示语言的某种缺陷。这些模式不是免费的。没有免费的午餐。因此，我们应该寻找能添加正确位的语言来发展。

作为游戏程序员而不是编译器设计师，我们很少有选择来发展我们使用的语言的选择，但是我们可以学习发展自己的风格以更好地适应我们的语言和要求。模式是其中的一部分，但是不使用模式是另一部分，尤其是因为正如Brandon所说，模式很少会在没有明显的性能，内存或代码敏捷性成本的情况下消失。MVC并不是游戏中很多事情的好模式。Singleton是la脚的C ++静态初始化规则的解决方法，您可能无论如何都不应该这样做。Factory简化了复杂的对象创建-也许您的对象从一开始就应该更简单。流行模式是我们需要时可以使用的工具 要管理复杂的东西，而不是工具，我们一开始就应该使用它们来构建复杂的东西。

好的（游戏）代码可能会使用模式，也可能不会。如果确实使用模式，那么很好-它们是一种很好的交流工具，可以在不依赖语言的高度向其他程序员解释代码结构。如果您认为不使用模式就更好的代码，请不要为它而烦恼-可能会。

当然，正如其他人所说，所有模式在正确的情况下都是有用的，学习如何使用它们的一部分就是学习何时使用它们。但是，Daniel Sanchez-Crespo Dalmau 撰写的出色的《游戏编程中的核心技术和算法》一书列出了六个编程模式和六个可用性模式，这些模式在游戏编程中特别有用。

程式设计：

• 辛格尔顿：我不像很多人那样讨厌这个人。它可用于单人播放器或键盘阅读器之类的东西。
• 工厂：使您可以有效地创建和销毁对象。
• 策略：让您优雅地更改AI策略。
• 空间索引：帮助对空间数据集执行查询。
• 复合：设置有用的对象层次结构。
• Flyweight：通过泛化诸如相同敌人之类的东西来释放记忆。

可用性：

• 盾牌：防止意外激活戏剧性动作。
• 状态：世界/ UI状态的视觉提示。
• 自动模式取消：使游戏更加直观。
• 磁性：自动定位，单位选择简单。
• 重点：消除分散注意力的UI元素。
• 进度：普遍有用。

当然，这本书会详细介绍这些内容。

实体系统是一种很好的模式。这不是完全正确的设计模式，因为它不是严格的OOP。但是，您可以将其与OOP混合使用。

一些好的链接（从顶部开始介绍）：

• http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=387
• http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
• http://games.fh-hagenberg.at/wiki/index.php?title=Componentbased_entity_systems

他们全部。除了辛格尔顿。[/轻浮]

不是真正关于模式，而是关于它们背后的基本原理。在“设计模式：可重用的面向对象软件的元素”（1995年）中，由四人组成的小组（Gamma，Erich，Richard Helm，Ralph Johnson和John Vlissides）仅建议了两个面向对象设计的原则：（1）编程接口而不是实现，并且（2）主张对象组成胜于类继承。

这两个原则在游戏开发的许多任务中非常有帮助。例如，许多游戏程序员已经使用了深层次的类层次结构来表示游戏实体。还有一种基于合成的方法 -基于组件的游戏对象。文章介绍了这种方法。甚至更多的链接。这是一个装饰器模式的例子。

该奇异递归模板模式可避免虚方法和性能损失可能来自虚函数的调用非常有用。

当您实际上不需要具有要使用的接口的基类类型的容器，但是您希望具有类似命名的行为和接口时，这可能是适当的模式。

例如，在为多个平台或引擎（dx vs. opengl）编译类时，可以在编译时知道类型差异的情况下使用此方法。

经过多年的发展，对我来说非常有用的设计模式被我称为“经纪人定义集”。如何用GOF术语来概括它似乎是有争议的，但是我在StackOverflow上写的有关此问题的详细信息。

核心概念是建立模型的某些属性（例如生物的种类），以便该属性的每个可能值都有一个对应的定义对象（每个值一个共享的对象），用于指定其行为，并且可以通过中央代理（在GOF方面可以是注册中心，工厂或两者）访问这些代理。在我的用法中，通常也可以通过标量键访问它们，以促进用于运行时态射影的弱绑定。