Здравствуйте, Ziaw, Вы писали:

G>>Такой подход удобен тем, что можно с легкостью расширять машину состояний, а расширять её придется неизбежно непредусмотренными заранее состояниями, или чтобы ввести плавность переходов между ними, придется вводить промежуточные состояния типа "доставать оружие", "убирать оружие", "радоваться победе" и много-много других. "Комбинированный" же подход, мне кажется, в этом случае может запутать сложностью.

Z>Я не спец в играх, но у меня возникает чувство, что машина состояний начнет давать сбои, когда понадобится радоваться победе убирая оружие на ходу.

Я тоже не занимаюсь играми профессионально. Но как хобби — лет наверное 15. По моему опыту — использование машины состояний — наиболее оптимальное решение по соотношению простота реализации/эффективность. Причем машину состояний как модель первого приближения удобно использовать не только для описания персонажей, но и описания всей "инфраструктуры" игры (состояния "заставка"-"экран помощи"-"пауза"-"загрузка уровня"-"процесс игры"-"демо"), а также других элементов. На реализацию машины (в виде паттерна State) можно навесить механизм событий (оповещение об изменении состояния), и в этом случае машина состояний идеально ложится на архитектуру MVC.

Вообще же, если инициатор топика дойдет в реализации свой идеи до той стадии, когда понадобятся указанные вами, Ziaw, навороты в поведении персонажей, советую курить эту книгу: "Искусственный интеллект в компьютерных играх: как обучить виртуальные персонажи реагировать на внешние воздействия", Алекс Дж. Шампандар (http://www.kodges.ru/2007/10/07/iskusstvennyjj-intellekt-v.html)