ゲーム開発環境の自動化

ゲーム開発環境の自動化 alwei (@aizen76)

今日はGDC 2011で開かれた、 「Automated Testing Roundtable」という 議事録内容を有志が日本語訳してくれたものを 部分的に紹介していこうと思います。 原文は以下にあります。 http://wiki.igda.org/GDC_2011__Automated_Testing_Roundtable

• http://wiki.igda.org/GDC_2011_-

注意点として、あくまでも参加者の 一人がメモしていた議事録の内容なので、 決して正確な情報ではない可能性があります。 また訳も決して正しいわけではないので、 そのままの内容で鵜呑みしない方が たぶんいいと思います。

1日目のトピック テストについての話 具体的に何が有効でその理由とは? 出席者のほとんどはプログラマ。 しかし少数のQAと生産の人もいた。

シンプルなテスト、スケジューリング ・既存プロジェクトのテストを始める場合はユニット テストよりも基本的な機能テストを好む。 ・明確な「ホットスポット」を見つける。プロジェクト特 有の複雑な部分に注目する。 ・既存システムを活用する：ゲームプレイと記録の 再生ができ、追加のマトリクス情報を生成する。

シンプルなテスト、スケジューリング ・TTY(標準出力)出力をパース、もしくは既存の TTYログシステムに更に出力を追加して、すぐに最 初のテストをブートストラップします。 ・「ゲームがロードされているか?」「それぞれのレベ ルがロードされているか?」というスモークテストか ら始める ・視覚的なスクリプトシステムは小さなテストを行う ために素晴しい環境です。

シンプルなテスト、スケジューリング ・単純な通過、失敗レポートは基本テストとしては 十分です。 ・変更をコミットする前にテストを実行するスタジオ もあります。ローカル版テストはよりフル機能に対 応したものと比べて幾分取り除かれているとしても 有益です。

シンプルなテスト、スケジューリング ・テストは、オールオアナッシングではない。すぐに やらなくてはならない（コミット前、かコミット後）もの と、猶予のあるテスト（デイリーでスケジュール化さ れたもののように）両方ある。ビルドイテレーション 時間を大きく遅​らせるようなものは後でやるべきで す。 ・「失敗を期待」するテストもいくつかのケースで有 用です。

シンプルなテスト、スケジューリング ・バージョン管理システムのセットアップやレイアウ トは重要だ。それは自動化が容易になるか難しくな るかに影響する。 ・多くの人はCI(継続的インテグレーション)ビルド サーバーか、テストスイート管理システムを使用し ているでしょう。

テストツール ・TeamCity ・Pulse Continuous Integration Server ・Hudson(forked to Jenkins) ・CruiseControl.NET ・Buildbot ・Bitten(automated metrics collection for Trac) ・Cucumber(behavior-driven testing) ・BugSplat(drop-in crash tracking)

テストツール ・ゲームにコマンドラインパーサーを組込む事は役 に立ちます。例えばCIビルドが「rungame.exe alltests」のようにビルド後のステップを実行する事 が出来ます。

入力の扱い ・入力の記録、運用、プレイバックをうまく使おう。ラ ンダムにボタンを押したりランダムな方向に向かっ て動く「モンキー」は少なくともいくつかのチームで は使われています。 ・もしランダムに歩かせるボットが動きをとれなく なったら、前のゲーム実行の「ヒートマップ」を使っ て頻繁に移動している場所にテレポートして戻す。 その時厄介な場所としてレポートを残し、テストを 継続します。

入力の扱い ・テスターの入力ストリームをそのまま記録する チームもある、そしてそれを自動テストで再生す る、成功して完走するか失敗、クラッシュするかを チェックする。 ・ゲームやUIの頻繁な変更に伴いこれらの入力ス トリームが「古く」なる場合があります。そして再レ コーディングするオーバーヘッドもあります。(このタ イプのテストはオーバーヘッドが大きすぎるという 人もいます)

レポートと履歴 ・内蔵のツールで行動履歴を記録します。バグやク ラッシュレポートも一緒に記録します。 ・グラフは報告された情報を理解するのに大いに 役立ちます。相関グラフにより個々のリビジョンと 時間経過によるトレンド/差異にフォーカスしたエン トリーを見る事が出来ます。

レポートと履歴 ・ソークテスト(1日から2週間ほど継続する)を行え ばリークやその他の問題をグラフ化する事が可 能。 ・スモークテストやソークテストのために、メモリ使 用、FPS、GPUステート(ポリゴン数等)、ゲームプ レイに関するイベントやバランス調整に関する統計 情報等を記録する。

テスト環境 ・環境のスナップショットはテストのための一貫性 のあるOSやソフトウェアスタックを構築したり維持 するのに有用です。VM Wareを使ってこれを実現 している人もいます。 ・Valgrind、Bounds Checker、Insure++といった ツール専用の環境はスケジューリングされたテスト に追加して走らせるのに良い場所です。

テスト環境 ・debugビルド、releaseビルド等の特別なビルドの 違いには慎重になるべきです。特別なビルドはバ グをより一層生成するし、クレイジーなバグは特別 な事をしていないビルドでしか浮き上がってこな い。debugビルドはreleaseにログ機能を付けるだ けであるべき、と断言する人もいました。

アンチパターン、避けるべき事 ・ユニットテストのカバレッジを100%にしようとする 人がいるが、大体の人の意見はそれは努力の無 駄遣いだと言う傾向にある。いくつかの機能テスト により十分テストされているから。 ・ユニットテストがフィットしているとしても、よく似た 機能テストを作成して走らせた方が往々にして早 い。他の全てが同じようにユニットテストが好ましい としても。

アンチパターン、避けるべき事 ・チューニングのために改造されたビルドからデー タを使用する場合、何かが変わった時に深刻な問 題が発生する。 ・可能であればベータ、実験、未熟なツールとコン ポーネントは「ビルドや自動テスト内で使うのを、お そらく一般使用も」避けるべきだ。

アンチパターン、避けるべき事 ・モックオブジェクトはそれらの価値から得られるも のよりも大体の場合、維持のトラブルがある。 ・ことわざ「Process and people make all the difference」「ひとそれぞれ、プロセスもそれぞれ」

ボット ・ランダムウォークに関しては入力の扱いに関して で既に述べられた通り。 ・優秀なプレイヤーをシミュレートして、ゲーム内経 済においてバランス崩壊する変更が露呈するのを テストします。

静的コード解析 ・意見が分かれました。検出のノイズ比率の問題で ほとんどの人は静的解析をお勧めしませんでし た。 ・当然、非コンパイル言語に対するランタイムチェッ ク前のある程度のソートには使っている。(Python のようなスクリプト言語)

静的コード解析 ・昔ながらのやりかたでの追跡か既存の静的解析 ツールかカスタムツールで良いので違反を検知し ましょう。あなたがどんなコードを書いているかを知 るために「スマートコメント」を使ってこれらのチェッ クをバイパスします。 ・静的解析は64bit移植問題を修正する時にかなり 役立ったという人もいた。

静的コード解析 ・レガシーなコードをベースに作業する場合、検出 とノイズの割合を調整して走らせる事で、差異に対 してのみレポーティングする事が出来ます。 ・コンパイラの警告は出来る限り大きくしておくべき です。そして「警告をエラーとして扱う」ように出来 るだけしておく。

2日目のトピック 主にインフラ回り 誰がデプロイや自動化を保持するか? そしてどんなツールやプラクティスを使っているの か?

内製vsサードパーティー ・出席者の75%以上は内製のカスタムビルド&テス トソリューションを使用している。 ・統合と自動化のメンテナンス時間がキーに。その 自動化システム自体がテストされていない、という 事はよくあります。自動化テスターが割り当てられ たチームもある。買う余裕のないところもある。

サードパーティツール ・Hudson(forked to Jenkins) ・TeamCity ・JIRA ・FishEye

テレメトリー ・Emailは万国共通 ・アサートや警告ログをレポートする ・メモリ状況をグラフ化する ・何かをグラフ化する時は履歴のデータに対応した 「現在のスナップショット」を見せるようにする。特に メモリ。

テレメトリーツール ・Confluence ・SQL Server Reporting Services ・Callgrind ・Tableau

テレメトリー ・ビルド毎にテレメトリーを収穫する。定期的にも実 行する。そしてそれぞれについて見れるようにす る。 ・Callgrindを使って5分毎のゲームのデータを集め ているチームもあった ・全ての可能な武器vsゾンビの組み合わせに対し て、ヒット数、ダメージ、誰が勝つかを試すとか

テレメトリー ・テスト中に獲得した全ての「達成」を記録する。 ・プレイ時間を記録する(QA側のチェックはこの方 法で出来る) ・テレメトリーツールは重要

テレメトリー ・アクションと完了までにかかった時間を記録。 ・ビルド時の追跡データを残す ・データを集めるために1つの簡単なグローバス データベースとWebサービスを使う。 ・スクリーンショットを撮る ・クラッシュした時やバグレポートが提出された再 にログとスクリーンショットをアップロードする

統合、メンテナンス ・出席者の15%はユニットテストを使ってじる。同じ く15%の出席者は機能テストも行なっている ・自動化の維持を任せる事が出来る人々という新 しい特徴の情報を得る事が難しいというチームも いる。 ・自動でテストケースを作ると、失敗を沢山作ってし まう傾向がある。

統合、メンテナンス ・スクリーンショットを撮る。これは人によって素早く 検証出来るし、ピクセル毎の比較にも使える。 ・イメージのdiffをとるツールにPerceptualDiffとい うものがある。 ・ボットはゲームを旋回する中でスクリーンショット を撮るべきだ。

統合、メンテナンス ・レンダリングのテストにはシンプルなボックスかス ケルトンにレンダーしてそれらの画像比較を行う。 推進するほどの価値はないかもしれない。 ・いつテストするか?ビルドが壊れた時、バグの起 こった時毎、機能追加する時等。

応答時間 ・シーケンシャルなステップを必要とするテストはや りたくないという人もいた。ターンアラウンドタイム (応答時間)は早く修正も早いので気にするほど長く はないという人もいた。 ・多くのチームはインクリメンタルデータビルドとビ ルドサーバーでフルコードビルドを行う。1日に1 回、データとコアのビルドをクリーンにする。

応答時間 ・コードのビルド時間は一般的には早い。ほとんど の人はフルコードビルドは数分で終わると答えた。 しかし40分や1時間と答えた人もいた。分散ビルド をしているのにも関わらず。 ・空いているコンソール(Xbox等)を確認してテスト スイートを日和見的に走らせる。 ・自動テスト専用のハードウェアがあるのは一般的 です。

プレゼンテーション ・結果を1日に1回か2回は出力する。 ・結果は探させるよりユーザに提示しよう。しかしや りすぎは良くない。 ・ユーザには自発的に頻繁にソースをプッシュする 事を許可するようにしましょう。 ・テストやビルドの失敗はすぐに関係者に通知する ようにしましょう。

プレゼンテーション ・データはビジュアルに見えるようにした方が好ま れる(vs テキスト表示) ・シンプルなビジュアル化を使おう。例、赤と緑の ドット、概要が簡単に掴めるように。 ・ビルドフェイズ毎のエラーレポート。それぞれのビ ルドエラーをタイプ毎に分ける事が出来、コードの エラーかスクリプトのコンパイルエラーかを切り分 ける事が出来る。

プレゼンテーション ・Pythonといったスクリプト言語を書く事を恐れて はならない。ビルドログや特定のエラーに興味を持 たせ、「宣伝」するために。 ・最新のレポートは誰でも読めるようにしておこう。 可能なら、基本的な修正方法の概要と詳細へのリ ンクを含める。

通知方法 ・Email ・yammer ・tumblr ・growl ・the famous GitHub traffic light ・siren(本物のサイレン) ・TV monitor(広く見える場所に)

通知方法 ・To/Ccのリストは最小限に。人数を少なくすれば するほど効果的。通知された失敗に一定時間対処 されない場合、それを上司やプロデューサ、マネー ジャに「宣伝」する。 ・シンプルだが容赦なく効果的。ビルドが失敗した 場合にはコミットを拒否する。

分散ビルド 以下のサードパーティ製ツールが挙がった ・SN-DBS(Sony platforms) ・IncrediBuild

分散ビルド ・分散アセットビルドのためにIncrediGridを使おう としている人もいた。 ・一般的に分散ツールよりもマルチコアスケーラブ ルツールの方が好まれる模様。構築とメンテナン スの容易性、もっとわかりやすいのは、変なやり方 をしても壊れにくい点。

分散ビルド ・ビルドシステムはより多くのコアでより信頼出来る 1つ以上のドライブを使用するべき。これらは最 近、他のほとんどのものよりも重要であるように思 われる。 ・ユニットテストを分散しよう。1例として6分かかる ものが40秒になった。

VCS(バージョン管理システム) 何を使っていますか? ・Perforce 60% ・Subversion 20% ・Git 少しだけ かなりおおよその割合。 向こうではPerforce派が圧倒的な模様。

3日目のトピック データ収集 マイニング 可視化等について

アサーション ・およそ5チームではアサーションが完全に禁止さ れていた。 ・データが正しいフォーマットであるかどうかを検証 するためにアサーションを広範囲に使用している 人もいる。 ・出来るならアサート時にコールスタックもとれるよ うに!!

アサーション ・実行フローを継続させる事が出来る「スキップで きるアサート」を使っている人もいる。 ・ボットにトリガーされた全てのアサーションを記録 するようにしている。 ・ユーザのプレイを通してスキップされたアサーショ ンはサーバにサポートされる。(ユーザ名も一緒に)

アサーション ・似たような感じで「全ての事前、事後状態をテスト する」ためにアサーションを使う。 ・アサーションは「アーティスト(デザイナー)フレンド リー」であるべき。人間が読める記述と修正のため の指示やリンクを含める。 ・アサートにグループによるタグ付け(マクロを使っ たりして)をする。自動的に修正出来る人にレポー トする。

アサーション ・アサーションの統計をとる。これによりバグの多い システムを識別する事が出来る。 ・出来るだけ、通常のスキップ可能なアサートと致 命的なアサートを切り分ける。 ・アサートを使用するチームの約10%は稼動させ る時に無効にしない。 ・アサートは「アルゴリズムのエラー用」に限定し、 全てのデータエラーのケースは別のコードで扱う人 もいる。

ゲームシステムの上位層のテスト ・ゲームプレイ中の指示(メッセージストリーム等)を 簡単にもしくは自動的に記録するようにする。QA は記録されたストリームを取り出しスクリプトから使 う事が出来る。シーケンスの記録のスタート、ストッ プが簡単に出来るように作っておくべき。 ・入力とゲームプレイメッセージを記録する事は ゲームを一意に決定するのを助ける事が出来る。

ゲームシステムの上位層のテスト ・非現実的なパラメータが入ってきた場合、アサー トする。チート対策にも使える。 ・機能テストが失敗した時、もう一度同じ事が起こ るか試してみるのもあり。 ・あなたのAIはきちんと定義されたAPIがあるかを 確認してください。そして開発のスタート時に動か せる事を確認してください。このAPIを使用する事 により自動テスト出来ます。

ゲームシステムの上位層のテスト ・サーバをフレームレートを固定せずに実行出来る ようにした方がいい。(出来ればレンダリングの OFFも)これによりテストを速くする事が出来る。 ・テスト結果をSQL等に記録する。レポートのプロト コルやデータベースのセットアップに過剰装飾して はいけない。そんなに価値はない。

投資収益率 ・時間を記録する。通常の開発時間、自動化方法 の開発、メンテナンス時間、バグの修正時間を記 録する。一度自動化されれば減らすことが出来た バグの数やバグの修正時間が明らかになるべき。 ・一度だけの移植やDLCなどの「一度作って終わ り」のプロジェクトはスモークテストのようなシンプ ルな上位レベルの機能テストに注目する。ユニット テストに取り組むのはやめるべき。

十分vsやりすぎなテスト ・最初に再利用可能なコンポーネントをテストする のが良い。 ・他のシステムよりもまずゲームプレイのテストをし た方が良い。 ・壁を越えたコミュニケーションを促進しよう。デイ リースクラムかミーティングにQAの人を1人は連れ てこよう。