下载 App

GAME DEV LOG 02|调查与涌现 —— 节点之间

5 小时前11 浏览综合
K-3089 —— 从文本调查原型到全节点系统
当你看见一台设备、一份档案和一个人的说法之后,怎样决定自己下一步要做什么?又过了三天,这次我记录了一些我们从流程整理、人物草图到节点交互与解谜原型的一轮探索,可能因为只有两个人的原因,推进和测试都处在一个比较平淡的节奏,在这次探索之后,我们明确了游戏的定义:
以节点连接为核心交互的科幻叙事解谜游戏:你将扮演空间站维修员,在修复设备的过程中了解全貌。
文中包含开发中的流程与机制画面,部分配图不会涉及最终游戏剧情和谜题解法。

1. 流程深入

最初的纸上草图很简单。Szu画了一个写着 E402 的框,连向房间里的电脑和盆栽;进入场景以后,再往局部走近一点。此时画的是视线和动作:我到了哪里,看见什么,又能调查什么,这种节点编辑器一般的解谜感突然让我们都觉得很新鲜,好像打开了软件一般,我们在想这也许是非常适合的一个方式 —— 对于一个维修员来说。
TapTap
1|从场景进入局部调查的早期纸上草图。
把故事继续拆开,线很快多了起来。一次交谈会带出一个部门,搜索部门又会找到不同的人;有人正在工作,有人不在这个班次,也有人还在休眠。于是流程图需要同时回答两件事:
A. 什么推动玩家前往下一节点?
B. 现在是否已经具备继续行动的条件?
TapTap
2|人物对话、人员检索与后续调查的分支整理。
角色功能和资料关联也需要单独看。一个人会出现在多少记录里,能解释哪些设备问题,又有哪些事情超出他的所知范围?把这些联系铺开,是为了检查同一份信息从哪里进入调查、会在什么时候被重新想起。关系图里的线越密,越需要回到具体的一次询问。
TapTap
3|角色功能整理与资料关联图,属于开发中的结构梳理,使用Obsidian进行整个流程模拟。
节点原型开始把这层关系带进操作界面:
把搜索结果、设备记录和人物口供放到同一张画布上,探索它们怎样帮助玩家形成新的问题和线索链。
这里最值得继续研究的,是从“我已经看过它”走到“我知道它和另一件事有关”的那一步,因此我们先构建了一个网页版的测试原型,尽量让一切都节点化,先不管节点膨胀的问题,体验下来这个版本真的让我们感觉到一种推理的味道正在出现,这种感觉很像在做料理,面对一堆杂七杂八的食材,突然想着干脆全部放进锅里,小火慢炖吧,结果却出人意料,令人开始期待后面的发展。
TapTap
4|把检索结果、设备记录与人物口供放进同一张调查图的初始原型画面。
回到全局,仍然要检查每段维修的前置条件、人物回访和资料开放的时机。玩家能先认识谁,与能先修好什么,是两套相互影响的顺序。图上的一条线需要最终落到可操作的动作、可读的信息和相应反馈上;画出全流程,只是让这些依赖可以被逐项检查。
*下一张图包含部分剧情设计,最终剧情以发布游戏内容为准。
TapTap
5|按调查阶段整理的全局流程与节点依赖。

2. 玩法探索

玩法的画面探索先把窗口、信号图形与人物放进同一张网里。下面的概念图为TD中的一个效果截图,这给了我们很大的启发,为保留了这种直觉:信息可以分散在不同对象里,也可以沿着连线被重新接近。它提出了一种组织画面的方式,具体操作还需要继续拆解。
TapTap
1|波形窗口、信息节点与人物肖像相连的界面概念图参考。
再把规模缩到开场,只留下休眠舱与人物之间最简单的一条关系。当前的方向,是让整个游戏在节点画布中展开:从休眠舱醒来,出现 Andruski 的头像,再接触 David、前往办公室,在Godot里简单实验了节点按键的动效和反馈,除了可以简单玩一下测试之外,还在考虑搭建架构上的后续落地实操难度。
TapTap
2|休眠舱设备与人物节点之间的最小关系示意。
接下来要分清,同样面对一个对象,查看属性、追踪记录、筛选信息和尝试连接,分别在做什么。具体示例把这些操作拆开:追踪两个人可能找到共同出现的文件,直接连接他们却可能没有结果;给一组文件加入条件,则可以缩小继续阅读的范围。
剧透提示:下一张示例包含部分人物、资料与地点之间的调查路径。
TapTap
3|推演属性、追踪、筛选与连接的组合,包括没有结果的情况。
在这之后我们的做法是,把具体名字拿掉,就能检查这套规则能否用于更多对象。人物、地点、设备与文件各自可以进入哪些操作,又会得到哪类结果?这张类型图让我们开始按共同规则整理任务与资料,也避免每增加一个角色就重新发明一套入口。
TapTap
4|人物、地点、设备与文件的操作类型及可能输出。
画布也需要容得下调查中的往返。暂时无关的节点应当可以移开,重要材料需要找得回来,人物与设备的状态要随行动更新。这些图让方向更清楚,完整体验仍要放进连续流程里验证。

3. 美术探索

为了让脑子喘口气,图也得画,我在思考让人物开始以头像的形式进入这些关系。对一个需要反复回访人物的游戏来说,初期还是以能看到像素感的铅笔笔刷绘制一些草图,先以黑白质感探索,方便后续1bit风格的简化。
TapTap
1|角色头像的黑白线稿探索。
把初版角色放在一起以后,还可以比较不同的处理方式:白底线稿保留细节,黑底强调轮廓,蓝紫色线条则开始靠近终端画面的感觉。同一张脸换了背景,表情与线条的分量也会变化,Szu给每一位角色写了小传,这帮助我快速的理解了每个人物的性格,短时间内制作多个角色是个很有意思的体验,所以后续希望可以尽力画出每个角色个性十足的一面,这版还差得很远。
TapTap
2|七名角色的白底线稿、黑底反差与蓝紫色线条比较。
探索到目前为止不具备什么有趣的视觉效果,由于我仍然想继续尝试 1-bit 的表现,就先挑了两个喜欢的角色,绘制了1bit的高反差肖像,并把人物放进点阵与窗口边框里,让“终端里的人”有了更具体的视觉方向。绘制像素画的时候最大的感受,是对于Dithering和渐变的绘制稍微掌握了一点眉目,不过目前的细节过于复杂,哪些特征还能留下,仍需要取舍和后续的探索,包括整体颜色和UI的视觉效果,如果可以让整体1bit的感觉和整体画面适配就好了,精美好看的像素画真的需要时间慢慢打磨,没有画过什么像素画的我在这里由衷的致敬每一位像素画师。
TapTap
3|人物肖像、点阵质感与复古终端窗口的风格探索。
关于这张图,其实是一个最开始的设想,分镜把休眠唤醒、连接私人终端、解锁和激活排成连续画面。屏幕从暗到亮,系统逐步给出信息,玩家也逐步获得行动的条件。人物、设备和界面最终需要在同一段操作里被理解。虽然后续不会按照这个感觉来,但还是记录一下,没有这个随意的草图也不会有后面的诸多想法。
TapTap
4|从休眠唤醒到连接、解锁与激活的终端分镜草图。

4. 解谜

让解谜也真的存在,和维修融为一体,这个是Szu的想法,我觉得非常值得尝试,虽然势必会加大工作量,但先尝试一下也蛮好的,我们想把抽象规则变成能观察的过程。线路追踪原型把路径选择、字节读取和校验放在同一个界面:沿线前进得到数据,再用规则检查它。规则虽然带着工程术语,玩家仍需要知道自己正在检查什么,以及一次失败能提供什么信息。
下一张图展示了一组已通过校验的线路与数据,这个完全不会出现在游戏里,只是一个谜题测试。
TapTap
1|线路追踪、原始字节读取与校验规则的机制原型。
另一类谜题接近调查本身。我们在尝试让玩家区分已确认事实、可以支持的推论,以及目前仍然未知的部分。逻辑链验证原型把这件事做成了可逐项判断的材料,也让它与游戏角色在故事中的工作发生联系,不过这个后续不一定会用上,但思考的过程中我们觉得很有趣,也自己测试玩了一下,也许喜欢做心理测试的玩家们会喜欢吧。
TapTap
2|用于区分事实、推论与未知的逻辑链验证原型首页。
一份记录可能是真的,一个人的记忆也可能是真实的,但把它们连起来以后,结论仍可能多走了一步。我们希望玩家能够指出那一步:哪条材料提供了支持,哪条材料造成了矛盾,还有什么尚未被解释。这里的难度需要留在判断上,避免把模糊的题意和隐蔽的操作入口也算进去。
这些画面展示的是机制探索。程序检查能够帮助发现状态与规则的问题;玩家是否理解了维修所得,又是否因此产生新的追问,还需要真实试玩来回答,仅为测试画面。

5. UI/UX探索

花费了很长时间去构思,不得不说,历史上优秀的解谜游戏交互太多了,例如Type Help这种可以开创一种解谜类型的作品,把玩法和剧情及世界观都完美的融入在一起。我们当然不追求一次就找到答案,但是等真的做起来才发现这有多难。早期探索优先比较了三种重心,维修工作台围绕设备局部与测试反馈展开;双页证据对照让两份材料并排,并尝试让玩家写出主张;值班终端则把工单、地点和资料放在持续可见的入口里。同一段调查,在不同布局中会先把玩家的注意力带向不同地方。
TapTap
1|早期界面的三条探索方向:维修工作台、双页证据对照和值班终端。
纸上草图继续把搜索列表、人物面板和关系网放到不同位置。一个名字可以出现在搜索框里,也可以成为画布上的对象;接近同一个人时,玩家可能在找他的资料,也可能想沿着相关记录继续追查。界面需要帮助保留这两种来回切换的方向。
TapTap
2|搜索列表、人物面板、节点视图与关系连线的纸上布局探索。
把关系铺到画布上,标签和连线便成为新的阅读入口。下面的草图用圆点与长条卡片试探信息如何聚集、展开。它也留下一个问题:玩家怎样看出哪里可以操作?Norman 对 signifiers 的讨论提醒我们,可感知的提示会影响人怎样理解眼前的行动。[1] 节点形状、文字标签与选中反馈,都需要承担这份说明。
TapTap
3|用标签、圆点与连线组织信息的关系草图。
文件系统的草图又把同一问题放回检索:左边是搜索后的条目,右边是从人物展开的关联资料。信息觅食研究中的“信息气味”,描述了人如何根据眼前线索判断一个信息来源是否值得继续探索。[2] 标题、日期与摘要需要给出追查的理由;把资料连起来以后,玩家也应当知道自己为什么要打开其中一份。
TapTap
4|文件列表检索与关联资料展开的两种呈现方式。
这些方案保留了从分区布局走向节点画布的思考过程,直到这一步,我们已经明确为用节点组织整个游戏,具体的展开方式、缩放后的文字和长档案的阅读,我们打算创建一套规则(语言)来实现。

6. 节点语言

我们目前开发的过程中,先决定把人物、地点和设备概括成 ITEM,把记录概括成 DOC。具体的调查动作就可以放进同一张语法图:对象或文档在功能节点的作用下,可以得到新的对象、文档、对话、终端界面,或者什么也找不到,我们想实现的一条链路是:
TapTap
1|对象、文档、操作与推进的规则示意。
这张图里,属性和追踪可以发现文档;筛选可以留下文档或对象;连接返回对象或 NULL。对话属于互动的可能结果,互动也可以进入程序解谜,再展开验证、扫描、修复、拆解或转换。它把不同动作的职责分开,也让一次没有结果的尝试有了需要解释的位置。
再把这套语法放回一段实际要制作的流程,就得到下面的 2.0 Nodal 草图。它从休眠舱与人物接触出发,接入终端、任务、物品和档案,再安排维修后的回访。这里开始检查的,是一次操作得到的结果,能否成为下一次行动的起点。
提示:下一张图包含的部分任务路线、对话与剧情线索,不代表最终游戏内容。
TapTap
2|用节点语法推演人物、任务、档案与终端操作的流程草图。
图里仍留着“任务1”“物品一”和“EXXX”等占位标记。这让我们可以先检查分支与回流,再逐项接入内容;它记录的是流程设计,尚不能代替完整版本的运行与试玩。
操作能够返回结果,还不等于一项判断已经成立。读过记录、提出猜想、确认矛盾,需要各自可辨认的状态。NULL 也需要合适的反馈,让玩家理解这次尝试没有得到结果,同时不提前替他排除所有可能的关系。画布应当容得下尚未被证实的猜想。
Jenkins 在嵌入式叙事的讨论中,描述了把故事信息散布于可探索环境、再由玩家重构过去的方式。[3] 人物、设备与档案节点可以成为这些碎片的载体。对《K-3089》来说,预先写好的事件仍在那里,我们更想观察的是:玩家通过哪些动作,逐渐获得自己的理解。
这一轮探索留下了几个更具体的问题:第一次连接是否容易理解;再次打开旧档案时,能否找到新的意义;面对一条看似完整的解释,是否还愿意追问它缺少什么。下一步需要让这些问题进入完整流程和实际试玩。
我们承认这一切暂时看上去还不太有趣,不过我们目前认为让维修员利用节点数据来维修和推理,是一件值得尝试的事情。
从维修到调查,故事还在继续获得形状。我们希望每一条新连接,都能让某件已经见过的东西变得更清楚一点,希望后面几天可以取得一些新的进展。

References

[1] Donald A. Norman. Signifiers, not affordances. Interactions, 15(6), 18–19, 2008. 作者原文 · DOI
[2] Peter Pirolli & Stuart Card. Information Foraging. Psychological Review, 106(4), 643–675, 1999. DOI · 作者上传的全文
[3] Henry Jenkins. Game Design as Narrative Architecture. In First Person: New Media as Story, Performance, and Game, MIT Press, 118–130, 2004. MIT 作者存档全文
【怪怪牧场开发日志 1/5】不只躲怪,我想让怪物成为我的帮手截图
【怪怪牧场开发日志 1/5】不只躲怪,我想让怪物成为我的帮手
这次活动的主题是“涌现”,我最初想到的是幸存者类肉鸽:走位、收经验、升级,再面对越来越热闹的敌群。 但我不想只做“武器越来越多、伤害越来越高”。如果敌人的本领,也能成为玩家的工具呢? 于是有了《怪怪牧场》。 玩家扮演一位牧场管理员,面对一群不太听话的小怪。它们会追你,也会影响彼此:牛的冲锋能撞伤其他怪,黏液能减速双方,膨胀的小怪还能引发连锁爆炸。 我希望玩家从“怎么躲过它们”,慢慢变成“怎么安排它
2 赞
开发日志2 — 从抽象到具体,把六边形棋盘铺成一片土地截图
开发日志2 — 从抽象到具体,把六边形棋盘铺成一片土地
#聚光灯gamejam开发者日志 上一篇,我们三个为“涌现”这个词争论了许久,最后决定放下包袱,老老实实做自己想做的游戏:一个结合了模拟演化+塔防+资源管理的“缝合怪”。 既然方向定了,接下来的工作就得从务虚转向务实。游戏的地图底层采用六边形网格,为了先摸清地表怎么画、怎么拼,我们单独建了个素材工程。原本以为画好几种地皮接起来就行,结果光是“把边缘拼顺”这件事,就来回折腾了好几轮。上一篇被抽象
3 赞
2 回复
《一方烟火》开发日志 01|想让一座小院,慢慢有了生活截图
《一方烟火》开发日志 01|想让一座小院,慢慢有了生活
大家好,我是《一方烟火》的开发者,惊澜互娱个人工作室,目前……整个工作室的产能,就我一个活人(悲 先叠个甲:本人是在读生物博士,日常搞算法开发,所以程序这块勉强能打;游戏玩得不少,对开发和设计也算有点自己的理解,所以策划这活儿能接;以前还玩过音乐、做过编曲,所以BGM这块也能自己上。至于美术——真不会,但没关系,现在有AI,科技改变生活(喜 说回游戏。 这款游戏算是我的第一款小体量经营游戏,也正式
2 赞
【2026聚光灯日志03】第5天进展,游戏化困难,进展缓慢……截图
【2026聚光灯日志03】第5天进展,游戏化困难,进展缓慢……
1.根据粒子分类规划了四种环: 橙色环:成品单质或者化合物。 绿环:核物理中间态粒子。 蓝环:化学反应中间态粒子。 紫环:怪异聚合物。和橙环对应,是现实中不存在的粒子。 2.关卡设计失败 原本的设计是每关给定随机粒子包,最终合成目标粒子后过关的。 实际测试后发现基本就是在让玩家等待,而且因为质子和中子数量固定,基本粒子的进化过程会被卡死。 初始确定,目标确定,也没有涌现的概念。似乎路径给定死了。 现
1 赞
四重悼歌开发日志_2截图
四重悼歌开发日志_2
各位好呀,这里是黑猫,那么过去了五天黑猫都做了那些内容呢?主要是游戏的一些素材绘制和关卡的搭建,游戏的UI方面黑猫非常喜欢一款游戏“女神异闻录5”的UI设计,然后国内有个开发者“皓际工造”制作的“不正经幻想”的UI让黑猫非常喜欢,所以决定把游戏的UI设计成“不正经幻想”的这种风格(黑猫已经问过原作者并且获得了同意喵)。然后想必各位从黑猫的名字就可以看出不会画画了,所以素材都是很劣质的 ( ๑ŏ ﹏
1 赞
第一天|《余烬生长》开发日志:我想让战场自己“长”起来截图
第一天|《余烬生长》开发日志:我想让战场自己“长”起来
大家好,我正在制作一款竖屏割草肉鸽小游戏,名字叫 《余烬生长》。 这次活动的主题是“涌现”。我一直在想:如果只是给玩家更多武器,算不算涌现?最后,我决定从战场本身入手。 我的设想是: 敌人死亡后留下藤蔓,藤蔓能够被火点燃;水可以灭火,也能让雷电传播。 这些规则单独看都很简单,但当它们同时存在,玩家的走位、击杀位置和能力选择,就可能让同一片战场产生不同的结果。 游戏的基础玩法会接近《吸血鬼幸存者》:
1 赞
短篇剧情游戏(回溯人间)截图
短篇剧情游戏(回溯人间)
积分不够了。做了一部分用AI,第一次用,试试创意,用来让AI制作。这效果还行吗?。这游戏可行?。 (仿去月球风格) 游戏简介:弥留老人回溯一生,回到四岁阻止车祸,重走人生,最后圆满落幕。 当前进度:第一次生成到76%中断,积分耗尽。踩坑:一次性粘贴完整剧本,消耗巨大,成品缺少互动,像纯文本小说。 接下来计划:后续用增量修改的方式,只增加场景点击彩蛋,不重建整个工程,节省积分。 随心制作用来看看现在
3 回复
《饭异常》开发日志#1 | 脑暴及开发方向确定截图
《饭异常》开发日志#1 | 脑暴及开发方向确定
10月1日,我们获得了聚光灯2026的主题“涌现”,1个小时后,我们开启了激烈地脑暴。 总结出以下几个方向: 1、Type help×瀑布流噪音 需要比较贴近生活一点的,某抖音主播不信灵异,头铁挑战了“午夜零点在某地使用电子香app上香”后猝死,调查其死因,从海量的互联网信息中还原故事。文字解谜类型。 玩法为玩家需要主动删除无效的瀑布流情报,留下有用的信息,完成推理 2、增量(tower wi
3 赞
玩家大人!和我们一起完成这个游戏吧|开发日志 01截图
玩家大人!和我们一起完成这个游戏吧|开发日志 01
大家好呀!这几天一直忙着做游戏,试了不少方向,也推翻了不少想法,总算把大方向敲定下来了。今天终于来写第一篇开发日志,和大家正式见个面! 我们正在做一款可以自由探索的即时战斗开放世界 RPG。 说到可以参考的目标,那么必然是 我打原神,真的假的,那自然是 好了好了,言归正传,还没跟大家介绍这个世界 你将扮演一位失去记忆的勇者,在村庄里醒来。公主陪在身边,王城送来了讨伐魔王的邀请,一场冒险就这样开始了
4 赞
【江湖自生#开发者日志02】江湖没长出来,bug长出来不少截图
【江湖自生#开发者日志02】江湖没长出来,bug长出来不少
今天开头干了一件蠢事 上午我以为问题在"内容不够",就打算往里加东西。 结果先做了一件事:把游戏从头玩了一遍,不开调试、不跳过、就当自己是个普通玩家。 玩了四遍。四遍都死在第四圈左右,四遍我都不知道自己为什么死。 更要命的是——我一点都不想开第五遍。 那一刻挺难受的。这游戏是我自己做的,主题还是"涌现",结果我自己不想玩。 那就不加东西了,先搞清楚为什么不好玩 我拉了个单子,发现三件事: 一,我不
1 赞