Ask the Developer Vol. 14, Nintendo Sound Clock: Alarmo – Chapter 2

Some of the images and videos shown in text were created during development.

This article has been translated from the original Japanese content.

All images show the Japanese version of the product. Nintendo Sound Clock: Alarmo is available in English.

Chapter 1: An alarm clock that's out of the ordinary, made by Nintendo

Chapter 2: The challenges of cross-functional development

Chapter 3: Not your average alarm clock

Chapter 4: Establishing a new convention for waking up

Chapter 2: The challenges of cross-functional development

It seems that this project was carried out by software and hardware developers working together as a team, but is this type of collaboration common on other projects?

Tamori:
It’s not common for a hardware developer to take a director role for a product that involves software development, as Akama-san did this time. But for example, during the development of Ring Fit Adventure (3), some requests were made from the software side to the hardware side along the lines of, “We’d like to create this kind of gameplay, but can you provide us with suitable hardware?”. Even though some of those ideas may not be released to the public, the software and hardware teams continue to work together to develop products.

(3) Nintendo Switch software released in October 2019. A fitness adventure game in which players attach the Joy-Con controllers to the included Ring-Con and Leg Strap accessories and play using their whole body.

Even so, the development process seems to be completely different from that of regular game software.

Tamori:
Yes, it’s completely different. On top of that, in this case, in addition to hardware and software developers, we also had developers from a field that connects the two, called system software. So the three different departments joined forces from the initial stages of development.

The term “development” covers a variety of fields: hardware development, which designs the physical product and its mechanics; system software development, which controls the motion sensor and inner devices; and application software development, which is required for the alarm and display. The cultures differ depending on the department or position, so we often struggled at a team-building level, figuring out how to move forward together.

Up to now, Tamori-san, you'd worked on software development, and Akama-san, you'd worked on hardware development. What challenges did you face from your respective standpoints when co-developing Alarmo?

Tamori:
When it's just software development, prototype tests can be done by the software developers alone, so in a sense, everything moves very quickly. But when hardware development is involved, as in this case, you need to create the hardware, control the internal equipment and sensor, run the application, and so on, which makes the development process complex.

For example, if the system software doesn’t control the sensor correctly, it causes the alarm sound emitted by the software to become unstable. On another occasion, you might put the sensor's lack of responsiveness down to an issue with the system software, when it was in fact caused by a slight change in the hardware design.

Akama:
Now that you mention it, I remember struggling when a slight change in the shape around the sensor made it less responsive. I had it pegged as an error in the system software, so I couldn't track down the cause. It's especially tricky if it’s not your area of expertise.

Tamori:
Just inserting another part in between or slightly changing the material or shape can affect its behaviour. Because the system software and the application had to be modified in accordance with changes to the hardware, we eventually had to ensure that we were sharing all our processes with each other and running them in parallel. Having to follow a completely different development process from that of standard game software was a challenge from the software development side.

Conversely, working on the entire development process within the team – from hardware design to system software and application development – was beneficial as we could quickly track down the cause and take measures in case of issues.

Turning that on its head, the fact that you experienced such hardships when co-operating is proof that all departments were vital to the project. Akama-san, what were some of the challenges you faced?

Akama:
In terms of hardware development, it was a real challenge to come up with the specifications from scratch. Game consoles that I’ve worked on until now had certain rules, such as the shape of the hardware and number of buttons. But this time, since it’s not a gaming console, there were no such rules. It was quite challenging to decide the specifications without any criteria, such as what kinds of buttons were necessary and how many of each.

Hearing the distinct challenges that the software and hardware developers faced, I can sense the differences in each department's culture. As developers who’ve worked on different things, were there times when you couldn’t quite understand each other in the first place?

Akama:
It was like that all along. (Laughs)

Tamori:
The gulf between our respective development cultures and personalities led to quite a few...differences in understanding. (Laughs) Relatively speaking, Akama-san and I are designers, so we tend to use abstract words. But fuzzy expressions are difficult to understand for system software programmers and hardware engineers who are used to creating things with precision. If we go up to them and share how we want to improve the responsiveness further, they’ll ask for specifics like, “Well, then how many seconds is acceptable?”.

Akama:
Or if we tell them, “Make it go boing!", the programmers might come back with, “Define boing".

Tamori:
I watched Akama-san being questioned by the programmers out of the corner of my eye thinking, “How on earth do you expect them to understand that, Akama-san…?”. (Laughs) I had similar experiences during game development, so I knew to some extent that talking in abstract terms wasn't a good strategy with programmers, but Akama-san seemed new to it, so I think he struggled a little in that area.

Akama:
Halfway through development, I started taking photos and videos of myself falling asleep and waking up, editing in sound and using it to explain how I wanted sound effects to play when I stretched, and so on.

Were there times when the development came to a standstill because of miscommunications or differences in development culture?

Tamori:
Oh yes. Multiple times. Especially since development took place amid the COVID-19 pandemic, not being able to have close communication had a large impact. At one point, we were so stumped on the development of Alarmo that we put everything on hold and set aside a week to go and make whatever we wanted instead.

You were developing an alarm clock, right? So, everyone just put that aside?

Tamori:
Exactly. To refresh everyone’s understanding of the motion sensor’s characteristics, without being bound to alarm clocks, we asked hardware and software team members to pair up and freely come up with ideas. There were ideas such as leveraging the motion detection function to recreate “Daruma-san ga koronda" (Daruma-san Fell Down) (4) or performing music by moving your body in time with the rhythm. It was fascinating to see all the ideas that came out of this process.

It was the first time anyone had worked so closely together between the hardware and software teams on the development of a product other than game consoles or game software, so things didn’t always go as expected, and it sometimes got tense. But through this experience, we were able to rediscover the enjoyment of developing together and it brought the teams much closer to each other.

(4) A traditional game that is popular in Japan, similar to Red Light, Green Light. One player is “it” and stands by a tree or wall as the base point. Other players stand at a starting line a short distance from “it". While “it” faces away from the other players and chants, “Daruma-san fell down", the other players move as close to “it” as possible. If “it” is facing the other players, the other players need to freeze, and if they move, they will be caught by “it". If a player successfully touches “it” on the back without being noticed, the other players must run as far away as they can before “it” counts to ten. Then, “it” will take ten steps and catch anyone in its reach as the person who will become the next “it". If no one can be caught within that range, the same person becomes “it” again. This is repeated, and the game is played. (This is just one example of how to play; there are several rule variants.)

Akama:
Eventually, with the improvement in the motion sensor’s response, it got close to the final product. I believe that having the time to create various prototypes freely, with team members becoming closer in a way that transcended profession or position, was key to getting the project moving forward.