Unity 中的 Chaos Goblin 游戏开发方法

开始任何游戏开发项目时，最令人不知所措的感觉之一就是在完成最初的游戏设计后立即感受到的感觉，无论是在餐巾纸上草草记下的一些想法，还是传统的 10 页设计文档。

因为当你决定你的游戏将是一款 ROGUELITE-RTS-MMORPG 后，你实际上必须构建这个东西，明白吗？

假设您决定首先要构建的是 RTS 部分。因此，您记下用户故事、任务或用于组织自己的任何工作单元。

然后假设该列表中的第一项是“实现可滚动地图”。

哎呀！您从未实现过可滚动地图。但没关系，谷歌来救援，对吗？

但是，如果您在网上找到的解决方案不能完全满足您的需要，会发生什么情况？或者你找到的解决方案已经有15年历史了？或者下面有大量评论说这是一个多么糟糕的解决方案，但没有一个评论指出更好的解决方案[^0]？

因此，您无法找到您要构建的任何内容的代码参考。游戏开发者要做什么？

答案就是进入混沌哥布林模式。

进入混沌哥布林模式

对于那些不熟悉地精的人来说，他们是一些奇幻作品中经常出现的种族，通常被描绘成更严肃的兽人或大地精的小表亲。在其他一些属性中，他们被描述为以非常特定的方式精通机械。而且这种方式是不可靠的。这意味着妖精制造的东西有时会起作用，并不是因为它们设计或制造得很好，而是纯粹出于聪明才智和冷静。

这就是混沌妖精游戏开发方法的精髓。现在，我确信我开始有点迷失了，所以让我回过头来总结一下混沌哥布林的本质：

为了进一步说明这一点，让我向您介绍一下《辐射 3》中的总统地铁头（您可以在此处阅读完整的故事）。其要点是，在游戏中的一个场景中，玩家认为自己站在地铁内，而玩家的头饰实际上已被替换为地铁车厢的模型，并且是玩家自己的模型在地铁上移动。预定轨道。

有些玩家读到这里可能会认为开发者太懒了。但事实是，开发人员一直在做这种事情。

而正是这种做法构成了混沌哥布林模式的宗旨，如下所示。

玩家不知道的事情不会伤害他们

假设在游戏的一部分中，玩家站在城堡塔楼内，向外面飞翔的龙射箭。龙时不时地靠近并把头伸出窗户试图咬玩家。

现在，对于玩家来说，龙实际上是飞到那里的。但作为游戏开发者，我们可能会采用一些技巧来帮助消除这种错觉并优化情况。

可以做的一些事情如下：

• 根据龙与玩家的距离使用不同的模型。玩家只有在靠近时才能看到龙的细节，那么为什么不将龙的 3D 模型替换为细节较少、但占用内存空间也较小的模型呢？

  
  

• 当玩家不看龙时将其关闭。通过跟踪玩家正在看的位置，我们可以有选择地打开和关闭 3D 模型以节省渲染时间。

  
  

• 防止玩家看到未完成的工作。可以说，无论出于何种原因，塔外环境的艺术尚未完成。因此，如果玩家走到窗台上，他们将什么也看不见。为了解决这个问题，游戏设计师决定让窗台成为即时死亡点。因此，当玩家站在壁架上时，将会播放 3 秒的龙吼声，并且玩家的屏幕将开始变暗。一旦 3 秒的声音结束，我们就会播放一段龙吃掉玩家的快速动画（也许会重复使用我们已有的动画）。对于玩家来说，壁架只是龙可以挑衅他们的地方；他们不需要知道这样做是为了防止他们看到未完成的工作。

  
  

• 也许当龙将头伸进窗户时，我们用更小但更详细的头部模型替换完整的龙模型。这将使我们能够从不使用的模型中释放内存，同时为玩家提供更好的体验。

  
  

如果您在游戏行业工作了很长一段时间，您可能会认为上述是标准做法，但曾经有一段时间这些技术被认为是聪明的伎俩并且非常创新。

现在你需要想出新的方法来欺骗你的玩家，让他们认为他们看到的东西远不止这些。

最好的解决方案是当前正在运行的解决方案

许多游戏开发者陷入困境，因为他们试图提出涵盖未来所有可能场景的解决方案。这种态度在适当的情况下可能很有价值，但当你处于混沌地精模式时，目标是让某些东西尽快发挥作用。

对此的补充：

有缺陷的原型比任何未完成的杰作更有价值

与上面的观点类似，许多开发人员在尝试实现某个功能时会陷入僵局，因为他们尝试过早进行优化。

优化应该留到项目需要在开发人员控制之外的机器上运行时才进行[^1]。

在做 X 之前我需要知道多少？答案是，无论你现在拥有多少知识就足够了

这是许多初学者游戏开发者遇到的另一个绊脚石。他们将推迟实现一项功能，这样他们就可以再学习一门课程，再学习一门在线教程，再观看一个视频，然后他们就可以准备好实现他们的游戏了。

我对此感到特别内疚，并且知道它是多么阴险。

为了给您提供一个更具体的示例，假设您的任务是从头开始编写 Pong 游戏的程序。

根据您知道或不知道的情况，可以采取不同的方法：

• 如果您熟悉 Unity 的物理系统，那么这是一个相对简单的工作。您只需使用几个刚体和碰撞器，施加力和速度，使用物理材质来实现球的弹力，仅此而已。一个准系统的 Pong 克隆。

  
  

• 但是假设你不熟悉Unity的碰撞系统，你只知道如何使用Unity的变换组件，那么你只能得到一个物体的位置和大小。

  • 但！这足以实现 Pong，您可以编写一个脚本来跟踪球的位置和大小，并将其与球拍的位置和大小进行比较，以检查是否存在碰撞。

    
    

• 或者也许您甚至不了解 Unity，您只知道 C++ 以及如何打印到控制台。

  • 但这也足够了！您可以使用终端技巧来打印行和列的符号来表示球、球拍和比赛区域。这与游戏循环的概念一起，足以编写一个响应输入的令人耳目一新的 UI。

    
    

• 或者您甚至没有计算机科学背景，或者没有上过 C++ 课程，只知道 Javascript？

  • 没问题！您可以使用Phaser ，它使用 JS 作为主要语言，并附带渲染和物理组件。

    
    

• 连编程都不会？绝对没问题。

  • Gamemaker是一款具有免费版本的商业游戏引擎，并且具有无代码选项。
  • GDevelop是一个免费的开源游戏引擎，也提供无代码选项。

你已经知道我要说什么了，对吧？

没有失败的项目，只有成堆等待重新利用的废料

大多数游戏开发者通常在某个地方有一两个（或 10,000 个）废弃的项目。浪费它们没有意义。如果那里有类似暂停系统的代码，请重新使用它。重写同样的东西是没有意义的。即使你清楚地记得怎么写，也要抄下来；如果很难适应，那么就重复一遍，这样下次就会更容易。

也许您甚至有一个研讨会项目[^2]，其中有一些可以重用的代码。

看到闪亮的东西了吗？拿一个闪亮的东西

需要对话系统吗？找到一个开源项目并重新利用它。它满足您的所有要求吗？不？是否达到50%以上？是的？那么值得使用它，而不是从头开始创建一个新的。

库存系统？在 itch.io 上找到一款开源游戏并采用他们的系统。

需要第一人称相机吗？利用预构建的资产来处理它[^3]。

那里有很多出色的游戏开发人员，毫无疑问比你我更熟练。

除非有特殊原因，否则一切都应该被视为使用预构建系统的候选者。但是，确实存在合理的例外情况，例如：不要使用仅仅复制粘贴的代码作为游戏的主干（至少确保您理解它、清理它并对其进行评论），并避免使用这个模块已经有十年的历史了，其作者大概是在热带某个地方闲逛，与猫王、图帕克和玛丽莲·梦露在一个没有狗仔队的天堂里喝着麦泰酒。

如有疑问，请复制

如果您不确定是否要实现某个功能，请找到一款与您想要的功能类似的游戏并模仿它。

我所说的“复制”是指设计方面，如控制处理、摄像机视图和机制，而不是艺术风格、故事或角色。

例如，在我们现在已经被遗忘的假设 ROGUELIKE-RTS-MMORPG 中，滚动应该有多快？

您无需猜测，而是可以看到另一个 RTS 是如何管理它的。假设您观察《帝国时代 II》（一款具有历史意义的 RTS），并发现它允许用户控制光标移动的速度。您甚至可以将游戏与 AoEII 并排放置并调整光标，直到感觉相同为止。您会惊讶地发现有多少开发人员依靠像这样的简单、低技术含量的解决方案来实现他们的目标。

离别的思念

那么，当你结束了混沌哥布林的滑稽动作之后，你应该做什么呢？好吧，休息一下，给自己泡杯茶，稍后再返回代码。

让您的代码休息后（如果天气太干燥，则在湿毛巾下），您应该稍微整理一下并分享它。是的！最好与高级开发人员、同事、同学共享，或者在最坏的情况下与在线社区共享[^4]。

你为什么要分享它？因为成为一名混沌妖精并不是要创造出耐用或最佳的东西；而是要创造出一些持久的或最佳的东西。这是关于构建有效的东西。它不必功能完美或看起来漂亮，它只需要工作即可。这种类型的开发会产生结果，但结果很少能立即投入生产。因此，咨询某人以提供反馈至关重要。

根据项目的阶段，您可能没有时间立即实施此人的意见。如果是这种情况，您至少应该在代码中记录这些注释[^5]。

就是这样！您现在拥有全球专业游戏开发人员用来解决问题的排名第一的技术。

我建议是时候喝第二杯茶了，不是吗？

笔记

[^0] - 这是一个令人惊讶的普遍现象，被命名为“丹佛寓言”，有关更多信息，请参阅以下学术文章。

[^1] - 这有点概括，与大多数概括一样，它可能不如对项目需求进行彻底分析那么有帮助。然而，一个好的经验法则是推迟优化，直到真正需要它为止。如今，优化视频游戏已经不像以前那么令人畏惧了。一些游戏引擎公司（例如 Unity）甚至可能会提供免费咨询来帮助您。毕竟，成功发布游戏符合他们的最大利益。

[^2] - 研讨会是我用来增进对 Unity 理解的方式或实践之一。您可以在此处阅读有关它和其他技术的更多信息。

[^3] - 您可以在本文中找到一个非常好的 FPS 控制器包以及其他有用的工具

[^4] - 这需要注意的是，您在网上收到的大约 95% 的评论可能是毫无意义的、不完整的、过时的，或者反映了作者深刻的个人信仰，无论它们是什么。因此，请始终以一定程度的怀疑态度对待此类反馈。尝试寻找有用的评论，忽略或消除其余的评论，并真诚地努力寻找可以与您共享代码的人。

[^5] - 不同的团队在维护代码文档的位置方面遵循不同的规范，您应该遵守这一点。然而，一般来说，我主张将代码的文档放置在与代码本身相邻的位置。如果这不可行，请考虑在您选择的代码版本控制系统中使用git 子模块或其等效模块。如果文档不能位于主存储库中，它至少应该位于 git 子模块中。