Che parta davvero

Un gioco che non si apre non è un gioco. Per qualche giorno il sesto pacchetto per i tester, quello per chi gioca su Linux, è stato esattamente questo: un file che al doppio clic non faceva niente e non diceva perché. Scoprire il motivo è stata la cosa più utile della settimana, e ci ha cambiato il modo di consegnare il gioco.

Un pacchetto che non si apriva

Su Ubuntu il pacchetto non partiva. Doppio clic, niente. Tasto destro, «Apri con…», che offre solo l’archiviatore. Nessun errore, nessuna finestra, nessun appiglio. Il tester lo segnala, e da fuori è indistinguibile da «il gioco è rotto».

Il motivo erano due mine sullo stesso sentiero. La prima: l’archivio era stato preparato da Windows, e Windows non conosce i permessi di Unix, così il file eseguibile arrivava senza il permesso di essere eseguito. Un file che non può essere eseguito, cliccato da un gestore grafico, non fa niente e non lo dice. La seconda: il formato AppImage, quello che avevamo scelto, richiede una libreria che le versioni recenti di Ubuntu non installano più di serie. Due modi diversi di fallire in silenzio, sulla stessa consegna.

La regola che ne è uscita è semplice: un pacchetto Linux non si consegna dentro un archivio fatto da Windows. E il gioco adesso esce in tre formati invece che uno. C’è il .deb, che si installa con un doppio clic e mette la voce nel menu come una qualsiasi applicazione: i permessi li scrive il sistema, e non serve nessuna libreria esterna. C’è ancora l’AppImage, per chi la preferisce. E c’è un archivio .tar.gz che conserva i permessi al suo interno, come rete di sicurezza. Il .deb l’abbiamo installato e avviato su una macchina Linux vera: la finestra si apre a tutto schermo, la copertina compare, la console è pulita. Parte davvero.

Quello che rompe una partita vera

Le due giocate su Linux, una di Leonardo Tomassetti (la voce di William) e l’altra di Mario Trani su uno schermo piccolo, hanno tirato fuori una fila di difetti che a noi, sulle nostre macchine, non si erano mai fatti vedere.

Gli oggetti raccolti restavano in scena. Presa la chiave a cricchetto, la sua voce continuava a comparire sotto PRENDI a ogni ritorno nella stanza, con un rifiuto al posto di un’assenza. È un peccato veniale e insidioso insieme: l’interfaccia offriva un’azione che non esisteva più, e chi gioca perde tempo a ripeterla convinto di aver sbagliato qualcos’altro. Adesso un oggetto raccolto smette di essere un bersaglio, e un contenitore che è stato svuotato smette di annunciare quello che non ospita più.

C’era la teca, che sembrava da prendere due volte perché veniva posata sul banco ma restava nella lista. E c’era un gesto che non serviva a niente: cliccare un oggetto nell’inventario accendeva la cornice e prometteva un comando che nessun verbo eseguiva. Sono state chiuse tutte e due, e la seconda ha rimesso a posto la metà del comando che mancava: prima l’oggetto, poi il verbo, come nelle avventure di una volta.

Da Mario è arrivato un difetto tutto suo, che si vedeva solo scendendo di risoluzione: la notifica di disarmo usciva rimpicciolita, e sempre peggio più lo schermo era piccolo. Il canvas si misurava con lo strumento sbagliato, quello che restituisce la dimensione già ridotta dallo zoom dello schermo, e così si rimpiccioliva una seconda volta. A schermo pieno il difetto era invisibile, ed è per questo che nessuna delle nostre prove l’aveva mai preso.

Simulare uno schermo piccolo

Quel difetto ci ha insegnato una cosa scomoda: provavamo sempre alla nostra risoluzione, e i problemi che nascono altrove restavano nascosti. La capacità di rimpicciolire c’era già, un cursore nelle impostazioni, ma parlava in percentuali, e per provare un monitor da 1366×768 bisognava sapere a mente che è il settantuno per cento.

Adesso, nelle impostazioni video, ci sono quattro schermi pronti: 1600×900, 1366×768, 1280×720, 1024×768. La simulazione è fedele al pixel, non approssimata, perché tutto il gioco vive dentro un piano fisso di 1920×1080 e abbassare la scala riproduce esattamente quello che vedrebbe uno schermo più piccolo. Sta nelle impostazioni e non in un menù nascosto perché serve anche a chi gioca, non solo a noi: «quale schermo sto simulando» è una domanda più chiara di una percentuale.

Lo schermo nero

Poi c’è stato il brutto momento della settimana. Verificando una versione appena fatta, il gioco è comparso nero. Non spento, non in errore: nero, con la console pulita, senza una sola riga da riportare.

Lo schermo del gioco può essere ridimensionato, e in un caso preciso quel ridimensionamento poteva finire a zero, cioè invisibile. Succedeva quando la preferenza di scala salvata veniva confrontata con lo spazio disponibile nella finestra, e la finestra, in quell’istante, riportava zero: minimizzata, o non ancora dimensionata dal sistema. Lo zero vinceva su tutto, e da lì non si tornava indietro nemmeno riavviando. Per chi gioca, di nuovo, indistinguibile da «il gioco non parte», e senza niente da segnalare.

Ci sono due reti adesso. Il tetto sulla scala si calcola solo quando la finestra ha una dimensione vera, e un valore salvato che non ha senso viene ignorato. E la scala, comunque vada, non può più valere zero: questo rimette in piedi anche chi si fosse già ritrovato con lo zero scritto nel salvataggio, senza dover cancellare niente a mano. Era un difetto vecchio di settimane, nascosto in una riga aggiunta per tutt’altro motivo. Trovarlo dal vivo, prima di un tester, è stato un colpo di fortuna che preferiamo non ripetere.

Una build alla settimana

Tutto questo ha cambiato il ritmo. Fino a ieri ogni correzione diventava un pacchetto; adesso i rilievi si correggono appena arrivano, ma i pacchetti si mettono insieme una volta sola, a settimana. Si accumula il lavoro, non i difetti: quando arriva il giorno della consegna il gioco è già a posto da giorni, e si impacchetta una versione cumulativa invece di dieci parziali.

La macchina che assembla i pacchetti, intanto, si occupa del solo Linux, che è la parte che ci faceva perdere tempo; l’installer di Windows si prepara qui, in locale, dove costa meno. Sono decisioni da dietro le quinte, di quelle che non si vedono mai in un gioco finito, ma è il tipo di ordine che decide se un progetto di una persona sola arriva in fondo o si arena.

Rimettere in ordine la stiva

E fuori dal codice, la settimana è servita a rimettere in ordine la stiva. Tutto il materiale di pre-produzione (i documenti di design, le schede dei personaggi, la mappa della nave, i testi) è stato ripreso, riordinato e allineato a quello che il gioco è diventato per davvero, che dopo mesi di lavoro non è sempre quello che i documenti dicevano all’inizio.

Nello stesso movimento sono cominciati a entrare nuovi materiali visivi: schede di riferimento per i personaggi, elementi che serviranno alle prossime fasi. È lavoro che non comparirà nella versione di questa settimana, ma è quello che la rende possibile: un gioco è anche l’archivio ordinato da cui esce.

Una veste nuova

E se leggete queste righe sul sito, avrete notato che ha cambiato faccia. Fino a ieri era verde su nero come tanti; adesso è vestito come il terminale del gioco: lo stesso verde-acqua freddo, un orologio di bordo che scorre in cima, i comandi incorniciati come sulla plancia della Santa Maria. Le parole sono le stesse di prima. È cambiato l’abito, non quello che c’è scritto: si legge tutto come prima, solo che adesso lo si legge da dentro la nave.

Nel frattempo

La settimana ha portato un pacchetto che finalmente si apre e una manciata di difetti in meno, dentro un modo di lavorare più sostenibile. Le partite di Leonardo e di Mario valgono più di dieci prove nostre: ci fanno vedere la nave con occhi che non sanno già dove sono nascoste le cose. Grazie a entrambi — buona parte di questo devlog è merito loro.