Quarto? Capitolo quarto? Sono già tre capitoli che parliamo di Quake
Editing e ancora non si è fatto nulla di serio? Sarà ora di cominciare a produrre qualcosa, se no qui mi cacciano via…
Non perdiamo tempo quindi, e facciamo subito un breve punto della situazione: l’universo di Quake è diviso in brush ed entity, e questi due elementi di base vengono memorizzati su disco in un formato molto semplice, un file di testo contenente l’elenco delle coordinate dei punti che formano i poligoni, l’elenco degli elementi animati che popolano l’universo virtuale, le caratteristiche fisiche e motorie dello stesso, e tutto ciò che serve per creare un’esperienza videoludica.
Questo file è identificato dall’estensione .map ed è il file ultimo dell’editing di un livello: quando il .map di un livello è generato, allora è già tutto fatto, perché la fase di design è terminata; l’ultima cosa che rimane da fare è compilare il tutto e provarlo in
Quake.
Entriamo ora nel dettaglio: come si fa a compilare un file map? Ma è semplicissimo: con dei compilatori dedicati, cioè programmi scritti appositamente per convertire (leggi compilare) il file map in un formato interpretabile dall’engine di Quake.
———————————————————————-
Questi compilatori sono in tutto tre:
* QBSP (Quake Binary Space Partition): Questo compilatore è l’unico
* LIGHT: Questo compilatore può anche non essere utilizzato in fase di
* VIS: Questo è l’ultimo nonché meno indispensabile compilatore, anzi,
———————————————————————-
Vediamo ora meglio come utilizzare tutti questi strumenti. Una volta ultimata la progettazione del livello dall’interno del nostro editor, esportiamo il tutto in formato map (c’è sempre il menu di esportazione, in qualunque editor) e lanciamo il QBSP su questo file.
Dopo una serie di output su schermo che indica a che stadio della compilazione si trova il nostro pargoletto, il compilatore sfornerà ben cinque nuovi file con lo stesso nome del map ma con estensioni diverse, denominati .h1, .h2, .pts, .prt e .bsp. I file .h1 e .h2 sono file temporanei necessari al processo di compilazione stesso; il file
.pts si spera sia vuoto, perché è quello che contiene gli errori di design del livello (vedremo in seguito); il file .prt è quello che contiene le informazioni necessarie per un’eventuale successiva ottimizzazione (cioè il VIS, ricordate?) e il file .bsp è il vero e proprio file del livello, quello cioè che Quake è in grado di interpretare.
Tutto chiaro? Beh, potete rileggere per chiarirvi meglio il concetto se non l’avete afferrato completamente, per questa volta siete giustificati (non sono procedimenti così elementari).
Adesso? Va meglio? Meno male… allora procediamo.
Quello che più interessa quindi dopo il passaggio con il QBSP è appunto il file .bsp, perché quello lo possiamo già provare in Quake.
Contiene infatti tutto quello che serve, a parte ovviamente le parti meno complesse: di quelle si occupano gli altri due tool (LIGHT e
VIS). Vedremo più avanti come sia già possibile lanciare il .bsp dalla console di Quake.
———————————————————————-
Procediamo ora con il passaggio successivo, il calcolo delle luci: in questa fase, il LIGHT apre il file .bsp generato dal QBSP, lo esamina, elabora tutte le entità che proiettano luce (ricordate che le luci sono entità, vero?…) e salva tutte queste informazioni di nuovo nello stesso .bsp. A questo punto avremo un .bsp un po’ più grande
(ovviamente) contenente la mappa delle luci del nostro livello.
Ora sì che il tutto comincia ad essere più accattivante, anche se ha i suoi svantaggi: senza lanciare il LIGHT, il .bsp è totalmente privo di informazioni sulle luci, e questo viene interpretato da Quake come un livello totalmente illuminato in ogni sua parte (anche perché lasciare tutto buio sarebbe molto stupido) con la conseguente possibilità di vedere subito quello che abbiamo fatto. Se lanciamo però il LIGHT, dobbiamo essere sicuri di aver posizionato correttamente tutte le luci che servono, altrimenti ci ritroveremo a vagare nel buio più totale!
Attenzione quindi a non dimenticare questo aspetto quando si progetta un livello per Quake, perché sappiamo tutti che l’atmosfera, in questo genere di giochi, è quella che fa la differenza (e quella che caratterizza i giochi della Id Software in generale).
———————————————————————-
Ultimo stadio della compilazione è appunto l’ottimizzazione del livello, alquanto facoltativa per la verità, ma buona norma se si intende distribuire poi il lavoro svolto a terze parti (non si può mai sapere su quale computer girerà il nostro livello se lo mettiamo su
Internet come Freeware, quindi perché non ottimizzarlo).
La prima cosa che va ricordata riguardo al VIS è che è TREMENDAMENTE
LENTO, è un processo lunghissimo (può durare anche molte ore) che vi consiglio di eseguire durante la notte (perché generalmente si dorme o si fanno altre cose che però non riguardano il computer) sperando che il mattino dopo tutto sia terminato (non sempre è così però).
Mi soffermo un attimo per spiegare cosa fa questo VIS in poche parole, in modo da farvi capire perché è così lento anche su un computer ben equipaggiato: considerate un livello molto complesso e ampio, che si sviluppa ad esempio in una serie di saloni (un castello, tanto per essere originali) comunicanti tra loro attraverso grandi arcate in stile gotico (o bizantino, non so nemmeno io cosa voglia dire ma lo dicono tutti, quindi dev’essere importante…). Cosa fa il motore tridimensionale di Quake quando deve rappresentare questi saloni? Semplicemente li disegna in ordine dal più lontano al più vicino, utilizzando il consueto algoritmo del pittore, in modo che il giocatore intraveda i saloni più lontani attraverso le arcate, le finestre, o i vari varchi architettonici del caso.
In questo particolare livello, tutto ciò è indispensabile, perché tutti i saloni sono comunicanti, quindi da ogni salone è potenzialmente possibile intravedere tutti gli altri, ma immaginiamo ora una situazione diversa: lo stesso numero di saloni ma comunicanti tra loro solo attraverso una fessura di 5 cm a livello del soffitto.
Cosa cambia? Cambia che il giocatore non vede praticamente mai gli altri saloni, però il motore tridimensionale li disegna lo stesso!
Questo significa che ci mette un sacco di tempo a disegnare qualcosa che in realtà non è possibile vedere… ecco perché c’è bisogno di
“ottimizzare” il livello una volta ultimato, per evitare di appesantire inutilmente il processore con lavori indiscutibilmente inutili e col risultato di vedersi crollare il frame rate a discapito della giocabilità.
Questo è il lavoro del VIS: calcolare, per ogni singolo punto della mappa, cosa è possibile vedere o non vedere, e memorizzare il tutto in una struttura apposita che indichi di volta in volta all’engine che cosa disegnare, quindi solo lo stretto indispensabile, in modo da lasciare spazio ad altri aspetti del gioco (tipo l’intelligenza artificiale dei nemici).
E’ ovvio che calcolare cosa si può vedere a 360 gradi in ogni singolo punto della mappa è un lavoro mooooolto lungo, ma che alla lunga viene completamente ripagato da un guadagno di velocità strabiliante.
Morale? Non perdete tempo ad ottimizzare un livello a metà dello sviluppo, ma ottimizzatelo sempre una volta ultimato e prima di distribuirlo.
———————————————————————-
Bene, anche per questo capitolo abbiamo detto tutto… vi rimando al prossimo per…
Ok, ok, stavo scherzando… ora ve lo dico come provare i vostri livelli in Quake, non preoccupatevi! Non mi sono dimenticato!
Dunque, innanzitutto vi ricordo che i file leggibili da Quake sono i
.bsp, quindi quelli prodotti dal QBSP; che poi voi calcoliate o meno le luci e/o ottimizziate il tutto, poco cambia: Quake si comporterà di conseguenza.
Una cosa che va considerata però è che Quake non va a cercare i .bsp in giro per il vostro hard disk, ma li cerca sempre dentro alla sua sottocartella di default, “.Id1”. Questa cartella di default contiene due file che sono sostanzialmente tutto il corpo di Quake, cuore escluso (il cuore è nell’eseguibile, ed è il vero e proprio motore tridimensionale): Pak0.pak e Pak1.pak.
Questi due file contengono in realtà una sottostruttura a cartelle in cui sono distribuiti tutti i file dei quattro episodi di Quake, più tutti gli altri file che gli girano intorno (campioni audio, modelli tridimensionali di mostri e oggetti, porzioni di codice di automazione, ecc…).
Il motivo per cui tutti i file necessari sono contenuti in due file compressi invece che uno solo (che sarebbe più logico) è che Pak0.pak
è praticamente la versione Shareware, mentre Pak1.pak è quella registrata… e non aggiungo altro.
Ora arrivo al dunque: in questa sottostruttura a cartelle, c’è una sottocartella denominata “.maps” che contiene proprio i file .bsp dei vari livelli del gioco originale, ed è proprio in questa sottocartella che Quake va a cercare, eventualmente, anche il vostro.
Lo so che vi state chiedendo “Ok, ma come faccio a sbattere il mio bsp dentro al PAK?”, ma la risposta è molto più banale: basta creare una sottocartella maps in Id1 (sì, con il Gestione Risorse) e copiarci dentro il vostro bsp, ed il gioco è fatto! I livelli normali di Quake verranno prelevati dai pak, ma nel caso in cui qualcosa non venga trovato lì, il nostro terremoto lo andrà a cercare in una sottocartella DOS, quella appunto che abbiamo appena creato.
Il resto è banale: dopo aver piazzato appositamente il vostro file, lanciate Quake, aprite la console e digitate “map ” seguito dal nome del vostro file bsp, senza l’estensione bsp (e come nome corto, quindi max 8 caratteri)… come per magia vi ritroverete a sguazzare dentro al vostro livello!!!
Semplice no?
———————————————————————-
L’ultima cosa prima di chiudere… questo è un indirizzo internet da cui potrete scaricare i tre tool di compilazione di cui vi ho parlato in questo articolo:
ftp://ftp.cdrom.com/pub/idgames2/
utils/level_edit/bsp_builders
Ovviamente questo è il più frequentato (i navigatori più esperti poi riconosceranno subito cdrom.com), ci saranno sicuramente mirror più vicini a voi, ma questa estenuante ricerca la lascio a voi, a me basta darvi la traccia iniziale. Troverete anche varianti più evolute di questi tool, sviluppate non direttamente dalla Id ma non per questo meno affidabili, come QBSP con gestioni avanzate degli errori, LIGHT con opzioni di illuminazione avanzate o VIS più veloci del solito o con la stima del tempo totale di elaborazione, ma poco conta: quello che avete letto ora vi basta per usarli anche se al livello più basso.
Adesso è veramente tutto: ora conoscete tutti i passi necessari per creare un livello di Quake, dalla definizione delle classi di brush ed entity alla compilazione ottimizzata e al testing dentro Quake… cos’altro serve?
A dire la verità, serve la parte più cruciale: l’editor, quello su cui spenderemo la maggior parte del tempo e quello che fa la differenza, perché quello che possiamo fare dipende indiscutibilmente dallo strumento che utilizziamo… un editor intelligente e versatile ci permette di risparmiare un sacco di tempo e fatica a fare le cose da zero, fornendoci strumenti avanzati che lascino a noi solo il compito di metterci la creatività, senza distrazioni derivanti da valanghe di opzioni incomprensibili, procedimenti inutilmente ripetitivi e fastidiosi, e chi più ne ha più ne metta…
…ma questo, nel prossimo capitolo!
