03 giu 2010

Introduzione

Programmazione | Roguelike

Da adesso, quindi, i miei post riguarderanno in prevalenza lo sviluppo di videogiochi, e nello specifico di roguelike.

Cos’è un roguelike?

Letteralmente, il termine inglese descrive un gioco che presenta una certa somiglianza con Rogue, che viene considerato il capostipite del genere.

I vari successori condividono con Rogue una serie di elementi di base, molti dei quali, più che rappresentare dei cardini, vanno considerati come linee guida, e come tali sono stati soggetti a numerose variazioni:

- Svolgimento a turni alterni tra il giocatore ed il resto del mondo di gioco.
- Interfaccia testuale che utilizza il set di caratteri ASCII per la visualizzazione di tutti gli elementi di gioco.
- Una serie di comandi associata ad una vasta lista di azioni che permettono al giocatore di interagire con l’ambiente circostante.
- Generazione casuale dei livelli, degli oggetti e dei mostri (come minimo), cosa che implica un’elevata rigiocabilità.
- Concept derivato dai GdR, con un’enfasi particolare sull’esplorazione e il combattimento.
- Limitazione o assenza della possibilità di salvare la partita in corso. Nei casi più estremi, permadeath: se il personaggio muore, il file di salvataggio viene automaticamente eliminato.

Da qualche anno nutro per i roguelike una certa passione: a loro ho già dedicato un post in passato, nel quale indico, tralaltro, gli esponenti più caratteristici del genere.

Perchè proprio un roguelike?

Esporre le motivazioni che mi hanno portato a questo punto è un compito che posso assolvere solo parzialmente. Da una parte pesa la mia nascita come videogiocatore, nei primi anni ‘80, e l’assistere all’evoluzione grafica dei giochi. Sono partito, come tanti altri della mia generazione, da un livello di grafica a dir poco minimale, e se trent’anni dopo il mio senso estetico può considerarsi appagato da un livello di dettaglio che tempo fa avrei solo potuto sognare, so istintivamente che devo dare un’occhiata dietro le quinte per capire effettivamente “quanto” gioco c’è. E’ un modo di pensare che ha ricevuto una forte spinta dalla nascita del concetto di modding, nel momento in cui un gioco finisce per essere un’entità unica per venire destrutturato in motore di gioco e plug-in grafico/meccanico/stilistico, ed è lo stesso che applico nell’analisi dello sviluppo dei miei progetti – ma di questo parlerò dopo.

Lasciando stare le considerazioni più intime ed emotive, ci sono anche un paio di fattori decisamente più oggettivi per la scelta di questo genere: ad esempio,la possibilità di trascurare il lato grafico permette di concentrarsi sul cuore del gioco, sulle meccaniche da implementare e sulle interazioni possibili all’interno del gameplay.
Consideriamo inoltre che un gioco a turni permette di organizzare in maniera migliore l’analisi e la reazione del gioco all’intervento del giocatore, in quanto due stati separati che agiscono separatamente. Potremmo paragonare (con qualche lieve attrito) un roguelike ad una partita scacchi, enormemente più complessa, nella quale non ci sono limiti di tempo per scegliere la propria mossa.

Ma più di tutto, programmare per conto proprio è un metodo per fare esperienza, per sperimentare tecniche o soluzioni alternative che magari non è possibile implementare sul posto di lavoro (per chi, come me, lavora pure nello stesso linguaggio), per entrare in uno stato mentale più consono allo sviluppo. Ed alle volte può essere anche rilassante, com’è sempre fare qualcosa che è in linea con i nostri interessi personali.

Scrivi un commento