contact contat contattaci mail scrivici write mailme email e-mail
Game Programming Italia
Introduzione all'engine di Quake III Arena
di Andrea "TexZK" Zoppi texzk@gameprog.it http://texzk.gameprog.it | 12-01-2004 21:12:18 | 3950 hit
Questo articolo cerca di introdurre l'utente all'engine di Quake III Arena, spiegandone le caratteristiche tecniche in modo generale.
Commenta/Vota | Segnala | Stampa | Aggiungi/Togli ai Preferiti | Cerca simili

Questo articolo introduce l'utente al modding di "Quake III: Arena", spiegando quali sono le caratteristiche tecniche utilizzate dal famosissimo titolo di id Software

Introduzione all'engine di Quake III Arena
Scritto da Andrea "TexZK" Zoppi

Quake III Arena è un gioco divenuto famoso per la sua giocabilità immediata, ma soprattutto per il suo engine di gioco potente, affidabile e facilmente ampliabile, seguendo l'esempio lasciato dai precedenti titoli della id Software.
Come potrete vedere di seguito, non si tratta di un engine particolarmente difficile da capire, ma è piuttosto vasto ed è meglio avere una panoramica generale prima di cominciare a mettere le mani sui file del gioco.

Che tipo di formati utilizza?

Ebbene, in questo tutorial capirete in che modo funziona l'engine di Quake3 e che algoritmi/linguaggi utilizza. Cominciamo con una scaletta che mostra le caratteristiche tecniche del videogioco, che analizzeremo nei prossimi paragrafi:

  • librerie grafiche: OpenGL
  • formato archivi: PK3 (uguale allo ZIP)
  • file del gameplay: in formato QVM (formato proprietario della id Software)
  • formato texture: immagini True-Targa (TGA) ed a compressione JPEG
  • formato modelli: MD3 (formato proprietario di id Software)
  • formato mappe: albero BSP
  • formato sonoro: WAVE a 22khz 16bit
  • linguaggio degli script/shader: lontanamente simile al C

Per modificare i file del gioco, quindi, dobbiamo conoscere questi formati e questi linguaggi, che come già detto cercherò di spiegare nei prossimi paragrafi.

Le librerie OpenGL in Quake 3

Queste librerie grafiche sono le dirette concorrenti delle Direct3D di Microsoft. Al contrario di queste ultime, le OpenGL sono open-source, cioè vengono distribuite con anche i sorgenti, liberi di essere modificati, espansi ed ottimizzati. Infatti, le OGL hanno tantissime "espansioni", che le rendono utilizzabili su tutti i fronti (anche se ultimamente le Direct3D hanno una vastità tale da renderle più competitive di prima - basti guardare a titoli come Half-Life2 che supportano tutte le ultime novità in campo D3D).

Non vorrei soffermarmi troppo sulle OpenGL, in quanto non sono un esperto in materia, ma dopo questa introduzione vorrei dire qualcosa in proposito.

Quake3, all'inizio del nuovo millennio, era il gioco che sfruttava forse più di tutti le OGL, utilizzando anche alcuni algoritmi utili a rendere più realistica la grafica. Infatti, il Q3 engine comprende curve scalabili ad altissima definizione, trasparenze "impalpabili" nelle texture, che supportano shader sfruttabili appieno, anche grazie all'implementazione delle funzioni "tc-mod", "deform-vertex", "rgb-gen" e "blend-func", che permettono al sistema grafico di deformare le texture, muoverle, rotearle, applicare riflessi e tantissime altre cose. Insomma, le OpenGL di Quake3  sono sfruttate appieno e pensando alla sua data di uscita (dicembre 1999) ci si accorge di quanto sia ancora un engine al passo coi tempi.

Gli archivi PK3

Gli archivi PK3 sono semplicemente degli archivi ZIP con estensione modificata. Ovviamente permettono di comprimere i dati senza compromettere la struttura delle directory, che è visibile nell'ultimo campo nei programmi come WinZip. Sfruttateli appena potete!

I file QVM

Riguardo al discorso di come funziona questo engine, è bene sapere che non può partire senza i file QVM, che contengono tutte le informazioni riguardo all'interfaccia, ai menu, all'Intelligenza Artificiale, alle armi... insomma, tutto quello che riguarda il gioco vero e proprio. Infatti, l'eseguibile "quake3.exe" contiene solo l'engine grafico, che può essere utilizzato per creare qualsiasi videogioco (bhe, non proprio, ma ci siamo vicini...), ma non contiene proprio nulla riguardo all'aspetto del gioco. A noi starà a decidere che gioco creare, modificando opportunamente i file QVM (questo lo vedremo in altri tutorial più specifici).

I file QVM sono compilati in linguaggio C, anche se presentano alcune differenze da quest'ultimo. Per esempio, la funzione principale non è la famosissima "main()", ma la "vmMain()", che ha un modo tutto suo di farsi passare variabili dall'engine (implementa dodici argomenti sotto forma di interi). I sorgenti del gioco sono compilati, ovviamente, da un compilatore apposito distribuito insieme ad essi. Contiene anche molti nuovi tipi di dato, altri sono stati modificati e c'è completo supporto per quel che riguarda il 3D nelle OpenGL (non nel senso che si possono utilizzare le funzioni OGL, ma che ci sono funzioni apposite per lavorare nel 3D).

Quindi, per lavorare sui file QVM bisogna conoscere piuttosto bene il linguaggio C e come si lavora in un ambiente 3D, senza dimenticare di conoscere i tipi di dato che sono alla base del linguaggio QVM (le strutture degli shader, dei client, eccetera). Questo è forse l'aspetto dell'engine di Quake3 più difficile da modificare, talmente è vasto e complesso. Sicuramente a questo tutorial ne seguiranno altri dedicati alla modifica/aggiunta di nuovi elementi di gioco, osservando come bisogna comportarsi per ottenere un buon risultato.

Le texture nel Quake 3 engine

Le texture in questo fantastico engine 3D sono di due formati, pochi ma funzionali a ciò che si vuol fare: il formato True-Targa (TGA) ed il formato JPEG. A seconda delle loro caratteristiche possiamo capire quando e come utilizzarli, anche negli shader (vedere il relativo paragrafo).

Il formato TGA è molto utile in quanto possiede un canale alpha che, se opportunamente utilizzato, permette di applicare effetti "speciali" alle texture. Per esempio, possiamo rendere trasparenti i pixel a seconda della quantità di canale alpha presente su di essi, senza rimetterci di qualità nei colori (come invece avviene nelle immagini JPEG in cui viene sottratto un colore). Ma la qualità ha un prezzo: i file in questo formato grafico saranno decisamente enormi, quindi è meglio utilizzarlo solo nei casi specifici, come quello sopraccitato, oppure per creare icone, font multicolore e qualche texture speciale. Di solito viene utilizzato per gli elementi dell'interfaccia.

Il formato JPEG è famosissimo e gode della possibilità di occupare poco spazio su disco, pur mantenendo una qualità accettabile. L'engine di Quake3 sfrutta questo formato per le texture più disparate, partendo da muri opachi ed arrivando agli effetti particellari. Per quanto riguarda gli effetti speciali, viene molto spesso utilizzato per quelle texture che hanno bisogno di molta trasparenza, sfruttando come canale alpha la percentuale di colore nero nei pixel, oppure per le più svariate situazioni in cui c'è bisogno applicare effetti di addizione/sottrazione del colore.

I modelli MD3

Questo formato 3D è stato creato appositamente per l'engine di Quake3. Come tutti sanno, ogni sistema grafico ha un proprio formato per i modelli 3D, in quanto deve contenere solo le informazioni utili all'engine: ad un sistema grafico che utilizza solo modelli "statici" e con skin esterna non interessa nulla di contenere informazioni sull'animazione 3D e sui pixel della skin, mentre per qualche altro sistema grafico avviene il contrario. Il formato MD3 contiene solo i frame di animazione, i "tag" (sono i "nomi" di alcune zone del modello) ed il link alla skin esterna. La gestione delle animazioni e della skin viene affidata ad altri file, come "animation.cfg" per determinare le animazioni e file QuakeC (che derivano dagli omonimi file di Quake 1, ndr) per informazioni varie sulla skin, sui frame eccetera.

Questa descrizione dei file MD3 non è sempre come ho scritto qui, ma cambia a seconda dell'editor utilizzato. Per esempio, gmax esporta un file MD3 contenente quasi tutte le informazioni del modello, mentre MilkShape 3D esporta il modello con allegato uno script in QuakeC.

Un discorso particolare è rivolto ai tag. Essi sono indispensabili per dire dove far "attaccare" gli altri "pezzi" del modello, quando esso è animato (alcune volte anche quando non lo è). Infatti, in Quake3 troverete sempre modelli divisi in "pezzi": la parte superiore, la testa e le gambe. Queste parti, per sapere come essere "attaccate" o semplicemente disposte, devono disporre di tre vertici uniti (in pratica un triangolo) a cui viene assegnato un nome, che è il tag. Con questi vertici l'engine capisce in che modo disporre le parti del modello.

Le mappe di Quake3

Il BSP, come potrete osservare nei tutorial dedicati che troverete un po' dappertutto, è uno dei metodi migliori per gestire ambientazioni 3D. Esso si basa su una struttura ad albero (da qui vengono gli "alberi BSP") che dispone le facce dei poligoni a seconda se sono visibili da una determinata disposizione oppure no. E' un formato che rende il motore 3D decisamente più veloce, poiché le facce non visibili non vengono disegnate ed il tempo dei calcoli per stampare i poligoni su schermo si riduce notevolmente. L'engine di Q3 utilizza questo formato per caricare le mappe del gioco.

Queste mappe possono contenere entità (oggetti e modelli 3D), strutture complesse (curve ad alta definizione, gruppi di poligoni, brush movibili), portali e tipi di brush particolari (cieli, fluidi, nebbia, texture scivolose, brush trapassabili eccetera). Ad ogni brush è applicata una texture o uno shader, che possono essere disposti a piacere come coordinate e rotazioni. Al brush può essere assegnata una classe (il tipo di oggetto), corredata da flag (le opzioni della classe), ed in questo caso diventa un'entità. A causa dell'utilizzo degli alberi BSP non è possibile creare brush concavi.

Sicuramente troverete di più nei tutorial dedicati al mapping di Quake3, che tratteranno più tecnicamente le mappe del gioco, spiegando come ottimizzarle al meglio e come sfruttare gli shader a nostro piacimento.

I suoni del gioco

I suoni di Quake3 sono registrati secondo il tipico formato WAVE a 22.050 Hz a 16bit. Non c'è molto altro da dire, se non che c'è libertà di scelta tra mono e stereo. Anche le musiche del gioco sono registrate in questo formato, anche se qualcuno si è azzardato ad inserire un lettore MP3. Ovviamente vi consiglio di utilizzare suoni stereo solo ove necessario, in quanto sprecano il doppio dello spazio su disco (ed il formato WAVE non si spreca a colmare l'hard disk...). E' ovvio anche che sta a voi a creare suoni più o meno belli!

Gli script

Gli script sono delle sequenze di codice richiamate dal gioco che permettono di determinare le cose più disparate. Si spazia dalla gestione degli oggetti (no, non come nei QVM) alle frasi dette dai bot. Anche gli shader sono degli script, ma hanno bisogno di essere trattati in un altro modo.

Gli script sono scritti in un linguaggio che ricorda, anche se molto lontanamente, il C. Di solito il linguaggio degli script viene usato per definire delle strutture, come nel caso degli shader, delle mappe e dei bot. In altri casi serve per definire variabili/costanti, come nella gestione degli oggetti e delle armi, oppure per comandare in che formato scrivere una frase. Bisogna stare attenti a non trattare gli script come funzioni, in quanto non ce n'è la minima traccia. Come già detto, servono solo per definire strutture, variabili e costanti, mentre non hanno la capacità di svolgere funzioni, poiché quel compito è svolto dai file QVM.

Gli shader

Gli shader sono un'implementazione grafica che permette di aggiungere effetti alle texture, come la trasparenza, la rotazione, la traslazione, il multitexturing, la deformazione, la riflessione eccetera. Quelli di Quake3 sono tra i più complessi che si potevano trovare fino a prima dell'arrivo delle DirectX 9.0. Infatti, questa libreria grafica permette di creare shader ancora più complessi e con funzionalità maggiori rispetto alle OpenGL di Quake3, ma questi ultimi rimangono ancora oggi un punto di riferimento.

Nell'engine di Quake3 è possibile creare shader decisamente completi e funzionali, grazie ad alcune implementazioni. Ho già citato le funzioni "tc-mod", che permettono di traslare, scalare e roteare le texture, ma ci sono alcune funzioni OpenGL capaci di deformare i vertici di una texture, di gestire i canali alpha, di darle "capacità" particolari, come l'attivazione del mip-mapping, la creazione di "texture-box" per i cieli tridimensionali eccetera. Senza contare la capacità di uno shader di emettere luce, di caricare frame esterni per fare animazioni e la capacità di "riflettere" un'immagine assegnata (una riflessione "finta") oppure riflettere l'ambiente come uno specchio.

Questo argomento, per quanto sembri solo utile per migliorare l'estetica, è molto utile per dare una certa giocabilità ad una mappa. Per esempio, è possibile creare portali o specchi che permettono di vedere cosa c'è in un altro punto della mappa, oppure rendere il terreno scivoloso, riempire una stanza di texture semitrasparenti che offuscano la vista (come per la nebbia o per gli ologrammi). Insomma, gli shader sono molto interessanti e sicuramente scriverò tutorial su come utilizzarli (spero) al meglio.

Struttura delle directory

Bene, se siete arrivati a questo punto vi dico subito che ora viene la parte più interessante dell'articolo per un modder. Infatti, dopo tutte le lagne riguardo a com'è l'engine di Quake3, è ora di scoprire dove dovrete mettere le mani per modificare ciò che vorrete. Ho deciso di creare un "directory tree", in modo da sapere facilmente che cos'è contenuto in una specifica cartella, vedendone subito la struttura. Le cartelle riportate qui di seguito si riferiscono alla versione base di Quake3, che può avere cartelle diverse dai MOD. Non ho inserito alcune cartelle perché contengono solo uno o due file. In ogni caso, è meglio controllare di persona esplorando i PK3.

 Directory  Descrizione
 ..\ cartella principale di Quake3
 <nome_mod> cartella principale del MOD ("baseq3" nel caso del gioco base), che contiene file di configurazione vari
 |- <botfiles> cartella che contiene script riguardanti la gestione degli oggetti e delle armi
 |  |- <bots> gestione dell'AI (determinazione della difficoltà e frasi delle chat)
 |- <demos> contiene le registrazioni di azioni di gioco
 |- <env> contiene le texture usate per creare cieli 3D
 |- <gfx> texture dell'interfaccia
 |  |- <2d> immagini dell'interfaccia
 |  |  |- <numbers> font (numeri)
 |  |  |- <damage> texture dei danni
 |  |  |- <misc> texture varie
 |- <icons> icone dell'interfaccia
 |- <levelshots> qui ci sono le immagini di caricamento delle mappe
 |- <maps> mappe BSP e direttive dell'AI (file AAS)
 |- <menu> texture menu
 |  |- <art> immagini varie dei menu
 |  |- <medals> icone delle medaglie che si guadagnano nel gioco
 |  |- <tab> termini della tabella punteggi
 |- <models> modelli MD3, skin e file di configurazione dei modelli (vale per tutte le sottocartelle)
 |  |- <ammo> modelli e skin delle munizioni
 |  |  |- <rocket> modello del razzo
 |  |- <flags> bandiere
 |  |- <gibs> parti del corpo maciullate
 |  |- <mapobjects> modelli generali usati nelle mappe
 |  |  |- [...] seguono cartelle divise per tipo di oggetti (lampade, teletrasporti, statue, eccetera)
 |  |- <players> modelli dei giocatori
 |  |  |- [...] seguono cartelle divise per modello del giocatore
 |  |- <powerups> modelli degli oggetti da raccogliere
 |  |  |- [...] seguono cartelle divise per il tipo di oggetti (munizioni, armature, eccetera)
 |  |- <weaphits> modelli dei danni di varie armi (+ sottocartelle dedicate)
 |  |- <weapons2> modelli veri p propri delle armi
 |  |  |- [...] seguono cartelle dedicate ad ogni arma
 |- <music> musiche del gioco
 |- <screenshots> immagini di gioco
 |- <scripts> definizioni di mappe, bot e shader vari
 |- <sound> suoni
 |  |- <feedback> annunci del server
 |  |- <items> suoni dei vari oggetti
 |  |- <misc> suoni vari
 |  |- <movers> suoni di porte ed elevatori
 |  |- <player> voci dei giocatori
 |  |  |- <announce> altri annunci di gioco
 |  |  |- [...] seguono cartelle divise per nome del modello
 |  |- <teamplay> annunci dedicati al teamplay (cattura di bandiere, ecc.)
 |  |- <weapons> ovvio, sono i suoni delle armi
 |  |  |- [...] seguono cartelle divise per arma
 |  |- <world> suoni ambientali
 |- <sprites> sprite bidimensionali (bolle, sfere, eccetera)
 |- <textures> cartella che contiene texture, ovviamente!
 |  |- [...] seguono cartelle divise per classi di texture (futuristiche, gotiche, animate, ecc.)
 |- <video> cartella contenente i video in formato RoQ
 |- <vm> ecco la cartella dei file QVM

Conclusioni

Con questo documento si conclude il primo approccio con l'engine di Quake III Arena, che si è dimostrato molto versatile ed al passo coi tempi (basti vedere quanti giochi basati su di esso sono usciti anche di recente). Spero che vi siate fatti un'idea generale di che cosa si possa fare con esso, anche se ho spiegato molto generalmente quali sono le sue potenzialità (non era questo lo scopo dell'articolo).
Nei prossimi tutorial entreremo più nel dettaglio, spiegando come si lavora con le mappe ed ottimizzarle al meglio, come creare shader, come programmare con le estensioni di gioco QVM e come modellare con i vari programmi.

Andrea "TexZK" Zoppi

© 2004 Game Programming Italia. Tutti i diritti riservati.




Commenti

Non sono presenti commenti

Per inserire commenti devi essere registrato !
 
Valutazione x 
6VOTI
9


www.steo.it

TIPS: Trucchi per il Visual Studio 6