UE4ぷちコンの開催期間は1.5カ月

UE4ぷちコンの開催期間は、大体1.5カ月程度です。それでも、実質1日中作業できるような日は、その時の仕事の量や家庭の事情で変動しますが、多くても10日程度になってしまいます。しかも、提出用の動画制作や、説明文を作る必要もあります。

つまり、作品として魅せたい部分と、切り捨てていい部分をハッキリさせないと、作品を作り上げる事自体が間に合わない可能性が出てきます。

そうなると、「切り捨てていい部分も出来る限り切り捨てた事が分からないようにする」という事が大切になってくるので、今回は作品のそんな部分を紹介していこうと思います。

Foot IK(段差に沿った足・膝の曲げ)不採用

ローポリの世界観とすることで、Foot IKの採用を見送りました。ローポリキャラは足が太くて短いので、Foot IKを採用しなくても、それほど見栄えは悪くありません。

足が太い!?

町マップでの車の移動は直線のみ

町マップでは、町の真ん中の大通りを車が走っていますが、実はこの車は大通りを東西方向にしか移動しません。そして、マップ自体がそれを違和感に感じないように、他の道は細かったり、車線を表示しないようにしてあります。

それでも、車にはしっかりとドライバーが乗っており、タイヤは回転しており、一定間隔で段差で突き上げるような動作もしています。

車が道路に沿って曲がったり、止まったりするロジックを組む時間は無かったけど、町マップなのに車が走ってないのはオカシイということで、このような方法を採用しました。

ドライバーの運転姿勢もアニメーションで作ってます

モブキャラの移動はルートに沿っている

本作品のモブキャラはAIControllerで動作させていますが、動きの拘りと、手抜きが混在した実装となっています。

よくAIControllerの簡単な実装例などでナビメッシュのエリアをランダムで移動するという方法を見かけますが、ランダムで移動先を決めてしまうと突然振り返るような挙動をする時があります。

町を歩いていて、突然逆方向に歩き始める人はそうそういませんので、これはリアリティが無いと思い採用しませんでした。

また、実際の歩行者は簡単に道に飛び出す事はありません。普通は歩道を歩いているはずです。(しかし、本作品でモブキャラが警察署に駆け込むシーンがありますが、この時は道路に飛び出す移動した方がリアリティがあると思っています)

このように、モブキャラの移動にリアリティを求め始めると、なかなか大変なロジックとなってきそうです。

そこで採用した方法が、ステージ毎に歩行ルートを定めるという方法です。

ステージには複数の歩行ルートが用意してあり、モブキャラはそのルートに従って歩いています。ルートは歩道や車通りの少ないところを歩くように設定されており、違和感を感じないようになっています。

また、ルートを多数用意し、できるだけ範囲が大きいルートにすることで、同じルートをトレースしているモブキャラが居ても気付かれにくいようになっています。

ビヘイビアツリータスクで、ルートをトレースしながら歩くようなロジックを組むだけで、リアリティのある動作をするので、この方法を採用してよかったと思います。(マップを増やす度にルートを定義するのが少し面倒でしたが・・・)

マップ上に点在する黄色いポールはモブキャラの移動ルート定義です

マップ毎に登場するモブキャラを固定化

本作品は1つのマップで複数のクエストが遊べるようになっていますが、登場するモブキャラはマップ毎に固定されています。しかし、クエストの内容によって、そのクエストだけ登場して欲しいモブキャラもいますので、それはクエスト毎に用意しているデータアセットで簡単に追加できる仕組みとなっています。

つまり、クエストに登場する総モブキャラは、”固定モブキャラ”+”クエスト特有モブキャラ”となります。

チュートリアルステージの神父さまは、他のクエストには登場しないなんて、ちょっと残念ですね・・・

クエストを定義する中で、クエスト専用のキャラクターを配置する情報を記述します

アイテムは簡単に増やせる

これは設計の話しですが、本作品に登場するアイテムは30種類となっていますが、アセットの中からそれっぽいスタティックメッシュを見つければ、すぐにアイテムとして追加することができるようになっています。

唯一の問題は、スタティックメッシュの大きさが、モブキャラの頭部に収まるか否かだけですので、パラメータにて、スタティックメッシュの表示倍率を調整できるようになっています。

アイテムを増やすだけでも、ゲームの幅が広がるので、ここを簡略化できる設計にしておいた事でとても助かりました。

アイテムは全てデータアセットで管理

それでも、スパゲッティになる

散々、効率的・簡略化してきたように書いてきましたが、これはうまくいった部分を抽出して記事にしているからです。

やはり、短い時間で作品を作るとなると、実装時間の為に設計時間が犠牲になる為、動きはするけど無駄が多いソースというものが生まれてしまいます。

見た目的には手間が掛かって無さそうな部分でも、BP自体が複雑なところを見るとすごく残念な気持ちになります。

短時間で素敵な設計ができるようになるには、経験を積むのが一番早いので、これからも作品を作り続けていくことが大切なんだと実感しました。

き、汚い・・・

まとめ

また、私自身はプログラマーとしてはある程度の経験値はありますが、ゲーム制作のプロではないので、上記の内容はプロからしてみたら的外れな部分もあるかと思いますが、温かい目で見て頂ければと思います。

次回

どこまで需要があるか分かりませんが、自分用のメモでもあるので、このシリーズは自由に書いていきたいと思っています。次回は、カットモード(ルーレットでタイミングよくボタンを押す)の実装について語っていきたいと思います。

No responses yet

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です