联合州，密克罗尼西亚联邦

发布于 2024-08-25 12:51:35 字数 557 浏览 8 评论 0原文

组合 FSM 的状态是否“正确”？

假设你有一个带有 It 的对象，

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

碰巧组合状态是有意义的，但是

State myState = State1 | State2 ;

在 FSM 理论中这是非法的吗？

它更像是一条捷径：

假设你有 3 种状态：跑步、行走和跳跃。然后你有第四个状态射击。

你需要能够奔跑并开火，行走并开火，以及跳跃并开火。我不想将“RunningFiring”、“WalkingFiring”、“JumpingFiring”这 6 个状态组合起来，而是将“Firing”状态与（无论“Walking Running Jump”状态）组合，

我知道我可以使用 BOOL 作为“第四状态”，但这似乎不是更错误吗？有一个“国家在一边......”

原文

Is it "correct" to combine states of an FSM?

Say you have an object with

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

It just so happens that it makes sense to combine states, as in

State myState = State1 | State2 ;

however in FSM theory is this illegal?

It's more a shortcut:

Say you have 3 states: Running, Walking, and Jumping. Then you have a fourth state Firing.

You need to be able to Run and Fire, Walk and Fire, and Jump and Fire. instead of making 6 states RunningFiring, WalkingFiring, JumpingFiring, I'd like to combine the Firing state with (whatever Walking Running Jumping state)

I know I could just use a BOOL for the "fourth state", but doesn't that seem even wronger? Having a "state on the side..."

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

儭儭莪哋寶赑 2024-09-01 12:51:36

在我看来，当你开始需要像这样组合状态时，那么你的状态机就开始做得太多了。您可能需要考虑将某些功能/逻辑移动到一个单独的状态机中，该状态机专注于当“父”状态机处于另一种状态时可能会或可能不会更改状态的一个任务。

回复收藏 0 原文

淡淡的优雅 2024-09-01 12:51:35

在我看来，这是状态与分解（以及正常的异或分解）的一个例子。 UML 使用正交区域对这种情况进行建模。因此，在这种情况下，您有两个正交区域。第一个包含正常的 OR 状态“跑步”、“行走”和“跳跃”。另一个正交区域包含状态射击。该状态机允许以下组合：跑步|开火、步行|开火和跳跃|开火。

您可以使用两个状态机来近似这两个正交区域（您需要两个状态变量）。目前，触发的状态机只有一个状态，但我确信您最终会得到补充状态“未触发”，因此它将是一个合适的状态机。

米罗·萨梅克，state-machine.com

回复收藏 0 原文

寒江雪… 2024-09-01 12:51:35

我记得大约 13 岁的时候读过一本关于游戏编程的书，看到了一个使用位掩码来建模属性的示例。类似之类的东西

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

。然后，您可以将 NPC 的属性表示为 int，并且可以使用属性作为掩码来设置/清除各个位。

当然，现在，随着内存变得越来越便宜，位打包已经不那么常见了，因此我们可以只使用布尔值来表示属性。无论如何，这看起来与您想要做的类似。

然而，属性与状态机中的状态不同。在状态机中，处于一种状态意味着您不一定处于任何其他状态。因此，如果您有一堆不互相排斥的东西，那么状态机可能不是最佳选择。考虑一下您添加的每个二进制值属性都会使整个计算机的大小增加一倍。

当你说

我知道我可以使用 BOOL 来表示
“第四状态”，但这似乎不是
甚至更错？拥有“状态
侧面..”

这对我来说意味着你思考你所代表的信息的方式可能有问题。当然，“解雇”听起来像是一个很好的州候选人，如果你总是无论是触发还是做其他事情，它都可以作为状态机工作。但是，如果“触发”可以与现有系统中的所有状态结合起来，那么将其建模为属性真的会有什么害处吗？

I remember reading a book on game programming back when I was 13 or so and seeing an example of a bitmask being used to model attributes. Something like

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

and so on. Then you could represent an NPC's attributes as an int, and you could set / clear individual bits using the attributes as masks.

Now, of course, bitpacking is much less common as memory has become cheaper, and as such we can just use boolean values to represent attributes. Regardless, this seems similar to what you want to do.

Attributes, however, aren't the same as states in a state machine. In a state machine, being in one state means that you are necessarily not in any other state. So if you have a bag of things that are not mutually exclusive, a state machine is probably not the way to go. Consider that each binary-valued attribute you add will double the size of your entire machine.

When you say

I know I could just use a BOOL for the
"fourth state", but doesn't that seem
even wronger? Having a "state on the
side.."

it signifies to me that there might be a problem with the way you're thinking about the information that you're representing. Sure, "Firing" sounds like a good candidate for a state, and if you're always either firing or doing something else then it works as a state machine. But if "Firing" can be combined with all of the states in the existing system, would it really do any harm to model it as an attribute instead?

回复收藏 0 原文

~没有更多了~