待って、気が変わった」 - ステートマシン遷移の中断

それでは、ステート・マシンの遷移と割り込みの複雑な詳細に飛び込んでみよう！

アニメーション・システムのデフォルトでは、トランジションを中断することはできない。いったんある状態から別の状態に移行し始めると、そこから抜け出すことはできない。大西洋を横断するフライトの乗客のように、目的地に着くまで座席でくつろいでいる。ほとんどのユーザーにとっては、これで問題ない。

しかし、トランジションをよりコントロールする必要がある場合、Mecanimはニーズに合わせてさまざまな方法で設定することができます。現在の目的地に不満がある場合は、操縦席に乗り込み、フライトの途中で計画を変更することができる。これは、より反応性の高いアニメーションを意味するが、同時に複雑さに没頭する機会も多い。

では、それを整理するためにいくつかの例を挙げてみよう。AからDとラベル付けされた4つの状態と、ステートマシンのすべての遷移にフックされたトリガーを持つ、かなり単純なステートマシンから始めることができる。

デフォルトでは、A->Bの遷移をトリガーすると、ステートマシンはBに向かって遷移し、目的地に到達するのを妨げるものは何もない。しかし、A->Bのトランジション・インスペクタで、中断ソースを "None "から "Current State "に変更すると、AからBへの旅は、ステートA上のいくつかの トリガーによって中断される可能性がある。

なぜ「一部」だけなのか？というのも、"オーダー中断 "チェックボックスもデフォルトでチェックされているからだ。つまり、状態Aでは、現在の状態よりも優先順位の高い遷移のみが許可される。状態Aの検査官を見ると、これはA->Cの遷移にのみ適用されることがわかる。

つまり、A->Bのトリガーを作動させ、A->Dのトリガーを作動させた直後であれば、トランジションは中断されない。しかし、代わりにA->Cのトリガーを押すと、遷移は即座に中断され、ステートマシンはCに向かって遷移を開始する。

内部的には、アニメーションシステムは中断時のポーズを記録し、その静止ポーズ（X）と新しいデスティネーションアニメーションをブレンドします。なぜ静止ポーズなのでしょうか？簡単に言えば、パフォーマンスだ。ゲームがカスケード的な中断に直面した場合、同時に起こる複数のダイナミックなトランジションを追跡し続けることは、アニメーションシステムをすぐにスケーラブルなものにしてしまう。

ここで、「順番に割り込む」チェックボックスのチェックを外すと、A->CとA->Dの両方がトランジションに割り込むことができる。しかし、両者が同じフレームでトリガーされた場合、A->Cの方が優先順位が高いため、やはりA->Cが優先される。

中断元を「次の状態」に変更すると、A->CとA->Dは、その順番に関係なく、トランジションを中断することができなくなる。しかし、B->Dのトリガーを押すと、Bへの移行が完了することなく、すぐにAからDへの移行が始まる。

状態Bでもトランジションの順番は重要だ。ただし、Bのトランジションが同じフレーム内でトリガーされた場合、どちらのトランジションが優先されるかは、Bのトランジションの順番によって決まります。この場合、B->DとB->Cが同じフレームでトリガーされると、B->Dが選択される。

最後に、完全にコントロールするために、中断ソースを「現在の状態→次の状態」または「次の状態→現在の状態」に設定することができる。その場合、トランジションは一方の状態、他方の状態というように独立して分析される。

そこで、次のようなコンフィギュレーションを想定してみよう。

A->Bのトランジションでは、非常に興奮した選手が同じフレーム内で4つのトランジションを引き起こす：A->C、A->D、B->C、B->D。どうなるんだ？

まず、"Ordered Interruption "がチェックされているので、A->Dはすぐに無視できる。現在の状態が最初に解決されるので、状態Bを見るまでもなく、遷移A->Cの勝ちがわかる。