Комбинированные состояния, FSM

«Правильно» ли комбинировать состояния FSM?

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

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

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

State myState = State1 | State2 ;

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

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

Допустим, у вас есть 3 состояния: Бег, Ходьба и Прыжки. Затем у вас есть четвертое состояние Firing.

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

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


fsm
person bobobobo    schedule 19.03.2010    source источник
comment
вы имеете в виду реальный пример? Обычно подобное состояние указывает на необходимость другого состояния...   -  person Steve    schedule 19.03.2010
comment
@Steve: это звучит как ответ. Пожалуйста, опубликуйте это как ответ, чтобы мы могли правильно проголосовать за него.   -  person S.Lott    schedule 19.03.2010

Ответы (3)


arrow_upward
1
arrow_downward

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

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

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

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

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

Когда ты сказал

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

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

person danben    schedule 19.03.2010
comment
Я думаю, вы правы в том, что рассматривать Firing как атрибут это нормально.. т. е. Firing — это не состояние . спс за ответ! - person bobobobo; 19.03.2010

arrow_upward
1
arrow_downward

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

person Joel Martinez    schedule 19.03.2010
comment
Это еще больше подтверждает мою точку зрения :-) У вашего парня должен быть конечный автомат передвижения, который имеет состояния ходьбы/бега/прыжка. В качестве отдельного модуля он может иметь тактический конечный автомат, который может принимать решения стрелять, защищаться и т. д. - person Joel Martinez; 19.03.2010

arrow_upward
1
arrow_downward

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

Вы можете аппроксимировать такие две ортогональные области двумя конечными автоматами (вам нужны две переменные состояния). На данный момент конечный автомат для Firing имеет только одно состояние, но я уверен, что вы получите дополнительное состояние «not-Firing», так что это будет правильный конечный автомат.

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

person Miro Samek    schedule 31.03.2010