Quando incominciai a fare mappe ho imparato a mie spese quanti pasticci si possono combinare se nessuno guida i nostri primi passi. Il Web è pieno di tutorials, in inglese, francese e tedesco, e i miei sono fra i primi in italiano. Ma i tutorials, tutti i tutorials, vanno subito al sodo: ti insegnano a fare questo e quello, dando per scontate tutta una serie di conoscenze preliminari indispensabili per integrare correttamente le abilità acquisite in un quadro generale.
Ecco perché, prima ancora di mettere le mani sull’editor e sorbirsi decine di tutorials, è opportuno mandare a mente e tenere sempre presenti alcuni accorgimenti di base, tanto per evitare errori grossolani e riuscire a impostare fin dall’inizio il lavoro secondo un metodo economico ed efficace. In questa pagina parleremo dell’ABC del mapping. Ti consiglio di spendere qui un quarto d'ora per evitare poi di buttare al vento ore ed ore di duro lavoro. Il mio decalogo è dunque questo:

La prima cosa di cui bisogna prendere coscienza all’inizio è che, per quanto potenti, sia l’Editor che il Motore hanno le loro limitazioni. Perciò, molte delle cose che ci si immagina di poter realizzare in una mappa, possono non funzionare o funzionare male. Ci sono limitazioni di ordine quantitativo: c’è un limite massimo di brushes (intorno ai 10.000 in Q3) che l’Editor può gestire e il motore ‘disegnare’; c’è anche un limite, più contenuto, alle entities che si possono piazzare in una mappa (intorno alle 2000, portato addirittura a 4060 in Q4 - ma so di chi l'ha già sforato :D, ritrovandosi l'errore: Warning: Fatal ERROR. No free entities); c’è, naturalmente, un limite alle dimensioni delle mappe stesse. Ci sono anche delle limitazioni di ordine funzionale: è possibile, ad esempio, assegnare un'lluminazione globale all'intera mappa, semplicemente inserendo una chiave nel worldspawn, ma non è possibile modulare l'illuminazione per settori o aree; è possibile, e molto semplice, aggiungere nebbia a una mappa, ma non è assolutamente possibile, almeno in SoF2, avere banchi di nebbia o aree con nebbia localizzata. Etc. etc. È importante, soprattutto agli inizi, tenersi alla larga dai limiti quantitativi ed evitare di sfidare le limitazioni di ordine funzionale. Lo stesso vale per le questioni di ordine progettuale. Troverai un elenco completo dei Limiti di Q3/GTK Radiant qui a fianco: "Maximum Allowable Design Limits", e un database di errori alla pagina Q3/Radiant Errors db, accessibile dala Home Page.

Uno degli errori macroscopici più frequenti di chi è alle prime armi è quello di partire in quarta a tutto gas, mettendo in cantiere sin dall’inizio una mappa grande, complessa e articolata, del tipo: il mio palazzo/quartiere/scuola/ufficio/etc. in cui vivo, studio o lavoro. Il più delle volte questo porta a due esiti diversi ma ugualmente fallimentari: a) appendo i guanti e dimentico il mapping; b) ci sto mesi e mesi sulla mia prima mappa finché, dopo carrellate di errori, prove, ancora errori, ripensamenti e correzioni, mi accorgo che sto cercando di fare il passo più lungo della gamba. Naturalmente, la strategia (b) può anche portare, se nel frattempo si impara dai propri errori e si insiste sulla strada scelta, a risultati più allettanti, ma in ogni caso con un dispendio di energie sproporzionato. Perciò, è sempre consigliabile incominciare con qualche progetto di modeste dimensioni e complessità, di cui si ha la consapevolezza di poterlo portare a termine con le limitate competenze di cui si dispone in partenza. Il resto verrà col tempo ;)

Carta e matita non sono morte. Prima di accendere il PC, è opportuno avere le idee chiare su cosa si intende fare con l’Editor e buttare giù quelle idee su un pezzo di carta. So bene che questo richiamo all’era pre-digitale può sembrarti assurdo. Ebbene, non è così. Per capire questa necessità bisogna, purtroppo, fare riferimento a una delle fasi terminali della costruzione di una mappa o livello, cioè alla sua ottimizzazione e, in particolare, al controllo delle r_speeds (il numero di poligoni che il motore deve ‘leggere’ in ogni punto della mappa), da cui dipende la performance in FPS (Frames Per Secondo) dell’intera mappa. Una resa ottimale dei FPS si ottiene con una buona architettura e con il sussidio di tecniche di controllo della Partizione binaria dello spazio (BSP) e della Visibility (atraverso l'uso di “hints” in Q3, e di Visportals in Q4). Una buona architettura parte sempre dalla carta, non soltanto dal punto di vista estetico, ma anche e soprattutto funzionale: ecco perché è consigliabile incominciare a disergnare lo spazio con in mente la performance. Certo, termini come BSP, Hinting, Visportal etc. sono per ora cinese per chi parte da zero, per cui mi dirai: come posso mettere su carta un buon impianto architettonico se ancora non so come il motore ‘leggerà’ lo spazio e ciò che ci metto dentro? Questo non è il luogo per affrontare la questione, ma per farti una prima idea su come funzionano i videogames basati sul motore Q3 il guardati Structural Vs. Detail Brushes; per il Q4 dà un'occhiata al tutorial Visportals (Q4 engine games). Farai il primo passo verso una comprensione approfondita di come questi motori "vedono" e 'rendono' ciò che tu costruisci con l'Editor.

Un altro errore abbastanza tipico dei principianti è quello di fare una stanzetta e rifinirla di tutto punto prima di passare al resto della struttura della mappa. Lo so che è entusiasmante vedere il prodotto finito, sia pure limitatamente a una piccola porzione della mappa che abbiamo in cantiere, con tutti i dettagli, le luci, i modelli al posto loro etc., insomma realisticamente rifinita. Certo, è qualcosa di cui abbiamo sicuramente bisogno, se non altro per ripagarci del lavoro fatto, ricaricarci e andare avanti con tutto il resto. Eppure, si tratta di un metodo di lavoro decisamente sbagliato. Il perché è presto detto: nel corso del lavoro, anche quando si sia partiti da un disegno su carta più o meno definito, sorgerà a più riprese la necessità di ridisegnare una o più stanze, spostare un corridoio o una porta, ridisegnare l’illuminazione oppure di cambiare le textures dell’intera mappa. A quel punto, tutte le nostre fatiche spese nel rifinire quel primo piccolo successo di realismo andranno a farsi benedire. Oltre a ciò, capita spesso, soprattutto nella messa a punto dei dettagli, di accorgerci strada facendo che qualcosa che avevamo fatto in un primo momento può (e deve) essere rifatto in modo molto più semplice e con minor dispendio di risorse. Quindi è consigliabile resistere alla tentazione di vedere terminate singole porzioni della mappa e concentrarsi piuttosto sulla struttura generale prima di passare alle rifiniture.

Nei Forums dedicati allo sviluppo di giochi basati sul Q3 capita spesso di sentire mappers alle prime armi lamentare il fatto che impiegano ore, se non giorni, a compilare una mappa, e che alla fine vengono fuori files pessantissimi rispetto alle dimensioni della mappa stessa. Si tratta di tipi piuttosto sprovveduti, che oltre a ignorare completamente quanto si diceva al punto (2), non hanno mai sentito parlare di Caulk e Detail Brushes, cosucce con cui, se lavori sul Q3, dovresti familiarizzare fin dall’inizio. Che cosa sono e come funzionano è spiegato per sommi capi nella nota qui a fianco e approfondito nei rispettivi tutorials: Prima stanza [soon] e Structural vs. Detail Brushes. Per ora valgano questi consigli: 1) ogni poligono che disegni nella tua mappa va interamente rivestito, prima di tutto, con la texture chiamata Caulk, che si trova in locazioni diverse a seconda del videogame. Dopo di che, una volta stabilito quali sono i lati che saranno visibili in-game, si procederà a rivestirli (questi e solo questi) con la texture desiderata, mentre il resto, che rimarrà nascosto ai giocatori, resterà rivestito con caulk. 2) per i giochi che usano il Q3, una volta costruito il perimetro della tua mappa, cioè il recinto che contiene lo spazio interno o worldspawn, ogni altra struttura interna dovrà essere costruita con Detail Brushes. Più precisamente, dal momento che di default l’Editor produce solo Structural Brushes, i brushes usati per le strutture interne dovranno essere settati su Detail non appena disegnati, semplicemente selezionandoli (Ctrl+Tasto-Sx-del-Mouse) e scegliendo dal menu: SELECTION > MAKE DETAIL. Naturalmente la cosa è un po’ più complessa, ma per ora questo suggerimento metodologico può bastare. Se invece usi solo il Q4, il problema dei tempi di compilazione non ti riguarda, perché l'introduzione del lighting in tempo reale ha incredibilmente velocizzato il processo. Per quanto riguarda l'uso del Caulk, invece, nulla o quasi è cambiato: è vero che i lati dei poligoni che sono a contatto con l'esterno del worldspawn non vengono renderizzati dal motore, per cui anche se rimangono rivestiti di textures non incideranno sui tempi di calcolo. Tuttavia, resta il fatto che le dimensioni della mappa cresceranno comunque, e ciò renderà il file più pesante e la mappa o livello più lenta da caricare. Quindi lunga vita al Caulk.

Se hai già dato una occhiata all’interfaccia di GTK Radiant avrai notato, in mezzo in alto, un bottoncino che al passaggio del mouse mostra la scritta CSG SUBSTRACT. Dimenticalo! Non Usarlo, almeno per ora. Questo strumento serve per eliminare o ‘sottrarre’ una parte di un poligono semplicemente inserendovi dentro un altro poligono della forma corrispondente alla cavità che si vuole ottenere. Come tale è una buona scorciatoia per disegnare geometrie complesse. Ma i miracoli che promette potresti pagarli cari, decisamente troppo cari. Infatti, la sottrazione potrebbe generare piccolissimi brushes di scarto, che poi nella fase di compilazione, quando cioè l’editor seziona i poligoni per ottenere triangoli più piccoli e per quanto possibile regolari, diventeranno con ogni probabilità degli Evil Brushes, provocando errori che andranno a bloccare l’intero processo. In Q3 la cosa potrebbe diventare ancora più drammatica se il CSG Substract viene applicato a uno Structural Brush, perché in questo caso, oltre al rischio ora ricordato, i micropoligoni di scarto andrebbero a generare miniportals, e dunque una sfilza di errori computazionali per cui la tua mappa sarebbe letteralmente da buttare. Quindi, se la curiosità è più forte delle mie raccomandazioni, provalo semmai su un Detail Brush, usando ogni cura nel verificare che l’intersezione dei poligoni sia netta e geometricamente pulita. Ma non usarlo mai e poi mai su Structural Brushes e tanto meno su Mesh ottenute con EasyGen. Fa’ un po’ tu ma..., come vedi, chi lo conosce lo evita.

In alcune versioni di GTK Radiant la griglia di lavoro può essere regolata fino a un minimo di 0,25 (in SoF2 p. e, mentre in CoDRadiant è stata fissata a 1). Per ottenere un lavoro pulito ed evitare il rischio di errori, è consigliabile disegnare le strutture portanti usando numeri interi, riservando le frazioni ai dettagli. In altre parole, non usare mai una griglia ridotta a 0,50 o 0,25 per i grandi brushes, soprattutto se si tratta di Structural Brushes, perché potresti andare incontro, soprattutto nelle giunzioni o nel caso di poligoni irregolari, al generarsi Evil Brushes o comunque di errori di computo (va da sé, i brushes non devono mai sovrapporsi l'un l'altro!). Quando usi la griglia a 0.25 su gioci basati sul Q3, assicurati di star lavorando su un Detail Brush.

Un altro accorgimento da osservare è: costruire sempre muri spessi, mai sottili. Questo per evitare che quando un giocatore si trova attaccato a un muro o comunque molto vicino ad esso, una parte del corpo oltrepassi il muro stesso e possa essere colpita dal lato opposto. Molti custom mappers (ma il difetto si trova anche in alcune stock maps), ignorano questo accorgimento. Per baypassare il problema basta costruire muri spessi o, quando ciò non è possibile, aggiungere lungo il muretto o elemento sottile che sia (in alto, in basso, in mezzo, non ha importanza) un Block Player, di modo che il giocatore non possa mai avvicinarsi al muro tanto da sporgere una parte del corpo oltre il muro stesso.

Non dico degli errori generati da eventuali bugs dell’Editor, ma dei warnings pesanti, etichettati ERROR o FATAL ERROR dall'Editor, che restituiscono il risultato di un tuo errore. Certo, GTK Radiant è un programma in continuo sviluppo e come tale non è esente da bugs, ma le cause più frequenti di errori sono dovute a infrazioni di un qualche limite dell'Editor da parte dell'utente. Gli errori possono insorgere da un momento all’altro, soprattutto se si lavora un po’ a tirar via. Ma anche il più scrupoloso dei mappers dovrà sicuramente fare i conti con qualche errore, ricercarne di volta in volta la o le cause, analizzare il problema e risolverlo. A questo proposito, in questo sito troverai due banche dati di Errori di compilazione (uno per Q3/GTK Radiant e l'altro per Q4, entrambi accessibili dalla Home Page > menù a sinistra), con le rispettive probabili cause e, quando possibile, la procedura per risanarli. Metti però sempre in conto che potresti trovarti di fronte a uno di quegli errori piuttosto rari, di cui nessuno sa gran che, o, peggio ancora, alle prese con un errore comune, e in fondo banalissimo, ma la cui soluzione comporta un lavoretto da ergastolano. In questi casi, la miglior cosa da fare è dimenticare il lavoro svolto nella presente sessione, e riprendere il lavoro dalla sezione precedente l’insorgere dell’errore. Naturalmente, ciò è possibile soltanto se hai avuto l’accortezza di salvare una copia di back up della sessione precedente. L'errore più comune sarà sicuramente un difetto nella costruzione del perimetro della mappa o una negligenza che si manifesterà nella forma di un LEAK. Qui a fianco troverai una definizione sommaria di Leak e nel database la procedura per risanarli. Oltre agli errori seri, però, l'Editore ti mostrerà, in console, una serie di warnings, per avvertirti che qualcosa non è ottimizzato al meglio. Stare dietro a questi warnings paralizza il lavoro di chiunque, per cui come regola è bene ignorarli e tirare dritto, a meno che al warning non corrisponda un percepibile malfunzionamento, vale a dire a un vero e proprio ERRORE.

Per fortuna, la comunità dei Mappers e Level Designers nel web è piuttosto numerosa, coesa, solidale e ben disposta ad accogliere i nuovi arrivati e a rispondere a tutte le domande di chi è alle prime armi. Nelle Pagine dedicate alle risorse web per ogni gioco supportato (accessibili dalla Home Page di questo sito) troverai gli indirizzi di tutti i Mapping & level Design Forums di cui sono membro ed altri ancora; ti posso garantire che in ognuno di essi avrai un’accoglienza cordiale e rispettosa, purché, beninteso, non te ne venga fuori con domandine da far ridere i polli. In ogni Forum ci sono dei cosiddetti Sticky da leggere, imparare e digerire prima di fare domande o porre problemi; e questo vale anche per il nostro Forum, cui sei invitato a partecipare. Oltre a ciò, molti forums sono dotati di un motore di ricerca interno, con cui si può, inserendo una parola chiave, fare una veloce ricerca per verificare se il problema che ci toglie il sonno non sia già stato esperito da altri, dibattuto e risolto. Perciò, prima di mobilitare l’intero Forum con i tuoi problemi, verifica con ogni mezzo che la soluzione al tuo problema non sia già disponibile da qualche parte, per esempio, nei nostri database di Common Mapping Errors. Non dimenticare poi che c'è Google, un ottimo strumento per individuare il forum in cui è presente il dibattito su un determinato problema: usa anche quello.

Disegnare Livelli Singleplayer o Mappe Multyplayer non è fra le cose più facili a questo mondo; richiede un certo impegno e porta via tempo. Ma deve pur rimanere un gioco, o meglio, per usare un parolone, una specie di metagioco, visto che si tratta di sviluppare ulteriormente e, magari, contribuire ad allungare la vita dei nostri Videogiochi preferiti. Per fare Livelli o mappe ci vuole, semplicemente: 1) un buon editor, 2) un pizzico di talento e 3) molta pazienza. L’Editor l’hai già (GTK Radiant 1.4 se hai deciso di lavorare su giochi non recentisimi basati sul Q3), oppure te lo trovi già nei CD / DVD dei videogames più recenti come Doom3 o Quake 4; o ancora, negli SDK che di solito vengono rilasciati in seguito alla messa sul mercato di un videogame. Il talento lo scopriremo strada facendo; quanto alla pazienza, beh, se non hai pazienza allora dimentica tutto: probabilmente il mapping non fa per te.