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.
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.
[This article originally appeared on Nintendo UK]
