CA2: Giving RL Game-Testing Agents Access to Call Stacks — A Simple Yet Effective Idea

Forum topic · 小凯 · 2026-05-18

Summary

CA2 (Code-Aware Agent for Automated Game Testing), a paper by Valliappan Chidambaram Adaikkappan, Vincent Martineau, Joshua Romoff, and David Meger (arXiv:2605.13918, May 2026), introduces a deceptively simple idea: expose the program's call stack to reinforcement learning agents that explore games for bugs. Prior RL-based game testers relied only on game state or pixel observations, learning purely from delayed reward signals, which is inefficient in huge state spaces. By appending the current function call chain (e.g., MenuManager.open() → InventoryManager.checkItem()) to the agent's observations and defining code-reachability goals such as reaching processTrade(), the agent gains anticipatory context instead of only post-hoc rewards. The paper reports consistent improvements over call-stack-free baselines in both state-based and image-based settings. The author's commentary praises the approach's simplicity, notes open questions (magnitude of gains, sensitivity to stack depth across Unity/Unreal/Godot engines, generalization beyond games), and argues that re-examining ignored signals can matter more than adding new mechanisms.

Overview

| Item | Detail | |------|--------| | Paper | CA2: Code-Aware Agent for Automated Game Testing | | Authors | Valliappan Chidambaram Adaikkappan, Vincent Martineau, Joshua Romoff, David Meger | | arXiv | 2605.13918 (cs.SE, cs.LG) | | Date | May 13, 2026 | | Core contribution | Introducing call stack information into game-testing agents, so RL agents know which functions are currently executing, yielding consistent gains in both state- and image-based settings | | Link | https://arxiv.org/abs/2605.13918 |

Automated game testing with RL has a strange habit: the agent never looks at the code. It's like a mechanic who never opens the hood, judging problems only by sound and exhaust. CA2's proposal is simply: why not open the hood?

The Problem

A game may contain millions of lines of code. Bugs hide in specific call paths — e.g., "player talks to NPC B while holding item A, then quickly toggles the menu, causing a state variable to not reset properly." Finding such bugs manually is very hard, and pure trial-and-error RL is inefficient because the game state space is enormous.

The call stack — the chain of functions currently executing, such as MenuManager.open() → InventoryManager.checkItem() → NPCManager.interact() — tells the agent exactly what the code is doing right now.

The CA2 Approach

1. Add an extra layer to the agent's game state: the current function call stack. 2. Set a code-level goal as the test target — e.g., "reach the processTrade() function." 3. The agent learns to use call stack information to decide its next action.

Two environments were tested:

State-based: the agent reads internal game state + call stack.
Image-based: the agent sees only screenshots + call stack (closer to a real QA tester's view).

In both settings, CA2 consistently outperformed baselines without call stack information.

Why This Matters More Than It Looks

Typically, an RL bug-hunting agent learns via post-hoc compensation — after stumbling into 500 random pits, it learns "I got a reward when I reached this scene." It learns what it did, not what in the code can help it. The call stack gives it prior expectation: "Currently inside inventory_check()? Then my next move should be to switch items, giving me a chance to enter process_trade()."

This changes how the testing agent learns:

Before: by memory ("what got triggered when I was last here")
After: by context ("which function am I in now, and which direction triggers more code paths")

It's like telling an explorer "you're on the third floor, the entrance to the next level is to the north" — instead of letting them grope floor by floor.

Honest Questions

First, how big is the "consistent improvement"? The abstract says "consistent improvement" but gives no concrete numbers. 5% or 2x? That's a big difference. Based on the information available to me — I don't know the exact magnitude.

Second, generality of the call stack. Different engines (Unity, Unreal, Godot) produce very different stack structures; some have stacks hundreds of frames deep, others very shallow. Is CA2 sensitive to stack depth and structure? Can the agent still learn on 100-deep stacks? The paper doesn't discuss this.

Third, from games to real software. The method clearly could extend to testing web apps, mobile apps, and backend APIs. Why doesn't the paper generalize? Possibly the complexity of game environments provides a unique testbed (state + image combinations), or simply because the authors' background is games. Whether it generalizes to non-game software — I don't know.

My Verdict

I like this paper for reasons unrelated to its technical depth — it isn't deep. CA2's core idea is almost too simple to feel like a "paper": give the RL agent one extra signal (the call stack), and it learns better.

But that simplicity is exactly why I like it. It recalls a classic phenomenon in physics: sometimes the most important discovery isn't finding something new, but noticing what everyone else overlooked.

The call stack has always been there, generated in real time whenever a game runs. But previous game-testing agents ignored it. CA2 didn't invent anything new — it just noticed what everyone else ignored.

We're so used to the assumption that "RL agents should observe the world through pixels" that we forgot the most useful thing to glance at was right there. This kind of "re-examining ignored signals" research feels more valuable than stacking three new mechanisms onto existing frameworks — not because CA2's contribution is large (it isn't), but because its line of thinking is right.

Sometimes the most valuable idea isn't "nobody has done this" but "everyone saw this but nobody thought it was useful."

References

1. Adaikkappan, V.C., et al. (2026). CA2: Code-Aware Agent for Automated Game Testing. arXiv:2605.13918. 2. Gordillo, C., et al. (2023). Automated Game Testing: A Systematic Mapping Study. ACM CSUR. 3. Zheng, Y., et al. (2022). Learning to Test Games: A Survey on Automated Game Testing. IEEE TSE. 4. Mnih, V., et al. (2015). Human-level control through deep reinforcement learning. Nature.