ゲーム開発環境の自動化

ゲーム開発環境の自動化

• 1.
  ゲーム開発環境の自動化 alwei (@aizen76)
• 2.
  今日はGDC 2011で開かれた、 「Automated TestingRoundtable」という 議事録内容を有志が日本語訳してくれたものを 部分的に紹介していこうと思います。 原文は以下にあります。 http://wiki.igda.org/GDC_2011_- _Automated_Testing_Roundtable
• 3.
  注意点として、あくまでも参加者の 一人がメモしていた議事録の内容なので、 決して正確な情報ではない可能性があります。 また訳も決して正しいわけではないので、 そのままの内容で鵜呑みしない方が たぶんいいと思います。
• 4.
  1日目のトピック テストについての話 具体的に何が有効でその理由とは? 出席者のほとんどはプログラマ。 しかし少数のQAと生産の人もいた。
• 5.
  シンプルなテスト、スケジューリング ・既存プロジェクトのテストを始める場合はユニット テストよりも基本的な機能テストを好む。 ・明確な「ホットスポット」を見つける。プロジェクト特 有の複雑な部分に注目する。 ・既存システムを活用する：ゲームプレイと記録の 再生ができ、追加のマトリクス情報を生成する。
• 6.
  シンプルなテスト、スケジューリング ・TTY(標準出力)出力をパース、もしくは既存の TTYログシステムに更に出力を追加して、すぐに最 初のテストをブートストラップします。 ・「ゲームがロードされているか?」「それぞれのレベ ルがロードされているか?」というスモークテストか ら始める ・視覚的なスクリプトシステムは小さなテストを行う ために素晴しい環境です。
• 7.
  シンプルなテスト、スケジューリング ・単純な通過、失敗レポートは基本テストとしては 十分です。 ・変更をコミットする前にテストを実行するスタジオ もあります。ローカル版テストはよりフル機能に対 応したものと比べて幾分取り除かれているとしても 有益です。
• 8.
  シンプルなテスト、スケジューリング ・テストは、オールオアナッシングではない。すぐに やらなくてはならない（コミット前、かコミット後）もの と、猶予のあるテスト（デイリーでスケジュール化さ れたもののように）両方ある。ビルドイテレーション 時間を大きく遅​らせるようなものは後でやるべきで す。 ・「失敗を期待」するテストもいくつかのケースで有 用です。
• 9.
  シンプルなテスト、スケジューリング ・バージョン管理システムのセットアップやレイアウ トは重要だ。それは自動化が容易になるか難しくな るかに影響する。 ・多くの人はCI(継続的インテグレーション)ビルド サーバーか、テストスイート管理システムを使用し ているでしょう。
• 10.
  テストツール ・TeamCity ・Pulse Continuous IntegrationServer ・Hudson(forked to Jenkins) ・CruiseControl.NET ・Buildbot ・Bitten(automated metrics collection for Trac) ・Cucumber(behavior-driven testing) ・BugSplat(drop-in crash tracking)
• 11.
  テストツール ・ゲームにコマンドラインパーサーを組込む事は役 に立ちます。例えばCIビルドが「rungame.exe alltests」のようにビルド後のステップを実行する事 が出来ます。
• 12.
  入力の扱い ・入力の記録、運用、プレイバックをうまく使おう。ラ ンダムにボタンを押したりランダムな方向に向かっ て動く「モンキー」は少なくともいくつかのチームで は使われています。 ・もしランダムに歩かせるボットが動きをとれなく なったら、前のゲーム実行の「ヒートマップ」を使っ て頻繁に移動している場所にテレポートして戻す。 その時厄介な場所としてレポートを残し、テストを 継続します。
• 13.
  入力の扱い ・テスターの入力ストリームをそのまま記録する チームもある、そしてそれを自動テストで再生す る、成功して完走するか失敗、クラッシュするかを チェックする。 ・ゲームやUIの頻繁な変更に伴いこれらの入力ス トリームが「古く」なる場合があります。そして再レ コーディングするオーバーヘッドもあります。(このタ イプのテストはオーバーヘッドが大きすぎるという 人もいます)
• 14.
  レポートと履歴 ・内蔵のツールで行動履歴を記録します。バグやク ラッシュレポートも一緒に記録します。 ・グラフは報告された情報を理解するのに大いに 役立ちます。相関グラフにより個々のリビジョンと 時間経過によるトレンド/差異にフォーカスしたエン トリーを見る事が出来ます。
• 15.
  レポートと履歴 ・ソークテスト(1日から2週間ほど継続する)を行え ばリークやその他の問題をグラフ化する事が可 能。 ・スモークテストやソークテストのために、メモリ使 用、FPS、GPUステート(ポリゴン数等)、ゲームプ レイに関するイベントやバランス調整に関する統計 情報等を記録する。
• 16.
  テスト環境 ・環境のスナップショットはテストのための一貫性 のあるOSやソフトウェアスタックを構築したり維持 するのに有用です。VM Wareを使ってこれを実現 している人もいます。 ・Valgrind、Bounds Checker、Insure++といった ツール専用の環境はスケジューリングされたテスト に追加して走らせるのに良い場所です。
• 17.
  テスト環境 ・debugビルド、releaseビルド等の特別なビルドの 違いには慎重になるべきです。特別なビルドはバ グをより一層生成するし、クレイジーなバグは特別 な事をしていないビルドでしか浮き上がってこな い。debugビルドはreleaseにログ機能を付けるだ けであるべき、と断言する人もいました。
• 18.
  アンチパターン、避けるべき事 ・ユニットテストのカバレッジを100%にしようとする 人がいるが、大体の人の意見はそれは努力の無 駄遣いだと言う傾向にある。いくつかの機能テスト により十分テストされているから。 ・ユニットテストがフィットしているとしても、よく似た 機能テストを作成して走らせた方が往々にして早 い。他の全てが同じようにユニットテストが好ましい としても。
• 19.
  アンチパターン、避けるべき事 ・チューニングのために改造されたビルドからデー タを使用する場合、何かが変わった時に深刻な問 題が発生する。 ・可能であればベータ、実験、未熟なツールとコン ポーネントは「ビルドや自動テスト内で使うのを、お そらく一般使用も」避けるべきだ。
• 20.
  アンチパターン、避けるべき事 ・モックオブジェクトはそれらの価値から得られるも のよりも大体の場合、維持のトラブルがある。 ・ことわざ「Process and peoplemake all the difference」「ひとそれぞれ、プロセスもそれぞれ」
• 21.
  ボット ・ランダムウォークに関しては入力の扱いに関して で既に述べられた通り。 ・優秀なプレイヤーをシミュレートして、ゲーム内経 済においてバランス崩壊する変更が露呈するのを テストします。
• 22.
  静的コード解析 ・意見が分かれました。検出のノイズ比率の問題で ほとんどの人は静的解析をお勧めしませんでし た。 ・当然、非コンパイル言語に対するランタイムチェッ ク前のある程度のソートには使っている。(Python のようなスクリプト言語)
• 23.
  静的コード解析 ・昔ながらのやりかたでの追跡か既存の静的解析 ツールかカスタムツールで良いので違反を検知し ましょう。あなたがどんなコードを書いているかを知 るために「スマートコメント」を使ってこれらのチェッ クをバイパスします。 ・静的解析は64bit移植問題を修正する時にかなり 役立ったという人もいた。
• 24.
  静的コード解析 ・レガシーなコードをベースに作業する場合、検出 とノイズの割合を調整して走らせる事で、差異に対 してのみレポーティングする事が出来ます。 ・コンパイラの警告は出来る限り大きくしておくべき です。そして「警告をエラーとして扱う」ように出来 るだけしておく。
• 25.
  2日目のトピック 主にインフラ回り 誰がデプロイや自動化を保持するか? そしてどんなツールやプラクティスを使っているの か?
• 26.
  内製vsサードパーティー ・出席者の75%以上は内製のカスタムビルド&テス トソリューションを使用している。 ・統合と自動化のメンテナンス時間がキーに。その 自動化システム自体がテストされていない、という 事はよくあります。自動化テスターが割り当てられ たチームもある。買う余裕のないところもある。
• 27.
  サードパーティツール ・Hudson(forked to Jenkins) ・TeamCity ・JIRA ・FishEye
• 28.
  テレメトリー ・Emailは万国共通 ・アサートや警告ログをレポートする ・メモリ状況をグラフ化する ・何かをグラフ化する時は履歴のデータに対応した 「現在のスナップショット」を見せるようにする。特に メモリ。
• 29.
  テレメトリーツール ・Confluence ・SQL Server ReportingServices ・Callgrind ・Tableau
• 30.
  テレメトリー ・ビルド毎にテレメトリーを収穫する。定期的にも実 行する。そしてそれぞれについて見れるようにす る。 ・Callgrindを使って5分毎のゲームのデータを集め ているチームもあった ・全ての可能な武器vsゾンビの組み合わせに対し て、ヒット数、ダメージ、誰が勝つかを試すとか
• 31.
  テレメトリー ・テスト中に獲得した全ての「達成」を記録する。 ・プレイ時間を記録する(QA側のチェックはこの方 法で出来る) ・テレメトリーツールは重要
• 32.
  テレメトリー ・アクションと完了までにかかった時間を記録。 ・ビルド時の追跡データを残す ・データを集めるために1つの簡単なグローバス データベースとWebサービスを使う。 ・スクリーンショットを撮る ・クラッシュした時やバグレポートが提出された再 にログとスクリーンショットをアップロードする
• 33.
  統合、メンテナンス ・出席者の15%はユニットテストを使ってじる。同じ く15%の出席者は機能テストも行なっている ・自動化の維持を任せる事が出来る人々という新 しい特徴の情報を得る事が難しいというチームも いる。 ・自動でテストケースを作ると、失敗を沢山作ってし まう傾向がある。
• 34.
  統合、メンテナンス ・スクリーンショットを撮る。これは人によって素早く 検証出来るし、ピクセル毎の比較にも使える。 ・イメージのdiffをとるツールにPerceptualDiffとい うものがある。 ・ボットはゲームを旋回する中でスクリーンショット を撮るべきだ。
• 35.
  統合、メンテナンス ・レンダリングのテストにはシンプルなボックスかス ケルトンにレンダーしてそれらの画像比較を行う。 推進するほどの価値はないかもしれない。 ・いつテストするか?ビルドが壊れた時、バグの起 こった時毎、機能追加する時等。
• 36.
  応答時間 ・シーケンシャルなステップを必要とするテストはや りたくないという人もいた。ターンアラウンドタイム (応答時間)は早く修正も早いので気にするほど長く はないという人もいた。 ・多くのチームはインクリメンタルデータビルドとビ ルドサーバーでフルコードビルドを行う。1日に1 回、データとコアのビルドをクリーンにする。
• 37.
  応答時間 ・コードのビルド時間は一般的には早い。ほとんど の人はフルコードビルドは数分で終わると答えた。 しかし40分や1時間と答えた人もいた。分散ビルド をしているのにも関わらず。 ・空いているコンソール(Xbox等)を確認してテスト スイートを日和見的に走らせる。 ・自動テスト専用のハードウェアがあるのは一般的 です。
• 38.
  プレゼンテーション ・結果を1日に1回か2回は出力する。 ・結果は探させるよりユーザに提示しよう。しかしや りすぎは良くない。 ・ユーザには自発的に頻繁にソースをプッシュする 事を許可するようにしましょう。 ・テストやビルドの失敗はすぐに関係者に通知する ようにしましょう。
• 39.
  プレゼンテーション ・データはビジュアルに見えるようにした方が好ま れる(vs テキスト表示) ・シンプルなビジュアル化を使おう。例、赤と緑の ドット、概要が簡単に掴めるように。 ・ビルドフェイズ毎のエラーレポート。それぞれのビ ルドエラーをタイプ毎に分ける事が出来、コードの エラーかスクリプトのコンパイルエラーかを切り分 ける事が出来る。
• 40.
  プレゼンテーション ・Pythonといったスクリプト言語を書く事を恐れて はならない。ビルドログや特定のエラーに興味を持 たせ、「宣伝」するために。 ・最新のレポートは誰でも読めるようにしておこう。 可能なら、基本的な修正方法の概要と詳細へのリ ンクを含める。
• 41.
  通知方法 ・Email ・yammer ・tumblr ・growl ・the famous GitHubtraffic light ・siren(本物のサイレン) ・TV monitor(広く見える場所に)
• 42.
  通知方法 ・To/Ccのリストは最小限に。人数を少なくすれば するほど効果的。通知された失敗に一定時間対処 されない場合、それを上司やプロデューサ、マネー ジャに「宣伝」する。 ・シンプルだが容赦なく効果的。ビルドが失敗した 場合にはコミットを拒否する。
• 43.
  分散ビルド 以下のサードパーティ製ツールが挙がった ・SN-DBS(Sony platforms) ・IncrediBuild
• 44.
  分散ビルド ・分散アセットビルドのためにIncrediGridを使おう としている人もいた。 ・一般的に分散ツールよりもマルチコアスケーラブ ルツールの方が好まれる模様。構築とメンテナン スの容易性、もっとわかりやすいのは、変なやり方 をしても壊れにくい点。
• 45.
  分散ビルド ・ビルドシステムはより多くのコアでより信頼出来る 1つ以上のドライブを使用するべき。これらは最 近、他のほとんどのものよりも重要であるように思 われる。 ・ユニットテストを分散しよう。1例として6分かかる ものが40秒になった。
• 46.
  VCS(バージョン管理システム) 何を使っていますか? ・Perforce 60% ・Subversion 20% ・Git少しだけ かなりおおよその割合。 向こうではPerforce派が圧倒的な模様。
• 47.
  3日目のトピック データ収集 マイニング 可視化等について
• 48.
  アサーション ・およそ5チームではアサーションが完全に禁止さ れていた。 ・データが正しいフォーマットであるかどうかを検証 するためにアサーションを広範囲に使用している 人もいる。 ・出来るならアサート時にコールスタックもとれるよ うに!!
• 49.
  アサーション ・実行フローを継続させる事が出来る「スキップで きるアサート」を使っている人もいる。 ・ボットにトリガーされた全てのアサーションを記録 するようにしている。 ・ユーザのプレイを通してスキップされたアサーショ ンはサーバにサポートされる。(ユーザ名も一緒に)
• 50.
  アサーション ・似たような感じで「全ての事前、事後状態をテスト する」ためにアサーションを使う。 ・アサーションは「アーティスト(デザイナー)フレンド リー」であるべき。人間が読める記述と修正のため の指示やリンクを含める。 ・アサートにグループによるタグ付け(マクロを使っ たりして)をする。自動的に修正出来る人にレポー トする。
• 51.
  アサーション ・アサーションの統計をとる。これによりバグの多い システムを識別する事が出来る。 ・出来るだけ、通常のスキップ可能なアサートと致 命的なアサートを切り分ける。 ・アサートを使用するチームの約10%は稼動させ る時に無効にしない。 ・アサートは「アルゴリズムのエラー用」に限定し、 全てのデータエラーのケースは別のコードで扱う人 もいる。
• 52.
  ゲームシステムの上位層のテスト ・ゲームプレイ中の指示(メッセージストリーム等)を 簡単にもしくは自動的に記録するようにする。QA は記録されたストリームを取り出しスクリプトから使 う事が出来る。シーケンスの記録のスタート、ストッ プが簡単に出来るように作っておくべき。 ・入力とゲームプレイメッセージを記録する事は ゲームを一意に決定するのを助ける事が出来る。
• 53.
  ゲームシステムの上位層のテスト ・非現実的なパラメータが入ってきた場合、アサー トする。チート対策にも使える。 ・機能テストが失敗した時、もう一度同じ事が起こ るか試してみるのもあり。 ・あなたのAIはきちんと定義されたAPIがあるかを 確認してください。そして開発のスタート時に動か せる事を確認してください。このAPIを使用する事 により自動テスト出来ます。
• 54.
  ゲームシステムの上位層のテスト ・サーバをフレームレートを固定せずに実行出来る ようにした方がいい。(出来ればレンダリングの OFFも)これによりテストを速くする事が出来る。 ・テスト結果をSQL等に記録する。レポートのプロト コルやデータベースのセットアップに過剰装飾して はいけない。そんなに価値はない。
• 55.
  投資収益率 ・時間を記録する。通常の開発時間、自動化方法 の開発、メンテナンス時間、バグの修正時間を記 録する。一度自動化されれば減らすことが出来た バグの数やバグの修正時間が明らかになるべき。 ・一度だけの移植やDLCなどの「一度作って終わ り」のプロジェクトはスモークテストのようなシンプ ルな上位レベルの機能テストに注目する。ユニット テストに取り組むのはやめるべき。
• 56.
  十分vsやりすぎなテスト ・最初に再利用可能なコンポーネントをテストする のが良い。 ・他のシステムよりもまずゲームプレイのテストをし た方が良い。 ・壁を越えたコミュニケーションを促進しよう。デイ リースクラムかミーティングにQAの人を1人は連れ てこよう。