Guida al modding di Gothic 1 e 2 – Parte 2°

Le possibilità offerte dalla sola alterazione delle istruzioni sono numerose; in particolare appaiono piuttosto semplici i seguenti generi di intervento:

1. reimpostazione degli attributi (ad esempio è possibile regolare individualmente la silhouette dei personaggi, la forza degli animali, la resistenza delle armature, la potenza delle magie);
2. riassegnazione dei modelli (onde poter ridistribuire le teste ed il vestiario dei personaggi o rimpiazzare le sagome di animali ed oggetti);
3. ridefinizione dei bagagli (quali le armi dei personaggi ed i trofei degli animali);
4. riscrittura dei dialoghi (al fine di correggere eventuali errori lessicali, tradurre mods stranieri, aggiungere più alternative nelle conversazioni, implementare nuove quests);
5. riorganizzazione delle routines (ovvero le sequenze di azioni prestabilite per i personaggi al trascorrere del giorno e della notte e le attività di interazione con alcuni elementi del gioco per la creazione di spade, pozioni, cibi).

L’ultimo punto elencato potrebbe apparire il meno stimolante ad una prima lettura, mentre invece nasconde interessanti potenzialità delle quali voglio fare qualche esempio.
Tra le idee più banali vi è quella di prevedere l’aggiunta nelle tasche del protagonista di un pezzo di minerale in corrispondenza di un arbitrario numero di colpi di piccone sul filone oppure di una bottiglia d’acqua per ogni prelievo dai pozzi; giusto per dare un senso ad alcuni elementi interattivi già esistenti.
Più complesse sono invece l’associazione del pentolone alla bollitura di una o più zuppe e l’associazione del banco dell’alchimista alla creazione di una o più pozioni; le ricette e le formule necessarie potrebbero essere reperite nei libri o nelle conversazioni con personaggi esperti nelle attività in questione. Magari si potrebbe correlare l’uso del pentolone e quello del banco dell’alchimista per produrre gli spinelli oppure si potrebbe organizzare una nuova sequenza di attività correlate (ad esempio il taglio dei tronchi con la sega da falegname per ricavare delle assi di legno, a cui far seguire la riparazione delle capanne con martello da carpentiere per ottenere il relativo compenso dal proprietario).
Credo anche sia doveroso concedere al protagonista del secondo episodio la più completa procedura di conformazione delle spade che era prevista nel primo ed al protagonista del primo la creazione di più generi di spade che è stata prevista nel secondo.

Alle forme di modifica già citate si possono aggiungere quelle che scaturiscono se si combina l’alterazione delle istruzioni di programma con l’aggiunta di nuovi modelli e relative textures (creati per l’occasione od estratti dai mods amatoriali già esistenti).

Ad esempio, se si reperiscono nuove varianti di teste, si potrebbero assegnare ad alcuni personaggi, per aumentare la varietà dell’insieme o magari per differenziare e valorizzare i personaggi più significativi.
Inoltre, nulla vieta di mutare almeno il volto del protagonista in occasione del suo ingresso nelle gilde maggiori: un noto mod opta per una testa rasata e tatuata in occasione dell’accettazione nella setta, ma si potrebbe imporre anche una folta barba nordica tra i mercenari ed invece baffi e pizzetto spagnoli tra le guardie.
Le fans femminili, invece, saranno probabilmente interessate alla creazione di un’eroina da impersonare in terza persona, in luogo dell’unico modello maschile attualmente offerto dai Piranha Bytes. Basterà reperire i modelli di corpo e testa femminile, associarvi le textures preferite, inserire il tutto tra gli altri files del gioco e prevederne i riferimenti nello script dell’eroina.

Si potranno anche aggiungere nuove armi ed armature, sebbene in questi casi non basterà ridefinire il bagaglio dei personaggi, ma occorrerà anche predisporre gli scripts specificanti nomi e caratteristiche del nuovo armamento. Non bisogna comunque dimenticare che i personaggi principali già dispongono di armi personalizzate almeno nelle statistiche e pertanto potrebbe essere una buona idea quella di accoppiare gli scripts delle armi speciali ai nuovi modelli più elaborati, senza dover intervenire negli scripts dei personaggi.
Qualche variante potrebbe essere predisposta per il vestiario dei ladri, che al momento appaiono troppo uniformati per essere una banda di scapestrati: alcuni potrebbero presentare un fazzoletto verde, altri una borsa nera, altri ancora dei pantaloni di cuoio rossiccio; giusto per sovrapporre un senso di casualità sul grigio cenere dominante (analogamente a quanto avviene per i minatori che già nel gioco originale non presentano un’unica divisa, sebbene su tutti domini il marrone). Invece non ha molto senso prevedere divise differenziate per le guardie dello stesso grado (perché ciò sarebbe in contraddizione con la definizione di divisa); forse i quadri bianchi dei miliziani potrebbero di volta in volta alternarsi a quadri rossi, arancione, viola, marroni, senza perdere la tonalità dominante, mentre per le guardie del primo episodio sarà meglio limitarsi alla sostituzione degli stiletti attuali con delle spade più lunghe.

Nelle righe precedenti mi sono dilungato a proposito della sostituzione dei modelli di elementi di gioco già esistenti nello stesso.
Invece, l’inserimento di nuovi elementi nel gioco (personaggi, animali, piante, oggetti, edifici) e qualsiasi rimodellazione degli ambienti non potranno essere realizzati attraverso le soluzioni spiegate nelle mie guide. Tali ambizioni esigono strategie diverse, atte a modificare i files in formato “.zen” (correlati ad altrettanti macroambienti) e per questo ricorrenti principalmente al programma Gothic Spacer (incluso nel Gothic Mod Development Kit). Per il conseguimento di simili obiettivi è consigliabile l’analisi delle guide e dei video già esistenti in tedesco od inglese; la gran parte è raccolta nella sezione tedesca e nella sezione inglese denominate Gothic Editing Wiki del sito World of Gothic.

Per ottenere i risultati descritti nei paragrafi precedenti, non è necessario avere esperienze nel campo della programmazione; difatti basterà ricercare le righe opportune degli scripts e riscriverle basandosi su semplici considerazioni logiche.

La fase preliminare di ricerca consiste nell’individuare i pochi files di scripts inerenti la modifica, tra oltre un migliaio di files analoghi presenti nel gioco di base e distribuiti ordinatamente in un ampio albero di cartelle e sottocartelle specializzate. Non sarà eccessivamente difficile ritrovare i files degli scripts utili ai propri scopi, sia perché files e cartelle sono contraddistinti da nomi esplicitanti più o meno chiaramente il loro contenuto, sia perché il numero delle sottocartelle è tale che in ognuna sono previste poche decine di files di scripts.
Ad esempio nella cartella STORY/NPC si trovano i files denominati BAU_901_HORATIO.d, EBR_100_GOMEZ.d, GRD_220_GARDIST.d, NOV_1340_NOVIZE.d, ecc.; ognuno di essi contiene i dati (nome, modello, attributi, equipaggiamento, routines) del personaggio a cui fa riferimento.
Invece nella cartella STORY/MISSIONS si trovano i files denominati DIA_BAU_901_HORATIO.d, DIA_EBR_100_GOMEZ.d, DIA_GRD_220_GARDIST.d, DIA_NOV_1340_NOVIZE.d, ecc.; ognuno di essi contiene i dialoghi del personaggio a cui fa riferimento e le condizioni specifiche per la loro enunciazione nel corso dell’avventura di gioco.

I files di scripts sono rappresentati da semplici testi nel linguaggio di programmazione del gioco. Non aspettatevi astruse sequenze di ideogrammi grafici o criptiche stringhe esadecimali o binarie, ma al contrario normali termini di senso comune in tedesco od inglese (od anche italiano, limitatamente alle stringhe destinate ad apparire durante il gioco nella versione italiana); essi appaiono alternati alle sigle sintetizzanti i comandi ed ai consueti simboli matematici e di punteggiatura.
Il testo peraltro è organizzato in paragrafi, capoversi e righe, secondo una rigida struttura gerarchica strettamente legata alle funzionalità codificate; questo significa che risulterà accessibile anche la ricerca delle singole righe da modificare al fine di realizzare i propri obiettivi.

Ovviamente, in questa sede non è possibile illustrare nel dettaglio il linguaggio di programmazione utilizzato in Gothic, ma almeno le modifiche già suggerite sono realizzabili a seguito di sommarie analisi degli scripts analoghi per forma e finalità.

Gli scripts esplicitanti gli attributi di personaggi, animali, armamenti, oggetti, magie, sono evidentemente i più semplici da comprendere e modificare; non credo sia il caso di aggiungere nulla in riferimento all’esempio sottostante.

Altrettanto banali sono gli scripts che disciplinano i dialoghi e, almeno in parte, le quests.

In questi casi sono sempre previste 3 componenti.
Una sezione preliminare specifica il nome che identifica il dialogo, il personaggio interessato oltre l’eroe, la posizione del sottotitolo che attiverà il dialogo alla selezione del giocatore, i nomi che identificano condizioni e contenuti. Normalmente viene anche precisato se il dialogo inizia automaticamente in vicinanza del personaggio interessato (important), se è sempre disponibile (permanent), se attiva determinate conseguenze come la possibilità del commercio con lo stesso personaggio (trade); il consenso e la negazione a tali eventualità vengono espressi rispettivamente attraverso le cifre binarie 1 e 0.
Le condizioni di esistenza del dialogo in generale esigono che nell’avventura si sia già verificato (TRUE) o meno (FALSE) un dato avvenimento e spesso ricorrono a stringhe come “Npc_KnowsInfo”, “Npc_HasItems”, “Npc_GetTrueGuild”; queste evidentemente richiedono che un certo personaggio (normalmente l’eroe) abbia già intrapreso un determinato dialogo o possieda un determinato oggetto (magari un certo quantitativo di monete) od appartenga ad una determinata gilda. Qualora siano necessarie più condizioni contemporaneamente, allora si utilizza la congiunzione “&&”, mentre se è sufficiente una sola condizione tra più alternative si ricorre alla congiunzione “||”; il simbolo “!” esprime la negazione “non”.
I contenuti di un dialogo sono invece esplicitati in più righe, ognuna elencante l’ascoltatore, l’enunciatore, il nome del dialogo di appartenenza, il numero che identifica il doppiatore (15 è il numero associato alla voce dell’eroe), il numero d’ordine della singola frase all’interno del dialogo in oggetto, il sottotitolo correlato.

Il secondo dialogo incluso nell’immagine (finalizzato a concedere la possibilità del commercio con il Signore del Riso) venne tagliato dai Piranha Bytes perché non prevedeva alcuna condizione e conseguentemente poneva dei problemi in relazione alla disputa tra l’eroe e Lefty. La questione potrebbe invece essere risolta imponendo che il dialogo sia disponibile solo dopo la risoluzione della disputa, evidentemente con l’irrisione di Lefty ormai sconfitto o con la sua morte.

Molti scripts sono invece più difficili da interpretare, ma in effetti quanto più sono complicati tanto più probabilmente si riferiscono ad aspetti di base del gioco e su di essi non appare utile o quantomeno conveniente intervenire. Personalmente credo che sia possibile capire, modificare e replicare molto più di quanto serva per la realizzazione di un mod anche complesso.

La difficoltà, almeno apparente, del modding di Gothic non risiede nella ricerca o nell’alterazione delle istruzioni di programma, ma nel rendere queste ultime accessibili all’utenza; difatti, il migliaio di files di scripts in formato Daedalus, quindi con estensione “.d”, nel gioco sono inglobati in una decina di files in un diverso formato, contraddistinto dall’estensione “.dat”. Il modder potrà operare solo sui primi e pertanto occorrerà in primo luogo estrarli dai secondi, poi alterarli ed infine ripresentarli al calcolatore nel formato compatto.
Si tratta quindi di attuare le operazioni di decompilazione e ricompilazione degli scripts. In informatica con il termine “compilazione” si intende l’operazione di conversione unitaria delle stringhe dal linguaggio di programmazione (comprensibile al programmatore, ma non al calcolatore) al linguaggio macchina (comprensibile al calcolatore, ma non al programmatore); la decompilazione è l’operazione inversa. Entrambe le operazioni sono attuabili da appositi programmi, specifici dei linguaggi interessati.

Occorre puntualizzare un aspetto importante delle operazioni di decompilazione e ricompilazione: esse non sono in grado di agire su singoli files, per estrarli e poi reinserirli individualmente negli archivi prestabiliti; piuttosto prevedono l’estrazione in blocco di tutti i files originari di tipo “.d” dal preesistente archivio di tipo “.dat” ed analogamente prevedono la ricompattazione in blocco di tutti i files di tipo “.d” (sia quelli aggiuntivi, sia quelli modificati, sia quelli rimasti allo stato originario) nel pianificato archivio di tipo “.dat”. Tale modalità di azione è del tutto indipendente dal numero dei files estratti (da poche decine a molte centinaia, a seconda dell’archivio prescelto) e dal numero delle modifiche apportate.
L’operazione che invece ammette la conversione individuale dei files, dal linguaggio di programmazione al linguaggio macchina o viceversa, in informatica è indicata con il termine “interpretazione”. La scelta tra i due sistemi di conversione viene presa dal programmatore in funzione di diversi aspetti, indipendenti dalle finalità di questa guida.

Per coloro che intendono creare mods in lingua tedesca (indipendentemente dalla lingua che caratterizza la loro versione del gioco) la procedura è decisamente semplice, in quanto devono esclusivamente provvedere alle 4 fasi di seguito elencate:

1. installazione del modkit ufficiale e conseguente scelta delle componenti del gioco che dovranno essere distribuite immediatamente ed automaticamente, già decompattate e decompilate, in un complesso albero di cartelle e sottocartelle (a partire dalla cartella sede del gioco nel calcolatore dell’utente);
2. alterazione arbitraria del complesso dei files degli scripts ormai nel formato “.d” ed eventualmente di altri files di vario genere (animazioni, modelli, rivestimenti, suoni, voci, ambientazioni) nei rispettivi formati (“.mxx”, “.mrm”, “.tex”, “.wav”, “.zen”);
3. aggiornamento dei files di testo in formato “.src” elencanti i files di scripts destinati alla compilazione, onde comprendere i nomi degli eventuali files di scripts supplementari creati nell’occasione dal modder (in aggiunta ai preesistenti modificati o meno);
4. ricompilazione dell’intero complesso di files risultante, semplicemente al reavvio di Gothic tramite il noto programma denominato Gothic Starter (questa volta scelto nella forma specifica per i modders ed impostato preventivamente con l’opzione di compilazione).

Il Gothic Mod Development Kit non è altro che l’insieme già decompilato dei files degli scripts nella versione tedesca, corredato di alcuni strumenti software; questi ultimi (tra i quali i più importanti sono Gothic Starter, Gothic Spacer e Gothic VDFS) sono tutti finalizzati alla gestione ed alla modifica delle varie componenti del gioco, ma offrono menù e guide interne esclusivamente in tedesco. Il modkit è disponibile nelle sezioni di download del sito World of Gothic, in due versioni distinte: G1 MDK 1.08H e G2 MDK 2.6A, rispettivamente dedicati al primo ed al secondo episodio di Gothic.

Sebbene tale modkit richieda la versione tedesca del gioco, attuando opportuni accorgimenti (già spiegati nella mia precedente guida) si potrà usare con qualsiasi versione. Tuttavia, la disponibilità dei soli scripts tedeschi obbliga il modder ad operare su questi ultimi e pertanto il mod conseguente riprodurrà menù, nomi e sottotitoli tedeschi per tutti i corrispondenti del gioco di base (a meno che non vengano tradotti manualmente uno per uno); questo perché, così come è già stato detto, la fase di ricompilazione includerà tutti gli scripts e non solo quelli aggiunti o modificati nell’occasione.

Durante la fase di compilazione, il programma Gothic Starter provvederà ad analizzare rapidamente gli scripts affidatigli, interrompendo l’operazione al rilevamento di ogni errore. Tale operazione di analisi non è particolarmente scrupolosa in confronto ad altre alternative, ma in ogni caso appare piuttosto snervante, perché in presenza di decine di errori richiede comunque decine di avvii del gioco e quindi della fase di compilazione.

Un ulteriore limite di questa procedura consiste nel fatto che sostituisce gli originali archivi degli scripts nel formato “.dat”, con i nuovi includenti le variazioni apportate dal modder; bisognerà dunque ricordarsi di salvare preventivamente quelli originali (comunque ripristinabili mediante una nuova installazione del gioco).
Tale accorgimento è richiesto solo al modder e non all’utente del mod, perché l’archivio in formato “.mod”, atto alla distribuzione, replicherà tutti gli archivi degli scripts nel formato “.dat”; come è noto, questi ultimi non saranno sovrascritti sui corrispondenti del gioco di base, piuttosto si aggiungeranno ad essi e ne assumeranno il ruolo.

Coloro che intendono creare mods in lingue differenti dal tedesco dovranno agire diversamente da quanto spiegato nel paragrafo precedente, perché la JoWood non ha distribuito alcun modkit multilingue; in effetti occorrerà far precedere la decompilazione degli scripts alla loro alterazione e ricompilazione.

Attualmente Gothic Sourcer è l’unico programma disponibile in grado di completare la decompilazione degli scripts di Gothic ed è forse il migliore nel supportarne visualizzazione, alterazione e ricompilazione. Nella sezione tedesca di download del sito World of Gothic è presente la versione trilingue (russo, inglese, tedesco), contraddistinta dalla sigla 3.10; un tempo era reperibile nel sito degli autori anche una versione aggiornata, contraddistinta dalla sigla 3.14.
Il programma è provvisto di una guida bilingue (russo ed inglese) probabilmente sufficiente per la comprensione di tutte le funzionalità offerte.

La procedura consigliabile nell’utilizzo di tale programma prevede più fasi:

1. definizione degli spazi di lavoro opportuni (a partire da una cartella a discrezione dell’utente), in cui si dovranno insediare alcuni files di supporto alle operazioni ed una copia dell’archivio di scripts in formato “.dat” oggetto delle modifiche pianificate;
2. decompilazione del suddetto archivio, così da distribuire i correlati files in formato “.d” all’interno di un albero di cartelle e sottocartelle che si svilupperà automaticamente nell’area di lavoro precostituita;
3. annotazione degli errori (critici o meno) associati agli scripts e riscontrati dal programma durante la fase di decompilazione;
4. ricompilazione di prova (destinata a non completarsi in presenza di errori critici) del complesso di files precedentemente estratti ed ancora non modificati;
5. annotazione degli errori (critici o meno) associati agli scripts e riscontrati dal programma durante la fase di ricompilazione;
6. correzione manuale degli errori annotati nelle fasi precedenti;
7. alterazione arbitraria delle istruzioni di programma (possibilmente evitando ulteriori errori);
8. ricompilazione finale del complesso di files in formato “.d” (includente quelli aggiunti, quelli modificati e quelli non modificati), così da conformare un nuovo archivio in formato “.dat” destinato a sovrascrivere quello sinora esistente nello spazio di lavoro dedicato;
9. ripetizione della procedura per ogni archivio di scripts che si intende modificare (sebbene normalmente è necessario agire solo sul più vasto tra i pochi esistenti, ovvero GOTHIC.dat).

La strategia appena descritta è evidentemente esente dai limiti che caratterizzano quella tradizionale.
Da una parte permette di operare sugli scripts contenuti nella copia del gioco dell’utente (e quindi nella localizzazione scelta), così come su quelli estraibili dai mods amatoriali già esistenti.
D’altra parte l’individuazione automatica degli errori procede ininterrottamente sino al rilevamento dell’ultimo esistente e non è quindi necessario ripeterla tante volte quanti sono gli errori.
Infine, non occorre prevedere il salvataggio degli archivi degli scripts, perché non vengono sovrascritti gli originali del gioco, bensì le copie replicate in spazi definiti dall’utente.

Gothic Sourcer offre molte funzionalità in aggiunta a quelle appena citate (ad esempio consente la conversione dei files dei modelli in formato “.asc”, “.mdl”, “.mds”, “.msb”, “.mmb”, “.mms”). Lascio all’intraprendenza altrui la scoperta e la sperimentazione di tutte le funzionalità disponibili, perché io preferisco limitarmi alle sole principali.

La prima fase della procedura già accennata esige la definizione dell’area di lavoro, tramite una tabella visualizzabile alla selezione del comando NEW SOLUTION.

La prima riga della tabella dovrà essere completata con il nome del mod pianificato (ad esempio BETTER GOTHIC). Tale nome preceduto dalla radice SOL (in luogo di “solution”) rappresenterà quello della cartella che ospiterà lo spazio di lavoro dedicato.
La seconda riga della tabella è riservata all’indirizzo dell’area di lavoro. Tale indirizzo è a discrezione dell’utente (ad esempio si potrebbe predisporre la cartella GOTHIC/LABORATORIO), ma saranno accettati solo quello suggerito dal programma od altri facenti riferimento a cartelle già costituite.
La terza riga della tabella permette solo la scelta della piattaforma di gioco (Gothic 1 o Gothic 2), a cui faranno riferimento gli scripts oggetto delle operazioni.

A questo punto sarà possibile selezionare l’opzione EMPTY PROJECT e scegliere il nome dell’archivio di scripts che in seguito andrà decompilato (CAMERA.dat, FIGHT.dat, MENU.dat, MUSIC.dat, PARTICLEFX.dat, SFX.dat, VISUALFX.dat o più comunemente GOTHIC.dat). L’avvio del comando imporrà la formazione delle prime cartelle di lavoro e la predisposizione in esse di alcuni microfiles di supporto (tra cui uno in formato “.src”, che elencherà tutti i files di scripts decompilabili dall’archivio in oggetto).
Il passo successivo consiste nella replica dell’archivio di scripts desiderato, presumibilmente dalla sede configurata durante l’installazione del gioco (GOTHIC/_WORK/DATA/SCRIPTS/_COMPILED) a quella appena predisposta (GOTHIC/LABORATORIO/SOL BETTER GOTHIC/PRJxxxxx). Qualora l’archivio utile sia GOTHIC.dat, occorrerà prevedere la stessa sorte anche per il file OU.bin (normalmente alloggiato all’indirizzo GOTHIC/_WORK/DATA/SCRIPTS/CONTENT/CUTSCENE); quest’ultima operazione non è invece richiesta per gli altri archivi di scripts.

Il procedimento sopra descritto è evidentemente sempre attuabile, sia quando le risorse da decompilare sono ordinatamente distribuite nelle cartelle opportune, sia quando questo non avviene (ad esempio perché le risorse sono state estrapolate disordinatamente dalla rete o da mods amatoriali).
Se però si rientra nel primo caso, allora conviene optare per un procedimento più breve: una volta completate le prime 3 righe della tabella, si può selezionare l’opzione FIRST DECOMPILE ACTION ed individuare l’indirizzo dell’archivio di scripts desiderato. L’avvio del comando implicherà in un’unica operazione la formazione delle prime cartelle di lavoro, la predisposizione in esse dei microfiles di supporto e la copia automatica dell’archivio di scripts indicato (e, se necessario, anche del file OU.bin).

Le fasi successive consistono nella decompilazione, secondo quanto spiegato nel paragrafo 9, e nella modifica delle istruzioni di programma, secondo quanto suggerito nei paragrafi 3 e 4.
Qualora la modifica del complesso di files decompilati non si limiti alla sola alterazione di alcuni di essi, ma includa anche la creazione di nuovi supplementari, allora diverrà necessario (prima della ricompilazione) l’aggiornamento del file in formato “.src” (in quanto finalizzato ad elencare al programma tutti i files da ricompilare). L’aggiornamento detto si potrà realizzare ricorrendo all’opzione FIRST COMPILE ACTION e specificando l’indirizzo dell’elenco in questione.

Al termine dell’organizzazione dell’area di lavoro, si potrà provvedere alla decompilazione. Se necessario, bisognerà prima ritornare nella cartella sede delle operazioni, mediante il comando OPEN SOLUTION, e poi riselezionare l’archivio utile degli scripts tra quelli replicati nella cartella di lavoro, mediante il comando SET AT ACTIVE PROJECT. La decompilazione inizierà all’attivazione del comando DECOMPILE ed alla sua conclusione gli scripts risulteranno riuniti in numerosi files nel formato “.d”, a loro volta distribuiti in un complesso albero di cartelle e sottocartelle a partire dalla cartella di lavoro del mod.
Una volta completata la trasformazione del complesso di scripts, si potrà provvedere alla loro compilazione. Per tale operazione valgono le stesse considerazioni fatte per la decompilazione, con la sola differenza che sarà avviabile mediante il comando COMPILE.

Se l’avvio delle operazioni descritte è decisamente elementare, qualche considerazione va aggiunta affinché possano essere portate a termine con successo. In particolare occorre affrontare il tema dell’individuazione automatica degli errori interni agli scripts garantita dal programma Gothic Sourcer (evidentemente per favorire la realizzazione di scripts formalmente corretti).

Gli errori di scripting riconoscibili dal programma non hanno tutti la stessa rilevanza; piuttosto possono essere distinti in 3 categorie principali: errori critici, errori comuni ed errori trascurabili. Questi ultimi sono evidenziati in blu nei registri di decompilazione e ricompilazione, ma sono intesi anche dal programma come ininfluenti nel gioco e pertanto non è necessario correggerli; l’esistenza di simili errori non interromperà il processo di compilazione. Le prime due categorie, invece, includono vari generi di errore evidenziati in rosso negli stessi registri di decompilazione e ricompilazione; almeno quelli critici sono intesi dal programma come probabile causa di bugs o crashes del gioco e pertanto devono essere corretti manualmente uno per uno, altrimenti la compilazione non potrà concludersi.

D’altra parte, la funzionalità descritta è talmente puntuale da rilevare centinaia di errori perfino negli scripts originari dei Piranha Bytes; anche tra questi errori ve ne sono alcuni apparentemente critici.
Ne conseguono due alternative: o tali errori non incidono sul gioco, o generano dei bugs concreti dei quali il giocatore non si accorge. Certamente però gli errori ci sono, almeno dal punto di vista strettamente formale, così come può notare chiunque attraverso pochi raffronti tra scripts analoghi per forma e finalità.

Per quanto detto, diviene necessario annotare le segnalazioni di errore che il programma Gothic Sourcer elenca durante le fasi di decompilazione e ricompilazione, per poi poter provvedere manualmente su ognuno di essi.

Il lavoro di correzione non è impegnativo come si potrebbe credere, per varie ragioni di seguito elencate:

1. ogni segnalazione specifica l’esatto file e l’esatta riga che contengono l’errore individuato;
2. le note di avvertimento sono previste in colore rosso o blu, a seconda della gravità dell’errore, ma soprattutto ne suggeriscono il genere;
3. una guida allegata al programma Gothic Sourcer garantisce il supporto essenziale relativamente ad ogni tipologia di errore riscontrabile;
4. così come appare possibile modificare gli scripts anche senza avere alcuna conoscenza dei linguaggi di programmazione, piuttosto basandosi semplicemente su considerazioni logiche, allo stesso modo (se non con maggiore facilità) si potrà agire in fase di correzione degli errori;
5. una volta intuita la modalità di correzione per una data tipologia di errore, la si potrà replicare identica per tutti gli errori analoghi;
6. le diverse tipologie di errore sono solo poche decine;
7. gli errori critici sono una piccola minoranza.

Ad ogni modo, io ho già tentato di risolvere gli errori segnalati in riferimento al gioco di base e ritengo di aver finalmente trovato la corretta soluzione per tutti. Per quanto non avessi esperienze in simili attività, ho affrontato l’impegno con la massima attenzione, al punto da prolungarlo per oltre una decina di serate di lavoro distribuite nei tempi morti di diversi mesi.
In qualche caso ho potuto dedurre la soluzione semplicemente dalla lettura delle note di avvertimento, rilasciate durante le fasi di decompilazione e ricompilazione; talvolta è bastata l’analisi degli scripts corrispondenti nella versione tedesca (in effetti arricchiti dagli appunti di lavoro dei programmatori, assenti invece nelle versioni localizzate); nella maggior parte dei casi è stato necessario il raffronto con scripts diversi ma molto simili per struttura e finalità; qualche volta ho fatto ricorso a semplici considerazioni logiche. In tutti i casi, però, ho anche ragionato sul senso concreto delle istruzioni e delle correzioni, al fine di avere una riprova del mio operato.

A dir la verità, ho anche cercato ulteriori riscontri tra chi ha esperienze di programmazione, ma ho ottenuto solo pochi consigli generici ad un livello più elementare di quello da me raggiunto.
Purtroppo non si è rivelato utile neppure il raffronto con gli scripts dei pochi mods prodotti con l’ausilio del programma Gothic Sourcer; infatti, buona parte delle correzioni in essi apportate appaiono ancora errate o comunque mai preferibili alle mie.
Mi sono alfine convinto di aver raggiunto delle conclusioni pienamente corrette e pertanto consiglio vivamente il resoconto del mio studio a tutti coloro che sono ancor oggi interessati a modificare le istruzioni dei primi due episodi di Gothic; quantomeno potrà essere un utile strumento per velocizzare e confermare indagini analoghe.

L’intera analisi è sintetizzata in un documento denominato Gothic Error List; esso elenca i nomi assoluti (ovvero esplicitanti il percorso completo tra le cartelle) di tutti i files di scripts riconosciuti come errati in Gothic 1 e 2 (espansione inclusa), insieme all’indicazione delle righe esatte in cui si manifestano gli errori (quasi 300 in totale). I nomi detti sono riordinati in funzione del genere di errore (su un totale di poco superiore a 20), cosicché per ogni genere è stato possibile selezionare uno script tipico, riprodurlo tutto od in parte nel documento, evidenziare la riga errata, premettere la nota correttiva rilasciata automaticamente da Gothic Sourcer, posporre le mie considerazioni e la ragionevole soluzione (replicabile identica su tutti gli errori dello stesso genere).
Gli estratti di riferimento provengono dalla versione inglese del gioco ed in tale lingua sono pure le mie considerazioni; questo perché stilai una prima versione del documento molti mesi fa, quando la proposi in uno specifico thread del forum inglese di World of Gothic, affinché fosse verificata e completata. Tuttavia tali estratti sono in realtà solo i corrispondenti di quelli italiani che furono il vero oggetto dell’analisi.
Il documento descritto è incluso in entrambi i modkits presentati nel paragrafo successivo.

Allo scopo di facilitare la realizzazione di nuovi mods per Gothic 1 e 2, ho predisposto i seguenti strumenti di supporto.

Gothic 1 & 2 Italian Advanced Modkit
L’archivio in oggetto raccoglie il complesso degli script italiani di Gothic 1 e 2 (espansione inclusa), già decompilati, ordinati e corretti nel pieno rispetto di quanto ipotizzato nella Gothic Error List. L’insieme è dunque pronto per essere modificato e poi ricompilato con Gothic Starter o con Gothic Sourcer (in quanto ormai privo degli errori formali).
Evidentemente tale modkit è lo strumento ideale per coloro che non vogliono affrontare personalmente la correzione degli scripts originali del gioco, ma al contempo confidano nell’affidabilità della Gothic Error List e desiderano poter sfruttare la praticità e la scrupolosità di Gothic Sourcer per la realizzazione delle loro modifiche.

Gothic 1 & 2 Italian Standard Modkit
L’archivio in oggetto raccoglie il complesso degli scripts italiani di Gothic 1 e 2 (espansione inclusa), già decompilati ed ordinati, ma preservati nel loro stato originale senza correzioni (salvo pochissime inevitabili perché richieste anche da Gothic Starter). L’insieme è dunque pronto per essere modificato e poi ricompilato con Gothic Starter, ma non con Gothic Sourcer (in quanto non ancora privo degli errori formali).
Evidentemente tale modkit è lo strumento ideale per coloro che dubitano dell’affidabilità della Gothic Error List e pertanto preferiscono affrontare personalmente la correzione degli scripts originali del gioco oppure scelgono di rinunciare alla praticità ed alla scrupolosità di Gothic Sourcer per la realizzazione delle loro modifiche.

Entrambi i modkits sono previsti per la creazione di mods necessariamente italiani; difatti, la ricompilazione e l’installazione degli scripts dei modkits (indipendentemente dal fatto che siano stati sviluppati ed inglobati in un mod o meno) imporranno menù, nomi e sottotitoli italiani almeno sul gioco di base (indipendentemente dalla localizzazione delle copie del gioco installate da modders ed utenti).

Ad integrazione degli scripts del primo volume di Gothic, ho incluso in entrambi i modkits l’archivio TEXTURES_FONT_SPANISH.vdf; esso contiene le tabelle dei caratteri accentati, necessari per replicare in modo corretto i sottotitoli in lingue neolatine. L’archivio è già compreso nelle copie del gioco in italiano, francese e spagnolo, e pertanto i possessori di esse non dovranno preoccuparsi di installarlo; al contrario, è assente nelle copie del gioco in tedesco od inglese ed allora converrà aggiungerlo all’interno della cartella GOTHIC/DATA, altrimenti i mods italiani visualizzeranno i sottotitoli in italiano ma senza gli accenti opportuni.
Evidentemente il modder potrà anche farne a meno, perché se redigerà le stringhe dei sottotitoli con gli accenti corretti, questi ultimi saranno comunque visibili da chi possiede le tabelle in oggetto. Tuttavia converrà che il modder inglobi l’archivio detto nel proprio mod, al fine di non lasciare la ricerca e l’installazione dello stesso all’iniziativa dell’utente; in effetti non sono pochi gli utenti italiani con copie del primo volume tedesche od inglesi.

Una delle applicazioni più interessanti dei temi trattati nella guida è la localizzazione dei mods stranieri. Essa sostanzialmente presuppone la conversione nella lingua desiderata di tutte le stringhe destinate ad essere visualizzate durante il gioco, ovvero menù delle impostazioni, nomi degli oggetti e sottotitoli dei dialoghi; tutto il resto, evidentemente espresso nel linguaggio di programmazione, dovrà rimanere inalterato.
Il programma Gothic Sourcer è in grado di visualizzare le stringhe con colori diversi a seconda del genere; ad esempio le righe rappresentanti i sottotitoli dei dialoghi appaiono in verde, i menù delle impostazioni ed i nomi degli oggetti in rosso, i nomi delle funzioni in blu, le costanti in giallo, quasi tutto il resto in nero.

La strategia migliore per iniziare una simile attività è quella di scegliere un mod di cui già esistano la versione tedesca e quella inglese; il raffronto tra le due permetterà l’individuazione di tutte le stringhe necessitanti della traduzione.
L’imponente total conversion denominata Diccuric è già disponibile in varie lingue, tra cui quella italiana; dunque appare come lo strumento più adatto per il riconoscimento delle diverse tipologie di stringhe. Il mod completo e numerosi suoi complementi sono raccolti nel sito dedicato. Gli scripts italiani non sono stati preparati per l’installazione automatica, ma sono comunque inclusi nella patch inglese e da essa possono essere estrapolati con gli strumenti software ormai noti.

Ovviamente le finalità perseguibili con le diverse localizzazioni di Diccuric sono replicabili anche ricorrendo alle diverse versioni del gioco di base. Tuttavia i relativi scripts non sono reperibili altrettanto facilmente, salvo quelli tedeschi (inclusi, come già detto, nel Gothic Mod Development Kit).

Purtroppo anche il procedimento di localizzazione dei mods stranieri non è esente da complicazioni, come al solito conseguenti all’insolita struttura intrinseca del gioco.
Sia che il mod da tradurre si riveli una total conversion, sia che preveda l’integrazione nel gioco originale, in ogni caso non raccoglierà solo gli scripts aggiunti o modificati per l’occasione dal modder, ma anche quelli non modificati del gioco di base; eventualmente le sole total conversions potranno rinunciare ad alcuni scripts non funzionali ad esse (ad esempio gli scripts che definiscono personaggi e dialoghi del gioco di base). Questo significa che qualunque sia il numero delle variazioni introdotte dal mod, l’insieme degli scripts incluso sarà al solito distribuito in oltre un migliaio di files.
Tali scripts saranno evidentemente tutti nella lingua scelta dal modder ed avranno la priorità su quelli preesistenti, appartenenti al gioco di base nella versione dell’utente; sarà quindi necessario operare sull’intero insieme di scripts in oggetto, altrimenti l’utente perderà la localizzazione del proprio gioco di base per tutto il tempo in cui manterrà attivo il mod.

Attualmente solo pochissimi mods prevedono come allegato distinto le proprie sorgenti (ovvero i files che raccolgono esclusivamente le variazioni apportate dal modder). D’altra parte, non è detto che si riesca ad ottenere tali sorgenti direttamente dagli autori dei mods per diverse ragioni (magari gli autori non sono rintracciabili o non conservano più le sorgenti o non vogliono cederle od altre ragioni ancora).
In assenza delle sorgenti, occorre in primo luogo raffrontare tutti gli scripts del gioco di base con quelli del mod straniero, al fine di individuare una per una tutte le aggiunte e le modifiche. Se è possibile, conviene utilizzare nel raffronto non tanto gli scripts del gioco di base nella lingua in cui si vuole convertire il mod straniero, piuttosto quelli nella lingua dello stesso mod; quindi se si intende convertire un mod inglese in italiano, conviene raffrontare i suoi scripts non con quelli italiani del gioco di base, ma con gli analoghi inglesi.

Una volta note le aggiunte e le modifiche introdotte dal mod, si potranno replicare su una copia degli scripts del gioco di base nella versione localizzata; solo in relazione ad esse dovranno essere previste le traduzioni di menù, nomi e sottotitoli. Il procedimento descritto appare meno faticoso e più sicuro, rispetto all’inverso che prevede invece la sostituzione degli scripts non alterati contenuti nel mod straniero con gli equivalenti localizzati del gioco di base e la successiva traduzione di menù, nomi e sottotitoli delle frazioni esclusive del mod.
Il nuovo gruppo di scripts così conformato potrà a questo punto essere ricompilato e distribuito all’utenza.