您实际上使用图表来建模游戏吗？[关闭]

我的意思主要是UML，但是任何可行的方法都是可行的。那么-您实际上是使用UML /其他图表或其他方法为游戏建模吗？我在大学时曾学习过有关使用UML进行建模的课程，这似乎比实际收益要付出更多的努力，但是我意识到这可能只是因为我从未创建过一个庞大的复杂IT系统。那么值得吗？通常哪种图/方法通常*是最好的？

*当然，很多时候需要选择具体工具来解决具体问题，但也许有一些模式。

编辑：我忘记了一件重要的事情- 在实现东西之前还是之后创建图表？我的意思是-当一个人设计和实现某些东西时，通常会改变主意，或者出现意想不到的事情，而又不得不进行更改，有时甚至是重大更改，而在已经很复杂的图中进行更改似乎与在代码本身中一样无望。

我想认为可以通过图表以一种或另一种方式表示我们周围的一切。即使它只是表示特定对象的状态在整个时间之间的过渡的线性图（例如生物，从出生到死亡经历多个状态）。我使用图表为实际实现奠定思想和想法。我即兴创作了很多。

因此，我的图大多数时候都处于很高的水平，并且感觉就像是思维导图。

举例来说，这实际上是我的游戏中的类继承映射（已被剪切），其中Interactive Object是基本类型。

这是一个FSM（有限状态机）图，用于尖峰陷阱（那些令人敬畏的陷阱，您踩到这些陷阱并且从地面出现尖峰的尖峰）。

这是我最近绘制的一本手册图（之所以这样命名，是因为它经常被用作回到它的图）。它概述了游戏的组成部分，还有助于收集所需的资产，因为您可以立即看到需要什么和不需要什么。我建议在小型项目中使用，因为在大型项目中它们会变得非常庞大。但是，它们可以进一步扩展，以便解决问题。

当我进入较低的层次时，通常是因为我需要规划架构中最复杂的方面，并且通常在那儿处理UML。我从不专心输出绝对干净和正确的UML。我采用了我最喜欢的UML约定，并将其转变为一个不错的思维导图式UML。它很简单，可以为我完成工作，但是出于明显的原因，我不会在期望使用实际UML的环境中使用它。

当我不得不下一个较低的层次时，是我必须描述实际的算法。我使用所谓的流程图。它是一种受白盒测试中使用的图表启发的格式。

我现在绘制的尖峰陷阱样本如下所示：

这通常是图表和实际算法实现之间的最后一层。如果需要，我将进一步详细说明流程图（带有额外的执行指令），并推论或估计复杂性，并建立准确的测试用例。我也更喜欢图而不是伪代码。

与游戏开发无关，我还有一种很好的格式来描述多屏幕应用程序中的屏幕，用户可以在每个屏幕上触发的功能以及屏幕之间的关系。我通常在开始实际开发之前就构建它们，并且它们在整个开发过程中都像地图一样。如果是针对客户，则屏幕图甚至更有用！它可以帮助我从头到尾遍历所有项目，并考虑到所有需要的功能。因此，提供准确的成本和时间估算非常宝贵。

是的，我绝对会画出所有东西。如果我有一个想法，我可以并且一定会为它画一个图。如果我以某种方式启动了一个项目，但至少没有一个非常宽泛的图表来支持我，那我会感到无能为力。

我当然会做-无论是结构上的还是行为上的-我的经验法则是，当制作图表的成本少于试图记住一个月后我在想什么的时候-或者当我需要清楚地说明自己时，我制作图表其他一些开发商

当继承层次结构变得足够复杂时的类图

当对象的实例化之类的东西变成异物组成的科学怪人怪物的对象时的对象图-在厨房水槽顶点和像素着色器用户中特别有用，以确保将所有必需的位都推入管道

当一组对象之间的详细交互变得复杂时的序列图-这在建模复杂渲染流程时非常有用，在渲染流程中，几乎不相关的下游位置需要先前计算的信息

图表是交流，记录和帮助您设计的一种好方法，而设计是软件开发中最重要的部分。UML具有许多功能，但您不应同时使用所有这些功能，而只能使用那些有用的功能。

在新城市中航行时，您实际上是在停下来看看地图，而不是只是继续跟随标志吗？这就是设计与编码的关系。当事物不熟悉，问题很复杂，感到迷茫时，那就是考虑设计最有帮助，最好早做。在实施任何操作之前，更改设计要容易得多。

图表是可视化问题并帮助您进行设计的好方法，特别是对于视觉思考者（这是我们想象中的游戏开发人员中的大多数人）。当问题清晰地映射到图表上时，许多问题变得微不足道，缺陷变得显而易见。您可能在图中发现一些问题：

• 单个组件的连接太多？你可能有一个上帝的对象是很难维持
• 互连太多？也许可以提高模块化，以使体系结构不那么脆弱
• 两个组件之间的通路太多？也许你有紧密的耦合
• 对于游戏等高性能应用程序，热路径或内部循环中是否包含太多组件？这可能会影响您的表现
• 但是，在大多数情况下，该图将显示您设想的设计与实际实现之间的不一致。

此外，图表非常适合与非技术人员或项目新手交流和记录您的设计-并且请记住，在6个月的时间内，您实际上也是该项目的新手！

应从这些考虑因素出发来使用UML。为自己着想？使用最适合的符号。与其他开发人员合作？尝试包括API调用，消息类型，依赖关系的详细信息。讨论架构？黑匣子和简单的连接就足够了。无论如何，没有人会使用UML的全部功能，而且它作为许多人都能理解的一组标准化符号非常有用-而我的餐巾纸涂鸦可能会让您难以理解，反之亦然。

至于我自己，我一直在使用图表-用于个人项目的简单记事本图纸，正在使用的简单UML图表。我认为这个UML图太复杂了，而且我从来没有做过，因为生产和维护它的成本超过了它的收益，但是YMMV当然是。

我会说有两种类型的图。形式图和涂鸦。

关于形式图，当我与其他程序员一起工作时，我会这样做，但是当我独自编程时，我很少这样做。

但是，这并不意味着我会坐下来编写所有想到的东西。我认为，编程（或实际上是生活中的任何事情）时最重要的事情是先思考然后再做。

编码是非常机械的任务。您键入，并且单词出现在屏幕上。这个想法是，当您开始编码时，您应该已经解决了手头的问题。乱涂乱画是整理您的想法的好方法，甚至可以强迫自己做出需要正确进行编码的想法。涂鸦并非要保存以备将来参考，只是为了您可以轻松地了解自己的思维过程。

如果您花太多时间思考，请不要担心。我认为当您将90％的时间和10％的代码投入于工作时，就会取得良好的平衡。我遇到了几个“高级”程序员，他们靠“我们没有时间去思考，只是去做”而生活。但是，即使他们比那些花时间思考自己在做什么的人更早地调用代码“完成”，他们（或之后留下的不幸的灵魂）也要花费无数的时间来修复和修补本应正确构建的东西从一开始就。

最好的是，思考是免费的！您不必坐在计算机上思考。您可以在进餐，上下班，锻炼时思考代码...实际上，最好的主意是在您最不期望的时候出现的，因此请始终保持开放态度，只有在真正了解自己的知识后才开始编写代码要去编码。

这是我碰到的相关文章。

编辑：关于图表的实际格式和类型，我建议您使用自由样式，并使用手写方式代替使用预先打包的工具。请记住，关键是要帮助您进行思考，因此请随意画画。语义是您喜欢的任何事物，并且它们在图表之间甚至在图表的不同部分之间可能有所不同。

与预打包工具相比，自由样式/手写图具有三个主要优点：

1. 您不会被迫遵守所选择的任何工具所支持的图表类型。有时mapmind会起作用，有时更像UML会很好，而其他时候逻辑图会起作用。有时，完全自定义的图表是可行的，并且没有任何工具可以为您提供自由样式图的所有灵活性（尝试在您喜欢的包装中在纸上打一个孔，然后在纸的反面继续，看看会发生什么）

2. 您将花费更多时间实际绘制图表，而不是使用该工具。无论使用哪种工具，笔和纸在绘制图表时总是比通过键盘和鼠标在菜单中查找要查找的特定元素更快。

3. 您无需计算机即可手写。大多数时候，我都在做复杂的设计，我在图书馆，咖啡馆甚至飞机上进行设计。同样，好主意总是在最不适当的时刻出现，因此请务必随身携带一些东西，然后再写东西。

值得一提的是2013年游戏开发者大会上的一些设计图演讲。这些都是非常实用且经过路考的示例-看来这些年来在许多会议上都有介绍。

（其他答案在说明为什么以及如何以设计为中心的图可以极大地帮助计划，构建，扩展和维护代码库方面做出了令人钦佩的工作，因此我将不谈这一方面，并​​相信这些资源可能会有用给访问该问题的任何人。）

Joris Dormans和Ernest Adams讨论了Machinations游戏设计/平衡图表系统。（这是来自GDC EU 2012 的付费墙GDC Vault视频；来自Dormans Wiki的GDC 2013 样本。）Wiki并非描述，而是以下对系统的描述：

机械化是一个理论框架，是一种交互式的，动态的图形表示形式，将游戏描述为动态系统，并专注于其中的封闭反馈回路。目的是找到一种方法来表达和研究（重复）游戏结构。机械化为游戏设计和平衡的直观而精致的实践提供了新的视角。

诺亚·法尔斯坦（Noah Falstein）进行了名为“拼图依赖图的奥术”的演讲（付费墙GDC Vault视频）。我在这里找不到任何非付费链接，但是许多人都在网上讨论或发布了他们的笔记。

两种讨论都讨论了它们的创建时间以及如何在某种程度上维护这些图。

您可能应该查看有关使用简单的抽象语法来描述游戏循环，如何帮助您识别设计问题以及在该级别进行迭代的容易程度的文章。

http://www.gamasutra.com/blogs/JoshuaStarner/20130205/186060/Applying_Abstract_Models_to_Game_Design.php

我还可以根据游戏循环的经济学原理，使用抽象资源来跟踪诸如机会，运气或准备之类的事情，来指导您自己从事该主题的工作：

http://www.stephanebura.com/diagrams/

如果您发现此方法有用，则应该看看Joris Dormans的Machinations，这是制作此类图并运行其仿真的工具：

http://www.jorisdormans.nl/machinations/

他的书中解释了他的整个过程：

http://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274/