元数据

课程： 教育游戏设计 (CMU 05-418)。

导师： Erik Harpstead 教授

队友： Christina(Qianou) Ma

YouTube 演示： 此处

项目摘要

在大四时，我选修了 Erik Harpstead 教授的教育游戏设计课程 (CMU 05-418/818)。

在这个项目中，我们被分成 2-3 人的小组。我们需要设计一款教育游戏——限制并不多：只要不实现 3D 游戏，一切都好说（当然如果你有能力做一个，也可以去和 Erik 谈谈）。因此，该项目要求团队成员通过有效的游戏设计工业流程进行良好协作：头脑风暴、研究、实现、原型制作、剧本编写和迭代。我们只有不到一个月的时间来完成游戏的 MVP——因此，建议我们不要制作数字游戏，因为编程可能非常耗时。

然而，由于我的团队对自己非常有信心，我们还是决定不把数字游戏从头脑风暴的选择中排除。嗯，这为我们最终制作出一款被誉为“该课程历史上最令人印象深刻的数字游戏”奠定了基础。

准备阶段

在准备阶段，我们确定了团队中的角色。由于我有较多的游戏设计经验，我负责了大部分的玩法设计、编程和游戏美术，而我的队友 Christina 负责进行游戏研究、问卷调查分发和故事剧本编写。在这里我将更多地描写我的部分，如果你对 Christina 的工作感兴趣，可以参考她的页面此处。

我们的第一项工作是决定做什么。我们使用 Miro 板对游戏主题进行了头脑风暴。

我们很快决定制作一款家长教育游戏。这对于这门课程来说可能是一个相对新颖的话题，因为许多人会选择金融、环境或编程等主题。

在确定主题后，我们开始了早期的头脑风暴。以下图表是该项目的早期方案。

结合同行评审的反馈，我们最终选择了第二个方案——聊天模拟器作为我们的最终项目主题。

故事剧本

既然我们决定游戏形式是聊天模拟器，我们就无法逃避编写一个体面故事的责任。这个故事应该支持分支，因为作为玩家的家长将从故事的不同结局中学习。另一方面，我们只有大约一个月的时间，所以我们不能把故事写得极长。

最初我们希望故事贯穿某个角色的整个一生，但我们很快发现这太雄心勃勃了。因此，我们决定只制作角色生命周期中的一部分。在这个选定的部分中，玩家应该体验到一段相对复杂的亲子互动。此外，我们需要考虑我们关注的家长群体，例如美国家长可能与中国家长完全不同。

我们最终的情景决定如下：

孩子正在准备一场重要的考试。在这个精神压力巨大的时期，孩子与家长之间的互动可能会变得困难且复杂。

我们从这里开始原型制作。编写故事的过程太冗长，这里就不多说了，如果你想了解故事是如何迭代的，请参考游戏文档。

如果你有兴趣阅读中文版的故事迭代，请看这里。 Playtesting Story - CHINESE version.pdfOpen ↗

用户界面

我们遵循了通用的 UI 设计流程。游戏过程相对简单，所以不需要绘制太多的 UI 元素。

以下列表显示了所有需要的场景。

• 开始页面
• 加载页面
• 家长的办公室
• 家（客厅）
• 家（卧室）
• 家（孩子房间）

连接逻辑由游戏进程决定。我们聊天模拟器中的一个游戏日始于玩家（作为家长）去办公室。在办公室里，玩家可以通过某些软件回复电脑屏幕上的消息，或者发起与某些 NPC 的对话。一旦他们完成了当天的对话，就可以回家；如果是周五，孩子也会回家（否则孩子在寄宿学校）。玩家可以从客厅去卧室，并在那里结束一天。第二天将通过从家到办公室的加载页面开始。

因此，以下页面是页面布局的第一个低保真版本。我们对它们进行了测试，通过玩测证明它们是直观的。

随后我们开始润色界面，添加一些视觉艺术元素。起初，我们决定以《女神异闻录 5》(Persona 5) 作为风格参考，因为它相对轻松，且在一个月内较易实现。这是我们的第二个 UI 版本。

由于时间非常有限，在这个迭代中一些背景插图没有完成；我使用了来自 Google 的照片代替。然而，尽管这个迭代从玩测者那里得到了一些好评，但他们中的许多人也反映 UI 风格看起来与游戏风格有些不符。这款游戏看起来不像需要流行风格 UI 的游戏；故事发生在学校，许多玩测者（大约 40-50 岁）并不喜欢这种风格。因此，我们制作了 UI 风格的第三个迭代，这次真的花了我很多时间来画。

游戏设计

这是游戏闭环和游戏系统图。

我认为它们很好地解释了游戏系统是如何运作的。如果你想阅读我们如何将补充系统加入系统的完整过程，请参考游戏文档，因为对于这个网站来说可能太长了。

编程

最后是编程阶段。编程部分涉及更高层面的微妙之处。我们遇到的第一个挑战，也是最重大的挑战，是如何存储故事的分支。最初我们考虑使用树结构作为数据结构，为了方便起见，因为我们不想手动将故事一行行输入到 Unity3D 中。起初我们想过写在一个 txt 文件中，并编写一个 parse() 函数来自动将 txt 文件转换为树节点。它看起来像这样：

使用 & 作为分隔符，每个节点存储消息组和响应组以及子节点索引。然而，这很快就失败了，因为故事分支实际上不是一棵树！

许多节点会汇聚，这意味着多个父节点可能共享同一个子节点。此外，这个简单的解析器使得合并游戏数值变得极其困难：如果我们想为每个选择设置阈值，以及选择该选项获得的奖励，节点将变得非常难以阅读。最后，我们通过在 Unity 中构建指定为 TextGroup 的数据结构来实现故事节点。一个 TextGroup 如下所示：

每个 TextGroup 都知道由 IncomingMessages[] 文本指定的传入消息，每个 IncomingMessages 都知道其 WaitTime（收到玩家回复到开始输入之间的时间间隔）和 TypingTime（输入传入消息所花费的时间）。这些变量允许对即时消息进行高保真模拟。此外，每个 TextGroup 都知道由 Answer[] 答案指定的玩家选择，每个答案都包含一系列信息：其 min_mh、min_int（最小心理健康亲密度）以及 MH_buff、Int_buff（做出选择后获得的奖励）。它还包含 tip 和 warn，用于在做出选择后给玩家提示和建议。最重要的是，NextGroup 和 NextAvailable 允许节点识别其唯一的子节点。底层的线性度是树状故事存储的基础；这些文本组运行得非常稳健。

第二个挑战看起来类似，但在本质上有所不同。面对面聊天模拟器：基本逻辑是类似的，但这次单个对话可能涉及 2 个以上的谈话者。因此，我们需要额外注意角色是如何切换的。此外，请注意角色不会“输入”，也不会“等待”，因此，即时消息模拟器的基本逻辑在这里实际上并不适用。似乎一个完全不同的数据结构会更有帮助。由于时间限制，这部分并非完全由我们自己实现——我们使用价值 $4.99 的 Unity 资源 DDSystem24 构建了面对面聊天模拟器。特别地，我们进行了适配以自动创建和分配角色。例如，在原始资源中，我们必须在 inspector 中创建角色，但这会产生一个问题，例如，如果玩家定义孩子是儿子而不是女儿，那么我们就不能使用女儿角色作为孩子出现。与其他重大挑战相比，这里的挑战更容易解决。

其他一些挑战出现在场景管理方面。我们在项目开始时确定游戏场景流程应如下：

1. 周一至周四：办公室 -> 加载（办公室到家） -> 卧室 -> 加载（睡觉） -> 加载（家到办公室） -> 办公室；
2. 周五：办公室 -> 加载（办公室到家） -> 面对面聊天 -> 卧室 -> 加载（睡觉） -> 面对面聊天
3. 周六：面对面聊天 -> 卧室 -> 加载（睡觉） -> 面对面聊天
4. 周日：面对面聊天 -> 卧室 -> 加载（睡觉） -> 加载（家到办公室） -> 办公室

因此，跟踪日历可能很重要，并且需要将日期转换为星期几。然而，通过确保数学关系，这个挑战也很快得到了解决。

剩下的挑战都是一些细微的调试和实现，例如玩家自定义变量替换、渲染管线优化、字体着色器以及按钮/切换/输入框渲染。这款游戏中几乎肯定、确定、必定还存在隐性 bug，但考虑到有限的时间，这些挑战已经得到了顺利处理，达到了我们的预期。