【Unity】RPGを作るチュートリアルその127 テスト時のポイントの総括
- 2025.08.28
- RPGチュートリアル
- RPG, Unity, ゲーム開発, チュートリアル
シンプルなRPGをUnityで作るチュートリアルシリーズの127回目です。
第126回ではWebGLでセーブが保存されない点など、確認できたバグを修正しました。
今回はテスト時のポイントの総括やリリースビルドに向けた準備について確認していきましょう。
制作環境
MacBook Pro 2023 Apple M2 Max
Unity6 (6000.0.30f1) Silicon
作業内容と順序
シンプルなRPGを作る上でどんな作業が必要か、どんな順番で作っていくと良さそうか、別ページで検討しました。基本的にこの流れに沿って進めていきます。
チュートリアルの一覧
このシリーズ全体の一覧は以下のページにまとめています。
前回の内容
前回はWebGLでセーブが保存されない点など、確認できたバグを修正しました。
テストのポイント
一般的に、システム開発で行われるテストには非常にざっくりと分ければ以下のようなものがあります。
- 単体テスト
- 結合テスト
- システムテスト
ゲームに当てはめて考えていくと、単体テストは個別の機能のテストで、例えばお店にアイテムが表示されること、戦闘中に魔法が表示されること、といった小さな単位でのテストになります。
結合テストになるともう少し大きな範囲で、戦闘機能全体の動作をテストしたり、メニューの機能全体をテストしたりと、まとまった範囲の動作をテストします。
システムテストになるとゲーム全体のテストになり、このチュートリアルだと全体的に機能が実装し終わった後のテストがそれに当たります。全体を通して動かしてみることで今まで気付かなかった部分に気付くこともあります。
「動いていること」を確認する上では上記のシステム開発でのテストの考え方を使えるのですが、ゲームとして考えた時には「これは面白いだろうか？」「ユーザはプレイしやすいだろうか？」といった感覚的なテストも必要になります。ここが大変なところで、自分では面白いと思っていても、他の人にプレイしてもらったらあまり反応が良くないこともあったりして、感覚的な部分の調整は難しかっかりします。
プレイしやすさに関しては、作っている本人は何度もプレイしているために操作に慣れていきますが、初見で遊ぶ場合にどう操作したら良いか、操作が分かりやすいか、といった点に気を配ることも大切です。他の人にテストプレイしてもらうのが良いのですが、それが難しい場合は3日くらい作ったゲームに触らない期間を設けて、少しでも客観的に判断できる冷静さを取り戻してから確認すると良いかと思います。
開発終盤になると、何度もテストプレイしていて「もうリリースしたい……！」という欲が生まれてきます。リリースしてしまえば肩の荷が降りるので気持ち的には非常に楽になるのですが、ここを1回だけ踏ん張って冷静にテストすることで、リリースした後のユーザが遊びやすいゲームに近づきやすくなります。
テストのタイミング
大きな括りだと、
- モック版が完成したとき
- 機能を追加したとき
- 必要な機能をすべて実装したとき
- アップデートしたとき
にはテストをしっかりやっておくと良いかと思います。
モック版とはゲームの動きを確認できる模型版のようなもので、ゲームとしての面白さを確認するためのテストを行なっておくと安心です。思いついたアイディアをまず形にしてみて、ゲームとして面白い要素があるかどうかを確認します。思いついたアイディアは全部リリースまで持っていきたい気持ちはありつつも、形にしてみると「あれ……想像していたほどじゃないな？」となることも多々あります。こうした時に、アイディアをさらに練れば楽しくできそうか、それとも方向性を変えた方が良いか、といった判断をするためにモック版でテストしておくと時間の節約になります。この段階から他の人に遊んでもらってフィードバックをもらっておくと、アイディアを練り上げる大事な材料になります。
モック版を作って方向性が決まったら実装を進めていきますが、この時にも機能単位でテストしておくと手戻りも少なくなるかと思います。上で触れた単体テストレベルで確認しておくことで、機能同士が繋がる結合テストでも負担が減っていきます。この段階でも動かせる部分についてはビルドして確認しておくとエラーを早めに検知できます。もし多少時間を取れるならテストコードを書いておくと、後のリグレッション(回帰)テストなどが楽になります。そうは言いつつテストコードを書くのにも時間がかかるので、重要な機能に絞って書いたり、リリース後にその動作を正としてテストコードを書いたりと、人によって時間の配分で特徴があったりします。
必要な機能をすべて実装したらゲームとして動かして全体を確認していきます。いわゆるゲームのテストプレイですね。ゲームとして遊んだ時に不具合などがないか、モック版の時に確認した面白さがブラッシュアップされているか、といった点も確認しておくとグッド。RPGならフラグ管理などもあるので、進める順番を変えることでゲームの進行に影響がないかどうかもテストしましょう。
リリース後にはアップデートによる機能追加が入ることもあります。こうした際には、機能追加によって以前の動きを変えてしまっていないかテストするリグレッションテストを行います。機能を追加したら元々の機能の方でバグが出てきた、というのは良くあることなので、元々の機能を壊していないことを確認するのも重要です。テストコードを書いてあれば機械的に実行して確認できるので時間がかなり節約できます。
開発期間のうち、ほとんどテストしているようなレベルですね。実際、動作やプレイアビリティの確認はゲームの面白さを損ねないようにする重要な点なので、泥臭い部分ではありますがテストは頑張っておくのがおすすめです。
RPGのテスト
一般的なゲームのテストについて上で触れましたが、せっかくなのでRPGを作る際のテストについても考えたいと思います。
RPGの場合、
- ストーリー
- イベント
- 戦闘
- 移動
といった部分でテストが必要です。戦闘に関してはテストと調整が混じっている部分もあります。
ストーリーのテスト
ストーリーに関しては、全体で破綻がないか、矛盾している点はないか、といった点をテストします。「テスト」というよりは確認に近い気もしますが、これらの点を確認しておくのはとても大切です。ゲームを遊んでいて話の流れで「ん？」となると気になって没入感が失われていくため、イベントを組む前にストーリーを確認しておくと安心です。
規模が大きくなるとストーリー全体を確認するのも大変になります。アウトラインプロセッサなど、場面に応じたテキストを確認できるようなツールを使っていくと負担が多少軽減されるかもしれません。ストーリーに関してもgithubのプライベートリポジトリなどで管理すると、変更点を追いやすくなります。
イベントのテスト
イベントはストーリーがある程度できてから組んでいくと良いでしょう。メッセージを表示するほかに、アイテム増加などのデータ変更、効果音の再生などの演出、といった形で様々なイベントがあるので、ひとつひとつテストしていきましょう。どのイベントが実行されているかなどをコンソールに出力すると、画面上の動作と内部の動作を結びつけて確認することができます。
イベントの実行に関してはフラグの管理とも密接に関わっているため、エディタ上でフラグを切り替えられるようにするのに加え、実機でもデバッグ用の機能を呼び出して、フラグを切り替えられるようにしておくと非常に確認がしやすくなります。フラグの状態に応じたイベントの実行をすぐに確認できるとテストの負担が減ります。切り替えに加えて、フラグの状態一覧を確認できるようにするのも重要です。
戦闘のテスト
戦闘に関しては、まずは動作のテストとして可能な限り全てのコマンドと選択項目を確認しておきましょう。覚えている魔法は全て使う、持っているアイテムも全て使う、くらいの感覚で良いかと思います。魔法だったらMPが足りている時、足りない時の動作を確認し、アイテムだったらアイテムを使い切る時の動作なども確認しましょう。
この部分は段階的な確認があると安心で、まずは1種類の魔法、1種類のアイテムを実装し、それを使って単体テストレベルで動作を確認します。この部分で問題がなければ、もう2つ3つ魔法やアイテムを実装してさらに動作を確認します。それでも大丈夫そうなら予定していた魔法やアイテムの動作まで確認していきます。単体テストレベルのバグを早めに修正しておくことで、後の確認作業の負担も減っていきます。
また、敵キャラクターに特定の魔法が効くかどうかの相性判定なども大変な部分です。実機での確認はもちろん大切なのですが、やはり時間がかかってしまうため、魔法の効果をシミュレートするツールやエディタ拡張などを作成しておくと便利です。例えば眠らせる魔法や毒にする魔法などを用意したとして、シミュレートツールから選択した敵キャラクターに対して100回、200回効果の判定を行い、実際に意図した割合で効いているのかを確認すると良いかと思います。実際の戦闘では演出のための待ち時間などがあって確認に時間がかかるので、こうしたツールから待ち時間なしで処理を確認できるようにしておくと助かることも多いです。
ツールを作る観点だと、味方のレベルや装備、パラメータを調整した上で戦闘をシミュレーションするツールなども作っておくと調整に役立ちます。例えば通常攻撃を選択した場合に何回でこの敵キャラクターを倒せるか、といったものを一覧で表示できるようにすると、敵キャラクターと戦う適正レベルなども見積りやすくなります。
移動のテスト
移動に関しては、入っていいマス、入ってはいけないマスのテストがメインになるかと思います。移動の制御はRPGだと大切で、進行状況を制御するためにも抜け道などは可能な限り潰しておきましょう。これも人力でやるには大変な作業なので、最終的な確認は人力でやるとしても、壁に向かって歩き続けるツールなどを作っておくと便利です。
リリースビルドに向けた準備
さて、テストについて考えた後は、リリースビルドに向けた準備についても考えていきます。今回のチュートリアルではローカル環境のWebサーバでビルドの動作を確認するところまでで完了としていますが、実際にゲームを作る際にはリリース用に設定を行なっていきます。
WebGLのビルドをリリースするなら、
- PlayerSettingsを本番向けに設定する
- デバッグ用ログの出力を調整する
- 実行時の速度を重視したビルドを作成する
といった部分を詰めていきます。
PlayerSettingsを本番向けに設定する
PlayerSettingsのウィンドウで各種設定を本番用に切り替えていきます。
セーブファイルの場所に影響するので、CompanyNameの項目は遅くともリリースする前までには自分で決めたものに変更しておきましょう。バージョンなども番号の規則などを決めておくと良いかと思います。
WebGLのビルドを自分のサイトで公開する場合は、WebGLのHTMLをカスタマイズすることもできます。このチュートリアルで作成したビルドだとUnityのテンプレートをそのまま使っています。マニュアルにはカスタマイズの方法も載っているので、必要に応じてこちらも参考にすると良いかもしれません。
unityroomなどで公開する場合は、そのサイトのデザインに合わせた形で表示されるようになります。
他の項目についても、ビルドの早さなどを重視していた項目を、動作時の早さやパフォーマンスを重視した設定に切り替えるなど、各項目について調整していくと安心です。
デバッグ用ログの出力を調整する
ログの出力をどこまで行うかも大切です。Logのレベルだとユーザに見えなくても良い情報まで見えてしまったり、LogErrorなら不具合の解決に必要な情報が出ていることが多かったりと、ログレベルに応じた切り替えも必要です。
今回のチュートリアルでは独自のデバッグ用クラスを用意しているので、そのクラスでメソッドの内部をコメントアウトすることで、他のコードを変更することなく切り替えができます。ビルド前にはgithubにコミットする手順をルール化しておくことで、いつコメントアウトを入れたか追跡することもできます。
UnityのDebugクラスを使ってログを出力している場合にはPlayerSettings内で「Other Settings」の中にある「Stack Trace」の項目で切り替えられます。
実行時の速度を重視したビルドを作成する
ビルドの作成においても、ビルドの速度ではなくリリースした後の実行速度を優先しておくと安心です。今回のチュートリアルで作成したRPGだとそこまでフレーム内の処理時間は大きくなりませんが、アクション系のゲームだとフレーム内の処理が大きくなるケースもあるため、実行時のパフォーマンスが良いビルド方法を選んでおきましょう。
WebGLのプレイヤーをビルドする際に少し触れましたが、検証中はビルドの時間を短縮するために、ビルド設定の「Code Optimization」の項目で「Shorter Build Time」を選択していました。リリース版をビルドするなら、「Runtime Speed」を選択してビルドすると良いかと思います。
ただし、ビルド時間は私の環境では6から7倍長くなったので、あくまでも確認が終わって最後にリリースする時に選択すると時間を取られずに済みます。実測値だと約27分だったので、リリース前のデバッグ中に30分近くUnityをいじれないのは結構な焦りを生みます。
最適化のヒントはマニュアルにも
ビルドの動作を最適化するためのヒントはUnityのマニュアルにも記載されています。例えばWebGLのビルドと最適化に関しては以下のページにまとまっています。
この情報と、リリース先の情報を照らし合わせてどの部分を変更していくか選んでいくと良いかと思います。unityroomやitch.io側の仕様などもあるので、それに合わせる形で最適化していきましょう。
今回のブランチ
今回はゲームのプロジェクト内の変更はありません。
まとめ
今回はテスト時のポイントの総括やリリースビルドに向けた準備について確認しました。ゲームのテスト、特にRPGのテストは確認項目が多いので、他の人の力を借りたり、テストしやすいツールを作ったりしておくと良いかと思います。
次回はチュートリアルのまとめを行います。
ゲーム開発の攻略チャートを作りました！
「ゲームを作ってみたいけど、何から手を付けていいか分からない！」
そんなお悩みをお持ちの方向けに、todoがアプリをリリースした経験を中心に、ゲーム作りの手順や考慮すべき点をまとめたe-bookを作成しました。ゲーム作りはそれ自体がゲームのように楽しいプロセスなので、「攻略チャート」と名付けています。
ゲームを作り始めた時にぶつかる壁である「何をしたら良いのか分からない」という悩みを吹き飛ばしましょう！
-
前の記事
【Unity】RPGを作るチュートリアルその126 WebGLのセーブが消える問題を修正 2025.08.27
-
次の記事
記事がありません