前回の記事はこちら
検証バージョン
Unity 2017.1.1p1
Arbor 2.1.7
処理の流れ
処理実行順
Arbor2を使ってみよう その1 概要 - hildsoftのコード置き場
で紹介した簡単なパターンから見ていきます。
Arbor2の処理は開始ステートから始まります。
Behaviourはステートごとに上から順に全て実行されます。
ステートは有効になった時に1度だけ実行されます。 そのステート中であれば常に実行されるというわけではないので注意してください。
(Tween系は更新処理があるので、UpdateやFixedUpdate内での時間経過処理が実行されますが、開始処理は有効になった時のみです)
ただし、Transition系(ステートを変更するもの)は、Updateメソッドを持っているため毎フレーム実行されています。
これはUnityのUpdateと同じ仕様で実行順は不確定ですので、並び順の通りに処理されることを期待してはいけません。
BehaviourのUpdateが実行された時に有効であれば移動先は上書きされてしまいます。 (Behaviourの条件が満たされている中で、最後に呼ばれたものに移動します)
なので、左右両方のキーを押した状態だと、どちらが有効になるかは保証されていません。
ステート更新のタイミング
ステートの変更はUnityのLateUpdateメソッド呼び出し時に更新されます。
ステートが変更されたときに実行されるBehaviourの処理もここで実行されます。
上記のFSMでは入力チェックと移動が分かれているため、キーを押しっぱなしにしても1フレームおきに移動します。
その結果、カクカクとした動きになってしまいます。
Unityのイベント呼び出しの順番はこちらを参照してください。
Unity - Manual: Execution Order of Event Functions
Immediate Transition
Transition系には、追加の設定があり、名前(初期値:Next State)の変更、矢印の色変更ができます。
また、処理に関わる重要な設定に、Immediate Transitionがあります。
このチェックがオンの状態だとLateUpdateを待たず、すぐにステートが切り替わって次のステートの処理も引き続き実行します。
常駐ステート
常駐ステートは、常に有効になっているステートになります。
ここでも注意しないといけないのが、ステートは1度だけ実行されることです。
Updateを持たないBehaviourは起動時に一度だけ実行されて、毎フレーム呼ばれるわけではありません。
処理の順番
画面の左側のTransitionはImmediate Transitionをオンに、右側をオフにしています。
現在のステートと、常駐ステートにKey Transitionで同じキーを監視しているBehaviourがあります。
右キーを押したとき、Updateが早く呼ばれた方のBehaviourのステートへ変更されます。
現在のステートにあるKey Transitionが先にUpdateを呼び出されたとします。
このとき、Immediate Transitionの設定のため、Updateでステートが更新されます。
通常はLateUpdateで実行されるステートの変更呼び出しもUpdate内で呼ばれることになります。
また、Go To Transitionでステート変更が予約されています。
全てのオブジェクトのUpdateが呼び出され、最後にLateUpdateが呼び出されます。
Go To Transitionで予約されていたステートに更新されるため、先ほどのステートまで戻ります。
Key TransitionはUpdateで処理を待つだけなので、実質なにも処理は行われません。
そして次のフレームのUpdateで再びキー入力を待ち受けます。
2017/09/19 21:18
仕様を誤解していましたので、大幅に書きなおしました。申し訳ありません。