如何在游戏开发中进行文档管理——与康斯坦丁·萨赫诺夫的访谈
游戏开发初期的文档应该如何编写，谁来负责，是否需要伪截图——关于这些和更多的内容，App2Top的编辑与独立工作室Vengeance Games创始人、课程《游戏设计基础》讲师康斯坦丁·萨赫诺夫进行了交流。
亚历山大·谢苗诺夫，App2Top: 康斯坦丁，你好！在这个采访中，我想和你谈谈文档。这个话题看似不太复杂，但实际上有很多潜在的陷阱。你准备好了吗？
康斯坦丁·萨赫诺夫
康斯坦丁·萨赫诺夫，Vengeance Games: 我很高兴！
很好。年轻团队面临的首个问题之一是：文档该使用什么形式？
康斯坦丁: 如果是团队开发，Confluence是一个非常方便且受欢迎的解决方案。它的优点之一是能够与Jira、Trello和Slack进行集成。
但也有一些细节。由于在俄罗斯使用Confluence比较困难。首先，你需要一张外国信用卡进行支付。其次，使用俄罗斯IP地址时，会收到通知，告知账户将在30天后被封锁。
这意味着，你需要为整个团队提供企业VPN，或者搬离俄罗斯。
如果你是独立开发者，可以考虑使用Notion作为替代方案。
遗憾的是，我目前还没有找到能够完全满足开发者文档需求的俄罗斯替代品。 但我喜欢服务Weeek。
游戏设计师也喜欢使用Google Docs来处理文档，但在其中维护一个大型商业项目的文档是比较困难的。
我知道一些团队在开发前花了很多时间选择文档工具。他们在Obsidian那种出色的内部链接系统与更简单更通用的Notion之间徘徊，甚至在考虑使用GitHub文本编辑器。想要有一个知识库，可以让几个人同时维护。你对此有何看法？
康斯坦丁: 对于文档处理工具的关注，可以防止文档的丢失或者材料从一个系统迁移到另一个系统时的漫长与繁琐。
但我认为，最重要的不是文档处理的系统，而是团队中所接受的管道计划和文化。在一个小型项目中，我们会把所有文档都放在Google Docs里（连甘特图都用“Google 表格”绘制）。
作者某款游戏的文档示例
可以说全面的设计文档和知识库是记录已完成的内容，而不是需要做的内容吗？
康斯坦丁: 在某种程度上是的。
任何文档的根本问题是：时效性。
难点不在于撰写数百页的描述、技术需求和公式，也不是构思和记录。难点在于不漏掉任何一个变化，这些变化可能是在项目会议上由制作人随口提及的，或者是团队成员提出的建议，或者是程序员为优化所做的实际调整。
如果文档不及时更新，如何能让新员工通过它融入团队？如何根据它来测试游戏的功能？那文档存在的意义又是什么呢？
你刚提到了时效性。更新文档总是个问题。新特性不断出现，旧特性又被淘汰… 还不断有新版本上线。很多版本间的区别可能只是一两个数字的变化。这些需要记录吗？总体上来说，什么应该记录在文档中，什么又不该记录？
康斯坦丁: 要回答这个问题，需要记住，游戏开发的文档不仅仅是产品文档。开发游戏时，我们经常需要处理行政文档（规定、规则、岗位结构和部门结构等）、法律文档（合同、协议等）和项目文档。上面提到的版本问题与项目文档有关。
假设我们有一个关于战利品箱机制的设计文档。在2.1.1版本中，战利品箱最多发放四个物品。从下一个版本开始，物品数量不再限制。这是构建版本的问题，因此应该在项目文档中记录下来。
但是，设计文档中不必要保存所有更新历史。我们只需更新文档，说明某一机制当前是如何工作的，或者应该如何工作。
如果几年后开发人员希望恢复到旧的平衡，届时应该有一个管理文档的解决方案，具备版本控制系统，允许找到特定日期的文档版本。
这也是选择专门的游戏设计师文档管理系统的一个重要理由。在Google Docs或MS Word中实现这一点会比较困难。不过，我也碰到过使用OneDrive和SVN存储文档的案例。
当然。还有一点也很重要：谁来负责这些内容的输入？这应该是一个单独聘请的职位，还是制作人或项目经理的职责？
康斯坦丁: 每个人都有自己的责任领域。设计文档由游戏设计师负责。如果文档不及时更新，应该向他们提出为什么不更新的问题。
项目文档，如时间表、构建过程、构建验证等，通常由项目经理和QA负责人来准备。
制作人则负责他们的文档，例如项目愿景和版本组成。
一个好的实践是，写了文档的人也负责文档的时效性。作者要确保其文档保持更新。但是，如果没有建立让作者了解更改的流程，这种模式就难以奏效。
让我们回到我们谈话的开始。设想一下，团队刚开始创建一款游戏。开发初期的文档应该是什么样的，当程序员还没有开始编码的时候？其中该包含哪些内容，哪些可以忽略？
康斯坦丁: 简洁而清晰。你的文档越多，阅读到最后的可能性就越小。文档应当没有歧义和模棱两可的解释。在我的课程中，我总是提到我见过的理想文档的例子：
一目了然：必须做什么，不能做什么，会有什么后果，谁是执行者…
开发初期的所有文档首先应该围绕可读性和可理解性来设计。
由此可以得出另一个论点：不必为执行者猜测工作内容。在描述规格、配置的命名、变量以及其他技术实现细节之前，应与程序员沟通，并确认他们需要知道哪些特性才能开始工作。
当然，如果你的团队合作已久，且已制作过多款游戏，设计师们通常会很清楚开发者们的需求。但即便如此，也可能存在与具体项目相关的细节。
游戏的工作是否应该从文档开始？难道只用手势就能就游戏过程的结构达成一致？就是说，简单在Miro上绘制主要机制、核心循环，然后开始实施？
康斯坦丁: 我很难想象一个不编写文档就能开始的游戏产品。而且在需要撰写产品文档之前，还需要进行大量的工作！
作为游戏设计师，如果没有市场研究和对竞争者、目标受众以及我们团队能力的了解，我很难撰写设计文档。
作为工作室或企业的负责人，我无法设想在没有基本财务评估的情况下开始工作。是的，产品的时限、成本和机制必然会在实施过程中发生变化。更有可能是朝着坏的方向。但如果我没有基本的认识，即这款游戏有潜力覆盖成本，我就绝对不愿意冒险去做这项工作。
说到解释上的模糊性！如果在Miro上绘制了游戏玩法示意图并交给程序员，你得到的并不是你的原型，而是程序员对任务的理解和想法。
是的，如果我们谈的是原型开发，在某些情况下可以接受这种情况。团队如果早已形成默契，简单的，比如超休闲类型的游戏…
但我总是尽量准备完整的文档，而不论项目的大小。
常常很难在精益求精的详细文档和以低成本及快速完成的创业热情之间维持平衡。然而，维持这种平衡是必要的。我没有遇到过这些极端情况在商业开发中都能良好运作。
我们现在谈到了程序员及其视角。那么我们就先停在这里。应如何与程序员合作？特别是在初始阶段。我曾遇到过这样的情况：为他们制定的任务极为模糊，甚至只限于要求方向，然后“放任自流”。这是很普遍的做法吗？
康斯坦丁: 不幸的是，这确实非常普遍。
在初期阶段我们没有确切的产品愿景，这完全正常。只有在我们做克隆时，才能不经过探索就写出明确的技术规范。
如果我们想在类型中引入一些独特的机制，我更不用说独特销售主张，关于产品的外观、玩法和行为的模糊性就必然存在。
而且，制作人可能觉得他确切地知道和看到了游戏。但没有经过实际的游戏测试，这仅仅是一个愿景。
但这并不意味着我们不能有明确的技术要求，而只是要求程序员做“这样那样”。这意味着我们有多个技术要求。我们做一种实现，评估它，与标准、经验和感觉对照。如果理解这不是那个，我们就再写一个新的技术要求，然后再来一次。
愿景可能在某个时刻不存在，但技术要求必须是存在的。
我总觉得如果游戏设计师会编程，那简直是太好了。他可以自己实现机制，立即测试，然后决定是继续还是抛弃。不过，如果游戏设计师不会编程，又该如何评估仅以流程图和一两张Excel表格存在的机制呢？
康斯坦丁: 我尽量不要求游戏设计师写代码。在我看来，有一个明确的范式：程序员负责逻辑和工具，游戏设计师创建游戏体验。
坚持这个范式并牢记很重要：不是程序员在调整射击体验或在引擎中布置对象。所有内容的工作都由游戏设计师完成。他设计了想要玩家如何开火，因此他应该设置武器，理解其特性并进行平衡。
程序员的任务是提供工具，以便游戏设计师能够在不懂C#、C++或其他语言的情况下调整射击效果。
关于独立评估游玩体验，这里有Unity Bolt、UE Blueprints、JSON、XML、LUA、YAML等脚本语言…
有时可以制作纸质原型——桌面游戏，有时可以在简单的引擎中自己搭建，比如Buildbox或GameMaker。但很多东西只能通过程序员的协助进行原型设计。
早在我想向制作人和同事展示我的想法时，我会在Adobe Flash中制作原型，并使用Action Script使其生动起来。因此我转到HTML5和JS。这是节省时间、向团队解释你想要什么的好方法，但很多时候，机制无法在没有完整实现、平衡内容和视觉效果的情况下进行评估。
假设我们向程序员解释了机制，他很好地实现了…… 然后就会有一个问题：数学、公式和游戏平衡在何时进入文档？在开发初期，是否需要认真对此进行思考？
康斯坦丁: 如果你是严肃的企业团队，拥有一定的时间和资金，你可以完全从一开始就制定良好的数学模型，清楚未来它们仍然会发生变化。我自己也在这方面犯过错，很难从企业背景转变为独立开发者的思维方式。
如果你是独立开发者，在初期阶段，通常只需要对将使用的公式有个，大致的理解。有时甚至可以用占位符替代精确复杂的模型（其中一些将活到发布时）。
游戏《复仇阴影》中的公式示例
我非常喜爱数学和剧情，因此在处理平衡表或写脚本时我时常需要提醒自己停下来。
但在早期阶段，确实值得在产品文档中添加机制使用示例。例如，如果你正在撰写一个关于法术机制的大设计文档，请提供一些你希望在游戏中看到的法术示例。不是完整的清单，也不是经过数学推导的平衡，而只是一个会在该机制上实现的内容示例。
好吧，早期阶段可以省略数学，那你对伪截图有什么看法？通过这些可以理解游戏完成时会是什么样子。目前看，这是一个普遍的做法。但它们真的有必要吗？
康斯坦丁: 伪截图是个重要的事情。它们是需要的：
- 用来给投资人留下印象。这是很正常的做法，因为在没有可视化的情况下很难评估潜在产品；
- 用于市场营销，让团队测试所选的图形方法是否能引起观众的兴趣，是否有反馈；
- 用于内部使用。在这个背景下，我称之为目标艺术。为了开发自己产品的视觉风格，拥有一幅满足我们质量要求并反映出我们生产能力的图像是非常重要的。对于独立开发者而言，这并不总是相关的。对于那些已经确定风格、思维导图并按现有指南工作的团队同样如此。
所以，如果我们开始绘制伪截图，文档中是否有必要详细描述视觉风格、界面元素等内容，还是仅需提供一些示例和对艺术家的总体要求，然后再调整结果？
康斯坦丁: 在不同的工作室，做法是不同的。当我在一些大型预算公司工作时，我们会编写详细的艺术文档。在小型工作室，可以通过思维导图来总结——在Figma中准备一个演示或者面板，上面收集来自网络的艺术品或生成的AI图像，以反映我们对游戏中关键资产的视角：角色、建筑、视觉效果、界面元素、魔法、材料等等。
作者游戏中的思维导图片段
假设我们的开发已经顺利推进。文档也随之膨胀。在这个时候应该考虑哪些事情/注意哪些事情？
康斯坦丁: 如我们所述，文档首先应保持时效性。
大型项目常常面临大量过时的内容，只有游戏设计师知道在这种混乱中应当阅读哪些，而哪些可以忽略。
为了避免这种情况，必须设定文档更新的规则以及明确责任人，可随时追究。
某一时刻，可能需要对Confluence的区块进行重组，因为这些内容不再反映日益扩展的项目结构，变得不便于导航。
企业级文档管理的一个关键原则是：搜索和阅读的便利性高于写作的便利性。
而且还有另一种做法。当你是独立团队时，常常可以说“好吧，这个文档已经完成它的任务，我们将其归档，继续前进”。
最后一个问题：你认为一个项目的成功（在此情况下是将其推向发布）有多大程度上依赖于良好的文档？
康斯坦丁: 游戏是风险投资。它们的商业成功依赖于一切或者任何方面。没有任何一份文档能够保证成功，就像没有哪部宪法能保护民主一样。
至于将项目推向发布的过程，依赖于高质量文档是十分直接的。而且非常重要的不是仅仅文档的质量、深度和简洁，而是处理文档的过程，培养责任感——这是开发过程中的极为重要的一部分。
但如同在游戏开发中，总会有例外。如果你是独立开发者，超强的目标感往往比严谨的文档更为重要，而这份文档的唯一读者可能就是你自己。
