《REframe/回帧》の创作日志

本文系用户投稿，不代表机核网观点
⚠️ 未经作者授权禁止转载
（本文很长预警）（废话含量较高预警）（点子扎堆预警）
1 写在前面
1.1 献给
此创作日志献给我充满bug的大儿子《REframe》，虽然你看起来不太聪明的样子但是记住妈妈永远爱你！！！
1.2 废话
虽然本人特别能春秋笔法，但是之前一直没有开始脚踏实地做一个游戏出来(虽然做过桌游以及用CS课用python做过avoider game，但属实不算很正规游戏罢！（悲））。
每次看到Unity那个看起来很复杂的页面还有密密麻麻的下拉菜单老是觉得自己跟做游戏有厚障壁。我曾经尝试过跟着网上教程学一下Unity，也生搬照抄了一个小狐狸2D横版游戏（b站上的），但是感觉啥也没学会。故本人曾以为自己的智商可能不太能用Unity。
本次机核Booom开始之前，朋友SleepingChef(@SleepyJeff)持续亢奋，且怂恿我参加。我想着，二十天时间说长不长说短不短，可以借此机会边学边做，遂决定参加。而且！机核的主题真的很符合我胃口，真的很馋之前那个时间幻觉主题的。
然后开始做之后发现，有些事情开始了才知道你缺的只是一个开始。我现在马后炮地觉得，GMTK说的，最好的学习是来一个问题解决一个问题，真的很有实践价值。

1.3 读前必看
如果你想先玩玩游戏本体，欢迎！+ 爱您！点击跳转
如果你不想玩的话，建议先看看这个完整流程视频:)
1.4 本文架构
1 写在前面
1.1 献给
1.2 废话
1.3 读前必看
1.4 本文架构
2 我的想法（设计相关）
2.1 废话
2.2 RE的发散
2.3 决定讲一个故事
2.4 模式
2.4.1 联想1：考古与还原（调查系统）
2.4.2 联想2：时空与静态的一帧
2.4.3 联想3：讲故事的谜题
2.4.5 联想5：伪“2D”
2.5 故事的逻辑
2.5.1 观音像
2.5.2 门
2.5.3 关键帧房间
2.5.4 因果线（观音像+小提琴+兔子+小窗户+日历）
3 一些改变和问题的解决（实现相关）
3.1 demo实现游戏机制
3.2 多场景vs单场景
4 开发过程中不完善的地方
4.1 开发顺序问题
4.2 兼容性问题
4.3 玩家角度
4.3.1 玩家脑洞不匹配问题
4.3.2字体与引导
4.3.3 玩法一致性
5 需要继续学习的点（个人参考用）
5.1 Hierachy问题
5.1.1系统命名方式
5.1.2 路径（建立整洁有序的文件夹）
5.1.3 Parent和 children的关系
5.2上传问题
6 写在最后
6.1 废话
6.2 使用的朋友或者软件或者网站（真入门级新手好用推荐）

2 我的想法（design相关）
2.1 废话
最痛苦的是，思考的时候会忍不住爬到床上。在床上躺着想太久的时候，会睡着。
2.2 RE的发散
首先对RE进行了组词，最开始筛选过的单子如下：
Recede后退
Replay重播
Revolve迴旋
Reborn/rebirth重生
Remold改铸
Restart重新开始
Reboot重启
Recast重铸
从中大概可以提取出三个“feel”：退，重，改，加工一下变成“在循迴往复中重塑”。我想可能大部分的参与者都是这么想的！
看来时间这个元素是RE不可剥离的一部分了。我前段时间正好在玩《星际拓荒》然后春秋笔法了一篇关于“时间轴”的文章，于是想到了对“时间轴”做做文章。
那么时间怎么体现呢？时钟的走动？与现实时间关联？感觉都没有什么可挖性。后来我想时间流动如果只是一个假象，我们感受的只是熵增，那么为什么不直接把这个让我们感受到时间流动的“因果关系”当做时间本身呢？
于是乎至此，我已经打算将跟RE相关的逻辑设定成：之前的因导致了之后的果，改变之前的因可以改变之后的果。玩法可以概括为reborn：recede+reframe+replay。回溯过去，修改因，重播，到达不同的未来，得以重生。
值得一提的是，frame正好是本文核心的另一个概念“frame”（帧），所以索性就用RE+frame做标题了。
2.3 决定讲一个故事
因果这种东西一听感觉就很叙事啊，要不讲一个故事好了（其实我做游戏就是为了讲故事来着）。然后我就开始苦苦构思一个因果嵌套的故事，以及文本工作（就是游戏里的信件啊，日程表啊，便利贴啊等等等等）。更恐怖的地方在于，一个改变的因对应一个改变的果，就使得素材得一套assets。代码不说，其实本身的写作量就很大。且因少了，玩家体验可能不会很丰富，也不能体现叙事的特征。我现在想想，这可能并不是game jam大多数作品注重的部分，可能大家还是更关注底层逻辑或者说机制。
关于故事本身，其实游戏中的“小佐”是我童年真实的好朋友。虽然游戏中讲述的故事不完全是她的人生，但是很大程度上是有着相同基调的。我一直试图为她想出一条“出路”，但是她身上的枷锁有点过多了。这些枷锁各式各样，但是有一个相同的名字叫做“过去”。
我让她的化身“小佐”在这个游戏中拥有改变因果的机会，其实也是我的私心。我很愧疚没有能够改变她的过去，没有能够为她想出一个好的未来。
我联想到伍绮诗的《无声告白》台剧《你的孩子不是你的孩子》的第三单元《茉莉的最后一天》。它们都用倒叙讲述了一个“死亡”后“还原”的故事，which也成为了我故事的核心讲述方式。不同的是，我不止讲了一个从后往前的故事，我讲了一个从后往前，往后，往前......如此循环往复的故事。
2.4 模式
那么问题来到：我想做一个什么“样”的游戏呢？或者说，我想怎么“样”讲这个故事呢？（注意以下联想不完全是在想法完全定下来之前想到的，有些是正在做的时候想到的。而且值得一提的是，它们属于爆发式的，网状出现，而挤牛奶般的，非线性出现）
2.4.1 联想1：考古与还原（调查系统）
在大多我玩过的步行模拟器（恐怖，叙事为主）中，探索·发现是不可或缺的内容。也正是这些潜藏在物体中的环境叙事，让听故事的人能够真正参与到这个故事当中，甚至能够决定故事叙述的顺序。于是我也决定让物品来讲这个故事。
至此，重中之重是看看能不能做一个调查系统， which也成为了我用Unity写的第一个代码（码）。可惜我是一个菜鸡，只能从网上的教程中“科学怪人”了一个调查系统，which也成为了所有玩我游戏的人吐槽的重点之一（泪目）。大家说，永远看不到纸的背面。下次一定下次一定。

2.4.2 联想2：时空与静态的一帧
大多密室逃脱游戏（特别是早期4399密室逃脱恐怖小游戏）和步行模拟器都是没有“人”参与的，只有物品在默默讲述这个房间的历史。于是我也想让主人公小佐在全程不出现的情况下被玩家建构出来。
这类游戏有些是动态的，即玩家是在一个动态的时间中对空间进行历史的考察。典型就是锈湖，你操作的同时时间在继续，事件在发生。有些则是静态的，比如《The Room》系列，全程唯一的时间流动大概就是开门的瞬间。
我纠结了一阵子相关的设定，直到我想到了我一直挂在嘴边的时空观。空间由（x, y, z）描述，时空则由（x, y, z, t）描述。我想象时空的方式时，你没走一步，看到的都是一帧，某个时间点的空间的状态。当你后退，你可能看到了过去的一帧；但你前进，你可能看到了未来的一帧。更有趣的是，当你斜斜地跨出去一步，你可能看到了另一种可能的未来或者过去的一帧。我也想将这种令我深深着迷的“移步换景”应用到我的游戏机制中。于是乎，我决定将每一个场景冻结到一帧，也即玩家考察的是一个冻结在“某一时刻”的房间。而且玩家还原的不是一个久远的过去，而是那一帧本身。静态的帧们则会组成完整的因果链条。玩家将用信息（不同帧间的变化和物品内容）和想象在这些静态的“关键帧”之间补充动画。
简而言之，玩家看到的是静态的帧，但是脑海中会构建出动态的动画去填补中间“缺失”的时间轴。

这样做不完全是为了概念，更多是我目前没有能力和时间去做一个“动态”的变化出来。其实我有在考虑要不要把目前游戏中分散的四帧改造成连续的一个进度条。当玩家拉动进度条的时候物品会自动改变位置之类的。觉得还是很值得一试的。
2.4.3 联想3：讲故事的谜题
我又联想到，层层恐惧给我影响很深的一个点就是，玩家发现/收集的“物品”会影响故事的结局。玩家对这些物品的“在意程度”决定了他们扮演的这个画家对这些事件的在意程度：发现这一过程本身影响了结局。另一个典型的例子是Unpacking，其中无处安放的奖状“无意中”也讲述一个故事。
是的，机制和谜题最妙的地方一定在于与故事或者其它游戏元素的自洽性。在我看来，一个找密码，找钥匙的密室逃脱并不是一个讲好故事的密室逃脱。于是乎，我也决定让还原故事本身切实成为机制之一；
2.4.4 联想4：门
游戏中一开门就换到一个“相同”空间，不同时间点的房间，是我个人很喜欢的一点。虽然我在构思时没有想到，但是马后炮地想到可能此灵感植根于短片《循环空间里的修门人》：短片中的主人公通过门达成了空间上的循环。我的游戏中不同的是：循环的是时间而不是空间。两扇门分别通往过去和未来，借此实现了一个有趣的转场效果。
门的意象在密室逃脱类型游戏中往往象征着ESCAPE。在REframe中其实也是如此。不同的是，玩家需要构建这扇门，以及定义这把钥匙（我想着或多或少受星际拓荒机制的启发：玩家并非在寻找一个门，一把钥匙，而是在构建钥匙和钥匙孔的形状）。玩家需要寻找的，消失的这扇门通往的是主人公“小佐”的未来。小佐被设定为在最开始，也是时间轴上的最后一个房间结束了她的一生。这个房间只有通往过去的门，没有通往未来的门。潜台词是：她没有一扇通往未来的门了。唯有改变她的过去，才能构建这扇门，让她的时间继续流淌。

于是当一定的机制被触发，玩家再到达最后的房间时，这个房间会多出一扇门，打开后游戏在开阔的草坪上结束。

2.4.5 联想5：伪“2D”
REframe的核心玩法只需要固定的画面，这让我纠结过是否只需要做成2D的游戏。2D听起来比3D要容易很多。但是考虑到真实感，我还是决定将游戏的场景本身做成3D。这一考量与小小梦魇机制有一定的联系。结果证明这是一个正确的选择。3D的场景反而让动画（开抽屉，开门等）的制作变得更加容易。3D的asset也让观察系统得以实现。
2.5 故事的逻辑
此部分关于REframe的故事逻辑（完全剧透）。
2.5.1 观音像
观音像被设定为一个“观世音”的观察者。它在的房间被观察且被记录，成为一个个关键帧。它不仅与游戏叙事相关（超度宠物的经文，桌子上的佛学经典），同时根据佛教，他也是一个与因果有关的形象，与游戏主旨有关。
2.5.2 门
不再是空间的转换者，而是时空的转换者。理念为四维时空中的“移步换景”。打开过去之门将回到过去的“帧”，打开未来之门则通往未来的“帧”。门的存在让玩家得以无视时间的单向性，穿梭于时间轴上，改变因果。
2.5.3 关键帧房间
本游戏所有的房间如下：

2.5.4 因果线

本游戏的所有因果线如下：
2.5.4.1 观音像（必要）
房间2.5.3.1给小佐的信件中提到，母亲想要携带观音像>>>将2.5.3.1 将观音像放入行李箱>>>房间2.5.3.2；2.5.3.3解锁，出现在时间轴中
2.5.4.2 小提琴（非必要）
房间2.5.3.1给小佐的信件中提到，不想携带小提琴，从日程表中看出，父母过度催促小孩学习小提琴>>>（若）2.5.3.1 将小提琴放入行李箱>>>小提琴出现在房间2.5.3.2；2.5.3.3中>>>房间2.5.3.2出现掉落的硬币（她在决定要不要参加乐团）>>>（若）2.5.3.2 置换下落的硬币成功)>>>房间2.5.3.3出现与三个乐团朋友合影的照片+房间2.5.3.4遗书内容改变
2.5.4.3 兔子（非必要彩蛋）
房间2.5.3.1给小佐的信件中提到，想要携带兔子>>>（若）2.5.3.1 将兔子放入行李箱)>>>兔子出现在美国的房间（2.5.3.2；2.5.3.3）中。
2.5.4.4 小窗户（非必要）
玩家解锁房间2.5.3.4后获得给小佑写的的告别信&&玩家在房间2.5.3.3中观察到用于超度宠物的经文&&玩家在对比房间2.5.3.2和2.5.3.3时发现后者没有猫窝和猫碗&&玩家与小佑取得联系后从电脑聊天中得知硼酸的用途以及小佐第一次养猫没有经验的事实，联想到潜在的危害&&房间2.5.3.2中空空的猫碗暗示猫可能会寻找别的食物>>>房间2.5.3.3中摆在地上的硼酸&&房间2.5.3.2中天花板上的活蟑螂和床底的死蟑螂>>>房间2.5.3.2中将硼酸扔进垃圾桶（扔掉）使得小窗户存活>>>房间2.5.3.3，房间2.5.3.4，房间2.5.3.5中出现长大的小窗户与小佐的合影。
2.5.4.5 日历（必要）
房间2.5.3.4中小佐给小佑写的的告别信中提到错过申请日期&&房间2.5.3.3电脑上的做游戏界面&&房间2.5.3.3中掉落在床底的大学海报（上有申请截止日期）&&房间2.5.3.3挂在墙上的海报中没有勾画该申请日期&&房间2.5.3.3中game jam海报的日期与截止日期重合（可能忙忘了提交材料）>>>在房间2.5.3.3中将海报拖入日历以记录截止日期>>>房间2.5.3.5（有未来之门的房间）解锁并替代2.5.3.4>>>玩家可选择将一些物品放入行李箱携带并从未来之门逃离时间循环。

3 一些改变和问题的解决（实现相关）
3.1 demo实现游戏机制
在构思一些基本玩法的时候，我没有纸上谈兵太久。我明白对于我这种空想家来说最重要的是实现。我开始试图建造一些DemoRoom来测试玩法的可行性。譬如我建造了一个project来实现相机中场景的观感，建造了一个project来测试开门动画（这对当时的我来说算是大跃进了笑死），建造了一个project来测试检查系统（examine system），建造了一个project来测试一个房间中“因”对另一个房间的“果”的影响。

事后想想，这样的玩法测试是很有必要的。首先他们让我明白了我的游戏有一定的可行性，在开发过程当中给了我一定的正反馈和继续做下去的动力。其次对于我这种有大量重复模式的游戏（比如一个房间有很多物品，虽然都不一样，但是大多都用一套代码）来说，大大缩短了之后批量生产、修改的工作。
3.2 多场景vs单场景
一开始我理所应当地认为，一个房间一个Scene（指Unity当中）。然后开门的时候来个转场再用SceneManager加载玩家所要到达的房间。开始搭建场景的时候还好，做转场的时候也都算顺利，到嵌入逻辑的时候就开始变得亏贼。首先我需要建立过多的public static变量记录玩家在每一个房间的改变，再传递到另一个房间去。而且reload之后一个房间的历史往往很难记录。朋友SleepyJeff给的建议是将所有的房间都放到一个场景中，并且告诉我他第一次也吃过这个亏（以此警告所有第一次用Unity的朋友）。
此时距离截止还剩一周左右的时间。我很慌，我有两个选择：（1）把所有房间都挪到一个场景中，利用摄像机的相对移动来造成房间移动的假象（没记错的话相对移动的灵感来源于GMTK Flappy bird那期），但是得从头开始修改代码（因为这个时候我已经在demo中写好了基础的代码）（2）仍然采用多场景，把剩下的时间都交给冗长，复杂，且重复的的场景间切换。
短暂纠结了一下，我决定试试只用一个场景。毕竟我给本次Booom的定位就是学习，而不是一定要做出什么成果。幸运的是，结果喜人！放到一个场景之后，进展突然变得顺畅。 
首先，代码的复杂程度直线下降，在一个场景中附着的boolean们让逻辑变得非常直观简洁。其次，在将所有房间横向排列后，我自己对于时间轴的把握也更加清晰了。同时，摄像机的平移产生了一个绝佳的转场效果！原先的转场是：开门，黑屏加载，转场画面（一个顺时针或者逆时针旋转的时钟），黑屏加载，新场景（关门动画以暗示这是刚才打开的门）。改变到一个场景之后，转场变成了：开门，相对移动（此时玩家可以看到两个连在一起的房间以及改变的方向），关门。这一转场更加直观的展示了帧在时间轴上的位置，以及向玩家暗示了时间流动的方向。以及，这一转场让场景更加立体，展现了我使用3D场景的好处（这个效果真的很低配版小小梦魇，狂喜）。

所以这件事告诉我们，年轻人，穷则变，变则通，通则久，嚯嚯嚯嚯。

4 开发过程中不完善的地方
4.1 开发顺序问题
人总是倾向于先干自己喜欢的活，我也不例外。我最喜欢的活是，搭场景和码字（可能是因为是容易吧）。于是我在没有打好设定基础就开始做文本工作，然后在blender里做成纸质材料。结果文件都做好之后我发现，由于计算的草率以及没有列时间线，时间点出现了混乱。时间点在本游戏中其实是很重要的一个部分。如果时间没有卡好，玩家在搜查房间的时候可能会出戏，更严重的是会对bug产生不必要的联想。
结果就是，在列出详细的时间线后，我得重新修改每一个文件，再重新从blender导出fbx文件，再导入Unity。这是一个很严重的返工点。
没有考虑好开发阶段的顺序问题也导致了在游戏后期阶段（加代码逻辑的阶段），我还在不断增加新的asset和故事线。每多导入一个物体，我可能就要为它附加两到三个代码，以及为这些代码附加public变量。这些重复工作不仅无法带来很多正反馈，还增加了bug激增的风险。
总之，在之后的游戏开发中还是得将各个阶段分开，循序渐进。
4.2 兼容性问题
没有考虑到兼容问题不仅影响了我的开发速度，游戏的大小，还影响了最终结果。这一兼容问题主要指的是我没有考虑到一些模型其实可以一模多用。
我的场景中有很多不同的书籍，但是我并不需要形同数量的书籍建模，我只需要导入相同数量的材质（稍稍改变形状以增加多样性）就可以了。更糟糕的是，当我意识到这一点之后，我直接将所有的png导入了引擎并且直接附到了模型上面，结果发现由于这些模型没有一个整洁的UV map, 导入的照片并不能够很好地贴合模型，有些纸质文件常常出现背部错位，边缘字体消失的问题。

在之后的开发中应当注意到应该先想好游戏中会涉及哪些asset，以及这些asset能否公用模型。以及一定要为模型建立整洁的UV map。
4.3 玩家角度
本次开发我最没有好好考虑的点就是“玩家”。其实我一直没有考虑清楚我做游戏到底是给谁做的。我听过很多次，游戏是做给玩家的，不是做给游戏开发者自己的。但是直到这次游戏发布后我才能够意识到这个问题。
4.3.1 玩家脑洞不匹配问题
最佳的游戏境界就是玩家跟开发者的脑回路同频共振的境界。最忌讳的就是开发者只考虑了自己的脑回路。你可以拥有自己的脑回路，但是你得有自信玩家会愿意花时间了解你的脑回路。其实锈湖宇宙是有独特脑回路但是很成功的一个系列。它的所有作品具有足够的自洽性，使得老玩家习得这种新频率后同样能够达到心流。但是这也导致了它对“新玩家”的不友好。我身边玩过锈湖的朋友基本上两级分化为（1）玩过所有作品并且爱得深沉（2）玩过一部或者一部都没玩完就放弃了。是的，做一款“不直觉”的游戏真的很冒险。
不幸的是，《REframe》充斥着我非常个人化，以及波频很奇怪的的脑回路。譬如通过将落下的硬币偷换成两面都是一样的硬币使得结果失去随机性。对于这个谜题，我在“遗书”中写道：（值得一提的是，我将所有的提示都放在了最后一个房间的“遗书”里。如果玩家成功改变了一条逻辑链，这个遗书的内容就会改变）
“我也曾经让硬币替我做决定，它成功打消了我好不容易产生的，想要参与这个世界的念头。你知道吗，如果那次硬币是正面，我真的会去面试乐团，我真的会努力。但是没有，硬币就是反面。我偷偷扔了第二次，硬币仍然是反面。就像我的未来，抛出去的时候是有两面的硬币，落下来的时候就一定是反面。
结果证明大家的脑洞决定了他们根本就不会很注意这个“不断变化”的遗书。于是乎这一我十分自信的“天才设计”，现在总感觉像是个冷笑话。在playtest阶段结束之后，我不得不增加了“提示”以免所有玩家都一头雾水的退出游戏。

玩家get不到的点，不论多“金子”，都永远不会发光。重点不是玩家被迷惑住了，而是玩家有能力解决被迷惑住的东西。
4.3.2字体与引导
《REframe》中，我试图通过简单的第一个房间和图像上方的文字提示来教会玩家基本操作。但是出于种种原因，相当一部分的玩家向我抱怨了没有新手教程这个点。结果证明是字体太小，他们都没有看见小小的，黑色的引导。在playtest阶段，朋友SleepyJeff也建议我将“loading”的文本改大几倍以让玩家注意到他们的行为产生了影响。
4.3.3 玩法一致性
拖动是本游戏中唯一改变因的方法，但是这一方法上的一致性并不等同于玩法的一致性。在本游戏中，玩家在第二个房间中会将观音像放入行李箱。这一行为生效后，他们可能会认为拖动意味着“放置”。但是在之后的房间中，他们需要拖动蟑螂药到垃圾桶里去“扔”，拖动海报到日历去“记录”截止日期， 拖动抽屉里的硬币与下落的硬币重合去“置换”。这一玩法的一致性放大了设计师与玩家之间的厚障壁。

5 需要继续学习的点（个人参考用）
5.1 Hierachy问题
5.1.1系统命名方式
5.1.2 路径（建立整洁有序的文件夹）
5.1.3 Parent和 children的关系
5.2上传问题

6 写在最后
6.1 废话
哪怕我放弃了一切把游戏作为“专业”，我也一直没有很能确定自己到底是不是真的能做游戏。这次的体验对我至关重要，不论结果如何，在过程中它切切实实地给我了很多正反馈，让我看到一些可能。真的很感谢Booom能够给我这次机会，去真的鼓起勇气打开这扇门。祝机核越办越好，也希望我能够成为这个年轻社区真正的一份子:)
6.2 使用的朋友或者软件或者网站（好用推荐）
@SleepyJeff 
Unity  (引擎）
Blender（建模）
GarageBand (编小曲儿）
Adobe Photoshop (根基）
Adobe Premiere (整点没用的宣传）
Adobe Express (做各种平面）
Unity自带的商店
不是Unity自带的商店

谢谢你读到这里！
2023.6.4
PearChicken