|
ArmA訓練所 2007/06/26 |
ミッションを作る過程において、テストは非常に重要なものです。
動作確認(テスト)の方法や観点を間違えると単なる自己満足動作確認になりかねません。
そこで、品質の高いミッションを作る上で必要なテストについて紹介したいと思います。
ミッションエディットにおけるテストの目的は、制作者が想定した動作をすることを確認することと、
プレイヤーの行動によってミッションの進行に支障を来すことがないか確認することです。
また、テスト後にプレイヤーから問題点、改善すべき点を指摘してもらい、内容を見直すことも大事です。
テストでチェックが甘いと制作者が想定した動作をしないことが度々発生したり、
プレイヤーから「何でこんな作りになってるの？」と疑問を持たれることになりかねません。
OFPの頃からユーザーミッション次第ではバグが酷くて遊べないものも多数出回っており、
ミッション制作者がこの工程で手を抜くことは、今まで作ったものが台無しになる危険性を認識すべきです。
マルチプレイでバグミッションに遭遇すると萎えるプレイヤーも結構いることと思います。
また、ゲームサーバーの管理をするうえで、こうしたバグミッションの存在は少なからず管理者の頭を悩ませています。
「作るのに疲れたから確認せずに公開しよう」などと考えるくらいであれば公開は先延ばしにし、確認が済んでから公開しましょう。
どうしても中途半端であることを認めた上で公開する場合は開発中であることを示しましょう。
ミッション制作者が手を抜いたことが原因でプレイヤーやサーバー管理者に迷惑をかけないよう、
テスト工程がいかに大事を認識し、作業に取りかかりましょう。
バグをなくすにはどうすれば良いのか、方法論はいくつもあるでしょうけど、
基本的にミッション制作者はアマチュアですからプロの技をそっくり持ってくるわけにも行きません。
そこで、バグをなくすための要素を考えてみたいと思います。
そもそもなぜバグが発生するのか？という点を考えてみましょう。
単純なものであれば、スクリプトコマンドのスペルミスや文法ミスでしょう。
これらの大半はエラーメッセージが表示されるため、制作者自身もミスに気づきやすいものです。
多くの場合、間違えた部分を正しく書き直せば解決します。
エラーメッセージは表示されないけどうまく動かないケースがあります。
例えばトリガーの条件文の内容が間違っているケース等です。(スコア10点で終了が9点で終了するなど)
これは実際に動かして試す方がいいでしょう。
デバッグするにはわざと変数の値を特定の値に書き換えて行うこともあります。
これは、通常のプレイでは時間がかかりすぎて効率的でない場合に、ミッションの進行上支障が無ければ有効な手段で、
スコアの境界値やイベント発動条件などをトリガーやスクリプトで指定して動かす方法です。
こうすることで大幅に時間を短縮できます。
エラーメッセージも出ず、条件文を見ても間違いが見あたらず、何が悪いのか分からない場合があります。
これは手直しに時間がかかりやすいタイプのバグですが、スクリプトの動作を細かく確認する方法が有効です。
hintコマンドをスクリプトコマンドに混ぜておくと、現在スクリプトのどの箇所が実行されているか分かります。
また、hintコマンドとformatコマンドを組み合わせることで変数の値を表示させることが出来ます。
これらのコマンドを使うことで、スクリプトの動作を詳細に把握し、間違いを見つけていくことになります。
厄介なのは、制作者自身が変数の値がどうなっているべきかを正しく認識していないと原因が見つからないことです。
スコアが加算されるべきところの処理が行われたのに点数がずっと0であることがおかしいと気づかないと先へ進めず、
なぜスコアが0のままなのかをさらに詳細に突き止める能力が必要になります。
まさに根気が必要とされる作業です。
もうひとつ面倒なのはトリガーとウェイポイントなどのシンクロナイズです。
これらはミッションエディタ上でグラフィカルに作業できるため、エラーメッセージはまず表示されません。
プレイヤーが特定の位置に来たら敵がやってくるということがやりたくても、
敵が全然やってこなかったりするケースが考えられます。
原因の一つはシンクロナイズの設定を間違えていることですが、
希にAIがスタックしていたり、単に移動に時間がかかりすぎて動いていないと勘違いするケースもあります。
これらはスクリプトコマンドではデバッグしづらく、プレイヤーをsetCaptiveコマンドなどで安全にし、
ヘリなどを用意して敵の動きを確認するしかないでしょう。
ここからは私の提案ですが、慣れない内はテストに点数を付けてみましょう。
簡単に言うと学校などで受ける試験と同じことです。
学校の試験と違うことは必ずしも100点中100点というキリのいい数字ではなく、
確認項目数一つに付き1点とし、確認項目が30個であれば30点が最高点となります。
例えば、ミッションが正しく終了することを確認したら1点という感じです。
こうすれば点数が高いほど、バグが少ないと言えるのではないでしょうか。
点数を付けるにはどうすればよいでしょうか？
まずは確認する項目を用意することです。
項目は多ければ多いほどいいと思ってかまわないと思います。
ミッションがこうなっていたらOKだという項目と、こうなったらNGだという項目を用意します。
書いてないことだったら何が起こってもいいんだよね？という突っ込みを食らってもいいくらいの項目が必要です。
ただし、あくまでゲームの話ですから、プレイヤーが極端に外れた行動を取った場合もミッションの進行に支障が出ないことを保証していてはキリがないでしょう。
また、時間の都合でたくさん用意した項目を全部チェックすることは出来ないかもしれません。
なので、次の項目をチェックしたらいいんじゃないかというものを作ってみました。
| 分類 | チェック内容 | 備考 | 結果 |
|---|---|---|---|
| 一般 | スタート地点が安全であること | ミッション開始直後に死亡しないこと | |
| スタートしてまもなくミッションが終了しないこと | ミッションの終了条件が勝手に満たされないこと | ||
| ミッションが正しく終了すること | 終わらないミッションでないこと | ||
| ミッションの終了するタイミングが正しいこと | 目標を破壊した直後(破壊の1秒以内)に終了しないこと | ||
| ミッションの勝利条件が正しいこと | 特定の目標破壊で勝利となること | ||
| ミッションの敗北条件が正しいこと | 時間制限や保護対象の死亡で失敗になること | ||
| 意図した天候条件であること | 初期状態で晴れやくもり、雨など | ||
| 意図した天候の変化が現れること | ミッション開始からしばらくして天気が変化するか | ||
| 意図した時間帯であること | 時計を表示して朝、昼、夜などを確認 | ||
| 推奨動作環境でまともにプレイできる負荷であること | AIの数やスクリプトが高い負荷をかけていないか | ||
| ミッションの内容がわかりやすいこと | 制作者じゃないと意味が分からない内容でないか | ||
| エラーメッセージが表示されないこと | Class名やファイルが見つからないなどのエラーが出ないこと | ||
| ユニット | 意図したユニットが配置されていること | SF SaboteurのつもりがSF Assaultでないかなど | |
| 意図した武器を持っていること | addWeaponなどで変更した武器を持っていること | ||
| ウェイポイントを正しくたどれること | 到達不可能なものがないか | ||
| 意図したユニットがグループリーダーであること | |||
| 意図した順番にグループ内の番号が与えられていること | 1がリーダー、番号が大きいほど下っ端など | ||
| 乗り物 | 人が乗っている(or人が乗っていない)こと | 用意した乗り物が有人か無人か確認する | |
| 武器の搭載量が正しいこと | 満載、少量、空っぽなど | ||
| 燃料の搭載量が正しいこと | 同上 | ||
| 損傷度が正しいこと | 全快か壊れかけなど | ||
| 初期配置の向きが正しいこと | 固定のマシンガンなどの向きを確認する | ||
| イベント | イベントが正しく発動すること | 意図したタイミングでイベントが発動するかどうか | |
| イベントの内容が正しいこと | 意図した内容のイベントであるかどうか | ||
| 意図しない条件でイベントが発動しないこと | プレイヤーのみが動作可能なイベントをAIが動作させないなど | ||
| Briefing | ブリーフィング画面が表示される(orされない)こと | ブリーフィング画面が出るかどうか | |
| デブリーフィング画面が表示される(orされない)こと | デブリーフィング画面が出るかどうか | ||
| Planページが表示されること | 空白になっていないか | ||
| Notesページが表示されること | 空白になっていないか | ||
| Planページに誤字、脱字が無いこと | 誤字脱字のチェック | ||
| Notesページに誤字、脱字が無いこと | 誤字脱字のチェック | ||
| Planページのリンクが正しくリンクしていること | クリックしても無反応でないか | ||
| Notesページのリンクが正しくリンクしていること | クリックしても無反応でないか | ||
| SP特有 | overviewが正しく表示されていること | ミッション選択画面の表示を確認 | |
| MP特有 | 少しのラグで動作が不安定にならないこと | SPとMPの挙動の違いが大きくないか | |
| 途中参加しても正しく動作すること | 目標クリアやスコアなどが他のプレイヤーとずれていないか | ||
| リスポーン処理が正しいこと | リスポーンの種類や場所、待ち時間が正しいか | ||
| アサイン画面の表示が正しいこと | ユニットの説明表示が意図したとおりになっていること |
上の表で書いた内容でも項目は少なめにしています。
ユニットや乗り物、イベントについてはそれぞれ用意した数だけチェックする必要があります。
備考に書いているのはあくまで例ですので、作ろうとしているミッションに合わせて読み替える必要があります。
ここで多くの項目を確認することでミッションの完成度が高まり、制作者のスキルアップにもなるでしょう。
上記の項目はあくまで例ですから、例よりも多い項目を用意することを心がけましょう。
制作途中の確認であればエディタのプレビューでもかまいませんが、最終確認はかならずエクスポートしてから行います。
ミッションをエクスポートして、シングルプレイならシングルプレイ、マルチプレイならマルチプレイミッションとして実際にプレイして確認します。
わざと死んでリスポーンの確認をしたり、同時に発生しないイベントの発生条件を確認するために何度かプレイする必要があります。
また、テストの時間を短縮するためにチートを活用します。
歩いて移動したり、しばらく待つ必要があるミッションでは時間を早めるキーを押して2倍速、4倍速にして時間を短縮できます。
テスト用のトリガーを用意してプレイヤーを捕虜に設定(setCaptive)したり、目標が自動的に破壊(setDamage)されるように設定したりします。
こうすることでテストの時間を短縮できます。ただし、ここでのチート設定は人間ががんばれば出来る内容にとどめた方が無難です。
例えば、瞬間移動(setPos)させて移動時間を短縮する場合、ウェイポイントが残ったままになったり、
通過点に置かれたトリガーを無視して進むことが出来るため、ときどき想定外の動作になったりすることがあります。
ほぼバグを潰したら、自分以外のプレイヤーに協力してもらい、プレイしてもらって意見を求めます。
自分以外の人にテストを頼むときは相手の時間を自分のために割いてもらっているわけですから、
バグだらけのミッションのままテストに協力してもらうのは失礼に当たります。
また、テスト途中に見つかったバグ次第によってはテストプレイを中断するという決断も必要です。
テストをこれ以上続けても時間の無駄だと分かったらなるべく早めに切り上げましょう。
自分以外の人にプレイしてもらう場合、あまり制作者自身が内容を説明しない方が望ましいです。
説明するとしたら、せいぜい敵の基地制圧ミッションとか、防衛ミッションといったジャンル程度にしましょう。
これはプレイヤーが制作者WEBサイトの説明などを目にしないMPミッションにおいて特に重要です。
多くのプレイヤーは制作者の声を聞くことは出来ないので、制作者の説明に頼らざるを得ないミッションは不親切です。
また、説明を受けることによってプレイヤーの取る行動パターンが狭まるので、いろんな行動を試すテストとしても不適切です。
MPミッションでは特に説明書きが重要になります。
多くのプレイヤーはミッション中に与えられた状況から、各自の常識に従って行動します。
わかりやすいブリーフィングやマップにマーカーを配置するなどしておかないと誤解を招いてしまいます。
また、紛らわしい演出、プレイヤーを混乱させる演出はあまり効果的でないことに注意しましょう。
初回プレイ時は驚くこともありますが、多くのプレイヤーは次に起こるイベントがどんなものか分かってプレイするので、
ネタバレすると非常につまらないものとなることがあります。
制作者の思いこみにも注意し、プレイヤーが自然に取った行動を見て修正しましょう。
敵の陣地に今後の移動に使う予定の車両を置いておくと、壊してしまうこともあるでしょう。
捕虜救出ミッションなのに捕虜を敵と間違って撃ってしまうケースも多々見られます。
こうした勘違いを起こさせないために説明書きを増やすことと、常識的なユニットの配置にしましょう。
最終的にプレイヤーの自然な行動でクリアできるかどうか、難易度の確認、改善すべき点がないか確認します。
内容を検討して、必要であれば改善します。
ここまで読んでくださった方はお気づきかもしれませんが、テストにはかなり時間がかかります。
ミッションの構想を練って実際にエディタで作った時間と、テストにかかる時間が同じくらいになるケースもあります。
とりあえずエディタで大まかに作るのに1週間かけた場合、テストには2,3日は少なくともかかると思います。
制作者としても後半は疲れてきたり、作っている内に飽きてくるということもあります。
自分で作って自分で楽しむミッションであれば別ですが、みんなに楽しんでもらうミッションを作ると言うことは必ずしも楽な作業ではありません。
ミッション制作の最終工程をきちんとこなして周りから「このミッション面白い」と言われればきっとミッションを作り続けられるでしょう。
面白いミッションを作り、コミュニティを活性化していただければ管理人としても幸いです。