Ready
2/s
Build a world. Equip an agent. Watch it think.
How does the simulation turn sensory readings into movement steps, and what happens when perception is toggled?
This interactive environment models an autonomous loop broken into three sequential phases: perception, decision, and action. At each tick, the agent senses its 4-neighborhood (up, down, left, right) for grid boundaries and obstacle walls if the scan tool is enabled. The decision module runs a breadth-first search (BFS) on an unweighted 12×12 grid from the agent's current coordinates to the target star. If the adjacent target cell is not directly ahead, the agent acts by turning in place before moving forward along the planned path.
The simulator uses classical deterministic graph search (BFS) rather than a large language model or reinforcement learning policy. Additionally, while the UI displays toggles for 'Move Forward', 'Turn Left', and 'Turn Right', only the 'Scan Adjacent' toggle alters the internal planner logic; turning off the scan tool causes the pathfinder to ignore walls, causing the agent to attempt moving straight into obstacles.
Clicking '⏭ Step' from the default Maze setup advances the agent from its starting coordinate (0, 0) facing up. Because the BFS path heads right toward (0, 1), the agent's first executed action is turning right to face that cell. The reasoning log updates to Step 1 with an observation of adjacent openings, a BFS direction decision, and the log message 'Turned right to face right.'
In each step, perceive() checks the four cardinal neighbors against the grid boundaries and the set of obstacle walls. The decide() function executes BFS to find the shortest path of coordinates to the goal. When the scan tool is active, walls are treated as impassable; when disabled, the pathfinder assumes all in-bounds cells are navigable.
Locomotion requires directional alignment: the act() function compares current facing direction to the vector between current cell and the next planned cell. If mismatched, it returns a 90-degree left or right turn action instead of advancing position.
In the underlying JavaScript implementation, unchecking 'Scan Adjacent' replaces the wall set with an empty set in decide(). However, the toggles for 'Move Forward', 'Turn Left', and 'Turn Right' do not guard movement execution in act(), meaning their toggles are cosmetic while scan directly alters agent navigation safety.
The sandbox uses a twelve by twelve grid, starting at zero zero and aiming for eleven eleven. In the open field the shortest path has twenty two moves. Breadth first search prefers right, then down, then up and left. The agent starts facing up, so it first turns right, moves eleven times, turns right toward down and moves eleven times. Because turns count as steps, the logged action total is twenty four, not twenty two. This is local algorithmic simulation, not an AI model call. Each step perceives, decides with breadth first search and acts. If the desired direction differs, a ninety degree turn changes facing and consumes a whole step without moving. A one hundred eighty degree difference returns none, so the agent may repeatedly stay. The move forward, turn left and turn right flags are exported and displayed but the act function never consults them. Only the scan flag changes the wall set used for planning. With scan disabled, planning assumes an empty wall set, but the movement function still checks real walls and can repeatedly hit one. That does not immediately mark the agent stuck; the next step can attempt the same path again. The safety limit is one hundred steps. Exports contain tool flags, walls, positions and logs, not proof of external agent capability. The native canvas fallback supports offline drawing; no external model, environment or service is executed here.