Disegni con il Domino in Unity 3D

Ispirato da questa combinazione di video (primo e secondo) che per combinazione ho visto in rapida successione, ho deciso di ricreare i mosaici creati dalle tessere del domino che cadono utilizzando Unity3D e il suo motore fisico.

Ho incontrato due problemi: per prima cosa so veramente poco di modellazione 3D, e anche la semplice creazione di una tessera di domino in SketchUp, e la sua esportazione ed importazione in Unity, ha richiesto un tempo imbarazzante.

L’altra cosa su cui ho perso un sacco di tempo è stato il piazzamento della telecamera: idealmente avrei anche gestito i movimenti della stessa, ma la posizione iniziale ha richiesto veramente tanto, anche perché le tessere sono generate in real time e quindi l’ho sostanzialmente dovuta puntare contro uno sfondo bianco.

Importare l’immagine e colorare adeguatamente le tessere del domino, invece, è stato sorprendentemente facile: ho semplicemente creato una texture nella quale ho caricato una immagine quadrata, e quindi sono andato a prendere i colori nei pixel relativi utilizzando Texture2D.GetPixel.

L’animazione praticamente è venuta da se applicando un rigidbody e un collider alle tessere del domino. Ho quindi fatto inclinare la prima tessera di ogni fila in modo da cominciare a far cadere le tessere.

Qui è emerso il problema di ottimizzazione: con 100 tessere funziona tutto a meraviglia, ma con 6700 il tutto cominciava a rallentare mano a mano che le tessere cominciavano a cadere. Il sistema fisico continuava a ricalcolare la posizione delle tessere sostenute su altre tessere andando a rallentare il funzionamento dell’animazione. Per questa ragione ho deciso un tempo arbitrario dopo il quale disabilitare per ogni singola tessera gli effetti della fisica e “congelarla” nella sua posizione finale. Con 2 secondi non si nota alcuna differenza in termini di animazione, e le prestazioni diventano accettabili.

Questo semplice test è un buon inizio per cominciare a tuffarsi nei problemi dell’ottimizzazione della grafica 3D.

Alcuni giochi delle due scorse settimane (27 Novembre)

Già, ho saltato una settimana nella mia consueta rubrica dove vado a spulciare la lista delle nuove uscite su Steam cercando di trovarci qualcosa di interessante. Recuperiamo il tempo perso con una speciale edizione bisettimanale.

SUPERHOT: MIND CONTROL DELETE

Sequel/expandalone di SUPERHOT, l’FPS dalla meccanica rivoluzionaria nella quale il tempo si muove solo mentre il giocatore si muove, questo titolo per il momento rilasciato in early access promette di espandere le meccaniche di base andando anche ad aggiungere la generazione procedurale dei livelli tipica dei giochi Roguelike.

RIOT: Civil Unrest

Un gioco italiano una volta tanto: Riot: Civil Unrest ci porta in piazza per simulare alcune delle principali manifestazioni degli ultimi anni. Basato su eventi reali, dalla TAV a Podemos, questo gioco ci mette nei panni dei manifestanti o dei poliziotti con due stili di gioco molto diversi. La grafica in pixel art è ad un livello meraviglioso, in particolare nei filmati introduttivi. Il gioco è attualmente in early access.

Dream Channel

Chiudo con l’obbligatorio “gioco” VR. Questo è uno strano esperimento ambientato per le vie di una Amsterdam onirica e unisce i classici modelli 3d a dei video live action a 360 gradi. Purtroppo temo che i video 360 non siano il massimo se integrati direttamente, ma mi piace comunque la sperimentazione, trattandosi di un titolo gratuito.

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.

Ludum Dare 40 (Live Blog)

Primo Giorno 2:55 > Inizio da qui il mio live blog del Ludum Dare 40. Siamo a 5 minuti dall’inizio, ovvero da quando verrà rivelato il tema della competizione. Vista l’ora italiana penso che leggerò il tema e andrò a dormire per cominciare con le idee più chiare domani mattina.

Primo Giorno 3:03 > Il tema della competizione è The more you have, the worse it is. Non è tra quelli che avevo preparato in anticipo, ma penso non sia troppo difficile pensare ad una meccanica a difficoltà incrementale. Il primo pensiero per cominciare il brainstorming è “i birilli del giocoliere”.

Primo Giorno 8:34 > Son già sveglio da un paio d’ore e penso di essere riuscito a fare un brainstorming in sogno. Ovvero mi son svegliato con una idea abbastanza particolare per un progetto. Contrariamente al solito questo progetto richiede più parti artistiche rispetto a quelle di programmazione, quindi non proprio il massimo per le mie capacità, ma ho deciso di provarci comunque. Come piccola anticipazione posso dire che questo gioco conterrà dei lootbox.

Primo Giorno 12:00 > Completata una prima fase di prototipo con grafica estremamente temporanea. Ecco la prima parte del gioco: una sorta di RPG. Nel pomeriggio metterò insieme tutti gli elementi del prototipo per vedere se riescono a passare correttamente i valori, e spero prima di sera di avere un prototipo completamente funzionante e cominciare a lavorare sulla grafica.

Primo Giorno 00:17 > Sono a buon punto con la grafica: lo sfondo è una rielaborazione di un quadro di Hokusai mentre il personaggio è una elaborazione di una vecchia foto di un samurai. Qua una immagine. A questo ho aggiunto un effetto per simulare l’alba. Ora manca il nemico e l’animazione, e la seconda parte del gioco.

Secondo Giorno 11:00 > Dopo una notte in bianco ho praticamente completato tutte le funzioni di base. Il gioco (non so in realtà se definirlo gioco o storia) è giocabile dall’inizio alla fine, e tutta l’operazione richiede pochi minuti. Ho cominciato ad aggiungere musica, e qualche effetto sonoro. C’è ancora qualche elemento grafico provvisorio e mancano i testi del finale. Vorrei inoltre aggiungere altri effetti luminosi, in particolare in corrispondenza all’eliminazione dei nemici. Non penso comunque di iscrivere il gioco alla Compo, dato che cominciano ad essere tanti gli elementi non originali.

Secondo Giorno 22:58 > Ci siamo quasi: aggiunto gatti ed effetti luminosi. La parte finale che mi preoccupava è praticamente completa. Ora devo aggiungere qualche immagine e sistemare i testi, e aggiungere la condizione di vittoria. Entro domani dovrei riuscire a completare tutto e pubblicare nella Jam. Il risultato è un gioco/esperienza molto strano, però mi son divertito a programmarlo, e penso sia quello l’importante.