UE4を用いたTPS制作事例 EDF:IR パラメータ管理実装実例

UE4を用いたTPS制作事例
EDF:IR
パラメータ管理実装事例
株式会社ユークス
テクニカルディレクター
野津翔太郎
©2019 YUKE'S ©2019 D3 PUBLISHER

はじめに
・4.19.2がリリースバージョンです
・本日お話する内容が、先日リリースされた4.23でも同じ動作をするかは
保証できませんのでご了承ください
・参考情報程度ですが、開発期間中に4.20.2までは動作確認しました
・原則としてエンジンは改造していません。必要最低限のバグ修正やCLの
取り込み、一部エディタの機能調整のみ施しました

パラメータ管理
・ゲーム制作にパラメータはつきもの、むしろパラメータがゲームの面白さを
決めると言っても過言ではない(野津調べ)
・しかし、UE4でパラメータをどのように扱うべきなのかはわからなかった
・そこで、プロトタイプを作るタイミングで、まずはブループリントをベースに
作ってみることに

プロトタイプでの試行錯誤

ブループリントをベースにした管理
■プロトタイプ時点で想定されたパラメータ
・自キャラのアクション周り・武器2種類
移動速度やジャンプ力などアサルトライフル/ロケットランチャー
・敵2体(アリ/ロボット)とそれに伴うアクション
移動速度や切断部位のリストなど
・敵の攻撃(武器として実装)
アリの噛みつきやロボットのビームなどなど(全5種程度)

■運用開始1か月ほどでゲームデザイナーから悲鳴が
・パラメータの所在が散らばっていてわかりにくいのでしんどい
・基底クラス？派生クラス？？なにそれ？結局どれを触ればいいの？
・プログラマーがブループリント(の処理部分)をずっと編集中で、
ぜーんぜんチェックアウトできないんですケド

・プロパティマトリクスという、複数のブループリントを一度に編集できる機
能があるらしい
・これを使うことで多少の手間は緩和されたが、ブループリントを編集すると
いう状況からは抜け出せていないため、あまり効果は上がらなかった

・パラメータ自体の一覧性が低く、またパラメータ操作が非常にやりづらい
・ブループリントを
開く際の右クリックで
コンパイルが走るため
それも地味につらい

・さすがに効率が悪すぎるので色々調べたところ、どうやらパラメータをマトリ
クスで扱う「データテーブル」というアセットがあるらしい
・(2016年当時は)情報が少なかったが、見た目はエクセルのようなシンプ
ルなマトリクスのようで安心感がある

・UE4でパラメータを扱うにはこれを使うのだろうなということが直感的にわ
かるシンプルかつなじみ深いインターフェースだったので、特に迷いなくパラ
メータをデータテーブルに移動
・各ブループリントに使用するパラメータのIDを設定し、BeginPlay時に
データテーブルからパラメータを取得する処理を書いた

■しかし、データテーブルを使った作業も効率が上がらない
・プロパティマトリクスと同程度のインターフェースで快適とは言えない
・どのパラメータを使用するかのIDを結局ブループリントに書く必要があっ
たので、煩雑な管理を脱したとは言えない
・パラメータはデータテーブルに移行したものの、着弾時のダメージエフェク
トやマテリアルなどのアセット参照は直接ブループリントに設定していたため、
結局設定が二分化されただけ ©2019 YUKE'S ©2019 D3 PUBLISHER

プロトタイプを終えて
・とりあえず数が少ないので何とかなったが結構ツライという印象
・本制作は武器、敵の攻撃に加えてビークルやアイテムも含めると数百種
類のパラメータを作成する必要があった
・更に、同じ武器やアイテムでも、威力や速さが異なるものも存在しうるの
でもっと増えそうな雰囲気もあった
・この調子で作ると開発に15年くらいかかりそう

プロトタイプを終えて
・そこでゲームデザイナーと相談し、今後どのようにパラメータを調整していく
のか話し合い、本制作に挑む前に新たな環境を作ることに

本制作パラメータ管理へ
■ブループリントをベースにした管理における問題点のまとめ
・ブループリントで値を設定するには一覧性がなかったり値をまとめてコピペ
などの一括操作がしにくかったりと不便が多い
・プロパティマトリクスも使ってみたが、一覧性のなさは改善されず、柔軟な
入力はできない

・データテーブルを用いた運用も試してみたが、プロパティマトリクスと同様
に入力ツールとしての貧弱さが気になった
・データテーブルは値のみ扱うため、計算式を入れたい場合は事前に手計
算したものを直接入力するしか選択肢が無かった

・武器の種類を追加するたびにブループリントを追加するのは面倒
・そもそもブループリントが武器だけで200や300にも膨れ上がる前提の設
計を容認できない

■新たに作成する環境のポイント
・パラメータの追加やコピー、一斉編集はやりやすいように
・武器や攻撃の種類が増えてもブループリントが増えないように
・ゲームデザイナーが自由にパラメータを追加できるように
・どうしても個別のブループリントが必要な場合の追加は許容する

本制作

パラメータ入力までの流れ
・パラメータのインターフェースとしてはデータテーブルを使用
・ただし、データテーブルを直接修正するのは禁止し、CSV or JSONをイ
ンポートして運用することを大前提に

・ツールはエクセル、データはJSONに決定
・エクセルは、使用するメリット、デメリットはそれぞれあるが、
→ツール操作の習熟コストをほぼ無視できる
→インハウスツールと違って保守の必要がない
→フィルタ機能やグループ機能があるのでデータを扱いやすい
という点がとても素晴らしかった

・パラメータの数もさることながら種類自体も増えることが懸念された
・ざっと挙げるだけでも自キャラの動き、敵の種類、武器、弾丸、アイテム、
ビークル、プロップ、建物などなど…
・エクセルファイルの数が膨大になることは容易に予想できたので、各ファイ
ルへのJSON出力機能の導入は手軽にできるようにしたい

最小限の手数でパラメータを追加するために
■共通フォーマットの策定
・エクセルの上部or左部にデータ形式とパラメータ名を決めるためのエリア
を用意し、パラメータの開始位置、終了位置をマーク
・出力スクリプトによりセルをパースし、必要なパラメータを必要な型と共に
取得し、JSONに出力できるように

■共通フォーマットの策定
・データテーブルのインポート処理が柔軟なため、基本的には
int/float/string/boolを出力できるようにすれば動いてくれる
・本作ではより便利にするためにenum/array/structにも対応

■enumとは？
・ザックリいうと、パラメータに名前を付けたもの
・このパラメータが0の時はアイドル状態、1の時は攻撃状態…などと数値
に暗黙の意味を持たせると、使用者がわかりにくかったりバグが出やすかった
りする
・そこで、その数値に名前を付けることでこれらのリスクを軽減できる

・UE4のenumをパラメータから設定
・Only Referenceがonのものは
パラメータからは参照されるがenumの
ヘッダファイルは出力しない

・応用で、boolもenumとして
定義することで、入力が簡単に

・この対応により、全てのパラメータは共通フォーマットで表現することがで
き、別途ツールを作成せずに済んだ
・出力スクリプトもだいたい300行くらいの小さなサイズでおさまっている
・結果、かなりコンパクトな仕様で大量のパラメータを管理することができた

■ 水平形式と垂直形式
←↓ それぞれ同じ
パラメータ

エクセルのペーストオプションで転置が簡単にできる

■ Auto Reimport
・エディタ環境設定の「ロード＆保存中」
・簡単な設定ですぐに使えるのがポイント

■ Auto Reimport
・基本的にはディレクトリをマップしておくだけ
・設定すれば、アセットの作成や削除も勝手にやってくれる
・各パラメータエクセルから出力ボタンを押すと、エディタが即座に反応し再
インポートしてくれるのでイテレーション速度を更に上げられる結果に

■ Auto Reimport ないとき～
１．パラメータを編集する
２．出力ボタンを押す
３．エディタで該当のデータテーブルを探す
４．データテーブルを右クリックしてパラメータを再インポートする
５．PIEで動作を確認する

■ Auto Reimport あるとき～
１．パラメータを編集する
２．出力ボタンを押す
３．エディタで該当のデータテーブルを探す
４．データテーブルを右クリックしてパラメータを再インポートする
５．PIEで動作を確認する

■ パラメータ参照
・別エクセルを参照し
パラメータの独立性を
高め、コンパクト且つ
見通しを良くする
・ここではギアID100の
パラメータを参照

・別に用意したギアエクセルのIDが100の列を参照していることに

・これで、ギアのパラメータはこのエクセルにまとめることが出来る
・更に、ソルジャーNPCだけ
でなく、他のパラメータから
参照することもできる

・パラメータ参照とそれによる連鎖はかなり多用している
・例えば「武器」から出る「攻撃」によって与える「ダメージ」の実行時に発生
する「エフェクト」「デカール」
・更に、「ダメージ」により「建物」を破壊した際に発生する「衝撃(攻撃)」が
トリガーとなる「ゲームパッド振動」「エフェクト」
・「」がそれぞれ全てパラメータとなっている

・「エフェクト」「デカール」「ゲームパッド振動」などのパラメータは、参照先に
アセットのパスが書いてある
・ハードリファレンスでなくソフトリファレンスで持つことで、パスが書かれた
データテーブルをロードした際にメモリ使用量が爆発することを回避
・パラメータを読み込む際に、芋づる式にロードする

・ソフトリファレンスで持つことでロード処理は自前で書く必要が出てくるが、
ハードリファレンスを避けることで必要最低限のアセットを網羅的にロードで
きるというメリットがあるので、作業コストと得られる効果のバランスは良い

まとめ
・これらの施策によりゲームデザイナーのパラメータ調整およびアセット量産
の速度を爆発的に向上させた
・「パラメータの量も種類もめちゃくちゃ増えそう」というプロジェクトの展開
を予想したこと、入力担当者であるゲームデザイナーと入念に話し合ったこ
と、そしてそれらの予想や話し合いにちゃんと時間を割いたことが大きく功を
奏した

まとめ
・何より、完全とは言えないまでもUE4でパラメータドリブンな制作環境を
構築できたのは、プログラマーのコスト削減にもつながった
・結果として、目標としていたプログラマーとブループリントを必要としない
ゲームデザイナー作業のみでの武器の追加が実現できた
・アセット参照を採用したおかげで、一部のアートアセットの登録とパラメー
タ入力作業はアーティストとも分担できた

まとめ
■あったらよかったと思う機能
・パラメータのデータ型に応じたセル書式の自動設定機能
・アセット参照しているセルの、別エクセルファイルへの自動リンク機能
・どこからも参照されていない行の検出機能

ちなみに
・パラメータがめっちゃ増えるということは、パラメータを使うプログラムの量
も増えるということなので、プログラマはめっちゃ頑張って実装しました

後日追記：質疑応答
Q：エクセルを使用したということで、複数人作業の際にマージが大変だったと思うが、どのように解決
したか？
A：エクセルを使用する際に起きうる弊害として、作業当初からその問題は認識していた。正直、完全
な解決は難しいと考えていたので、緩和策としてエクセルの内容自体を複数に分けてしまい、作業者自
体を別々にするようにしていた。例えば武器なら自キャラの武器、NPCの武器、エネミーの武器、ビー
クルの武器、アイテム(手榴弾等)などにカテゴライズしてしまい、それら毎にエクセルファイルを用意し別
途用意した「どのエクセルを武器出力に使用するか」を記載するためのエクセルを用い、そこから出力さ
せるようにした。分割する弊害として、データの追加(メタ情報の追加)を行う作業が手作業だと煩雑に
なってしまうため、データ追加用のスクリプトを用意し、そちらを用いて関係するエクセルには全て同様の
データを追加できるようにした。

したか？
A：作業者分割と出力例
武器エクセル自キャラ武器
エネミー武器
ビークル武器
アイテム系武器
出
力
要
求
武器パラメータ
JSON
出
力
Aさん作業
Bさん作業
Bさん作業
Cさん作業

したか？
A：パラメータ追加例
武器エクセル自キャラ武器
エネミー武器
ビークル武器
アイテム系武器
一括で
パラメータを
追加！

Q：エクセル、あるいはエクセルファイルのバージョン管理はどのように行ったか？
A：エクセル自体は社内システムの関係で全員が同じバージョンを使用していたため問題にはならな
かった。パラメータごとのエクセルファイルについては他のデータやUE4のアセット同様Perforceにて
バージョン管理していた。

ご清聴ありがとうございました！

UE4を用いたTPS制作事例 EDF:IR パラメータ管理実装実例

More Related Content

What's hot

More from エピック・ゲームズ・ジャパン Epic Games Japan

UE4を用いたTPS制作事例 EDF:IR パラメータ管理実装実例