つぶやく「24Frameの邪道経営哲学」第4回：Unreal Engineに注意する時の哲学
 |
「Unreal Engine（UE）のハードルの本質」
 |
ゲームが各社の自社エンジンではなく，Unreal Engine（UE）やUnityなどのミドルウェアで作られることが多くなってきた昨今のゲーム業界。
しかし一般的にUEは難しく，Unityは使いやすい，などの通説もあります。前回UEでの試作を公開させていただきましたが，それを通じ僕なりに分解したことをここに記しておきます。
確かに前回の試作は「難しい？ どこが？」というレベルの爆速で組みあがりました。そして「概ね面白い」という手ごたえも感じることができた。しかし，ここからが問題なのです。コマンドで行われるアクションの中，その面白さを邪魔するノイズをどれだけ少なくできるか，が次の勝負になっていきます。それは主に「ここをもうちょっとこうできたらな」という要望としてプログラマーに降り注ぎます。
ちなみに，前回の試作ではプログラマーは一行もプログラムを書いていません。では「プログラマーがいなくていいのか？」というと違います。主にプログラマーは「Blue Print（BP）」という機能を使い，あの挙動を実現していました。
「ブループリント（BP）はその名の通り「青写真」である」
 |
BPとはその名の通り青写真。プロトタイピングのためにあるような機能です。厳密には，いわゆる本実装でも使われる部分もありますが，やはりあくまでも「青写真」であることには一定の注意を払わねばなりません。
主にこの機能の恩恵を受けるのはアートとプランニングです。UEにおけるゲーム制作では，いわゆるデザイナーとプランナーと呼ばれる人たちが，プログラマーの用意したブループリントを組み合わせどんどんゲームを形にしていきます。ブループリントをつなぎ変えたり数値を変更したりするだけで，どんどん手元で動作が確認できます。
以前は一度できたデータをプログラマーに渡して実装してもらったうえで初めて手元での確認が可能になったものですが，その「プログラマーさんお願いします」をすっ飛ばしてどんどん作業を進めることができるのです。
ここまで読んで「おや？」と思った人もいらっしゃるかもしれません。そうです。確かに上述の通りであれば，デザイナーとプランナーだけでなく，プログラマーもいちいち「プログラマーさんお願いします」がなくなっているし，これは全員が幸せになってるじゃん，という構図のように見えるのです。しかしこれはUE導入初期に多く見られる，UE最大の誤謬といっても過言ではないでしょう。
「誰がBPを作るのか？という問題」
 |
BPは「ゲーム制作を操作しやすく簡略化したもの」といえるかもしれません。しかしこれはあくまでインタフェースなのです。BPの向こうでは今までのゲーム制作と同じく，超複雑なプログラムが複雑に絡み合って動いています。それを目の当たりにしなくてよくなった，というのは確かにありがたいことではあります。特にプログラムを理解する必要が元々薄かったデザイナーとプランナーの仕事の領域においては。
しかしプログラマーはそんなことありません。結局のところ，超複雑なシステムをBPに落とし込み，各パートの要望に応えていくという仕事のスタイルは基本的に今までと変わりません。
とはいえUEはライティングやシェーディングといった基本機能の充実ぶりが半端ないのもまた事実。今まではそこも各社で一から，だったのが，今は導入と同時に基本機能はできた状態，というのはプログラマーにとっても大いなるメリット。しかもプラグインまで視野に入れれば，モーション制御やUI制御などもカバーしているアセットが大量にある。やはりUEは万能なのではないでしょうか？
「ここをちょっとだけこうしたい」という問題
 |
例えば我々も導入してみた「Advanced Locomotion System v4」。これは導入した瞬間にAAA級のモーション制御が動き出す，まさに魔法のようなツールです。前回の試作のような青い仮のモデルのキャラでもすごくリアルに動いているのが分かります。
となると次はこのモデルだけオリジナルに差し替えれるだけで，少なくともモーションとモデルはすぐにでも商品レベルに達するぞ！UE万歳！という訳です。
そして気合を入れてオリジナルモデルを作って，実装！ ここまで二週間！ マジかよ！ ワクワクは高まるばかりです。
しかし，奇妙なことが起こります。基本的に元気に動いている我々のオリジナルモデルですが，ある一点だけバグっている。それは死んだとき。死ぬと手足の力が抜けてダラーンとした状態になるあれ（正式にはラグドールというんですが）これのときだけ，なぜかモデルが痙攣する。「なんでなんだ？」と調査しますが，一向にそれがはかどりません。それは，元々ALSV4がどうやって動いているのか，詳しいことは我々にも分かっていないからです。
「アセットストアの駆使」
 |
食い下がる手はいくつかあります。商業利用可能なモデル，というのは実は結構ネットで売られていて，しかも「ALSV4 Ready」（つまりALSV4に対応していますよ，ということ）なモデルなんかも結構な数あります。これを使えば上記のようなバグはなくなることもあります。
または，死んだときの処理をラグドールではなく専用の死にモーションに差し替える，という手もあります。しかしこれも考え物で，ラグドールのチャームさはなくすには惜しい，という問題がまず一点。まあそれはバグには代えられないとしても，その死にモーションの差し替えもどうやって動いているか分からないALSV4の中につっこむのはそれなりの慎重さが要求されます。
そもそもゲームの顔である主人公キャラが借りてきたものでいいのか？（まあこれはどういうゲームを作るかによりますが）という問題も残ったまま。いや，がんばればできるんですよ。調査し，一手ずつALSV4をデバッグし，検証すれば，いつかゴールにたどり着くことはできます。しかしそれをやるのと自分たちで一から制御を作成するのと，どっちがいいのか？ というのはこの場合は考えものです。そもそもALSV4のモーションすべてがこのゲームにとって必須だったわけでもないし……。
「必要な機能のキュレーション」
 |
あまりに底の浅い問題に思えるかもしれません。しかしこれは実はUE全体で起こり得ることなのです。UEはソースコードも公開されていますし，エンジン全体を自由に書き換えて改造して使うことさえ理論的には許容されています。
しかしそんなことができる時間を持つプロジェクトというのは世界でも一握り。小さなチームが小さなゲームを作るには「Unityのほうがいいんじゃね？」みたいな気もしてきます。そもそも上記の作業はUEではすべてC++というプログラム言語で書いていく必要がありますが，Unityなら要所のカスタマイズをC＃というやや簡単な言語で書いていくことができます。
そもそも公開されているとはいえ数十万行のプログラムを紐解いて自由自在にカスタムできる人間など世界に何人いるのでしょうか。その時間を与えられている人間も。それはもうUEの設計者じゃないのか？ という気さえしてきます。
そしてさらにはUEの設計思想は普通じゃちょっと思いつかないようなトリッキーな書き方もしばしば。後に「だからそうなっていたのか！」と教えられることはあっても，それに対し真っ向から取り組めるのは，やはりUEそのものを作るレベルでのセンスや見識が必要になってくるのです。
いささか話が飛躍しました。上記のような特性はありつつ，うまくやっている小規模なプロジェクト，というのもあるにはあります。例えば「STRAY」なんかはそうですよね。
「小規模でUEをうまく使った作品」
 |
これは歩く，ジャンプ，会話などシンプルに整理されていて，そこに絞って上記のような渦かしい課題をクリアしていたったものと思われます。実に美しいゲーム。あまりに美しいので僕も思わずしゃべりたくなってこんなことをしています。
結果から言うとこれに比較しても現状の我々の想定はサイズがオーバーしてる気がします。そもそも複雑な要素を伴うRPGではなく，その前にシンプルなものをいったん完パケにまでもっていってみるべきでしょう。
という訳でいったん要素をリダクションし，シンプルにまとめてみました。
こちらは追ってSteam上からダウンロード可能な状態にしておこうと思いますので，みなさましばしお待ちください。
「改めてプロトタイピングが始まる」
 |
さて，ここでも「制限」が以下にゲームにとって重要であるかが浮き彫りになってきました。制限された要素を極限まで煮詰めて新たなゲーム体験を生む，というのが我々の次にやるべきことです。そのためにはまず自分のやりたいこと，を極限まで煮詰めて言語化することが必要でしょう。試作の顛末は動画で確認していただくとして，次回は改めてその旅に出たいと思います。
次回は，改めてそんな不詳なる我々の「コア」に迫る旅にお付き合いくださいませ。それでは次回も乞うご期待！
