共享文件夹时代的噩梦

在90年代中期，游戏开发的「协作」还处于非常原始的阶段。你可能有过这样的经历：团队里的美术和程序员同时改了同一个文件，结果互相覆盖；或者重要的美术素材被误删除了，但因为没有历史记录，只能重画；或者因为版本混乱，昨天还能玩的功能今天又坏了。

这就是版本控制工具引入前的真实图景。对小团队来说，「人肉协调」还勉强可行，但当团队规模扩张到数十人时，协作就变成了灾难。

版本控制系统的引入与「水土不服」

1990年代中期，软件行业已经在使用版本控制系统，如CVS和RCS。但游戏开发的痛点和普通软件不一样——游戏项目里有大量的二进制文件（美术、音频、动画），而传统的源码控制系统对二进制支持很差。

Perforce（现在叫Helix Core）是在1995年发布的，它从一开始就被设计成能处理二进制文件，并且性能足够好。最早采用Perforce的游戏工作室是Epic Games，随后id Software、Valve等大厂也陆续跟进。

从「人肉协调」到「工具约束流程」

当Perforce这样的工具被引入时，带来的不只是技术上的变化，更是工作流程的变革：

• 你不用再问「谁在改这个文件」——工具会告诉你
• 你不用再害怕「误删除」——每一个版本都在历史记录里
• 你不用再为「回不去了」而崩溃——随时可以回退到任意版本

但这种转变也遭遇了「水土不服」。很多早期开发者觉得版本控制太麻烦，不如直接用共享文件夹快。这也是为什么Perforce的推广不是一蹴而就，而是经历了多年的「文化渗透」过程。

每日构建习惯的普及

版本控制系统的普及还催生了另一个重要习惯：每日构建（daily build）。

一旦代码和资产都在版本控制里，你就可以自动化地每天构建一次游戏——这样你可以确保：

• 今天提交的代码没有破坏编译
• 最新版本的游戏是可玩的
• 任何人都可以拿到当前「最新的可玩版本」

每日构建是持续集成（CI）理念的前身，而CI在今天已经是标准游戏开发流程的一部分。

为什么游戏开发需要专门的版本控制

Perforce针对游戏开发的特点做了很多设计：

• 二进制文件支持——游戏开发中有大量美术、音频资源，传统版本控制对这些处理很差
• 大仓库支持——Perforce可以处理数百GB甚至TB级的仓库，这对游戏项目是必须的
• 文件锁定机制——避免两个人同时改同一个二进制文件导致冲突
• 性能优化——即使是巨大的文件，传输速度也足够快

工程化是否压制了创作自由度？

一个至今仍在讨论的问题是：工程化管理工具的引入，是否让游戏开发变得更「流水线化」，从而压制了小团队时代的创作自由度？

这个讨论至今没有统一答案。不过有一个事实是：即使是今天的独立开发者，版本控制也已经是标配了——不是因为有人强迫，而是因为「不小心搞坏东西但没备份」的痛苦实在太深刻了。

从这段历史带走的三件事

本词条的下一步

我们计划补充：

• 具体工作室的工具迁移案例——比如Valve从共享文件夹转向Perforce的过程
• 早期技术美术（TA）岗位如何在这次转型中诞生
• Perforce与现代Git工作流的对比与互补

如果你有相关经验或见解，欢迎在议事厅讨论！