Begin with the search question
“Let the agent play overnight” describes a schedule, not a test objective. Before choosing a model, identify the system under investigation: traversal, inventory, combat, quest progression or a specific interaction between them. Then define the states that would make the run informative. A route through the first level may never exercise a late-game item combination, even if the agent completes that route thousands of times.
Separate behavioral competence from test value. An agent trained to maximize score may learn a safe loop that avoids difficult transitions. An agent rewarded for distance may run past interactable objects. Successful play can therefore conceal poor coverage. Record the objective, constraints and known blind spots alongside each campaign so the resulting evidence is interpreted in context.
Choose the least complicated useful agent
Scripted input sequences are often the best first instrument. They are understandable, inexpensive to run and straightforward to compare between builds. Behavior trees and search-based agents can add branching choices without requiring a learned policy. Reinforcement learning becomes interesting when decisions depend on changing state, but it also introduces training cost, reward design and model-version management.
Unity ML-Agents provides tooling for learning agents in Unity environments. Gymnasium defines interfaces commonly used in reinforcement-learning experiments. Neither automatically supplies a game's correctness rules. An observation space that omits inventory state, for example, cannot reliably support reasoning about inventory transitions. Treat the agent interface as test infrastructure that needs review, not a neutral window into the game.
Illustrative investigation
An exploration agent repeatedly reaches a locked doorway while holding a quest item. This is a lead. The door may require a conversation flag rather than possession alone. Capture both conditions before describing the observation as a progression defect.
Measure meaningful coverage
Hours played, actions issued and total sessions are useful operational counts, but they are weak substitutes for coverage. Define a small set of state dimensions tied to risk: map region, movement mode, equipment category, quest phase and network role. Count transitions as well as visited states. Entering a vehicle is not equivalent to exiting it during a save operation.
Avoid claiming complete coverage from a finite state summary. Games contain continuous positions, timing dependencies and combinations that become impractical to enumerate. Report what the measurement excludes. A navigation heat map, for example, says little about dialogue correctness or the accessibility of a menu. Compare agent exploration with human test charters to expose these omissions.
Control the environment without erasing failures
Fix the build identifier, content package and initial save before comparing runs. Record randomness seeds where supported, but do not assume one seed determines every subsystem. Physics scheduling, asynchronous asset loading and network messages can still differ. Keep environment metadata for hardware, graphics settings, platform and simulation timing.
Reset policies also matter. Automatically restarting after a long pause may hide a genuine soft lock. Restarting after every death may prevent investigation of broken respawn states. Establish an observation window and preserve the state before cleanup. An agent needs permission to fail visibly; otherwise the harness may clean away the most valuable evidence.
Turn exploration into a defensible lead
When a suspicious event appears, retain the preceding actions, state snapshots and relevant telemetry. Describe the observation in literal terms: “the interaction prompt remained visible after the item was removed,” not “the quest system is broken.” Record the expected behavior and where that expectation came from, such as a design requirement or an existing acceptance test.
Then attempt a smaller replay. Remove unrelated movement, reduce the setup and test whether the condition persists without the original agent. If the result disappears, preserve that fact rather than treating it as an inconvenient failure. The difference may reveal a timing dependency, hidden state or an incorrect assumption about the first observation.
Methodology note: compare strategies fairly
Compare scripted, random and learned exploration under matched build, runtime budget and starting-state conditions. Track unique reviewed findings, replay success and review effort. Do not rank strategies solely by raw alert counts: a noisy detector can make an unproductive explorer look busy.
Primary references to inspect
These sources document tools and testing concepts, not an endorsement or a claim that a particular agent will find defects in your project.
- Unity ML-Agents documentation — agent observations, actions and training environments.
- Farama Foundation Gymnasium — environment and interaction interfaces.
- Epic Games Unreal Engine Automation Test Framework — engine-level automated testing facilities.
- Godot Engine unit-testing documentation — a complementary layer below automated play.
- ISTQB Certified Tester Foundation Level — shared terminology for risk, testing and coverage.