Cube Up è un videogioco endless disponibile esclusivamente sulla piattaforma Android, ma in pochi sanno la sua storia.
Lo sviluppo parte nell’Agosto del 2017 da un team composto da amanti del settore videoludico sotto la direzione di una azienda chiamata Hypothetical Games.
Il titolo di questo articolo parla chiaro, inizialmente il gioco è stato strutturato con determinate regole, funzionalità, grandezza e distribuzione, ma quello che è disponibile ora è solo la metà, se non addirittura i 4/10, di quello che sarebbe stato il prodotto se il processo di sviluppo fosse andato secondo i piani.
In questo articolo vorremmo far passare un messaggio molto chiaro: “costruire un software qualsiasi non è facile e non basta la tecnica per poterlo portare a termine”.
Partiamo con ordine.
La realizzazione di un videogioco o di un qualsiasi software parte da un’idea. Questa viene scritta in un determinato documento, che nell’ambito videoludico, viene chiamato GDD (Game Design Document), mentre nella produzione di un software ordinario è chiamato Backlog.
Se il design alla base è errato o non completo, difficilmente il prodotto finale sarà perfettamente fruibile dal pubblico.
Nel caso di Cube Up, il designer incaricato, se pur con poca esperienza all’epoca, è stato capace di redigere un documento con tutte le carte in regola per far sì che il gioco potesse funzionare.
Al tempo tutti i partecipanti al progetto erano all’inizio della loro carriera e purtroppo sono stati sottovalutati certi aspetti, reputandoli semplici e veloci da realizzare. Questo non ha permesso di avere un’idea chiara sulla vera difficoltà del progetto e della sua vastità.
Qualsiasi progetto può essere realizzato, ma con il giusto tempo e con la giusta dedizione. Il tempo stimato per terminalro e pubblicarlo era di circa 4 mesi.
Il problema di un progetto lungo consiste nel resistere alla mancanza di hype, che si genera appena si parte in una nuova produzione.
L’hype può essere paragonato all’adrenalina che ti permette di lavorare senza sosta, con un umore alto e fiducia in te stesso.
Ma quando finisce che cosa succede?
L’hype ovviamente non dura in eterno e dopo molto tempo che si lavoro al medesimo progetto, il cervello non lo reputa più interessante e lo slancio iniziale diventa sempre più complicato da mantenere.
In questa situazione entra in gioco la professionalità del singolo individuo, che gli permette di andare avanti con costanza e qualità nello sviluppo. Purtroppo questa qualità non è per tutti.
Allo scadere della prima deadline alcuni membri del team abbandonano il progetto, lasciando scoperte intere aree di produzione e ovviamente rallentando il tutto.
Per ovviare il problema si è cercato di reclutare altre figure, ma la professionalità non consiste solo nel portare a termine un progetto, ma anche di lasciare una buona documentazione di ciò che si è fatto qualora si decida di lasciare.
La documentazione era inesistente e le figure che entravano si trovavano spaesate, dovendo quindi reiterare le parti fatte per continuare.
Questa situazione si protrae per diverso tempo e alla fine nel team, all’atto pratico, rimangono poche figure di quelle che avevano avviato il progetto.
Nonostante questo abbia provocato grossi problemi sulla pipeline di produzione, perlomeno i membri del team si potevano riunire nella sede a Moncalieri vicino a Torino. In seguto, però, per diverse problematiche, questa venne chiusa e Hypothetical Games morì.
In assenza di una sede fisica, i membri restanti del team decidono di portare avanti il progetto da remoto.
Portare avanti un progetto da remoto è molto più complicato, in quanto se alla base non c’è una buona organizzazione e un feeling adeguato, si rischia di aumentare le tempistiche se non addirittura fallire il progetto.
Nel nostro caso siamo riusciti ad avere un’organizzazione base che ci ha permesso di continuare, ma ovviamente il prolungarsi del progetto ha reso alcune figure restie nel dedicare il proprio tempo come una volta. La situazione ha generato così diversi ritardi.
Dopo mesi di sviluppo in queste condizioni, si è optato di tagliare tutte le funzionalità che non si reputavano necessarie al fine dell’MVP (Minimum Viable Product), cercando di snellire il tutto così da diminuire i tempi di sviluppo.
Per far fronte alle tempistiche, si è deciso di organizzare delle Jam di 48 ore e portarlo così a pubblicazione.
Il sistema sembrava funzionare, ma il malumore e la frustrazione all’interno del team aumentava, causato dal fatto di non riuscire a vedere una data per il delivery.
Per mettere la parola fine o inizio, dipende da come si vuole vedere la situazione, alcune figure del team decidono di dare una data di pubblicazione e di rispettarla costi quel costi.
Alla fine il gioco viene pubblicato il 6 Ottobre 2018 sotto l’azienda MACACO, che si è prestata come publisher dato che un membro del team iniziale è anche uno dei fondatori di questa azienda.
Il gioco pubblicato sullo store è perfettamente funzionante nel suo gameplay e in alcune sue parti cardini, ma è solo l’ombra di quello che doveva essere.
Questa esperienza ha permesso a tutti i membri del team rimasti di crearsi un bagaglio tecnico tale da capire a fondo le vere difficoltà di un processo di sviluppo software. La chiave di un buon prodotto è l’esperienza, che in questo caso non c’era, ma che ci ha permesso di acquisirla nella speranza di non commettere più questi errori in futuro.
Di solito si sente sempre parlare di successi, ma mai di fallimenti. Il fallimento è necessario per migliorarsi e per creare dei successi, quindi ci sembrava giusto, noi di MACACO, raccontare come le nostre esprienze ci abbiamo fatto diventare quello che siamo oggi.