2

FSMの状態を組み合わせるのは「正しい」ですか？

あなたがオブジェクトを持っているとしましょう

enum State
{
    State1 = 1 << 0,
    State2 = 1 << 1,
    State3 = 1 << 2
} ;

たまたま、次のように状態を組み合わせることが理にかなっています。

State myState = State1 | State2 ;

しかし、FSM理論では、これは違法ですか？

それはもっと近道です：

ランニング、ウォーキング、ジャンプの3つの状態があるとします。次に、4番目の状態の発砲があります。

走って発射、歩いて発射、ジャンプして発射できる必要があります。RunningFiring、WalkingFiring、JumpingFiringの6つの状態を作成する代わりに、Firing状態を（Walking Running Jumping状態）と組み合わせたいと思います。

「第4の状態」にBOOLを使用できることは知っていますが、それはさらに間違っているように思われませんか？「側の状態...」を持っている

4

3 に答える 3

1

13歳くらいのときにゲームプログラミングに関する本を読んだり、属性のモデル化にビットマスクが使用されている例を見たりしたことを覚えています。何かのようなもの

const int HAS_WEAPON =    0x1;
const int WEARING_ARMOR = 0x2;
const int IS_ALIENT     = 0x4;

等々。次に、NPCの属性をintとして表すことができ、属性をマスクとして使用して個々のビットを設定/クリアすることができます。

もちろん、メモリが安くなったため、ビットパッキングはそれほど一般的ではなくなりました。そのため、ブール値を使用して属性を表すことができます。とにかく、これはあなたがやりたいことと似ているようです。

ただし、属性はステートマシンの状態と同じではありません。ステートマシンでは、1つの状態にあるということは、必ずしも他の状態にないことを意味します。したがって、相互に排他的ではないもののバッグがある場合、ステートマシンはおそらく行く方法ではありません。追加する各バイナリ値属性は、マシン全体のサイズを2倍にすることを考慮してください。

あなたが言う時

「第4の状態」にBOOLを使用できることは知っていますが、それはさらに間違っているように思われませんか？「側の状態」を持つ。

それは、あなたが表現している情報についてのあなたの考え方に問題があるかもしれないことを私に意味します。確かに、「発砲」はステートの良い候補のように聞こえます。常に発砲するか、何か他のことをしている場合は、ステートマシンとして機能します。しかし、「発砲」を既存のシステムのすべての状態と組み合わせることができる場合、代わりにそれを属性としてモデル化することは本当に害を及ぼしますか？

于 2010-03-19T02:33:22.247 に答える
1

私の意見では、このような状態を組み合わせる必要が出始めたとき、ステートマシンはあまりにも多くのことをし始めています。「親」ステートマシンが別の状態にあるときに状態を変更する場合と変更しない場合がある1つのタスクに焦点を当てた、別のステートマシンに一部の機能/ロジックを移動することを検討する必要がある場合があります。

于 2010-03-19T01:58:38.350 に答える
1

これは、状態のAND分解（および通常の排他的論理和分解）の例であるように思われます。UMLは、この状況を直交領域でモデル化します。したがって、この場合、2つの直交する領域があります。最初のものには、通常のOR状態のRunning、Walking、およびJumpingが含まれています。もう一方の直交領域には、状態の発火が含まれています。このステートマシンでは、ランニング|ファイアリング、ウォーキング|ファイアリング、ジャンプ|ファイアリングの組み合わせが可能です。

このような2つの直交領域は、2つのステートマシンで近似できます（2つの状態変数が必要です）。今のところ、Firingのステートマシンには1つの状態しかありませんが、補完的な状態「not-Firing」になると確信しているので、適切なステートマシンになります。

Miro Samek、state-machine.com

于 2010-03-31T01:10:11.617 に答える