Обработка событий в государственном автомате

Question

У меня есть конечный автомат для моего npcs, который структурирован следующим образом:

execute state
[[[pred1 pred2....] state1]
 [[pred3 pred4....] state2]
 [[pred5 pred6....] staten]]

Что происходит, когда текущее состояние завершается, оно начинает итерацию по списку состояний / предикатов и, как только список предикатов, возвращающих все значения true, переходит в состояние, с которым оно связано.

Определенные события могут происходить во всех состояниях, скажем, команды игрока npc куда-то уходят. Как и любой другой переход состояния, я могу проверить состояние предиката и изменить его, но добавление одного и того же фрагмента кода в каждое состояние выглядит несколько неубедительным. Поэтому мне было интересно, как люди справляются с событиями в государственных машинах?

Answer 1

Просто создайте структуру данных, например:

state1 -> event1, event2
state2 -> event1
state3 -> event2, event3

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

[state1, condition1] -> state2
[state1, condition2] -> state3
...

(условие - это ваш набор предикатов).Вы также должны каким-то образом убедиться, что переход уникален, то есть что условие1 и условие2 не могут быть выполнены одновременно.Или возьмите первый, который соответствует действительности.

Answer 2

Попробуйте использовать шаблон под названием «State» - http://en.wikipedia.org/wiki/State_pattern

Определите абстрактный суперкласс (например, класс AbsatractState, поместите туда код методов, общих для всех состояний), и все классы, представляющие реальные состояния, должны быть разделены на подклассы из него.

Answer 3

Использовать иерархический конечный автомат (HSM).HSM точно разработаны для разделения общего поведения на суперсостояния и обеспечения возможности его повторного использования для всех подсостояний.Чтобы узнать больше о HSM, вы можете начать со статьи в Википедии "UML State Machine" на http://en.wikipedia.org/wiki/UML_state_machine.

Answer 4

Если у вас есть конкретное действие, которое можно предпринять из всех возможных состояний, поступайте так же, как в математике: делайте это!

т.е.: 4 * 10 + 5 * 10 + 6 * 10 + 4 * 20 + 5 * 20 + 6 * 20 = (4 + 5 + 6) * (10 + 20)

То есть: ваш (забвение) NPC может спать, или на работе, или есть. Во всех трех случаях он должен реагировать на некоторые события (с ним можно поговорить, быть атакованным, ...). Постройте два FSM: Ежедневная активность = [спать, работать, есть]. Состояние реакции: {нетронутый, разговаривал, атакован, ...}. Затем переслать события только на второй FSM

И вы можете продолжать заниматься факторингом FSM, пока вы учитываете независимые вещи. Например, настроение NPC (счастливый, нейтральный, злой, ...) не зависит от его повседневной активности и состояния реакции. Я имею в виду «независимый» в том смысле, что «NPC может быть на работе, разговаривать и злиться, и нет никакого противоречия». Конечно, ФСМ влияют друг на друга, атакуемые NPC, как правило, злятся.

Таким образом, вы можете добавить третий FSM для состояния настроения вместо того, чтобы включать его в каждый узел