我们都知道，独立游戏开发基本上是一场永无止境的 boss 战，要对抗许多敌人，比如范围蔓延（scope creep）和营销。对我个人而言，这些确实是最难的问题。今天我想聊聊在开发游戏时，我是如何尝试控制范围的。
这并不是通用的建议，很多内容取决于你正在制作的游戏类型。但我想，也许其中一些可以帮助那些只差一个 YouTube 教程就会不小心把自己的“小型独立项目”变成 12 年 MMO 开发周期的独立开发者们。
简单的敌人 AI 被低估了
我避免的最大陷阱之一是对敌人 AI 进行过度设计。起初我有很多想法：
- 也许我应该实现高级路径寻找。
- 如果敌人协同攻击会怎样？
- 我应该学习行为树吗？
- 我的敌人状态机应该有多少状态？
随后我提醒自己，我只有一个人，而且我还想在宇宙热寂之前完成游戏。于是我的最终敌人 “AI” 其实非常简单：
- 持续向玩家移动
- 以锯齿形左右移动
- 每隔几秒随机跳跃一次
就这么多。
没有行为树。没有花哨的导航系统。没有 “战术决策”。随机的侧向移动和跳跃已经足以让敌人大多数情况下不卡住，老实说？在实际运行时的感觉远比纸面上听起来好得多。
让你的美术风格符合自身能力
我主要是程序员，无论是游戏开发还是日常工作，所以我必须从零开始学习 Blender。这本身就已经耗费了大量时间。
接下来就是另一个问题：作为独立开发者，要制作大量细致、高质量的 3D 资源非常困难。比如，“花 14 小时建模一根生锈的管子，却仍然不满意”——这真的很难。
于是我没有去硬拼，而是选择了简化：
- 简单的几何形状
- 高度可复用的资源
- 采用写意风格而非写实
- 设计资源时特意让它们可以在多个场景中出现且不显突兀
这些也帮助我在所有资源之间保持了一致的设计语言。
关卡设计要配合你的限制
关卡不应只服务于玩法——它们也必须配合你的制作上限。
因为我的敌人移动方式非常简单，我把关卡设计成这种移动仍然能够顺畅运行的方式。更宽敞的空间、易读的布局、减少敌人因为追踪玩家而卡死的情况。
资产也是如此：关卡尽量围绕复用素材来设计。如果一面墙、一个平台或一个道具能够在约 20 处出现，只需做一点小改动，那对独立项目来说就是巨大的收益。很多范围蔓延正是因为你在与自己的系统硬碰硬，而不是围绕系统去设计。
选择能够快速迭代的工具
我特意选择了 Godot 引擎，因为它轻量、易上手，并且迭代速度极快。原生的 Blender 文件导入功能本身就为我省下了大量时间。
我也坚持使用 GDScript 而不是 C#。
我是否可以用其他语言让某些系统写得更“干净”或更“优化”？可能可以。
但在独立开发时，快速迭代胜过理论上的完美。能够快速测试想法、故意弄坏、修复再前进，这种能力极其宝贵。很多未完成的项目在技术上很惊艳，却少有真正完成的。
最后感想
我认为独立游戏开发中最难的教训之一，就是接受限制并不总是坏事。有时候，限制恰恰是把游戏逼向你能够实际完成的形态的关键。
每个功能单独看都很酷，危险之处在于每个功能都会带来：
- 更多的 bug
- 更多的平衡工作
- 更多的资源
- 更多的边缘情况
- 更多的测试
- 更多的时间
- 更多的动力流失
有时最聪明的做法就是有意做一个 “够用” 的版本，然后继续前进。
再次声明，这些并非通用建议。但它们对我本人帮助很大。
我正在开发的游戏叫 Defrost，上面的大多数做法都可以在预告片里看到（希望这不违规）：
https://www.youtube.com/watch?v=QTYLjI8De0g
评论 (0)