资产协作避坑指南

备注

最后更新：2025年9月7日

引言

在多人协作的开发环境中，资产管理不当是导致冲突、性能问题和返工的主要原因。本指南将重点关注 Unity/Unreal Engine 等现代游戏引擎中的协作流程。

核心原则

1. 谁负责？ 每个资产或模块都应有明确的负责人。对于一个角色，模型师负责模型和UV，贴图师负责材质和贴图，动画师负责动画。

2. 先沟通，后修改: 在修改不属于你的资产前，务必与负责人沟通。

常见问题与解决方案

场景与预制体 (Scene & Prefab) 协作

问题点:

• 场景文件冲突: 多人同时编辑同一个场景文件 (.unity, .umap) 是最常见的冲突来源。

• 预制体耦合: 巨大的、无所不包的“上帝预制体” (God Prefab) 极难维护和协作。

解决方案:

• 场景拆分: 将大型关卡按区域或功能拆分成多个小场景，使用 场景加载/卸载 (Additive Loading) 技术进行组合。这样不同的人可以负责不同的小场景。

• 预制体模块化:

  • 单一职责: 每个预制体只做一件事。例如，一个角色预制体，一个道具预制体，而不是一个包含了角色、道具和环境的巨大预制体。

  • 嵌套预制体 (Nested Prefabs): 善用预制体嵌套来组合复杂对象。修改最底层的预制体可以自动更新所有引用它的地方。

  • 变体 (Variants): 为预制体创建变体来处理差异化需求，而不是复制和修改。

模型与贴图协作

问题点:

• 枢轴点与缩放不统一: 导入的模型枢轴点 (Pivot) 位置错误，或缩放比例 (Scale) 不是 1，导致在引擎中难以对齐和使用。

• 材质丢失或错乱: 导入模型时，材质信息丢失，或者需要手动重新指定贴图。

• 贴图格式与分辨率混乱: 项目中存在 .png, .tga, .jpg 等多种格式，且分辨率从 512 到 4k 不等，管理混乱且影响性能。

解决方案:

• 导出前校准:

  1. 冻结变换: 在 DCC 软件 (Blender, Maya) 中，导出前必须 应用所有变换 (Apply All Transforms)，确保位移、旋转为0，缩放为1。

  2. 对齐坐标系: 确保 DCC 的坐标轴与引擎的坐标轴匹配 (例如，Blender 导出到 Unity 需要设置 Z-Up, Y-Forward)。

  3. 命名匹配: 遵循命名约定，例如模型名为 SKM_Goblin，其材质也应命名为 MAT_Goblin，引擎会自动匹配。

• 统一贴图标准:

  • 格式: 规定项目使用的主要贴图格式。例如，UI 使用 .png，带 Alpha 通道的贴图使用 .tga，普通颜色贴图使用压缩格式。

  • 分辨率: 制定不同类型资产的贴图分辨率上限，如角色为 2k，道具为 1k。

  • 通道打包 (Channel Packing): 将多张灰度图（如金属度、粗糙度、AO）打包到一个贴图的 R, G, B, A 通道中，以节省内存和采样器。

版本控制中的二进制文件

问题点:

• 二进制文件无法合并: 引擎中的场景、预制体、材质等都是二进制文件，Git 无法像合并代码一样自动合并它们的冲突。

• 仓库过大: 大尺寸的贴图、模型、音频文件会迅速撑大 Git 仓库，导致克隆和拉取速度变慢。

解决方案:

• 使用 Git LFS (Large File Storage):

  • 配置: 为大文件类型（如 .fbx, .png, .psd, .wav）启用 Git LFS 跟踪。

  • 工作流: LFS 会将大文件存储在专门的服务器上，而在 Git 仓库中只保留一个轻量的指针文件。

• 文件锁定 (File Locking):

  • 对于无法合并的二进制文件（尤其是场景和预制体），使用 文件锁定 机制。

  • Perforce 等版本控制系统原生支持文件锁定。对于 Git/Git LFS，一些团队会通过团队沟通或第三方工具来实现“签出/签入”(Check-out/Check-in) 的逻辑。

注意

在修改场景或核心预制体等高风险资产前，务必在团队频道中声明，告知其他人“我正在修改 XXX，请暂时不要动它”，并尽快完成提交。这是一种手动的“逻辑锁定”。

关于

作者:

Refactor团队

主要贡献者:

• 邱文涛

特别鸣谢:

所有走在前列、为后辈探路的游戏开发行业的师兄师姐们。