Arbor

お世話になっております。

基本的な仕組みについて質問させていただきます。
ゲームのUpdateが行われたときに呼ばれるステートは１つのみという認識でよろしいでしょうか？

CharacterControllerのMoveを行うStateBehaviorを作成しました。
これを使用し、SDユニティちゃんに歩行モーションを行わせつつ
Move→GotoTransition→Move...とステートを交互に繰り返して移動させてみたところ
移動にがたつきが発生しました。
おそらく、内部処理で1フレーム間隔でMove処理が行われているからだと思いますが
Arborの挙動として、1フレームで行わせたい処理は1ステート内の中にまとめる
という認識でよろしいでしょうか？

ゲスト wrote:基本的な仕組みについて質問させていただきます。
ゲームのUpdateが行われたときに呼ばれるステートは１つのみという認識でよろしいでしょうか？

原則的に実行されるステートは通常ステート１つと全ての常駐ステートとなっています。
もし並列的にステートを状態遷移させたい場合は別のArborFSMを用意して別々に処理する形になります。

ゲスト wrote:Move→GotoTransition→Move...とステートを交互に繰り返して移動させてみたところ
移動にがたつきが発生しました。
おそらく、内部処理で1フレーム間隔でMove処理が行われているからだと思いますが
Arborの挙動として、1フレームで行わせたい処理は1ステート内の中にまとめる
という認識でよろしいでしょうか？

1フレーム中に複数のステートをまたがって遷移させるには、TransitionTimingをImmediateにすることで可能です。
詳しくはマニュアルの「TransitionTimingについて」を参照してください。
http://arbor.caitsithware.com/manual/ge ... tionTiming

ただし、遷移先がループしている＆OnStateBegin()など遷移時のコールバックからTransitionを行っている際にImmediateにしていると、無限ループになってStackOverflowExceptionが投げられる可能性がありますので注意が必要です。

また、推奨する組み方としましては、1フレーム内に細かく遷移をするような組み方ではなく、1ステート数フレーム以上かかるようなステートの粒度が大きい組み方を推奨いたします。
Arbor Editor上でのデバッグもしづらくなるのはもちろん、ロジック的に「状態」と言えない単位でまでノードを分割するとステートマシンを使う意義自体がなくなってしまうためです。
私自身もステートの粒度は難しくこれといった正解は持てていませんが、一度ご検討頂ければと思います。

ご返信ありがとうございます。

>また、推奨する組み方としましては、1フレーム内に細かく遷移をするような組み方ではなく、
>1ステート数フレーム以上かかるようなステートの粒度が大きい組み方を推奨いたします。
了解しました。UE4のBluePrintのような使い方を考えていましたが
AIのような使用用途にのみ使用しようと思います。