第4回UE4ぷちコン応募作を公開した。
【自作ゲーム】 U(fo)-BOAT 2001 - BowlRoll
自作品は予選を通らなかったようなので、供養のためにここで解説を行いたいと思う。
ゲームの目標
初のぷちコン応募ということでとにかくアイデアを形にして、少なくとも人に見せられる状態にまで完成させるという点が最優先であった。 ゲームコンセプト的な点で言うと、 まず個人的に潜水艦の魚雷戦を扱ったフィクション作品が昔から好きで、これをゲーム化したいとずっと思っていた事、 さらに最近、 Lurking, Dark Echo PERCEPTION といった、音を可視化するようなコンセプトのインディーズゲームが増えてきているのに対して、 なんでこのスタイルで潜水艦を扱ったゲームがないの？って疑問に思っていた事から、 自分で潜水艦のゲーム化に挑戦してみることにした。
現実の潜水艦戦には多数の要素が複雑に絡むため、 なるべくシンプルに抽象化してゲームという形に落とす事にも注力した。 まず当然ながら本来潜水艦は深度を含む3次元での移動が可能な点を今回は２次元に限定したほか、 例えば回避方法にもデコイとしての気泡缶や音響魚雷、あるいは急速潜航といった手段も現実にはあるが、 今回は取り扱わなかった。 もし今後バージョンアップする機会があればこういった要素を増やすのも良いかもしれない。
開発中に気をつけたこと・学んだこと
以下は最初に作ったゲーム「Dangeon and Ossan」を制作中に学んだ事として書き留めていた内容だが、 いままで公開しそびれていたので今回まとめて出してしまうことにした。 実際、潜水艦ゲームでも「Ossan」で学んだ事をかなり応用して作られている。 なので以下のまとめはUE4でのゲームづくりに共通して言えそうな事かもしれない。
単体テストレベル作成を徹底する
私がUE4を勉強するにあたって株式会社ボーンデジタル発行「Unreal Engine 4で極めるゲーム開発」 から多くの事を学んだ。私はこの本のハンズオンを最後まで終わらせてから最初のゲーム（Ossan）の着手に取り組んだ。 もともとUE4のHowTo本は少ないのが現状だが、この本は現時点で最強のUE4習得本であると個人的に確信しているので、 UE4習得中の方々には是非おすすめしたい。
そしてこの本の中で徹底されていたのが 「ひとつのロジックを組むたびに、それを試すための専用のテストレベルをつくり単体テストを行う」 であり、今回の制作で私も徹底している。おかげで問題点の把握に大いに役立った。 単体テストは業務系ではもはや当たり前だが、小規模な個人のゲーム制作では忘れられがちな気がする。 だが効果は絶大なのでちょっとしたものでもテストレベルを作ることは是非おすすめしたい。
プレイヤーの状態管理には列挙型を使っていく
今までは、攻撃中であれば攻撃状態フラグを立てる、ダメージ中であればダメージ状態フラグを立てる、 といったように別々にフラグ管理をしがちであったが、 なにかの拍子に 「死にながら攻撃している」 など、 通常では取り得ない2つの条件を同時に満たしてしまうことで異常状態に陥るケースが頻繁に起きていた。 ダメージ中か、死亡中か、攻撃中か、あるいは通常状態か、どれかひとつしか取り得ないことが予めわかっているのであれば、 早い段階で列挙型への移行をオススメしたい。
また列挙型はデバッグのためにPrint Stringで内容を書きだした時に、 各状態の値の名称そのまま（例えばWalkとかAttackとか）表示できるので、 整数型で状態0とか1とか表示させるよりもずっとわかりやすい。
キャストは早い段階でマクロ化したい
気づくと１つのブループリント内で同じクラスへのキャストをかなりの回数書いてる事に気づく。 AIブループリントなら「Get Controlled Pawn→Cast to 操作対象クラス」の流れは 最初に書いた時点でマクロ化するくらいの勢いでも問題なさそうだ。 キャストの間違いを防げるし、もし後で別のクラスに変更することなっても１箇所を直せば 芋づる式にエラーをたどることができる。
敵の巡回処理は共通化したい
「決まったコースを巡回する」「プレイヤーをみつけると寄ってくる／攻撃する」「見失うと元のコースに戻る」 という敵の行動パターンはもはや鉄板である。これは多数のアクションゲームに応用が効く。 もともと前述の「UE4極め本」で利用されていたロジックだが、 これは便利すぎるので、UE4エンジンの共通部分に組み込んで頂いても困らないくらいだと個人的には思っている。 というわけでこのロジックはいつでも組めるようにマスターしておきたい。 できればオレオレアセットを組んで別のプロジェクトに再利用できるようにしておきたいが、どうすれば効率的かは 現在研究中である。
ビヘイビアツリーはなるべく使いたくない（少なくとも小規模な開発では）
正直、Ossanの開発ではUE4のビヘイビアツリーの煩雑さと不安定さには辟易していた。 行動ごとにブループリントがどんどん増えていき管理が大変になっていき、実際バグの温床にもなっていたし、 頑張って実装しただけの恩恵が、少なくとも今回レベルの開発では充分に受けられなかった感覚があった。 あと、エディタが落ちる。非常に落ちやすい。これにはまいった。 なのでOssanも途中からAI部分はブループリント１枚のみで完結出来るように改造してしまったし、 潜水艦ゲームも実際そのように済ませた。 おそらく、大規模な開発になってキャラのAIを専門に担当するスタッフとの切り分ける目的でとか、 キャラの行動自体が複雑になってきた場合では恩恵を受けられるようになってくるのだと…思う。思いたい。
攻撃モーションやダメージモーションをステートマシン内で管理してはいけない
これはOssanの話。 多分これはUEを触っている人ならもう基本的なことなのかもしれないが、個人的にはひっかかったのでメモしておく。 アニメーションモンタージュがよくわからなかった時はステートマシンですべてを管理しようとしていたが、これは間違いだった。 ダメージモーションは停止中であろうが歩行中であろうが攻撃中であろうが構わず「割り込む」形で再生されなければならないため、 通常のステートマシン内でダメージフラグを立ててダメージ状態に移行して…なんてことをやらせるのは複雑になるばかりでなく即時性もない。 アニメーションモンタージュを仕込んだスロットをステートマシンより下流に接続し、 アニメーションブループリントから直接Play Montageすることですぐさま「割り込む」形で再生ができる。
同様に、攻撃モーションも専用のスロットを用意してステートマシンとは別軸で扱ったほうが良いと思われる。 特にこのゲームでは攻撃モーションのコンボ入力を実現させるために、 アニメーションモンタージュの即時的なモーション移行は非常に有効である。
アニメーションモンタージュ。コンボ発生のたびに各セクションの頭にジャンプする。
攻撃１段目のアニメーションの通知設定。下から(1):コンボ入力受付時間 / (2):攻撃判定有効時間 / (3):剣を振るサウンドの再生
アニメーションモンタージュの基本的な実装方法はこちら。
そしてコンボ攻撃の実装方法はこちら。
- UE4 AnimMontage(アニメーションモンタージュ)について 実践編 - Let's Enjoy Unreal Engine ←※UE4.7までの内容
- UE4 AnimMontageのブランチポイントでのハマりポイントについて - Let's Enjoy Unreal Engine
パッケージ化するときは
UE4のゲームを配布する目的でパッケージングをする必要があるが、 使用していないアセットも含まれてしまうため配布ファイルの容量が馬鹿みたいにでかくなるという 現象が起きる。プレイ時間が５分程度のゲームで2Gとか3Gとかの容量をダウンロードしなければ ならないハメにもなり一般のプレイヤーにとってそもそもプレイする以前の高い壁として立ちはだかる。
容量を減らす手段として、使用中のアセットだけ残してあとは消してしまえれば良いのだが、 この使用中か否かを一つ一つ判定していく作業がなかなか骨の折れる作業である。 使用中のファイルだけを抜き出す手法として、レベルを別のプロジェクトに「移行」するという技が UEユーザー内では一般的に知られている（と思う）。
しかし…
UE4で不要アセットを削除する目的で新規プロジェクトにコピーする際の忘れがちな事（備忘録）：１．ゲームモード設定し忘れ／２．インプット設定し忘れ／３．コリジョン設定し忘れ／４．プロジェクト情報記述し忘れ #UE4Study
— ちょむ (@chom) 2015, 10月 8こういうミスはやらかしがちなので注意。インプットが設定されていないとそもそも操作できないし、 コリジョンが設定されていないと敵が無敵になったりゲームとして成り立たなくなるので特に注意が必要である。
正直そもそもなんで要らないアセットも含めるんだよ、エンジン側でそれくらい判定しろよ、というのが もっともな意見なので今後のUEのアップデートに期待したい。
あと以下の記事も参考になる。
以上、ゲーム２本作ってみて学んだことでした。
