Software libero e minimalismo per uno sviluppo davvero indipendente

Intervento a Zona Warpa 2023

Questo è il testo dell'intervento che tenni a Zona Warpa 2023, nelle tappe di Firenze, Siena, Montelupo Fiorentino e Napoli. Il testo integrale dell'intervento, così come le diapositive e il loro codice ROFF, è rilasciato con la licenza CC0 di Creative Commons. <https://creativecommons.org/publicdomain/zero/1.0/legalcode.it>

Per ulteriori informazioni su Zona Warpa, la festa del videogioco ribelle e itinerante, rimando al sito ufficiale dell'evento. <https://zonawarpa.it/>

Nei limiti permessi dalla legge, ho rinunciato a tutti i diritti d'autore e derivati o connessi su quest'opera. Quest'opera fu pubblicata in Italia nel 2023. In breve, quanto segue è di dominio pubblico.


Introduzione

Partiamo dal seguente presupposto: avete in mente di realizzare un videogioco sovversivo, slegato dalla logica arida del profitto e sognate che possa essere veicolo di cambiamento sociale. L'argomento del gioco non è in esame, però ciò che conta sono i mezzi di cui vi servite. Infatti dobbiamo sempre domandarci cosa comportino i mezzi che impieghiamo, anche se pensassimo che il fine li giustifichi. L'informatica è una disciplina che nasce dalla ricerca militare e che attualmente è asservita in toto al capitalismo. In questo ambito c'è un disperato bisogno di libertà. Abbiamo bisogno sia di giochi indipendenti con un messaggio sociale forte, che di una struttura che faccia crescere tale cultura. Non possiamo affidarci alle ditte che controllano il mondo digitale, perché la loro filosofia distruggerebbe un tale movimento. Basti pensare allo spreco enorme di computer funzionanti, per colpa di un'insensata corsa verso la novità scintillante e superficiale, che non tiene in minima considerazione della disponibilità economica delle persone.

Una cultura equa pensata per durare dev'essere prima di tutto decentralizzata, sia per mitigare la possibile perdita delle informazioni, sia per aumentarne la diffusione e infine per diminuire il potere di chi l'ha ideata. Dal momento che profitto è sinonimo di potere, se vogliamo creare dei videogiochi scollegati dal profitto, dobbiamo scollegare i videogiochi dal potere. Quindi dobbiamo non solo creare videogiochi sovversivi, ma pure condividere la conoscenza di come si creano. Svelando i segreti del mezzo, insegneremo a creare videogiochi senza dover frequentare costosissime scuole di dubbia utilità, che di fatto sono barriere del potere. Coloro che aspirano a far parte del movimento potranno imparare gratis e sul campo, attraverso giochi veri fatti da altri, restituendo così il mezzo al popolo.

Per raggiungere quest'obiettivo propongo di adottare la filosofia del software libero ideata negli anni '80 da Richard Stallman, fondatore della Free Software Foundation e del progetto GNU. Di seguito le quattro libertà fondamentali su cui si poggia questa ideologia.

  1. Libertà di eseguire il programma come si desidera, per qualsiasi scopo.
  2. Libertà di studiare come funziona il programma e di modificarlo in modo da adattarlo alle proprie necessità. L'accesso al codice sorgente ne è un prerequisito.
  3. Libertà di ridistribuire copie in modo da aiutare gli altri.
  4. Libertà di migliorare il programma e distribuirne pubblicamente i miglioramenti da voi apportati (e le vostre versioni modificate in genere), in modo tale che tutta la comunità ne tragga beneficio. L'accesso al codice sorgente ne è un prerequisito.

Lo spirito del software libero è di restituire l'intera branca dell'informatica al proletariato. Io ne parlerò principalmente in relazione ai videogiochi, però vi consiglio di approfondire l'argomento, poiché il dibattito sui diritti digitali e sull'etica informatica è quanto mai attuale e necessario. Dal software libero e dal progetto GNU è nato il sistema operativo GNU/Linux con le sue distribuzioni, come per esempio Ubuntu. L'intero codice sorgente di questo sistema operativo gratuito è pubblico e modificabile da chiunque.

Dovreste aver assimilato abbastanza teoria per passare alla pratica. Ricapitoliamo: avete un'idea per un gioco sovversivo e volete usare dei mezzi che siano anch'essi sovversivi, al fine di creare un ecosistema indipendente dove il vostro messaggio possa crescere; avete pure una basa filosofica alla quale ispirarvi, il software libero.

Ho stilato una serie di passi da compiere per avvicinarci alla meta. Come nelle scale, non dovete considerare i gradini più in alto come i più importanti, bensì come quelli più faticosi da raggiungere. In questo caso l'altezza non è da associare alla fatica, ma alla specificità tecnica del suggerimento. In aggiunta, i miei consigli sono volutamente scollegati tra loro per permettervi di provarli in ordine sparso, a seconda del vostro livello di conoscenza e dello stadio di lavorazione del gioco che volete realizzare.

Iniziamo!

Sapere che GNU/Linux esiste, cos'è e perché è importante

Dopo quanto detto finora, questo passo dovreste averlo già compiuto, a meno che non sia stato un inetto completo. Bene, proseguiamo la scalata.

Distribuire il gioco attraverso negozi che rispettino gli acquirenti

Anzi, per meglio dire, che rispettino le persone, poiché per scollegare i videogiochi dal profitto la soluzione più ovvia è abolirne la vendita, distribuendoli gratis. Tuttavia, nell'ottica di sostenere un processo di cambiamento a lungo termine, è accettabile vendere videogiochi sovversivi; ancora meglio se con un prezzo opzionale a partire da, prendendo spunto dalle donazioni. Di seguito i criteri da valutare quando si sceglie un negozio digitale di videogiochi (e non solo).

  1. Niente DRM, nessun "sistema di protezione". I file si devono poter copiare per archiviarli o inviarli a chicchessia. Dev'essere possibile giocare anche senza connessione Internet.
  2. Possibilità di scaricare il gioco senza un'applicazione specifica di parti terze.
  3. Possibilità di avere un prezzo opzionale o di mettere il gioco gratis.
  4. Salvare il meno possibile delle informazioni sui giocatori, ovvero lo stretto indispensabile. Nel caso di un gioco gratis, ciò significa non salvare alcunché!

Con queste premesse, ecco una classifica di merito di alcuni dei maggiori siti che vendono videogiochi.

  1. itch.io
  2. GOG.com  Non permette il prezzo opzionale e richiede la registrazione per giochi gratuiti.
  3. Steam  DRM, necessita di un'applicazione per scaricare i giochi, non permette il prezzo opzionale e richiede la registrazione per giochi gratuiti.

itch.io gode di un ulteriore vantaggio, ovvero che potete pubblicare il vostro gioco quasi istantaneamente, senza pagamenti aggiuntivi o moduli da compilare. Un'altra opzione che consiglio è la pubblicazione indipendente attraverso la rete. Scaricare un gioco dal sito dell'autore può sembrare démodé, ma è il miglior modo per decentralizzare la distribuzione. Inoltre riduce il numero degli intermediari tra i quali dividere i soldi di un eventuale prezzo. È molto semplice implementare un sistema di pagamento digitale sul proprio sito. Da non scartare sono pure i vettori classici della pirateria, come i protocolli peer-to-peer BitTorrent ed eDonkey. Cercate di non adottare un'unica opzione e di diversificare, per preservare il valore della decentralizzazione della rete. È importante che le comunicazioni sul gioco abbiano un canale preferenziale sul vostro sito, per non dipendere da terzi. Avere un sito è semplicissimo ed è il primo passo verso l'indipendenza digitale.

Provare se il gioco funziona con Wine o Proton

Anche se non avete le risorse per fare una versione GNU/Linux, potete usare Wine per eseguire i programmi di Windows su Linux. Wine non è un emulatore, bensì un programma che trasforma le chiamate alle API di Windows in chiamate per Linux. Proton è una versione modificata di Wine da Valve, per Steam. Wine non dev'essere una scusa per non scrivere del buon codice portabile e multipiattaforma, però può essere una toppa da mettere con la speranza di fare meglio in futuro. Pure se non avete familiarità con GNU/Linux, non costa nulla chiedere a qualcuno che l'abbia se può provare il vostro gioco con Wine e magari consigliarvi per aumentarne la compatibilità. Non escludete gli appassionati del pinguino, perché sono loro che si impegnano per un mondo informatico equo.

Usare strumenti e librerie libere

Di nuovo, anche se non state sviluppando un gioco per GNU/Linux, potete attingere lo stesso alla sua filosofia di base. Per creare il gioco, usate programmi e librerie libere. Quando dico "libere" mi riferisco alle quattro libertà fondamentali di prima. Per esempio, le licenze GPL e MIT (o Expat) sono considerate libere. Quindi i programmi pubblicati con tali licenze sono da ritenersi software libero. Utilizzando questi strumenti contribuirete allo sviluppo di mezzi alternativi più equi, decisamente scollegati dal profitto, e che a lungo andare potrebbero influenzare l'intera industria informatica, come nel caso di FFmpeg.

Usare abitualmente GNU/Linux

Non basta blaterare di libertà, questo sistema operativo libero va provato! Scegliete una qualunque delle distribuzioni di Linux o uno dei BSD e usatelo almeno una volta a settimana. Scoprirete la forza e le differenze di questi sistemi. Non fatevi spaventare da quello che non c'è o è diverso. Apprezzate ciò che c'è e la forza della differenza radicale del paradigma informatico. Gli inglesi dicono «less is more», la mia ragazza dice «si fa meglio con poco». Fate vostro questo motto.

Pubblicare il gioco per GNU/Linux

Dopo averlo usato per un po', questo sistema non dovrebbe spaventarvi più. Pubblicare giochi per GNU/Linux non è difficile, soprattutto con qualche accorgimento. Addirittura tanti motori proprietari e famosi supportano Linux, tra cui l'onnipresente Unity e Unreal. Sebbene un gioco creato con un motore proprietario, quindi chiuso, non sia un passo verso la sovversione del capitalismo videoludico, realizzare una versione del vostro videogioco per GNU/Linux vi metterà a contatto con la sua logica di libertà e contribuirà ad aumentare l'interesse dei giocatori nei confronti di questo sistema, rendendolo ancora più appetibile per gli sviluppatori di videogiochi davvero sovversivi. Mi raccomando, attenti a non fare il contrario: ovvero implementare restrizioni degne delle peggiori console moderne su un sistema operativo libero. Non scoraggiatevi se adesso state lavorando con tecnologie chiuse. Pubblicate il vostro lavoro pure per GNU/Linux, imparate ad apprezzare il suo spirito di libertà e migliorate la prossima volta. Non è troppo tardi: potete imparare un modo diverso per un mondo migliore.

Liberare il codice sorgente del gioco

Finora abbiamo scherzato, ora entriamo nel vivo dell'argomento! Pubblicare il codice sorgente di un gioco con una licenza libera è tra i modi migliori per riprendersi o "ridonare" il mezzo videoludico, scollegandolo dal profitto. Ripeto che con libera intendo una licenza che garantisca le quattro libertà fondamentali di prima. Tra le licenze più famose c'è la GPL, altri preferiscono quella MIT o Expat. La scelta dipende dalle circostanze, perciò adesso non mi soffermerò a cavillare. Pubblicando il codice sorgente permetterete agli altri d'imparare dal vostro lavoro, studiando un prodotto vero e finito, e non un esercizio teorico trovato su un libro. Non voglio sminuire assolutamente i libri d'informatica, sto solo evidenziando il valore dell'esperienza sul campo che si può apprendere in questo modo. Pure il gioco stesso, insieme al suo messaggio sovversivo, ne trarrà beneficio, in quanto diventerà potenzialmente immortale. I videogiochi sono un mezzo collegato strettamente ai dispositivi per cui vengono creati e hanno bisogno di manutenzione per rimanere funzionanti sui computer che verranno. Il codice sorgente libero permetterà alle persone di apprezzare l'opera anche dopo la vostra dipartita, magari facendola funzionare su dei computer che neanche sareste riusciti a immaginare. Ultimo, ma non per importanza, è il vantaggio di dare agli altri la libertà di modificare il codice per creare qualcosa di diverso, nuovo e ancora più strepitoso! Se vogliamo innescare il potenziale sovversivo dei videogiochi, dobbiamo prima di tutto imparare l'azione più sovversiva in una società capitalista, ovvero la condivisione. Condividendo il codice sorgente indebolirete il diritto d'autore, la proprietà privata digitale e il potere derivante dal privilegio, che in questo caso è il privilegio di sapere e poter scrivere codice. Non dovreste preoccuparvi d'intaccare le "vendite" del gioco sovversivo, poiché esistono tanti progetti gratuiti che campano con le donazioni. Tuttavia, se foste davvero preoccupati per l'aspetto economico, potreste attendere qualche anno dalla pubblicazione prima di rilasciare anche il codice sorgente. Al massimo cinque anni, meglio se lo fate dopo uno o tutt'al più due anni. Infine, esiste la possibilità di liberare soltanto la logica del gioco e non i dati, obbligando così chi vuole usare il codice a comprare lo stesso una copia, come fu fatto per i vecchi DOOM. Infatti la battuta «DOOM gira ovunque» deriva proprio dalla possibilità di accedere al codice sorgente. Lo stesso vale per la sua longevità e il gran numero di mod. Detto ciò, vi esorto a essere generosi per davvero, a non fare come id Software, e a liberare il vostro videogioco. Liberate il codice, i dati, la grafica, la musica, tutto! Vedrete che le persone apprezzeranno la vostra generosità.

Usare motori grafici liberi

Questo scalino è un'appendice del punto precedente, per farvi riposare un po' dopo tutti quei paroloni. Vien da sé che se usate un motore grafico chiuso o proprietario, per esempio Unity, serve a poco rilasciare il codice sorgente del gioco. Certo, altri potranno apprendere dal vostro lavoro e saranno in grado di estenderlo, però verrà meno la potenziale immortalità del titolo e l'indebolimento del potere del privilegio. Questi fattori saranno entrambi assoggettati a coloro che detengono il controllo del motore grafico. Anzi, oltre a non indebolire il potere del privilegio, addirittura potreste rischiare di rafforzarlo. Difatti, se il vostro gioco essendo di successo fosse preso come riferimento, potreste aumentare la popolarità del motore grafico proprietario che avete scelto, a discapito di alternative libere ed eque. Godot è un motore multipiattaforma libero, generico, per giochi in 2D e in 3D, che di recente è diventato parecchio popolare.

Siamo arrivati alla terza parte dell'intervento, quella che riguarda come mantenere a lungo termine la libertà ottenuta. All'inizio abbiamo scoperto il software libero e la sua filosofia, dopo abbiamo discusso di come metterla in pratica pian piano, e ora ci troviamo dinnanzi alla sfida di adottare dei comportamenti che ci permettano di resistere alle forze avverse alla libertà. La libertà è intrinsecamente più faticosa della sua assenza, perché richiede un costante mettersi in dubbio e una costante modifica del comportamento per tutelare le nuove minoranze. La libertà è un concetto difficile, per renderlo meno astratto dovremmo parlare di ciò che vogliamo evitare, ovvero un abuso di potere. Per evitare gli abusi di potere dobbiamo dividere il potere, decentralizzandolo. Perciò, per mantenere la libertà informatica e dei videogiochi, dobbiamo avere a cuore la decentralizzazione dei sistemi. Ora vedremo come attraverso il minimalismo possiamo ottenere un risultato pratico ed efficace.

Usare motori grafici liberi e specifici

Sebbene il motore Godot sia un traguardo fantastico, vi sconsiglio di usare motori grafici generici per il vostro gioco sovversivo. Chi scrive software libero spesso ricrea le medesime soluzioni informatiche proprietarie. Con questo approccio si rischia di dimenticare che la progettazione di un programma non sempre è scindibile dalla sua filosofia di sviluppo. Per quanto sia allettante avere un motore grafico libero, multipiattaforma e generico, non dobbiamo sognare che Godot diventi lo standard. In primo luogo perché perderemmo la forza della diversità, che è un pilastro della decentralizzazione; in secondo perché un motore generico è oneroso da mantenere senza una struttura di tipo industriale o capitalista. Vi consiglio di trovare un motore grafico libero e specifico per il genere di gioco che volete creare. Basta cercare un gioco di software libero e modificarlo per le vostre esigenze. L'ideale è che il motore sia facile da mantenere al massimo da tre persone, per far sì che il progetto resti piccolo, indipendente e decentralizzato. Ancora meglio se voi stessi rientrate tra le tre persone, così oltre a creare un gioco sovversivo, aiuterete attivamente altri a creare il loro.

Sviluppare su GNU/Linux o altri sistemi liberi

Ormai ve lo sareste dovuto aspettare... Siate il cambiamento che volete vedere negli altri! Tutto ciò di cui abbiamo discusso sinora non basterà se non siete pronti a cambiare radicalmente le vostre abitudini informatiche. Volete un futuro più giusto, con risorse distribuite equamente? Allora dobbiamo combattere pure nell'ambito digitale, affinché il destino dei dispositivi non sia in mano a un unico ente, ma alle persone. Chiedete degli strumenti, non delle scatole nere le cui potenzialità sono limitate artificialmente da terzi, in funzione esclusiva del loro profitto gigantesco. Sviluppare su GNU/Linux o un altro sistema libero come i BSD vuol dire chiedere un mondo diverso e, nel mentre, dimostrare a chi ci è vicino che tale mondo è possibile. Non solo, dal punto di vista tecnico, sviluppare direttamente su GNU/Linux vi permetterà di supportare più facilmente sistemi "esotici", poiché il sistema stesso vi invita a capire il suo funzionamento e a diventare dei programmatori migliori, più attenti alla qualità del codice e della sua portabilità, semplicemente mettendovi a disposizione il codice sorgente di tutti i programmi sul vostro computer, kernel incluso. Inoltre la struttura delle distribuzioni Linux e dei BSD è modulare, cosa che vi spronerà a seguire tale paradigma, scrivendo codice che più facilmente potrà essere multipiattaforma.

Scrivere il proprio motore grafico

Scrivere un gioco da zero non è un'opzione da scartare. Anzi, avere il vostro motore grafico vi darà la possibilità di cucirvi il processo di lavorazione su misura! Sarà anche un ottimo esercizio, attraverso il quale acquisirete numerose competenze trasversali. Bisogna sfatare il mito che scrivere un motore grafico specifico sia difficile. Uno già fatto può aiutarvi, se non siete pratici di programmazione. Nonostante ciò, una soluzione pensata da altri, soprattutto se generica, può anche rivelarsi un ostacolo. Prima o poi, tutti i nodi vengono al pettine, perciò non pensiate di poterla fare franca senza mettere mano al codice. Che vi piaccia o meno, i videogiochi sono un mezzo collegato ai computer e coi computer si conversa programmando. Cercare di sfuggire a questa logica è illusione pura, o un'ingenua delegazione. Infine, dal momento che non esiste conoscenza che non sia potere, e visto che la riappropriazione del mezzo passa attraverso l'indebolimento del potere mediante la condivisione della conoscenza, mi pare ovvio incentivare i partecipanti al movimento ad acquisire una conoscenza completa sulla faccenda. Senza contare che, scrivendo da soli il motore grafico, sarete in grado di mantenerlo a una dimensione piccola e indipendente, che è fondamentale per la libertà di un gioco sovversivo. È ovvio che ciò non vi esime dall'atto importantissimo di pubblicare il codice sorgente con licenza libera. Un motore grafico fatto in casa, ma chiuso, è piuttosto inutile ai fine della nostra rivoluzione.

Scrivere codice facile da portare e da leggere

Se il gioco sovversivo contiene un messaggio degno di nota, sarà vostra premura e interesse fare in modo che possa girare su più dispositivi possibili. Non basta scegliere un motore multipiattaforma, dovete strutturare il codice sorgente affinché la trasposizione da un sistema operativo all'altro sia indolore. Darò per scontato l'importanza di un codice facile da leggere, però voglio sottolineare questo aspetto ai fini della diffusione della conoscenza. Ecco alcuni consigli, in ordine di onerosità crescente.


1. Provare il gioco sul computer meno potente che avete

Non riguarda strettamente la portabilità del codice, però vi aiuterà a definire un minimo comune denominatore per i requisiti. Vi prego inoltre di non snobbare i PC "vecchi", dite NO allo spreco di componenti elettroniche!

2. Diminuire le linee di codice

È evidente, ma non viene ripetuto abbastanza. Di solito, è più facile comprendere file brevi che lunghi. Lo stesso dicasi della portabilità.

3. Diminuire il numero dei file

Appendice a quanto detto prima: è più facile comprendere la struttura di un programma se non è sparpagliato in migliaia di file. Lo stesso dicasi della portabilità.

4. Evitare la virgola mobile

Non siamo negli anni '80, però un sacco di processori si affaticano coi calcoli a virgola mobile. Soprattutto se avete intenzione di far girare il gioco su dispositivi esotici e vecchi, come le console classiche, state lontani dalla virgola mobile. Niente variabili float, solo int. Una logica a numeri interi è pure più facile da collaudare.

5. Evitare l'accelerazione hardware

Sebbene ormai le schede grafiche siano in quasi ogni PC, non è così per i vecchi portatili o altri dispositivi mobili esotici. Sfruttate pure la potenza dell'accelerazione hardware della GPU, ma non trasformate questa possibilità in requisito. Soprattutto perché le schede video non parlano tutte la stessa lingua. Tra l'altro scrivere un render software, quindi sfruttando solo il processore per disegnare a schermo, vi farà risparmiare la batteria dei dispositivi portatili. Infine, per i giochi di cui stiamo parlando, ovvero piccoli, indipendenti e probabilmente in due dimensioni, non avete bisogno della scheda grafica, al massimo potreste sfruttarla solo in momenti specifici della composizione del fotogramma, tipo l'ingrandimento alla risoluzione nativa dello schermo o per dei filtri applicati sul fotogramma composto.

6. Evitare implementazioni dipendenti da architetture a 64 bit

Quelli che dicono che i 64 bit sono necessari mentono! Scherzo? Non proprio. Uno dei motivi per il passaggio a 64 bit che è avvenuto negli ultimi vent'anni è per aumentare la capacità della RAM oltre i 4 GB. Il software libero e GNU/Linux girano benissimo con soli 4 GB di RAM, però il mondo degli affari è stato troppo pigro e avido per ottimizzare i programmi. Per carità, non buttate via il vostro processore a 64 bit, ma cercate di scrivere codice che non dipenda da esso. Compilate il vostro gioco per 32 bit e distribuite anche quella versione. Insomma non escludete una vasta gamma di processori che il progresso ha dismesso prematuramente. Ad alcuni sembrerà un ragionamento cretino, ma un processore a 32 bit consuma di meno di uno a 64. Del resto è così che va il mondo...

7. Separare la logica dall'implementazione

Non legatevi alla struttura di una determinata API, seguite il funzionamento del vostro codice. Create delle funzioni involucro, di cui farete differire l'implementazione a seconda della piattaforma di compilazione. Per esempio, in C, potete definire un header dove racchiudere la definizione delle funzioni astratte, come una draw_texture, e implementarle nel file col nome dell'API o della libreria che avete scelto, tipo sdl.c o win32.c. Per compilare il vostro gioco su un altro sistema, vi basterà scrivere l'implementazione delle funzioni che si appoggiano alle API. Così il codice sorgente rimarrà incentrato sulla logica del gioco e non sulla struttura della piattaforma di sviluppo.

8. Non dare per scontato una determinata periferica audio

Sarebbe meglio, sia per la portabilità che per l'accessibilità, che il gioco sovversivo funzionasse pure senza audio. Non tutte le periferiche audio sono uguali e in alcuni casi i giocatori potrebbero sentire i suoni in maniera molto diversa da come avevate immaginato. Tenetene conto e fate in modo che l'audio non sia mai l'unico vettore di informazioni. Mi rendo conto che questo suggerimento e gli altri che seguiranno dipendono molto dal genere di gioco che avete in mente, però basta osservare la scena delle demo e dei giochi nuovi per console vecchie per comprenderne la bontà.

9. Non dare per scontato l'accesso al file system

Di nuovo, questo consiglio, che può sembrare anacronistico coi computer di oggi, assume tutto un altro significato quando si sviluppa sui computer vecchi o sulle console. L'accesso al file system non dev'essere dato per scontato sia per il caricamento degli elementi grafici, che per il salvataggio dei progressi. Vi ricordate dei sistemi a password?

10. Non dare per scontato una determinata risoluzione e un rapporto

Questo è più difficile, anzi praticamente impossibile se disegnate gli sfondi per una certa inquadratura, come nelle avventure grafiche. Però, per i giochi in cui l'immagine viene composta attraverso l'assemblaggio di caselle, con un po' d'impegno riuscirete a supporto diverse risoluzioni e rapporti differenti (4:3, 5:4, 16:9, 16:10).

11. Pensare il gioco per risoluzioni basse

Appendice di quanto detto prima: usate la risoluzione più bassa che avete scelto di supportare come riferimento principale per la creazione della grafica e poi, se serve, aggiungete dettaglio. A volte basta un classico 640x480 ingrandito con un'interpolazione lineare. Oppure, se volete scialare, un bel HD (1280x720).

12. Non dare per scontata un'uscita video a pixel

L'ultimo punto è il più estremo, ma non per questo meno valido. Tanti giochi possono funzionare alla grande con interfacce testuali. Si pensi prima di tutto alle avventure testuali, poi ai dungeon crawler, ai roguelike, ai giochi di commercio e agli strategici simulativi. Non solo non avete bisogno di una scheda grafica, potete fare a meno anche della grafica a sprite!


In sintesi, per cercare di scrivere codice facile da portare e da leggere, adottate un approccio modulare, separate la logica dall'implementazione, prevedete diversi casi d'uso e cercate di favorire la facilità d'implementazione rispetto a quella d'interfaccia, tranne quando tale scelta cozza con la leggibilità o il buon senso.

Siamo quasi arrivati in cima alla nostra scala delle libertà digitali per lo sviluppo di videogiochi indipendenti. Manca poco più di un gradino. Non demordete!

Usare linguaggi di programmazione il più indipendenti possibile

Innanzitutto, cosa vuol dire indipendente? Torniamo al discorso sul potere che ho fatto all'inizio. Un linguaggio di programmazione per potersi definire indipendente non deve poter essere controllato da un unico ente. Quindi sorge un'ulteriore domanda, come si esercita il controllo su un linguaggio di programmazione? Il modo più ovvio è stabilendone le regole e l'evoluzione. Se un unico ente chiuso determina la sintassi e le funzionalità di un linguaggio, tale linguaggio non può dirsi indipendente. Un altro modo di controllare un linguaggio di programmazione è d'impedire la creazione di compilatori di terze parti. Il compilatore è quel programma che trasforma il codice da file di testo in binario eseguibile. Se esiste un solo compilatore per un linguaggio di programmazione ed è di fatto impossibile per terzi crearne un altro, allora tale linguaggio non può essere definito indipendente. Se pensate che il mio ragionamento sia una crociata ideologica, ricordatevi dell'importanza di controllare i mezzi di produzione per liberare i lavoratori. Per convertire il mezzo digitale a favore della gente comune è d'obbligo adottare strumenti che non si ritorcano contro chi li usa; quindi mezzi che un'enorme ditta non possa plasmare e limitare a proprio piacimento, per inseguire un profitto sfacciato. Non è fondamentale oggi, in questo momento, abbandonare i linguaggi "non puri", però dobbiamo tenere a mente questo monito quando vogliamo costruire qualcosa di essenziale che duri. Di linguaggi davvero indipendenti per fare videogiochi ce ne sono pochi. Quelli che mi sento di consigliare sono in primo luogo C e C++, anche se quest'ultimo presenta delle complicazioni. Sono da escludersi a priori C# e Java, in mano rispettivamente a Microsoft e a Oracle. Neanche Rust e Go sono da tenersi in seria considerazione, ma adesso non è il momento di scendere in dettagli troppo tecnici. Il mio consiglio è d'imparare C o C++, di usare Lua per i compiti più leggeri o collegati alla logica del vostro gioco, infine Python o shell se avete bisogno di programmini fatti in quattro e quattr'otto per automatizzare un compito noioso.

Consigli per C

Se decidete di utilizzare C come linguaggio di programmazione, vi consiglio di aderire allo standard dell'89/'90 (ANSI) o a quello del '99. Questo consiglio non è mosso da un sentimento nostalgico verso quegli anni, ma dal fatto che quegli standard sono i più diffusi. Perciò troverete un gran numero di compilatori per i sistemi più disparati, se vi atterrete a revisioni del linguaggio passate. Sempre a favore dell'indipendenza del linguaggio, se avete tempo e voglia, provate a compilare il vostro gioco con compilatori diversi dai classici GCC o Visual Studio. Infine, su GNU/Linux e BSD, evitate Autoconf a favore di semplici Makefile con configurazioni differenti scritte come commenti.


Complimenti, siete arrivati in cima alla vetta! Datevi una pacca sulla spalla e riprendete fiato. Permettetemi una sintesi estrema di quanto abbiamo discusso. Rispettate i videogiocatori distribuendo i giochi senza barriere, che siano economiche o tecnico-pratiche mediante registrazioni inutili e dannose per la riservatezza dei dati. Usate programmi liberi, possibilmente su sistemi operativi altrettanto liberi, pubblicando il frutto del vostro lavoro. Lasciate che altri leggano e modifichino il vostro codice sorgente. Rimanete in pochi e mantenete un forte sentimento d'indipendenza. Scegliete strumenti che rispettino la vostra filosofia. Coltivate uno spirito minimalista per soppesare le decisioni da prendere. Se in dubbio, prediligete soluzioni vecchie e rodate alle novità di tendenza, a meno che esse non vi permettano maggiore flessibilità nel lungo termine. E, come per ogni linea guida che si rispetti, non abbiate paura d'infrangere quanto detto prima, se dovete agire a discapito del buon senso.

Bibliografia

Sitografia

Elenchi di giochi liberi:

Come scegliere una licenza libera:

Strumenti per scrivere un motore grafico:

Risorse grafiche e audio libere e gratuite:

Elenchi di programmi liberi e minimalisti:

Ludografia

Contatti