新手游戏开发者最大的错误是试图一次性完成整个游戏。
你会想象所有的战斗、制作、AI、世界生成、派系、生存机制、过程式故事、天气系统、对话、任务和成百上千其他功能，而你还没有完成移动。
我以前也这样做。
最终，我开始按如下方式工作：
- 基础
- 墙壁
- 家具
而不是反过来说。
1. 创建项目蓝图
在编写代码之前，写一个简单的文档，回答：
- 什么是这个游戏？
- 什么是最终目标？
- 哪些系统将最终存在？
- 哪些系统将在什么顺序中被建立？
例如：
阶段1 — 移动
阶段2 — 移动
阶段3 — 装备
阶段4 — 战斗
阶段5 — 解剖
阶段6 — 状态效果
阶段7 — AI
阶段8 — 世界生成
具体阶段并不重要。
重要的是要有一个路线图。
如果一个功能属于阶段8，不能在阶段2中工作。写下来，继续。
这就避免了大规模的范围扩张。
2. 只建造当前阶段所需的内容
常见陷阱：
- 我要建造一个完美的游戏。
不。
未来的系统应该影响当天的设计。
但它们不应该在当天被实现。
好问题：
- 我们应该如何实现AI？
坏问题：
- 我们应该如何实现AI，才能在游戏中实现最好的效果？
记住将来。
不要建造它。
3. 完成一个系统之前不要开始下一个系统
一个系统不是完成的，只要它存在。
一个系统是完成的，只要：
- 它工作
- 它经过测试
- BUG被修复
- 设计被记录
只有这样才继续。
这防止了项目变成一个巨大的半成品。
4. 保持一个存活项目状态文档
有一个文档来跟踪：
存在的内容
- 移动功能工作
- 移动功能工作
- 装备功能工作
已知问题
- 装备总是放入主手
- 没有实现负担
未来工作
- 后期添加盾牌
- 后期添加装甲覆盖
这成为项目的记忆。
几个月后，你不需要猜测你曾经想的是什么。
5. 分离“现在修复”和“后期修复”
不是每个问题都值得立即关注。
当你查看你的代码时：
现在修复
- 破坏功能
- 引起BUG
- 违反你的设计规则
后期修复
- 正常工作
- 可以变得更干净
- 可能在未来阶段中很重要
这防止了无限的重构。
许多项目失败，因为开发者花了几个星期来完美的代码，但它已经工作。
6. 在基础上建立复杂性
许多开发者希望“有趣的东西”立即出现。
战斗。
BOSS。
魔法。
故事。
问题是，这些系统依赖于更低级别的系统。
例如：
战斗依赖于：
- 行动者
- 装备
- 移动
- 转变
- 位置
试图在这些系统存在之前建立战斗通常会导致混乱。
先建立基础。
有趣的机制会变得更容易后来。
7. 将事项写下来，而不是将它们保留在脑中
如果你想：
- “如果我有时间，我会实现AI”
你很可能不会。
创建一个回款单。
每当出现一个酷的想法：
- 写下来
- 然后回到当前阶段
这保持了创造力，而没有破坏焦点。
8. 评审比增加功能更有价值
完成一个阶段后：
- 审查它
- 问：
- 什么是破坏的？
- 什么违反了设计？
- 什么会在将来成为问题？
- 什么应该被记录？
一个坚实的审查往往比添加另一个功能更改善了项目。
9. 不要追求完美
完美是最快的方法来杀死一个项目。
目标是：
- 正确
- 稳定
- 可维护
不是：
- 完美
- 终极
- 完成
许多成功的游戏从非常简单的基础开始。
复杂性在后来。
10. 认真地思考一个建筑师
当建造一栋房子时：
- 你不会在屋顶存在之前安装吊灯。
游戏开发也是如此。
每个系统都应该有一个存在的理由。
每个功能都应该有一个地方在路线图中。
每个阶段都应该比之前更强。
慢慢地前进，生存比快速前进更容易被丢弃更好。
我学到的最重要的教训：
最失败的项目并不是因为想法不好。
它们失败是因为开发者试图一次性建立所有东西。
建造一个阶段。
完成它。
审查它。
记录它。
然后继续下一个阶段。
重复足够长的时间，直到你醒来有一个真正的游戏。
这是我实际上做的：
步骤1：在编写代码之前创建蓝图
在触摸任何代码之前，创建一个蓝图文档。
蓝图应该回答：
- 什么是游戏？
- 什么是主要系统？
- 哪些系统将在什么顺序中建立？
- 哪些系统将不被建立？
例如：
阶段1：移动
阶段2：移动
阶段3：装备
阶段4：战斗
阶段5：解剖
阶段6：状态效果
阶段7：AI
目标不是计划每个细节。
目标是创建边界。
如果战斗属于阶段4，那么战斗在阶段2中不应该被实现。
步骤2：定义阶段的合同
在编写代码之前，定义什么是完成的。
例如：
移动阶段要求
必须：
- 存储物品
- 添加物品
- 移除物品
- 展示库存
不必：
- 装备物品
- 使用物品
- 制作物品
- 交换物品
这些属于后期阶段。
这保持了范围的控制。
步骤3：仅建造基础
实现满足阶段合同的最小代码量。
不要添加额外的功能。
不要添加未来系统。
不要优化尚未存在的问题。
目标是：
工作 > 巧妙
步骤4：完成阶段
一个阶段不是完成的，只要代码存在。
一个阶段是完成的，只要：
- 功能工作
- BUG被修复
- 实现与合同相符
- 项目仍然正常工作
只有这样才继续。
步骤5：进行正式审查
完成阶段后停止编码。
审查阶段。
查找：
合同违反
违反了同意设计的东西。
例如：
- 库存意外包含装备的物品
- 装备系统修改库存直接
BUG
不正确工作的东西。
例如：
- UI 文本溢出
- 重复物品存在
- 动作消耗错误的转变
架构问题
今天工作的东西，但可能会在将来成为问题。
例如：
- O(n) 查找可能变得昂贵
- 硬编码对玩家
- 系统过度耦合
将来兼容性问题
今天接受的东西，但应该被记录。
例如：
- 武器总是装备到主手
- 没有支持盾牌
步骤6：分类发现
不是每个问题都值得立即修复。
使用分类。
现在修复
- BUG
- 合同违反
- 破坏功能
后期修复
- 重构
- 未来兼容性
- 性能问题
忽视
- 正常工作
- 没有真正影响
- 预早优化
这防止了无限的打磨。
步骤7：仅修复“现在修复”项
不要修复所有问题。
仅修复实际上对于当前阶段很重要的问题。
其他所有问题都应该被记录并在将来重新审视。
这保持了开发的进展。
步骤8：更新项目状态文档
维护一个独立的项目状态文档。
记录：
完成
- 移动完成
- 移动完成
- 装备完成
已知限制
- 武器总是装备到主手
- 没有盾牌物品
延迟问题
- 后期重构计划
- 后期性能优化计划
这个文档成为项目的记忆。
步骤9：冻结阶段
当：
- 阶段工作
- 至关重要的BUG被修复
- 文档被更新
冻结它。
不要继续改变它。
继续下一个阶段。
步骤10：重复
对于每个阶段：
- 蓝图
- 定义合同
- 实现
- 审查
- 分类发现
- 修复关键问题
- 更新文档
- 冻结阶段
- 进行下一个阶段
评论 (0)