Ciao a tutti da parte del team Calalinta!
Abbiamo pensato potesse essere utile ed almeno un po’ interessante parlare un po’ della nostra esperienza riguardo l’unica entry della jam appena conclusasi: Faashado è disponibile su ITCH! Correte a provarlo se non lo avete già fatto!
Abbiamo raccolto un po’ di pensieri e adesso andrò a riportare quanto abbiamo imparato grazie a questa esperienza, prima volta in cui Calalinta vede la collaborazione di tante persone all’interno dello stesso progetto!
DAVCRI (Davide) ha seguito la programmazione in Godot.
Ciao GL! Dato che Stavros ci ha chiesto di scrivere qualcosa sulla gljam04 ho pensato di prendere il progetto e farvi vedere la struttura del nostro bel gattino mummiato.
Chiaramente non è nulla di così complicato da essere “difficile da riprodurre”, ma ci tengo a farlo vedere perché ci ha permesso di avere una buona comprensione del progetto, credo anche per chi metteva le mani su Godot (4.1.1) per la prima volta come Melvin (che magari dirà la sua)!
Questa scena è una versione leggermente semplificata del codice che è stato usato nella jam
Di base la gerarchia di nodi sulla sinistra dovrebbe essere abbastanza intuitiva per capire le responsabilità di ogni nodo, ma andiamo per ordine:
- Player: è un nodo CharacterBody2D che gestisce il movimento e le collisioni. Vedete l’icona della pergamena? Significa che c’è uno script collegato a questo nodo! Lì dentro c’è la logica di movimento.
- CollisionShape2D: definisce la forma di collisione del player (in questo caso un rettangolo)
- PlayerSprite: tutte le sprite animation. Questo nodo viene controllato dallo script collegato al nodo Player (da script è molto facile ottenere riferimenti ad altri nodi)
- PushbackTimer: è un timer che indica la durata dell’effetto pushback dopo aver preso danno da contatto con un nemico
- Life e Mana: sono nodi con degli script per tenere traccia di LP e MP.
Non hanno una rappresentazione grafica ed infatti le barre per vita e mana sono in un’altra scena (“ui_gameplay”) e si aggiornano grazie a dei segnali che vengono emessi da questa scena.
- BandagePlacer: gestisce la benda. In realtà questo non è un singolo nodo ma bensì una scena a sé con diversi sotto-nodi. Il suo contenuto rimarrà un segreto per tutti voi 😛
Ogni nodo è di fatto una feature.
Questa struttura la reputo molto leggibile a colpo d’occhio ed anche facilmente manutenibile. Vogliamo disabilitare una feature? Basta togliere il nodo (oppure disabilitarne il processing, così da non render nulli eventuali riferimenti).
Non sarà in grado di fare 10k raycast query in un singolo frame ma riesce a farmi divertire mentre sviluppo giochi, che non è poco!
Ci tengo a sottolineare che in passato, con poca esperienza con Godot, avrei probabilmente strutturato la scena del Player in questo modo:
Praticamente avrei sovraccaricato lo script del nodo Player con responsabilità per gestire Life, Mana, PushbackTimer, ecc. Sconsiglio di fare questa cosa perché, sopratutto nelle jam, è meglio dare priorità alla leggibilità e alla “rimuovibilità” dei singoli nodi.
MELVIN (Kevin) ha seguito il game design e supportato la programmazione in Godot.
Ciao GL!
Mi accodo a Davcri parlando della produzione e aggiungendo un piccolo feedback.
Premesso che mi sono unito al team di Calalinta all’ultimo momento dopo essere rimasto senza un team, posso considerarmi soddisfatto dei risultati ottenuti e dell’ottimo rapporto che ho avuto con tutti i membri del team.
Principalmente, mi sono occupato del Game Design di Faashado, iniziando con la creazione di High-Level Design Document che avesse l’obiettivo di avvicinarsi il più possibile a un GDD completo.
Nel documento sono state proposte anche soluzioni che, purtroppo, non sono state incluse nella versione finale del gioco a causa di limiti di tempo o sono state scartate.
Una volta completato il pseudo GDD, abbiamo avviato la fase di prototipazione, che ha assorbito la maggior parte del nostro tempo di sviluppo. Durante questa fase, abbiamo esplorato diverse soluzioni per gestire la core mechanic, ovvero il controllo dei colpi. Dopo vari tentativi e l’uso di diversi sistemi di controllo, siamo giunti alla scelta finale che ha soddisfatto tutti.
Dopo aver definito la core mechanic, ci siamo concentrati sul level design, sull’HUD e sul menu, con uno sprint finale nelle ultime due settimane per raggiungere il risultato finale.
Se potessi tornare indietro, apporterei alcune modifiche ad alcuni dettagli di design e dedicherei maggiore attenzione alla parte di level design, che considero la parte più debole.
Come ho già menzionato, nonostante queste considerazioni, sono estremamente soddisfatto di quanto abbiamo realizzato, soprattutto tenendo conto del periodo estivo e del mio primo coinvolgimento con Calalinta.
È importante sottolineare che gran parte della comunicazione è stata basata su testo, ma nonostante ciò il lavoro è progredito senza intoppi, mantenendo un ritmo adeguato.
SPAGHETTI (Pietro) ha seguito il game design.
Ciao Gamelupi!
Faashado è stato un piacevolissimo esperimento di sviluppo in pieno stile Calalinta: scope piccolo, un personaggio simpatico e una certa attenzione nel minimizzare il solito consumarsi del fegato di quando si sviluppa un videogioco.
Ero un po’ spaventato dal collaborare con un altro designer “di ruolo” ma è filato tutto liscio, con produttive discussioni riguardo al gioco e divisione dei compiti, che ahimé non era proprio equo a causa del mio poco tempo a disposizione (Mi spiace! Spero che il mio contributo sia stato comunque utile.)
Da mesi mi sto concentrando su giochi gestionali, lavorare anche solo per poche decine di ore a un gioco action è stata una boccata di aria fresca. Il core di Faashado è primordiale, rischiare di essere colpiti da un nemico per abbatterlo è spassoso sin dal salti sui Goomba di Super Mario. Mi sarebbe piaciuto enfatizzare ancora di più questo aspetto, e chissà, potrebbe esserci l’occasione in un futuro progetto Calalinta… *wink wink*
STAVROS (Elia) ha seguito la grafica.
Ciao a tutta GL ed eccoci con le mie considerazioni sul gioco che abbiamo prodotto a 8 mani per la GLJAM04.
Questa volta mi sono occupato prevalentemente della parte grafica (con qualche supporto da parte di Kevin) e del supporto al team con cori da stadio a suon di ping su Discord.
Inizialmente abbiamo discusso su cosa fare e come farlo, sempre tramite call su Discord, raccogliendo le idee che poi Kevin e Pietro avrebbero concretizzato. Dopo aver buttato giù qualche idea grafica su dei post-it, abbiamo deciso di andare col gatto e l’ambientazione egizia, la quale ci permetteva di integrare narrativamente il tema della jam, Progress Will Make You Weaker.
Avendo i nostri designer maturato concretamente l’idea sono passato alla realizzazione vera e propria degli asset grafici: per arrivare al risultato finale sono state necessarie due iterazioni in quanto la prima tornata di grafica era fatta in fretta e furia. Ogni entità animata del gioco ha sostanzialmente 3 frame (per animazione) i quali alterano di pochissimo la figura in sè restituendo comunque un senso di movimento. Le animazioni per la morte dei nemici sono più lunghe ma era necessario per restituire il senso di liquefazione.
In ultima ho realizzato (a mano, scannerizzato e colorato con GIMP) le schermate narrative per intro, fine livello, gameover e vittoria.
Come unica nota negativa: ho sentito la mancanza, nel gioco finito, di un level design più vario e questo è da imputare sicuramente alla mancanza di tempo dedicato all’attività e alla comunicazione da remoto. In presenza o comunque riservando uno sprint al level design collaborativo sicuramente avremmo ottenuto qualcosa di più interessante.
Organizzando il lungo tempo della jam in “sprint” separati per ambito, abbiamo centrato l’obbiettivo, portando a termine un gioco con un’ambientazione definita, un gameplay che offre varie soluzioni e chiudendo in tempo per la fine della jam.
La prima volta per Calalinta in cui tante persone collaborano assieme completamente da remoto. Una prima volta che fa ben sperare per progetti futuri!
