Entrevista com os criadores – Edição 14: Nintendo Sound Clock: Alarmo – Capítulo 2
28/10/2024
Alguns vídeos e imagens aqui apresentados foram criados durante o desenvolvimento do jogo.
O conteúdo deste artigo foi publicado originalmente em japonês.
Todas as imagens mostram a versão japonesa do produto. O Nintendo Sound Clock: Alarmo está disponível em português do Brasil.
Capítulo 2: Os desafios do desenvolvimento interfuncional
Parece que este projeto foi realizado por criadores de software e hardware que trabalharam em equipa, mas este tipo de colaboração é comum noutros projetos?
Tamori:
Não é comum um criador de hardware assumir a função de diretor de um produto que envolve o desenvolvimento de software, como aconteceu com Akama-san neste caso. Mas, por exemplo, durante o desenvolvimento de Ring Fit Adventure (3), a equipa de software fez alguns pedidos à equipa de hardware, do género: "Gostávamos de criar este tipo de jogabilidade, conseguem dar-nos o hardware adequado?" Mesmo que algumas dessas ideias não cheguem ao público, as equipas do software e do hardware continuam a trabalhar em conjunto para desenvolver produtos.
(3) Software para a Nintendo Switch lançado em outubro de 2019. Um jogo de aventura e fitness em que os jogadores encaixam os comandos Joy-Con no Ring-Con e na correia para a perna incluídos e jogam utilizando o corpo todo.
Ainda assim, o processo de desenvolvimento parece ser completamente diferente do de um jogo normal.
Tamori:
Sim, é completamente diferente. Além disso, neste caso, para além dos criadores de hardware e de software, tivemos também criadores de uma área que liga essas duas, chamada software de sistema. Assim, os três departamentos diferentes uniram forças desde as etapas iniciais do desenvolvimento.
O termo "desenvolvimento" abrange uma variedade de áreas: o desenvolvimento de hardware, que concebe o produto físico e respetivas mecânicas; o desenvolvimento do software de sistema, que controla o sensor de movimento e os dispositivos internos; e o desenvolvimento de software de aplicação, que é necessário para o alarme e o ecrã. As culturas diferem consoante o departamento ou o cargo, pelo que nos debatemos muitas vezes ao nível da formação de equipas, tentando perceber a melhor forma de avançar em conjunto.
Até agora, Tamori-san, trabalhou no desenvolvimento de software e Akama-san no desenvolvimento de hardware. Que desafios enfrentaram, dos vossos respetivos pontos de vista, no codesenvolvimento do Alarmo?
Tamori:
Quando se trata apenas de desenvolvimento de software, os testes dos protótipos podem ser realizados só pelos criadores do software, pelo que, de certa forma, tudo avança muito rapidamente. Mas, quando envolve o desenvolvimento do hardware, como é o caso, é necessário criar o hardware, controlar o sensor e o equipamento interno, executar a aplicação e por aí fora, o que torna o processo de desenvolvimento complexo.
Por exemplo, se o software do sistema não controlar corretamente o sensor, o som de alarme emitido pelo software torna-se instável. Noutra ocasião, poderá atribuir-se a falta de responsividade do sensor a um problema do software do sistema, quando na realidade se deve a uma ligeira alteração no design do hardware.
Akama:
Agora que falamos disso, lembro-me de ter tido dificuldades quando uma ligeira alteração no formato à volta do sensor o tornou menos responsivo. Assumi que fosse um erro do software do sistema, então não consegui descobrir a causa. É particularmente complicado quando não é a nossa área de especialização.
Tamori:
A simples inserção de outra peça ou uma ligeira alteração do material ou do formato pode afetar o seu comportamento. Como o software do sistema e a aplicação tinham de ser modificados de acordo com as alterações ao hardware, acabámos por ter de garantir que partilhávamos todos os nossos processos uns com os outros e que os executávamos em paralelo. Ter de seguir um processo de desenvolvimento completamente diferente do típico jogo foi um desafio do ponto de vista do desenvolvimento do software.
Por outro lado, trabalhar em todas as vertentes do processo de desenvolvimento dentro da equipa – desde o design do hardware até ao software do sistema e ao desenvolvimento da aplicação – foi vantajoso, porque podíamos rapidamente identificar a causa e tomar medidas caso houvesse problemas.
Em contrapartida, o facto de terem enfrentado essas dificuldades na vossa cooperação prova que todos os departamentos foram vitais para o projeto. Akama-san, quais foram alguns dos desafios que enfrentou?
Akama:
Em termos do desenvolvimento do hardware, foi um grande desafio determinar as especificações a partir do zero. As consolas de jogos em que trabalhei até agora tinham certas regras, como o formato do hardware e o número de botões. Mas, desta vez, como não é uma consola de jogos, essas regras não existiam. Foi bastante desafiante decidir as especificações sem qualquer critério, como o tipo e número de botões que seriam necessários.
Ao ouvir os desafios distintos que os criadores do software e do hardware enfrentaram, sinto as diferenças na cultura de cada departamento. Enquanto criadores que trabalharam em aspetos diferentes, houve alturas em que não se conseguiam entender?
Akama:
Foi assim o tempo todo. (Risos.)
Tamori:
O fosso entre as nossas respetivas culturas de desenvolvimento e personalidades levou a um número considerável de... divergências no entendimento. (Ri-se.) De um modo geral, Akama-san e eu somos designers, então usamos palavras abstratas. Mas as expressões vagas são difíceis de compreender para os programadores do software do sistema e para os engenheiros do hardware, que estão habituados a criar coisas com precisão. Se formos ter com eles e lhes dissermos que queremos aumentar a responsividade, eles vão perguntar coisas específicas, como: "Quantos segundos é aceitável?"
Akama:
Ou, se lhes dissermos que queremos que faça boing, os programadores poderão responder: "Defina boing."
Tamori:
Vi oAkama-san a ser interrogado pelos programadores pelo canto do olho e pensei: "Como espera que eles percebam isso, Akama-san?" (Risos.) Tive experiências semelhantes no desenvolvimento de jogos, então sabia, em certa medida, que falar com programadores em termos abstratos não era uma boa estratégia. Mas isso parecia ser algo novo para o Akama-san, então diria que ele teve algumas dificuldades nesse aspeto.
Akama:
A meio do processo de desenvolvimento, comecei a tirar fotografias e a fazer vídeos de mim a adormecer e a acordar, adicionando sons, para explicar como queria que os efeitos sonoros fossem reproduzidos quando me espreguiçava, etc.
Houve alturas em que o desenvolvimento chegou a impasses devido a falhas de comunicação ou diferenças na cultura de desenvolvimento?
Tamori:
Sim. Várias vezes. Sobretudo porque o desenvolvimento teve lugar durante a pandemia de COVID-19. Não poder comunicar de perto teve um grande impacto. A dada altura, estávamos tão bloqueados no desenvolvimento do Alarmo que suspendemos tudo e tirámos uma semana para fazermos o que quiséssemos.
Estavam a criar um despertador, certo? Todos puseram simplesmente isso de lado?
Tamori:
Exatamente. Para estimular a compreensão de todos das características do sensor de movimento, sem estarmos limitados aos despertadores, pedimos aos membros das equipas do hardware e do software que formassem pares e apresentassem ideias livremente. Houve ideias como aproveitar a função de deteção de movimento para recriar "Daruma-san ga koronda" (Daruma-san Caiu) (4) ou tocar música movendo o corpo no ritmo. Foi fascinante ver todas as ideias que surgiram deste processo.
Foi a primeira vez que as equipas de hardware e software trabalharam em conjunto de forma tão próxima no desenvolvimento de um produto que não fosse uma consola ou um jogo, pelo que as coisas nem sempre correram como esperado, chegando por vezes a ficar tensas. Mas esta experiência permitiu-nos redescobrir o gosto pelo desenvolvimento em conjunto e aproximou muito mais as equipas.
(4) Um jogo tradicional popular no Japão, semelhante ao Macaquinho do Chinês. Um jogador é "o escolhido" e fica junto a uma árvore ou a uma parede que serve de base. Os outros jogadores colocam-se numa linha de partida perto da base. Enquanto o escolhido está de costas para os outros jogadores, canta "Daruma-san caiu" e os restantes jogadores aproximam-se o máximo possível. Se o escolhido se virar para os outros jogadores, estes têm de parar e, caso se mexam, serão apanhados pelo escolhido. Se um jogador conseguir tocar nas costas do escolhido sem ser apanhado, os restantes jogadores têm de se afastar o máximo que conseguirem antes de o escolhido contar até dez. Depois, o escolhido dá dez passos, apanha quem estiver ao seu alcance e esse jogador torna-se o próximo escolhido. Se não houver ninguém ao alcance, o escolhido continua a ser o mesmo. O processo repete-se e o jogo continua. (Isto é apenas um exemplo de como se joga. Existem variantes das regras.)
Akama:
Posteriormente, com a melhoria da resposta do sensor de movimento, aproximámo-nos do produto final. Acredito que termos tido tempo para criar vários protótipos livremente, com os membros da equipa a tornarem-se mais próximos de uma forma que transcendeu a profissão ou o cargo, foi fundamental para fazer avançar o projeto.