In questo capitolo vediamo come gestire i contenuti che compongono la nostra applicazione. XNA ci offre la possibilità di caricare e scaricare oggetti dalla memoria rispetto al disco, di effettuare preprocessing dei nostri files, etc in modo trasparente ed automatico.
In un videogioco sono presenti grossissime quantità di file di contenuti. Questi contenuti, tipicamente creati da un artista o da un designer, costituiscono la metà del gioco non composta da codice sorgente e richiedono di essere processati e manipolati per essere utilizzati dal nostro gioco. La content pipeline è l'aspetto di XNA che si occupa proprio di questo lavoro.
In questa lezione esaminiamo i tipi di contenuto con cui possiamo trovarci ad operare, dalle immagini ai modelli tridimensionali.
Modelli 3D
I modelli 3D sono realizzati dal nostro artista, o designer, con editor come Maya, 3D Studio Max, Autocad e Blender. Sono quindi file che contengono gerarchie di nodi che rappresentano scene o oggetti tridimensionali come:
- Personaggi animati o veicoli o armi
- Paesaggi, come città o montagne
- Dettagli, come lampioni o alberi
Ciò che dobbiamo fare è importare vertici e triangoli "già pronti" da un file tramite content pipeline.
Textures e sprites
Sono file che contengono immagini, in diversi formati ed utili a diversi scopi, ad esempio possiamo avere:
- Immagini di sfondo
- Sprite per l'interfaccia utente (barra della vita, indicatori dell'HUD)
- Icone per il menu
- Sprite per le entità di gioco se è un gioco solo 2D
- Animazioni per effetti speciali (esplosioni, fumo, ...)
- Testo
- Mappe di normali per il normal mapping
- Immagini da applicare sopra i modelli con UV mapping (spesso chiamati anche "skins")
- Immagini che fanno da input per gli shaders (possiamo usare una texture come una tabella 1D, 2D o addirittura 3D per contenere numeri per i calcoli degli shaders)
- Immagini per il fondale 3D (possiamo definire sei "istantanee" del fondale 3D che rappresentano quello che l'utente vede a distanza molto grande; tramite questa tecnica possiamo disegnare con un cubo uno sfondo molto bello e con oggetti 3D con il costo computazionale di un cubo texturizzato visto dall'interno e centrato sulla telecamera)
In generale anche le textures vengono create in un editor esterno (Photoshop è uno dei più usati in assoluto, ma non è l'unico) anche se è possibile generarle proceduralmente dentro il codice. Come per i modelli, laddove è necessaria l'abilità estetica di un artista di professione non sceglieremo la via di generare le textures proceduralmente ma piuttosto caricheremo un file già fatto dalla content pipeline.
File audio
Si tratta di tutti quei file che compongono la colonna sonora del gioco ad esempio:
- Dialoghi per le scene animate
- Suoni di armi ed esplosioni
- Suoni ambientali (musiche di sfondo, suoni "sinistri" per un gioco horror, ...)
- Suoni di dettagli (passi dei personaggi, frenate, motore, ...)
- Descrittori di "progetti di suoni", con tanto di descrizione dei parametri e delle rispettive curve dei vari suoni (possiamo definire progetti di suoni con XACT, che ci permette di definire aggregati di suoni che si mescolano tra loro in modo omogeneo in relazione a variabili impostate dall'applicazione.
Ad esempio se abbiamo un suono per il motore di una macchina ad ogni marcia, uniremo assieme questi suoni in un unico suono del progetto e imposteremo una variabile intera di questo suono "aggregato" che rappresenta la marcia corrente e in relazione a questa variabile definiremo la transizione dei vari suoni da una marcia all'altra)
Da XNA 4.0 per la prima volta si applica ai suoni la stessa considerazione che si applica ai modelli ed alle textures procedurali. Possiamo generare anche suoni in modo procedurale, anche se sarà molto raro non importarne di costruiti esternamente da un artista.
File di configurazione
Sono quei file che descrivono i parametri dell'esecuzione del gioco, spesso in formato XML per facilità di gestione ma a volte anche in formati di testo più rudimentali.
Esempi di files di configurazione sono i descrittori dei livelli, che contengono informazioni come:
........ ........ .X...... ##...... ........ ..G.G.GA ..###### ........ ........ ##...... ........ ..G.G.GC ..###### ........ 1....... ########
per definire un livello di un semplice gioco platformer, in cui # sono i blocchi su cui si salta, G per definire le gemme, X per definire l'obiettivo del livello, C e A per i nemici e 1 per la posizione di partenza del giocatore.
Altri esempi sono:
- i file di configurazione dei livelli in XML (numero di vite del giocatore, numero di ondate dei nemici, presenza dei boss a fine livello)
- i file per configurare le tipologie di entità in gioco (astronavi del giocatore, astronavi nemiche, armi)
- i file delle UI del menu, in termini di posizione dei bottoni, label, etc.
Alternativamente è possibile mantenere tali definizioni direttamente all'interno del gioco come variabili statiche, anche se raramente questa è una buona pratica perché le definizioni del gameplay richiedono di essere sperimentate e bilanciate con grande attenzione da un designer.
Possiamo gestire tramite la content pipeline anche altri tipi di entità, in virtù del fatto che la content pipeline è estensibile per gestire formati di file diversi da quelli predefiniti; torneremo su questo punto in seguito.