SerpApi.Org
Today (the 23rd) at CEDEC 2026, Capcom presented a session on the industry-trending topic of AI in game development, using 'Monster Hunter Stories 3' as a case study. The speakers—Naohiro Nomura, Ryota Sakiyama, and Yudai Hirata from the CS Second Development Division's System Infrastructure Department—were responsible for building and operating AI agents capable of automated playtesting in environments identical to those of human players. They shared their insights on why automated playtesting for product builds is necessary and how to manage it efficiently.
As Game Development Expands, Automated Product Build Testing Becomes Essential
Nomura opened the session by emphasizing that automated playtesting AI for product builds has become a necessity. As hardware performance has surged, the demand for higher-quality graphics and complex physics simulations has grown. Furthermore, the global rise in demand for multiplayer games has increased the need to incorporate online elements. With more features to implement, the scope of testing has naturally expanded, making the verification of product builds particularly critical.
Development builds contain internal debug information—such as navigation data, scene status, coordinates, movement, and progress—along with various built-in check functions, allowing for immediate error and bug handling. However, product builds delivered to users have all such debug code and data removed for security and optimization. Naturally, traditional automated testing methods that rely on internal program data are difficult to use. Consequently, bug detection and verification in product builds previously required manual QA checks by humans.
To solve this, the team needed a system that could operate without access to internal data, mimicking a user by interacting with the screen via virtual keyboard or controller inputs. The challenge was to build an agent that could operate 24/7, making its own decisions from the start of the game to the ending with minimal human intervention.
An Automated Play Architecture Implemented via a Hybrid of Situation - Awareness and Action - Decision AI
Sakiyama then explained the architecture for testing 'Monster Hunter Stories 3' product builds. Since product builds cannot access internal data, the automated play agent had to perceive the screen like a user. To achieve this, the team implemented a situation-awareness AI for screen perception and a separate action-decision AI based on that input.
The technology stack was divided: C# was used for the situation-awareness AI to handle high-speed processing tasks like OCR, template matching, color detection, screen capture, virtual controller input, Windows API integration, and debug views. Python was used for decision-making and control processes, including rule-based action selection, prompt control, and VLM/LLM calls.
Four main recognition technologies were introduced to help the AI perceive the situation. First, OCR was used to extract text data, such as message window text or selected weapon/item names; it required no preparation and was easy to process programmatically. Second, template matching was used to search for specific UI elements, confirm their presence, and check their exact locations, which was useful for identifying fixed icons or decorative text.
Third, color detection technology was used to analyze specific screen areas at high speed. For example, the system could recognize loading screens by detecting the screen-wide blackout, or identify menu windows by detecting specific green UI elements.
Finally, a Vision-Language Model (VLM) was used to receive both the screen image and a prompt to understand the situation in semantic units and return structured results. This was primarily used for ambiguous scenes that are difficult to define with program rules, such as startup logos, title screens, and initial settings.
After the AI perceived the situation, the action-decision AI used a rule-based approach to determine the necessary actions and operate the virtual controller. The rule-based approach was chosen primarily for its ease of modification and debugging. Because action patterns were clearly written (e.g., If A, then B), it was easy to trace the cause of actions. This allowed for safe, localized logic fixes when problems arose—a major advantage in a development environment where game specifications change daily.
From Situation Awareness to Movement: Navigating to the Ending
Once the perception and action design were complete, the team had to teach the agent how to actually control the character to move and progress to the ending in the 'Monster Hunter Stories 3' product build.
To do this, they first defined the story loop, not as a narrative progression, but as a bundle of major actions: moving to a destination, triggering events, and engaging in combat/training.
Meanwhile, they organized the story flow using Python scripts. For example, they defined specific segments like "Chapter 1 Part A: Talk to NPC" and "Chapter 1 Part B: Boss Fight" to enable the rule-based pipeline. They also modularized frequently used tasks like NPC conversations, menu navigation, and movement to allow for reuse. The situation-awareness AI was configured to verify that the screen transitioned as expected.
Sakiyama used 'Fast Travel' as an example. To perform Fast Travel, the agent must open the menu, move the cursor, confirm the destination, and select the time of day. From the perspective of the situation-awareness AI, it first uses OCR to check for the text 'Please select a destination' to confirm it is in the Fast Travel menu.
Next, it uses color detection to pinpoint the cursor position. Since 'Monster Hunter Stories 3' uses a specific teal color for the menu cursor, the system can quickly verify its location. It then uses OCR to confirm the destination name, initiates the move, and uses OCR and template matching to select the time of day when the dialogue box pops up. Once the text disappears and the screen goes black, the system determines the process is complete.
Beyond Fast Travel, the team had to implement 3D field movement. Since UI recognition alone is insufficient for 3D space, they built a database of route images and metadata (jumps, camera angles) captured via the development build's NavMesh auto-movement.
3D field movement was implemented using two methods: feature point matching and mini-map pattern matching. Feature point matching, used in towns or narrow areas, extracts common features between the current game screen and the route image to guide movement. It geometrically estimates the misalignment of corresponding points and converts them into input values for the right stick (camera rotation) and left stick (movement), applying smoothing to adjust behavior.
For wider areas where feature matching is difficult, the team quantized the mini-map colors and compared terrain patterns. This method calculates stick inputs based on the camera direction rather than the map, allowing for fast and stable movement across large areas without camera manipulation.
To clear the story, the agent also had to handle boss fights. It needed to evaluate character stats and perform training—such as leveling up, upgrading equipment, or collecting Monsties—when necessary. The situation-awareness AI checked the player's status, and the rule-based action-decision AI executed the appropriate training steps.
Another challenge was saving and loading. If the game crashed or the character got stuck in the terrain, Fast Travel might not work. Since debug tools are unavailable in product builds, the solution was to load save data.
The system was set to perform manual saves at key intervals and prioritize loading these custom save files upon restart. If the agent detects a character stuck in terrain or a dialogue freeze, it first attempts to reset via Fast Travel. If that fails, it restarts the game and loads the save point. If the issue persists, it marks the section as un-clearable, loads a pre-prepared save file for that specific progress point, and skips the problematic section.
Utilizing LLM+VLM to Master 'Combat', the Core of Gameplay
Nomura returned to explain how the AI agent handles combat. 'Monster Hunter Stories' features a complex rock-paper-scissors system (Power/Speed/Technical) combined with kinship gauges, breaks, Monsties, elements, and status effects, making fixed logic insufficient.
The team first structured the screen information so that OCR, template matching, and VLM could perceive the situation. They integrated ally/enemy HP, enemy types, and target arrows into a single 'Battle State' object, then extracted a list of possible actions for that turn.
They then organized data for RAG (Retrieval-Augmented Generation). By analyzing game specifications and assets, they stored monster names, elemental affinities, weaknesses, and special gimmicks to be referenced automatically. By inputting past turn data, RAG strategy knowledge, and natural language play policies into three LLMs, the system could predict the optimal move, enabling high-level play such as conserving Flash Bombs.
Natural language instructions were processed in two stages. First, parameters were structured (e.g., "Fight without healing, avoiding weaknesses" becomes 'No Healing: True', 'Avoid Weaknesses: True'). If 'No Healing' was true, the system physically removed the healing potion from the item menu to prevent LLM hallucinations. Ambiguous instructions like "play defensively" were added to the system prompt to allow for flexible constraints.
The team also cached tactics for each phase; if the same phase occurred, the system executed the cached command immediately. If a major loss occurred, the cache was discarded and recalculated.
The LLM judged the win rate; if the judgment was uncertain, the system sampled multiple phases, added advice prompts, and applied dedicated rule-based overrides to prevent progress stalls. If the win rate remained low, the agent would avoid combat and focus on training.
Beyond Building the AI: Visualization and Automation for Data Utilization
Finally, Hirata explained how they accelerated the process and utilized data. Capcom built a CI tool similar to Jenkins and a central agent server. The central server assigns different tasks to various terminals—for example, terminal A focuses on story progression, B on combat, and C on field exploration.
Each task was assigned parameters for start/end conditions, prompts, and test frequency, allowing the same program to verify different playstyles by simply changing the prompt.
The team conducted both comprehensive and hotspot testing. Comprehensive testing checks the entire game according to a matrix to ensure basic stability. Hotspot testing prioritizes areas based on bug tickets from the last month.
The LLM analyzed ticket descriptions, tagged them by monster/field, and ranked them. It then automatically generated tasks and parameters for bug-prone areas and issued them to the CI server for rapid response.
Data was visualized for different teams: developers viewed logs, videos, and error trends; QA checked uptime, crash counts, and clear rates; performance engineers synced video with FPS graphs to automatically list underperforming segments.
When a crash was detected, the system vectorized the stack trace, compared it to past cases, and automatically generated a ticket in the bug tracking system if it was a new bug.
They also built a natural language interface so that planners and QA could check status without coding. Every morning at 9 AM, the system automatically summarized results from the night/holidays. If a clear failed, the LLM generated a report detailing the cause, error location, time, and frame drops, allowing teams to start work immediately.
As a result, Capcom built an AI agent capable of 24-hour autonomous play from start to finish, automating over 30k hours of aging tests per month. Hirata concluded that AI has relieved the burden of repetitive testing and data collection, allowing developers to focus on the creative essence of making the game more fun.
