オンラインゲームと社内テスト
Upcoming SlideShare
Loading in...5
×
 

オンラインゲームと社内テスト

on

  • 28,418 views

(株)Aimingの社内勉強会で使われたスライドです。開発中のタイトルの画像は削除してあります。ご了承ください。

(株)Aimingの社内勉強会で使われたスライドです。開発中のタイトルの画像は削除してあります。ご了承ください。

Statistics

Views

Total Views
28,418
Views on SlideShare
28,193
Embed Views
225

Actions

Likes
61
Downloads
71
Comments
0

7 Embeds 225

http://192.168.33.10 112
http://geechscamp.lovepop.jp 61
https://twitter.com 41
http://okdsgr.tumblr.com 8
http://tweetedtimes.com 1
http://www.linkedin.com 1
http://s.deeeki.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

オンラインゲームと社内テスト オンラインゲームと社内テスト Presentation Transcript

  • オンラインゲームと 社内テスト 水島 克 2013.9.11 Aiming Inc.
  • 社内テスト好きですか Aimingの社内テスト 社内で配布して指定の時間にフリープレイ 東京スタジオでは月に2∼3回の頻度 参加は自由 参加率が高くオープンな良い文化
  • 良い点 デバック会社に頼むより短期で柔軟に開催 社内のプロジェクトについて共有できる 経験ある開発者からも意見がもらえる 後で個別にヒアリングしやすい
  • 悪い点 自由参加なので、何人参加するかわからない 業務の支障になる場合がある 気安さからか進行がグダグダになりがち 説明が不足で結局なんのテストだったのか…
  • 特に、 開発チームと運営担当の情報共有が不十分で 「なんとなくやってるテスト」がある… 改善したい!
  • ゲーム開発のテストとは 旧来のコンソールゲームにおけるテスト テスト≒デバッグ テストは主にゲームの完成間近に行われる もの、という意味合いが強かった
  • ゲーム開発が大規模化/多様化 QA(品質管理)のセクションが独立化 テスト自体をゲーム開発に組み込む傾向 開発のためのテスト
  • オンラインゲームでは コミュニティがゲームの在り方を規定 少数の人間の評価だけでは把握できない ためテストが重要
  • テストの重要な側面 ゲームに隠れているの問題点や 未来の可能性を「定量化」 「能力」や「センス」に頼っていた部分を 数値や言葉に置き換え
  • 本日のおはなし 最初はオンラインゲーム開発における 様々なテストについてのはなし 残りは現在開発中のプロジェクトの事例 効果的な社内テストの方法について考える
  • 様々なテストのかたち 社内テスト事例 なぜ社内テストをやるか 本日のメニュー Chapter 1 Chapter 2 Chapter 3 テストの障害と対策Chapter 4 テスト前のチェックシートChapter 5
  • 様々な テストのかたち Chapter 1
  • 開発行程とテスト Prototype Alpha Beta CBT ver. OBT ver. フォーカステスト 負荷テスト 自動テスト 実装確認 自動テスト データロギング デバッグのためのテスト 互換性 互換性 レベルバランスのテスト 負荷テスト
  • フォーカステスト1 開発中のタイトルに対する目的を絞ったテスト ゲームのコンセプトや開発中の特定パートが どのような印象を与えるのかを調査 1 プレイ中の動向を観察 2 プレイ後にインタビューする 3 アンケートを取る
  • フォーカステスト ✓ テスト目的:ゲームの特定のパートが狙いどおりに実 装できているか確認 ✓ プレイヤー:一般ユーザー、社内の別チームの人など ✓ テスト方法:1部屋で数人のプレイヤーに遊んでもら い観察(撮影)する ✓ 必要な結果:プレイヤーが示す反応、受けた印象、コ メントなど
  • レベルバランスのテスト2 レベルデザインのプロセスの一部 想定する状態(装備/成長レベル/パーティー 人数等)でプレイしてバランスを確認 デザインドキュメントを見る 短期間に修正とフィードバックを繰り返す
  • レベルバランスのテスト ✓ テスト目的:特定のレベルの難易度が想定どおりかど うか/前回の問題点が反映されているか ✓ プレイヤー:社内のテスター、レベルデザイナー ✓ テスト方法:デザイン側のスコープに合った環境を作 り、テスターにプレイしてもらい観察する ✓ 必要な結果:想定した難易度に収まっているか。想定 した動線や遊び方でプレイされるか。逆に想定外の不 適切なプレイをされないかどうか。
  • データロギングのテスト3 プレイヤーの行動ログを記録。 難易度や動線などを計測 何千回ものプレイの動線を地図やグラフに展開 移動、死亡、戦闘、アイテム使用 etc... FPS/TPSのAAAタイトルで多く見られる
  • データロギングのテスト ✓ テスト目的:プレイヤーの行動ログを記録しそこから 統計的な偏りを探る ✓ プレイヤー:社内のテスター ✓ テスト方法:ログの記録を行いながらフリープレイ ✓ 必要な結果:できるだけ多数のプレイヤーの行動の傾 向、統計的なデータ
  • 負荷テスト4 オンラインゲームで、サーバ/クライアントプ ログラムの性能を見るためのテスト 同時接続し、ゲームの進行が円滑か確認 機能別の各サーバに負荷をかける 小規模→大規模に段階的に行う場合が多い
  • 負荷テスト ✓ テスト目的:サーバ/クライアントプログラムの性能 を確認、ボトルネックを探す ✓ プレイヤー:社内・デバッグ会社のテスター、全社員 ✓ テスト方法:多くのテスターが同時接続し、同時に同 じ行動をして発生する負荷を検証 ✓ 必要な結果:同時接続時のサーバログ、CPU負荷、ク ライアントのフレームレートなど
  • BOTによる自動テスト5 特にMMOGなどで、簡単なBOTのプレイヤー キャラクターにプレイさせログを取る 通常プレイでは膨大な時間がかかるゲームの 平均プレイ時間や難易度などを計測
  • BOTによる自動テスト ✓ テスト目的:通常プレイでは時間のかかるプレイを自 動化しログを取り、バランスの参考にする ✓ プレイヤー:BOTプログラム ✓ テスト方法:BOT操作によるプレイヤーキャラを生成 し、24時間無休で自動プレイさせる ✓ 必要な結果:BOTキャラクターのプレイ難易度、プレ イ時間など
  • 実装確認6 実装完了となったシステムやゲームのデータ、 アートのアセットなどをチェック 仕様書やリソースのリストを参照 「すべてのスキルの組み合わせをすべてのキャ ラで」といった、総当たり式のテストも
  • 実装確認 ✓ テスト目的:プログラムやデータが正しく実装されて いるか確認 ✓ プレイヤー:社内・デバッグ会社のテスター ✓ テスト方法:仕様書やテーブル、アセットのリストな どに基づいて正常に機能するか確認 ✓ 必要な結果:チェック項目のリストと各項目に対する テスト結果
  • デバッグのためのテスト7 純粋な不具合を発見し、開発チームに修正依頼 するためのテスト フリープレイ&怪しい箇所は重点的にプレイ チケットを発行し、開発チームに報告 再現性の高い報告(不具合が出る条件を特定し たもの)が望ましい
  • デバッグのためのテスト ✓ テスト目的:ゲームの不具合を発見て修正を依頼し、 ゲームの商品としての完成度を高める ✓ プレイヤー:社内・デバッグ会社のテスター ✓ テスト方法:ゲームをフリープレイ、怪しい部分を重 点的にプレイ ✓ 必要な結果:不具合の再現条件や原因を報告するチケ ット
  • 機種互換のテスト8 様々な端末でプログラムが「プレイ可能な水 準」を満たしているか確認 スマートフォンの場合、最低スペックと標準ス ペックの方針(OS・RAMサイズなど)が必要 アクション性のあるゲームの場合、平均で 15fpsを切るようだと厳しい
  • 機種互換のテスト ✓ テスト目的:保証スペックを満たす端末で正常にプレ イできるかどうかを確認 ✓ プレイヤー:社内&デバッグ会社のテスター ✓ テスト方法:できるだけ多くの端末(特に人気端末) にインストールしプレイする ✓ 必要な結果:各端末毎の動作確認結果のリスト
  • 開発行程とテスト Prototype Alpha Beta CBT ver. OBT ver. フォーカステスト 負荷テスト 自動テスト 実装確認 自動テスト データロギング デバッグのためのテスト 互換性 互換性 レベルバランスのテスト 負荷テスト
  • ゲームに隠れているの問題点や 未来の可能性を「定量化」 テスト目的に合わない結果・レポートは 意味をなさない場合が多い
  • 適切なタイミングで 必要なテストを 行うことが肝要
  • プロジェクトNの 社内テスト事例 Chapter 2
  • プロジェクトN 概要 30中盤∼後半のオッサン中心のチーム 5∼10人の小規模チーム スマホのフル3Dオンラインゲーム サーバ・クライアント共に内製 ちょっと新規性あり
  • プロジェクトN 概要 これまでに6回のマイルストーン(1.5∼2.5ヶ 月単位) 計5回の社内フォーカステストを実施 そのうち4回はアンケートも実施 ゲームはまだ未発表…
  • Nのマイルストーン Prototype Prototype2 Alpha Beta1 Beta2 テスト1 テスト2 テスト3 テスト4 テスト5 アンケート1 アンケート2 アンケート3 アンケート4 Alpha2
  • テストの目的 Prototype Alpha Beta CBT ver. OBT ver. フォーカステスト 負荷テスト 自動テスト 実装確認 自動テスト データロギング デバッグのためのテスト 互換性 互換性 レベルバランスのテスト 負荷テスト 互換性
  • プロトタイプ版1 基本的な操作性/画面イ メージ/ヒット感/戦術 を試すもの 最初のサンプル版 オフラインのみ
  • プロトタイプ版 ✓ 個別に1人ずつ呼んでテスト ✓ ゲームデザイナ(水島1人)がプレイをじっと見る ✓ テスターは全部で10人くらい(企画の人中心) ✓ プレイ後、各テスターにインタビュー ✓ アンケートは無し テスト方法 フォーカステスト
  • プロトタイプ2版2 プリプロ版をマルチプレ イで遊べるもの 複数人で遊んだ時のプレ イ感を検証
  • プロトタイプ2版 ✓ 個別に3人ずつ呼んでソロ&マルチテスト ✓ ゲームデザイナがじっと見る (東京20人+大阪21人) ✓ テスターは運営のスタッフを中心に選出して依頼 ✓ 各テスターにインタビュー&アンケートもらう テスト方法 フォーカステスト
  • アンケート形式 google docsの アンケート機能 訊きたい項目別に 5段階で評価 項目に対する コメント欄
  • プロトタイプ2版 スコア 項目 とてもよい よい ふつう いまひとつ よくない 第一印象 14% 62% 19% 5% 0% ゲームデザイン 5% 38% 40% 14% 0% ビジュアル/演 出/世界観 12% 38% 33% 17% 0% 操作性/UI 5% 29% 29% 38% 0% レベルデザイン 7% 21% 57% 12% 2% コンセプト/新 規性/将来性 17% 43% 33% 7% 0% ※41人が回答
  • アルファ版3 複数のマップが遊べる スキルシステムを追加 遊びの基礎を補強 ソロ∼マルチへの序盤の 流れを作る
  • アルファ版 ✓ 個別に3人ずつ呼んでソロ&マルチテスト ✓ ゲームデザイナがじっと見る(17人) ✓ テスターを選出して依頼 ✓ 各テスターにインタビュー&アンケートもらう ✓ アンケート項目を最小限に絞り固定化 テスト方法 フォーカステスト
  • アルファ版 スコア 項目 とてもよい よい ふつう いまひとつ よくない スキル 0% 65% 18% 12% 6% UI/操作性 0%(5%) 29%(29%) 29%(29%) 41%(38%) 0%(0%) レベルデザ イン 18%(7%) 0%(21%) 47%(57%) 24%(12%) 12%(2%) コンセプト /将来性 6%(17%) 65%(43%) 18%(33%) 12%(7%) 0%(0%) ※17人が回答。 ()内は前回の結果
  • ベータ1版4 チュートリアルを入れ 序盤の流れを構成 プレイ評価システム 基礎的なコミュニティの 機能
  • ベータ1版 ✓ 個別に10人ずつ呼んでソロ&マルチテスト ✓ ゲームデザイナ(3人)がじっと見る ✓ 各テスターは東京スタジオで公募(35人くらい) ✓ アンケートもらう(東京スタジオ27人) ✓ アンケートに端末機種と不具合報告を追加  テスト方法 フォーカステスト 互換性
  • ベータ1版 スコア 項目 とてもよい よい ふつう いまひとつ よくない スキル 4% (0%) 74% (65%) 15% (18%) 7% (12%) 0% (6%) UI/操作性 7% (0%) 22% (29%) 33% (29%) 26% (41%) 11% (0%) レベルデザ イン 4% (18%) 30% (0%) 52% (47%) 15% (24%) 0% (12%) コンセプト /将来性 37% (6%) 41% (65%) 15% (18%) 7% (12%) 0% (0%) ※27人が回答。()内は前回の結果
  • ベータ2版5 ステージ選択画面など UI周りの強化 1時間程度のプレイボリ ューム アイテムを入手しプレイ ヤーが成長する流れ
  • ベータ2版 ✓ はじめての全社テスト ✓ 参加希望者が同じタイミングで一斉にテスト (東京+大阪で全部で60人くらい) ✓ 同時プレイの負荷テスト ✓ 不具合端末などの報告を受付 ✓ 各テスターからアンケートもらう テスト方法 フォーカステスト 互換性 負荷テスト
  • ベータ2版 スコア 項目 とてもよい よい ふつう いまひとつ よくない スキル 6% (4%) 33% (74%) 21% (15%) 30% (7%) 9% (0%) UI/操作性 0% (7%) 9% (22%) 27% (33%) 48% (26%) 15% (11%) レベルデザ イン 9% (4%) 15% (30%) 42% (52%) 24% (15%) 9% (0%) コンセプト /将来性 15% (37%) 36% (41%) 27% (15%) 18% (7%) 3% (0%) ※33人が回答。()内は前回の結果
  • Nのテストのポイント 開発の初期段階から何度も見せる テストの規模は開発段階に応じて大きくする テスト結果をオープンに(チームwikiに貼る) アンケートを集計しコメントは細かく読む 「将来性あるか?」をストレートに聞く
  • なぜ社内テストを やるのか Chapter 3
  • この章はプロジェクトNで 社内テストを何度かやっての個人的な感想 基本スタンス ゲーム開発は主観的で属人的な行為 多数決ゲームが作りたいわけではない テスト結果をどう使うか?
  • 問題点を特定する 開発中のゲームの潜在的な問題を知る アンケートで書かれた意見から問題を推察 例)「カメラを動かしたい!」 本当の問題は必要な要素が画面内 に収まっていないこと?
  • プレイヤーの動向を知る プレイヤーの視点でゲームを再確認できる ゲームのどこに注目し、どこに注目しないか 例)大きな文字のメッセージを読まない 例)驚くほど簡単な場所でつまづく 全体を把握しない視点が重要
  • 作業優先度の参考に やりたいことは山のようにあるが、予算や 開発期間の都合でできることは一部だけ 開発の順番・優先度の参考にする 意見を参考に主観的に判断
  • 会社との共通認識 CxOな人々(社長など)が安心できる このゲームが「もういけそう」なのか 「まだいまいち」なのかざっくり共有 ゲームの「強い点」と「弱い点」を明確 化し、会社と目標を共有
  • 開発チームの本音 「完璧にできてから人に見せたい」 「不当に評価されるのが怖い」 いつかは評価される。テストは 早いほうが行動の選択肢が増える テスト結果はあくまで参考に
  • テストの 障害と対策 Chapter 4
  • 4.1 開発チーム側の 問題
  • 情報の共有不足 文化的な問題:オープンになれない 「評価されるのが怖い」心理 サービス直前に社内テストをして 問題が出てもすぐには直せない テストでハッキリ評価を受けたほうがいい
  • 開発の目標設定 マイルストーンの目標設定が分かりにくい →どんなテスト結果が要るのか分からない 目的設定をイメージしやすいものに × 移動、エンカウント、スキル、敵を殺せる、および戦闘のUI ○ 戦闘のプレイ感覚と操作感、特に「爽快感」を具現
  • 遊べるバージョンが無い 日常的に遊べるバージョンが無いと起こる問題 例)運営「触らせてもらえません?」   開発「いま遊べないんだよねー(ずっと)」 例)社内テストの前日の深夜にリリース → 運営担当者が触ら ないままテスト開始 不十分なバージョンでも日常的に 見せたほうがいい
  • 4.2 開発∼運営の 距離感
  • 企画/運営の切り分け ソーシャル/スマホネイティブの傾向 イベント中心のゲームが主流 開発と運営とプロモーションは一体 「開発チームが作ったものを運営に渡してサー ビスしてもらう」みたいな発想は捨てる
  • 担当者間の対話不足 運営担当者が開発の後半に合流することが多い テストの目的が共有されていない × 作るだけ作って「あとはヨロシク」の企画担当者 × 仕事を「やらされて」いて無関心な運営担当者 メンバー全員が積極的に関われる環境づくり
  • 社内テスト前の チェック項目 Chapter 5
  • チェックリスト ✓ ゲームの最終形はどういう形? ✓ 今回のマイルストーンは何が目標? ✓ どんな目的のテスト?(複数) ✓ どういう規模で誰を対象に行う?
  • アンケートを作ろう 開発チーム内で評価ポイントをヒアリング プログラム、アート、企画でポイントが 異なる そのバージョンで最もフォーカスするべき部分 をピックアップ
  • まとめ
  • 社内テストは会社の良い文化。 適切なフィードバックをすることで ゲームがより早期により良くなる 社内テストをうまく 活用しましょう!