聚光灯 GameJam 开发者日志0 1：断臂求生， 3D 到 2D 的痛苦转型

修改于5 小时前6 浏览综合

聚光灯 GameJam 开发者日志 01：断臂求生，从 3D 到 2D 的痛苦转型

游戏名称：《退格：第七码头。》

大家好，我是《退格：第七码头。》的独立开发者。

这次参加 TapTap 聚光灯 GameJam，我选择的主题是“涌现”。

最开始，我对“涌现”的理解，是让玩家进入一个真实存在的 3D 空间：这里有废弃的码头、污染的河流、分裂的阵营、可以调查和互动的设施。玩家不应该只是按照固定选项推进，而是通过观察、交流、获取材料和组合物品，让事情逐渐产生不同的结果。

于是，我一开始选择了 3D。

现在回头看，那是一个非常有野心、也非常危险的决定。

【本期进展：为什么我砍掉了做好的 3D 模块】

过去几天，我从完全不了解完整 3D 游戏制作流程的状态，开始学习使用团结引擎和 C# 搭建一个真正可以运行的 3D 原型。

一开始，我们从最基础的角色移动开始。

角色最初只是一个胶囊体，场景也只是几个简单的 Cube。但我第一次真正理解了：

GameObject 和 Component 是什么；
CharacterController 如何控制角色；
为什么直接修改 Transform 不能正确处理碰撞；
CharacterController.Move() 到底接收的是速度还是位移；
重力为什么需要自己计算；
Time.deltaTime 为什么必须参与移动；
相机为什么要独立于玩家角色；
父子物体和局部坐标到底是怎么工作的。

最初的移动代码只是简单地修改角色位置。后来，我们把它改成了基于 CharacterController 的移动方式：

csharp
controller.Move(totalMove);

水平方向的移动和竖直方向的重力被拆开计算，再合成为一次完整位移。角色终于可以在场景中移动、落地、撞墙，也可以从平台边缘掉下去。

这一步看起来很简单，但对我来说，是第一次感觉到自己不是在“拼一个按钮”，而是在真正理解游戏里的空间、物理和程序状态。

【从基础移动到第一个 3D 场景】

完成角色移动之后，我们开始搭建第一个灰盒场景。

最开始的场景非常简陋：

一个地面；
一面墙；
一个胶囊体玩家；
一台跟随玩家的摄像机；
一个方向光；
一些用于测试距离和碰撞的基础物体。

但这一步非常重要。

在没有美术资产之前，灰盒让我第一次能够站在“玩家”的角度思考问题：

玩家从哪里出生？

前方应该看到什么？

墙壁会不会挡住道路？

场景的空间会不会太大？

交互物体距离玩家多远才舒服？

镜头会不会被场景遮挡？

这些问题以前都只是设计文档里的文字，直到它们变成了真实的空间，我才发现，游戏设计和程序实现之间有很大的距离。

后来，我们开始加入交互系统。

玩家靠近物体后按下 E 键，系统会在一定范围内寻找最近的可交互对象，再调用它的 Interact() 方法。

玩家负责寻找目标，物体负责决定自己被交互后发生什么。

这让我们逐渐形成了一个比较清晰的架构：

玩家移动脚本只负责移动；
玩家交互脚本只负责检测输入和寻找目标；
交互物体自己决定如何响应；
背包系统负责保存材料；
组合系统负责检查材料并产生结果。

这也是我第一次真正理解“职责分离”。

以前我会本能地把所有功能都写进一个脚本里。后来才发现，一个脚本什么都管，短期看起来快，后面会越来越难修改。

【3D 游戏最初的想法：让“涌现”发生在空间里】

当时的游戏设想是这样的：

玩家来到一座因为“退格”而陷入危机的废弃工业码头。

这里的河水已经被污染，旧净水设施无法正常工作。码头上有两个互相不信任的阵营：

铁岸：掌握金属和容器类资源；
苔棚：掌握纤维、过滤介质等材料。

双方都只拥有解决问题的一半条件。

玩家可以：

调查环境；
和 NPC 交流；
获取或者交换材料；
发现污染记录；
组合金属容器和过滤材料；
修复净水设备；
影响两个阵营之间的信任；
最终走向不同结局。

我希望“涌现”不是一个写在标题里的概念，而是玩家实际玩出来的结果。

同一个净水设备，可能因为玩家是否调查过污染记录、是否帮助过某个阵营、是否拿到了正确的材料，而产生不同反馈。

理想状态下，玩家不是按照一条固定路线通关，而是在自己的选择中让这个世界慢慢显露出不同的状态。

【我第一次做材料、背包和组合系统】

在交互系统可以运行后，我们继续加入了材料拾取和背包。

玩家和场景中的材料互动之后，材料会从场景状态转移到玩家状态。

例如：

text
玩家与金属材料交互
→ 背包增加金属数量
→ 场景中的材料消失
→ 后续组合系统可以读取背包内容

随后加入了过滤材料，并尝试制作第一个组合系统。

组合流程大致是：

text
玩家点击组合按钮
→ 检查玩家能力
→ 检查背包材料
→ 消耗材料
→ 生成组合结果

这期间也遇到了很多非常基础、但对新手来说很容易踩中的问题。

比如：

Unity 生命周期函数的大小写必须完全正确；
Start() 写成 start() 后不会自动执行；
UI 按钮不能直接调用返回 bool 的方法；
原本使用 && 的条件判断，实际上应该使用 ||；
场景没有及时保存，导致部分物体丢失；
组件引用为空时会触发 NullReferenceException。

这些问题现在看起来都不复杂，但它们构成了我真正学习游戏开发的过程。

不是看完教程就会了，而是写出来、运行、报错，再一点点弄清楚为什么错。

【真正的问题不是 3D 不能运行，而是我做不起完整的 3D】

到这里为止，3D 原型其实已经可以运行。

角色可以移动。

相机可以跟随。

场景有碰撞。

玩家可以靠近物体并交互。

材料可以拾取。

背包可以保存材料。

组合系统也有了第一版。

后来，我们甚至开始搭建第七码头的正式开场：

玩家在污染河流附近醒来；
可以观察死鼠和黑色污染液体；
可以选择是否饮用河水；
饮用污染河水会进入死亡结局；
死亡页可以重新开始；
开场镜头和字幕流程可以运行。

所以，我并不是因为 3D 完全失败，才决定转型。

真正的问题是：3D 原型只是完成了“能运行的骨架”，距离一个完整、好看、能交付的游戏，还有非常长的路。

接下来还需要制作：

大量场景模型；
建筑、管道、码头设施；
NPC 模型；
人物动画；
交互动画；
道具模型；
材质和灯光；
场景构图；
视觉特效；
UI；
音效和音乐；
更多剧情触发；
更多测试和修复。

这些工作并不是简单地“再加几个模型”。

每一个模型都涉及比例、材质、碰撞、摆放、镜头表现和与其他物体的关系。

而我当时仍然处在学习 3D 建模、学习引擎、学习 C# 和学习游戏设计的阶段。

我可以继续往前做，但我已经清楚地意识到：

如果继续坚持 3D，最后很可能会把大量时间消耗在“把场景补完整”上，却没有足够时间把真正重要的玩法、剧情和结局打磨出来。

【最痛苦的决定：保留设计，放弃表现形式】

这次转型最痛苦的地方，不是删除模型，也不是重写代码。

而是承认：我当前的能力和时间，不足以支撑最初设想的 3D 版本。

我曾经以为，只要把技术学会，就可以把脑海里的东西全部做出来。

但实际开发后才发现，游戏制作不是只有“会不会写代码”这一项能力。

它同时要求：

设计能力；
程序能力；
美术能力；
关卡能力；
叙事能力；
音频能力；
项目管理能力；
对时间和范围的判断能力。

在 GameJam 的时间限制下，最重要的不是证明自己可以做一个多大的游戏，而是判断什么内容值得留下，什么内容必须舍弃。

所以这次我没有放弃《退格：第七码头》的核心设计。

我放弃的是 3D 作为表达它的方式。

【转向 2D：把复杂的空间，压缩成可控的画面】

转向 2D 之后，我们重新思考了游戏的核心。

原本 3D 版本强调的是：

text
在空间中移动
→ 观察环境
→ 寻找物体
→ 与 NPC 互动
→ 获取材料
→ 组合净水设备

2D 版本则改成：

text
进入场景
→ 点击调查热点
→ 获取线索或物品
→ 作出判断
→ 解开局部障碍
→ 前往下一个区域

玩家不再需要自由行走，也不再需要角色碰撞、寻路、跳跃和多方向动画。

我们把场景压缩成一张固定画面，再用点击区域表达玩家能够观察和操作的对象。

例如在河岸场景中，玩家可以调查：

河水；
死鼠；
黑色污染液体；
通往码头的道路。

调查并不会直接告诉玩家正确答案，而是给出足够的事实线索。

玩家可以选择喝水，也可以暂时不喝。

如果喝下污染河水，就会进入死亡结局；如果选择观察并继续前进，就可以进入后续流程。

这样一来，“观察—判断—行动—反馈”的核心体验依然保留了。

只是原本需要靠 3D 空间表达的内容，现在改由画面、热点、文字和状态变化来表达。

【2D 转型后，我反而更接近最初想做的游戏】

转型之后，我发现一个很有意思的变化。

3D 版本看起来更接近我脑海里的“完整游戏”，但它让我不得不花大量时间处理表现层问题。

2D 版本看起来更简单，却让我可以把注意力重新放回：

玩家应该先看到什么；
哪个线索应该提前出现；
为什么玩家会相信某个选择；
选择之后世界应该如何反馈；
不同阵营之间的关系如何变化；
三个结局之间应该有什么因果关系。

换句话说，3D 让我先面对“怎么做出一个空间”，2D 则让我重新面对“我到底想让玩家经历什么”。

这也是我目前最重要的一次开发认识：

有时候，降低表现形式的复杂度，反而能让核心设计变得更清楚。

“涌现”不一定要通过复杂的物理系统、大型场景或者真实 NPC AI 表现。

它也可以来自几个简单状态的叠加：

玩家是否观察过污染；
玩家是否拿到了某种材料；
玩家信任哪一方；
两个阵营之间的冲突是否升级；
玩家是否理解了污染的真正来源；
玩家最终选择了独自生存，还是促成合作。

这些变量彼此交叉，就有可能产生超出单一对话分支的结果。

【问题与风险：转型并不意味着轻松】

转向 2D 之后，并不代表项目突然变简单了。

我失去了部分已经完成的 3D 表现工作，也需要重新整理场景、流程和交互逻辑。

目前的风险主要有几个：

第一，2D 素材还需要统一风格。

如果背景、角色、道具的画风不一致，画面会显得像素材拼贴。

第二，固定画面很容易变成“点击热点列表”。

如果每个物体只是点击后弹出一句话，玩家会觉得自己不是在探索，而是在逐项检查按钮。

第三，叙事和机制必须真正结合。

玩家调查死鼠和黑液，不应该只是为了完成任务，而应该让这些信息影响之后的判断。

第四，GameJam 的时间依然非常紧张。

转型只是把制作风险从“做不完 3D 内容”转移到了“如何在 2D 中快速做出完整闭环”。

所以接下来最重要的事情，不是继续扩张设定，而是完成一个短小、完整、可以从头玩到尾的版本。

【本期总结】

这几天的开发过程，大概可以概括成这样：

text
最初的宏大设想
→ 学习 3D 移动和碰撞
→ 搭建第一个灰盒场景
→ 加入交互、材料、背包和组合
→ 制作 3D 开场流程
→ 意识到个人时间和制作能力无法支撑完整 3D
→ 保留核心玩法和世界观
→ 转向 2D 点击探索与叙事

我曾经把“砍掉 3D”理解成一种失败。

但现在看来，它更像是一次范围控制。

真正的失败不是放弃一个做不完的方案，而是明知道做不完，还继续把时间投入到无法完成的部分里。

《退格：第七码头》的 3D 版本并没有完全消失。

它留下了角色控制、交互系统、材料系统、组合系统、开场流程，以及我对这个游戏最初的理解。

而 2D 版本，则是我在当前时间、能力和精力范围内，真正有机会完成的版本。

【下期计划】

下一期，我会集中完成 2D 版本的第一个可玩闭环：

标题界面；
醒来剧情；
河岸场景；
河水、死鼠、黑液和道路调查；
喝水死亡；
新输入重试；
不喝水并前往码头；
第一版试玩结束页。

同时，我也会继续整理 3D 版本留下的过程截图，让这次从 3D 到 2D 的转型不只是一次删档，而是完整保留下来的开发记录。

如果最后能做出一个哪怕只有几分钟、但可以完整体验的版本，这次转型就是值得的。

（附注：本文记录的不是一个“从头到尾都很顺利”的开发过程，而是一个新手开发者如何在野心、能力和时间之间不断做取舍的过程。3D 没有白做，它至少让我知道了自己真正想做什么，也让我知道现在应该先把什么做完。）聚光灯GameJam开发者日志 | TapTap

聚光灯游戏创作挑战

9.1

前往论坛

游戏开发者讨论区

1.2 万关注·4023 帖子