Ludum Dare 40: Post Mortem

Bene, anche questo secondo Ludum Dare è concluso, e anche questa volta son riuscito a pubblicare qualcosa. Ci hai già giocato? Non è un gioco lungo, giusto un paio di minuti e puoi giocarci direttamente dal browser (ma è richiesta una tastiera, quindi niente cellulari o tablet, temo). Provalo qui, prima di continuare.

Brainstorming REM

In un certo senso si potrebbe dire che l’idea di questo gioco mi sia comparsa in sogno (e penso che si noti fin troppo). Il tema del Ludum Dare è rivelato alle 3 di notte, ora italiana, quindi venerdì ho atteso l’annuncio e quindi sono andato direttamente a dormire pensando alle varie possibili idee, e la fare REM ha fatto il resto mischiando le mie idee con altre più inaspettate. E da qui appunto è venuta fuori l’idea di fare un gioco basato su SPOILER: se non hai ancora giocato, ora svelerò il twist nel gioco. Ultima occasione lootbox e Pachinko.

I lootbox sono stati un tema caldo nelle ultime settimane mentre i pachinko sono qualcosa che ho scoperto qualche mese fa esplorando la collezione di giochi per MAME.

Da quando ho visto il funzionamento del pachinko ho pensato che fosse un tipo di progetto carino da realizzare in Unity, e questo Ludum Dare è stata l’occasione giusta per crearne uno.

I prototipi sono semplici

Il prototipo del patchinco penso abbia richiesto meno di 2 ore: nella prima versione non c’era la condizione di vittoria, grafica, luci, o schermo; c’era solo una fila di palline sparate verso l’alto che ricadevano colpendo alcuni chiodi. La prima parte del gioco è ancora più semplice, ma purtroppo l’ho sottovalutata finendo per creare un codice discretamente confuso.

La progressione della storia

La parte confusa è stata quella di elaborare il modo in cui vengono mostrati i messaggi, e la loro successione. Questa è più o meno la prima volta che provo a scrivere qualcosa di sequenziale, forse a parte il piccolo simulatore di Monty Hall. La confusione è nata perché ho integrato tutta la logica dei messaggi all’interno del game controller, e non ho creato un sistema autonomo che gestisse messaggi e feedback dell’utente. Questo si è tradotto nell’avere una funzione Update molto articolata che conteneva sia i controlli del giocatore, sia i timer, e i controlli dei messaggi. Oltre a questo lo stato del messaggio da mostrare era determinato da un numero al quale corrispondono le azioni, tipo, se accettare o meno i movimenti del giocatore. Anche la collisione con gli avversari è stata gestita male. La lezione qui è: il poco tempo a disposizione in una Jam non deve portarti a scrivere soluzioni sporche e veloci, perché le soluzioni sporche e veloci ti causeranno certamente grattacapi di li a poche ore quando dovrai trasformare il prototipo in qualcosa di completo.

La grafica è difficile

Uno dei grossi problemi con questo progetto è la quantità di grafica richiesta: per la prima parte me la son cavata ritagliando diverse opere d’arte giapponesi e alcune foto, ma per la seconda volevo puntare ad un maggiore realismo, o meglio proprio al fotorealismo, ma non rieadattare delle foto reali di una macchina di pachinko non si è assolutamente rivelato semplice per le mie attuali capacità. La lezione qui è che devo imparare ad usare Gimp, o Paint.net, o altro, e soprattutto devo scegliere quali strumenti utilizzare: ora ho una decina di programmi di grafica e finisco per usarli tutti e 10 per elaborare una singola immagine, perdendo un sacco di tempo e non avendo comunque un risultato buono.

La Parallasse di un quadro

Una delle cose che volevo provare è la creazione di uno sfondo su più livelli sfalsati per simulare la parallasse: anche in questo caso il ci ho messo più tempo a ritagliare le immagini, e in particolare ad immaginare le parti nascoste del quadro, che a scrivere il codice necessario per simulare questo effetto. Sicuramente una tecnica che riutilizzerò in futuro.

Luci e ombre coprono molto bene i difetti grafici

Il trucco che ho trovato per evitare che quel collage di immagini faccia estremamente a pugni con se stesso è stato quello di utilizzare i base color: nella prima parte ho simulato un tramonto: inizialmente doveva essere un’alba, ma ho preferito trovarmi alla fine con il colore più scuro in modo da facilitare la transizione. Per la seconda parte invece ho utilizzato a dismisura le luci colorate: l’effetto è caotico come desiderato, ma nonostante possa considerare accettabile il risultato non posso dire di aver capito ancora come funziona l’illuminazione nel 2D, e in particolare non ho alcuna ombra. Su questo tema dovrò tornarci certamente, magari proprio realizzando una versione “standalone” del pachinko.

Movimenti di camera e nausea

Il piccolo colpo di scena del gioco è effettuato con un movimento all’indietro della telecamera per rivelare che tutta la prima parte del gioco si è svolta su uno schermo di un pachinko: è stato relativamente semplice realizzarla, con qualche piccolo trucco. Per prima cosa ho effettuato un cambio di scena, e nella seconda scena ho inserito uno screenshot dell’ultima immagine visibile nella prima fase, che per questa ragione è sempre uguale. Quel movimento di camera mi è piaciuto così tanto da volerne includere altri: ho programmato uno zoom sullo schermo quando si segna un punto e appare l’immagine del samurai che colpisce il drago, ma poi ho deciso di rimuovere questo effetto. Perché? Nausea. Mi sono accorto che io stesso nella fase di debug e test del gioco ho cominciato a soffrire di chinetosi, e quindi ho commentato tutta questa parte del codice. La lezione qui è: tra i vostri playtester assicuratevi di averne almeno uno che soffra di una leggera forma di chinetosi. I giocatori come me vi ringrazieranno.

La musica è più semplice di quanto pensassi

Certo, il piccolo loop musicale che c’è sotto il mio gioco non è nulla di che, ma l’ho composto e registrato in meno di un’ora utilizzando Bosca Ceoil. Il suono all’apertura dei lootbox invece non è riuscito come speravo: stavo tentando di usare una scala di shepard, ma non è uscita come volevo. Volevo sistemarlo, ma ho preferito dare la priorità ad altri aspetti.

Compilazione e pubblicazione

Compilare e pubblicare il gioco mi ha fatto scoprire che per qualche ragione Unity non la prende bene se cambi il nome del gioco o dell’autore, in corso d’opera. Non so se è un problema legato al mio gioco, o alla attuale versione di Unity o ad altro: semplicemente ho lasciato stare quei due valori e tutto si è compilato correttamente. L’aver lavorato dall’inizio con l’unica risoluzione alla quale è possibile avviare il gioco mi ha salvato da diversi grattacapi che ho avuto nella scorsa edizione. Ho pubblicato senza problemi il gioco su Itch.io e l’ho collegato alla pagina su Ludum Dare, e tutto ha funzionato a meraviglia su questo fronte. Questo è un lato spesso sottovalutato nella produzione amatoriale di videogiochi, ed è una delle per cui si partecipa alle Jam: fino a quando il videogioco gira sulla tua macchina e nel tuo editor va tutto bene, ma prima o poi devi provare a compilarlo e distribuirlo, e il Ludum Dare ti spinge proprio in quella direzione.

Questo può bastare come Post Mortem: in un post successivo tratterò delle modifiche post rilascio che ho fatto in seguito ai feedback dei giocatori, e in generale di quanto siano importanti questi feedback.

Lascia un commento