Объединенные государства, ФСМ

Question

Является ли «правильным» объединение состояний автомата-автомата?

Скажем, у вас есть объект с

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

Просто так получается, что имеет смысл объединять состояния, как в

State myState = State1 | State2 ;

однако в теории FSM это незаконно?

Это скорее ярлык:

Скажем, у вас есть 3 состояния: бег, ходьба и прыжки. Тогда у вас четвертый государственный стрельба.

Вы должны уметь бегать и стрелять, ходить и стрелять, а также прыгать и стрелять. вместо создания 6 состояний RunningFiring, WalkingFiring, JumpingFiring, я бы хотел объединить состояние стрельбы с (независимо от состояния прыжка при ходьбе)

Я знаю, что мог бы просто использовать BOOL для «четвертого состояния», но разве это не кажется еще более неправильным? Имея «состояние на стороне ...»

Answer 1

Я помню, как читал книгу по программированию игр, когда мне было около 13 лет, и видел пример использования битовой маски для моделирования атрибутов. Что-то вроде

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

и так далее. Затем вы можете представлять атрибуты NPC как int, и вы можете устанавливать / очищать отдельные биты, используя атрибуты в качестве масок.

Теперь, конечно, битовая упаковка гораздо реже, поскольку память стала дешевле, и поэтому мы можем просто использовать логические значения для представления атрибутов. В любом случае, это похоже на то, что вы хотите сделать.

Атрибуты, однако, не совпадают с состояниями в конечном автомате. Нахождение в автомате означает, что вы не находитесь ни в каком другом состоянии. Так что, если у вас есть множество вещей, которые не являются взаимоисключающими, конечный автомат, вероятно, не тот путь. Учтите, что каждый добавляемый вами двоичный атрибут удваивает размер всей машины.

Когда вы говорите

Я знаю, что могу просто использовать BOOL для «четвертое состояние», но разве это не кажется еще злее? Имея "состояние на сторона .. "

для меня это означает, что может быть проблема с тем, как вы думаете об информации, которую вы представляете. Конечно, «увольнение» звучит как хороший кандидат на государство, и если вы всегда либо увольняете, либо делаете что-то еще, то это работает как конечный автомат. Но если «Увольнение» можно объединить со всеми состояниями в существующей системе, действительно ли это вместо этого повредит моделированию его как атрибута?

Answer 2

Мне кажется, что это пример AND-разложения состояний (а также нормального разложения исключающего ИЛИ). UML моделирует эту ситуацию с ортогональными областями. Итак, в этом случае у вас есть две ортогональные области. Первый содержит нормальные состояния ИЛИ Бег, Ходьба и Прыжки. Другая ортогональная область содержит состояние обжига. Этот конечный автомат допускает следующие комбинации: бег | стрельба, ходьба | стрельба и прыжки | стрельба.

Вы можете аппроксимировать такие две ортогональные области с помощью двух конечных автоматов (вам нужны две переменные состояния). Пока у конечного автомата для стрельбы есть только одно состояние, но я уверен, что в конечном итоге вы получите дополнительное состояние «не стрельба», так что это будет правильный конечный автомат.

Миро Самек, state-machine.com

Answer 3

По моему мнению, когда вы начинаете нуждаться в объединении состояний, подобных этому, ваш конечный автомат начинает делать слишком много. Возможно, вам придется рассмотреть вопрос о перемещении некоторых функций / логики в отдельный конечный автомат, ориентированный на те задачи, которые могут или не могут изменить состояние, пока «родительский» конечный автомат находится в другом состоянии.