Estrarre gli stati di animazione del sistema di entità


8

Di recente ho iniziato a progettare un Game Engine usando il paradigma Entity System, ovvero avere entità come aggregazione di componenti e sistemi che implementano il gioco reale. Mentre ho avuto difficoltà in vari aspetti, ciò che mi preoccupa di più è l'astrazione / modularità dei vari componenti / sistemi. In particolare, supponiamo che il mio Playerabbia diversi stati di animazione, ad es. Walking, Sleeping, Jumping, E un tipo di Opponententità ha diverse (non necessariamente uguali) Uniti così, ad esempio. Walking, HidingEcc

Come devo progettare il motore, in modo che gestisca i vari stati (animazione) di ciascun tipo di entità? Dovrebbero esistere sistemi di animazione diversi per ciascun tipo di entità? Dovrei usare flag che segnalano il sistema di animazione per rendere l'entità corretta? Inoltre, posso evitare di usare enum "hard-coded" per le varie pose? Vedo che un sistema di scripting potrebbe probabilmente aiutare, ma sono quasi sicuro che esista una soluzione più semplice.

Risposte:


4

No a sistemi diversi per ogni tipo, ciò sta tagliando troppo bene la divisione delle responsabilità.

Questo è quello che sto facendo nel mio attuale progetto personale:

Esistono molti modi per gestire lo stato, ma probabilmente hai bisogno di uno che abbia un senso per gli umani, o almeno un ponte tra umano e codice. Devi pensare al sistema di animazione come a un grande frullatore anziché a uno stato discreto, ad esempio vai da inattivo a camminare lentamente aggiungendo il 50% di camminata al sistema e successivamente aggiungi il 100% di corsa.

All'esterno del sistema di animazione è possibile utilizzare le stringhe per rendere piacevole e facile la scrittura di script e codici con il sistema. All'interno del sistema in cui si crea una mappatura tra quella stringa e i dati di animazione , questo può essere fatto con un archivio di valori-chiave come una hashmap (per evitare del tutto gli enumerando i dati di animazione come archivio) o con una stringa-en-enum cerca se ti piace lavorare in quel modo. È tutta una questione di gusti a quel punto. Preferisco il valore-chiave poiché può essere totalmente guidato dai dati da file XML o INI.

Per gestire tipi diversi puoi, a livello di sistema, consentire la creazione di set di mapping delle animazioni in modo che set per "minion" e "run" per "minion" sia diverso dal set per "run" e "female player" genere.

In sintesi: il sistema di animazione è generico e hai un solo sistema; il mondo esterno ha bisogno di un'interfaccia amichevole; il mondo interno deve mappare stati generici a tipi di entità.

E la mia lista di cose che voglio fare ma che non rientrano ancora nel mio design:

TODO : mappatura automatica della velocità di movimento al tipo di animazione, quindi invece di avere il programma principale a conoscenza di "walk" anziché "run" il sistema di animazione può convertire "move at x speed" nell'animazione corretta.

TODO : dividere le animazioni come il monitoraggio della testa e del busto in modo trasparente.

TODO : animazioni di reazione (come farsi dare un pugno in faccia) gestite dal sistema e non dal programma principale.


Quindi, suggerisci di usarne un paio ifall'interno del sistema di animazione; In precedenza ero scettico sull'uso dei dizionari di stringhe (in C ++), per quanto riguarda la memoria. Avendo letto oggi sugli hashtabili però, trovo la tua risposta abbastanza semplice. Per quanto riguarda la parte "frullatore": "aggiungere il 50% di camminata" significa sostituire alcuni fotogrammi con quelli di "camminata" al 50% delle volte?
petermer,

Blending è un termine piuttosto comune nell'animazione, significa letteralmente che si fondono due (o più) animazioni di base per ottenere l'output finale. Nell'esempio del 50% sto assumendo una miscela del 50% di "Idle" e del 50% di "Walk" che produrrebbe una passeggiata a metà velocità. In questo modo puoi variare continuamente il movimento da "Idle" a "Walk" e poi "Run". La fusione in seguito ti consentirà di fare cose come far girare la parte inferiore del busto mentre la parte superiore del busto spara una pistola o saluta qualcuno, ecc ... Se il tuo motore di animazione non supporta la fusione, usa questo come un modo per pensarci e non una regola.
Patrick Hughes,

1
Cordiali saluti: preoccuparsi della memoria per le stringhe nel programma in questa fase è tempo perso, che si chiama "ottimizzazione prematura" e generalmente una cattiva idea. Successivamente, se le stringhe stanno davvero causando un carico enorme, possono essere trasformate in numeri CRC brevi per ridurli notevolmente, a spese della facilità di debug e di un ulteriore passaggio al processo di creazione.
Patrick Hughes,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.