ビルドに関する最新のディスカッションでは、デベロッパーにアップデート提供について、当初は今よりずっと慎ましいものでった頃を思い出していました。
2001 年の Unreal Engine 2 初期の頃は、エピック社に居たプログラマーは 10 人にも満たず、Visual Source Safe を使い、オフィシャル さらにはビルドの構築用マシンが私のパソコンで、コンパイルされたバイナリを私のマシンでローカルにまたは共有されたネットワーク ドライブ上に保存していました。
当時エンジンのデベロッパーへの配布は「コードドロップ」という ZIP ファイルで行っていました。そもそもが優雅とは言えないやり方でしたが、一番の問題は私達がエンジンへの仕様追加に合わせて不定期にリリースを行うという誤った方法を取っていたという点です。つまり予定されていた仕様が延期される事が決定されると、リリースそのものも延期されていました。そして仕様が大きいものであればあるほど、リリースを待つ期間が延び、また期待度も増していきました。
このような延期が、Unreal Engine 2 のマテリアル システムでした。これは当時の既存マテリアル システムから大きく離れた革新的な物であり、この領域におけるコントロールをアーティストに提供しようという私達の初めての試みでした。当社の 2002 GDC デモは、十二年前にこのマテリアル システムを使って実現できた事の良い一例です。こちらで実際に観ていただき、またこちらの 2014 年版 Unreal Engine 4 developer koola で実現出来た内容の動画と併せて参照していただけたらと思います。
しかしこのイノベーションは代償を伴っていました。マテリアル システムが数か月延期された結果、当社でも開発中だったその他機能 (マテリアル システムの用意が出来ていなかったために提供できなかったもの) をデベロッパーの方々が複製しなければならないという、非常に残念な状況になってしまいました。
そのおかげで Ubisoft 社の Jean-Francois Dube と Emilie Gauthier に私達の延期を茶化す唄が作られてしまいました。ちなみに、この歌はこちらからお聞きいただけます。この一件は私にとって、二度と置かれたくない状況というものを常に思い出させてくれるものとなりました。
当社にとっても多くを学ぶ機会となり、Unreal Engine 3 でリアルタイムでのソース アクセスを提供し、「QA ビルド」(当社エンジン QA 部門が確認し承認したビルド) と呼ばれる毎月の安定版ビルドを提供するという、およそ十年前の転換を行った大きな理由の一つでした。この毎月リリースの形式は Unreal Development Kit のリリース時にも採用し、Unreal Engine 3 のライフサイクルを通して使用され続けました。
そして時間を 2014 年へと飛ばしてみると、エピック ゲームズではおよそ 150 名のエンジニアが働いています。現在、巨大なビルドと継続的なインテグレーション用の部署、様々な部門などが動いています。ですが一つだけ、当社のリリース、テスト手順およびステータスに関する透明性を与えるために、お客様にライブ アクセスを提供したい、という願いは今も変わっていません。
ライブ アクセスと頻繁な品質管理部門に承認されたリリース (6～8週間毎) の組み合わせは、素晴らしい顧客体感を生み出す重要なコンポーネントであると、弊社では強く感じています。