精神之井复盘

绪论

《精神之井》是我为了参加开拓芯，CUSGA 比赛而开发的项目。比赛周期约四个月，且没有明确主题限制，因此我希望借这个机会挑战一次相对完整的中型项目开发。 在此之前，我主要完成的是 Game Jam 类型的小型项目；而中大型项目往往因为开发周期拉长而半途而废。所以这次项目的核心目标，不只是完成一款参赛作品，也是在真实开发过程中检验自己：当项目结构变复杂、代码量上升、系统之间开始互相影响时，我是否还能保持稳定推进，并最终把项目完整做完。 且此项目包含1策划，1美术，2程序，锻炼合作能力以及模块拆解和程序分工能力。

核心玩法设计

2D平台跳跃解密游戏，玩家可操控最多四人的小队，通过各自技能的配合完成解密闯关。

成果

这次基本完成了《精神之井》的整体开发。虽然开发过程中删减了一部分内容，但最终仍然按时完成了游戏，并且主要功能都能正常运行。测试阶段没有发现明显的严重 Bug，整体流程也能够从头到尾跑通。

在玩法实现上，完成了角色控制与角色切换，并围绕四名角色设计了不同的能力：战士可以背人和投掷队友，盗贼可以拉人传送与蹬墙跳，法师可以悬浮和滑行，弓箭手则负责射箭，并拥有狗跟随相关机制。除此之外，项目还实现了风场、移动平台等交互物，以及音效、BGM 控制和对话系统。

比较满意的是，项目整体没有出现重大的逻辑漏洞或流程阻塞，核心玩法链路能够正常闭合。角色移动、投掷、传送等关键操作的手感也比较流畅，说明基础系统的稳定性达到了预期。

不太满意的是，很多交互物虽然逻辑上实现了，但反馈不够明显，导致玩家感知偏弱。例如压力板被踩下时没有明显的下压表现，风场的粒子效果也比较粗糙。由于自己在 TA 和画面表现方面经验不足，最终只做了比较基础的后处理，整体视觉表现还有提升空间。

问题

1，时间管理问题

没有给画面表现层优化给太多的时间，时间基本都花费在逻辑层的实现上，导致画面表现只是简单的背景图层拼接加上前景的角色和交互物，只给了简单的后处理以及unity自带的2D灯光系统，应该投入更多的时间在画面表现上，如优化灯光系统，使其更贴合游戏。

2，协作问题

最关键的点，沟通时间过少，一周一次的线上会议加上微信沟通无法很好的了解需求以及对接美术和策划。 只能通过微信询问无法很好的理解策划的意图，出现多次返工重做的情况，如以关卡为场景还是直接制作一个大场景的问题。 与美术对接有误，应该明确告诉美术所需要的图片规格以及样式，问题集中在npc移动方式导致的素材不可用，背景图片无法正确衔接。

具体说明：

• npc移动方式导致的素材不可用 npc移动方式为水平平滑前进，遇到障碍物返回，设计形象为一只兔子，素材给的是兔子跳跃向前，且素材图中本身已经有上下的位移以及左右的位移，无法使用。

解决方法，截取部分素材，强行适配，导致效果变差。

• 背景图片无法正确衔接 背景图是一个一个单独的，相互之间无法很好的衔接。且交互物没有单独设计图，使用的背景中部分组件来实现的 解决方法：绘制一些瓦片，yongtilemap填充缝隙以及实现碰撞

程序分工感觉可以进一步优化，我是按照角色/交互物这两大块来分的，实际开发表明这两块耦合度还是比较高的，因为交互物需要和角色有一些配合，如风场等等

解决方法：我来制作一些耦合度比较高的交互物，如风场。但是这个解决方法还是不太好，因为绝大多数交互物都需要和角色配合。

现在看来应该再加入一个公共规则层，通过统一的能力标签、接口或事件通信。这样即使某个交互物需要和角色配合，也只依赖公共规则，而不是依赖具体角色代码，后期扩展和调试都会更清晰。

其实我们做的时候有这样子的思路，比如重力平台实现的时候定义了角色重量这种公共规则，但是没有将这种公共规则层应用到整个项目中，而是想到了就用一下，没想到就耦合在一起。

3，设计问题

场景的规模选择，有两种选择方式。

• 一种是以关卡为单位做场景：方便实现复活点，相机边界空间限制。较难实现跨关卡机关，比如拉杆在关卡1，门在关卡2的情况。适合做线性关卡。

• 另一种是以大厅层为单位做场景：方便实现跨关卡机关，但是缺点是资源开销和场景管理成本会变高。一个大厅层需要容纳更多关卡对象、机关和摄像机边界，导致场景层级更复杂，物体引用和状态管理更容易混乱，后期调试与维护成本也会增加。

我们选择的是以大厅层为单位做场景，回头看的话感觉以关卡为单位做场景更好，后续也不会遇到美术资源无法拼接的问题。

4，技术问题

这次开发中比较重要的技术问题，是多角色切换和摄像机系统的配合。最开始看起来只是“按键切换角色”，但实际做起来会牵涉到很多状态同步：摄像机要跟随正确的角色，输入只能交给当前角色，其他角色要停止响应输入但继续保持物理模拟，全局视角下还要通过高亮告诉玩家当前选中了谁。这个系统最终通过两套 Cinemachine 虚拟相机来实现，常态下跟随角色，切到全局视角后再选择目标角色。难点不在单个功能，而在这些功能必须同时正确，否则就会出现摄像机跟错人、多个角色一起动、玩家不知道当前控制谁等问题。

另一个关键问题是 Tarodev 2D Controller 的衔接。项目的基础移动手感依赖这个第三方控制器，所以自写技能不能绕开它另起一套逻辑。盗贼蹬墙跳、战士投掷、弓箭手抛物线预览、法师缓降这些能力，都需要复用控制器已有的地面检测、速度覆盖、重力参数和输入控制。这个过程让我学到的一点是：使用第三方控制器时，最好把它作为稳定的底层模块，自己的玩法能力通过外部接口叠加上去，而不是直接修改核心源码。这样虽然前期需要多花时间理解它的接口，但后期更容易保持移动手感一致，也更方便维护。

收获

这次项目让我对 Unity 中型项目的复杂度有了更真实的认识。相比 Game Jam 项目，中型项目更难的不是单个功能实现，而是角色、摄像机、交互物、UI、音频和场景流程之间的整合。很多问题都出现在系统连接处，比如切人时的输入控制、摄像机状态、角色高亮，以及机关和角色能力之间的配合。

在工程上，我意识到 Unity 项目不能只关注代码，还要重视 Prefab、Inspector 配置、命名规范和文档。很多机关逻辑本身并不复杂，但如果依赖关系没有整理清楚，后期就很容易出现漏拖引用、组件缺失、状态不同步等问题。之后做项目时，应该更早建立公共交互规则和验证清单，减少角色与机关之间的直接耦合。

在玩法设计上，我更明确地意识到，功能实现不等于体验成立。机关、技能和 UI 都需要足够清晰的视觉与音效反馈，否则玩家很难理解当前发生了什么。之后做交互设计时，应该把反馈表现当作功能的一部分，而不是最后才补的装饰。

在画面表现上，我认为不能将画面表现这种东西放到最后做，因为这往往可能因为时间等原因被舍弃，应该更重视画面表现，加深对shader，粒子系统的学习。

游戏链接与演示视频

演示视频：【一人操作四个角色的横板动作解密！大学生自制游戏《Spiritual Well精神之井》宣传视频】https://www.bilibili.com/video/BV1N45q6nEmE 游戏链接：https://yyw123456.itch.io/spiritual-well