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 | このブログの読者になる | 更新情報をチェックする

2017年05月14日

昔より状況はずっと良くなったんだけども

久々の更新です。最近多忙だった物で、申し訳ないです。

さて、最近私はUnrealEditor4(以下UE4)をいじくることが多くなりました。
かつてはValveのソースエンジンによるHammerEditorでMODなんかを作っていた私ですが、同じレベルエディターであるUE4は面白いエディターなので、よく触ってます。
というか今おもいっきりUE4関連のお仕事をさせてもらってるような状態なので、嫌でもいじくることになる環境になってしまったのですが(爆
ks_ue4_01_1.jpg

というわけで遅かれ早かれUE4については話題として触れなきゃあかんよなーとは思っていたのですが、中々踏ん切りがつきませんでした。
何故なら、正直UE4は出来ることが多い分、複雑で奥が深いので分からないことや不明なことが多すぎ、書いてもコレで合ってるのか?という疑問符が常につきまとう状態になるうえ、それ故に不満点も多く結局愚痴を並べるだけのネガティブな記事になりがちになることが容易に想像できたからです。

でもUE4関連の記事は未だ国内で少なく、正直な意見もあまり見られないので、長年レベルエディタ(HammerEditor)を触ってきた人間の意見は多少なりとも参考になるであろう、と言うことで、今回書く決心をしました。
とりあえず一度には書ききれないので、定期的に更新するようなシリーズ物になると思いますが、まあふっと気が向いたら書く、くらいのレベルになると思われます。
チュートリアルみたいな解説というよりは所感的な記事ですけど、いずれはそういう解説的なのもシリーズとしてやっていけたらいいですね。


さて、レベルデザインツールは海外ではとうの昔にゲーム開発に取り入られ始めてましたが、ようやく国内でもレベルエディタを中心としたゲーム開発が浸透し始めてきたようです。
かつては全てのゲームの基盤というものはプログラマーといった専門職の人達が作り上げて来たもので、一般の素人には茅の外の出来事でした。
しかしレベルデザインツールの登場で、ゲーム開発が効率化され、プランナー職や専門的な知識のない一般の人でもゲームの基盤を作成するのが昔より遙かにたやすくなってきました。
それこそ個人でゲームを作るような小規模な開発に、これらレベルデザインツールは欠かせない物になりつつあります。絵描きの人がフォトショやMAYAを使うようになったのと同じように、ゲーム開発者がこうしたレベルデザインツールを使うようになった、と言えるかもしれません。良い時代になった物です。


現在はレベルエディタといえば、このUE4かUnityか、というくらい、この2つの勢力が大きくなってますね。
特にUnity勢は大きく、最近はこれで作られたゲームを本当に多く見かけるようになりました。
それ故に国内では既にUnityに関する書籍も多く出回っており、ネットでも多く情報を見つけることが出来ます。
そういう意味では国内でUE4は出遅れており、得られる情報はまだ英文が大半を占めます。リファレンスが日本語化されており数人のUE4マスターによるレクチャーがネットにあるおかげでまだ救われてますが、この点はまだまだこれからと言った段階です。
ちなみに個人的には、もっと他のレベルエディタやエンジンも頑張って欲しい(選択肢は沢山あった方が楽しい)ので、今の現状はあまり嬉しい状況ではないかもしれません。それこそCG界ではフォトショの一人勝ち状態になってますが、そういった選択肢のない状況になるのはあまり好ましい未来ではないですね。ここはひとつVALVEのソースエンジンには巻き返しを期待してしまう所ですが・・・。


で、実は私もUE4を触る前に、Unityを数ヶ月ほど触って色々勉強はしていたクチです。で、触ってみた感想として、あくまで個人的意見ですが、Unityをレベルデザインツールとして私は認めていません。
その理由は、Unityがガッツリとスクリプトむき出しのツールだからです。
ks_ue4_01_2.jpg

つまり、何をするにもスクリプトを書かないとゲーム的制御が何一つ出来ないツールなので、その時点で「誰でも簡単にゲームの基礎を組み上げることが出来る」という私が最もレベルエディタに求める要素を端から否定してしまっているため、プログラマーによるプログラマーのためのツールである、というのがUnityに対して私が出した結論です。

ですが、実はUnityにはビジュアルプログラミングを可能にするアセットが幾つか出回っています。(アセットというのはまあプラグインみたいな拡張機能みたいなもの)
それをいれることで、直接プログラムを書かなくても、フローチャートを繋げていくような感覚でゲーム制御を組み上げる事が可能ではあります。
ks_ue4_01_3.jpg

ただ、これらはあくまでサードパーティのアセットでしかないため、日本語による解説も極めて少なく、これですべての制御をまかなえるほど万能ではないので、結局中途半端であまりオススメできる物ではありません。
その中でも有名な「Playmaker」を買って試したりもしました。実際、だいぶ簡単になるのですが、やはり途中から日本語のドキュメント不足により理解が追いつかなくなるので途中で諦めてしまったというわけです。


ではUE4ではどうなのか?
実はUE4は最初から公式にビジュアルプログラミングを取り入れています。
これはブループリントと呼ばれ、Playmakerと同じように、フローチャートを書くようにノードを繋げてプログラムを書くことが出来るのです。
アセットではないため公式のリファレンスにも日本語で解説されているので、そういう意味ではUE4の方がこの点に関しては先を行っています。

私がUnityからUE4に乗り換えた最大の理由がこれでした。やはり、「プログラミング知識がないと何も出来ない」という呪縛から少しでも解き放とうとしている姿勢がUE4から感じ取れたからです。
また、基本的にハイエンド向けのエンジンなため、見た目が豪華であり、いとも簡単にリッチな画面を作成できるのもUE4の魅力の一つです。
その代わり相当にハイスペックなマシンを要求されてしまいますが、まあ普段FPSをやってるようなゲーマーなら余裕ですよね?(え
ks_ue4_01_4.jpg

ただ、色々触ってみて分かったのですが、このブループリントも様々な問題を抱えていて、手放しで賞賛できる物では残念ながらありません。
あくまでUnityと天秤で量った場合に勝っているだけで、決して扱いやすい代物とはお世辞にも言い難いです。
その理由は、このブループリントが極めて本格的なビジュアルプログラミングツールであるが故に、これで全てのゲーム制御をまかなえる代わりに非常に複雑で素人にはぱっと見よく分からないという代償を負っているからです。
ks_ue4_01_5.jpg

この点については追々詳しく解説しますが、もっと素人にも分かりやすい基本セット的なノードを別途用意するなど、色々やりようはあるはずで、まだまだ改善の余地があります。
しかし、 UE4側は素人向けよりもあくまでプログラマーに対して使って欲しい事前提でプループリントを組み上げている印象があるので、よりどんどんと専門的になっていかないか懸念もあるのですが・・。


というあたりで今回はこの辺で。早速もう不満爆発みたいな感じになっちゃいましたが(爆
ですが、これはUE4に期待しているからこその意見であり、実際UE4は触っていて面白いツールなので、是非とも良い方向に改善していって欲しいですね。
次回は、例のブループリントについて詳しく語ろうと思います。




web拍手 by FC2
posted by KS(Koumei Satou) at 21:35 | Comment(0) | TrackBack(0) | UE4 | このブログの読者になる | 更新情報をチェックする