＜前文＞
別にオリンピックを見て急に気が付いた訳ではないでしょうが、最近になって、ほとんどの日本人にも、日本って国が終りを迎えている事がはっきり認識出来る様になって来ました。
私は前々から思っていたので、はっきりと書きますが、日本人と日本文化は世界で最も優秀な部類に入ると思っています。
しかしそれと国の衰退は全く別な話です。
私はアメリカに10年も暮らしていたので、日本が終焉を迎える日が来るのは凄く前から感じていました。
そして悲しい事ですが、国の支えが無くなったら他国の人から日本人は奴隷のように扱われます。賃金を払わなくても誰からも文句を言われないから、僅かしか払われないでしょうし、暴力を振るっても逮捕される事もない訳ですから、暴行される事も度々起きるでしょう。
のでその解決策も同時にずっと考えていました。
これは、私にとっての解決策なので、ゲーム関連のProgrammerの人にしか参考にならないですが。そのアイデアの一端をここに記しておきます。
それは一個のゲームに対して一個の会社を作る事です。
今、ゲーム会社で一番割を食っているのはProgrammerです。アメリカの大学でCSを勉強している学生の間では「絶対にゲーム会社には就職するな」と言われていました。
その理由は単純で、ゲーム会社の給料が他の産業に比べて格段に低いのに長時間働かされるからです。
この状況はProgrammerに会社のStockの数十パーセントを分ける事で回避出来るはずです。一個のゲームに対して一個の会社ならそれが可能です。もしそのゲームが世界的なヒットを出せば、その会社の株価もとんでもない値段になります。更にProgrammerが自分で会社を興した場合は、そのゲームのIPはずっと自分で所有出来ます。
日本のゲーム会社はLoot Boxを採用する事でゲーム自体の収入を上げてその結果、Programmerの給料も高くするという戦略を取っているみたいですが、Loot Box自体がアメリカなどの西洋諸国では違法、もしくはほぼ違法と見られているため、本格的に海外進出する事は出来ません。
それに比べて私の「一個のゲームに対して一個の会社」戦略は、世界的な大ヒット作を制作しなければならないという制約が付きますが、ゲーム関連のProgrammerもとんでもない大金持ちになれます。
そしてここが大事ですが、とんでもなく大金持ちに成れる事が確実なら、世界的な大ヒット作だって作成出来ます。
日本の漫画は、アメリカのコミックより全然面白いです。
その理由は、日本の漫画家は大ヒット作品を描けば大金持ちに成れるからです。アメリカのコミックライターは給料制で、そのコミックが売れたからと言って大金持ちに成れるわけではありません。
今のゲーム会社のProgrammerも同じです。彼らの製作しているゲームが売れたからと言って、彼等は大金持ちには成れません。
その結果、頑張る質が変わってしまいます。
世界的な大ヒット作を制作するために頑張るのではなく、会社で出世するために頑張るようになってしまいます。
ゲームは漫画と違い、一人で作成する事は出来なくはないですがかなり大変です。最低でも5人くらいは必要でしょう。それ故に真のゲームの制作者は誰にも分からないです。だから会社にそのゲームを所有させてその会社の株でそのゲームの所有権の割合をはっきりさせるのです。
全体の5%しか株を貰えないなら、かんばりも5%位になります。20%も貰えるなら結構頑張るって良いゲームを作るかもしれません。
そしてここも大事ですが、お金を出すから株よこせと言うヤツは絶対に仲間にしない事です。面白いゲームを作れるのが保証されていれば、いくらでもファンからの寄付で制作費は集められます。労働以外の対価で株を得る事が分かったらみんなやる気をなくします。
更に、最近知ったのですが、株を売って得た収入はどんなに稼いでも最高で20％の税率にしかならないそうです。3億円とか稼いでも、給料だと半分持っていかれる訳です。それが株で稼いだ場合、2割で済むそうです。これは聞いた話でまだ自分では確認していないのですが配当金も税金は2割で済むらしいです。
ゲームの制作は最低でも2~4年はかかるでしょう。その間、ずっと少ない給料で我慢してやって来て、いざ大金が入るようになったら、全部税金で持っていかれるとなるとこれまたやる気をなくします。その問題も株で対価を払う事で回避できる訳です。
まあ、国が崩壊した後は、税金もどれだけの人が払うのか疑問ですが。イタリアなんかだと地方によっては経済の半分位はアングラらしいですし。
そう言えば、突然思い出したんですが、昔私、VRで酔う理由の一つ、しかも大きな理由の一つがFPS以外にある事を発見しました。それは画面の旋回方法についてなんですが、同時に、私がそれを実装出来たとしても、私に入るお金は0と言う事も気が付きました。結局やらなかったです。そしたらとうとうVR産業自体が無くなってしまいました。
勿論、VR産業が崩壊した理由は色々あるでしょうが、VRを使用すると悪酔いするのはもっとも大きな理由でしょう。それに対する解決策を提示しても大金持ちに成れないんじゃ、やる気は全く起きません。
こういうやる気の問題も一個のゲームに対して一個の会社にしてStockの数十パーセントを分ける事で回避できます。
それでは今週の勉強を始めます。
＜本文＞
１．今週の予定
今週は以下の事をやります。
- Niagaraの勉強としてCGHOW氏のUnreal Engine Niagara Tutorials [1]のどれかを勉強する。
- Cascadeの勉強の続き、もしくは英語で書かれたUE4のEffectについての本を読む
- 戦闘後のアイテムの入手の作成の続き
- Warp Passの作成
- Good Skyの検証
2. Niagaraの勉強としてCGHOW氏のUnreal Engine Niagara Tutorials [1]のどれかを勉強する。
無難に一番最初のヤツをやります。
2.1 Unreal Engine Niagara Cloud Tutorial | Download Project Files [2] を勉強する
T_Smoke_SubUVを使用するそうです。
またSmoke関連か。と思いましたがCGHOW氏のTutorialは初めてなので、それも良いかもしれません。
Niagara Emitter とNiagara Systemを作成しました。
が、今の形式と違います。
Emitterで、どのTemplateを選んだのかが分かりません。
Tutorialの映像を見ると
Particleが飛んでいるので何かしらのTemplateが選択されたと思われますが、以下に示した様にSystem Overviewが表示されていないのでどんな設定なのか良く分かりません。
今のNiagara Systemとかなり違います。
Mar 2, 2019に制作されたとあるので、たった2年前です。2年の間に、Niagara Systemの形式がこんなに進化しているなんてびっくりしました。
取りあえずこの部分はスキップしてMaterialの作成を先にします。
Materialは以下のように作成しました。名前はM_Smokeとしました。
これ以上ない位シンプルなMaterialですね。
Depth Fadeノードは使用していませんね。
後、MaterialのBlend Modeの設定をTranslucentにする時、
「HoudiniとUnreal Engine 4で学ぶリアルタイムVFX」で半透明にするとどうしてコストが余計にかかるのかの説明図が、ブアッと頭の中に浮かんできて「こんなにコストがかかるのに本当に半透明にする必要があるの？」と心の中で問いかけて来ました。
「HoudiniとUnreal Engine 4で学ぶリアルタイムVFX」を見返したんですが、この本には検索機能がついていません。
どこに書かれているのか見つかりませんでした。
普通は検索機能がついているんですが、何が違うんでしょうね。
先週、気がついていたらこの本に対する不満点にこの事を追加していました。
Tutorialに戻りますが、Emitter Systemの説明をしていますが、一向にSystem Overviewは表示されません。
Tutorial ではEmitter SystemのModule内のParameterについての説明をしてます。
仕方がない。EmitterのTemplateは適当に選んで、この説明で表示されているModuleと同じModuleを追加します。
一番、見た目が似ているFountain Templateを選択します。
TutorialのEmitter Systemですが、
＜Emitter Spawn＞
Emitter Spawn Category内にEmitter Properties Moduleがあります。見た事ないModuleです。
＜Emitter Update＞
Emitter Update Category内にはEmitter Life Cycle ModuleとSpawn Rate Moduleが表示されています。Emitter Life Cycle Moduleも見た事ありません。
多分Spawn Rate Module以外は別のModuleに進化したんだと思いますが、一応調べて見ましょう。
やっぱりありませんね。
どのTutorialで学んだのか忘れてしまったのですが、Emitter Spawn Categoryは基本的にはノータッチで良いと書かれていた気がします。これって結構初心者には大切な情報だと思うんですが。
ひょっとしてCGHOW氏って結構投げっぱなしな人なのかもしれません。
普通、Tutorialを作成している人ならこれだけ変更されたら新しいTutorialを作り直すと思うんですが。
Emitter Update Category内のModuleも見てみましょう。
やはりEmitter Life Cycle Moduleはありませんでした。
ただしこっちのModuleはParameterを見てみると
Emitter State Moduleと同じような事をしてそうです。
Emitter Life Cycle ModuleのNext Loop DurationとEmitter State ModuleのLoop Durationは何となく同じParameterのような気がします。
その他のParameterのある程度は一致しそうです。
Emitter Life Cycle ModuleはEmitter State Moduleに進化したと仮定して先を見てみましょう。
＜Particle Spawn＞
TutorialのParticle Spawn Categoryです。
Fountain Templateの方は以下のModuleを使用してます。
こっちはパッと見には結構似ています。Add Velocity ModuleとAdd Velocity Cone、Sphere Location ModuleとSphere Location Module、そしてSet Variables ModuleとInitialize Particle Moduleです。
最初に最も似ていないSet Variables ModuleとInitialize Particle Moduleを比べてみます。
Set Variables Moduleには３つのParameterがあります。
Initialize Particle ModuleにはParticle Lifetimeによく似たParameter、Lifetime Modeがあります。
Initialize Particle ModuleのNiagara Module Scriptを表示すると、Lifetime MinとLifetime Maxの値をParticle Lifetimeにセットしています。
ただ、Input Lifetimeが何を表しているのか不明です。
その後ろのノードを見たら分かりました。Input LifetimeはLifetimeのModeがRandomでなく直接値を入力する時に使用します。
他のParameterはどうでしょう。
Sprite Rotationを調べて見ます。
まずSprite RotationというParameterが存在するのかを調べます。
ありますね。
ではInitialize Particle Module内でSprite Rotationの値を指定してるのか調べます。
Sprite Rotation ModeというParameterがSprite Attributes内にあります。
これがSprite Rotationの値を指定していそうです。
Initialize Particle ModuleのNiagara Module Scriptを開いてSprite Rotationの値がどうやって決定されているのか調べて見ましょう。
ありました。しかも3つもありました。
その次のノードを見るとSprite Rotation ModeがRandomの場合は二番目の実装が実行されるとあります。
このStatic Switchノードみたいな繋ぎ方をするノードって他にもあるんでしょうか？
右から左に戻って読まなければならない結構不思議なノードですよね。
Randomの場合を遡ってノードを追っていきます。
あれ、Sprite Rotation Angle MinとSprite Rotation Angle Maxの値を入力しています。後、これらのParameterの左側にある数字ですが、Default値でしょう。
Emitter Systemに戻ってInitialize Particle ModuleのSprite Rotation Modeを見たらSprite Rotation Angle MinとSprite Rotation Angle Maxはありました。隠れていただけでした。
0と360がDefault値として指定されていますね。
最後のParameterであるSprite Sizeを調べます。
これですね。
Initialize Particle Module 内でSpriteSizeの値を指定してそうな所と言えばこれしかありません。
Initialize Particle ModuleのNiagara Module Scriptを開いて調べて見ましょう。
はい。ありました。
何となくですがNiagara Module Scriptの見方が分かって来ました。
Sprite Size ModeでRandom Uniformを選択した場合の実装を追っていきます。
はい。ParameterであるSpriteSizeにUniform Sprite Size MinとUniform Sprite Maxで指定された値からうにゅうにゅして出て来た値をセットしています。
あれ。
Initialize Particle Module 内でUniform Sprite Size MinとUniform Sprite Size Maxの値を以下の様にセットしましたが、
Niagara Module ScriptではDefault値は5.0と10.0になっていますね。
これはInputされた値が無い場合は、5.0と10.0がDefault値になると言う事なのでしょうか？
ちょっと分かりませんね。
細かい点ではまだまだ分からない事が沢山ありますが、Tutorialで使用しているSet Variables ModuleとFountain Templateで使用されているInitialize Particle Moduleはほぼ同じ事をしている事が分かりました。
因みに、Initialize Particle Moduleではその他に
のParameterの値も指定していました。
次にAdd Velocity ModuleとAdd Velocity Cone Moduleですが、この二つのModuleはParticleの初期速度を設定しているだけでしょう。
Particle Spawn CategoryのVelocityの項目を見るとAdd VelocityとAdd Velocity Coneがありますし。
そうだ。公式のDocumentを見てみましょう。Particle Spawn Group [3]を見るとVelocity Modulesについての項目があります。
ここの解説を見ると
となっています。Parameter, Velocityに値をセットするのはAdd Velocity In Cone Moduleだけなの？Add Velocity ModuleだってParameter, Velocityに値をセットしそうですが。
それだけ調べて見ます。
Add Velocity Moduleを追加して
Add VelocityのNiagara Module Scriptを開きます。
はい。
Add Velocity ModuleもParameter, Velocityに値をセットしています。
Add Velocity ModuleのNiagara Module Scriptの全体像です。
あれ。これだけ。これなら私でも理解出来そうです。ちょっと読んでみましょう。
2.2 Add Velocity ModuleのNiagara Module Scriptを読む
InputであるVelocityとScale Added Velocityを掛けています。Add Velocity ModuleにScale Added Velocity なんでParameterあったけな？と思ったら。
ありました。
確かDistributionの勉強をした時にScale何とかと言うParameterがあって、その機能は単純に値を掛けているだけ。と結論づけた時がありました。それと同じ機能ですね。
次にTransform Vectorノードに繋がっています。
Transform Vectorノードは先程のVelocityの値だけでなくSource SpaceというParameterからも値を受け取っています。
このSource Spaceの値は
から来ています。
Add Velocity ModuleのCoordinate Spaceをみると
となっていてCoordinate Spaceの値は数字じゃないです。
となるとこのTransform Vectorノード内でSource SpaceがLocalの時は○○の値を追加。みたいな事をやっているはずです。
クリックしたらTransform Vectorノードの中身が見れました。
これです。このSource SpaceノードからLocalはパスされてNF Transform Baseノード内である値に変換されています。
ただここまで深く潜ってしまうと正直何をやっているのかさっぱり分かりません。
今回は実際のコードを見るのはTransform VectorノードまでとしてTransform Vectorノードに表示されている情報からSource Spaceの役割を推測する事にします。
Source Spaceが取り得る値は、World、Local、そしてSimulationだけです。と言う事はWorld Coordinateの時は、VelocityにParticleの位置を足す必要があります。Local CoordinateならばParticleの位置は0になるので何も足す必要はありません。
はい。
Transform Vectorノードは、これをやっているんじゃないでしょうか？
次のノードです。Aには先程、Transform Vectorノードで計算した値が入っています。
Bですが、なんとParameter、Velocityそのものの値が来ています。
あれ、Parameter、Velocityの値を決めるためのModuleなのに何でParameter、Velocityの値が前から存在しているの？
と思ったんですが、このAdd Velocity Module、次のParticle Update Categoryからも呼び出せるはずです。その場合は前のVelocityを足す必要があるはずです。
最後に計算された値をParameter、VelocityにセットしてOut Putします。
これがAdd Velocity Moduleの仕組みでした。
2.3 Unreal Engine Niagara Cloud Tutorial | Download Project Files [2] をもう一度勉強する
Add Velocity ModuleとAdd Velocity Cone Moduleに戻りますが、取りあえずはどっちでも良いかなと思っています。後で変更します。
Particle Spawn Categoryの最後のModuleであるSphere Location ですがこれは同じModuleを使用しています。
＜Particle Update＞
Particle Update Categoryを見て行きます。
こちらがTutorialのParticle Update Categoryです。
こっちがFountain TemplateのParticle Update Categoryです。
した二つのModule、Solve Forces and VelocityとColor（Scale Color）は同じ、もしくはほぼ同じでしょう。
Gravity Force ModuleとAcceleration Force ModuleもAcceleration Force Moduleが重力の計算をしている限り同じ機能でしょう。
Drag Moduleは空気抵抗の計算をしているんだと推測されます。
となると残りはUpdate Age ModuleとParticle State Moduleです。
現在のVersionのNiagaraにはUpdate Age Moduleは存在しません。
TutorialでもUpdate Age Moduleが何を担当しているのかの説明は全くないのでこれ以上の推測は出来ません。
のでUpdate Age Moduleが進化したのがParticle State Moduleであると仮定して次へ行きます。
＜Render＞
TutorialでRenderに使用されているModuleはSprite Rendererとほぼ同じModuleのようです。
Tutorialの説明に沿って使用するMaterialを先程、作成したSub UVのヤツに変更します。
設定もSub UV用に変更します。
あれ。
何かオカシイです。
Materialのalphaの代わりにRGBAを繋げていました。
直しました。
イメージも正しくなりました。
Aminationを追加します。
その前にPreview の設定を変更します。
こんな感じに変更しました。
これは見やすいです。この方法は覚えておきましょう。
まずWindowからPreview Scene Settingsを選択します。
するとSelectionの隣にPreview Scene Settingsが表示されます。
Show Environmentのcheckを外し、Environment Colorに黒をセットします。
以上です。
後、Tutorialでは、煙の動きを変えるためにVelocityの値やAcceleration Forceの値を弄りました。これらは本質的な事ではないのでスキップします。
＜Animationの表示＞
TutorialではSub Image Index Moduleを追加してAnimationを表示しています。
こんな感じです。
む。これって確か2021-07-18のブログでやった方法で作成出来たはずです。
Particle Update CategoryにSet new or existing parameter directly Moduleを追加します。
追加するparameterにSub Image Indexを選びます。
はい。
Tutorialと同じになりました。
2021-07-18のブログでやった時はSet new or existing parameter directly ModuleはParticle Spawn Categoryに追加しました。今回はParticle Update Categoryです。
これだとアニメーションも自動で更新され続けるんでしょうか？
Sub Image Indexの値の設定方法をFloat from Curveに変更します。
0の値を0、1の値を64にセットします。
64個だから0から63だと思うんですがどうなんでしょう？
問題が起きたらTutorialの先の方で直すはずなのでこのままで行きます。
Animationが発動している事を確認します。
出来てますね。
＜Cylinder Locationの追加＞
Sphere Location Moduleを外してCylinder Locationを追加します。更にサイズを以下の様に横に広く高さが無いようにします。
Spawn Rateを1000に変更します。
こんな感じになりました。
もう大体理解しました。
このCylinder Location Moduleの設定を横に広く高さが無いようにすれば霧が満ちている世界を作成出来るんです。分かりました。
ちょっと発生する煙が沢山重なった時の挙動に納得できないので色々弄って見ました。
こんな感じです。
正直、これだけ分かれば十分です。
後、Niagaraを勉強する時間も無くなって来ましたのでTutorialの残りは来週やる事にします。
3. Cascadeの勉強の続き、もしくは英語で書かれたUE4のEffectについての本を読む
先週「HoudiniとUnreal Engine 4で学ぶリアルタイムVFX」を読んでこんな凄い本あるのかと驚いたんですが、英語の本でも同じ位凄い本があるんじゃないかと思ってアマゾンUSAで探したんですが見つからなかったです。
と言うか、UE4を学ぶ事に対する熱量が全く感じられませんでした。
これと同じ雰囲気を前に感じたのがRuby on Railsです。
Ruby が持っていた市場は一気にPythonに奪われました。Python原理主義者たちは、Rubyの息の根が止まるまで追撃の手を緩めませんでした。これが機械学習とか、科学計算に関してならPython原理主義者の言う事もそれなりに納得出来ますが、Back end用の言語としてRuby on railsが特別Pythonに劣ってるとは、私には全然思えませんでした。
ただWeb関連のProgrammingは、私はちょっと齧った程度なので専門家ではありませんから、Pythonの信者達からそう言われたら黙るしかありません。
ちょっと小耳に挟んだだけなのでどれだけ本当なのかは不明ですが、カナダのある都市ではUnityに対する求人広告3000件に対してUE4は1～5件だそうです。
UE4が第二のRuby on Railsとして一気に市場から消えるかどうかは神ならぬ私が知る由もないですが、そういう可能性は結構ありそうです。
そういうわけで、UE4のVFX関連の洋書を読む計画は一端中止にして、Cascadeの勉強をします。
3.1 Cascade 応用編
CascadeにしてもNiagaraにしても一応基礎は理解したので応用としてゲームに使用するEffectの作成を勉強しようと思います。
ゲームで作成するEffectについて思いつくまま書いて行くと
魔法関連
- 炎
- 煙
- 雷
- 水
- 氷
- 魔法陣
- 雪
- 砂
- 風
- 光
- 闇
- 爆発
- 回復
- 状態異常や呪い
でしょうか。
この中で炎、煙、雷、魔法陣については一応、一回以上は作成した記憶があります。氷や水のEffectはあまり見た記憶がありません。
＜氷のEffect＞
氷のEffectについて調べて見ました。
Particle Systemで作成しているのか不明ですが以下のAssetは段違いで本物そっくりです。
こっちはNiagaraですがCGHOW氏が作成したIce Effectです。（Ice Hit Effect | Unreal Engine Niagara Tutorial [4] より）
圧巻の一言です。やっぱりCGHOW氏のEffectは凄いです。
別な動画を見ていたら、先程、紹介したAsset、Ice Coolは2019年の9月にFreeで配布されているとありました。
えっ。
調べたら持っていました。
それではこのAssetをもっとよく見てみます。
3.2 Ice Coolの調査
デモ画面を開きます。
凄い。これが作成出来れば氷のエフェクトとしては完璧でしょう。
これで十分でしょう。
元になっているMaterialを見ましたがチンプンカンプンです。
Effectは付いていませんでした。
氷のEffectを作成するには、このMaterialを使用したMeshをMesh Renderingで表示して使用する事になりそうです。
以上です。
3.3 Cascade 応用編の続き
水のEffectも探してみます。
＜水のEffect＞
いきなり凄いのを見つけました。
と思ったらこれもCGHOW氏のTutorialでした。名前はStylized Water Splash | UE4 Niagara Water Splash | Download Project Files [5] です。勿論、Niagaraを使用しています。
後は、4.26から付属になったWater Simulationの使用方法です。
これはParticle Systemではないんで今回はパスします。
そう言えばWater Simulationではなく4.24で使用しているUIWS（Unified Interactive Water System）の方にEffectが何個かあった気がします。見てみます。
他のも大体同じ感じです。
Particle Systemをみると
Mesh Dataを使用しています。
水のEffectもこれを使用すれば作成出来そうです。
＜雪のEffect＞
雪のEffectについてです。
そうだ思い出しました。
Particle Effectsという色んなEffectを紹介したProjectがあったんです。
その中に確か雪があったはずです。
見てみます。
空を舞う雪の粒はP_Blizzerdと言うEffectで作成されていました。
ところがこのEffect、Viewportでは全く雪の粒が表示されていません。
何か私がまだ知らない仕組みがあるみたいです。
Particle Effectsには、水のEffectがありました。
P_WaterFall_Mist_Lightと言う名前のEffectでした。
これだけ見ると簡単そうですが、使用されているMaterialを見ると
こんな感じでとても一筋縄で理解出来るとは思えません。
雪のEffectですが、YouTubeに一杯ありました。こっちを先に勉強します。
＜砂のEffect＞
砂のEffect のTutorialもYouTubeに結構ありました。
＜風のEffect＞
まずYouTubeにそのものずばりのTutorialがありました。
Niagaraですが他にも風のTutorialがあります。
GameDev Outpost氏のTutorialは雪が風で舞う様子を作成するためのTutorialみたいですね。
もう一人のRimaye氏は聞いた事がありません。ちょっと動画を見て確認して見ます。
英語じゃなかった。一応、言葉が分からなくても理解出来るように頑張って作成したと有りますが…。
＜爆発のeffect＞
光や闇はまあいいです。雷とほぼ同じでしょうから。
爆発のEffectを調査します。
またRimaye氏の動画が出て来ました。
フランス語なんてマジでParlez-vous français ?しか知らないレベルなのに、どうしろと言うんでしょうか？
しかしEffectはマジで凄い。
Cascadeで作成しているTutorialも一個見つけました。
ちょろっとだけ見ましたがこれも凄いです。
ただしこのTutorial、一時間もあります。これ勉強したら終わるのに一カ月かかる可能性が…。
＜回復のEffect＞
回復系のEffectも調べます。Healing Effectで調べました。
これはCascadeで結構簡単そうです。
3.4 Cascade 応用編を勉強する目的についての確認
Cascadeと言うかParticle Effectの基礎であるSpriteやMesh、Ribbon、そしてBeamなどの仕組みは一応理解しました。その基礎的な技術をどう使って具体的なEffect、例えば炎などを制作するのかを明らかにするのが、Cascade 応用編を勉強する目的です。
例えば煙のEffectを作成するために、Sprite + Sub UVを使用するみたいな事を理解するのが目的です。
3.5 炎のEffectの復習
そういうわけで今回は炎のEffectの復習をします。
TutorialはUnreal 4 Particles Tutorial - Simple Flame, Embers, Smoke. [6]を選びました。
最初に当然ですがParticle Systemを作成します。名前はFrame Touchです。
MaterialをM_Fire_SubUVに変更します。
ここでもSub UVを使用するのか。Sub UVって滅茶苦茶基本のTechniqueなのね。
Sub UVは以下の設定に変更しました。
Interpolation MethodでLinear Blendを選択しました。これはImageが単純に1から2に移るのではなくその間のImageも1と2のImageをBlendするMethodだそうです。
これだけではSub UVのImageはずっと0番しか選択されないのでAnimationになりません。
Sub Image Indexを追加します。
Sub Image Indexの値は以下の様に設定します。
M_Fire_SubUVのImageは36個なので0の時に0、1の時に35をセットします。
上のNiagaraのTutorialでは64個imageがある時に
1の時に64をセットしていますが、このTutorialの作者であるGame Dev Society BU氏はきちんと63にセットしていました。
と思ったらこの人も、Tutorialによって1の値が違うけど35であっているはず。と言っていました。
後、もし入力する値が2つ以上ある場合は、Curve Editorを使用して入力した方が分かり易いです。
これはGame Dev Society BU氏は述べていませんでした。
以下の様なImageに変化しました。
上昇が速過ぎてAnimationがきちんと動いているのか分かりませんね。
根元に注目すると常に同じimageが同じ個所から発生していて不自然に見えます。
Rotationを追加する事でこれを直します。
Initial Rotationを追加します。
Initial Rotation内のParameterは以下のような設定になっています。
ここのMaxの値が１と言うのは360度の事だそうです。ので値自体は弄る必要はないです。
結果、Imageが以下の様になりました。
今度は色をつけます。
Particle Systemに元からあるColor Over Life Moduleの値を変更します。
以下の値にしました。
流石に色の変更はDetail画面でやった方が分かり易いですね。
後、色の値で1以上が入れられるのは、以下に示したようにMaterialでEmissive Colorに繋がっているからだそうです。
はい。これは初めて知りました。
結果です。
完全な炎になりました。
今度はInitial Size Moduleの値を弄ります。
こんな感じに値を変更しました。
その結果です。
微調整と言う感じです。
今度はParticleの存在している間中のサイズを指定します。
Particleの最初のサイズを0.4倍にしました。
こんな感じになりました。
この辺の微調整が実際のゲームをPlayするに当たってどれくらいPlayerの満足度に影響するのか知りたいですね。
次に炎の広がりを修正します。
今回作成する炎はまっすぐに伸びる炎なので炎の広がりを直します。
修正するModuleはInitial Velocityです。
ｘ、ｙ方向への初速度を0に変更しました。
結果です。
こんどはLife Timeの調節をします。
ちょっとだけMinを小さくしました。
こんな感じになりました。
今度はEmberの作成です。Flicking OFFって言っているので燃えカスから飛び出して舞っている燃えカスの粒でも作るのでしょう。
燃えカス用のEmitterを追加しました。
それぞれのEmitterの名前が同じなので変更します。
EmbersのMaterialにM_Radial_Gradientをセットします。
更にInitial Size Moduleから
Particleのサイズを以下の様に変更します。
以下の様になりました。
今度はEmbersに色を追加します。
Frameと同じ値を追加します。
こんな感じに成りました。
今度はInitial Velocityを変更します。
EmberはFrameと違って横に広がります。ので
としました。
その結果、
と成りました。
Frameと合成して見るとEmberが横に飛び散り過ぎです。
EmbersのInitial Velocityの値を以下の様に微調整しました。
結果です。
少しはマシになりました。
はい。
Tutorialではこんな微調整を丁寧にやっていますが、これがどの程度大切なのか知りたいです。一人でGame作ったらこんな細かい点まで調整している時間も労力もありません。
Emberの数が多いので調節します。
Spawn Rateの値を10に変更しました。
こんな感じです。
EmberはFrameの上にもよく舞っています。それを再現します。
Emberの寿命をFrameより長くします。
その結果です。
Screen Shootでは見にくいですが、Emberが確かにFrameの上を舞っています。
いや、正確に言うと飛んでいます。舞ってはいません。
それではEmberが舞うようにします。
Module、Orbitを追加します。
初めて使うModuleです。
公式のDocumentであるOrbit Modules [7]では
と解説されています。
Orbit ModuleのOffset Amountの値を以下の様に変更しました。
公式のDocumentであるOrbit Modules [7]によるとOffset Amountは以下のような機能を司るそうです。
以下の様になりました。
値を変更する前を覚えていません。しかしEmberの回転がおとなしくなった気がします。
最後に煙を追加します。
煙用のEmitterを追加します。
名前をSmokeに変更します。
更にRequired ModuleのMaterialにM_Smoke_subUVをセットします。
いつもの煙用のMaterialですね。
Sub UVの値を以下の様に変更しました。
Interpolation MethodがNoneのままですが大丈夫なんでしょうか？
取りあえずはこのままでやって行きます。
煙のAnimationを表示するためにSub Image Indexを追加します。
値は以下の様にしました。
１には64ではなく63をセットしました。
Curve Editorは以下のようになっています。
こんな感じです。
正直、煙にAnimationが追加されたかどうか以前に、煙自体が見えません。
今度は煙にFrameと同じような動きにするためにRotation を追加します。
結果です。Viewportからだと煙が全く見えないのでLevel上に配置しました。
煙が凄いです。
この炎の煙にはおかしな点が幾つかあります。一つ目は煙が底から発生している点です。
それを直します。
Required ModuleのEmitter OriginのZの値を30に変更します。
結果です。
大分、本物の炎に見えて来ました。
煙が多すぎるので量を減らします。Spawn Rateを20から5に変更しました。
こんな感じです。
うーん。どうなんでしょう。煙が少し薄過ぎる気がしますが。
煙のColor Over Life Moduleの値を弄る事で直すみたいです。
はい。
暗くしました。
結果です。
色々位置を変えてScreenshotを取ったのですが、上手く取れませんでした。確かに煙が黒くなって存在感が増しています。
Tutorialの説明によると今度は、煙が突然、無から現れるように見えて不自然なのでそれを直すそうです。
私にはよく分かりません。少なくとも私の煙はそんなに不自然な感じはしません。が一応Tutorialの通りにやっておきます。
Color Over Life Moduleのalpha値を調節します。
最初は完全な透明です。そこから段々、不透明になって行きます。半分まで来ると80％位不透明になります。その後また透明になり最後は完全な透明に成ります。
グラフも載せておきます。
こんな感じです。
それでは結果を見てみましょう。
うーん。確かに本物の炎に見えます。
一応、これで炎のEffectの作成方法を理解しました。
4. 戦闘後のアイテムの入手：今までの復習
先週どこまで終わらしたのか覚えていません。
ので先週まで何をしたのかの復習を最初にします。
4.1 2021-07-25のブログの復習
＜石像との会話用のBGI＞
まず、それぞれの石像に話しかけた時に、表示されるBGIを作成しました。
こういうヤツです。
今、見直したら9個、全部描いてありました。結構頑張ったんですね。
閉じるボタンについてコメントが書かれていました。
閉じるボタンの実装は以下のようになっているがどんな時もきちんと作動するのか不安と書かれています。
これは調べて確認します。
＜石像からの報酬用のWidget＞
その次にしたのは石像との会話の後に表示される報酬を表すWidgetの作成です。
思い出してきました。報酬でパスを得た場合は道具以外に表示されますが、これ間違ってますね。パスは道具に追加する予定ですから。
後。パスを道具袋に追加する機能も作成してないはずです。
ただしこれはパスをItemに追加すれば解決します。
パスに関する問題はパスを作成してから直していきます。
＜石像封印に関するデータ管理＞
これはCanTalk変数の値をTrueに変更する関数を作成していません。
まだ石像の封印を解く必要はないのでしばらくは、CanTalk変数の値をTrueに変更する関数は作成しませんが、忘れない様にしましょう。
＜Stone Statue BPの配置＞
以下の様にStone Statue BPを配置しましたが、適切な位置で適切な石像と会話出来ているのか確認していません。
出来ていませんね。三体同時に認識されている場所があります。
こっちは2体同時です。
これらは後で直します。
思ったより忘れていませんでした。先週のBlogを読んだら何をやったのか結構思い出してきました。
4.2 先々週のブログ（2021-07-18）の復習
先々週の復習もやっておきます。
＜20％の確率で元の世界に戻らないようにする仕組み＞
以下に示した様に、今は100％の確率でItemが貰えるようになっています。
後で、直すのを忘れない様にします。
次はW_StoneStatueTalkウィジェットの閉じるボタンの機能は、
以下の様になっています。
多分大丈夫でしょう。
＜「石像との会話」の実装＞
Stone Statue BPのExclamation Markの表示は
以下の実装で行っています。
この仕組み自体は特に問題はないですね。
NPCの会話システムをこちらの方法に統一するかどうかが検討する必要がある所です。
それぞれの石像の向きや大きさはReturn Statue Mesh 関数内で指定しています。
以下に実際に表示されている石像の位置と向きを示します。
問題なさそうです。
以上です。
5．戦闘後のアイテムの入手：Landscape 4でテスト
5.1 Stone Statue BPの配置の直し
闘技場のサイズを少しだけ大きくしてそれぞれのTrigger Boxの距離を取る様にしました。
調べた範囲では２つの石像と同時に話せる状態にはなりませんでした。
が実際の原因はよく分からないです。
取りあえずはこれでOKとします。
5.2 RPG Game Mode BPのVictory関数のDefault値
しかしこのバグを直している間に別なバグが見つかりました。
原因を調べたらRPG Game Mode BPのVictory関数のDefault値がVictoryになっているからでした。
このDefault値を別な要素に変更すれば解決しますが、それで問題ないのか調べます。
このVictory変数は、Event Report Fight is OverでYou Winの値をセットされています。
以下に示した様に、このEventはMonsterかPlayerの操作するキャラのHPが0になった時、もしくは戦闘から逃亡した時に、Boolean 変数であるcombatOverがTureになった時に発動します。
それ以前の段階でRPG Game Mode BPのVictory関数のDefault値がVictoryである必要はないはずですが、一応調べておきます。
Get Victoryで検索してみます。
それぞれの関数が何時使用されているのか調べます。
最初のGet Victoryです。
RPG Game Mode BPのEvent Fight Is Over内で使用されています。
Event Fight Is OverはEvent Report Fight is Overの後で呼ばれるので問題ないです。
次にGet Victoryが呼ばれる箇所です。
RPG Game Mode BPのEvent Fight Is Over内です。のでこれも問題ないです。
残りの6個はMyThirdPersonAnim_BP内にある同名の変数であるVictoryでした。
最後の２つは石像でExclamation Markを表示するかどうかの時、つまり今回の目的に使用している場合でした。
はい。この結果から、RPG Game Mode BPのVictory関数のDefault値はVictoryである必要はないです。
しかし、EscapeやGameOverにするのも何かが違う気がします。
PHASE_Noneを追加してそれをDefault値にします。
はい。BuildしてEditorを再起動します。そしてVictoryにPHASE_NoneをDefault値としてセットします。
はい。
テストします。
今度は消えています。
戦闘に勝利した後も、問題ないです。石像との会話も出来ます。
念のために、戦闘に負けてみます。
これも問題なかったです。
逃走も試してみました。
逃走出来るのは確率で決まるので逃走する前に死なないように盾だけ装備した状態でテストしました。
これも問題なかったです。
5.3 Landscape 4でテスト
Landscape 4でテストしてみます。
はい。一個目のバグです。
Victory Awardウィジェットが表示されている間、playerの操作するCharacterを動かす事が出来ます。
Victory Awardウィジェットの後に、以下のコードを追加しました。
これでVictory Awardウィジェットを表示している時は動かなくなるはずです。
テストします。
アホ過ぎる。今度はVictory Awardウィジェットを閉じてもCharacterが動きません。
はい。閉じるボタンにコードを追加しました。
直りました。
その後、何回か戦闘をしましたが問題はなかったです。
出来てますね。
6. RPGの作成に必要なもの
「Warp Passの作成」するつもりだったんですが、ちょっと止めます。
その理由はここまで作成して分かったんですが、もう既にRPGの作成に必要な部品は揃っています。後はどう組み立てるかだけです。
だからいたずらに複雑にする機能を今追加するのではなく、今ある部品を組み立ててRPGとして完成品とする事の方が先だと思いました。
それで、一番今、必要なのか何かと考えたら目的とゴールなんです。
それを今、ここで決めてしまいます。
候補を思うままに書き記します。
- 隠し財宝を見つける
- 仇を討つ。
- オーブを集める。
- 捕らわれの姫を助ける。
- 魔王を倒す。
この中で最も簡単なのは「オーブを集める。」です。これにします。
そうだ。
どうせならWarp Passにします。
金のPassを集めるのが目的にします。
ああ。
もっと良い事を思い付きました。
Passじゃなくて切符にします。せっかく主人公の名前をジョバンニにしたんだから、Warpじゃなくて銀河鉄道に乗る為の切符にします。
そうすると2021-07-18のブログで考えたWarp Passの設定が生きて来ます。
このWarp Passの設定を銀河鉄道の切符に変更すればいいんです。普通の切符、切符の切れ端、青い切符、赤い切符、黄金の切符、銀の切符、銅の切符です。
そしてこのWarp Gateですが、銀河鉄道の駅に変更します。
はい。これで行きます。
ジョバンニは、赤い帽子を被った魔女から、金の切符を探すように依頼される訳です。
そしてジョバンニが金の切符を見つけたらゲームクリアと成る訳です。
7. 銀河鉄道の切符の作成
となるとやっぱり切符の作成をする必要がありますね。
Itemに切符を追加します。
現在、ItemはData Table、Itemsで管理しています。
中身は、
こんな感じです。
ここに銀河鉄道の切符も追加しましょう。
道具屋で買えるか確認します。
普通に表示されています。
値段は駄目ですね。BGIからはみ出してしまっています。
それは兎も角、切符のイラストは絶対必要ですね。
当分、絵は描きたくないです。切符の絵は来週やる事にします。
銀河鉄道の駅には、普通の切符で別な世界にワープが出来る事。切符の切れ端、10個で普通の切符と交換できる事。切符が買える事などの機能が必要です。
これらの機能も来週作成する事にします。
更に、ワープ、つまり銀河鉄道で移動中の画像も必要です。
次のmapの読み込みに時間が掛かっている場合は、事故が起きて列車が停止しているとかの解説も付け足したいです。
戦闘中にItemとして切符を使用する事も出来ます。
切符の切れ端は体力と魔力を回復します。普通の切符は戦闘からEscape出来ます。相手のMonsterに使用した場合は相手が強制的にEscapeします。などです。
8. 銀河鉄道の切符関連でやる事まとめ
ここで来週、銀河鉄道の切符関連でやる事をもう一度まとめ直します。
- 赤い帽子の魔女に金の切符を集める様に依頼されるシーンの作成
- 切符のイラストの作成
- 駅員との会話システムを作り直す。
- 切符は道具屋では買えない。駅で駅員から変える様にする。
- 銀河鉄道に乗る。切符を買う。切符の切れ端10個と普通の切符を交換して貰う。
- 移動シーンのアニメーションの作成。
- 駅でセーブも出来るようにする。
- 切符が戦闘でもアイテムとして使用出来る様にする。
- 切符の切れ端―＞体力と魔力を回復
- 普通の切符―＞戦闘からEscape
大体こんなものでしょうか？
結構、沢山ありますね。Preparation and Implementationです。それぞれの実装に必要なものを調べていきます。
8.1 赤い帽子の魔女に金の切符を集める様に依頼されるシーンの作成
以下にスタート画面を示します。
このMap内に赤い帽子の魔女との会話を追加しましょう。
「新しく始める」ボタンを押すと、Widgetが開いて赤い帽子の魔女が登場します。赤い帽子の魔女は、あなたに別世界に来て金の切符を探す事を依頼します。
8.2 切符のイラストの作成
切符のイラストを作成します。
サイズは200x200です。
8.3 駅員との会話システムを作り直す
これは以下の機能を作成する必要があります。道具屋の機能を参考にすれば良いと思うのでそれも復習します。
＜切符は道具屋では買えない。駅で駅員から変える様にする＞
今は、切符は通常のItemと同じData Tableで管理されています。
Itemsは全ての道具の一覧表とします。
それぞれの村の道具屋はどんな道具をその店で売れるのかを示す新しいData Tableを示します。そこには村名、道具番号がありその番号に当たる道具がその村で買える道具になるようにします。
そして、切符ですが同じようなシステムにします。新しいData Tableを作成しそこには駅名、道具番号があり番号に当たる切符がその駅で買える切符になります。
＜銀河鉄道に乗る。切符を買う。切符の切れ端10個と普通の切符を交換して貰う＞
NPC_ItemShopOwnerBPの中身を復習します。
Componentの中身は以下の様になっています。
Exclamation Markを表示するためのComponentがありません。
あれ？
Exclamation Markを表示するためのComponentは後で追加します。
Box内にPlayerが操作するキャラが侵入すると以下の事を行います。
ます侵入したActorがThirdPersonCharacterにCast出来るかどうかを確認します。
Playerが操作するキャラならCast出来き、出来なければ違うActorが侵入した事が判明します。
次に以下の方法でRPG Game Instance BPにアクセスします。
これもかなり昔に実装した部分ですので現在の（私独自のですが）BPのGuidelineには反した書き方です。今のGuidelineではGame InstanceとGame ModeはEvent BeginPlayでそれぞれに対応した変数にAssignしてその変数からアクセスするようにしています。
これも後で直します。
RPG Game Instance BPにある変数、Talk Shopの値をtrueに変更します。
うーん。この変数、確か道具ボタンを押す時に道具屋内で押したのかPause画面から押したのかを判別するためのBoolean変数だったと思います。だったらRPG Game Mode BPで作成すべきです。後同じボタンを全く別な個所で呼び出すのもDesign Patternとしてどうなんでしょう。
この辺は後で検討が必要ですね。
今はこのままにしておきます。
今度はGame Modeにアクセスしています。
こっちは敢えて変数を作成していますね。全然統一性がないです。まあ道具屋の実装はRPG作成においてもかなり最初に作ったので、何を統一すれば良いのかも不明だったのでしょうがないですね。
これも後で直します。
RPG Game Mode BPの変数、My Place For Eventsの値をPE Item Shopに変更しています。
これをする事でkeyboardのeを押した時の挙動が、道具屋での会話になる訳ですね。
あらゆるInputに対する挙動は、Third Person Characterとその親クラスであるUE4C++のCh4_3Characterクラスが管理しているので、一見わかりにくい実装方法ですが、理屈には合っています。この実装方法は正しいです。
Third Person Characterの実装も確認しましょう。
Event Do Somethingから見て行きます。
DoSomehing()関数は、UE4C++のch4_3Characterクラス内で宣言されています。
Function SpecifierでBlueprint Implementable Eventを使用しているので実装をBP内で行えます。
このEventは、以下に示したようにInputの指定により
Key BoardのEを押すと発動するように設定されています。
この辺の設定方法、ちょっと理解が曖昧です。後で復習する必要がありますね。
次にRPG Game Mode BPをAssignされた変数であるMy RPG Game Mode Base BPが値を持っているのか確認しています。
持っていない場合は改めてMy RPG Game Mode Base BPに値をセットしていますね。
これは、Game Mode とGame InstanceはEvent BeginPlayで対応する変数にAssignしとくべきで、それをやっておけば後でこんな確認をする必要は無くなります。
後で直します。
次はRPG game Mode BPの変数、My Place for Eventの値によって別々な実装になります。
My Place for Eventの値は、先程、NPC_ItemShopOwnerBP内でPE Item Shopに変更しました。
My Place for Eventの値がPE Item Shopの場合に実行されるコードです。
このコード、現在23個ある分岐の一番最初に書かれたコードでした。キャラのいる場所によってEボタンを押した時の対応は千差万別ですがその一番最初の対応が道具屋だったとは。結構感動です。
やっている内容ですが、最初に道具屋のWidgetであるShop_Welcomeウィジェットを開いています。
Shop_Welcomeウィジェットは名前から道具屋のWidgetである事が推測出来ない駄目な名前です。後で直します。
次にCursorを表示しています。
このゲームを作成し始めた時はゲームのPlayしている間はなるだけCursorを表示させないようにしていました。のでWidgetを開く時に必ずCursorを表示させるような実装をしています。
ゲームのPlayしている間にCursorを表示しないと画面が激しく動き３D酔いするようになるので。今は常にCursorを表示するようにしています。
のでこの部分の実装は要りません。後で外します。
Widgetを開いている間はPlayerはcharacterを動かせません。そのための実装です。
なのですが、うーん。Set Game Paused関数は分かるのですが、それに追加してSet Input Mode Game And UI関数も必要なんでしょうか？
この部分はなぜこうやって実装したのかは忘れちゃいました。
思い出せない理由があるかもしれないのでこの部分はノータッチとします。
ここまでは復習みたいなものですがここからが本番です。
Shop_Welcomeウィジェットを見ます。
まずはDesignです。
あれ、Itemを売る時のボタンがありません。
ちょっと確認します。
うっそ。
道具は売れないようになってました。これは後で直さないと。
それは兎も角、買い物ボタンを押した場合の実装です。
Shopウィジェットを開いてみると
となっています。
この商品の下のScrollBox_Inventoryに商品名の付いたボタンを追加する実装があるはずです。それを確認します。
Event Constructで始まっていました。
Widget にはEvent BeginPlayは無かったんですね。Event Constructでもこの場合は変わらんでしょう。
はいData Table、Itemsのデータを一つ一つFor Each Loopで回しています。
この部分も後で変更が必要です。新たなData Tableを作成してそれぞれの村の道具屋で売っている道具の差別化を図ります。しかしそれは駅が完成した後でやります。
はい。そのLoopの中です。
Itemsの要素を元にItemウィジェットを作成します。これがアイテムを購入するボタンに成る訳です。そのWidgetを先程のScrollBox_Inventoryに追加します。そしてその後で？？？
作成したItemウィジェット、つまりボタンの変数、Parent WidgetにこのWidget、つまりShopウィジェットをセットしています。
うーん。これItemウィジェットの変数、Parent Widgetの設定のExpose on Spawnにチェックを入れて
Create WidgetでAssignした方がいいですね。これも後で直します。
それではこの節の山場であるアイテム購入を実装しているWidget、Itemを見てみましょう。
デサインは枠いっぱいにボタンが配置されています。
本当それだけです。Canvas Panelすらありません。
Event Constructの実装です。
Game InstanceとGame Instanceの変数であるMy Your Hero、そしてThirdPersonCharacterの変数を作成しています。
これは、後でこのウィジェット内でこれらの値にアクセスするが楽になり非常に便利です。
それではボタンをクリックした場合の実装を見ます。
あ、これは随分後で、修正していますね。かなり綺麗に整理されています。結構最近直したのかな？正直覚えていません。
イキナリ、Remove My Tool Image Widget()関数を読んでいます。
思い出しました。この関数、以下のイメージを消すための関数でした。
この関数がないとずっとこのイメージが表示されているんでした。
次です。
ここで道具屋でこのボタンを押したのか、Pause画面でこのボタンを押したのかを判別しています。
あれ？
RPG Game Instance BPにある変数、Talk Shopがこれを担当していると思ったんですが。
ちょっと調べて見ます。
何と。RPG Game Instance BPにある変数、Talk ShopはMap2とMap3で使用されていました。
うーん。何のために使用されているのか不明ですが、RPG Game Instance BPにある変数、Talk Shopは道具屋でこのボタンを押したのか、Pause画面でこのボタンを押したのかを判別している訳ではなかったんですね。
この変数の意味については後で検討します。必要ないなら消します。
勿論、この実装で今最も知りたいのは、道具屋ないでボタンを押した場合です。
そちらを見て行きます。
まずData Table、Itemsから対応するItemのデータを取り出します。
ここで調べてるのはそのItemの値段です。
はい。
そのアイテムの値段よりもお金を持っている場合は、次に進めます。持っていない場合はここで実行は終わっています。
つまり、アイテムを買うお金を持っていない場合はボタンをクリックしても何も起きない訳です。
十分なお金を持っている場合は、まずお金が引かれます。
次に、RPG Game Instance BPの変数でPlayerが操作するキャラの所有するアイテムを管理している変数、Itemsに購入したItemの名前を追加します。
次です。
この部分一体何をしているだろうと思ったら、簡単な事でした。
以下に示した道具の購入画面で左側の道具袋に勝ったアイテムを表示させる実装が書かれていました。
これは報連相の観点から重要ですね。買ったItemが所持品内で表示されなとかなり焦りますから。
ここで作成されるYour Itemウィジェットですが
Textだけで構成されているWidgetです。
この部分を参考にする事で、切符を買うための実装は作成出来ますね。
切符の切れ端10個と普通の切符ですが、それ専用のボタンを作成します。
「切符の切れ端コレクション」ボタンとして、それをクリックすると現在持っている切符の切れ端の数が表示されます。10枚以上だった場合は、普通の切符と交換しますか？ボタンが表示されます。そのボタンを押すと切符の切れ端10枚と交換で普通の切符が貰えます。
銀河鉄道に乗る。場合です。
これはA_WarpGateKeeper BPの復習をする事で実装方法を確認します。
実装方法を見てみます。
うん。これは何をしているでしょうか？
あ。NPCと同じ実装をしています。
これはBPのPrivateな変数がそれぞれのInstanceで独立した値が取れる事を知らない時に書いたコードです。
BPの変数は
にチェックを入れない限り、所謂Global変数みたいな扱いになると思っていましたので、こんな複雑なコードを敢えて書いていました。
実際はInstance Editableにチェックを入れると以下に示したように
Level上に静的に配置したBPのInstance内の変数の値をDetail画面から編集出来ると言う意味でした。
間違っている訳ではないです。ただもっと簡単に実装する方法があるだけです。
そしてその方法は石像との会話で実装しています。
もう頭が働かなくなってきました。
今週はここまでにします。
ワープの実装方法については来週以降考えます。
＜移動シーンのアニメーションの作成。＞
これはまだ実装はしませんが、理想だけ書いておきます。
銀河鉄道で移動すると言う事は別なMapに移動すると言う事になります。
その場合読み込みに時間がかかる場合があります。ない場合もあります。
読み込みに時間が掛かるときは、電車内の会話で人身事故が起きました。とか線路内に人が立ち入ったので点検しています。しばらくお待ちくださいのようなコメントが流れるようにしたいです。
そして次のMapが開く前に○○駅に到着しました。と表示されるようにします。
だけどUE5で制作した場合は読み込み時間がほぼ0になるみたいですよね。そうなると要らない機能になってしまうんでしょうか？
＜駅でセーブも出来るようにする。＞
これは良く考えたら神官の仕事を奪ってしまいます。のでこのアイデアは没にします。ただし駅内に神官を配置する事は考えます。
9. Good Skyの検証
とてもやる知力が残っていません。来週以降やります。
10. まとめと感想
今週は以下の事について勉強しました。
- Particle Systemの勉強
- Niagara：
- 応用編の最初としてCGHOW氏のUnreal Engine Niagara Tutorials [1]を半分だけ実際に作成した。
- Cascade：
- 応用編の最初として炎、雷、氷、水、風、回復などの色々なEffectの資料を集めた。
- Unreal 4 Particles Tutorial - Simple Flame, Embers, Smoke. [6]を元に炎のEffectを作成した。
を行いました。
来週は、
- Particle Systemの勉強
- Niagara：
- CGHOW氏のUnreal Engine Niagara Tutorials [1]の続き
- Cascade：
- 炎以外のEffectの実装
- Niagara：
- RPGの作成
- スタート画面の続きで、魔女との会話を実装
- 切符の実装方法
- 駅における切符の購入の実装
- 駅における移動の実装方法の検証
- 実際に別なマップに移動してる間に別なアニメーションを表示する方法についての調査
- 時間があったらGood Skyの復習
などを行う予定です。
11. 参照（Reference）
[1] CGHOW. (n.d.). Unreal Engine Niagara Tutorials. YouTube. Retrieved August 1, 2021, from https://www.youtube.com/playlist?list=PLwMiBtF6WzsqC7_cJmD26ts0YDbtPCCfe
[2] CGHOW. (2019a, March 2). Unreal Engine Niagara Cloud Tutorial | Download Project Files [Video]. YouTube. https://www.youtube.com/watch?v=hDfKZh1tRmU&list=PLwMiBtF6WzsqC7_cJmD26ts0YDbtPCCfe&index=2
[3] Epic Games. (n.d. -b). Particle Spawn Group. Unreal Engine Documentation. Retrieved August 1, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/Niagara/EmitterReference/ParticleSpawn/
[4] CGHOW. (2019b, August 16). Ice Hit Effect | Unreal Engine Niagara Tutorial [Video]. YouTube. https://www.youtube.com/watch?v=txR-uEwXj64
[5] CGHOW. (2020, July 17). Stylized Water Splash | UE4 Niagara Water Splash | Download Project Files [Video]. YouTube. https://www.youtube.com/watch?v=Xj5fRywPIlo
[6] Game Dev Society BU. (2019, March 14). Unreal 4 Particles Tutorial - Simple Flame, Embers, Smoke. [Video]. YouTube. https://www.youtube.com/watch?v=u7hRDl2yQmM
[7] Epic Games. (n.d.-a). Orbit Modules. Unreal Engine Documentation. Retrieved August 1, 2021, from https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/ParticleSystems/Reference/Modules/Orbit/
