レール式移動型シューティング 設計を考える
最終更新：
orika_ex_miyako 2021年10月27日(水) 18:55:57履歴
全体の構成とゲームの目的 
最終的に AR 対応して遊べるゲームを目標に設計を考えていきます。
ゲームの全体の流れは次のような内容になります。
０．オープニング演出を行う。その場合、経路が設定されていても、演出が完了するまでは移動を開始させない １．設定されている経路に沿ってカメラが移動を開始する(プレイヤーの移動と同義) ２．経路は複数の地点がつながって作られており、各地点に到着するたびに、ミッションが発生するかどうか判定を行う ３．ミッションとは「移動先の分岐」「イベントの発生」「ゲーム終了」のいずれかになる ３−１．「移動先の分岐」は、経路の最終地点でのみ発生する。このミッションが発生すると、画面に最大３方向までの次の経路の候補が表示される いずれかを選択するまで経路が確定しないので、移動は発生しない。いずれか１つを選択すると【１】の処理に戻る ３−２．「イベントの発生」は、経路の最終地点以外でのみ発生する。イベントとは敵・アイテム・障害物のことで、これらが自動生成される。 これらはすべて攻撃することで破壊でき、複数のイベントが同時に発生する(敵・敵・障害物、など) クリア方法は２種類あり、制限時間まで耐えきるか、すべての敵や障害物を破壊するかのいずれかになる。クリアすると【１】の処理に戻る ３−３．「ゲーム終了」では、最後の経路の最終地点でのみ発生する。ここに到達することがゲームの目的の１つになる ４．クリア演出、リザルト表示などを行う。リトライ、次のステージなどの制御も行う
ゲームの目的は、最後の地点までたどりついてクリアすることと、なるべく高いスコアを目指すことの２つです。
まずは最後の地点までのクリアを目指してもらい、それが達成できるようになったユーザーにはハイスコアを狙ってもらうようなデザインを心掛けます。
例えば、向きを変えないと見えない位置に高得点のアイテムがあったり、あるいは、ランダムで高得点の敵が出たり、といった部分です。
プレイヤーの情報
プレイヤーには以下の情報があります。
・体力(ＨＰ、ＬＩＦＥ) => 敵に攻撃されると減少。回復アイテムを獲得すると回復(上限は超えない)。0 以下になるとゲームオーバー ・攻撃力 => 敵を攻撃した際に与えるダメージ。攻撃力アップアイテムを獲得すると上昇。上限あり ・弾数 => 現在の弾数と最大数の設定がある。弾数アップのアイテムを獲得すると上昇。上限あり 0 になるとリロード処理が発生し、一定時間後に最大値まで装填される ・スコア => 点数。敵を倒す、障害物を壊すと加算 ・リロード時間 => リロード処理による装填までの待機時間。この時間を経過したあとに弾が最大値まで装填される
他にも適宜なものを検討し、必要に応じてゲーム内での役割を考えて実装を行います。
UI として表示する内容は「体力、現在の弾数、スコア」です。最大弾数は任意です。
表示方法としては、体力についてはゲージ、あるいはアイコンで値を視覚的に表現します。
現在の弾数とスコアについては数値のみでの実装を検討します。
プレイヤーの出来る事
プレイヤーのアクションを設計します。最初にどういったものを実装したいかをイメージして、順番に組み込んでいくようにします。
あとで追加仕様が発生しないように、始めから全体で組み込む内容を把握しておくことが大切です。
・視点移動 => AR の場合はカメラの位置や角度で自動的に実装される エディターでの場合は、マウスの操作に合わせて上下左右に視点移動する制御を実装する ・攻撃 => AR の場合は画面のタップ。エディターの場合はマウスの左クリックで弾を画面中央の位置に発射する どの部分に発射されるかわかるように、標的用のアイコンも用意する ・回避 => 敵が弾を発射してくる仕様にする場合のオプション。ボタン操作(マウスの左クリック)で攻撃を回避できる 連続での回避に制限を加える必要があるので、回数制限や、インターバルなどを一緒に検討する
Input.GetMouseButtonDown メソッドを実装することで、スマホのタップにも自動的に対応できます。
攻撃に関しては Ray による制御で実装を検討します。弾の発射については、押しっぱなしで打ち続けられるモードと
１回押すたびに１回しか出ないモードとを用意して、ゲーム前に切り替えられるようにします。
弾数が 0 になったときに弾を発射する操作をすることで、自動的に弾のリロード処理が動くように制御を考えます。
回避については、敵の攻撃パターンの仕様検討時に合わせて検討します。回避行動とわかる処理の実装に合わせて、
回数制限やインターバルなどを設ける場合には UI にもそれらの情報を表示するようにします。数値なのか、ゲージなのかも検討します。
敵の情報
敵をイベントとして生成します。生成位置はランダム、あるいは固定値、どちらでもできるように出現位置のロジックの検討します。
このサンプルプロジェクトではゾンビ系の敵を主とします。
NavMeshAgent の機能を利用して移動させるのか、DOTween の機能を使って移動させるのか、Rigidbody の機能を利用して移動させるのか、
あるいはそれらを敵の種類に応じて切り替えるのか、などを検討します。
基本的には NavMeshAgent にて制御し、ボスについてはDOTween による制御を行うような、ハイブリッドな移動方法を検討します。
敵の種類を増やせるように、EnemyData クラスを用意して、体力、攻撃力、移動速度といった数値をデータとして登録できるようにしておきます。
これはスクリプタブル・オブジェクトの機能を活用して、Unity 内に EnemyData のデータベースを作成し、インスペクター上から設定と管理を行えるようにします。
当たり判定については、頭部のみ３倍ダメージとし、その部分を攻撃して敵を倒した場合には頭部が破壊される演出を実装します。
この判定には専用のクラスを作成し、部位ごとにコライダーをアタッチし、さらにクラスも一緒にアタッチします。
それ以外はその場で倒れます。
アセットとして利用する敵のモデルにはアニメーションや、部位ごとにリグが分かれている必要があるので、Humanoid 型のモデルを採用します。
ボスについては自由に設計します。
敵が遠距離攻撃を行う場合、それは弾用のゲームオブジェクトを生成し、プレイヤーの方に向かって発射する処理を実装します。
その場合には、弾用の攻撃力と速度を準備する必要があります。また、敵の弾を破壊できる仕様を盛り込むかどうかも、合わせて検討しておきます。
敵にコライダーを活用して攻撃範囲を設定し、その範囲内にプレイヤーが留まっている間だけ、攻撃の準備と攻撃の処理を行うようにします。
この設定も敵の体力などと同じで、敵ごとにデータとして設定が出来るようにします。
敵を倒すとスコアが加算されます。
それ以外のご褒美についても検討します。
例えば、ミッション開始時から１回もダメージを受けずに敵を全滅させたらスコアにボーナスや、体力回復、などです。
プレイヤーが挑戦したいと思える目標を設定しておくことで、敵との戦闘を作業ではなく、緊張感のあるやりとりにすることが出来ます。
アイテムの情報
複数のアイテムをイベントとして生成します。こちらも出現位置を固定化するか、ランダムにするかをロジックを考えます。
アイテムの種類は３種類を検討していますが、すべてを出す必要はありません。自分で考えたアイテムを実装するようにしてください。
・体力回復 => 体力が固定値分、回復します。効果に応じて、数種類つくることもできます。その場合には、モデルを変えて違いを作ります 薬や、薬瓶などのモデルを検討します ・攻撃力アップ => 一定時間の間、プレイヤーの攻撃力を固定値分、アップさせます。ミッションが終了時に効果時間が残っている場合、そこで終了するのか、 効果時間を停止して、次のミッションでも残り時間から再開するのかを考えて、それにあったロジックを作ります 効果時間中に次の攻撃力アップのアイテムを獲得した場合についても仕様を検討します 攻撃力自体をさらにあげるのか、効果時間は加算なのか、初期値に戻すのか、などです こちらも薬瓶、あるいは力が上がることが分かるアイコンのモデルなどを検討します ・弾数アップ => 装填可能な弾数の上限値を固定値分、上昇させます。一時的なものにする場合には、攻撃力アップと同じ設計を検討します ゲーム終了まで効果があるのであれば、出現する確率などを調整する方向で検討します マガジンなどのモデルを検討します
アイテムもイベントなので、攻撃して獲得することになります。
生成されるアイテムについては、単純に 1/3 にするのか、割合を作って出現率を変化させるのかを検討します。
障害物の情報
障害物をイベントとして生成します。破壊することでスコアを獲得できます。生成位置についても他のイベントと同様に設計を考えます。
出現する障害物については、固定として設置しておいた方が、プレイヤーの邪魔になったり、あるいは役にたったりということに活用してもらえます。
・木の樽 => すぐに破壊できるが、一番少ないスコアアップ ・岩 => 硬いが、スコアは高い ・爆薬樽 => すぐに破壊でき、スコアも獲得でき、周囲の敵に攻撃する ・有刺フェンス => 硬いが、スコアはそこそこ。破壊できないとダメージを受ける。受けるタイミングはミッション終了時に判定する
他にも実装してみたいものを考えて実装するためのロジックを検討します。
これらもすべて登場させる必要はありません。
クラスの設計
ここまでの情報を元に、どのようなクラスを作って運用していければよいかを書き出してみます。
設計方法は色々とありますので、イメージをそのまま設計に落とし込めるかがポイントになります。
＜主な設計＞
・RailPathData 移動する経路用の地点を登録して管理するクラス。Create Empty で新しいゲームオブジェクトを作成してアタッチする ステージ内に設置した空のゲームオブジェクト(Transfrom コンポーネントのみのゲームオブジェクト)を子オブジェクトとし、 インスペクター上でクラス内の配列に登録しておき、ゲーム内で参照できる状態にする ・RailMoveContoller カメラを経路にそった移動を行わせる制御クラス。FPS 視点なのでカメラ=プレイヤーの位置として考える。Create Empty で新しいゲームオブジェクトを作成してアタッチする 最初は RailPathData クラスの情報をそのまま参照して、経路の情報を作成し、経路移動が行えるかどうかを検証する 実装できたら、GameManager から RailPathData の情報を受け取って、その情報を参照して経路を作るようにする そうすることで、これは経路移動の出力専用のクラスとなれる(自分で考えないで、もらった情報を処理していくだけにする) 経路の地点に到着するたびに、まだ次の経路が残っているかを確認し、残っている場合には、GameManager にミッションが発生するかどうかを確認してもらう命令を出す もしもすべての経路を通過して最終地点についているなら、GameManager にゲームクリア処理の命令を出す ・GameManager ゲームの進行管理を行うクラス。Create Empty で新しいゲームオブジェクトを作成してアタッチする � 仝什澆離押璽爐凌聞埔�態を enum で管理し、他のクラスへ提供する �◆＾榮阿垢觸萢�が発生したら、RailMoveContoller に情報を提供して、移動を実行させる �� ミッションが発生するか確認し、発生した場合には、分岐の場合には UIManager に情報を提供して分岐を表示する イベントが発生した場合には、EventGenerator に情報を提供してイベント(敵、アイテム、障害物)を生成する �ぁ．�リア条件を満たしたらクリアにする ・EventGenerator 敵、アイテム、障害物を生成するためのジェネレータクラス。GameManager からもらった情報を元に DataBaseManager から詳細を受け取り、生成する 生成したイベントの初期設定を行うメソッドを実行する。Create Empty で新しいゲームオブジェクトを作成してアタッチする ・UIManager UI 表示関連の制御を行うクラス。Create Empty で新しいゲームオブジェクトを作成してアタッチする プレイヤーの情報関連(体力の表示更新、弾数の表示更新、スコアの表示更新など)、分岐が発生した場合に、GameManager から受け取った情報を元に 画面上に行先矢印のボタンを表示し、その方向への経路処理を GameManager へと戻す ・DataBaseManager 経路の情報、敵のデータなどのスクリプタブル・オブジェクトの管理を行うクラス。Create Empty で新しいゲームオブジェクトを作成してアタッチする シングルトンで作成し、どのクラスからでもアクセスしやすい状態にする ・BranchDataSO スクリプタブル・オブジェクト作成用のクラス。経路の情報(RailPathData)を List で管理することにより、データベース化する機能を有する 作成したスクリプタブル・オブジェクトはアセット扱いになるため、ヒエラルキーには依存しない。DataBaseManager に登録して情報をゲーム内に提供する ・PlayerController プレイヤーの情報を管理するクラス。体力や弾数などを管理し、外部のクラスに情報提供するクラス。リロード処理、敵の攻撃の当たり判定なども管理する カメラのゲームオブジェクトにアタッチする。AR Camera、あるいは Main Camera ゲームオブジェクト ・EffectManager エフェクトの管理を行うクラス。Create Empty で新しいゲームオブジェクトを作成してアタッチする シングルトンで作成し、どのクラスからでもアクセスしやすい状態にする。エフェクトなどは個別のゲームオブジェクトに持たせないようにし、管理を簡便化できる ・RayController 画面のタップ処理(マウスの左クリック)を判定し、弾が発射できるかを管理制御するクラス。 PlayerController から弾数の情報を提供してもらい、PlayerController の弾数の値を更新したり、リロードさせる命令をだす カメラの子オブジェクトとして Create Empty で新しいゲームオブジェクトを作成し、そこにアタッチする
移動の処理については、最初の３つのクラスで完結するようにしています。
RailPathData が移動の情報を管理し、それを GameManager が参照して、RailMoveController に移動するように命令を出します。
これを繰り返して移動していきます。
上記の他に、イベント用のクラスがあります。それはクラスの継承を活用したクラスになるため、次の項目で説明します。
それ以外にも敵用のデータ管理クラス、敵の部位を管理するクラスなどを作成していきます。最終的なクラスの数は30前後の予定です。
クラスの継承とクラス図
プレイヤーの攻撃対象として利用するゲームオブジェクト(攻撃して破壊できるもの)に対して、クラスを継承させた設計を行うようにします。
最も最上段にあるクラスは EventBase クラスです。一番のスタート地点になるクラスを親クラス、あるいは基幹クラス(スーパークラス)と呼びます。
このクラスは MonoBehaviour クラスを継承しています。
EventBase クラスは abstract 修飾子を用いた抽象クラスとして作成をしています。
抽象クラスは、それ単体ではインスタンスが作成できないクラスです。つまり、いずれかのクラスに継承させる前提で設計を行うクラスになります。
EventBase クラスでは、プレイヤーの攻撃があたった際の処理を実行するメソッドを作成しておきます。
これは、敵であっても、アイテムであっても、障害物であっても、すべて「プレイヤーが攻撃した際に処理を行う」といい共通部分をメソッド化しています。
EventBase クラスを継承したクラスが２種類あり、敵用の EnemyBase クラスと、アイテム用の ItemContoller クラスです。
他にも障害物用に利用することも出来ます。
EnemyBase クラスは敵用の基幹クラスとして利用するためのもので、敵の処理の内、すべての敵に共通する変数やメソッドを記述しておきます。
ItemContoller クラスも同様で、アイテム用の基幹クラスとして、アイテムに共通する処理を記述しておきます。
この２つの、親クラスを継承しているクラスを子クラス、あるいは派生クラス(サブクラス)と呼びます。
いつも Unity で作成するクラスは、最初に MonoBehaviour クラスを継承しています。そのため、そういった意味では、
いつも作成しているクラスも、MonoBehaviour クラスを親クラスとし、その子クラスとして作成を行っていることになります。
クラスの継承はクラス名の右側のコロン(:)の右側に、１つだけ継承させることができます。
継承できるのはクラスだけです。同じ場所にインターフェースを記述することができますが、これは書く場所が同じであっても継承とは呼びません。
インターフェースの場合は「実装する」と使い分けます。
EnemyBase クラスはさらに子クラスとして、EnemyController_Normal クラスがあります。
継承を行うと、それ以前のクラスの情報はすべて継承していることになります。
EventBase => EventBase と MonoBehaviour EnemyBase => EnemyBase と EventBase と MonoBehaviour EnemyController_Normal => EnemyController_Normal と EnemyBase と EventBase と MonoBehaviour
このように、子クラスになればなるほど、親クラスから継承するクラスが増えていきます。
EnemyController_Normal クラスでは、それまでに継承しているクラスの情報に対して、足りない情報のみを変数やメソッドとして追加するだけになります。
つまり、敵１と敵２の処理のうち、共通していない部分が２か所あるのであれば、その部分だけを EnemyController_Normal クラスに記述するだけで
敵としての機能を有することになります。
継承したクラスの情報(宣言フィールドでの変数、メソッド)は自動的に実装されます。これは、子クラス内に記述する必要はありません。
そして、明示的に子クラスに親クラスのメソッドを記述することで、親クラスのメソッドの内容を上書きできます。
これをメソッドのオーバーライドといいます。オーバーライド可能なメソッドには virtual(バーチャル) キーワードを宣言しておきます。
この virtual キーワードのあるメソッドのみ、子クラスは override(オーバーライド) キーワードを記述することで上書きしたり、親クラスの処理に加えて
子クラスの処理を追加したり出来ます。
例えば EnemyController_Normalクラスから見ての親クラスは、EnemyBase、EventBase の両方を指していますので、
その両方のクラス内にある virtual キーワードのメソッドがオーバーライド可能なメソッドとなります。
実際に処理を実装する際に再度学習しますので、そういった機能があることを覚えておいてください。
＜親クラス(EnemyBase)＞
protected virtual void Update() { // 親クラスには virtual キーワードでメソッドを用意する
}
＜子クラス(EnemyController_Normal)＞
protected override void Update() { // 子クラスには virtual キーワードのあるメソッドのみを orverride キーワードに変えることでメソッドの内容を変更できる
}
このオーバーライドの機能によって、同じメソッドを実行した場合でも処理の内容が変わります。これを振る舞いを変えるといいます。
クラスの継承やオーバーライドの機能はオブジェクト指向型プログラムにおける多態性(ポリモーフィズム)という考え方の１つになっています。
参考サイト
G学院 様
多態性(ポリモーフィズム)
https://gimo.jp/glossary/details/polymorphism.html
以上でこの手順は終了です。
=> 次は 手順１ です。
コメントをかく