A Unity AI Workflow from Request to Runtime Verification

Code that looks correct is not the same as behavior that works in the running game. In this scenario, a developer asked whether player and enemy collision behavior worked as intended in a real platformer project. EngineForge inspected the existing project, moved into the connected Unity editor, ran a controlled Play Mode verification, and returned runtime evidence the developer could review.

The Unity task

The project was a git-backed Unity 2D platformer using the new Input System. The gameplay question was concrete: when the player walks into an enemy, does the player die and then recover through the project's respawn behavior? The task was diagnostic. It did not assume that the game needed a code change before the existing behavior had been observed.

Understand the existing project first

EngineForge first inspected the relevant project logic. The collision code used the player's position relative to the enemy to decide whether the enemy was stomped or the player was killed. That established a useful hypothesis and identified the player's alive state as the condition that mattered.

But project/code context could answer only what the logic intended. It could not establish which objects were active in the scene, whether the relevant behavior was connected correctly, or what would happen under real input in Play Mode.

Move from code into Unity

Through the connected Unity environment, EngineForge could work with the actual project and editor state rather than treating source files as the whole game. The workflow checked the relevant input configuration, prepared a controlled verification sequence, entered Play Mode, and drove the player toward the enemy without adding a helper component to the scene.

This is the important separation: project/code context explained the rule, editor/scene context established where and how to exercise it, and runtime evidence would show what the running game actually did. The Unity integration connects those stages while keeping the resulting project changes visible.

Verify the behavior in the running game

During a valid Play Mode run, the player entered the enemy collision, changed from alive to dead, and later returned to the alive state through the project's respawn flow. The observation answered the original gameplay question at the level that mattered: both the death behavior and the recovery behavior occurred in the running scene.

Reading the collision code made this result plausible. Running the game made it observable. See runtime verification for the bounded evidence model used by EngineForge.

When the evidence itself is not trustworthy

One verification attempt returned incomplete evidence. That result could not support either conclusion: it did not prove that the behavior worked, and it did not prove that nothing happened. No valid observation is not the same as observing no change. Instead of treating the quiet result as proof or inventing a game-code diagnosis, the workflow rejected the unreliable observation, reran the verification path, and obtained valid runtime evidence.

Review the result

The verified behavior did not require a speculative game-code fix. The developer could inspect the diff, confirm that no gameplay change had been introduced, and review any supporting project changes made during verification. When a workflow does change code, code checkpoints provide a review and restore boundary for captured code changes.

What this scenario proves — and what it does not

This scenario shows why a Unity workflow needs more than a plausible code-level answer. Project intent, connected editor state, and observed runtime behavior are different kinds of evidence. EngineForge connected those layers for one concrete gameplay question, recovered when the first observation was not trustworthy, and returned a result the developer could review.

• It covers one platformer using Unity's new Input System; it does not establish support for legacy UnityEngine.Input workflows or universal Unity compatibility.
• It verifies the named collision and respawn behavior, not every gameplay path or visual result.
• It is not autonomous full-game QA.
• External editor and generated state remain outside the complete code-checkpoint restore boundary.
• The developer still reviews the evidence and any resulting changes.

Explore the broader EngineForge Unity workflow, the extensible Crew, or the current download.