Chiedi allo sviluppatore, Volume 14, Orologio sonoro Nintendo: Alarmo - Capitolo 2
28/10/2024
Alcune delle immagini e dei video di questa intervista mostrano un prototipo del prodotto.
Il contenuto originale di questa intervista è stato pubblicato in giapponese.
Tutte le immagini mostrano la versione giapponese del prodotto. Orologio sonoro Nintendo: Alarmo è disponibile in italiano.
Capitolo 2: Le sfide di uno sviluppo inter-funzionale
A quanto pare, quindi, questo progetto è stato realizzato grazie alla collaborazione di sviluppatori di software e di hardware. Ma questo tipo di collaborazione è normale anche in altri progetti?
Tamori:
Non è comune che uno sviluppatore di hardware ricopra il ruolo di director per la creazione di un prodotto che include lo sviluppo di software, come ha fatto questa volta Akama-san. Ma, per esempio, durante lo sviluppo di Ring Fit Adventure (3) chi si occupava del software fece delle richieste a chi si occupava dell'hardware, come: “Vorremmo creare questo tipo di gameplay. Potete fornirci l’hardware adatto?”. Anche se alcune delle idee non vengono presentate al pubblico, il team del software e quello dell’hardware continuano a lavorare insieme per lo sviluppo dei prodotti.
(3) Software per Nintendo Switch uscito a ottobre 2019. Un software di avventura fitness in cui i giocatori collegano i controller Joy-Con agli accessori inclusi, il Ring-Con e la fascia per la gamba, e giocano utilizzando tutto il corpo.
Ad ogni modo, pare che il processo di sviluppo sia stato completamente diverso da quello di un gioco normale.
Tamori:
Sì, completamente diverso. E inoltre, in questo caso, oltre a sviluppatori di software e di hardware, avevamo anche sviluppatori provenienti da un settore che unisce le due cose, chiamato software di sistema. Quindi tre diversi dipartimenti hanno unito le forze fin dalle prime fasi dello sviluppo.
Il termine “sviluppo” copre una grande varietà di campi: sviluppo hardware, che riguarda il prodotto fisico e i suoi meccanismi; lo sviluppo del software di sistema, relativo al sensore di movimento e ai dispositivi interni; e lo sviluppo dell’applicazione software, necessaria per l’allarme e lo schermo. Il modo di lavorare è diverso in base al dipartimento o alla posizione, quindi spesso abbiamo avuto difficoltà relative alla coesione del team e non è stato facile capire come procedere tutti insieme.
Fino a questo momento, Tamori-san, tu avevi lavorato allo sviluppo di software e Akama-san, a quello dell’hardware. Quali sono state le sfide che avete dovuto affrontare rispettivamente quando avete sviluppato insieme Alarmo?
Tamori:
Quando si tratta solo di software, gli sviluppatori possono fare i test dei prototipi da soli e tutto procede molto velocemente. Ma quando lo sviluppo di hardware è coinvolto, come in questo caso, bisogna prima creare l’hardware, gestire le componenti interne e il sensore, far funzionare l’applicazione e così via. Tutto questo rende il processo di sviluppo molto complesso.
Ad esempio, se il software di sistema non gestisce il sensore nel modo corretto, i suoni emessi dal software diventano instabili. In altre occasioni, si potrebbe ricondurre la mancanza di ricettività del sensore a un problema del software di sistema, quando invece è dovuta a un piccolo cambiamento di design dell’hardware.
Akama:
Ora che lo dici, mi ricordo il problema che abbiamo avuto quando un piccolo cambiamento nella forma dell’hardware intorno al sensore lo aveva reso meno ricettivo. Lo avevo considerato un errore del software di sistema e quindi non riuscivo ad individuarne la causa. È particolarmente difficile se non è il tuo campo specifico.
Tamori:
Anche solo inserire un elemento o cambiare leggermente il materiale o la forma può modificare il comportamento. Dato che il software di sistema e l’applicazione dovevano essere cambiati tenendo conto delle modifiche all’hardware, dovevamo assicurarci di condividere tutti i nostri processi con gli altri e portarli avanti in parallelo. Per il dipartimento di sviluppo del software è stato impegnativo dover seguire un processo completamente diverso da quello di sviluppo di un software di gioco normale.
D’altra parte, lavorare all’intero processo di sviluppo con tutto il team, dal design dell’hardware al software di sistema fino allo sviluppo dell’applicazione, è stato molto utile perché ci ha permesso di individuare rapidamente i problemi e prendere le misure necessarie per risolverli.
Aver dovuto affrontare così tante difficoltà nella collaborazione all’interno del team è la dimostrazione che tutti i dipartimenti erano di vitale importanza per il progetto. Akama-san, quali sono alcune delle difficoltà che avete dovuto affrontare?
Akama:
Dal punto di vista dello sviluppo dell’hardware, è stato molto difficile creare le specifiche da zero. Le console a cui ho lavorato fino a questo momento hanno sempre avuto delle regole precise, come la forma dell’hardware e il numero di pulsanti. Ma questa volta, dato che non si trattava di una console, queste regole non esistevano. È stato piuttosto complicato decidere le specifiche non avendo un criterio da seguire, come ad esempio quali pulsanti servissero o quanti di ogni tipo.
Sentendovi parlare delle diverse difficoltà che gli sviluppatori di software e di hardware hanno dovuto affrontare, percepisco la differenza nel modo di lavorare due dipartimenti. In quanto sviluppatori abituati a lavorare in ambiti differenti, vi è mai capitato di non riuscire a capirvi assolutamente?
Akama:
Sempre. (Ride)
Tamori:
Il divario che c’è tra le nostre rispettive culture di sviluppo e le nostre personalità individuali ci ha portato a... qualche problema di comprensione. (Ride) In generale, Akama-san e io siamo designer e tendiamo a usare parole astratte. Ma i programmatori del software di sistema e gli ingegneri dell’hardware, che sono abituati a creare in modo molto preciso, fanno fatica a capire le espressioni vaghe. Se andiamo da loro e gli spieghiamo come vogliamo migliorare ancora di più la ricettività, loro ci chiedono dele specifiche molto precise, come ad esempio. “Allora, quanti secondi possono essere considerati accettabili?”
Akama:
O se gli diciamo “Fagli fare boing!”, i programmatori ti rispondono “Definisci la parola boing”.
Tamori:
Guardavo di sottecchi quando i programmatori facevano domande ad Akama-san e pensavo: “Come ti aspetti che possano capire quello che dici, Akama-san...?”. (Ride) Ho avuto esperienze simili durante lo sviluppo di giochi, quindi sapevo che utilizzare un linguaggio astratto con i programmatori non era una buona strategia, ma Akama-san non era abituato e credo che per lui non sia stato facile.
Akama:
A metà del processo di sviluppo, ho cominciato a fare foto e video di me stesso quando mi addormentavo o quando mi svegliavo, aggiungevo suoni e li usavo per spiegare come volevo che gli effetti sonori funzionassero quando mi stiracchiavo e così via.
È mai successo che lo sviluppo si arenasse a causa di fraintendimenti o differenze nella cultura di sviluppo?
Tamori:
Oh sì. Più volte. Soprattutto perché lo sviluppo si è svolto durante la pandemia COVID-19. L’impossibilità di comunicare direttamente ha avuto un forte impatto sul nostro lavoro. A un certo punto, eravamo così persi e disorientati nello sviluppo di Alarmo, che ci siamo fermati per una settimana e ognuno si è dedicato a ciò che voleva.
Lavoravate allo sviluppo di una sveglia, giusto? E lo avete semplicemente accantonato?
Tamori:
Esatto. Per rinfrescare la comprensione del sensore di movimento, non necessariamente collegato a una sveglia, abbiamo chiesto ai membri dei team del software e dell’hardware di formare delle coppie e di raccogliere nuove idee. Ci sono state proposte di sfruttare la funzione di rilevamento del movimento per ricreare qualcosa di simile al gioco “Daruma-san ga koronda" (Daruma-san è caduto) (4) o per fare musica muovendo il corpo secondo un determinato ritmo. È stato affascinante vedere tutte le idee che sono venute fuori durante questo esercizio.
Era la prima volta che il team software e hardware lavoravano a così stretto contatto allo sviluppo di un prodotto che non fosse una console o il software di un gioco, quindi le cose non sono andate sempre come ci aspettavamo e a volte la situazione era tesa. Ma attraverso questa esperienza, abbiamo riscoperto la gioia di creare insieme e i nostri rispettivi team si sono avvicinati molto.
(4) Un giocato tradizionale giapponese molto popolare, simile a Un, due, tre, stella! Un giocatore viene scelto come “capogioco” e si deve mettere vicino a un albero o a un muro, e quella è la sua base. Gli alti giocatori si allineano in piedi alla linea di partenza non lontano dal capogioco. Il capogioco si gira e mentre dice ad alta voce “Daruma-san è caduto”, gli altri giocatori avanzano in direzione del capogioco. Quando il capogioco si gira, gli altri giocatori si devono immobilizzare. Se il capogioco, girandosi, li vede muoversi, gli altri giocatori vengono esclusi. Se un giocatore riesce a toccare il capogioco sulla schiena senza essere notato, gli altri giocatori devono scappare via prima che il capogioco abbia contato fino a dieci. A questo punto, il capogioco può muoversi di dieci passi e se riesce a raggiungere uno degli altri giocatori, questo diventerà il nuovo capogioco. Se non riesce a raggiungere nessuno, toccherà di nuovo a lui fare il capogioco. Queste sono le regole del gioco. (Questo è solo una versione del gioco; ne esistono diverse varianti con regole diverse.)
Akama:
Alla fine, con il miglioramento della reattività del sensore di movimento, ci siamo avvicinati al prodotto finale. Credo che avere il tempo di creare liberamente diversi prototipi, consentendo ai membri del team di avvicinarsi indipendentemente dalla loro professione o posizione, sia stata la chiave del successo del progetto.
