Размер видео: 1280 X 720853 X 480640 X 360
Показать панель управления
Автовоспроизведение
Автоповтор
全てのキャラクターにダメージ計算や能力値の上下などを持たせたい場合、キャラ毎にマイブループリントの関数へコピー&ペーストするのではなく、別途ブループリント関数にまとめて呼び出したほうが良さそう?ですね。
コメントありがとうございます~!そうですね、同じような関数をそれぞれのブループリントで作ると、後で変更しようとした時に大変なので、まとめられるものはまとめた方が良いですね!無理やりまとめようとした結果、インプットが多くなって中で大量にブランチする…とかになるとそれはそれで大変なので、小さい機能ごとにまとめていくのがいいかな…と思ってます!
@@kuriemeiku 一度全てまとめようとしたのですが、1つのインプットから枝分かれするように引っ張る事はできても、1つのアウトプットに異なる数値(ダメージ計算結果)を入れる事が出来なかった事と実行ピンも同じく一つまでだったので難しそうなので小分けにしようと思います。
@@おおみみず >1つのアウトプットに異なる数値(ダメージ計算結果)を入れる事が出来なかったこれはリターンノードを分けるか、数値を一度ローカル変数に入れてその値をアウトプットに入れることで解決するかなと思います。>実行ピンも同じく一つまでこれは関数が終わった後の処理を変えたい、ということですかね?アウトプットに列挙型を追加して、関数から抜けたところで列挙型でスイッチを使うことで一応解決はできるかなと思いますが、そこまでして統一するべきなのか、はまた別の話になりますね…。
@@kuriemeiku リターンノードって増やせたんですね、始めて知りました。リターンノードを増やしても他で呼び出す時アウトプットの見た目に変化が無かったので、内部の実行ピンの分岐で関数のアウトプットから異なる結果が出るという事になるのでしょうか。上手くやれば一つに出来そうな気がしてきたのですが、物凄く縦長の関数になりそうであんまり意味が無さそうな気もしました。実行ピンはウィジェットの方の話と繋がるのですが、ダメージ計算結果を上手く纏められてもウィジェット作成のインプット側の実行ピンが一つだけで、その前にブランチで分岐しているため纏められないなーという意味です。今回のブループリント関数とは関係が無いかも?しれません。
キャラごとに色々なダッシュ機能(ドッジロール or 俊足 or テレポートなど)を搭載したいと思った場合、・Interfaceで実装する。・Componentで実装する。どちらが合理的なものでしょうか?どちらも「機能を追加する」ような要素な気がして、掴めておりません。漠然とした質問で恐縮です。お時間のある時に返信いただきたく!🙏
う~~~~~ん、難しいところですね…。キャラごとに、ということだったので、例えば、「3種類のキャラ(皆ダッシュ方法が違う)」と「ダッシュ板」があったとして、ダッシュ板の上にキャラが乗ったら自動的にキャラがダッシュする、みたいな仕様があるとします。そのときは、IDashインターフェースを作って各キャラクターに実装して、ダッシュ板からは上に乗ったキャラのIDashインターフェースの関数を呼ぶ、みたいな形にすると、ダッシュ板は各キャラクタークラスを知らなくていいので、依存が減り疎結合になってよい、とは思います。じゃあ、実際にそのダッシュの機能をどう各キャラクターで実装すればいいのか、といったときにはDodgerollComponentやTeleportComponentを作って、componentとして実装してもいいと思いますし、各キャラクターにそのまま実装してもまあいいかなと思います。(使いまわしたくなった時に別クラス化すれば)ただ、上記のダッシュ板のような仕様がなかったとして、自分で操作したらダッシュするだけ、とかであれば別にインターフェースは無くてもいいかなと思います。インターフェースは、あくまでも外部との結合のために使うもの、という認識なので、内部で閉じている分に関してはインターフェース化する必要がないはずです。ただ、コンポーネント以外にも、UEにはGameplayAbilitySystemという神機能があるので、私なら各ダッシュをAbilityにして実装すると思います!アビリティなら、Tag指定で起動できるので、ダッシュ板でもインターフェースが不要になりますし。
@@kuriemeiku 詳細にありがとうございます‥!九里江さんのGAS説明動画も拝見しました。「自分で操作したらダッシュするだけ」であれば・GASを使うのが良さそう。・必ずしもインターフェースを使う必然性は無さそう。だということがわかっただけで方針が定まりましたので、とても助かりました‥!余談ながら‥本件同様、UE5を使っていて初心者ながら難しいと感じるのが、・同じ機能だから共用化したい。・同じアニメーションだから共用化したい。と思った時に「どうやって?」がわからないことが多く手が止まってしまう点です。先程もVRMモデルを更新してImportし直そうと思った時に、同じボーン構造のモデルなのでスッと差し替えられるかな?と思ったものの、単純な差し替え方法がわからず、結局イチからImportし直してIKリターゲットでAnimationを作り直し、モンタージュを作り直し、通知を作り直し、Blueprintを修正、etc...とするしか術が無く、自分の無知を嘆いています(´Д⊂ヽこの"後から差し替え不可能かもしれない恐怖"が強い障壁でして、九里江さんの言う「使いまわしたくなった時に別クラス化」とか、前工程を編集し直した場合の差し替えといった手順について、今後解説に含めていただけるととても有り難いです!
データのインポート周りは私も怖いですね…。インポートするときに、本当に更新なのであれば、新規データにならないように(既存データの上書きになるように)インポートするとよいかもです!あとは、CompatibleSkeletonを使う、ですね!ruclips.net/video/a9hyQTV-DDw/видео.html後から差し替え不可能なやつの判別は、難しいですね…。私もそんなに…ですけど、基本的にBPとかのロジック系に関しては、比較的あとからやりやすい、というか、言ったら結局作り直しなので、差し替えるというか、結局作り直しているだけ、という…。
いつも大変助かっております!クラス設定の中でインターフェースを追加する際・実装インターフェース・継承インターフェースと二種類ありますが、動画と違い継承インターフェース側にしか追加ドロップダウンが表示されません。環境は5.1になります。(以前のバージョンを使用したところ動画通りになりました。)継承インターフェース側で追加しても問題なく動いてはいるんですが、理由がわからずなんだかモヤモヤしております。。。もし理由ご存じでしたらお時間ある際にご教示いただけますと幸いです!
ほんとだ…!私も言われて気が付きました…!逆になってますね…!片方が「親から継承しているインターフェース」で、片方が「このクラスで追加したインターフェース」なのですが、どこかのバージョンで名前が変わったんですかね…?使用上は問題ないと思います!
どこのブループリントで何を実装したのか全然わからんかったのとそれぞれのクラスで関数定義するならインターフェースってないのと一緒じゃないの!?メリットとか使う場面が全然わからんかった
05:00までがメリットのところですね!それぞれのクラスで関数定義すると、その関数を呼ぶためにそのクラスにキャストしないといけなくて、クラスの数が増えるとそれが大変ですよね、という話です!
全てのキャラクターにダメージ計算や能力値の上下などを持たせたい場合、キャラ毎にマイブループリントの関数へコピー&ペーストするのではなく、別途ブループリント関数にまとめて呼び出したほうが良さそう?ですね。
コメントありがとうございます~!
そうですね、同じような関数をそれぞれのブループリントで作ると、後で変更しようとした時に大変なので、まとめられるものはまとめた方が良いですね!
無理やりまとめようとした結果、インプットが多くなって中で大量にブランチする…とかになるとそれはそれで大変なので、小さい機能ごとにまとめていくのがいいかな…と思ってます!
@@kuriemeiku
一度全てまとめようとしたのですが、1つのインプットから枝分かれするように引っ張る事はできても、1つのアウトプットに異なる数値(ダメージ計算結果)を入れる事が出来なかった事と実行ピンも同じく一つまでだったので難しそうなので小分けにしようと思います。
@@おおみみず
>1つのアウトプットに異なる数値(ダメージ計算結果)を入れる事が出来なかった
これはリターンノードを分けるか、数値を一度ローカル変数に入れてその値をアウトプットに入れることで解決するかなと思います。
>実行ピンも同じく一つまで
これは関数が終わった後の処理を変えたい、ということですかね?
アウトプットに列挙型を追加して、関数から抜けたところで列挙型でスイッチを使うことで一応解決はできるかなと思いますが、
そこまでして統一するべきなのか、はまた別の話になりますね…。
@@kuriemeiku
リターンノードって増やせたんですね、始めて知りました。
リターンノードを増やしても他で呼び出す時アウトプットの見た目に変化が無かったので、内部の実行ピンの分岐で関数のアウトプットから異なる結果が出るという事になるのでしょうか。
上手くやれば一つに出来そうな気がしてきたのですが、物凄く縦長の関数になりそうであんまり意味が無さそうな気もしました。
実行ピンはウィジェットの方の話と繋がるのですが、ダメージ計算結果を上手く纏められてもウィジェット作成のインプット側の実行ピンが一つだけで、その前にブランチで分岐しているため纏められないなーという意味です。今回のブループリント関数とは関係が無いかも?しれません。
キャラごとに色々なダッシュ機能(ドッジロール or 俊足 or テレポートなど)を搭載したいと思った場合、
・Interfaceで実装する。
・Componentで実装する。
どちらが合理的なものでしょうか?
どちらも「機能を追加する」ような要素な気がして、掴めておりません。
漠然とした質問で恐縮です。お時間のある時に返信いただきたく!🙏
う~~~~~ん、難しいところですね…。
キャラごとに、ということだったので、例えば、「3種類のキャラ(皆ダッシュ方法が違う)」と「ダッシュ板」があったとして、ダッシュ板の上にキャラが乗ったら自動的にキャラがダッシュする、みたいな仕様があるとします。
そのときは、IDashインターフェースを作って各キャラクターに実装して、ダッシュ板からは上に乗ったキャラのIDashインターフェースの関数を呼ぶ、みたいな形にすると、
ダッシュ板は各キャラクタークラスを知らなくていいので、依存が減り疎結合になってよい、とは思います。
じゃあ、実際にそのダッシュの機能をどう各キャラクターで実装すればいいのか、といったときにはDodgerollComponentやTeleportComponentを作って、componentとして実装してもいいと思いますし、各キャラクターにそのまま実装してもまあいいかなと思います。(使いまわしたくなった時に別クラス化すれば)
ただ、上記のダッシュ板のような仕様がなかったとして、自分で操作したらダッシュするだけ、とかであれば別にインターフェースは無くてもいいかなと思います。インターフェースは、あくまでも外部との結合のために使うもの、という認識なので、内部で閉じている分に関してはインターフェース化する必要がないはずです。
ただ、コンポーネント以外にも、UEにはGameplayAbilitySystemという神機能があるので、私なら各ダッシュをAbilityにして実装すると思います!
アビリティなら、Tag指定で起動できるので、ダッシュ板でもインターフェースが不要になりますし。
@@kuriemeiku 詳細にありがとうございます‥!九里江さんのGAS説明動画も拝見しました。「自分で操作したらダッシュするだけ」であれば
・GASを使うのが良さそう。
・必ずしもインターフェースを使う必然性は無さそう。
だということがわかっただけで方針が定まりましたので、とても助かりました‥!
余談ながら‥本件同様、UE5を使っていて初心者ながら難しいと感じるのが、
・同じ機能だから共用化したい。
・同じアニメーションだから共用化したい。
と思った時に「どうやって?」がわからないことが多く手が止まってしまう点です。
先程もVRMモデルを更新してImportし直そうと思った時に、同じボーン構造のモデルなのでスッと差し替えられるかな?と思ったものの、単純な差し替え方法がわからず、結局イチからImportし直してIKリターゲットでAnimationを作り直し、モンタージュを作り直し、通知を作り直し、Blueprintを修正、etc...とするしか術が無く、自分の無知を嘆いています(´Д⊂ヽ
この"後から差し替え不可能かもしれない恐怖"が強い障壁でして、九里江さんの言う「使いまわしたくなった時に別クラス化」とか、前工程を編集し直した場合の差し替えといった手順について、今後解説に含めていただけるととても有り難いです!
データのインポート周りは私も怖いですね…。
インポートするときに、本当に更新なのであれば、新規データにならないように(既存データの上書きになるように)インポートするとよいかもです!
あとは、CompatibleSkeletonを使う、ですね!
ruclips.net/video/a9hyQTV-DDw/видео.html
後から差し替え不可能なやつの判別は、難しいですね…。
私もそんなに…ですけど、基本的にBPとかのロジック系に関しては、比較的あとからやりやすい、というか、
言ったら結局作り直しなので、差し替えるというか、結局作り直しているだけ、という…。
いつも大変助かっております!
クラス設定の中でインターフェースを追加する際
・実装インターフェース
・継承インターフェース
と二種類ありますが、動画と違い継承インターフェース側にしか追加ドロップダウンが表示されません。
環境は5.1になります。
(以前のバージョンを使用したところ動画通りになりました。)
継承インターフェース側で追加しても問題なく動いてはいるんですが、理由がわからずなんだかモヤモヤしております。。。
もし理由ご存じでしたらお時間ある際にご教示いただけますと幸いです!
ほんとだ…!
私も言われて気が付きました…!逆になってますね…!
片方が「親から継承しているインターフェース」で、片方が「このクラスで追加したインターフェース」なのですが、
どこかのバージョンで名前が変わったんですかね…?
使用上は問題ないと思います!
どこのブループリントで何を実装したのか全然わからんかったのと
それぞれのクラスで関数定義するならインターフェースってないのと一緒じゃないの!?
メリットとか使う場面が全然わからんかった
05:00までがメリットのところですね!
それぞれのクラスで関数定義すると、その関数を呼ぶためにそのクラスにキャストしないといけなくて、
クラスの数が増えるとそれが大変ですよね、という話です!