ゲーム開発環境の自動化

ゲーム開発環境の自動化

alwei (@aizen76)

今日はGDC 2011で開かれた、

「Automated Testing Roundtable」という

議事録内容を有志が日本語訳してくれたものを

部分的に紹介していこうと思います。

原文は以下にあります。

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

注意点として、あくまでも参加者の

一人がメモしていた議事録の内容なので、

決して正確な情報ではない可能性があります。

また訳も決して正しいわけではないので、

そのままの内容で鵜呑みしない方が

たぶんいいと思います。

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移植問題を修正する時にかなり役立ったという人もいた。


・レガシーなコードをベースに作業する場合、検出とノイズの割合を調整して走らせる事で、差異に対してのみレポーティングする事が出来ます。

・コンパイラの警告は出来る限り大きくしておくべきです。そして「警告をエラーとして扱う」ように出来るだけしておく。


主にインフラ回り

誰がデプロイや自動化を保持するか?

そしてどんなツールやプラクティスを使っているのか?

内製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派が圧倒的な模様。


データ収集

マイニング

可視化等について

アサーション

・およそ5チームではアサーションが完全に禁止されていた。

・データが正しいフォーマットであるかどうかを検証するためにアサーションを広範囲に使用している人もいる。

・出来るならアサート時にコールスタックもとれるように!!

アサーション

・実行フローを継続させる事が出来る「スキップできるアサート」を使っている人もいる。

・ボットにトリガーされた全てのアサーションを記録するようにしている。

・ユーザのプレイを通してスキップされたアサーションはサーバにサポートされる。(ユーザ名も一緒に)

アサーション

・似たような感じで「全ての事前、事後状態をテストする」ためにアサーションを使う。

・アサーションは「アーティスト(デザイナー)フレンドリー」であるべき。人間が読める記述と修正のための指示やリンクを含める。

・アサートにグループによるタグ付け(マクロを使ったりして)をする。自動的に修正出来る人にレポートする。

アサーション

・アサーションの統計をとる。これによりバグの多いシステムを識別する事が出来る。

・出来るだけ、通常のスキップ可能なアサートと致命的なアサートを切り分ける。

・アサートを使用するチームの約10%は稼動させる時に無効にしない。

・アサートは「アルゴリズムのエラー用」に限定し、全てのデータエラーのケースは別のコードで扱う人もいる。

ゲームシステムの上位層のテスト

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

・入力とゲームプレイメッセージを記録する事はゲームを一意に決定するのを助ける事が出来る。


・非現実的なパラメータが入ってきた場合、アサートする。チート対策にも使える。

・機能テストが失敗した時、もう一度同じ事が起こるか試してみるのもあり。

・あなたのAIはきちんと定義されたAPIがあるかを確認してください。そして開発のスタート時に動かせる事を確認してください。このAPIを使用する事により自動テスト出来ます。


・サーバをフレームレートを固定せずに実行出来るようにした方がいい。(出来ればレンダリングのOFFも)これによりテストを速くする事が出来る。

・テスト結果をSQL等に記録する。レポートのプロトコルやデータベースのセットアップに過剰装飾してはいけない。そんなに価値はない。

投資収益率

・時間を記録する。通常の開発時間、自動化方法の開発、メンテナンス時間、バグの修正時間を記録する。一度自動化されれば減らすことが出来たバグの数やバグの修正時間が明らかになるべき。

・一度だけの移植やDLCなどの「一度作って終わり」のプロジェクトはスモークテストのようなシンプルな上位レベルの機能テストに注目する。ユニットテストに取り組むのはやめるべき。

十分vsやりすぎなテスト

・最初に再利用可能なコンポーネントをテストするのが良い。

・他のシステムよりもまずゲームプレイのテストをした方が良い。

・壁を越えたコミュニケーションを促進しよう。デイリースクラムかミーティングにQAの人を1人は連れてこよう。

ゲーム開発環境の自動化

Technology

Transcript of ゲーム開発環境の自動化