最近讨论我们的版本编译及发布过程时，让我想起了最初要给发布更新时的悲催情形。
2001年，虚幻引擎2发布的初期，Epic的程序员不到十人，那时我们使用Visual Source Safe，而且我本人就己是官方的编译机器，要在我自己机器上编译二进制文件，并将它们放到共享的网络硬盘上。
我们通过所谓的codedrop压缩文件将引擎发布给开发者。这不仅笨重，还有一个主要的问题是：由于我们尝试发布功能时出现的错误偶尔会导致时间间隔，而这意味着如果预计发布的功能出错，那么整个发布及所有其他功能也会出错。功能越大，版本发布的间隔时间就越长，并且大家对它的期望也更高。
其中有这样的错误和虚幻引擎2的材质系统有关，那个材质系统和现有材质系统是完全不同的，那是我们首次尝试为美术人员在该领域提供很多控制。我们在2002年度游戏开发者大会上的演示就是一个很好的示例，该示例在十二年前就可以通过这个材质系统完成。您可以自己在 这里 查看， 您也可以看下虚幻引擎4开发者koola在2014年的版本（这里）中可以实现何种效果。这个创新是要付出代价的，因为所发布的材质系统在几个月后出现了错误，这意味着开发者处于非常不利的位置，由于材质系统还没有准备好，所以我们那时同时开发的其他功能也尚不能提供，那么开发者就不得不复制这些功能。
这个问题在Ubisoft的Jean-Francois Dube和Emilie Gauthier创作了一首歌来取笑我们的错误时，达到了顶峰。您可以在 这里. 听这首歌。对于我来讲，这永远是一个警钟，提醒我们再也不想看到自己处于那种境地。
这对于我们来说是一次重要的教训。这也是十年前我们改变方法，向开发者提供虚幻引擎3实时源码访问权并且每月提供稳定的经过QA验证版本（已经由QA部门测试并审查的版本）的主要原因。我们将这个每月发布版本的节奏也延伸到了虚幻开发工具包的发布过程，并且在整个虚幻引擎3生命周期中我们都一致坚持这一原则。
快速前进到了2014年，现在Epic Games有大约150位工程师。我们有巨大的版本和连续集成机制、各种分支等，但是有一件事却一直没有改变，这就是我们希望消费者可以实时地访问我们在正在制作的内容，让我们的版本发布、测试进度和状态更加透明。
我们深信，实时访问同定期(每隔6到8周)发布具有质量保证的版本相结合，是保证良好用户体验的重要组成部分。