Керовані даними стани анімації


14

EDIT: Щоб уточнити, що конкретно моє питання: чи це хороший спосіб обробляти анімацію / стан анімації в ігровому двигуні з оглядом на створення вмісту / управління вмістом? Які недоліки в цьому зробити і який був би альтернативний спосіб зробити це? - Хоча на мою відповідь частково відповіли в коментарях, оскільки, здається, це саме шлях.

Я намагаюся обробляти анімації в проекті 2-ігрового хобі з двигунами , без жорсткого кодування. Стани анімації жорсткого кодування здаються мені звичайним, але дуже дивним явищем.

Невелика довідка: я працюю із сутнісною системою, де компоненти є пакетами даних і на них підсистеми діють. Я вирішив використовувати систему опитування для оновлення станів анімації.

Під анімаційними станами я маю на увазі: "ходьба_ліва", "біг_ліфт", "ходьба_право", "зйомка", ...

Моя ідея обробляти анімацію полягала в тому, щоб створити її як модель, керовану даними . Дані можуть зберігатися у XML-файлі, rdbms, ... І можуть бути завантажені на початку гри / рівня / ... Таким чином ви можете легко редагувати анімації та переходи, не потребуючи змінити код скрізь у вашому гра.

Як приклад, я зробив набір проектів визначень даних xml .

Одним з дуже важливих даних буде просто опис анімації . Анімація матиме унікальний ідентифікатор (описове ім'я). Він міститиме посилання на зображення (аркуш спрайту, який він використовує, оскільки різні анімації можуть використовувати різні спрайтові листи). Кадри в секунду для запуску анімації. Тут "повтор" визначає, чи мусить анімація працювати один раз чи нескінченно. Потім я визначив список прямокутників як кадри.

<animation id='WIZARD_WALK_LEFT'>
    <image id='WIZARD_WALKING' />
    <fps>50</fps>
    <replay>true</replay>
    <frames>
        <rectangle>
            <x>0</x>
            <y>0</y>
            <width>45</width>
            <height>45</height>
        </rectangle>
        <rectangle>
            <x>45</x>
            <y>0</y>
            <width>45</width>
            <height>45</height>
        </rectangle>
    </frames>
</animation>

Дані анімації завантажуватимуться та зберігатимуться у пулі ресурсів анімації та посилатимуться на ігрові суб'єкти, які її використовують. Це трактується як ресурс, як зображення, звук, текстура, ...

Другим фрагментом даних, який слід визначити, буде машина машини для обробки станів анімації та переходів. Це визначає кожний стан, в якому може бути ігровий суб'єкт, який стан може переходити і що викликає зміни цього стану.

Ця державна машина відрізнялася б від сутності до сутності. Тому що у птаха може бути стан "ходити" і "літати", а у людини буде стан "ходіння". Однак це може бути поділене різними сутностями, оскільки у багатьох людей, ймовірно, будуть однакові стани (особливо, коли ви визначаєте деякі загальні NPC, такі як монстри тощо). Крім того, орк може мати ті ж стани, що і людина. Просто для того, щоб продемонструвати, що це визначення стану може бути спільним, але лише вибраною групою ігрових утворень .

<state id='IDLE'>
  <event trigger='LEFT_DOWN' goto='MOVING_LEFT' />
  <event trigger='RIGHT_DOWN' goto='MOVING_RIGHT' />
</state>
<state id='MOVING_LEFT'>
  <event trigger='LEFT_UP' goto='IDLE' />
  <event trigger='RIGHT_DOWN' goto='MOVING_RIGHT' />
</state>
<state id='MOVING_RIGHT'>
  <event trigger='RIGHT_UP' goto='IDLE' />
  <event trigger='LEFT_DOWN' goto='MOVING_LEFT' />
</state>

Ці стани можуть бути оброблені системою опитування . Кожна гра відмічає поточний стан ігрової сутності та перевіряє всі тригери. Якщо умова виконується, вона змінює стан суб'єкта господарювання на стан "goto".

Остання частина, з якою я зіткнулася, полягала в тому, як прив’язати дані анімації та стани анімації до сутності . Мені здавалося, найбільш логічним підходом є додавання покажчика до даних про стан машини, якими користується сутність, і для кожного стану в цій машині для того, щоб визначити, яку анімацію він використовує.

Ось приклад xml, як я б визначив поведінку анімації та графічне представлення деяких загальних об'єктів у грі, адресуючи стан анімації та ідентифікатор даних анімації. Зауважте, що і "майстер", і "орк" мають однакові стани анімації, але різні анімації. Також інша анімація може означати інший аркуш спрайта або навіть іншу послідовність анімацій (анімація може бути довшою чи коротшою).

<entity name="wizard">
    <state id="IDLE" animation="WIZARD_IDLE" />
    <state id="MOVING_LEFT" animation="WIZARD_WALK_LEFT" />
</entity>

<entity name="orc">
    <state id="IDLE" animation="ORC_IDLE" />
    <state id="MOVING_LEFT" animation="ORC_WALK_LEFT" />
</entity>

Коли сутність створюється, вона додала б список станів з даними про стан машини та посилання на дані анімації.

Надалі я використовую систему сущностей для створення цілих об'єктів, визначаючи компоненти у подібному форматі xml.

-

Це те, що я придумав після деяких досліджень. Однак у мене виникли проблеми з обертанням голови, тому я сподівався на відгуки. Чи є тут щось, що не має сенсу, або є кращий спосіб впоратися з цими речами? Я зрозумів ідею про повторення кадрів, але мені важко зробити крок далі, і це моя спроба зробити це.


1
Я придумав аналогічну ідею для зберігання анімаційних даних, хоча тригери не розглядав. Ось коротка стаття, яку я написав про це, та посилання на проект XNA, який я написав, що споживає XML та обробляє анімаційну сторону речей. У мене є кілька речей, що відрізняються, як концепція наборів і послідовностей, але крім цього, я думаю, ви на шляху.
Джон Макдональд

2
Не те, що ваш дизайн поганий (це не так, це дуже схоже на аналогічну систему, яку я побудував у минулі часи), але що саме тут у вас є питання? Я думаю, що це дійсно могло б стати зрозумілішим.
MrCranky

@ Джон - Спасибі товаришу, я погляну на це пізніше цього вечора. @ MrCranky - Ну, переважно, саме те, що ви сказали. Якщо це будь-які корисні та, можливо, поради / посилання на більш усталені методи. Я тут справді в темряві.
user8363

1
Я хотів би дати цьому підсумок за глибину наданої інформації, але, наголошуючи на MrCranky, я не дуже слідкую за тим, яке питання є. За власною особистою порадою (яка породжується тим, що побудували подібну систему пару тижнів тому), я б сказав, що ви на місці.
Майк Клук

@MikeC Це лише відповідь, яка мені була потрібна. Прошу вибачення за те, що мені не вдалося зрозуміти своє питання. Можливо, якби я не був на ньому, це виглядало б більше як питання :). Факт полягає в тому, що я не зміг знайти багато ресурсів, які займалися анімаційними станами та тими, хто зробив їх жорстким кодуванням, тому створення / зміна вмісту було б кошмаром. Отже, моє запитання: чи правильний такий підхід чи ні? А якщо ви, хлопці, скажете, що це так, то це добре :).
user8363

Відповіді:


4

Анімаційні кліпи найкраще описати у звичайних старих даних, як це було зроблено у вашому першому фрагменті XML. Ви можете зробити це вручну або експортувати до нього з арт-пакету. Так чи інакше, ви, ймовірно, захочете створити конвеєр, який бере його з читаного для людини проміжного формату, як XML, і вкладає його в щось приємне та швидке завантаження.

Наступним кроком є ​​можливість зробити річ. Якщо ви використовуєте якийсь графік сцени, це, ймовірно, означатиме створення Вузла для тварин. Ви повинні мати можливість вказати вузлу анімації, яка анімація в даний час відтворюється, і де на часовій шкалі вона знаходиться. Переконайтесь, що ви зберігаєте інформацію обмеженої скриньки доступною на цьому рівні, щоб ви могли легко вносити її у вашу систему відсіву.

Тепер ви хочете пов’язати анімацію з ігровою сутністю. Я схильний використовувати модель на основі компонентів, тому для мене це означає і компонент AnimState. Це ваш проміжний шар між геймплеєм та рендерінгом. Він відслідковує, в якій анімації грає суб'єкт, ігрові режими (циклічний цикл, один раз, пінг-понг тощо), синхронізацію тощо. Він може пересилати такі об'єкти, як "animover" назад, і оновлює стан анімації, коли це доречно . AnimStates для активних осіб буде оновлюватися один раз за сім галочок, якщо вони відтворюють анімацію.

Компонент animstate, ймовірно, достатньо для простих ігрових предметів (основних фонових реквізитів тощо), але для складніших об'єктів ви хочете використовувати державну машину, щоб керувати нею. Це найкраще виражається в мовах сценаріїв, таких як Lua або Python. У стані може бути кілька функціональних блоків (onEnter, onExit, onUpdate, onEvent), а також часова шкала, яка визначає певні дії та тригери, які мають відбуватися в певний час. Напевно, у вас буде якийсь клас менеджера, який відповідає за оновлення цих станкових машин у міру необхідності, а також за активізацію зворотного виклику тимчасової шкали, коли вони виникають. Ви повинні намагатися зберігати ці речі якнайбільше на основі подій, оскільки кожен запис OnUpdate буде лінійною вартістю з кількістю сутностей. Ви також хочете мати можливість вказувати теги ("атакувати", "простоювати", 'ignoreininput' тощо), які пов'язані як з цілими станами, так і з певними часовими регіонами штатів. Ви, ймовірно, також захочете обробляти події високого рівня, які застосовуються до всього графіку стану, а не лише до певного стану.

Персонажі "Sentient", ймовірно, матимуть і якийсь AI. Я схильний робити певний компонент «локомотора», який обробляє ходьбу. Він взаємодіє зі статеграфом, використовуючи систему сигналів і подій та запитів на теги стану, і йому можна сказати "піти до точки" або "бігти в певному напрямку з певною швидкістю". Компоненти AI вищого рівня (наприклад, дерево поведінки чи будь-яке інше) можуть використовувати цей інтерфейс, не турбуючись про деталі.


1

Найкраща анімаційна система, керована даними, яку я бачив до цих пір, - це дерево Blend . Дійсно, це чортово добре, і тут можна зробити все, що просиш. За інформацією AIGameDev.com, це тепер стандарт фактичної галузі, і я вважаю, що вони праві.

На жаль, я не знайшов хорошого ресурсу зі швидким поглинанням, але ви можете спробувати те чи інше , щоб отримати огляд. На AIGameDev.com також є стаття про оплату, не знаю, чи варто отримувати преміальний рахунок.


Це дуже хороший ресурс, дякую. Я шукаю подібну інформацію.
user8363

1
Змішування анімації неможливо з дискретними
спрайтами
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.