游戏规划和软件设计？我觉得UML不方便

在我的大学里，他们总是强调并大肆宣传UML设计和内容，在这种情况下，我认为它不能与游戏结构设计很好地配合使用。现在，我只想就如何开始游戏设计提供专业建议？故事是我在编程方面有一定技能，并且做了很多次要的游戏，例如使2D平台游戏得以扩展。我在程序中发现的问题是质量差的设计。经过一段时间的编码后，由于规划不当，事情开始崩溃（当我添加新功能时，往往使我不得不重新编码整个程序）。但是，没有一个设计缺陷就计划所有内容太理想了。因此，关于如何计划游戏的任何建议？我应该如何将其放入可见的图片中，以便我和我的朋友能够概览设计？

我计划开始和朋友一起编写游戏。这将是我的第一个团队合作，因此任何专业建议都将是我的荣幸。除了UML之外，还有其他选择吗？

另一个问题是“原型”通常是什么样的？

我只想就如何开始游戏设计提供专业建议？

游戏设计是游戏玩法，资产，计分系统等的规范-这些不是特定于软件的。因此，UML是该任务的错误工具。

在设计用于实现这些系统的代码时，UML是完成任务的好工具，可以让您的团队知道并坚持使用更常见的图表类型。通常，在尝试设计功能时，您会知道是否需要使用描述或图表。如果确实需要使用图表，UML为您提供了一种标准的绘制方法，这是一件好事。

经过一段时间的编码后，由于规划不当，事情开始崩溃（当我添加新功能时，往往使我不得不重新编码整个程序）。

这通常是编程方式的问题，而不是计划的问题。好的软件通常易于扩展和重用。如果您坚持良好的编程习惯，此问题将减少。但是更好的计划也将有所帮助，并且您不需要复杂的图表。仅具有功能列表将意味着在编写一件事时，您会想到其他功能，并在编写代码时可以考虑它们。

因此，关于如何计划游戏的任何建议？我应该如何将其放入可见的图片中，以便我和我的朋友能够概览设计？

听起来您在这里混了两个问题，即游戏设计和代码设计。

我建议首先编写一个基本的游戏设计，指定所需的功能，所需的图形和声音，游戏的得失方式等。如果需要帮助，请查阅“设计文档”。

从那里，您将了解需要编写代码的功能。您可以依次查看每个功能，然后尝试考虑如何实现它们。图表可以帮助显示游戏中不同类别和对象之间的关系，但是必须通过练习和/或进一步阅读来了解知道哪些对象需要存在的技能。

另外，请尝试进行规模较小，不那么雄心勃勃的项目。这将使您习惯于编写良好的工作代码，而无需进行大量的计划或重写。

不了解某些内容很容易被解雇。UML是一种工程工具，用于以结构化方式传达您的想法。游戏是可以像其他任何一种一样进行设计的系统。如果有的话，游戏的复杂性和动态性使得它的各个部分以及它们之间的相互作用的可视化表示非常宝贵。

UML图是正在讨论的系统模型的不同视图。我从用例开始，一个人坐在我的程序前面并启动它。就游戏而言，有两种用户：设计师和玩家。我为我可以看到的每件事做一个用例。然后，我制作了一些CRC卡来弄清楚我需要提供的服务。然后，为提供这些服务及其关系的接口制作一个类图。这基于CRC卡。接下来是需要计划和编排的诸如初始化之类的事件的动态图。然后是更详细的静态图，显示实现接口的类。

我一直在编写代码并进行原型开发，并朝着提供满足游戏要求的服务方向发展。在用例中，没有什么不支持用户的。我写了一些无用的图表元素，但是在接口编码和图表之间，我只写了很少的无用代码。图表使我充满信心，了解自己正在编写的类适合整个系统的方式。

我要说明的一点是，琐碎的程序可以在没有计划的情况下编写，但是游戏绝不是琐碎的事情。前段时间，当OOP刚发布时，就进行了许多试验，并提出了一些最佳实践。软件开发社区同意我们需要一种语言来编写和分析软件设计。UML是我们开发的语言。我们都知道并理解它，因此，如果您想使用其他人的解决方案（书籍，在线讨论，文章，模式目录等），而又不想重新发明轮子，则必须学习阅读标准符号。另外，当您强迫自己用另一种语言考虑系统时，您会学到意外的事情。

存在许多不同的方法，但是它们都可以识别问题并以系统的方式描述一种解决方案。这是工程。UML庞大而复杂，但是没有一个模型使用所有构造。就像瑞士军刀。您必须了解它并弄清楚如何使用它来支持您的工程过程。重要的不是哪个过程或方法，而是您拥有一个。否则，您将淹没在复杂性中。

我还与一个朋友（2人团队）一起从事一些独立的游戏项目。作为与您处境类似的人，我可以提供一些有用的提示。

1. 如果您的想法很粗糙，请尝试在超小型原型项目中一次实施一个。例如，我现在正在制作2D平台游戏，而让玩家正确跳动对我来说非常重要。因此，我创建了一个新项目，其中仅有的两件事是：a）在屏幕上绘制播放器，以及b）检测输入并重新绘制跳转（字符甚至不能向左或向右移动）
2. 有些人可能不愿接受这一建议，但请考虑首先编写游戏手册（以解释概念，控件和目标）。这可以为您做两件事-生成急需的文档，但也可以概述游戏的子系统以及玩家的任何必要细节。如果您事先知道玩家需要知道的内容，那么您就知道您需要做什么。
3. 以足够小的代码块（也称为模块化）编写代码，以便可以分解或更好地组织分解后的块，而不会感觉要尝试从一盘意大利面中取出所有中型的意大利面条。

希望您在那里找到了至少一条有用的信息，祝您好运！

我认为您不能否认UML有一些有价值的收获。另一方面，请记住，UML是为业务流程而构建的，您知道，建模系统需要很多人与之交互，并且所有人都有不同的需求和需求。UML试图确保您不会遗漏任何东西或让细节不知所措。

UML是“可视化系统架构的标准方法”

UML描述

• 活动
• 演员
• 业务流程
• 数据库模式
• （逻辑）组件
• 编程语言声明
• 可重用的软件组件

但是，如果您要制作一个简单的游戏，您真的需要对所有这些进行建模吗？

• 演员：玩家。

有什么帮助？

但是，对其他一些事情进行建模非常有帮助。例如，如果您要制作小型MMO，则肯定需要设计良好的数据库架构。

因此，尽管从UML取得的成就非常出色（知道您在做什么，写下需求，并在需要的地方写下流程图的示意图），并且其中的元素非常有用，但我倾向于觉得完整的UML过程是游戏中有一个方形的圆孔。

UML不是一回事，它是其中一些有价值的东西的集合，而其他却没有那么有价值。状态较旧的用例（至少称为用例）

• 名称
• 要求
• 前提条件
• 触发器
• 行动
• 替代行动
• 例外情况

可能非常有用。但是，如果您进行网络搜索（图片），您在“用例”中找到的内容更多是针对常规软件的。

我还要归功于类图。这表明您能够显示所有对象之间的关系，并且知道体系结构的布局。

最终的结果是，在进行建模甚至开始绘制图表之前，应该对功能集进行全面规划，并锁定为int（根据需要/需要进行设置）。这些应该全部放在您的“摘要/处理/脚本”中（有时称为“草稿”，“要素文档”和“故事”）。然后从那里开始您的技术文档工作，其中包含您的模型和图表。

有使用UML的公司，但这些公司通常都是拥有独立的设计和实施团队的公司。公司将创建其所有文档，然后将其提供给一组代码猴子以创建原型/ alpha。它说，如果您可以准确地对游戏进行建模，则应该可以将它分配给完全不同的团队，并让他们进行编程，尽管这不是梦，而是准确性。

他们将在您的大学里教您有关UML的知识，以帮助您将您的想法传达给团队的其他成员，并向讲师展示您对基本软件工程原理的良好使用知识。

就像关于语言，工具或设计的任何讨论一样，它通常取决于您的使用方式。选择最适合工作的工具/语言/设计，并以充分的理由支持您的选择。我承认UML在游戏制作方面不是那么灵活，尽管我可以说我们已经有效地使用了它来为引擎功能建模，例如网络通信和计时，并行任务管理和用例。没有什么比在10个不同的时间向5个不同的团队成员解释同一件事更糟糕的了，因为他们不太了解。这是文档，请阅读。

根据您设计的扎实程度和团队的纪律程度，能够围绕尚未开始的结构建模自己的结构，并确切地知道由于以下原因它们将如何运行，这可能会非常有效。文档。

尽管如此，您可能会听到（并严厉地意识到）这些是生存文档，除非定期对其进行检查和更新，否则它们将很快变得过时且实际上无用。