Архитектура конечных автоматов в Unity для организации поведений юнитов

[Brightori]

на самом деле поведение добычи дерева использует внутри себя поведение ходьбы.

Один вопрос — зачем? Поведение перемещения это отдельный функционал, рубка леса отдельный функционал, зачем тут

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

Как мне видится — правильнее в поведении рубки, определять что мы закончили рубить по разным причинам, и запускать следующее поведение.

[SanQri]

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

Поведение перемещения это отдельный функционал, рубка леса отдельный функционал

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

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

[plus]

Вы изобрели state (GOF). Или я ошибаюсь?

[neochief]

State — это конечный автомат на объектах. Автомат может быть реализован и не на объектах.

[SanQri]

Вы правы. Только шаблон состояние модифицирован еще и компоновщиком.

[LeVoleur]

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