すべてのゲームを際立たせるために不可欠な4つのデブオプス・プラクティス
ホットフィックスから迅速な反復とリリースへ。
導入
リリースの数カ月前から週60時間労働？一晩中コードを書き続け、週に数回、奇跡のバグフィックスを提供する？文字通り発売直前になって、思いつきで機能を追加するのか？
この業界は、クランチ・クランチ・クランチの繰り返しで悪名高い。そして、あなたはそのクレイジーさで成功する人かもしれない。しかし、年度末にその見返りがないのであれば、自問自答せざるを得ない。
もしかしたら、主要な開発者の一人が、発売を延期して辞めてしまったのかもしれない。もしかしたら、徹夜明けの体調不良が連鎖反応を引き起こしたのかもしれない。もしかしたら、土壇場でテストが不十分だった機能が、プロジェクト全体を崩壊させる恐れがあったのかもしれない。具体的なシナリオがどうであれ、ひとつだけはっきりしていることがある：あなたは何度もここに来ている。
これらの戦術が価格に見合わないと感じるなら、それはあなたの英雄的行為にもかかわらず、顧客が望むものを与えていないからだ。シェーダーをスクリプト化する能力、水をアニメーション化する能力、レベルを想像する能力、CDNを設定する能力などは、ゲーム・コミュニティに価値を生み出すために必要なことのほんの一部にすぎない。収益性の高いプロダクションへのキャズムを超えるために、より重要なスキルは、ファンのために素晴らしいゲームを提供するという一つの方向にエネルギーを向けるシステムとプロセスを適用することです。
スタジオをクランチベースのカオスから生産的で効果的なワークフローの土地へと変えるには、スマートなDevOpsの実践が必要だ。目標は、チームの最も貴重な資源である時間を取り戻し、実際に重要なことに取り組めるようにすることだ。
しかし、カリカリをなくすことで、実際にどれだけの時間を取り戻すことができるのだろうか？エレクトロニック・アーツのテクニカル・ディレクター、ジョシュ・ニックスドルフによれば、数年後である：「私のチームにとって、最も重要な指標のひとつは、節約できた労力年数です。それも、DevOpsの旅が進むにつれて指数関数的に増加し、DevOpsに初めて取り組んだ約20年の努力から始まり、今日では1000年を超えている。"
より合理的で意図的な開発プロセスに移行することで、チームはプレーヤーにより良い体験を提供できるようになり、より頻繁に提供できるようになります。本書では、ゲーム開発環境に特化した基本的なDevOpsの原則とプロセスを紹介し、円滑に稼働するスタジオの技術スタックに不可欠なDevOpsツールをいくつか紹介する。
なぜDevopsなのか？
ゲーム機の世代が変わるたびに、ゲーム開発はより複雑になっている。プレイヤーは、より優れたグラフィック、発売後の頻繁なアップデート、充実したサポートをますます期待するようになっている。ローンチ時にバグだらけだった場合、挽回するのは不可能ではないにせよ、非常に難しい。Xsollaのクリス・ヒューイッシュ社長がGamesIndustry.bizのインタビューで語ったように、「成功の積み重ねはいつでもできるが、失敗したローンチの灰の中から成長することはできない」。
選手の価値を最大化するためには、プロセスとツールを検証し、最適化の機会を特定することが不可欠だ。現在のワークフローで、長期にわたってゲームをサポートすることができるでしょうか？将来のプロジェクトについては？
スタジオ・チームは、開発者やアーティストがいかにして難易度の高い仕事をこなすかに注意を向けがちだ。しかし、この焦点の当て方は、プロセスへの理解を完全に見落としてしまいがちだ。例えば、プログラマーが頻繁に作業を中断してチェックすれば（DevOpsプロセス）、バグ修正に費やす時間は減る。
このプロセスへの理解なくして、スタジオは存続できない：
- 常にクランチモードで働く過重労働の開発者たち
- バグとネガティブ・フィードバックに悩まされるリリース
- 混乱した開発計画による不満の蔓延
- 全体的に無駄な努力
解決策は、開発サイクルを最適化し短縮するDevOpsプラクティスとツールを採用し、一貫してパフォーマンスの高いゲームを生み出すことだ。利点は挙げればきりがないが、いくつか紹介しよう：
- 開発者を反復作業から解放するプロセスの自動化
- 消極的ではなく積極的な意思決定
- 継続的なインテグレーションとデプロイメントにより、選手により質の高いコンテンツを提供。
- 過労、ストレス、燃え尽き症候群が大幅に減少
会計年度末の支払いは？より幸せなスタッフ、より幸せな顧客、より幸せな会計士。
必要不可欠な4つの実践
DevOpsエンジニアでなくても、開発環境でDevOps的なアプローチのメリットを得ることができる。一人の開発者であっても、これら4つのDevOpsに不可欠なプラクティスを理解するだけで、生産性を向上させることができる。
堅牢なバージョン管理：ほとんどすべてのプログラマーにとって、コードの変更をバックアップすることは、まばたきするのと同じくらい自動的なことだ。シンプルなコミットによって、作業は安全で、上書きされて失われることはない。しかし、ゲーム開発では、分散しているアーティストやその他の人々によって生成された、時には膨大な種類のアセットを管理・追跡する必要がある。このため、強力な機能を備えた完全なバージョン管理システムが必要となる。
ビルドの自動化（CI/CD）：継続的インテグレーション（CI）とは、1つまたは複数のソースからの作業を自動的に中央リポジトリにマージすることを意味する。継続的デリバリー（CD）とは、開発中に自動的に新しいビルドを作成することだ。自動化されたCI/CDパイプラインを実装することは、アジャイル方法論において確立されたベストプラクティスであり、ゲームをビルド、パッケージ、テストするための一貫した自動化された方法を提供する。
成果物の管理：バージョン管理システムによって管理されるコードや資産だけでなく、成果物には、ベースイメージ、ソフトウェアパッケージ、Helmチャート、メタデータ、その他付随するが重要なリソースなど、さまざまな依存関係が含まれる。アーティファクト・マネージャーは、アプリやゲームのビルドやデプロイに必要なあらゆるものを一元管理することで、バージョン管理を補完する。
頻繁な自動テスト：DevOpsのアプローチは、従来の開発者とQAのサイロを破壊する。例えば、開発者はコードを小さな塊に分けて書き、ビルドのためにメインのコードベースにプッシュする前に独自のテストを実施する。理想的には、このテストは継続的かつ自動化されたものである。リリース候補はより洗練され、QAチームはゲームのパフォーマンスをより深く掘り下げる。
1:堅牢なバージョン管理
マージによるコンフリクトと作業ロスを最小限に抑える
アーティストとプログラマーが常に対立していたり、マージの衝突によって冗長な作業や失われた作業が生じたりする場合、バージョン管理がその原因であることが多い。ゲーム開発環境でバージョン管理のベストプラクティスを適用するには、独自の機能を備えたシステムが必要だ。
実用的に言えば、コードファイルは長さに関係なく小さい。しかし、次世代ゲーム機やPCゲームのグラフィックは比較的巨大になる可能性があり、ネットワーク帯域幅が重要な要素となります。中央リポジトリからこれらのアセットをプルしたりプッシュしたりするのは、他の開発アセットと同じように迅速かつ簡単でなければならない。
ほとんどのバージョン管理ソリューションの最大の問題点は？ユーザビリティ - すべての人に。
プログラマーは通常、コマンドラインインターフェイスや複雑なバージョン管理の分岐テクニックに長けているが、アーティストは単に「保存」を何度も押すだけでは難しいと感じるかもしれない。しかし、彼らのドローイングやアニメーションは、コードベースと同様に最終的なパッケージにとって非常に重要である。
ゲーム開発のバージョン管理システムは、開発者に複雑で詳細なオプションを提供しながらも、技術的な知識のないユーザーにも非常に使いやすいものでなければならない。そうでなければ、エンジニアはシステムの仕組みを何度も何度も説明することに時間を費やすことになる。
直感的でグラフィックなUIは、異なるプラットフォーム向けの異なるレベルやバージョンで同時に作業しているプログラマー、アーティスト、デザイナーとの複雑な分岐や結合の調整をはるかに容易にする。
トレーサビリティとは、アセットがいつ、どこで変更され、どのブランチで使用されたかを正確に把握できることを意味し、QAチームにとっても重要な機能です。さらに、リポジトリ、ブランチ、ラベル、パスのすべてにわたって十分なセキュリティを確保することが最低条件だ。
2:ビルド自動化（CI/CD）
複雑なパイプラインやツールの管理時間を減らし、作成に時間をかける
すべてのDevOpsプラクティスの一貫したテーマは、作業を小さな塊に分解することだ。小さなユニットは扱いやすく、テストも簡単で、最適化も早い。また、壁にぶつかったり、方向転換を決めたりしても、無駄な努力を最小限に抑えることができる。
ゲーム開発では、自分の進行中の変更を他の人の変更と頻繁にマージし、新しいビルドを作成することになる。手作業でビルドを作成するのはそれほど複雑な作業ではないが、他の作業の邪魔になるし、かかる時間もすぐに増えてしまう。繰り返しになるが、他の多くのDevOpsプラクティスと同様、自動化が鍵となる。
自動ビルドパイプラインはバージョン管理システムと連携し、変更を監視し、コミットごとに、あるいは変更数が特定のしきい値を超えたときに新しいビルドを作成します。つまり、開発者は物事が手に負えなくなる前に、早期に、そして頻繁に欠点を発見し、修正することができる。コードとアセットをより信頼性の高い、リリース可能な状態に保つことができる。何らかの理由で変更をロールバックする必要がある場合、最後に成功したビルドがすぐに使える。さらに、他のチームも簡単にビルドにアクセスしてアップデートを行い、タイムリーなフィードバックを与えることができる。
文化的に、自動化を構築するためのDevOpsアプローチは、チームの優先順位を、新しい機能に飛びつく前に自分たちの仕事が正しく行われていることを確認することにシフトさせる。長いスプリントをして疲れ果てて倒れるのではなく、小さな成功を積み重ねながら少しずつ前進していく。自信がつくし、自分のコードがまだ完成していなかったために、他の人の仕事を脱線させる可能性を大幅に減らすことができる。
3:アーティファクト管理
ゲームを必要なところに持っていく
CI/CDシステムが新しいビルドを作成した後、通常、ビルドを成果物リポジトリにプッシュし、そこで成果物マネージャーがすべての依存関係やその他の必要なコンポーネントと一緒にビルドを登録する。これらの「その他の必要なコンポーネント」をオーケストレーションすることが、ゲーム開発のDevOpsにおいて成果物管理が重要なプラクティスである理由だ。
アーティファクトは、社内の開発者、契約アーティスト、オープンソースコードのパブリックリポジトリなど、あらゆるソースから得ることができる。アーティファクト・マネージャーは、バージョンや承認のチェック、セキュリティ問題のスキャンなどを行いながら、重要なコンテンツがすべてアップロードされ、アーカイブされるようにするものだ。失敗の可能性はたくさんある。
もちろん、有用な成果物管理システムには最低限の要件がある。ライセンスに基づくバージョニングとフィルタリングをサポートするために、メタデータを管理できなければならない。どのコンテンツをどれだけの期間保持するか、開発者が設定できるようにする必要がある。そして重要なことは、ダウンタイムを避けるために高可用性システムとして構築されなければならないということだ。
単にS3バケットをプロジェクトリポジトリとして指定するのに比べ、本物のアーティファクトマネージャーを実装することにはかなりの利点がある。つまり、すべてのプロジェクト・リソースを共通のライブラリで管理することで、特にアーティストとエンジニアのコラボレーションが強化されるのだ。すべてのリソースは登録され、追跡可能であるため、予測可能で再現性のあるビルドが可能になる。そして、チーム全員がデプロイメントの管理から解放され、コーディング、アニメーション、デザインなど、それぞれが得意とすることができるようになる。
4:頻繁な自動テスト
フィードバックに対応し、機敏に働く
2つの原則が、QAに効果的なDevOpsプラクティスを形成している：
開発初期の頻繁なテスト
自動化されたQAワークフロー
大工は2度測って1度切る。言い換えれば、彼らは長さの変数を解き、次の製造ステップに進む前に、自分たちの仕事をテストするのである。開発者は、コードブロックを短く書き、さらに書く前にダブルチェックすることで、まったく同じことができる。開発者とQAの境界線が曖昧になる。
開発者による頻繁なコードチェックは、ビルドが自動テストされることで実を結ぶ。コンパイラーが新しいビルドをリポジトリにプッシュするたびに、それがテストされる。継続的に自動化されたテストがあれば、バグが開発期間を超えて本番コードで問題を起こす可能性はかなり低くなる。そして、生き残ることができたとしても、それほど病原性は強くないだろう。
とはいえ、バグが起こることは誰もが知っている。自動化されたQAテストに付随するのは、テストプロトコルからの自動化されたレポートであり、ゲームが市場に出た後は、そのゲームが動作しているデバイスからの自動化されたレポートである。QAまたはユーザーのインストールで異常が発生するとすぐに、システムが特定のクラッシュおよび例外データを報告し、迅速な修正を可能にします。多くの場合、問題はエンドユーザーにはまだ見えず、目立った不具合として表面化する前に修正可能である。
ゲーム開発環境におけるDevOpsプラクティスの中でも、頻繁な自動テストは最も重要かもしれない。プレイヤーは定期的に新しいコンテンツを求めており、スタジオは画期的な新機能を搭載して発売日に間に合わせるという大きなプレッシャーにさらされている。しかし、一人の重要なインフルエンサーが、悪い日の上に悪い経験をすれば、その影響は壊滅的なものになる。QAを正しく行うことは必須である。
ゲームスタジオの成功
DevOpsとアジャイルのプラクティスは、大部分は常識的な仕事の習慣にすぎない。しかし、複雑なコード、何千ものアセット、容赦ないパフォーマンス制約を伴うゲームに適用する場合、スタジオには、綿密なソース管理、継続的インテグレーションとデリバリー、安全でセキュアな成果物管理、頻繁な自動テストを保証する専用のDevOpsツールが必要になる。
開発プラットフォームと緊密に統合されたDevOpsツールを使用することで、その効果はさらに高まる。以下は、ワークフローを改善し、魅力的なゲームを制作するために、DevOpsツールのライブラリが増えているUnityクリエイターのほんの一部です。
スタジオAlta
UnityのTwitchチャンネルで行われたCreator Spotlightで、AltaはUnity Version Control（旧Plastic SCM）を使用してリリースサイクルを高速化し、大規模で成長中のファンベースに定期的なコンテンツアップデートを提供する方法を紹介した。「ソース管理にはPlastic SCMを使っています。アルタのゲーム・ディレクター、ボラミー・ウンは言う。「機能ごとに新しいブランチを作り、各機能の中でリスクのある取り組みがあれば、サブブランチを作る。
スタジオKO_OP
KO_OPはモントリオールを拠点とする共同所有のゲームスタジオです。彼らは、最新プロジェクト『グッバイ・ヴォルケーノ・ハイ』の制作にあたり、アーティストとエンジニアの間の障害を取り除くバージョン管理ソリューションを探していた。「KO_OPの開発者であるJacob Blommestein氏は、Unityのケーススタディで「Gluon（Unityバージョンコントロールのアーティストワークフロー）は嬉しい驚きでした。「アーティストたちは、分岐やマージについて何も知る必要はなかった。彼らは.psdファイルを追加しただけで、バージョン管理は透明だった」。
スタジオサイコフォージ
Unityブログのインタビューで、CEOのMichela Rimensberger氏は、Sycoforgeとそのコミュニティが協力して野心的なゲーム『Return to Nangrim』を実現するために、Unityバージョン管理がどのように役立っているかを語りました。「技術的な観点から言えば、Unityバージョン管理はコラボレーションの救世主です。「さまざまなバージョン管理ツールを試しましたが、どれもゲーム開発会社のニーズに合っていないことにすぐに気づきました。プログラマーが使えるものもあれば、アーティストが使って汗をかくものもあった。バージョン管理で、私たちは真のゲーム・チェンジャーを見つけた。ノンプログラマーにもプログラマーにも使いやすい。"
スタジオクリプティック・スタジオ
パーフェクトワールドの子会社であるクリプティック・スタジオは、バグやエラーの追跡を自動化するためにBacktraceを使用している。「Backtraceは、クラッシュデータの探索と利用方法を変えました」と、Cryptic Studiosのシニア・プロデューサーであるブレント・ラムは、今年発表されたUnityの電子書籍の中で述べている。"誰もが安心してクエリーを実行し、我々のゲームの健全性を理解している"
今すぐ使用を開始する
UnityのDevOpsソリューションでワークフローをスピードアップし、DevOpsツールチェーンを構築しましょう。より効率的に作成し、期待通りの品質で、時間通りに市場に投入する。解決策はこちらから。
