心锚

项目概述

《心锚》设定在一个被 AI 全面接管的未来社会。玩家扮演 Debugger，在赛博世界中探索并解除谜题。美术风格压抑而写实，玩法核心是探索，并在探索过程中传递关于 AI 时代的严肃知识。

在这个五人团队中，我承担了三重角色：主程序（负责底层架构与全局系统）、Unity 整合（把美术与程序落地进可玩场景）、项目管理（版本控制、Kanban 与模块交付流程）。

设计起因与目的

我与团队确立的目标是：发挥每个人的长处，做出一款独特且运行流畅的 3D 探索游戏。这句话推导出两个结论，几乎决定了下文所有的技术选择。

其一，"发挥每个人的长处"意味着代码由程序编写，但必须由策划、UI 与美术来使用。因此系统需要提供零代码的配置界面，而不是把行为写死在代码里。

其二，"运行流畅"在我们这里被理解为一种流程保证而非性能指标：项目必须在任何时刻都拿得出一个可玩版本——这直接推动了后文的分支模型与 Kanban 流程。

严肃游戏的表达则通过收集品完成。每一个被收集的物件都承载一段"严肃档案"：例如齿轮对应的《算法决定论》——人类行为可以通过数据分析与机器学习模型被预测，甚至被提前结构化，从而削弱个体的自主性。背包是这款游戏真正的论述载体，这也是我亲自接手它的原因。

程序架构

我把游戏底层代码搭建为 manager - gameplay - data 的三层结构，并划分为 Global System 与 Local System 两侧。

通信方式按作用域刻意做了区分：

• 模块内部——依赖注入配合 GetComponent 直接引用，编写成本低，没有额外仪式感。
• 模块之间——由 Event Bus 与 ServiceHub 共同承担的松耦合、自适应架构。

背后的判断是：解耦本身有成本，因此只应在能带来回报的地方付出。模块内部的额外间接层换不到任何东西，只会拖慢开发；而跨模块边界的解耦换来的是独立迭代与易于维护。游戏事件以 ScriptableObject 的形式存在，策划可以在场景中直接把触发者与目标连起来，完全不需要碰代码。

UI / 背包 / 收集品系统

为了满足游戏对"严肃性"的表达需求，我接手了 UI、背包与收集品系统——一个相对复杂的多模块全局系统。这需要与 UI 设计师保持持续沟通，最终基本实现了对方的交互构想：悬停高亮物品框并展开右侧描述，按 B 开合背包，拾取物品时弹出承载档案文本的窗口。

我没有逐个手写物品，而是用统一的 ScriptableObject 模板来搭建收集品系统。这既提升了代码复用度，同样重要的是为 UI 与策划提供了一个零代码的设计窗口：图标、名称、描述、消息名与严肃档案全部作为数据字段填写。

关卡系统

我负责编写了**旋转塔（Rotating Tower）与网格谜题（Grid Puzzle）**的代码，并参与了蜘蛛关卡的部分关卡设计。

• 旋转塔——自下而上激活对应踏板来旋转各层（90 度、四种朝向，每种对应不同图案），直到图案连成一个完整表面即通关。由于旋转塔在场景内是一对一的物件触发模式，我把原本的 Index 记录模式改为复用 EventBus，使策划能够零代码配置。
• 网格谜题——早期构想中这个谜题会在游戏内多处出现，因此我编写了 Grid Puzzle Generator，让它在后续开发中可以直接复用，而不必逐个重建。
• 蜘蛛关卡——策划提供的原型只包含一套机制原型，若直接使用难免单调。我将蜘蛛生成器与 ViewAlign 谜题改造以适配场景，让玩家在多个 ViewAlign 之间往返移动。这既延长了游戏流程，也因为该关卡出现在游戏后期，使其难度曲线更为平滑。

遇到的困难与解决方案

每周的开发日志记录了问题浮现的过程，以及各自采用的解决方案。

Manager 加载顺序问题。 给所有 Manager 启用单例模式后带来了加载顺序问题。我没有去纠缠初始化次序，而是引入 ServiceHub 并把所有 Manager 注册进去，让依赖通过查询解析，而不是依赖构造顺序。

跨模块耦合。 系统之间若直接互相引用，模块就再也拆不开了。我采用基于 ScriptableObject 的 EventBus 与 Event Listener，将其挂在 Trigger 与 Target 物件上，从而在场景内实现便捷的事件通信，同时保持模块彼此独立。

策划原型与框架不匹配。 为了把策划制作的关卡原型整合进既定框架，我对其代码做了自适应重构，把原有的 move / damage / spawner 重新组织进 Hierarchy。这项工作产出了两个决定：经与策划讨论后，移除了仅存在于该关卡的血量系统——关卡局部的状态模型破坏了全局游戏状态的一致性；同时统一使用 IInteractable 接口规范交互，让所有可交互物件遵循同一套契约。

交互手感不一致。 我补充了基于指针的交互方案：只有鼠标指向物件时交互通道才会触发；以及一套通用方案：玩家进入交互区域并按下交互键时，触发对应的回调事件。

美术迭代成本。 若靠手工整合美术资源与脚本，每次美术修改都代价高昂。我大量使用 Prefab，使迭代能够自动传播，而不需要重新整合。

最终测试前累积的缺陷。 缺陷没有被随手修补，而是集中在一次专门的批次中清理（04/29 修复清单：旋转塔出口传送脚本与图案对齐、关卡一收尾动作、关卡二传送点位置与收集品、字幕出现、收集品显示、旋转塔速度等），随后在最后一周的测试中进行关卡优化。

项目管理

版本控制。 美术与程序分别在独立分支上开发（Dev-Art、Dev-Gameplay），并将最新可运行版本同步至 main。这一模式保证项目始终存在一个当前可玩版本——当团队在持续整合美术时，这比一份整洁的提交历史更重要。

Kanban 与模块化交付。 我们使用 Kanban 看板进行模块化的团队开发。每个模块作为一个整体，依次走过原型设计、美术/程序初稿、美术/程序细化，最后完成整合，才被装配进整体游戏开发中。让一个模块完整地走完这条流水线，正是可用版本得以始终存在的原因，也是课上所讲敏捷开发模式的实际应用。

资源归属。 为了分散开发责任、降低 Unity 项目内的冲突风险，我们按团队成员建立文件夹，让每个人各自负责分配到的脚本模块与美术资源。共享资源则在 Root 目录下单独归类，便于在场景整合时取用最新版本。

Hierarchy 规范。 场景 Hierarchy 同样做了分类，把美术、程序与 UI 设计师的工作彼此分开，使项目后期的整合工作保持可预期。

过程中的思考

在游戏系统设计上，我深刻体会到游戏开发是一门代码服务于设计的艺术，主次不可颠倒。开发早期我一再陷入过度设计架构、过分追求全局复用性的陷阱，反而忽视了游戏本身的设计美感。在朋友的提醒之后，我认识到一种新的开发模式：从 GDD 与 Storyboard 出发，先把游戏拆解为若干核心系统，对最重要的部分排定优先级，再通过调用这些基础设施，在 Unity 环境中复现 Storyboard 所描述的体验。架构应当是设计所调用的东西，而不是设计需要去迁就的东西。

作为项目管理者，我也在疏漏中学到了东西——我时常忘记更新 Kanban 看板。事实证明任务拆解是模块化游戏开发中至关重要的产物：它反映真实的开发进度，并决定了游戏单元的测试阶段以及下一次迭代的测试阶段。若没有真正掌握敏捷开发流程，项目就会堆积大量半成品的程序与美术，这对项目管理而言是一场灾难。

素材致谢

第三方素材：DOTween (HOTween v2)，作者 Demigiant。