下载 App
GAME DEV LOG 03 | 群星
修改于昨天 11:0710 浏览
这次,想先告诉大家一件小事:我们的游戏确认了正式的名字:
群星 | CONSTELLATIONS



00.游戏LOGO和一个小动画尝试
K-3089 会继续留在故事里,但随着开发的进行,一台设备的编号,已经不足以装下我们想要讲的东西了。
这十天中,我们俩人一边继续验证玩法,一边重新寻找游戏的样子。我们讨论节点、人物、终端、文字,也讨论一个很实际的问题:如果玩家真的要在这座空间站里工作,他面对的屏幕应该是什么样的?

游戏画面整体目前确定使用1bit像素美术,采用暖感的蓝黄对比色来体现复古+科幻的质感,试了很多不同的颜色之后我们喜欢这个色调和像素渐变产生的抖动效果。这里有一些没用上的概念图,放出来给大家做一个感觉上的区别。




01-a.《群星》界面初版设计探索
把资源画完拼起来的时候看起来很对味,我们将画面分成了1:2的两个窗口,两边都设计了一套单独的UI交互系统,简述大概是:
左边是真实场景发生的互动窗口,右边是终端机的虚拟交互界面。

01-b.《群星》当前游戏画面截图
我们之前提到的节点玩法会主要在终端里面进行完成和操作,当然了,我们还打算设计一些其他功能,这些如果能做出来并且实现的话,后续再分享吧。
再体验这个游戏画面的时候,还是会有一种无以言表的开心,这是我第二次自己体验到自己画的游戏,不过是第一次自己做程序,边请教GPT老师边自己想办法,玩起来的时候还是个空壳,但是我怀念这种纯粹的快乐,然后直到名字确定下来的时候,回想起来最开始这些互不相关的东西,我能感觉到它们正在慢慢靠近同一个方向。
01 | 为什么是群星
我们想过一些更长的名字。
“群星静默”“群星之间”,我都很喜欢。前者有一种安静的伤感,后者则很自然地让人想到联系:不是某一个独立的对象,而是对象与对象之间发生了什么。
最后,Szu说直接叫“群星”好了。
为什么不呢?这太好了。
故事发生的地方叫群星号。它是一座球形空间站,像一颗人造的星球。里面的人各自工作、生活、休眠,也留下各自的记录和记忆。他们已经熟悉彼此,参与过某次工作,对一件事情形成过自己的解释。有些关系仍然持续,有些只剩下一份公告、一条备注、一件物品。
我开始觉得,人物也像群星。
每个人都是一个独立的存在,却并不孤立。我们认识一个人,常常不是因为他完整地介绍了自己,而是因为在另一个人的话里、在一件物品的来历里,再次遇到了他的名字。
这也很像我们正在做的节点式调查玩法:从一个名字出发,走到一份记录,再从记录里看见另一个人。
群星不只在空间站之外,也在这些人与人之间。
不过,这个名字对我来说并不只有浪漫。
一条联系被重新发现,并不意味着它能重新发生。我们可以恢复文件,读出铭文,却未必还能等到那个人亲自回答。
02|节点不应该只负责承载内容
名字确定的同时,节点系统也在继续收束。
我们用很粗糙的网页 Demo 跑了一些例子。没有美术资源的时候,反而更容易看清自己是在思考游戏设计,还是只是在按照我们安排的顺序点按钮。
最开始我们想让人物、设备、档案、对话、维修和解谜推理都变成节点,维修员的工作也会包含恢复数据,那么我们想让操作终端成为一个有代入感的方式,推理过程就在节点的连接之间涌现。

02.初次节点交互实验 | 10.6
Szu先利用很粗糙的DEMO试验了一下,主要是为了验证核心的三个节点大类:
【实体节点】【信息节点】【功能节点】运作起来是否流畅。
如图所示,例如人物、设备等统一归纳为【实体节点】,【功能节点】包含细分类别,例如【属性】【追踪】【筛选】等,将其连接在【实体节点】就可以得到一些新东西,这是目前玩法的一部分,作为一款推理游戏来说感觉还是蛮新鲜的,不过问题也很多,例如交互起来会有很多琐碎和重复操作,以及信息量过大带来的节点膨胀。
所以后面我们主要保留三类核心结构:
| 实体节点 是人物、部门、设备、场景,以及世界内能够被定位和操作的对象。 | 信息节点 是从这些对象那里获得的记录、档案、测试结果与陈述。 | 功能节点 则是玩家使用的方法:属性、追踪、筛选、连接。 |
| 人物 | 报告 | 属性 |
| 部门 | 公告 | 追踪 |
| 物品 | 记录 | 筛选 |
| 程序 | 活动 | 连接 |
节点不应该只负责承载内容。它也应该代表玩家拥有的能力、方法和资源。
03.一些UI探索
节点本身就应该代表玩家拥有的能力、方法和资源。
例如,知道一个名字,只意味着知道了一个名字。使用“属性”,才能补全它对应的登记信息;
使用“追踪”,可以继续查找相关材料;
当材料太多时,再用“筛选”缩小范围。
“连接”也不只是把两张东西放在旁边。它可以帮助玩家比较候选人与经办记录,寻找共同出现的材料,或者把两份原文放在一起阅读。nexus9_node_investigation_demo_…
举一个和游戏内容无关的例子:
一台设备已经能够通电,却仍然读不出旧工作环境。此时,只知道某个人“会维修”还不够。玩家需要继续查他的专业与工作记录,判断他是否真正处理过这个问题。
我们希望推进不只是因为找到了那个被预先标亮的人,而是因为玩游戏的人可以开始思考自己现在需要的帮助究竟是什么。
当然,这套方法也暴露了不少问题。
信息一多,节点就还是容易膨胀;提取、展开、再作为输入,有时候会让一个已经想清楚的判断,需要经历好几次重复操作。
操作有步骤,不代表步骤都有意思。
接下来要继续删掉的,就是那些只负责搬运信息、却没有带来新判断的手续。功能节点究竟需要怎样的限制,也还要测试。我们不想为了让它“像一种资源”,反而让玩家在已经知道怎么做的时候,被迫多跑一趟。
03 | 美术探索 —— 节点块 NODE BLOCK
我以前是一个Notion重度使用患者,使我依赖这个产品的功能特点有两个:
- All in one的概念
- Block的概念
卡片的概念固然很好,但是缺少了一些维修员的体感,然后我就想到了模块,之前看过一个很有意思的产品:

04.SAM PHYSICAL NODES
这是一个名叫SAM的模块化编程物理组件,模块的节点之间互相运作的感觉,更像维修员,而且这样可视化的效果给了我很多视觉探索上的灵感。画了一些草图,想要尝试找到一个感觉,想要在平面和立体感中找到一个平衡。


05.最初的节点设想概念设计



06.第二步尝试的升级版节点像素动画
然后我就想要让这个节点看起来不那么程序化,像模块可能会比较有意思,左右两边各有一个比较小的连接点,当【功能节点】进行连接作用时就大概是像视频这样子。
07.一个简单的实现效果 | Godot
这个时候颜色还是一个比较暗沉的版本,看起来不是很有趣,不过作为初次的美术尝试我觉得还可以,也摸到了更多绘制像素画的技巧,万幸的是没有浪费时间做无用功。接下来会顺着这个感觉以确定的色调继续优化,希望一切顺利,画出很有意思的【节点块】给大家来玩。
04|让它们慢慢连接起来涌现
我觉得”涌现“其实在潜移默化地影响我们对游戏的理解,以至于我们已经不会去多想主题了,因为它已经成为了我们游戏的一部分,我们现在只需要连接起所有的碎片,拼图的外圈拼好了,事情在慢慢变得简单。


08.基本功能测试画面 | Godot
节点操作仍然需要压缩,资料过多时怎样组织、长时间阅读是否舒服、剧情与终端如何更自然地配合,都还需要继续试验。
但这次再看画面,我终于有一种比较确定的感觉:我知道自己想让它往哪里长了。
不是因为每件事情都有了答案,而是因为名字、人物、玩法与画面,不再各自朝着不同的方向前进。
那台工程终端仍然叫 K-3089。它等待着被检查、被修复,也等待有人继续追问它留下来的东西。
而故事里的人,不应该只是通往下一个任务的入口。他们各自拥有一段生活,也在别人的记录里留下了某个位置。
我们现在想做的,就是让群星可以相连。












