Pregunta al desarrollador, volumen 14. Nintendo Sound Clock: Alarmo – Capítulo 2

Varios de los vídeos e imágenes que se muestran se crearon durante la fase de desarrollo.

El contenido de este artículo se publicó originalmente en japonés.

Las imágenes muestran la versión japonesa del producto. Nintendo Sound Clock: Alarmo está disponible en español.

Capítulo 1: Un despertador hecho por Nintendo que se sale de lo común

Capítulo 2: Los desafíos de un desarrollo multifuncional

Capítulo 3: Un despertador fuera de lo ordinario

Capítulo 4: Crear una nueva forma de despertar

Parece que este proyecto es fruto de la colaboración entre equipos de desarrollo de software y hardware. ¿Es común este tipo de cooperación en otros proyectos?

Tamori:
No es normal que alguien que se encarga del desarrollo de hardware dirija un proyecto que incluye el desarrollo de software, como ha hecho Akama-san en esta ocasión. Aunque, por ejemplo, durante el desarrollo de Ring Fit Adventure (3), la parte encargada del software hizo ciertas peticiones al equipo encargado del hardware, en plan «Nos gustaría crear un juego con estas características, ¿podéis proporcionarnos un dispositivo que se adapte?». Aunque no siempre esas ideas llegan al mercado, los equipos de desarrollo de software y hardware no dejan de colaborar para desarrollar nuevos productos.

(3) Título lanzado para la consola Nintendo Switch en octubre de 2019. Un juego que combina aventura y ejercicio físico en el que los usuarios acoplan los mandos Joy-Con al accesorio Ring-Con y una cinta que se coloca en la pierna (incluidos con el juego) y juegan usando todo el cuerpo.

Aun así, parece que el proceso de creación de este producto es totalmente diferente al de los juegos al uso.

Tamori:
Sí, es completamente diferente. Además, en este caso, además de equipos de desarrollo de hardware y software, también intervino un equipo de software de sistema, que es un campo que está a caballo entre los dos ámbitos. Así que tres equipos diferentes unieron fuerzas durante las primeras fases del desarrollo.

El término «desarrollo» se aplica a distintos campos: desarrollo de hardware, que se encarga del diseño del dispositivo físico y su funcionamiento; desarrollo de software de sistema, que se ocupa del sensor de movimiento y la mecánica interna; y el desarrollo de software, que se dedica a la programación de la alarma y la pantalla. Cada puesto y departamento tiene su propia forma de trabajar, lo que en ocasiones ocasionaba problemas a la hora de trabajar en equipo y decidir qué rumbo tomar.

Tamori-san, hasta ahora ha trabajado en el desarrollo de software y, Akama-san, en el desarrollo de hardware. ¿Qué desafíos planteó desde cada punto de vista el desarrollo conjunto de Alarmo?

Tamori:
Cuando se trata de desarrollar únicamente software, se pueden hacer pruebas con prototipos solo con el equipo de desarrollo de software, así que, en cierto modo, todo es más ágil. Pero, cuando participa el equipo de desarrollo de hardware, como en este caso, es necesario crear el dispositivo físico, controlar la mecánica interna y el sensor, ejecutar la aplicación, etcétera, lo que dificulta todo el proceso.

Por ejemplo, si el software de sistema no controla correctamente el sensor, hace que el sonido de alarma que emite el programa se vuelva inestable. En otra ocasión, la falta de sensibilidad del sensor se achacó a un problema de programación del sistema, pero en realidad fue causado por un pequeño cambio en el diseño del dispositivo.

Akama:
Ahora que lo dices, recuerdo que un pequeño cambio en la parte que rodea el sensor me dio bastantes quebraderos de cabeza porque le restó sensibilidad. Di por sentado que se trataba de un problema del software de sistema, así que no hubo manera de dar con la causa. Si encima no es tu área de especialización, todo resulta más complicado.

Tamori:
Solo añadir una nueva pieza o cambiar ligeramente la forma o el material puede afectar al comportamiento del dispositivo. Debido a que hay que modificar el software de sistema y la aplicación siguiendo los cambios en el dispositivo, finalmente tuvimos que asegurarnos de compartir todos nuestros procesos con el resto y aplicarlos en paralelo. Tener que aplicar un proceso de desarrollo completamente diferente al de los juegos ordinarios fue un desafío desde el punto de vista del desarrollo de programación.

Por otro lado, trabajar en el proceso de desarrollo al completo dentro del equipo, desde el diseño del hardware hasta la programación del dispositivo y la aplicación, fue beneficioso porque nos permitía detectar rápidamente la causa de los problemas y buscarles solución.

Visto de otro modo, el hecho de que haya habido desafíos a la hora de cooperar es la demostración de que todos los departamentos han hecho una aportación vital al proyecto. Akama-san, ¿puedes darnos algún ejemplo de las dificultades a las que te enfrentaste?

Akama:
En términos de desarrollo de hardware, realmente fue un desafío diseñar las especificaciones desde cero. Hasta ahora, las consolas en las que he trabajado tenían ciertas reglas, como la forma del dispositivo y el número de botones. Sin embargo, en esta ocasión, al no tratarse de una consola, no había este tipo de reglas. Fue complejo decidir las especificaciones sin atenerse a ningún tipo de criterio como qué tipos de botones se requerían y qué cantidad de cada.

Oyendo los diferentes desafíos a los que se han enfrentado los equipos de software y hardware, puedo notar las diferencias entre las culturas de cada departamento. Como desarrolladores que habéis trabajado en cosas diferentes, ¿ha habido momentos en los que simplemente no os entendíais el uno al otro?

Akama:
Así fue todo el rato. (Risas)

Tamori:
La diferencia entre nuestras respectivas culturas de trabajo y nuestras personalidades dio lugar a ciertos... malentendidos. (Risas) Relativamente hablando, Akama-san y yo somos diseñadores, así que tendemos a usar palabras abstractas. Pero las expresiones vagas son difíciles de entender para los programadores de sistema y los ingenieros de hardware, que están acostumbrados a crear cosas con precisión. Si nos dirigimos a ellos para decirles que queremos mejorar más aún la capacidad de reacción, nos preguntarán cosas específicas, como «Vale, ¿cuántos segundos sería aceptable?»

Akama:
O, si les decimos «Queremos que haga ¡boing!», los programadores nos responderán con un «Define boing».

Tamori:
Alguna vez vi de reojo a Akama-san respondiendo a preguntas de los programadores y pensé, «¿Cómo diantres quieres que entiendan eso, Akama-san?...». (Risas) Me han pasado cosas parecidas durante el desarrollo de juegos, así que más o menos sabía que hablar en términos abstractos no era la mejor estrategia con los programadores. Akama-san no parecía estar al tanto, así que creo que en ese sentido le costó un poco.

Akama:
A medio camino del desarrollo, empecé a hacer fotos y vídeos de mí mismo yendo a dormir y despertando para luego insertar audio y usar ese material para explicar cómo quería que fuesen los efectos de sonido cuando me estirase y demás.

¿Hubo momentos en los que el desarrollo llegó a un punto muerto debido a los malentendidos o las diferencias entre culturas de desarrollo?

Tamori:
Ya lo creo. Varias veces. Especialmente porque el desarrollo coincidió con la pandemia de la COVID-19. El no ser capaces de comunicarnos cara a cara tuvo un gran impacto. Llegado cierto punto, estábamos tan saturados por el desarrollo de Alarmo que lo dejamos todo en suspenso y nos dimos una semana para hacer cualquier otra cosa que quisiéramos.

Estabais creando un despertador, ¿no? ¿Y todo el mundo lo dejó en suspenso?

Tamori:
Exacto. Para refrescar el concepto que teníamos todos de las características del sensor de movimiento, sin ceñirnos a los despertadores, les pedimos a los miembros de los equipos de hardware y software que formaran parejas y aportaran ideas con total libertad. Hubo ideas como usar la función de detección de movimiento para hacer una versión del juego infantil «Daruma-san ga koronda» (4) o reproducir música al mover el cuerpo siguiendo el ritmo. Fue fascinante ver la de ideas que surgieron de este proceso.

Fue la primera vez que los equipos de desarrollo de hardware y software trabajamos tan de cerca en el desarrollo de un producto que no fuese una consola o un juego, así que las cosas no siempre fueron como se esperaba y a veces surgieron tensiones. Sin embargo, gracias a esta experiencia, fuimos capaces de redescubrir los placeres de crear cosas juntos y logramos acercar mucho a los equipos.

(4) Juego tradicional japonés similar al «escondite inglés». El jugador que la lleva se coloca junto a un árbol o pared que hace de base. Los demás jugadores se colocan tras una línea a no mucha distancia de la base. Mientras el jugador que la lleva mira en dirección contraria a los demás jugadores y canta «Daruma-san ga koronda» (Daruma-san se cayó), estos aprovechan para acercarse a la base todo lo que puedan. Cuando el jugador que la lleva mira a los demás, estos tienen que quedarse quietos. Si los ve moverse, quedan prisioneros. Si alguien consigue tocar la espalda del jugador que la lleva sin caer prisionero, los demás deben alejarse todo lo que puedan mientras el jugador que la lleva cuenta hasta diez. Entonces, el jugador que la lleva debe dar diez pasos para intentar atrapar a otro jugador, que será el siguiente en llevarla. Si no logra alcanzar a nadie, la misma persona deberá llevarla de nuevo. La misma mecánica se repite una y otra vez. (Este es solo un ejemplo; existen múltiples variantes de las reglas.)

Akama:
Finalmente, gracias a la mejora de la capacidad de respuesta del sensor, nos acercamos al producto definitivo. Creo que la clave para sacar adelante el proyecto fue disponer de tiempo para crear varios prototipos libremente y hacer que los miembros de los equipos creasen vínculos con independencia de sus puestos.

Continuar al capítulo 3: Un despertador fuera de lo ordinario