{"id":47516,"date":"2025-04-29T12:09:59","date_gmt":"2025-04-29T03:09:59","guid":{"rendered":"https:\/\/automaton-media.com\/en\/?p=47516"},"modified":"2025-05-19T18:12:01","modified_gmt":"2025-05-19T09:12:01","slug":"how-do-like-a-dragon-games-come-out-so-fast-one-of-rgg-studios-secrets-is-a-highly-efficient-testing-and-debugging-cycle-that-starts-as-soon-as-development-does","status":"publish","type":"post","link":"https:\/\/automaton-media.com\/en\/interviews\/how-do-like-a-dragon-games-come-out-so-fast-one-of-rgg-studios-secrets-is-a-highly-efficient-testing-and-debugging-cycle-that-starts-as-soon-as-development-does\/","title":{"rendered":"How do Like a Dragon games come out so fast? One of RGG Studio\u2019s secrets is a highly efficient testing and debugging cycle that starts as soon as development does"},"content":{"rendered":"\n

SEGA\u2019s Like a Dragon<\/strong> series, developed by RGG Studio, is known for its expansive games and rapid release schedule. To maintain this scale and speed of development, efficient testing and debugging are a must. In many game development cycles, testing and debugging typically take place during the final stages, after or right before all the game\u2019s content has been made. However, at RGG Studio, these processes begin early on in development and run in parallel with game production. This approach allows the team to keep up their rapid pace without compromising quality. <\/p>\n\n\n\n

How is this possible? The key lies in the studio\u2019s extensive use of test automation, a technology refined over the years at SEGA. AUTOMATON spoke with SEGA\u2019s quality engineers Naoki Sakaue, Yuto Namiki, and Kazuto Kuwabara, who specialize in test automation and quality assurance, to get a better idea of their approach to automated testing. <\/p>\n\n\n\n

\u2500Please introduce yourselves.<\/strong> <\/p>\n\n\n\n

Yuto Namiki (hereafter Namiki):<\/strong> 
I\u2019m Namiki from Sega\u2019s 1st<\/sup> Development Division. I joined the company in 2016, so it\u2019s my ninth year here. I\u2019ve been a part of RGG Studio ever since, and I was a programmer for Yakuza 6: The Song of Life. After gaining experience in programming various gameplay systems, I was assigned to the Super Monkey Ball series as a UI and localization programmer. For the latest title in the series, Super Monkey Ball Banana Rumble, I joined the quality engineering team. <\/p>\n\n\n\n

\"Yuto<\/figure>\n\n\n\n

Kazuto Kuwabara (hereafter Kuwabara):<\/strong> 
I\u2019m Kuwabara from Sega\u2019s 1st<\/sup> Development Division. I\u2019ve been with the company for seven years, since 2018. Like Namiki, I initially joined as a game programmer, and I was involved in the development of Yakuza: Like a Dragon and Lost Judgment, mostly overseeing the adventure parts and minigames. Since then, I\u2019ve gradually become involved in quality engineering tasks, becoming the quality engineering team leader for Like a Dragon: Infinite Wealth. <\/p>\n\n\n\n

\"Kazuto<\/figure>\n\n\n\n

Naoki Sakaue (hereafter Sakaue):<\/strong> 
I\u2019m Sakaue, part of the Development Technology Division that provides technical support for SEGA Group. I joined the company back in 2004, so I\u2019ve been here for twenty years already (laughs). At the start, I was also a game programmer, working on the Let\u2019s Make a Soccer Team! series and other projects. I\u2019ve been involved in the Like a Dragon series\u2019 development since Yakuza 3. Initially, I wasn\u2019t involved in test automation, but things like stage rendering and researching in-game day and night transitions. The research I handed down became the foundation for the seamless time progression implemented in Infinite Wealth\u2019s Dondoko Island. <\/p>\n\n\n\n

Now, I\u2019m focusing on the implementation of automated testing in all SEGA titles as part of the Development Technology Division. <\/p>\n\n\n\n

\"Naoki<\/figure>\n\n\n\n

What is test automation?<\/strong> <\/h2>\n\n\n\n

\u2500Let\u2019s start from the basics: What is test automation?<\/strong> <\/p>\n\n\n\n

Sakaue:<\/strong> 
This might get a bit long, but allow me to explain. In game development, we have two processes called testing and debugging. Testing involves creating a plan of what to test in a game based on its specifications, and testing (playing) the game based on that plan to discover bugs. The bugs are reported and then verified after they\u2019re fixed. What I\u2018ve described so far is the job of a QA tester. <\/p>\n\n\n\n

Debugging, on the other hand, involves investigating the causes of discovered bugs and fixing them. This is the job of the development team, primarily the programmers.  <\/p>\n\n\n\n

That brings us to test automation \u2013 this is the process of automating tasks related primarily to the \u201ctesting\u201d process I just described. The image below might give you a good idea of what I\u2019m talking about. <\/p>\n\n\n\n

\"Automated<\/figure>\n\n\n\n

Moreover, at RGG Studio, we go beyond the scope of automated testing and automate the entire development environment. This includes automated packaging*, which we do from the early stages of development onwards.  <\/p>\n\n\n\n

*Packaging in game development refers to the process of compiling all data required to run the game.<\/em> <\/p>\n\n\n\n

\"Test<\/figure>\n\n\n\n

Going a step further from automated packaging, we\u2019ve also automated the process of setting up the testing environment and installing packages needed for testing. Automated testing itself tends to be what people focus on, but we also automate the process of setting up a testing plan, as this is actually the more demanding part of the testing process. Although, in our lectures, people are always the most impressed when they see the game being played automatically (laughs). <\/p>\n\n\n\n

\u2500That reminds me, you gave a rather memorable lecture at CEDEC 2020 (via <\/strong>Famitsu),<\/strong><\/a> where you introduced an almost fully automated bug tracking system. Since when have you been researching automated testing?<\/strong> <\/p>\n\n\n\n

Sakaue: <\/strong> 
Since quite a long time ago. At first, we only dabbled in automated packaging and automated error detection, but we made the tools we needed to go further during the development of Yakuza 6, when we started automating the analysis of in-game logs and the issue tracking system for keeping track of bugs and tasks. Then, by the time Yakuza: Like a Dragon was released in 2020, we created the catchy sounding \u201cfully automated bug detection system\u201d (laughs). <\/p>\n\n\n\n

This is how it works \u2013 the history of actions you performed when playing the game manually (where you travelled, who you talked to, what items you used, etc.) is converted into commands and recorded, then automatically output as replay data (scripts) which you can edit manually and run as automated tests. Replay data continues to be recorded when running automated tests, and if a bug occurs during an automated test, the replay data gets saved, so you can run it back later to encounter the bug yourself. It often happens that you can\u2019t reproduce a bug just by warping to its coordinates. This is because you also need to recreate the steps leading up to it \u2013 that’s why it’s important to record each step. <\/p>\n\n\n\n

Also, I\u2019d like to mention that just implementing automated testing doesn\u2019t mean much on its own, because you won\u2019t know what the results of the tests are. That\u2019s why we needed a crash report function to detect bugs. There\u2019s also a function that records information needed to investigate detected bugs, as well as a way to check the status of successful tests. Then, by implementing a system that gives us a visualization of performance, we were able to make iteration* more efficient, increasing the overall efficiency of the development process. <\/p>\n\n\n\n

*Iteration in software development refers to performing repetitions of a specific test over a short period of time.<\/em> <\/p>\n\n\n\n

How does test automation help?<\/strong> <\/h2>\n\n\n\n

\u2500How much has introducing test automation benefitted you?<\/strong> <\/p>\n\n\n\n

Sakaue: <\/strong> 
The benefits have been quite obvious. When I give lectures, I always illustrate using numbers (laughs). For example, the number of errors we detected when developing Yakuza 0 was fewer than 1,000. Since then, we\u2019ve made various improvements to the program and have become able to perform a wider variety of tests, which led us to discovering around 60,000 errors in Infinite Wealth. Most importantly, the percentage of errors found though automated testing has been steadily increasing the whole time, and is now at over 80%. <\/p>\n\n\n\n

The total running time for tests has also been gradually increasing \u2013 for Infinite Wealth, we ran full tests of the main scenario and substories, as well as tests of the mini games every day, in each language and on every platform \u2013 resulting in a total of about 700,000 hours of testing (performed during the night). We have more and more machines running automated tests 24 hours a day now, and it\u2019s getting to the point where machines that started running tests in the morning are already showing errors by the afternoon. <\/p>\n\n\n\n

The time it took us to create the automated tests and implement the automated testing system for Infinite Wealth was about 5,000 hours. This is less than one-hundredth of the total 700,000 hours of running time I just mentioned. This means that each person on the team is doing the work of more than 100 people (laughs). <\/p>\n\n\n\n

By putting it like that, I might have given you the impression that we were able to achieve a huge cost cut, but I\u2019d like to emphasize that this was only possible thanks to our accumulated efforts to improve the system over time \u2013 it\u2019s not a level of efficiency we could have hoped for right from the start. <\/p>\n\n\n\n

\"Achievements<\/figure>\n\n\n\n

For Super Monkey Ball Banana Rumble, it was our first time implementing automated testing in the series\u2019 history, so the efficiency was only about 10 times higher than that of human labor alone, but even that was a lot higher than what we\u2019d anticipated. These numbers were possible because we were able to reuse mechanisms developed for the Like a Dragon series. I think that when you introduce automated testing for the first time, the initial benefit is a lot more noticeable in terms of quality than it is in terms of cost efficiency. <\/p>\n\n\n\n

\u2500It seems like a major reduction in man-hours overall.<\/strong> <\/p>\n\n\n\n

Sakaue: <\/strong> 
Also, people usually associate testing with the late stages of development. However, at RGG Studio, we use our experience and systems from previous games to start testing not in the beta phase, but as early as the alpha and prototype phases. <\/p>\n\n\n\n

\u2500Wait, so you do testing in parallel with development from the start?<\/strong> <\/p>\n\n\n\n

Sakaue:<\/strong> 
Basically, as soon as development starts, we start preparation for testing. <\/p>\n\n\n\n

\u2500That\u2019s surprising. Does that mean you don\u2019t have a dedicated testing period at RGG Studio?<\/strong> <\/p>\n\n\n\n

Sakaue:<\/strong> 
Of course, there is a period of testing and debugging for final, manual verification during the end stages of development. However, we don\u2019t want to have any fatal bugs left over at this point, so we deal with them in advance. We want to fix any obvious bugs \u2013 like bugs that cause the application to crash when you go to certain coordinates or bugs related to missing collision detection \u2013 as soon as possible. Everyone remembers the details of a bug that occurred last night, but if a bug gets reported a month after it occurred, we may have lost track of what it is or even worse, the bug may have led to another bug in the meantime. As such, it\u2019s a lot less costly to just fix things early on. <\/p>\n\n\n\n

\"Naoki<\/figure>\n\n\n\n

\u2500True, it makes sense to want to iron out bugs as early on as possible.<\/strong> <\/p>\n\n\n\n

Namiki:<\/strong> 
Before we introduced automated testing, it used to take longer for us to get to debugging after a bug’s initial discovery. Then when it came the time to debug, we\u2019d have to dedicate extra time to investigate the conditions for its occurrence, which would slow down the pace of development. Even if we wanted to concentrate on other tasks, we\u2019d get interrupted by bug investigations and fixes. <\/p>\n\n\n\n

After introducing automated testing, we created a cycle whereby information on bugs gets sent in batches. This allowed us to fix bugs found overnight by noon the next day, generate a new package automatically by night, and have the fix ready by the following morning. This has allowed us to develop games at a completely different speed than before. Since the bugs get fixed faster, we have more time on our hands to devote to other areas of development. Seeing games come together at such a rapid pace really drove home to us how amazing test automation is. <\/p>\n\n\n\n

Kuwabara:<\/strong> 
Letting even a single fatal bug remain in the game in the final stages of development is bad news. By using automated testing, we can guarantee that the main story and all substories have been cleared every day, and that the mini games are functioning properly too, which gives us a lot of reassurance. In turn, we get more time to improve the game and add new features to it. <\/p>\n\n\n\n

Sakaue:<\/strong> 
One more advantage of test automation is that we can share the results with our teams that do manual testing and localization testing. For example, a common issue we get is that a package won\u2019t run in a specific language. But now, the other teams can consult with the automated test results and decide what package to use for their own testing based on that, which I think is really useful. <\/p>\n\n\n\n

Due to time differences, we can\u2019t always communicate in real time with staff working overseas, so we used to have incidents where information was not communicated properly, leading to them selecting non-functional packages. However, automated testing has solved this problem for us. The communication involved in dealing with bugs is time-consuming, and due to it being daytime in Japan and nighttime overseas- it also led to unhealthy working habits, so it wasn\u2019t something we could just ignore. I\u2019m really glad we\u2019ve managed to resolve this issue. <\/p>\n\n\n\n

Test automation helped us with efficiency, but that\u2019s not all<\/strong> <\/h2>\n\n\n\n

\u2500What have been some common bugs occurring in the Like a Dragon series?<\/strong> <\/p>\n\n\n\n

Sakaue:<\/strong> 
Each title is prone to specific bugs, so it\u2019s important to identify what kinds of bugs are likely to occur in a game and prepare the necessary testing to intercept them. For the Like a Dragon series, the trickiest part is the connection between different elements of the game. The games are generally structured around a main story, with substories and minigames scattered throughout. With this kind of structure, it\u2019s common for errors to occur where the minigames connect with the main story. <\/p>\n\n\n\n

For example \u2013 you finish playing a minigame, and you get warped to strange coordinates and the game crashes. When a bug like that arises, it has to be fixed before development of the main story can resume. That\u2019s why it\u2019s very important to check progression of the main scenario all the way through in one go for Yakuza games \u2014 not just from start to finish, but as a continuous experience. Infinite Wealth included essential side content like Dondoko Island and Crazy Delivery, so it was crucial to make sure these sections didn\u2019t interfere with each other. <\/p>\n\n\n\n

\"Crazy<\/figure>\n\n\n\n

\u2500I can imagine how difficult testing Like a Dragon games must be, given how NPCs change places with in-game time progression and events.<\/strong> <\/p>\n\n\n\n

Sakaue:<\/strong> 
Problems can easily arise when characters from the main scenario are located close to characters from a substory, so we thoroughly check such places. From Yakuza 6 onwards, we\u2019ve implemented a system that clears the game automatically. Before that, every time we\u2019d submit a package to the manual testing team, the game had to be tested by hand from start to finish in a continuous run, so we\u2019d assign one person for each chapter and go through it manually. But now that we can do this automatically, we\u2019ve been freed from this process (laughs). Although we still have to do final verification manually, getting rid of the repetitive checking process was a huge achievement for us. <\/p>\n\n\n\n

\u2500Are there any difficulties particular to the Super Monkey Ball series?<\/strong> <\/p>\n\n\n\n

Namiki:<\/strong> 
Compared to the Like a Dragon series, the Super Monkey Ball series has simpler gameplay and is more compact, plus the physics and behavior of the ball have been refined over many years. That\u2019s why we focus less on the core of the program and more on checking the stage and environment graphics, as well as the functionality of new gimmicks. <\/p>\n\n\n\n

There is one important thing I\u2019d like to mention though… the Super Monkey Ball series is challenging in terms of skill. If you assign different people to different stages of the game, the people in charge of the later levels have a really hard time (laughs). We worked on Super Monkey Ball Banana Mania before introducing automated testing, and there were only one or two people on the development team who could clear all of the levels. As a result, we had to basically rely solely on them and the QA testers for the later stages of the game. We knew we couldn’t remain dependent on human labor for this, which was a big factor that led to us introducing automated testing. <\/p>\n\n\n\n

\n