停滞的 Unity 项目可能看起来比实际情况更糟。缺失的 SDK、未记录的构建步骤或已停用的服务，可能掩盖了一个仍可使用的产品。同样，令人信服的演示也可能隐藏严重的发布问题。
作为创始人或制作人，您需要知道下一笔投入实际上能实现什么。我会先问：您想发布什么、哪些部分已经可用、哪些问题可能妨碍完成。第一次沟通只需简单介绍；分享敏感资料或源代码访问权限前，我们可以先签署保密协议（NDA）。
01
保存接手时的项目
保留仓库历史、最后一个可运行构建，以及所有设置说明。在用其他版本打开项目之前，记录 Unity Editor 版本和目标平台。保存原始项目，在单独的工作副本上调查。
首个有用交付物是可重复构建：另一台机器能够按文档步骤生成可运行应用。如果失败，记录确切阻碍和缺失依赖。“无法构建”是需要调查的发现，还不足以证明应当重写。
Unity 建议升级前先备份，并评估收益是否值得投入。我在改变接手项目的基线之前也遵循同样的原则。
Unity：升级 Unity 项目02
检查项目需要的工具、服务和账号
我会检查编辑器版本、渲染管线、Unity 包、Asset Store 资源、原生插件和外部 SDK。审查还包括构建工具、后端环境、签名权限，以及必需账号由谁控制。
针对每个关键依赖项，确认其版本、可用性、兼容性和负责人。依靠未记录的本地修改维护的插件，需要采用不同于可直接安装且无需修改的插件的处理方式。
将包清单和锁文件随项目一同保存。Unity 锁文件记录已解析的包依赖，应纳入版本控制，以便在不同机器上复现相同的包集合。无法使用的服务或缺失的源码，可能比 C# 代码的年代更能决定恢复范围。
Unity：依赖解析与锁文件03
在目标设备上测试性能
“在我的电脑上运行流畅”并不能证明已适配移动端或头显。我会选择有代表性的硬件和可重复场景：启动、繁忙玩法时刻、场景切换，以及适用时的较长会话。
我会寻找 CPU 或 GPU 压力、内存增长、加载延迟和反复分配，再将发现与玩家可感知的问题联系起来。记录设备、构建版本、设置和步骤，确保比较有意义。
Unity 建议在目标平台进行性能分析。Editor Play Mode 与编辑器共享资源，无法准确反映设备性能。开发构建支持连接 Unity Profiler。性能分析指导诊断；在认定问题解决前，我也会在预期发布配置中检查拟议修复。
Unity：分析应用性能04
检查存档进度、购买记录和分析数据
成功启动只是兼容性的一部分。已有玩家可能有保存的进度、已解锁内容、购买记录或服务器端状态。
我会追踪数据存放位置，并用有代表性的旧存档测试拟议改动。检查加载中断、数据缺失和迁移失败。在改变格式或标识符前，商定必须保留什么、什么可以改变，以及如何恢复。
然后走完一条完整成长路径：开始、获得或解锁某项内容、保存、重启并继续。验证关联分析事件，包括含义和版本背景。如果历史跟踪不可靠，下一版本可以建立测量基线，但无法自动证明留存已经改善。
05
用小型可运行示例测试最大的未知问题
在估算大规模代码修改或重做之前，我会先约定一个小测试：它需要回答什么问题、投入上限是多少、怎样算成功。
例如：一个代表性关卡能否加载现有存档、完成一次玩法循环、发送预期事件，并在目标手机上满足约定的性能预算？
测试应包含最有可能阻碍发布的系统。单独重做一个菜单，无法说明多少关于玩家进度或平台服务的问题。提前设定工作上限，并记录测试确认了什么、哪里失败了、还有什么未知。
06
根据检查结果选择下一步。
建议应说明检查发现了什么、为什么重要，以及接下来该做什么。
- 完成
核心游戏可以运行，剩余工作能清楚列出并估算。
下一步： 修复阻碍发布的问题，并测试约定的功能。
- 重构
特定系统反复导致故障，或阻碍必要的改动。
下一步： 改进一部分代码，再检查相关功能是否仍然可用。
- 重建
即使考虑过切实可行的修复办法，现有代码仍难以合理支持所需功能。
下一步： 测试替代方案，并规划如何迁移已有玩家数据。
一次范围较小的付费项目检查，可以帮助您决定下一步。开始前，我们会约定要回答的问题、所需访问权限、工作上限和交付内容。您会收到可运行的版本或阻碍其运行的说明、按优先级排列的发现，以及明确说明前提条件的下一步建议。
要查看玩法、存档与成长相互连接的具体案例，请了解 Polar Station Survival——这款游戏包含许多相互连接的系统，我是唯一的 Unity 开发者。