有什么设计模式对游戏开发特别有用吗?

访客。

观察者。

命令。

代理(用于网络游戏)。

几乎所有的创造模式。

想想,“scenegraph”。

游戏不是真的 那个 与其他类型的应用程序不同,至少在人们认为的程度上不同。我说这是一个专业的游戏开发人员以及一个专业的非游戏开发人员:)

请记住,这些不是通常的“设计模式”要解决的典型软件架构问题——它们是游戏设计问题,即对最终软件的一组需求。因此,典型的软件模式并不真正适用。出于这个原因,对于你描述的类型来说,没有真正的软件模式,因为在大多数情况下,在多个游戏中没有一组商定的规范和需求。这些特性通常很大程度上依赖于游戏设计,程序结构也随之而来。当然,各种各样的书中都有这样的例子——例如,游戏编程gems系列是强烈推荐的——但它们只是你必须为你的特定需求定制的起点。

任务-它们能重复吗?一个任务是“失败”还是不完整?它们包含多个阶段吗?在任务能够提供之前,是否有必须满足的标准?有需要更新的日记吗?最后有自动奖励吗?完成的条件是什么,如何检查,何时检查?某些事件是由接受任务或任务完成引起的?在任务中是否有玩家进步的概念?有些任务是强制性的吗?任务是以某种方式安排的吗?基于设计,所有这些将在不同的游戏之间产生巨大的差异。

现在,游戏程序员发现自己使用了很多技术和方法,例如,嵌入脚本语言、使用二维散列或分区的空间数据库、有限状态机等,但这些实际上只是一些通用工具,恰好能很好地映射到游戏开发者所面临的问题。

如果你阅读《四人帮》,整个创作模式部分都是为了创造一个迷宫。

我的拙见是所有的模式 可以 在游戏中是有用的,但一般来说,模式的最强大用法是在开发过程中出现的,而不预先确定特定目标。

换言之,图案是一个伟大的白话 是 . 但是,将它们用作实现策略是很糟糕的,因为以这种方式使用它们通常会导致复杂、膨胀和缓慢的代码。

我想说的是,大多数游戏都可以大量使用,这取决于游戏的类型,有些游戏可能比其他游戏更有用。

如果我不得不选择一些最有影响力的游戏设计:

• 观察者:大部分逻辑是基于事件和反应。
• 责任链:在运行时改变行为(通电等)。
• 状态:有明显的原因。
• 复合:例如,库存管理或场景图。