WangShuXian6
commented
2 weeks ago 1. 成功的准备
1. 欢迎
欢迎
恭喜你来到这里！如果你正在学习本课程，我知道你非常有热情，并且真正希望提升自己的技能。
课程概述
本课程将帮助你超越游戏设计师在学习文档编写时常见的错误。我们将首先记录一个全新的游戏，更像是一个概念游戏。为什么不记录一个完整的、已有的游戏呢？
首先，即使是记录一个非常小的游戏也需要大量页面和游戏时间，而我们的目标是让你专注于文档本身，而不是游戏。
其次，所有游戏在开发过程中都会发生变化，这些变化也需要在文档中进行更新！为了在本课程中体现这一点，这款游戏将在过程中经历三次变更，你将需要记录这些变更，以模拟真实的游戏开发环境中的情况。
不记录现有游戏的原因
第三个也是最重要的原因是，基于我的经验，大多数完成的商业游戏并没有一个更新到最新的GDD（游戏设计文档），而且这些文档通常由多个设计师编写。因此，要求一个设计师无论经验如何来完成这样一个任务是既不可能也不公平的。
课程目标
本课程提供了一个你可以快速上手的概念游戏，这不仅让你有机会记录游戏及其变化，还给了你充足的空间去提出新的功能建议。所有这些都是为了模拟在真实的游戏开发环境中编写GDD的工作，使你能够真正学习和掌握编写优秀GDD所需的知识。
经验分享
这基于我在多个行业中撰写GDD的多年经验，从为独立项目编写的简短概念文档，到为AAA开发深入解释单一功能的大型文档。我希望本课程能为你提供记录游戏的实用工具和技术，不论公司规模或游戏类型。
感谢
非常感谢你信任游戏设计思维团队，以及我们致力于为你带来最佳游戏设计教育内容的使命。
4. 为什么你的文档应该是有效的、高效的和引人注目的
课程面临的主要问题
本课程解决的一个重要问题是：团队成员可能不会阅读GDD（游戏设计文档）。大多数情况下，团队成员只会阅读与自己相关的部分，但最糟糕的情况是，整个文档可能被遗忘。
这会对游戏产生负面影响，因为有些决策可能没有考虑到游戏设计师的整体视角。例如，有一次我作为程序员在项目中工作，游戏设计师写了一份GDD，但文档难以阅读，有许多空白和未解答的问题。编程团队根据这些内容实现了多个机制，后来才发现，由于阅读文档时的误解，一个重要的系统完全不同于游戏设计师的设想。
即使我是一位细致的阅读者，完整地阅读了GDD，但仍然很难记住和理解其中的内容。游戏的想法很棒，但沟通不太理想。因此，本课程的目标就是解决这一问题。
创建易读和易懂的文档
如何创建让人不仅愿意阅读，而且能够理解的文档呢？请记住，GDD并不是一本书或期刊，更像是一本手册。阅读文档的人必须能够理解并执行其中的内容。
三个关键标准
我从可用性领域引入了三个修改后的标准：
-
有效性：文档必须准确传达需要完成的内容，尽量减少不确定性和误解。
-
高效性：文档应该简明扼要地解释游戏设计，用最精炼、直接的方式表达。
-
吸引力：这是最难做到的部分。要创建吸引人的文档，首先要确保文档有效且高效，并且必须针对读者的需求进行编写。可能需要为不同的利益相关者和开发过程创建不同的文档，例如投资者、团队成员、提案等。你需要为项目的特定阶段创建适合读者的文档。
此外，可以使用合适的形容词、图形和视觉元素来补充信息。
测量文档效果
你可以通过查看是否有人理解文档内容，并是否收到了大量反馈和问题，来衡量文档是否符合这三项标准。很多时候，未收到任何反馈的文档可能是没有人读过的。
现实建议
在理想情况下，所有团队成员都会阅读并完全理解你的文档，但游戏开发的本质是迭代且复杂的。首先，不要假设所有成员都会读完整个文档，因此确保每一部分都能独立执行。其次，如果有些团队成员没有阅读文档，不要因此而受到影响或觉得被冒犯。他们也有其他职责，有些人没有阅读习惯，这是无法避免的。
第三，如果你觉得某个系统或机制描述得不够详细，或者觉得仍需要改进，请保持开放的态度，始终寻求反馈。这将帮助你不断提高作为游戏设计师的技能。
接下来的课程内容
现在，让我们继续课程的内容，以便编写出有效、高效且吸引人的文档。
6. 针对不同开发风格的不同文档
视频概述
嘿！在这段简短的视频中，我将告诉你在创建文档时，根据团队规模和开发规模的不同所产生的主要差异。
经验分享
首先，我想声明，这些内容基于我的经验、与同事的交流以及在游戏设计书籍和文章中所读到的信息。我尽可能全面地向你传达这些信息。
小团队与模板GDD
一般在网上找到的GDD模板非常适合解释简单的游戏概念，这对于启动小项目和小型团队非常有用。
在开发过程中，大多数小团队会将静态文档换成更动态的解决方案，比如Notion或Trello，并在这些平台上讨论各个具体的实现方式。这对于一个有5到6人的小团队来说更加高效。
大型项目与功能规格文档
对于大型项目，比如AAA级游戏开发，多个设计师通常会在各种文档上合作。设计师们一般专注于特定功能，而不是整个游戏。因此，你会撰写一个深入解释某个功能的文档，这称为功能规格文档（feature spec），并基于你、项目负责人或创意总监预先设定的一些目标来撰写。
文档的多样性与详细程度
根据功能的不同，这种文档的长度可能从1到2页到20页甚至更多。通常，它们包含多种图像、视频和表格，有时甚至会被分成更小的文档，以便向不同的团队或功能的不同部分提供详细信息。
重视文档的质量
这意味着无论你是同时负责整个游戏还是只负责某个特定功能，都要在文档编写方面保持高水平。正如《星之卡比》和《任天堂明星大乱斗》的创作者樱井政博所说：“在文档编写方面，你必须始终保持最佳状态。”这意味着要自信地书写，确保自己已经深入研究和设计了该功能。
课程适用性
好消息是，你可以使用本课程中介绍的任何技术，为任何规模的团队和游戏编写出色的GDD。
9. 游戏设计文档（GDD）应该包含什么内容
GDD内容的常见问题
这是关于创建GDD最常被问到的问题，同时也是最难、但也最容易回答的。
模板的局限性
每份GDD的内容都是独特的，因此大多数在网上找到的GDD模板本质上都有缺陷，因为GDD并非“万能模板”。游戏设计的本质决定了不可能用一个模板来适用于所有类型的游戏。
如果你经常从事类似类型的项目，拥有一个模板当然是很方便的，但这个模板应当是你根据这些项目的特定需求创建的。在本课程中，我不会提供模板，而是在课程结束时，你将能够创建和修改自己的模板，这在我看来更加有价值。
GDD的基本内容
不过，每个GDD必须包含一些基本信息，还有一些可选的分类。这份基本清单是文档的最高层次概述，是最概括的视图。
游戏名称与基本信息
首先，GDD必须包含游戏的名称，最好在文档中注明是否为暂定名称。你还可以添加平台和预期的发行日期，记录文档的初次完成日期也会有参考价值。
游戏介绍与目标
接下来，你需要对游戏进行介绍。这是解释游戏整体概念、主要机制和目标的好地方，建议用一到两段文字说明。同时，要清楚地说明玩家的目标以及获胜和失败的条件。一个好的原则是在第一页上添加游戏名称、介绍和目标，这样能为所有读者提供一个清晰的游戏概念。
系统、机制与部分
接下来是系统、机制和部分（Systems, Mechanics and Parts）部分，这是最显而易见也是最长、最关键的部分。你需要详细描述所有系统、支撑这些系统的机制以及用于这些机制的各个部分。我们将在视频的多个部分深入探讨这三要素。在这里，你还可以加入关于摄像机的描述，并注意到你可能会不断修改这个部分。
控制方案与多平台布局
之后，你必须详细说明控制方案。如果是多平台游戏，这是一个提出不同平台初始控制布局的好时机，这将大大减少后期的工作量，并在开发早期就提供有用信息，以便程序员和美术不需要去猜测角色的移动控制方式。
UI布局
如果你在开发一款移动游戏，特别是要包括一个UI部分。这是对UI必要信息的早期考量，而非UI的艺术设计，后续需与UI美术讨论艺术部分，最好用单独的文档迭代UI。
屏幕流程图
一个初步的屏幕流程图和每个屏幕上的信息列表将大大减少后期开发中的麻烦。每个屏幕上的按钮、功能、HUD等都应列出，并说明在屏幕间切换的方式。例如，在哪些情况下需要切换确认弹窗。这通常是一个容易忽略的部分，但它会节省大量时间和精力。
艺术与音乐参考
最后，可以加入艺术与音乐参考部分，以便向美术和音乐团队传达游戏的氛围。保持开放的心态，不要给他们过多指示。一个好的艺术家或音乐人只需少量参考和一次关于期望氛围和设计的讨论，就能把握住游戏的氛围。信任你的团队。
变更日志
最后，可以加入变更日志。维护变更日志会多一些工作量，但它是传达文档主要更改的好方法。变更日志并不是GDD最重要的部分，但在某些情况下会很有用。你也可以选择使用软件的版本历史记录功能来代替，因为现在大多数软件都有这个功能。
总结
以上是GDD内容的总体概述。我们将在多个视频中实践这份清单，因此你可以在文档中找到该清单，并在开始记录游戏时随时参考这份信息。
11. GDD是否是最终的开发方法
传统的GDD方式
你可能听说过，在过去的日子里，GDD通常会被打印出来并分发给团队成员。团队会在打印的文档上直接进行手写标注，修改规范、提出问题，而文档上的内容通常被视为最终版。
现代开发方法与GDD的灵活性
如今，随着敏捷开发、较短的开发周期以及LiveOps游戏等新型生产方式的出现，游戏开发已成为高度迭代的过程，使得这种传统方式难以适用。游戏设计师需要保持敏捷、灵活，并创建模块化文档，以便清晰地传达游戏内容，同时留出评论和修改的空间。
因此，在现代开发周期中，GDD并不总是最终的决策依据。一些公司更倾向于使用简洁的GDD，并将部分内容提取到任务追踪应用中进行讨论和细化。虽然GDD仍需更新，但不一定包含所有细节。
分散式文档的优势
一些公司更喜欢为特定的机制、系统和对象创建多个小型文档。这种方法特别适用于LiveOps游戏，因为集中式文档难以跟踪不断新增的系统、机制和对象。对于复杂的游戏，使用多个小型文档而非一个庞大的集中式文档也是有益的，每个文档可以独立评估和实施。
“GDD为最终决策”的方法
最后，有些公司采用了“GDD为最终决策”的方法。这是一种简单但有力的方式——在有疑问时遵循GDD。这种方法给设计师带来了很大的责任。如果在会议或任务追踪应用上的讨论导致游戏发生了未写入GDD的变更，可能会引发开发问题。游戏设计师必须完全了解需要修改的内容，并明确其在GDD中的位置。
团队合作与设计师的职责
要做到这一点，需要团队的共同努力以及设计师丰富的知识和灵活性，以适应游戏和团队的需求来传达复杂的系统。
14. 学习编写GDD时不要这样做
课程的常见陷阱
现在，我想告诉你一些非常重要的事情。在我学习过的课程和阅读过的关于编写游戏设计文档的文章中，和同事以及教师们的讨论中，我发现了一些常见的陷阱。
陷阱一：关注“是什么”而非“为什么”
许多课程在实践时专注于描述已有的游戏，这种方式最多只能让你“描述游戏是什么”，而不是“为什么这样设计”。这样会让你以玩家的视角思考，而不是设计师的视角。更糟糕的是，许多游戏，即使是小型的独立游戏，对于一个人来说也难以完整记录，特别是当你学习的是编写文档而非分析游戏时。而且，基于我的经验，大多数开发者在发布游戏时并没有最新的GDD，所以让一个人完成多个设计师都无法完成的工作，既不现实也没用。
陷阱二：忽略文档的更新过程
第二个常见的陷阱是，许多课程未能反映游戏开发过程中常见的一个重要部分——在游戏发生变化时更新GDD。我不知道有哪个游戏在开发过程中不需要进行迭代。如果这种情况真的存在，设计师的工作就仅仅是写下文档，然后交给程序员，自己休假直到游戏完成。但显然情况并非如此，游戏在开发过程中通常会经历多次更改，而大多数课程并未考虑到这一点。
陷阱三：只介绍一种记录GDD的方式
第三个陷阱是，大部分文章或课程只关注一种记录GDD的方式，即用文字处理器创建经典的“游戏设计圣经”。本质上，这种方式没有问题，且已经被使用多年。然而，问题在于，并非所有公司都采用这种方式来记录文档，也并非这是创建文档的最佳方式。有时候，你需要为不同的利益相关者准备不同的文档，掌握更多的工具总是有益无害的，对吧？
本课程的实践方式
考虑到上述问题，本课程将为你提供一个游戏原型，虽然比商业游戏简单，但包含了所有游戏元素。你需要将这个游戏作为课程的一部分进行记录。在课程过程中，这款游戏会像真实开发一样发生变化，你将需要跟踪这些变化并相应地更新你的文档。
此外，你将使用三种常见的工具和相关技术来记录该游戏，这样你可以从不同的角度记录游戏。
下载与体验游戏
在接下来的材料中，你会找到一个包含游戏的.zip文件夹。请下载并游玩一段时间，以更好地理解它。
我唯一的请求是不要按下“修改”按钮，这个按钮将用于在记录过程中修改游戏，提前使用会影响你的学习效果。
15. 分析笔记（视频）
记录现有游戏的初体验
这可能是你第一次记录现有游戏的笔记以创建游戏设计文档。如果是这样，或者即使你之前从事过类似工作，这段视频也可能为你未来的工作提供帮助。
记录游戏的技巧
在本视频中，我将教你一些记录游戏的技巧，帮助你更好地撰写游戏文档。首先，我希望你使用一种从高层到低层的方法进行评审。简单来说，从游戏的整体视角开始，再逐渐深入细节。
高层和低层视角
记住高层和低层的区别，可以用“高度”来帮助理解。从高空看，你可以看到整座城市，但缺少细节；从低空看，细节清晰可见，但你会失去整体视角。
因此，记录游戏时，始终先从整体视角入手。这包括游戏类型、风格、平台、主要系统或机制的概述等。然后再深入到组成游戏的各个部分和细节。
系统、机制、部件和参数
- 系统：系统之间互相作用并形成反馈。例如，在《街头霸王》中，战斗系统允许玩家通过进展解锁新角色。
- 机制：系统由多个机制组成，比如跳跃、攻击、防御和移动等，它们共同构成了战斗系统。
- 部件：比如角色，像肯和隆属于平衡型角色，而达尔锡姆和本田则属于远程型角色。
- 参数：参数是定义系统如何模拟游戏的数值。例如，隆的攻击速度、伤害和生命值等数值参数。
使用这些定义，你可以创建一个反映设计意图和实现细节的文档。
记录方法
在玩游戏时，带上笔和笔记本，记录你发现的与上述类别相关的信息。如果遇到低层级细节，也可以记录下来备用，但建议从高层级入手，逐渐关注低层级的内容。
参考其他游戏
在记录游戏之前，可以选择类似的游戏进行参考。玩这些游戏30分钟到一小时，并用几段话描述它们。这将帮助你发现模式，增进对所分析游戏的理解。
总结
记住：参考、系统、机制、部件、类别和参数。这是一个用于记录笔记的方法，而不是最终文档。它是对游戏内部结构和组件的个人提醒，以便在正式记录游戏时获得更清晰的视图，从而加快文档的编写速度并提高准确性。
接下来
现在，让我们开始我们的第一个文档吧！
17. 介绍你的第一份文档：角色创建器
欢迎撰写第一个文档
欢迎来到本课程的第一个文档撰写任务！我们将从记录一个角色创建游戏的GDD开始。
任务启动
首先，准备好之前看到的GDD清单，并在玩游戏时记录笔记。拿出笔记本，一边玩游戏一边注意其中的重要细节。你可以在本章节或下个章节找到游戏附件（视平台而定）。然后，尽可能勾选清单中的项目。
撰写你的GDD
从笔记中填写信息，如果觉得有些细节不够，保持游戏打开，继续围绕需要更详细的信息进行记录。最终你应该得到一个3到5页长的文档。虽然可以写得少一些，但我建议不要超过5页。
完成后，将你的文档分享在我们的Discord社区！我们很期待看到你的作品！
尽量做到尽可能详细，可以使用GDD清单来组织文档，分成不同部分。
总结步骤
- 准备GDD清单。
- 玩几分钟游戏并记录笔记。
- 根据清单中的每个点来撰写GDD。
- 如果觉得有遗漏的部分，再次游玩并集中记录这些部分。
- 重复此过程，直至满意。建议文档在3到5页之间。
你可以使用任何适合的方式来展示内容，比如视频、GIF、截图、或草图等。完成后，将文档分享至Discord！这只是一个热身练习，让你在课程结束时可以回顾自己的进步。祝你好运，我们下章再见！
编写专业的游戏设计文档 Write a Professional Game Design Document (GDD)
1. 成功的准备
2. 文字处理器GDD
3. 游戏界面流程
4. 数据库与维基
5. 单页文档
6. 再见
Introducing your first document Character Creator
Congratulations on completing this section!
Congratulations on completing Section 3!
Congratulations on completing Section 4!
Congratulations on completing Section 5!