Buonsalve! Questo post tratterà brevemente alcuni argomenti relativi al framework degli NPC di Hytale, al suo stato attuale, al suo aspetto e a dove vogliamo arrivare. Alcuni contenuti potrebbero essere un po' più tecnici, quindi sentitevi liberi di saltare o dare solo un'occhiata alle parti che non vi interessano. Ci sono anche molti argomenti da trattare quando si parla di sistemi relativi agli NPC, quindi non aspettatevi che questo post sia esaustivo!
A CHE PUNTO SIAMO
Allo stato attuale, il framework degli NPC supporta un'ampia varietà di comportamenti su più sistemi, tutti configurabili utilizzando risorse dati. Non è necessario conoscere alcun linguaggio di programmazione per poterli impostare: anche i nostri NPC più complessi sono quasi interamente basati sui dati.
Otteniamo questo risultato attraverso una serie di sistemi diversi relativi al comportamento, ma i due che tratteremo in questo post sono i “Ruoli” (il cuore dei nostri NPC) e il “Combat Action Evaluator” (Valutatore delle azioni di combattimento).
DOCUMENTAZIONE E TUTORIAL
Se desideri saperne di più sugli NPC, i nostri amici di hytalemodding hanno già pubblicato un'ampia documentazione e noi abbiamo fornito sia l'NPC generato che un tutorial scritto.
Insieme a questo tutorial abbiamo realizzato una serie di 6 video, in cui trattiamo alcune parti in modo più approfondito; per un'esperienza ottimale, utilizza entrambi:
RUOLI
Ogni NPC ha un ruolo. Questo è l'espressione del loro comportamento generale e di come reagiranno ai diversi stimoli nel mondo. Cambiare l'intero set di comportamenti di un NPC è semplice come cambiare il suo ruolo, e forniamo una serie di modelli con valori personalizzabili che possono essere applicati per rendere la creazione di nuovi NPC rapida ed efficiente.
Oltre al comportamento stesso, il ruolo determina anche aspetti quali il modo in cui un NPC si muove, gli oggetti che trasporta, il suo aspetto e così via.
Dal punto di vista tecnico, questo comportamento è rappresentato da un concetto che chiamiamo “elenchi di istruzioni”. Non è molto diverso dagli alberi decisionali o dagli alberi comportamentali, ma con alcune semplificazioni semantiche. Ogni istruzione è composta da un “sensore” - un elemento che interroga lo stato del gioco per decidere se questa istruzione può essere eseguita - e dalle azioni o dai movimenti che l'NPC dovrebbe compiere se questa istruzione viene selezionata. In alternativa, le azioni e i movimenti possono essere sostituiti da un elenco di istruzioni nidificato, dando origine a comportamenti più complessi da costruire.
Se avete familiarità con gli alberi comportamentali, potreste chiedervi dove risiedano le differenze effettive: i sensori sono in qualche modo analoghi ai decoratori e si tratta comunque di una struttura ad albero. La chiave sta nella semantica che utilizziamo per attraversare i nostri elenchi di istruzioni. Mentre gli alberi comportamentali possono seguire semantiche diverse a seconda del tipo di nodo, noi seguiamo sempre la semantica del nodo selettore di fallback. Ogni istruzione viene valutata in ordine e, se corrispondente, eseguita. A meno che nell'istruzione non siano inclusi flag specifici, non valuteremo ulteriori istruzioni nell'elenco. Ciò garantisce che il flusso logico all'interno dell'NPC sia facile da seguire, indipendentemente dalle dimensioni o dalla profondità degli alberi.
Mentre tutti i singoli tipi di elementi (sensori, azioni, movimenti, ecc.) sono scritti in Java, gli elenchi di istruzioni sono costruiti interamente in JSON. In questa fase abbiamo più di 150 tipi di elementi diversi che possono essere combinati per costruire comportamenti e un framework che rende facile per i modder aggiungerne altri con Java. Non tutti sono in uno stato finito, ma stiamo lavorando attivamente per iterarli e aggiungerne il più possibile!
Fondamentalmente, abbiamo progettato il nostro framework degli NPC in modo che fosse interagibile su diversi livelli. Che tu sia completamente nuovo al modding e alla progettazione di NPC o un veterano in grado di creare comportamenti complessi, vogliamo assicurarci che ci siano modi per consentire a tutti di dare vita alle proprie creazioni.
Ecco un esempio di come modificare il ruolo delle pecore per passare da un comportamento da bestiame abilitato da Template_Animal_Neutral a uno aggressivo con l'aiuto di Template_Predator.
E passa dall'essere docile ad aggressivo.
Con alcuni modelli di base che abbiamo creato, puoi anche assegnargli un'arma casuale ed ecco a te la mod "Die Hard Sheep".
VALUTATORE DELLE AZIONI DI COMBATTIMENTO (CAE)
Sebbene gli elenchi di istruzioni offrano già una grande flessibilità ai designer nella configurazione dei propri NPC e nell'implementazione dei comportamenti di combattimento, creare un personaggio che non si limiti a pochi attacchi di base e che debba prendere decisioni rapide su quando utilizzare determinati attacchi diventa rapidamente complicato.
Il valutatore delle azioni di combattimento esiste proprio per rispondere a queste esigenze, offrendo un framework complementare al comportamento centrale di un NPC in grado di prendere decisioni intelligenti momento per momento sul suo stato, sullo stato del mondo che lo circonda e sui suoi nemici o alleati. A ogni possibile attacco (o altra azione di combattimento) viene assegnata una serie di condizioni che designano il momento migliore per utilizzarlo: quando i punti salute sono bassi, quando il nemico è vicino, quando un giocatore sta cercando di avvicinarsi di soppiatto alle spalle. Queste condizioni vengono quindi valutate e ogni azione viene ponderata rispetto alle altre per determinare la linea di condotta che l'NPC vuole adottare.
Prendere decisioni in questo modo introduce un certo grado di “imprevedibilità” nell'NPC e porta a combattimenti più interessanti con configurazioni meno verbose. Lo svantaggio è che la curva di apprendimento è più ripida e gli NPC potrebbero non agire sempre come ci si aspetta! Inoltre, le prestazioni non sono ottimali, ma speriamo di migliorare questo aspetto con ulteriori iterazioni.
Ad esempio, lo Scheletro Pretoriano può decidere di utilizzare diverse abilità con un certo grado di intelligenza: bloccare, evocare quando la salute è bassa e caricare, oltre agli attacchi di base.
Di seguito è riportato uno snippet che mostra parte della configurazione per la condizione dell'abilità di evocazione:
E questo è un video per mostrare queste decisioni:
IL CONFRONTO CON LA REALTÀ
Sembra tutto piuttosto avanzato, vero? Forse potresti persino credere che sia pronto per essere distribuito?
Beh... no. Ci sono ancora molti aspetti da ritoccare, funzionalità mancanti e sezioni che necessitano di notevoli miglioramenti. Proprio come abbiamo parlato di ciò che i sistemi sono in grado di fare, è importante parlare anche di alcune delle principali aree di sviluppo in cui non siamo ancora arrivati.
Da un grande potere derivano... grandi esigenze in termini di strumenti. In questo caso siamo molto lontani dall'obiettivo. Ci sono progetti per l'editing visivo e il debug, ma al momento la maggior parte della configurazione degli NPC viene effettuata direttamente nei file JSON utilizzando editor di testo. È fattibile, ma laborioso, e sebbene forniamo una serie di strumenti per il debug degli NPC quando non funzionano come previsto, nessuno di essi è intuitivo e la maggior parte richiede la lettura di pagine e pagine di file di log dettagliati.
Abbiamo menzionato la curva di apprendimento associata al valutatore delle azioni di combattimento, ma questo vale praticamente ovunque quando si tratta di lavorare con gli NPC. Immaginiamo un approccio più facile e fluido alla modifica degli NPC, ma in questa fase possiamo solo offrire pochi modelli come esempi, insieme alla documentazione sugli elementi disponibili e a semplici tutorial.
Ci sono anche molte caratteristiche importanti che mancano. Gli NPC non si posizionano molto bene in combattimento: non usano tecniche di schivata o di raggruppamento adeguate. Mentre gli NPC volanti possono atterrare e spiccare il volo, quelli che nuotano non possono uscire dall'acqua e viceversa. L'elenco delle caratteristiche che dobbiamo ancora aggiungere per poter realizzare il gioco che abbiamo in mente è infinito.
Naturalmente, le potenziali problematiche relative alle prestazioni sono numerose. Siamo in grado di supportare un numero relativamente elevato di NPC, ma c'è ancora molto lavoro da fare per renderli più performanti, in particolare per quanto riguarda il pathfinding (ricerca del percorso migliore). Cerchiamo di tenere il pathfinder disattivato il più possibile, altrimenti le prestazioni rischiano di crollare!
E poi ci sono tutti i "debiti tecnici" che devono essere risolti, dagli NPC che non sono in grado di rompere deliberatamente i blocchi al di fuori delle esplosioni basate sui proiettili a causa di alcuni vincoli del sistema non NPC che devono essere rivisti (però possono posizionarli!), alla fisica degli NPC che necessita di una completa rielaborazione per unificarla correttamente con i sistemi dei giocatori. C'è ancora molta strada da fare per mettere tutto in ordine, e non abbiamo nemmeno parlato dello spawn!
BUG, BUG OVUNQUE!
Molti membri della community hanno segnalato la presenza di numerosi bug nel filmato di gameplay pubblicato. Considerando il ritmo attuale dello sviluppo, gran parte di quel filmato è già obsoleto e i bug più critici sono già stati corretti! Tuttavia, vorrei dedicare un momento per parlare più approfonditamente del pathfinding, delle sue sfide e di cosa potrebbe significare per il rilascio.
Il pathfinding è un argomento ampio e complesso, tanto che molti giochi tradizionali hanno difficoltà ad affrontarlo. Quando si aggiunge un mondo procedurale completamente modificabile basato su blocchi, la questione diventa ancora più complessa, poiché non è più possibile affidarsi a molti dei trucchi utilizzati dai giochi per ottimizzare le prestazioni su terreni conosciuti.
Ciò significa che attualmente il nostro pathfinding è lento. Non così lento da causare problemi di prestazioni evidenti, ma abbastanza lento da non permettere a tutti gli NPC di utilizzarlo in ogni momento e da imporre severe restrizioni alle sue attuali capacità. Questo è il motivo per cui, ad esempio, i raptor delle caverne non saltano oltre i burroni per inseguire il giocatore. Non possiamo pre-popolare il mondo con “punti di salto” perché il mondo potrebbe cambiare in qualsiasi momento e ogni blocco di distanza aggiuntiva che un NPC può saltare sopra un burrone è un gran costo aggiuntivo per ogni ricerca.
Non prevediamo che questo cambi in tempo per il rilascio dell'accesso anticipato, ma ci impegniamo a migliorare il nostro pathfinding nel suo complesso e abbiamo già iniziato a lavorare allo sviluppo di un nuovo metodo che potrebbe risolvere la maggior parte di questi problemi, se si dimostrasse fattibile.
QUINDI COSA CI ASPETTA?
Gli strumenti sono in cima alla nostra lista di priorità. Se vogliamo supportare adeguatamente i modder, dobbiamo fornire loro gli strumenti adeguati per rendere divertente la creazione di NPC! All'inizio non sarà inclusa una suite completa di strumenti di debug, ma faremo del nostro meglio.
Dobbiamo anche affrontare i problemi relativi al pathfinding e al movimento, occupandoci al contempo del debito tecnico per garantire che non si creino colli di bottiglia nelle prestazioni quando i giocatori si trovano ad affrontare più NPC in ambienti complessi. C'è molto che possiamo migliorare in questo ambito per garantire che il combattimento sia divertente, anche in questa fase iniziale.
L'aggiunta di ulteriori modelli contribuirà anche a ravvivare un po' di più il mondo, con comportamenti personalizzati che daranno vita alle culture delle numerose specie di Orbis. Questi modelli sono pensati anche come ulteriore fonte di ispirazione ed esempi per i modder che desiderano creare NPC più complessi, oppure possono essere utilizzati direttamente se il comportamento è adatto!
Tutto ciò porta alla possibilità di creare boss che si possano definire tali, incontri che spingeranno tutti i nostri sistemi PvE al limite assoluto. C'è molto lavoro da fare per raggiungere questo obiettivo, molto più di quanto elencato qui, ma lo stiamo pianificando passo dopo passo e ci stiamo lavorando. Con un po' più di tempo, riusciremo a far funzionare tutto!
PER PARTIRE: COMANDI DI DEBUG
Questo post è stato originariamente scritto per essere pubblicato prima del rilascio della nostra versione in accesso anticipato. Da allora, abbiamo dedicato molto impegno nel rendere gli NPC più accessibili ai modder. Anche se non disponiamo ancora di un editor visivo o di uno strumento di debug approfondito, abbiamo aggiunto una serie di visualizzazioni diverse per rendere più facile comprendere il funzionamento dei vostri NPC (e abbiamo anche individuato una serie di bug da parte nostra grazie al loro utilizzo!). Alcune di queste funzionalità sono ancora in fase di sviluppo, ma ecco un'anteprima del nostro lavoro in corso e di ciò che sarà disponibile nelle prossime versioni.
Ciascuna di queste visualizzazioni può essere abilitata attivando determinati flag di debug NPC sui singoli NPC. Ciò avviene utilizzando il comando di debug NPC mentre si mantiene l'NPC nella propria visuale. È possibile farlo digitando /npc debug set <flag> nella console di chat all'interno del gioco o aggiungendo i flag come elenco separato da virgole nella proprietà Debug del ruolo NPC stesso. Eseguendo il comando /npc debug presets si ottiene un elenco completo dei flag disponibili e dei set di flag preimpostati che possono essere utilizzati, ma i flag di visualizzazione più utili sono descritti in dettaglio di seguito.
/npc debug set VisAiming
È possibile utilizzarlo per determinare a cosa sparano effettivamente gli NPC. Funziona per gli NPC che hanno istruzioni di mira nella loro logica.
/npc debug set VisMarkedTargets
Visualizza tutti i bersagli attualmente contrassegnati dall'NPC. Nella maggior parte dei nostri modelli standard, l'NPC ha un unico LockedTarget, che di solito è l'entità con cui è attivamente impegnato in combattimento. Utile per capire come e quando l'NPC cambia obiettivo, nonché qual è esattamente il suo obiettivo attuale in mezzo alla folla.
/npc debug set VisSensorRanges
Visualizza tutte le zone di rilevamento dei sensori degli NPC attualmente selezionati sotto forma di anelli e settori di visualizzazione, oltre a indicare quali entità nel campo di rilevamento vengono rilevate da ciascuno di questi sensori. Considerando l'uso che generalmente facciamo di questi sensori nei nostri NPC, ciò fornisce una rapida panoramica visiva delle “capacità sensoriali” di un NPC. Da notare che, sebbene siano visualizzati come settori e anelli, tecnicamente si tratta di sfere e coni che possono essere limitati da condizioni di altezza.
La prima schermata mostra l'orso che dorme e ha solo un sensore attivo. Nella seconda schermata l'orso ha udito, vista e raggio di rilevamento assoluto. Anche se le pecore vengono rilevate dal raggio visivo (hanno dei segni di mira), si trovano al di fuori del cono visivo. Le pecorelle sono ancora al sicuro!
/npc debug set VisLeashPosition
Visualizza la posizione attuale del "guinzaglio" dell'NPC ossia dove è ancorata la sua posizione nel mondo.
/npc debug set VisFlock
Visualizza il gruppo associato a un NPC. Questa visualizzazione include l'indicazione del capo del gruppo e di tutti gli NPC che attualmente ne fanno parte.
Commenti consigliati
Crea un account o accedi per commentare