EDYCJA: Aby wyjaśnić, jakie dokładnie jest moje pytanie: czy to dobry sposób na obsługę animacji / stanu animacji w silniku gry z myślą o tworzeniu / zarządzaniu treścią? Jakie są wady robienia tego w ten sposób i jaki byłby alternatywny sposób? - Chociaż w mojej odpowiedzi częściowo udzieliłem odpowiedzi w komentarzach, wydaje się, że jest to właściwa droga.
Próbuję obsłużyć animacje w projekcie hobby silnika gier 2D , nie kodując ich na stałe. Twarde kodowanie stanów animacji wydaje mi się powszechnym, ale bardzo dziwnym zjawiskiem.
Trochę tła: pracuję z systemem encji, w którym komponenty są workami danych, a podsystemy działają na nie. Wybrałem system odpytywania do aktualizacji stanów animacji.
Przez stany animacji mam na myśli: „walking_left”, „running_left”, „walking_right”, „strzelanie”, ...
Moim pomysłem na obsługę animacji było zaprojektowanie jej jako modelu opartego na danych . Dane mogą być przechowywane w pliku xml, rdbms, ... I mogą być ładowane na początku gry / poziomu / ... W ten sposób możesz łatwo edytować animacje i przejścia bez konieczności zmiany kodu wszędzie w swoim gra.
Jako przykład stworzyłem wersję XML definicji danych, które miałem na myśli.
Jednym z bardzo ważnych danych byłby po prostu opis animacji . Animacja miałaby unikalny identyfikator (opisową nazwę). Przechowuje identyfikator odwołania do obrazu (z którego korzysta arkusz sprite, ponieważ różne animacje mogą używać różnych arkuszy sprite). Liczba klatek na sekundę, na której uruchomiona zostanie animacja. „Powtórka” określa tutaj, czy animacja powinna być uruchomiona raz czy nieskończenie. Następnie zdefiniowałem listę prostokątów jako ramki.
<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>
Dane animacji byłyby ładowane i przechowywane w puli zasobów animacji, do których odwołują się podmioty gry, które ich używają. Byłby traktowany jako zasób jak obraz, dźwięk, tekstura ...
Drugi fragment danych do zdefiniowania byłby maszyną stanu do obsługi stanów animacji i przejść. Definiuje to każdy stan, w którym może znajdować się jednostka gry, w którym stanie może przejść i co powoduje zmianę tego stanu.
Ta maszyna stanu różni się w zależności od jednostki. Ponieważ ptak może mieć stany „chodzenia” i „latania”, podczas gdy człowiek może mieć stan „chodzenia”. Może być jednak dzielony przez różne byty, ponieważ wielu ludzi prawdopodobnie będzie miało takie same stany (szczególnie, gdy zdefiniujesz kilka pospolitych postaci niezależnych, takich jak potwory itp.). Dodatkowo ork może mieć te same stany co człowiek. Tylko w celu wykazania, że ta definicja stanu może być wspólna, ale tylko przez wybraną grupę podmiotów gry .
<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>
Stany te mogą być obsługiwane przez system odpytywania . Każda gra zaznacza pobiera bieżący stan podmiotu gry i sprawdza wszystkie wyzwalacze. Jeżeli warunek jest spełniony, zmienia stan jednostki na stan „goto”.
Ostatnią częścią, z którą miałem problemy, było powiązanie danych animacji i stanów animacji z bytem . Wydaje mi się, że najbardziej logiczne jest dodanie wskaźnika do danych maszyny stanów, których używa jednostka, i określenie dla każdego stanu w tej maszynie, jakiej animacji używa.
Oto przykład XML, w jaki sposób zdefiniowałbym zachowanie animacji i graficzną reprezentację niektórych typowych bytów w grze, poprzez odniesienie do stanu animacji i identyfikatora danych animacji. Zauważ, że zarówno „kreator”, jak i „ork” mają te same stany animacji, ale inną animację. Również inna animacja może oznaczać inny arkusz sprite, a nawet inną sekwencję animacji (animacja może być dłuższa lub krótsza).
<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>
Podczas tworzenia encji dodawałaby listę stanów z danymi maszyny stanu i odniesienie do danych animacji.
W przyszłości używałbym systemu encji do budowania całych encji poprzez definiowanie komponentów w podobnym formacie xml.
-
To właśnie wymyśliłem po kilku badaniach. Miałem jednak problemy z obejściem tego, więc liczyłem na jakieś opinie. Czy jest tu coś, co nie ma sensu, czy jest lepszy sposób, aby sobie z tym poradzić? Wpadłem na pomysł iteracji w ramkach, ale mam problem z pójściem o krok dalej i to jest moja próba zrobienia tego.