UE4の勉強記録

UE4の勉強の記録です。個人用です。

「Unreal Engine 4.xを使用してRPGを作成する」の足りない部分を作成する 戦闘後のアイテム収得 Part 2

f:id:kazuhironagai77:20210725225509p:plain

<前文>

Minimal Pairのアプリを販売するに当たって一個だけはっきりさせておかない事を書いておきます。

Minimal Pairで練習する事でLとRの音の区別がつくようになるのかは、今の時点では分からないです。こう書くと英語学習の初心者は「RとLの区別は簡単だよ。」と言うかもしれませんが、それは、ゆっくり発音した場合や単語の最初や最後の音がRやLの場合で、アメリカ人が通常の速度で会話した場合でLとRの音を完全に区別出来る日本人(英語がネイティブ以外で)は少なくとも私は会った事がありません。

そのために本当にLとRの音の区別がついているのかどうかのテストもMinimal Pairでみっちりします。そのテストで満点が取れる方のみが「RとLの区別は簡単だよ。」と言う権利があります。

後、LとR以上に日本人にとって難しいと言われれているzとdz、ʒとdʒもみっちりとテストします。

それでですね。

もしかするとある年齢を超えたらLとRの区別はつかないかもしれない可能性もあると思っています。なぜなら絶対音感は子供だけが身に付ける事が出来るように、音素の識別が学べるのはある年齢以下の子供だけかもしれないからです。

その場合はLとRの音素の違いを聞き分ける訓練はやるだけ無駄になります。

ただ100%無駄になるかどうかはやってみないと分かりません。

YouTubeの動画ですが、4年前の動画であるWhy do Japanese mix up "L" and "R"? [1]でJun氏はLとRの区別がつかないとアメリカ人の奥さんから指摘されていますが、最近の動画であるCan Jun finally tell "R" and "L" apart? [2]ではJun氏はLとRのテストを出されてほぼ全問正解しています。

このテストで出された問題の単語の発音は普通の速度で読まれていますし、Jun氏は完全にLとRの区別がつけられるようになったと思われます。と言う事は日本人でも大人になってからもLとRの区別はつけられる可能性はあると思われます。

勿論、Jun氏がどんな訓練をしてLとRの区別がつくようになったのかは分かりません。Minimal Pairの練習ではLとRの区別がつけられるようになるにはならない可能性もあります。

後、もう一つの問題はこの動画で行われたテストは二重盲検法(Double blind experiment)じゃないです。問題を出す側も答えを知っていますし、撮影をしてる奥さんも答えを知っています。だからこの結果だけで日本人でも大人になってからもLとRの区別はつけられるとは言えないかもしれません。

それで言語学の専門家は「日本人は大人になってからでもLとRの区別がつくように成れるのか?」について、どういう見解なのか調べたんですが、これは良く分かりませんでした。

もし出来る様になるのならばMinimal Pairの果たしている役割はどの程度なのかも不明です。と言うか言語学の専門家ってどれだけ信用出来るのかも分かりません。

まあ、そういう訳で問題だらけではありますが、それはVersionをupしながら直していこうと思っています。

それでは今週の勉強を始めます。

<本文>

1.今週の予定

今週は以下の事をやって行きます。

  • Niagara の勉強
  • Cascadeの勉強
  • 石像との会話と石像からのItemの入手
    • それぞれの石像のBack Ground Imageの作成
    • それぞれの石像からItemを貰うときに開くWidgetの作成
    • それぞれの石像のセリフの作成
    • 戦闘中に石像と会話出来ない仕組みの作成
    • 石像を封印する仕組みの作成
  • Warp Passの作成
  • Good Skyの検証

それでは始めます。

2.Niagara の勉強

今週は、先週出来なかったRecreate the Starter Content Smoke Effect in Niagara [3]をやっていきます。もうSub UVの使用方法も大体理解出来たのでそんなに深くはやらないでぱっぱと終わらせてしまいます。

2.1 Recreate the Starter Content Smoke Effect in Niagara [3]の勉強

<Create System and Emitter

先週作成したFX_Smoke emitterの複製を作成しそれのNiagara systemを作成しました。そのNiagara systemにDark Smokeと名付けLevel上に配置しました。

f:id:kazuhironagai77:20210725225627p:plain

<Edit the Emitter Update Settings

Emitter Update CategoryのEmitter State ModuleにあるLife Cycle Modeの設定をSystemに変えます。

f:id:kazuhironagai77:20210725225648p:plain

Tutorialの説明ではEmitter自身がLife Cycleを管理する必要がないから。とありますが、その辺、もっと詳しい説明が欲しいです。

Selfの時には以下に示したようなParameterを全部自分で指定していました。

f:id:kazuhironagai77:20210725225703p:plain

例えばLoop BehaviorはSystemの時は自動的にInfiniteになるのかそれとも別なFactorによってコントロールされるのか?全く分かりません。

調べましょう。

まずはcursorをLife Cycle Modeに合わせて、表示される解説を読んでみます。

f:id:kazuhironagai77:20210725225719p:plain

うん。成程。Systemの時の方が最適化されるので出来るだけSystemにすべきと書かれています。

つまり効率の観点から出来るだけこのParameterはSystemを選ぶべきで、どうしてもEmitter側でLoopingの設定をしなければならない場合を除いてSystemにしておけという事らしいです。

更に、最初の疑問である「Systemの時は自動的にInfiniteになるのかそれとも別なFactorによってコントロールされるのか?」についてですが、それらの値はSystem側から自動で渡されるそうです。

公式のDocumentであるEmitter Update Group [4] も見ましたが同じ事しか書いてなかったです。

うーん。これだけではまだよく分かりませんね。

Emitter State ModuleのNiagara Module Scriptを開いて見ましょう。

f:id:kazuhironagai77:20210725225736p:plain

何を書いてあるのかまだ分かりません。しかしちょっとは読める部分もあるでしょう。

ノードの塊ごとに整理されていてその塊が何をしているのかのコメントが入っていました。

f:id:kazuhironagai77:20210725225750p:plain

例えば、上記のノードの塊はLoop Durationの初期化を行っているとコメントされています。

これなら少しは理解出来そうです。

先程のInitialize Loop Duration Pre Life Cycleの中身を見るともしFixedならとかもしInfiniteならと書いてあるノードなどがあります。

f:id:kazuhironagai77:20210725225804p:plain

と言う事はこの時点でSelfの内容について実装してるのかもと思い、その前の実装を調べると

f:id:kazuhironagai77:20210725225820p:plain

Initialize Loop Duration Pre Life Cycleの前で分岐してる箇所を発見しました。この分岐した一番下の線を追うと

f:id:kazuhironagai77:20210725225836p:plain

ドンピシャです。Systemで計算する時の実装が書かれている箇所を見つけました。

これのノードらが何をやっているのかが分かれば「Systemの時は自動的にInfiniteになるのかそれとも別なFactorによってコントロールされるのか?」についても分かるはずです。

見てみます。

f:id:kazuhironagai77:20210725225852p:plain

何これ?

f:id:kazuhironagai77:20210725225907p:plain

この青い楕円で囲まれてたSYSTEMというマークがついているやつらがSystemから送られてきた値を保持しているParameterでしょう。でもそれぞれのParameterの名前、AgeとかLooped Ageって初めて見るParameterです。何を担当してるのか全く分かりません。

Niagara SystemのParametersからSystem Attributesを開くとそれらのParametersが表示されています。

f:id:kazuhironagai77:20210725225922p:plain

うん。ひょっとしてSelfの時に手動で決定する以下のParameterって

f:id:kazuhironagai77:20210725225937p:plain

実際には存在しなくて、本当は以下の実際のParameterの値が変化していると言う事なんでしょうか?

f:id:kazuhironagai77:20210725225950p:plain

調べて見ます。

はい。

以下のノードを見つけました。

f:id:kazuhironagai77:20210725230030p:plain

Infinite、Once、そしてMultipleの場合においてそれぞれのParameterの値について指定しています。

つまり、Life Cycle ModeがSelfの時のLoop Behaviorの値を示しています。

f:id:kazuhironagai77:20210725230045p:plain

Infiniteの場合を見ると、以下の様にAge、Looped Ageなどの先程、Life Cycle ModeでSystemを選択した場合に設定したParameterと同じparameterの値を指定していました。

f:id:kazuhironagai77:20210725230101p:plain

と言う事は。やっぱりSelfの時に手動で決定する以下のParameterって実際には存在しなくて、本当はもっと細かい値を指定するParameterが実際の値の管理をしていました。

ただし、先程のInitialize Loop Duration Pre Life Cycleの中身にFixedの場合はLoop Durationの値はこっち、Infiniteの場合はこっちと書かれている箇所がありました。

f:id:kazuhironagai77:20210725230117p:plain

全部のParameterが存在しないと言うわけでもないんですね。

この位で深堀は止めて次に行きます。

Spawn Rate ModuleのParameterであるSpawn Rateの値を25にセットしました。

f:id:kazuhironagai77:20210725230132p:plain

こんな感じになりました。

f:id:kazuhironagai77:20210725230147p:plain

この辺は、デザイナーが見た目の良さから最適化すべき値で、Programmingとは直接は関係ないので今回は深堀しません。

<Edit the Particle Spawn Settings

Particle Spawn GroupのModuleの設定を変更します。

Initialize Particle ModuleのLife timeの値を変更します。

f:id:kazuhironagai77:20210725230206p:plain

この値もデザイナーが見た目の良さから最適化すべき値で、Programmingとは直接は関係ないので今回はスキップします。

Color ModeのColorの値を変更しました。

f:id:kazuhironagai77:20210725230227p:plain

ちょっと値を弄っただけで煙の印象が全く変わりました。

f:id:kazuhironagai77:20210725230241p:plain

Sprite Size ModeからSpriteのサイズを変更しました。

f:id:kazuhironagai77:20210725230256p:plain

煙のサイズが小さくなりました。

f:id:kazuhironagai77:20210725230403p:plain

正直、前の方が良かった気がします。

Add Velocity Moduleの値を変更しました。

f:id:kazuhironagai77:20210725230418p:plain

こんな感じになりました。

f:id:kazuhironagai77:20210725230433p:plain

うーん。あんまり変わらないですね。

Particle が発生する箇所をもっと狭めないとへんな感じは無くならない気がしますね。

Sphere Location ModuleのSphere Radiusの値を変更しました。

f:id:kazuhironagai77:20210725230449p:plain

はい。やっぱりParticle が発生する箇所を小さくしましたね。元の値が64でしたので半分の半径になりました。

f:id:kazuhironagai77:20210725230503p:plain

前よりはマシですが、煙の上昇速度が速過ぎる気がします。

<Edit the Particle Update Settings

Acceleration Force ModuleのAcceleration のZ 軸の値を20にしました。

f:id:kazuhironagai77:20210725230521p:plain

Scale Color Moduleのcurveの値を以下のようにしました。

f:id:kazuhironagai77:20210725230537p:plain

結果です。

f:id:kazuhironagai77:20210725230551p:plain

まあま煙には見えます。

Level上に配置した場合です。

f:id:kazuhironagai77:20210725230605p:plain

うん。影はないですがそれ以外はまあまあいいんじゃないでしょうか。

2.2 Smoke Effectのまとめ

Sub UVの使用方法や影の追加方法なども勉強出来たのでSmoke Effectについてはこれで一応終りにします。

UE4でSmokeがどのように作成されているのかは全く想像出来なかったので、Smokeのeffectの作成方法についてかなり深い理解が出来ました。

のでそれをここにまとめておこうと思います。

<その1:Smokeの一つ一つの粒子はSpriteで作成される>

SmokeはSpriteで作成されます。粒子を大量に生成してそれぞれの粒子に常にカメラ側を向いた面を貼り付けるそれです。それぞれの粒子の移動こそが煙が煙らしく見えるための必須条件になります。

<その2:SmokeはSub UVを使用する>

それぞれの粒子が持つ面状でSub UVによってアニメーションが描かれます。それが煙の動きを表します。

f:id:kazuhironagai77:20210725230757g:plain

この二つの働きによってSmoke Effectは作られています。

2.3 Smoke Effectについての考察やまとめ

所で実際の煙の動きはどうなのでしょうか?

このSmoke Effectでやったようにそれぞれの粒子は不完全燃焼をするために煙を発生させ、全体としては沢山の粒子が上方に舞い上がって煙を発生させているんでしょうか?

色んなサイトを見た感じでは、最初から小さい粒子が発生してそれぞれが勝手に舞っているだけの様です。

だから本当の煙を作成する場合はParticleを何十万個と発生させてそれぞれのParticleに煙の粒子を表現させる事になるんでしょうか?

勿論、それでは高コストになってしまうためUE4では上記の方法を採用している訳です。

BlenderのSmokeのSimulationを見るとどうもGridを使用して計算してそうです。流体のSimulationでGridを使う方法と粒子を使う方法があったような気がしますがもう忘れました。

流体力学のSimulation Softはいつかは自分で作成したいとは思っていますが忙しくて勉強する暇がありません。

Real timeで数値解析するんだったらUnreal Engine内で可視化するのもありだと思っているんですがどうなんでしょうか?

UE4や5はゲームだけじゃなくて3D の可視化のツールとしての利用も有効だと思ってはいます。

2.4 Content Exampleの観察

今週は、Niagara Systemで勉強する事が無くなってしまったのでContent ExampleのNiagara systemのサンプルでも見ながら次の勉強に何をするのかを考えます。

<Sprite Facing

Sprite は面が常にカメラに向いていますがそれをコントロールする為の方法が勉強出来るみたいです。

f:id:kazuhironagai77:20210725230847p:plain

地味ですが絶対知っておくべき技術ですね。

<Static BeamとDynamic Beam

Beamは散々勉強しましたがStatic BeamとDynamic Beamの違いが分かりません。

f:id:kazuhironagai77:20210725230905p:plain

<Multiple Rendering

Multiple Renderingそのものについてはそんなに優先順位は高くないですが、この例が素晴らしいです。

f:id:kazuhironagai77:20210725230925p:plain

3次元上での原子核の周りの電子の軌道をこれを利用して表したら面白いなと思いました。

今は小学校の教科書でも量子的な解釈をした電子の雲が原子核の周りを覆っている図しかないんでしょうか。その場合は太陽系の図でも面白いと思います。

<Location Events

これは花火の製作に使えるTechniqueですね。

f:id:kazuhironagai77:20210725230945p:plain

そう言えば花火を作ると言ってすっかり忘れていました。

<Expression

これは何をやっているのか分かりません。

f:id:kazuhironagai77:20210725231003p:plain

HLSLが直接書けると言う事でしょうか?

<Collision

この地面にぶつかって停止しているのは拾えたり出来るんでしょうか?

f:id:kazuhironagai77:20210725231021p:plain

拾えると応用方法が凄く広がりそうです。

<Static Mesh Sampling

これは何やっているのか全く不明ですね。

f:id:kazuhironagai77:20210725231041p:plain

f:id:kazuhironagai77:20210725231048p:plain

Samplingが出来ると言う事はStatic MeshをNiagara systemから自由に動かせると言う事なんでしょうか?それともNiagara system は、Worldに配置されているStatic Meshの持っている情報を自由に得る事が出来ると言う事なんでしょうか?

うーん。

これはこれで面白いですが今はあんまり興味が湧かないです。

CGHOW氏のUnreal Engine Niagara Tutorials [5]の方が面白そうです。

f:id:kazuhironagai77:20210725231104p:plain

これの一番最初のヤツをやって見る方が面白そうです。

決めました来週はこれをやります。

3.Cascadeの勉強

今、言語学についても少しは勉強しなくてはと2冊、英語の発音を勉強する人達が良く薦める教科書を読んでいます。日本語で書かれた本です。それが結構Volumeがあります。軽くは読めないんです。

それで思ったんですが、日本語で書かれたUE4VFXの教科書も結構良いのがあるんじゃないと。

調べたらありました。池田 亘 著「HoudiniとUnreal Engine 4で学ぶリアルタイムVFX」です。今週はCascadeの勉強はお休みしてこの本を読む事にしました。

正し日本語の本の内容を丸々このブログに載せる訳にはいかないので感想を書くに留めます。

3.1 総評

まず全体の感想として、内容が非常に濃く読み応えがあります。しかし平易な言葉で説明しているのでかなり読みやすいです。サラッとですが3時間くらいで一応読み切りました。(ただしHoudiniの箇所は今後も勉強する気はないのでスキップしました。)

私が思うこの本の凄い所は、ノードの計算をGraphを使用する事で可視化している点です。これによって一つ一つのノードが何をやっているのかが正確に分かります。更にその計算の裏側にある理論と目的もはっきり理解出来ます。目から鱗の学習方法でした。

UE4VFXを基礎から勉強したい人や、深い部分までしっかり理解したい人は絶対読むベき本です。後、UE4のMaterialの理解を基礎から一歩進めたい人にもお勧めです。この本のかなりの章でMaterialについても詳しく解説しています。

題にある通り、Houdiniの使用方法の解説や、Houdiniを使用して何かをしたりする箇所が沢山ありますが、Houdiniがないと理解出来ない訳ではないのでUE4 onlyで勉強してる人でも問題なく読み進められます。

私はKindle版を買いましたが、本で買うより断然読みやすいです。PCの画面に200%で表示させて一気に読みました。Kindle版をお勧めします。

勿論、人間が作成したモノに完璧なものはないのでこの本にも良い点と悪い点があります。それについては以下にまとめました。

3.2 私が思うこの本の良い点

私が思うこの本の良い点を以下に述べます。

  • 計算の検討を逐一している。(筆者が完全に理解したり、完全に納得した事のみを書いている。)
  • 付属ファイルにこの本に載っている全てのノードの図が提供されている。(図が小さくて読者が混乱する事はない。)
  • 最新の技術を紹介していると思われる。

細かい点でもっと良いと思う部分はありましたが、最も重要だと思う事を3つ選びました。

<計算の検討を逐一している>

Shader内の計算が特にそうですが、Nodeの計算を全部自分で計算し直しています。

特にこの中で私が凄いと思ったのが計算結果をGraphで表す方法です。

この学習方法が素晴らしいは、計算の意味をしっかり確認するだけでなく、その計算の元になっている理論をしっかり自分のものに出来る事です。

大変分かり易い。

マンガを読んでる位の脳力しか使わないで、複雑な計算方法とその元の理論まで理解出来ます。

一例を挙げるとDot productの計算です。

私はDot Productを反転すると何で円の淵がぼやっと浮き上がるイメージになるのかずっと分からなかったんですが、この本の説明で一発で理解出来ました。

しかもこの本は最初から最後までこの解説方法で一貫しています。非常に沢山の計算方法とその元になる理論が紹介されています。

<付属ファイルにこの本に載っている全てのノードの図が提供されている>

こっちは流石に試している時間はないですが、読者がしっかり自分で試せるように、付属のファイルに全てのノードの図が入っていました。

前に買ったUE4の本で、ノードの図が小さ過ぎて何が書かれているのが分からなくて、実際に自分で試そうとしたら何も出来なかった時がありました。その時、かなり頭にきたので今もってその事を覚えています。

それ以降、UE4関連の本にノードの図がある時は、その図に載っている全てのノードの名前が読めるのかどうかと、全てのノードの繋がりが見えるのかどうかを確認する癖が付きました。

本に載っているノードの図からも一応は全てのノードの名前は読めますが、付属のファイルに入っている同じ図は本の図より5倍位大きくて読みやすいです。

<最新の技術を紹介していると思われる>

すいません。

私はゲーム業界については全く知らないので単なる想像ですが、この本で紹介されているテクニックは実際のプロが現場で今使用しているテクニックそのもののような気かします。最新かつ最高水準のテクニックを教えていると思われます。

3.2 私が思うこの本の不満点

ただ全てか完璧と言うわけでの無く不満点もありました。

以下に私が感じた不満点を記します。

  • どの層が読者なのか?デザイナーが対象なのか、Programmerが対象なのか。はっきりしない。
  • カタカナ語が多すぎ

<どの層が読者なのか?>

Effect Designerに成りたい人向けに書かれているのかと思われます。しかしUE4をちょっと触ってEffect を1個か2個作成しただけの素人にはこの本の内容は高度過ぎます。

元々、programmerでHLSLやGLSLでガンガンコードを書いていた人ならUE4のEffectを学ぶには丁度良い本です。

理論もしっかり説明されていますし、UE4での具体的な操作の仕方も丁寧に説明されています。

でもそうだとすると何で数式や方程式を省くのかな。と思います。更にVisual scriptingの説明でもDesignerでも使えます的な説明をしていますがProgrammer向けならそんな事言う必要ないと思います。

後「2つのイメージを並べて、こっちの方が良くなっています。」と解説されるとかなり焦ります。デザインの勉強をした人には明白な違いなのかもしれませんがProgrammerから見ればどっちも凄く見えます。

デザイナーは元々、絵の上手さでも90点と95点で争っている訳で、85点の絵と95点の絵を二つ並べればすぐに95点の絵が凄いと分かります。しかしProgrammerは絵については素人というか素人の平均を下回っている人がほとんどなので85点の絵と95点の絵を二つ並べられてもどっちも凄いとしか思えません。

2つのイメージを並べて比較する時はデザインの観点からここに注目するポイントがあって、その点から見ると左の方が全然良いよね。と言う感じで説明してほしかったです。

後、デザイナーでUE4のEffectの基本は身に着けた人がこの本の想定している読者なのかなとも思いました。

それなら敢えて数式や方程式までは書く必要ないし、2つのイメージを並べてた時も、こっちの方が良くなっています。で終わりでも良いです。

しかしその場合はVisual Scriptingについて素人同然の人に対してするような説明をする必要はないですよね。

そういう訳で想定している読者がどの層なのか???でした。

対象とする読者を

  1. Programmerで元々HLSLGLSLでバリバリコードを書いていたがUE4VFXの使い方を深いレベルで学びたい人
  2. デザイナーでUE4Niagaraは一応使いこなせるが、更に深く学びたい人
  3. UE4の初心者でVFXを学び始めたばかりの人

と仮定して、この部分は1のタイプの人には常識かもしれませんが、ほとんどの2のタイプの人は初めて聞く内容なので詳しく説明します。ここは3のタイプの人にはまだ理解するには難しいですが、将来的にはこういう事を勉強しないといけいないのでその準備と思って読んでください。完璧に理解する必要はありません。のようなコメントが一言あると読者もここは良く読む必要があるな。とか俺はこの部分はスキッブしていいわ。とか、ああこの部分は3のタイプの人を勇気づけるために敢えて不正確な表現をしているんだな。とか色々分かって読書中に混乱したり不安になったりあるいはちょっとイラッときたりする事が無くなると思います。

カタカナ語が多すぎ>

別にこの本に限った事ではなくProgramming関連の日本語の書籍全般に通じる問題ですが、安易なカタカナ語の作成とその使用は質の高い日本語の崩壊につながると私は思っています。

しかし問題はそれだけじゃありません。

安易な英単語のカタカナ化は実際の発音と全く別の発音を生み出してしまいます。

プロシージャルって何。全く聞いた事ない。と思ったらProceduralの事でした。

Proceduralの発音はprəˈsiʤərəlです。敢えて片仮名で表したらプル(ェ)スィヂュアゥです。どう聞いたらプロシージャルになるんですかね。

英語でシの音とスィの音は全く別な音です。「あんこ下さい」って言うつもりで「ウンコ下さい」って言ってんのと同じ位、間違ってます。しかもその後でʤəの音、つまりヂュの音なのにジャって書いてあって、これまた全く別な音です。「あんこ下さい」って言うつもりで「ウンチ下さい」になっています。

やっぱり私の作成しているMinimal Pairによる音素聞き分け訓練ソフトは必要だと思いました。

4.それぞれの石像のBack Ground Imageの作成

イラストなんですが、ちょっと悩んでいます。

以下にNPCに使用したイラストを示します。

f:id:kazuhironagai77:20210725231257p:plain

f:id:kazuhironagai77:20210725231303p:plain

f:id:kazuhironagai77:20210725231310p:plain

単純ですが、中々可愛いイラストで大変な苦労をして開発しました。私がIllustratorだったら、この画風で勝負を賭ける位の自信作です。

しかし自分の作ったこのRPGをテストしていると、以下に示した回復薬のイラストで描いたイラストの方が上手いです。

f:id:kazuhironagai77:20210725231326p:plain

f:id:kazuhironagai77:20210725231333p:plain

こういう感じの絵はなんの苦労もなく描けます。石像はどっちの絵柄にしようか迷っています。

2番目の絵柄で書いて見ました。

f:id:kazuhironagai77:20210725231347p:plain

こんな感じです。

f:id:kazuhironagai77:20210725231401p:plain

絵の練習を今からする訳にもいかないのでこれで行きます。

残り8体の石像も描いてしまいます。

f:id:kazuhironagai77:20210725231415p:plain

f:id:kazuhironagai77:20210725231423p:plain

f:id:kazuhironagai77:20210725231429p:plain

f:id:kazuhironagai77:20210725231437p:plain

f:id:kazuhironagai77:20210725231445p:plain

f:id:kazuhironagai77:20210725231452p:plain

f:id:kazuhironagai77:20210725231459p:plain

疲れた。本当に疲れました。一緒にゲームを作ってくれるIllustratorの人を早く探さないと。と本気で思いました。

後、このWidgetだと返事用のボタンで石像の3Dのイメージが見えないですね。後で直します。

5.それぞれの石像からItemを貰うときに開くWidgetの作成

これです。

f:id:kazuhironagai77:20210725231522p:plain

今の時点では、以下の画面から「はい」ボタンを押すと

f:id:kazuhironagai77:20210725231535p:plain

どの石像の場合でもGet Item  ウィジェット(つまり最初のイメージ)が開きます。

このWidgetだと一回に一種類のアイテムしか与えられません。色々なパターンのWidgetを作成しようと思います。

沢山のWidgetを作成しようとしたんですが、全部のパターンに対応出来るWidgetを思いつきました。

f:id:kazuhironagai77:20210725231549p:plain

Angle Statue02に会話をした場合です。

f:id:kazuhironagai77:20210725231602p:plain

6.それぞれの石像のセリフの作成

<Betrayal Statue

セリフです。

f:id:kazuhironagai77:20210725231624p:plain

はいといいえの表示は後で直します。

f:id:kazuhironagai77:20210725231636p:plain

f:id:kazuhironagai77:20210725231643p:plain

褒美は以下に示した様に1/6 の確率でしかもらえません。

f:id:kazuhironagai77:20210725231657p:plain

f:id:kazuhironagai77:20210725231704p:plain

外れた時は何も表示されません。

f:id:kazuhironagai77:20210725231718p:plain

Betrayal Statue DialogueのセリフでRewardがなかったのでそれも足しました。

f:id:kazuhironagai77:20210725231731p:plain

Teleport用のPassの仕組みはまだ作成していないのでItemに追加したりする機能は後で作成します。

<Angel Statue>

Angel Statueの場合です。

f:id:kazuhironagai77:20210725231750p:plain

はい。を選びます。

f:id:kazuhironagai77:20210725231804p:plain

褒美を受け取るボタンを押します。

f:id:kazuhironagai77:20210725231823p:plain

イーサーを1個か回復薬を3個もらえます。

残りの石像は何をくれるのかはまだ考え中なのでこれで一端、中止します。

その代りW_StoneStatueTalkウィジェットの回答ボタンの位置を直しました。

f:id:kazuhironagai77:20210725231848p:plain

前より見易くなりました。

7.戦闘中に石像と会話出来ない仕組みの作成

今のStoneStatueBPの実装だと戦闘中でも石像と会話出来てしまいます。それを防ぐ方法を考えます。

考えました。

f:id:kazuhironagai77:20210725232035p:plain

戦闘に勝利した時はRPGGameModeBPの変数であるVictoryの値はPHASE_Victoryになっています。

Victoryの値がPHASE_Victoryの時だけ、石像と会話出来るようにしました。

StoneStatueBPの指定しているTrigger Boxから出る場合も、一応、同じ実装をしておきます。

f:id:kazuhironagai77:20210725232050p:plain

この二つは実際に試してみないときちんと動くか分かりません。

後は実際に配置する時に、Trigger Boxの位置を微妙にずらしてPlayerの操作するキャラがいる位置から外れるようにする事も出来ます。

やっぱり実際にテストをしてみたいのでStoneStatueBPをBattle Field Map上に配置してみます。

8.Stone Statue BPBattle Field Map上に配置する

以下のようにStone Statue BPを配置しました。

f:id:kazuhironagai77:20210725232112p:plain

戦闘が終わりました。

f:id:kazuhironagai77:20210725232126p:plain

石像、AngleStatue02に近づきます。

f:id:kazuhironagai77:20210725232141p:plain

AngleStatue02の頭上にExclamation markが表示されました。あんまりよく見えません。別な方法でこの石像と会話出来る事をPlayerに知らせる必要があるかもしれません。

会話するためにキーボードのEを押します。

いつもの画面が登場しました。

f:id:kazuhironagai77:20210725232156p:plain

「はい」ボタンを押します。

セリフが変わりました。

f:id:kazuhironagai77:20210725232209p:plain

あんまりにも速くセリフが変わったんで、セリフが変わった事に気が付きませんでした。ボタンをクリックするたびに音がするなどの工夫が必要かもしれません。

「褒美を受け取る」ボタンを押します。

Reward画面に切り替わりました。

f:id:kazuhironagai77:20210725232223p:plain

回復薬が1個しかもらえていません。最低の褒美ですね。

戻るボタンを押します。

戦闘前のLevelに戻って来ました。

f:id:kazuhironagai77:20210725232238p:plain

成功ですね。

道具袋を開くと貰った回復薬がしっかり入っていました。

f:id:kazuhironagai77:20210725232252p:plain

そう言えば以下のウィジェット、W_StoneStatueTalkに閉じるボタンがありますがこれの機能を書いた覚えがありません。

f:id:kazuhironagai77:20210725232305p:plain

閉じるを押せばW_StoneStatueTalkが消えて他の石像と会話出来るんでしょうか?

多分出来ないです。が試してみます。

出来ました。

あれ。

実装部を見てみます。

f:id:kazuhironagai77:20210725232319p:plain

うーん。これだけで大丈夫なのでしょうか。何らかのParameterを元の設定にしないといけない気がしますが。

後で調べる事にします。

9.石像を封印する仕組みの作成

これはRPG Game Instance BPにBooleanのarrayを作成して管理します。

管理し易くするために、石像封印専用のStructureをBPで作成しました。

f:id:kazuhironagai77:20210725232338p:plain

このStructureからRPG Game Instance BPにArray、Stone Statue Talkを作成します。

f:id:kazuhironagai77:20210725232351p:plain

このArrayに要素を9個足して、

f:id:kazuhironagai77:20210725232404p:plain

それぞれの石像が封印されているかどうかを管理します。

石像と会話するためのTrigger Box内でkey boardのEを押した時に、Third Person Character内の以下のコードでその石像が封印されているかどうかの確認をします。

f:id:kazuhironagai77:20210725232419p:plain

もしされていたら、新しく作成したWidgetが開き、この石像とは会話出来ない事をPlayerに連絡します。

以下に石像とは会話出来ない事を示すWidgetを示します。名前はNot Allow to talkです。

f:id:kazuhironagai77:20210725232432p:plain

Angel Statue 02を封印してテストしてみます。

f:id:kazuhironagai77:20210725232525p:plain

戦闘終了後に、Angel Statue 02に話しかけてみます。

f:id:kazuhironagai77:20210725232547p:plain

封印されて話せませんでした。

「別の石像に話しかける」ボタンを押すと元の画面に戻りました。

f:id:kazuhironagai77:20210725232602p:plain

出来ています。

10.全部の石像をStone Statue BPと入れ替える

やはりこの状態でテストしないときちんと動くのか不明です。

出来ました。

f:id:kazuhironagai77:20210725232634p:plain

テストします。

戦闘が終了しました。

それぞれの石像をチェックします。

f:id:kazuhironagai77:20210725232650p:plain

因みに、会話出来る石像は以下の3つだけです。

f:id:kazuhironagai77:20210725232705p:plain

AngleStatue02 に話しかけました。

f:id:kazuhironagai77:20210725232719p:plain

会話出来ます。

いいえを選択して隣の石像に話しかけました。

f:id:kazuhironagai77:20210725232732p:plain

Betrayal Statueとも会話できます。

次のStatue01 に話しかけると

f:id:kazuhironagai77:20210725232746p:plain

となりました。

残りの石像も同じ回答でした。

最後のAngle Statueは普通に会話出来ました。

f:id:kazuhironagai77:20210725232759p:plain

出来ているようです。

残念ながら時間がなくなってしまったので今週はここまでとします。残りは来週やります。

11.Warp Passの作成

来週やります。

12.Good Skyの検証

来週やります。

13.まとめと感想

今週は、

  • Niagaraの勉強
  • UE4Effectについての本「HoudiniUnreal Engine 4で学ぶリアルタイムVFX」を読む
  • 戦闘後のアイテムの入手の作成の続き

を行いました。

来週は、

  • Niagaraの勉強としてCGHOW氏のUnreal Engine Niagara Tutorials [5]のどれかを勉強する。
  • Cascadeの勉強の続き、もしくは英語で書かれたUE4Effectについての本を読む
  • 戦闘後のアイテムの入手の作成の続き
  • Warp Passの作成
  • Good Skyの検証

を行います。

今週は、久しぶりに日本語の本を読んだり、絵を沢山描いたのでいつもより疲れました。

<参照(Reference)

[1] Rachel and Jun. (2017, February 17). Why do Japanese mix up “L” and “R”? [Video]. YouTube. https://www.youtube.com/watch?v=F4MsJHn-lRA

[2] Rachel and Jun’s Adventures! (2021, June 30). Can Jun finally tell “R” and “L” apart? [Video]. YouTube. https://www.youtube.com/watch?v=zufKIv4-Q0U

[3] Epic Games. (n.d.). Recreate the Starter Content Smoke Effect in Niagara. Unreal Engine Documentation. Retrieved July 25, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Niagara/HowTo/RecreateSmoke/

[4] Epic Games. (n.d.-a). Emitter Update Group. Unreal Engine Documentation. Retrieved July 25, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Niagara/EmitterReference/EmitterUpdate/

[5] CGHOW. (n.d.). Unreal Engine Niagara Tutorials. YouTube. Retrieved July 25, 2021, from https://www.youtube.com/playlist?list=PLwMiBtF6WzsqC7_cJmD26ts0YDbtPCCfe