2017年05月21日

設計図は簡潔にまとめましょう

先週に引き続き連続になってしまいますが、レベルデザインツールのUE4に関しての話題を書こうかと思います。
UE4ってなんぞ?と言う方は前回の記事を参照していただくとして、今回はその中の目玉機能、ブループリントについて、触ってみた所感とかを書いてみます。
ks_ue4_02_1.jpg

前回も軽く話したとおり、UE4では直接プログラミングを書くことなく、ゲーム的制御を構築することが出来る「ビジュアルプログラミング」の機能を搭載しており、フローチャートを書く感覚でゲームを作ることが可能です。それがブループリントと呼ばれる物です。
一部のフローをまかなうといった事に留まらず、全てこのブループリントを使って作ることが可能なので、スクリプトを組む必要はありません。なので、プログラミングの知識が無くとも、ゲームを作成することが可能なのです。

ええ、表向きは・・・・・。


とりあえず何かやって試してみましょう。
UE4ではツールを立ち上げた段階で既に簡単なフィールドと、一人称視点なら銃を持った状態のプレイヤー、三人称視点ならマネキンモデルが既に動かせる状態で始まるので、この辺の複雑な制御は作る事無く始めることが出来ます。
なので、まずはフィールドに何かゲーム的な制御のオブジェクトを配置してみましょうか。
となると、まあ私的に思いつくのはドアの開閉ですかね。
ドア制御はとにかくよく使いますからね、特にFPSでは。

ちなみに、かつて私がよく触っていたソースエンジンのHammerEditorでは、Func_Doorという物が用意されていて、これを該当するオブジェクトに割り当てるだけでドアの開閉を可能に出来るお手軽仕様でした。
HammerEditorでは、こうしたゲーム上でよく使われるであろう制御(回転、スライド、パス移動など)が既に用意されていて、それを割り当てて行くことで動的オブジェクトを簡単に制御できたのです。
ks_ue4_hm_1.jpg

さて、UE4では当然それをブループリントでやるわけですが。
凄く簡単な方法としてシーケンサを使うという手段もあるのですが、とりあえず今回はそれはおいておくとして。
StarterContentフォルダの中にドアのメッシュ(プロップ)があるのでそれを配置します。ちなみにメッシュというのは、まあ要約するとフィールド上に配置可能なモデルデータという事です。
ks_ue4_02_2.jpg

ちなみにこれから動かそうとするメッシュには、プロパティ(詳細)の可動性の設定をムーバブルにしとかないと動きません。これを良く失念して「あれ?動かないぞ?」ってなります。
ちなみにこうしたフォールド上のオブジェクトをUE4では通称アクターと呼んでいます。


準備が出来たので、いよいよブループリント。上のメニューにあるブループリントから、レベルブループリントを選択、するとブループリントが開き、この中でノードと呼ばれる物を組み上げていくことでプログラムを書いていきます。
ks_ue4_02_3.jpg

とはいえ、まずどうしたらいいのかサッパリわかりません(爆)
HammerEditorと違い、ドア制御専用のノードとか用意されてないですからね。
とりあえず最初から配置されている赤いノード(Begin Play)がスタートになるので、ここの後に繋げていきます。
Begin Playはゲームが始まったと同時に命令を伝えるノードです。本当はドアに近づいたら開くとかしたいけど、まあまずは動きを確認したいので。

で、どういたらいいかというと、タイムラインノードというのを使うようです。
画面右クリックでリストが出るので、そこでtimeとか打ち込めばタイムラインが出てくるので、選択します。
ks_ue4_02_4.jpg

タイムラインは、中でグラフを書いて、その動きを別の所に伝える働きをします。要するに、0から100になったグラフを書いたら、それをしかるべき所に繋げてドアに指定すれば、その数値の移動をドアがやってくれるようになる、という事のようです。
なんかもうこの時点で、ん、どういうこと?・・ってなりそうだけどまあ気を取り直してやってみます。

タイムラインノードをダブルクリックするとグラフが出るので、そこでFloatのグラフを新規作成します。
ドアを90度回転させたいので、グラフの開始地点を0にし、3秒の地点に90と指定します。これで3秒かけて0から90という数値移動をすることになります。この段階では、まだ単純に数字の変化だけです。
ks_ue4_02_5.jpg

というわけで次にこれを回転という移動方法に変換しなければなりません。そこで必要になるのがMake Rotator。
これをタイムラインと繋げることで、グラフ数値を回転移動に変換します。
タイムラインには緑のFloatグラフ出力ピンが出来てるので、それをZ軸に繋げます。
ks_ue4_02_6.jpg

勿論これで終わりじゃありません。タイムラインはあくまで数値を出してるだけなので、これをドアに伝える橋渡し的なノードが必要です。
これは色々と種類が用意されてるみたいですが、ここはとりあえずSetActorRotationというノードを用意します。
まあ要するに、任意のアクターに回転移動をセットしまっせ、という事でしょうねこれ。
ks_ue4_02_7.jpg

これを、タイムラインのUpdateの出力ピンと繋げます。あと、回転に変換した数値も伝えなくちゃ行けないので、NewRotationの所にMake Rotatorを繋げます。

あとは、この一連の流れを「どの」アクターに適応するか指定しなくちゃいけません。ここ重要。というわけで、アウトライナ上から該当するドアのアクタを直接ブループリントにドラッグアンドドロップして持ってきます。
あとは、SetActorRotationのTargetと繋げれば完成!
ks_ue4_02_8.jpg
最後に左上にあるコンパイルボタンを忘れずに押して起きます(そうしないと動きません)

さてプレビューボタンを押して確かめてみましょう。
ks_ue4_02_9.jpg


あれ・・・・?

なんか変な位置から始まって反対方向に曲がってますけど?


これ、どうやらSetActorRotationがドアの初期状態からタイムラインの移動を適応してるせいで起きてる現象っぽい。
実はドアを90度回転させた状態で配置してたんですよね。
しかしSetActorRotationはそんなの無視してアクタの初期状態(回転させる前の位置)から開始してしまうので、90度ずれた状態で回転していたってわけ。
じゃあどうするのか?っていったら、タイムラインの数値を、ドアの回転させた分を乗せてしまえばいい、てことで、
ks_ue4_02_10.jpg
ドアを-90度回転して配置していたので、タイムライン上で、0秒の所を-90とし、逆に3秒後を0とします。これでズレが治るはず。

これでやっと意図した動きに。長かった・・・。
というか、それくらいそっちで補完してくれよって正直思うんだけども・・・。
ks_ue4_02_11.jpg


なんかイキナリつまづいたけども、じゃあ今度はスライド式のドアの時はどうするのか?っていう。
やることは大体一緒です。
ks_ue4_02_12.jpg

スライド移動の場合はxyzのベクトル移動になるので、タイムラインでは、Vectorという3軸グラフで指定します。
X軸を0-100と指定すれば、X方向に100m動いてくれるはず。
今度はアクタは回転とかさせずにそのまま配置(笑
ks_ue4_02_13.jpg
架け橋として今度はSetActorLocationを用意して、同じように繋げます。
さあ、今度は素直にちゃんとうまくいってくれるかな?


ks_ue4_02_14.jpg

・・・あ、ずれた。(でしょうね!)


これまたSetActorLocationが、今度はxyzの初期位置で始めてしまうために起きてる現象。要するに、座標0,0,0の位置に持って行ってしまってるわけで。その座標がドアの置いた位置より前にあるので、ずれてしまった、というわけで・・・。

いい加減にしてくれませんか(爆


勿論これを直すのも、タイムラインでずれた数値を乗せてしまえば治るわけだけど、もしドアの位置を移動させたとしたら、タイムラインの数値も変えなきゃならなくなるのは至極面倒。
だがそこは大丈夫、ドアの現在位置を取得して、そこから始められるようにする簡単な方法が用意されています。
これを理解すれば同じ失敗は繰り返さなくて済みそうです。

位置を取得するGetActorLocationにVectorの変数を繋げ、(出力ピンで右クリックして変数に昇格を選択すれば作成されて出てくる)それをタイムラインの前に繋げる。
出来たVectorの変数をゲットで配置し、それをVector+Vectorの乗算ノードに繋げ、されにそれをタイムラインとSetActorLocationの間に割り込むように繋げる。
そしてGetActorLocationに該当するドアと繋げればよし。
ks_ue4_02_15.jpg

これで、ずれることなくドアが開閉するようになるんですよ!
おお、なるほど!








・・・・・って、こんなん分かるかい!!


変数とか出てきた時点でもう素人は「は?」ってなるし、そもそも何故こういう組み方をすれば動くようになるのか、ぱっと見サッパリ分かりません。
詳しく見ていけばそりゃ理解できるようにはなるんでしょう。でも、たかだかドアをスライドさせるような単純な動きをさせるだけでこの複雑な構造になってしまうのは入門的に正直どうかと思ってしまいます。
たとえ理解できたとしても、こういう組み方による解決法を自力で思いつける気が全くしません(爆

要するに、実際プログラムを組んでドアを動かすとなったら、裏ではこういう事をやってるんですよ、って事なんだけども、レベルデザインツールでは、そういった事を意識させないで組むことが出来るようになるのが最終的な理想です。
そういう意味では、ブループリントはあまりに自由に組めることを優先しすぎたあまり、プログラムチックに寄りすぎており、未だ素人が理解しづらいものになっています。

本来なら、HammerEditorのように、素人が理解しやすいような、明快に用途が判別できるノードを別途用意すべきでしょう。
上でやったような一連のドア開閉のブループリントを1個のノードにまとめてしまって、ドア特化の物を用意するなど、もっと単純化することは可能なはず。


というわけで、知識のない人間がブループリントを組む場合、結構なイバラの道なのは確かです。これは残念。
ですが、ある程度分かってくれば、だんだんやれる事が増えてきます。大体単純な動的制御なら普通に出来るようになります。ただ現状、理数系向けの概念なので、文系な人間にはどうしても理解が追いつかない感は否めませんが・・・。
前述したシーケンサも使うことでもっと複雑な動きも出来ますが、まあこれはこれで難点も多いので、それについてはいずれ。
これでゲームを完成させるのは難しいかもだけど、「なんかゲームぽい」ものは簡単に出来るようになるはず。後は自分の努力と、UE4側のビギナーサポートがしっかりすれば完璧でしょう。


今回はこの辺で。次回この話題を上げるのはいつになるか分からない不定期シリーズになると思いますが、またいずれこのネタは出していきたい所存です。

まあそういうわけで、とりあえずUE4はレゴ基本セットみたいな、ビギナー用基本ノードセットを早急に用意しなさい。
さあ、早く早く。




web拍手 by FC2
posted by KS(Koumei Satou) at 22:50 | Comment(0) | TrackBack(0) | UE4 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック