Абстрагирование состояний анимации Entity System

Недавно я начал проектировать игровой движок с использованием парадигмы Entity System, то есть иметь сущности в виде совокупности компонентов и систем, которые реализуют настоящую игру. В то время как у меня были трудности в различных аспектах, меня больше всего беспокоит абстракция / модульность различных Компонентов / Систем. В частности, скажем, у my Playerесть несколько состояний анимации, например. Walking, Sleeping, Jumping, И один тип Opponentобъекта имеет несколько (не обязательно одни и те же) состояний , а также, например. Walkingи Hidingт. д.

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

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

Вот что я делаю в своем текущем личном проекте:

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

Вне системы анимации вы можете использовать строки, чтобы сделать работу с системой удобной и простой для сценариев и кода. Внутри системы вы строите отображение между этой строкой и данными анимации , это можно сделать с помощью хранилища значений ключей, такого как hashmap (чтобы вообще избежать перечисления, делая хранилище данных анимации) или с помощью строки в перечисление ищите, если вам нравится работать таким образом. Это все дело вкуса в этот момент. Я предпочитаю ключ-значение, поскольку он может полностью управляться данными из файлов XML или INI.

Для обработки различных типов вы можете на системном уровне разрешить создание наборов отображения анимаций, чтобы набор для "minion" и "run" для "minion" отличался от набора для "run" и "female player" тип.

В итоге: система анимации является общей, и у вас есть только одна система; внешний мир нуждается в дружественном интерфейсе; внутренний мир должен отобразить общие состояния на типы объектов.

И мой список вещей, которые я хочу сделать, но пока не вписывается в мой дизайн:

TODO : отображение скорости движения на тип анимации автоматически, поэтому вместо того, чтобы основная программа знала «ходьба» и «бег», система анимации может преобразовать «движение на скорости x» в соответствующую анимацию.

TODO : прозрачное разделение анимаций, таких как отслеживание головы и туловища.

TODO : анимация реакции (например, удар по лицу), обрабатываемая системой, а не основной программой.