Ciao a tutti! Questo post coprirà brevemente alcuni argomenti relativi al framework degli NPC di Hytale: il suo stato attuale, come appare e dove vogliamo portarlo. Alcuni contenuti potrebbero essere un po' più tecnici, quindi sentitevi liberi di saltare o scorrere le parti che non vi interessano. C'è anche molto da dire quando si parla di sistemi legati agli NPC, quindi non aspettatevi che questo singolo post sia esaustivo!

A che punto siamo

Allo stato attuale, il framework NPC supporta un'ampia varietà di comportamenti attraverso molteplici sistemi, tutti configurabili utilizzando asset "data-driven" (basati sui dati). Non è necessario conoscere alcun linguaggio di programmazione per poterli impostare - anche i nostri NPC più complessi sono quasi interamente guidati dai dati.

Raggiungiamo questo obiettivo attraverso una serie di sistemi legati al comportamento, ma i due che tratteremo in questo post sono i 'Ruoli' (il cuore dei nostri NPC) e il 'Valutatore delle Azioni di Combattimento' (Combat Action Evaluator).

Documentazione e Tutorial

Se volete saperne di più sugli NPC, i nostri amici di hytalemodding hanno già molta ottima documentazione e abbiamo fornito quella generata per gli NPC così come un tutorial scritto.

Insieme a questo tutorial abbiamo realizzato una serie video in 6 parti, dove copriamo alcune parti in dettaglio extra; per la migliore esperienza usateli entrambi:

Ruoli (Roles)

Ogni NPC ha un ruolo. Questa è 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 cambiarne il ruolo, e forniamo una serie di template con valori personalizzabili che possono essere applicati per rendere la creazione di nuovi NPC rapida ed efficiente.

Oltre al comportamento stesso, il Ruolo detta anche aspetti come il modo in cui un NPC si muoverà, quali oggetti trasporta, il suo aspetto, e così via.

Dal lato tecnico, questo comportamento è rappresentato da un concetto che chiamiamo 'liste di istruzioni'. Questo non è troppo lontano dagli alberi decisionali o dai behavior trees, ma con alcune semantiche semplificate. Ogni istruzione è composta da un 'sensore' - un elemento che interroga lo stato del gioco per decidere se questa istruzione può essere eseguita - così come le azioni o i movimenti che l'NPC dovrebbe intraprendere se questa istruzione viene selezionata. Alternativamente, le azioni e i movimenti possono essere sostituiti da una lista di istruzioni nidificata, dando origine a comportamenti costruibili in modo più intricato.

Se avete familiarità con i behavior trees, potreste chiedervi dove risiedano le differenze reali - i sensori sono in qualche modo analoghi ai 'decorators' ed è ancora una struttura simile a un albero. La chiave sta nella semantica che usiamo per attraversare le nostre liste di istruzioni. Dove i behavior trees possono seguire semantiche diverse a seconda del tipo di nodo, noi seguiamo sempre la semantica del nodo selettore di ripiego (fallback selector node). Ogni istruzione viene valutata in ordine e - se corrispondente - eseguita. A meno che non siano inclusi flag specifici nell'istruzione, non valuteremo ulteriori istruzioni nella lista. Questo assicura che il flusso logico all'interno dell'NPC sia facile da seguire, non importa quanto grandi o profondi diventino gli alberi.

Mentre tutti i singoli tipi di elementi (sensori, azioni, movimenti, ecc.) sono scritti in Java, le liste di istruzioni sono costruite interamente in JSON. A questo stadio abbiamo più di 150 diversi tipi di elementi che possono essere combinati per costruire comportamenti e un framework in atto per rendere facile ai modder aggiungerne altri con Java. Non tutti sono in uno stato finito, ma stiamo lavorando attivamente per iterare su di essi e aggiungerne il maggior numero possibile!

Al suo nucleo, abbiamo progettato il nostro framework NPC per essere interagito su diversi livelli. Che siate completamente nuovi al modding e al design degli NPC o veterani in grado di creare comportamenti complessi, vogliamo assicurarci che ci siano modi per tutti di poter dare vita alle proprie creazioni.

Ecco un esempio di modifica del ruolo della Pecora per passare da un comportamento di Bestiame abilitato da Template_Animal_Neutral a essere aggressiva con l'aiuto di Template_Predator.

E passa dall'essere affezionata a te all'attaccarti.

Con alcuni template di base che abbiamo creato, potete anche darle un'Arma casuale e siete pronti per la mod "Die Hard Sheep".

Il Valutatore delle Azioni di Combattimento

Sebbene le liste di istruzioni offrano già ai designer una grande flessibilità per configurare i loro NPC e implementare comportamenti di combattimento, creare un personaggio che faccia più di pochi attacchi base e debba prendere una qualche decisione su quando usare certi attacchi diventa rapidamente macchinoso.

Il valutatore delle azioni di combattimento esiste per rispondere a queste esigenze, offrendo un framework compagno al comportamento centrale di un NPC che può prendere decisioni intelligenti momento per momento sul suo stato, lo stato del mondo intorno a lui, e i suoi nemici o alleati. A ogni possibile attacco (o altra azione di combattimento) è assegnato un set di condizioni che designano il momento migliore per usarlo - quando gli HP sono bassi; quando il nemico è vicino; quando un giocatore sta cercando di aggirarlo alle spalle. Queste condizioni vengono poi valutate e ogni azione viene pesata contro le altre per determinare il corso d'azione che l'NPC vuole intraprendere.

Prendere decisioni in questo modo introduce un livello di 'sfumatura' (fuzziness) all'NPC e porta a incontri di combattimento più interessanti con configurazioni meno prolisse. Il lato negativo è che c'è una curva di apprendimento più ripida e gli NPC potrebbero non agire sempre nel modo in cui vi aspettate! Non è nemmeno altrettanto performante, ma è qualcosa che speriamo di migliorare con ulteriori iterazioni.

Ad esempio, lo Scheletro Pretoriano può decidere tra usare diverse abilità con un certo grado di intelligenza: parare, evocare quando ha poca salute, e caricare, insieme agli attacchi base.

Qui sotto c'è uno snippet che mostra parte della configurazione per la condizione dell'abilità di evocazione:

Ed ecco un video esempio di quelle decisioni:

Il bagno di realtà

Tutto questo sembra piuttosto avanzato, vero? Forse potreste persino credere che sia pronto per il rilascio?

Beh… no. Ci sono ancora molti spigoli vivi, funzionalità mancanti e aree che necessitano di vasti miglioramenti. Proprio come abbiamo parlato di ciò che i sistemi possono fare, è importante parlare di alcune delle aree principali in cui non siamo ancora arrivati.

Da un grande potere derivano… grandi necessità di strumenti (tooling). Siamo molto lontani dall'obiettivo qui. Ci sono piani per l'editing visivo e il debugging, ma al momento la maggior parte della configurazione degli NPC viene fatta direttamente nei file JSON usando editor di testo. È fattibile, ma doloroso, e sebbene forniamo una varietà di strade per il debug degli NPC quando non funzionano come previsto, nessuna di esse è intuitiva e la maggior parte richiede la lettura di pagine su pagine di file di log dettagliati.

Abbiamo menzionato la curva di apprendimento associata al valutatore delle azioni di combattimento, ma questo si applica praticamente ovunque quando si tratta di lavorare con gli NPC. Immaginiamo un onboarding più facile e fluido nel modding degli NPC, ma a questo stadio possiamo solo offrire un numero limitato di template come esempi insieme alla documentazione sugli elementi disponibili e semplici tutorial.

Ci sono anche molte importanti funzionalità mancanti. Gli NPC non si posizionano molto bene in combattimento; non usano correttamente l'evitamento o il flocking (movimento di gruppo); mentre gli NPC volanti possono atterrare e decollare, gli NPC nuotatori non possono lasciare l'acqua e viceversa. Non c'è fine alla lista di funzionalità che dobbiamo ancora aggiungere per poter consegnare il gioco che immaginiamo.

Naturalmente, il potenziale per problemi di performance abbonda. Possiamo supportare un numero relativamente grande di NPC ma c'è molto lavoro da fare per renderli più performanti, particolarmente quando si tratta di pathfinding. Teniamo il pathfinder spento il più possibile altrimenti le performance probabilmente crollerebbero!

E poi c'è tutto il debito tecnico che deve essere risolto, dagli NPC che non sono in grado di rompere deliberatamente blocchi al di fuori delle esplosioni basate su proiettili a causa di certi vincoli di sistema non-NPC che devono essere rivisti (possono piazzarli però!), alla fisica degli NPC che necessita di una rielaborazione completa per unificarla propriamente con i sistemi del giocatore. C'è una lunga strada davanti per mettere le cose nella forma giusta - e non abbiamo nemmeno parlato dello spawning!

Bug, bug ovunque

Molti membri della community hanno sottolineato la pletora di bug emersi nei filmati di gameplay rilasciati. Con il nostro attuale ritmo di sviluppo, gran parte di quei filmati è già obsoleta e i più critici di quei bug sono già stati risolti! Tuttavia, voglio specificamente prendere un momento per parlare un po' di più del pathfinding, le sue sfide, e cosa questo probabilmente significherà per il rilascio.

Il pathfinding è un argomento vasto e complesso - abbastanza complesso che molti giochi regolari faticano con esso. Quando aggiungi al mix un mondo procedurale basato su blocchi completamente modificabile, questo diventa ancora più complesso poiché non possiamo più affidarci a molti dei trucchi che i giochi usano per ottimizzare le performance intorno a terreni conosciuti.

Questo significa che il nostro pathfinding è attualmente lento. Non così lento da causare problemi di performance evidenti, ma abbastanza lento che non permettiamo attualmente a tutti gli NPC di usarlo in ogni momento e poniamo severe restrizioni sulle sue capacità attuali. Questo è il motivo per cui - per esempio - i raptor delle caverne non saltano attraverso i vuoti 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 addizionale che un NPC può saltare sopra un vuoto è un grande costo addizionale per ogni ricerca.

Non ci aspettiamo che questo cambi in tempo per il rilascio in accesso anticipato, ma siamo impegnati a migliorare il nostro pathfinding nel complesso e abbiamo già iniziato a lavorare sullo sviluppo di un nuovo metodo che potrebbe risolvere la maggior parte di questi problemi se si dimostrasse valido.

E adesso? (So what's next?)

Gli strumenti (Tooling) sono in cima alla nostra lista di priorità. Se vogliamo supportare i modder propriamente, dobbiamo dare loro gli strumenti di cui hanno bisogno per rendere divertente la creazione di NPC! Questo non includerà una suite completa di strumenti di debug all'inizio, ma metteremo insieme quello che possiamo.

Dobbiamo anche affrontare i problemi con pathfinding e movimento mentre gestiamo il debito tecnico per assicurarci di non creare colli di bottiglia nelle prestazioni quando i giocatori affrontano multipli NPC in ambienti complessi. C'è molto che possiamo migliorare qui per assicurarci che il combattimento sia piacevole, anche a questo stadio iniziale.

Aggiungere più template aiuterà anche a ravvivare un po' di più il mondo, con comportamenti su misura che introducono vita nelle culture delle molte specie diverse di Orbis. Questi sono anche intesi per servire come ulteriore ispirazione ed esempi per i modder che cercano di creare i propri NPC più complessi - o possono essere usati direttamente se il comportamento si adatta!

Tutto questo porta verso il potenziale per creare veri boss - incontri che spingeranno tutti i nostri sistemi PvE ai loro limiti assoluti. C'è molto lavoro richiesto per raggiungere questo punto - molto più di quanto elencato qui - ma lo stiamo stendendo passo dopo passo e lavorando attraverso di esso. Con un po' più di tempo, faremo funzionare tutto!

Un vantaggio: comandi di debug

Questo post è stato originariamente scritto per essere pubblicato prima del nostro rilascio in accesso anticipato. Nel tempo trascorso da allora, abbiamo messo un bel po' di impegno nel cercare di rendere gli NPC più accessibili ai modder. Sebbene non abbiamo ancora un editor visivo o un debugging profondo, abbiamo aggiunto un numero di diverse visualizzazioni per rendere più facile capire come funzioneranno i vostri NPC (e abbiamo rintracciato un numero di bug dalla nostra parte usandoli!). Alcune di queste funzionalità sono ancora in sviluppo, ma ecco un'anteprima del nostro lavoro in corso e di cosa arriverà presto nelle future release.

Ognuna di queste visualizzazioni può essere abilitata attivando certi flag di debug NPC sui singoli NPC. Questo viene fatto usando il comando di debug NPC mentre si mantiene l'NPC nella propria visuale. Potete farlo digitando /npc debug set <flag> nella console della chat in-game o aggiungendo i flag come una lista separata da virgole nella proprietà Debug del ruolo dell'NPC stesso. Eseguire il comando /npc debug presets fornisce una lista completa dei flag disponibili e dei set preimpostati di flag che possono essere usati, ma i flag di visualizzazione più utili sono dettagliati qui sotto.

/npc debug set VisAiming

Potete usarlo 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 marcati correnti agganciati dall'NPC. Nella maggior parte dei nostri template standard, l'NPC ha un singolo LockedTarget che è solitamente l'entità con cui sono attivamente impegnati in combattimento. Utile per capire come e quando l'NPC cambia focus, così come esattamente qual è il loro focus corrente in una folla.

/npc debug set VisSensorRanges

Visualizza tutti i raggio dei sensori Mob attualmente controllati come anelli e settori di vista, così come quali entità nel raggio vengono abbinate da quali di questi sensori. Con come questi sensori sono generalmente usati nei nostri NPC, questo dà una rapida panoramica visiva delle 'capacità sensoriali' di un NPC. Notate che sebbene questi siano mostrati come settori e anelli, sono tecnicamente sfere e coni che possono essere delimitati da condizioni di altezza.

Il primo screenshot mostra l'Orso che dorme e ha solo un sensore attivo. Nel secondo screenshot l'Orso ha udito, visione e raggio di rilevamento assoluto. Anche se le Pecore sono rilevate dal raggio visivo (hanno marchi di bersaglio) sono fuori dal cono visivo. La famiglia di pecore è ancora al sicuro!

/npc debug set VisLeashPosition

Visualizza la posizione corrente del guinzaglio (leash) dell'NPC.

/npc debug set VisFlock

Visualizza lo stormo/gregge (gruppo NPC) associato a questo NPC. Questo display include la marcatura del leader dello stormo e tutti gli NPC che sono attualmente membri dello stormo.