top of page

甲骨文
通过游戏学习象形文字。
Project Summary.
游戏设计重点项目
《甲骨文》是一款3D益智游戏,旨在通过谜题让玩家了解中国古代甲骨文背后的概念和思想。这款游戏的核心机制是点击点来绘制古代甲骨文象形文字,并理解代表谜题甲骨文文字含义的场景或事件。
这款游戏从最简单的形式到复杂的形式向玩家介绍中国古代甲骨文。首先向玩家教授最简单的甲骨文,这些甲骨文可以被识别为单个甲骨文,同时又是另一个甲骨文的组成部分。然后,在完成几个与这些简单甲骨文相关的谜题后,由几个最简单的甲骨文组成的谜题将作为挑战呈现给玩家。通过这种方式,我们试图教授中国古代甲骨文形成背后的逻辑,这也与今天汉字的结构相似。
开发引擎: Unity 3D
运行方式:打包的可执行文件
工作时间: 2021年9月 - 2021年11月
团队规模: 3人
游戏时间: 15 - 30 分钟
亮点:
-
场景解密挑战
-
通过游戏学习古代语言
-
脚本实现的对话系统
Responsibility 1.
#1 拼图设计。
定义

汉字笔画表
汉字笔画参考。我们的字谜设计并没有将字谜分解成笔画。这里只是帮助读者对汉字有一些基本的了解。

汉字部首表(部分)
这是一张部分汉字部首的表格。部首是我们谜题的重点部分,因为在中国甲骨文中,部首也都是没有发生形体变化的单字。

汉字结构表格
这是一张介绍汉字七种基本结构的表格。早在中国古代的甲骨文中就已经使用了这些结构。在我们的游戏中,我们的谜题都集中在左右结构和上下结构上。

汉字笔画表
汉字笔画参考。我们的字谜设计并没有将字谜分解成笔画。这里只是帮助读者对汉字有一些基本的了解。
1/4
在进入谜题设计之前,我先介绍一下甲骨文形成的一些概念和定义(汉字也类似)。
笔画:甲骨文文字的基本组成单位,不同的笔画相互组合形成部件,甚至形成文字。
部首: 部首是具有相似部分和结构的汉字的组成部分或变体,用于多种不同的汉字中。有些部首被简化为笔画组合,无法单独阅读。
声部: 声部是赋予字符基本含义和发音的组件。不同的部首分配给同一个声部,它们就会成为意义不同但发音相似的字。
汉字结构:除了仅由笔画组成的字符外,所有汉字都遵循几种结构来组织其组件。它们包含左右、上下、全包围和上中下三种结构。在这个游戏中,我们只使用了没有结构的汉字和具有左右和上下结构的汉字。

单字甲骨文的基础谜题的设计逻辑示例
游戏中的基础谜题囊括的是只包含笔画的单字。之后,它们将成为具有左右或上下结构的复杂字的组成部分

进阶谜题设计的逻辑示例:基于汉字结构的谜语
两个单字 “勿”和 “牛”有各自的含义和谜题,在游戏的后期被用来作为进阶谜题以教学甲骨文 “物”,它的组成部分是 “牛 ”和 “勿”。

单字甲骨文的基础谜题的设计逻辑示例
游戏中的基础谜题囊括的是只包含笔画的单字。之后,它们将成为具有左右或上下结构的复杂字的组成部分
1/2
当我要为一个字设计谜题时,我会先从它的意义来源开始。在查阅了一些参考资料后,我了解到“中”这个字很可能来自于中国古代房屋中央底部到顶部出口的景象,那里有一个指向天空的梯子。
遵循类似的设计逻辑,我设计了由左右和上下结构组成的高级谜题。对于引入复杂甲骨文的高级谜题,我将它们设计为在玩家完成其组件的谜题后连同其叙事事件一起解锁。
Responsibility 2.
#2 关卡设计。
版图设计

现实世界中的地理位置
在制作前期,我们研究了夏、商两代都城的地理位置,最终决定以殷城作为关卡布局参考。

殷城周边环境计算机复原模型
后来,我们又潜心寻找记录殷墟的资料。最后,我们决定按照电脑模拟复原来制作我们的关卡布局。

最终关卡的布局
这就是游戏最终呈现版本中关卡的样子。在编辑器中,包括树木和草地在内的装饰物都被隐藏起来,以减少性能问题。

现实世界中的地理位置
在制作前期,我们研究了夏、商两代都城的地理位置,最终决定以殷城作为关卡布局参考。
1/4
因为这个项目更侧重于向观众介绍甲骨文文化和古代历史,所以我们没有太多自由的布局设计。我们试图保持关卡与殷城的实际布局尽可能相似。根据我们从一些考古文献中找到的参考资料,我们设法将殷都的规模缩小到适合我们项目规模的大小。
关卡设计。

关卡流程图
我在关卡中均匀地安排了谜题点,其中两个谜题点位于玩家进入殷城之初的同一条路径上。

进入村庄处的聚焦
这是一个简单的聚焦,它在当玩家沿着路线来到殷墟入口处时可以告诉玩家下一个目标。。

任务标识
简单的任务标记表示该 NPC 有任务(或对话)。游戏中的所有 NPC 都使用了这种标记。

关卡流程图
我在关卡中均匀地安排了谜题点,其中两个谜题点位于玩家进入殷城之初的同一条路径上。
1/3
当我从事这个项目时,我负责该项目的关卡设计。从手绘地图开始,我创建并组织了游戏中的所有谜题以及相关的对话事件。我试图优化玩家的视线并尽可能地利用关卡空间。这就是为什么我准备了两个单字作为游戏的结尾,地点是玩家一开始走过的大道附近的河岸。
Responsibility 3.
#3 编程。
模型、视图、控制器框架

为了减少不同系统之间的一致性,我决定在我们的游戏中实现通用的编程框架 MVC。MVC 代表模型 (Model)、视图 (View) 和控制器 (Controler),其中模型 (Model) 处理设计师和程序员指定的数据,视图 (View) 处理 HUD 和对话等数据的呈现,控制器 (Controller) 处理 I/O、数据操作(如计算、封装、更新和监听回调)。
对话系统
由于游戏包含大量对话,我编写了一个基于 FSM(有限状态机)的对话系统,以便我们的故事作者可以更 方便地更改对话文本。在每个事件中,我编写了一个简单的序列器,通过Unity协程来处理NPC的动作、说话和动画。
Postmortem.
反思。
什么是
做得好的?
-
我成功地将中国古甲骨文与点击谜题结合起来
-
我设计并组织了难度不断增加的谜题
-
我们根据殷商古城的考古研究建立了一个关卡
-
虽然我们没有动画美术,但我设法在Unity中编写了自定义动画脚本和框架
什么
是做得不好的?
-
作为项目的领导者,我忘记每周关注每个团队成员的进度。这导致团队对剩余工作的估计不正确
-
我们没有注意到我们项目规模太大了,尤其是在美术资产方面。
-
我们倾向于单独工作而不是作为一个团队工作,当我们遇到进展阻碍时,会消耗额外的时间沟通协调。
-
我们没有大量文档来跟踪我们的开发周期,导致任务分配混乱
我学到了
什么?
-
在 2 人以上的团队中工作时,例行会议确实可行
-
在将一种文化概念转化为另一种文化环境时,我们对自己文化的认知在新的文化环境中肯定不起作用。开发人员需要跳出自己的文化环境,从外人的角度进行设计
-
与队友讨论你的进度和障碍因素对于维持开发进度和节奏非常重要
Gallery.
画廊。

Picture3

Picture5

Picture4

Picture3
1/5
bottom of page
