Arbor

物理を使った移動等に使いたいのでUpdateSettingsでFixedUpdateのタイミングも選択できるようにして頂けると嬉しいです。

ご要望ありがとうございます。

viewtopic.php?f=3&t=2597&p=3053#p3051

A_rosuko wrote: ↑2019/05/15 06:21 FixedUpdateについてはStateBehaviourからプログラムを追いかけて、別の方向行ってしまった気がしますが下記の内容を追加してみました。
１、UpdateType.csにEveryFixedUpdateを追加。
２、Updatesettings.csにEveryFixedUpdateでTrueを返すcaseを追加。
３、arborFSMInternal.csにUpdate関数があったので下にFixedUpdate関数を作ってUpdateの中身をコピーして追加。
とりあえず、何か影響が出ないか慎重に確認しながら使ってみようと思います。
この方法でダメだったら提示頂いた方法も含めていろいろ試してみようと思います。
こちらは要望として出しておきますね。

こちらに関する要望ですね。

まずは、ArborFSM全体の処理タイミングをFixedUpdateに切り替えてしまう点についてですが、組み込みスクリプトの処理などはFixedUpdateで処理することを想定していないため、問題が大量に発生する可能性があり、開発面やサポート面でのコストが大きいように思います。

現状でも、StateBehaviourを自作する場合は物理移動処理のみをFixedUpdateメソッド内に書けます（StateBehaviourはMonoBehaviourの継承クラスなのでMonoBehaviourと同様の機能を有しています）ので、それでことは足りませんでしょうか？

また、現状の組み込みスクリプトのうち、どうしてもFixedUpdate処理にしたいものがありましたら、ピックアップしていただければ個別に対応いたします。

より具体的に、UpdateTypeにEveryFixedUpdateを追加する利点などがありましたら、そちらも教えていただけると助かります。

追記：
既にソースを直接変更して試しておられるということですが、ソースを変更されている場合のサポートは原則行っておりませんので、その点もご了承ください。
（Arborのバージョン更新したら変更箇所が消えた、といった報告がありましてもこちらからは何もできません。）

丁寧に説明して頂いてありがとうございます。
検討していただいただけでも嬉しいです。
ソースは触らずStateBehaviourを自作する方向で検討してみます。

FixedUpdateは物理を使う場合はほぼ条件反射的に使っていたのでうまく説明できるかわかりませんが
具体的な利点としては下記の２つでしょうか。
１、一定間隔で更新される。
特殊なケースかもしれませんが、速度の計算で固定フレームの方が少し楽できます。
敵の移動先に向かって偏差射撃するなど。

２、物理の更新タイミングと同期している。
物理の更新タイミングに合わせて確実に１回だけ処理したい場合に向いています。
押すとか移動するとか0回でも2回以上でもダメな場合。

Update(可変フレーム)とFixedUpdate(固定フレーム)でどちらが作りたいものに向いているかという話だと思います。
また何かありましたら相談させてください。
いろいろありがとうございました。

追記：
書き終えてからUpdateSettings.typeがManualの存在に気が付いたのですが
ExecuteUpdate(false)をFixedUpdateから実行してはいけない感じでしょうか？
同様に組み込みスクリプトが想定していないということで・・・。

A_rosuko wrote: ↑2019/05/15 16:12 FixedUpdateは物理を使う場合はほぼ条件反射的に使っていたのでうまく説明できるかわかりませんが
具体的な利点としては下記の２つでしょうか。
１、一定間隔で更新される。
特殊なケースかもしれませんが、速度の計算で固定フレームの方が少し楽できます。
敵の移動先に向かって偏差射撃するなど。

２、物理の更新タイミングと同期している。
物理の更新タイミングに合わせて確実に１回だけ処理したい場合に向いています。
押すとか移動するとか0回でも2回以上でもダメな場合。

概ね私の理解と同じかと思いますが、「２、物理の更新タイミングと同期している」の方が要点となっていますね。
「１、一定間隔で更新される。」は物理計算においては固定フレームでの呼び出しが最適、という意味では理解しています。

ちなみに、UpdateとFixedUpdateの使い分けについては、以下の記事が参考になります。
[Unity] InputとFixedUpdateと物理演算の関係を整理しよう

Input関連の組み込みスクリプトもありますので、OnStateUpdateがFixedUpdateから呼ばれると問題が起きそう、という感じですね。
Input関連以外も組み込みスクリプトは多数あるので、実際にどれに問題があるかを検証するコストを考えると対応は難しいかと思います。
一応Input関連の判定自体はUpdateで処理していますが、どのみち全スクリプトをFixedUpdate版で検証するコストは発生しますので。
（逆に、本来FixedUpdateで処理したほうが良いものをUpdateで処理してしまってる場合もありますが、それは気づき次第個別に対応していきます）

別案として、OnStateFixedUpdateを追加しArborFSMのFixedUpdateから常に呼ばれるようにする、というのも考えられますが、
スクリプト自作するならFixedUpdateそのものが書けるので、今のところ必要性はあまりないと思います。

A_rosuko wrote: ↑2019/05/15 16:12 書き終えてからUpdateSettings.typeがManualの存在に気が付いたのですが
ExecuteUpdate(false)をFixedUpdateから実行してはいけない感じでしょうか？
同様に組み込みスクリプトが想定していないということで・・・。

Manualはグラフの階層化対応の際に、親グラフのUpdateSettingsに依存して動作する仕組みが必要になって追加した感じです。
InputとFixedUpdateの記事にある問題は同様に付いてきますので、「FixedUpdateから実行してはいけない」とまでは言いませんが推奨できない方法となります。
使う分には自由に使っていただいても構いませんが、あくまで自己責任でお願いいたします。

まとめ

こちらが感じている問題点をまとめますと、以下ようになります。

1. 組み込みスクリプトを使用する場合にFixedUpdateから呼び出されることを考慮していないので、対応したら全組み込みスクリプトの再検証作業が発生する。
2. FSM全体の更新をFixedUpdateで使用する利点がよくわからない（物理計算に関連するところだけFixedUpdateのスクリプト書けば済みそう、という考え）。
3. 特殊なロジックを組む際、組み込みスクリプトのみ（スクリプトを一切自作しない）でFSMを使用することも想定していないので、必要に応じてスクリプトを書いていただきたい。

という感じです。
1の検証コストも重要ですが、2の全体更新についての私の理解不足もあって、現状頭に？が並んでいる感じです。

今後も、この件について必要性を感じましたら、具体的なグラフのスクリーンショットなども交えて問題点の共有と改善策を練っていけたら良いなと思います。

貼って頂いた記事の前日は私の記事だったりします。
まとめの２について、物理を使っているとInput関係をUpdateで処理してほとんどをFixedUpdateに書くという逆の場合もあると思っていただければと思います。
物理が無ければFixedUpdateの利点がよくわからないと思われるのも理解できます。
ソフトの方針ですし仕方ないですね。
ありがとうございました。

記事についてはご存じで、予測射撃を書いたお方だったのですね。
私も予測射撃の記事を拝見しております。

ちなみに、具体的にはどの組み込みスクリプトがFixedUpdateで動かなくて困っておられますか？
前にも書きましたが、必要に応じてFixedUpdateで処理するように個別対応いたしますので、遠慮なさらずおっしゃってください。
もちろん、その内容次第では、覚悟を決めて全体対応も検討いたします。

なお、私自身がArborを使用するうえで推奨する思考というか方針としては以下のような感じです。

• ArborFSMはステートパターン（厳密にはFSM）＋挙動をコンポーネントで実装したもの
• １ステートは数フレーム以上にまたがって処理するものを推奨
• 逆に１フレーム内に数ステートにまたがってしまう場合は、できるかぎり自作スクリプトを用いて「ステート」概念の粒度を細かくし過ぎないこと（あくまでステートマシン）。
• 組み込みスクリプトは基本機能として使えそうなものをあらかじめ提供しているにすぎず、この機能を超えた処理を実装する場合は、無理に組み込みスクリプトを組み合わせず自作すること。

あくまで参考程度で、どう組むかはユーザー様にお任せいたします。

基本的に挙動のスクリプトを書けば済む場合や、具体例もなく私が理解できない場合はご期待に沿えないこともある点はご了承ください。

追記：
私も昔物理エンジンを作ったことがあるので、物理計算は固定フレームで処理しないと力を加える計算やめり込み判定などでひどい目に合うのも重々承知している点も追記しておきます。

記事読んで頂いていたのはとてもうれしいです。
お気遣い頂きありがとうございます。
ArborFMSをまだ触り始めたばかりでどう使っていこうか勉強している段階なので現状で困っていることは特にありません。

先日の問題もマッハで原因特定して解決しましたし、最高のサポート体制だと感じてます。
なにかありましたらまた相談させて頂きたいと思います。

現状で困っていることは特にないということで、こちらとしてもひとまず安心いたしました。
今後ともよろしくお願いいたします。