An LLM Wrote an Arkanoid Player and Beat the Boss in 10 Out of 10 Games

A familiar problem with AI agents looks like this: the model confidently writes code, runs it, and reports success, but nobody can prove that the task was actually completed. An experiment with the DOS game Arkanoid exposed this problem literally on screen. The LLM received the game without an API or access to process memory—only a 320 × 200-pixel image, mouse and keyboard controls, and the ability to return to saved states. The resulting player beat the DOH boss in 10 out of 10 games, scoring an average of 343,977 points.

Why training did not work

The first attempt followed the familiar approach: the LLM helped the author write a reinforcement-learning system. The agent took 17 million steps over roughly 17 hours, but plateaued at an average score of 7,000–8,000 points. It saw a downscaled image, moved the paddle in short increments, and received a reward based on the score.

The problem was hidden in the bounce mechanics. If the paddle struck the ball at different points within roughly 12 pixels of its center, the angle changed from a shallow leftward trajectory to a shallow rightward one. In the downscaled image, the ball became a blur, while the controls did not allow the paddle to be moved quickly to the required position. The author pointed out the relationship, but the new run was never completed.

This was the Software 2.0 approach: a human chose the architecture, data, reward, and training method, while the LLM helped build the system within those constraints. It accelerated the work, but did not decide which method the task required.

What changed in the second attempt

The same LLM was then given a different role. Instead of being asked to write a training system, it received access to the emulator, the full frame, precise mouse control, save states for repeatable experiments, and a goal: independently understand the game and write a player program.

The model began as a researcher. It found the settings, learned to skip the intro, created digit templates for reading the score, and noticed that the paddle could be moved across the entire field in a single frame. It then ran an experiment: it replayed the same moment several times, changed where the paddle met the ball, and measured the trajectory. This revealed six bounce zones. The player began calculating the flight path for each zone and selecting the hit that would destroy the bricks fastest.

The early versions made mistakes. The paddle jittered near the edge, the ball became stuck in one of the later rounds, and the final boss fired projectiles the player had not encountered before. The researcher examined the frames immediately before each loss, formed a hypothesis, changed the code, and repeated the test. For the boss, it added a prediction of where a projectile would intersect the paddle's line. For looping, it added a rule that deliberately misses the ball and starts the serve again.

An important detail: the LLM did not play the final games. It wrote a conventional deterministic program that could be inspected and tested. The model explored an unknown environment, while fast code executed the strategy it discovered.

What product teams can take from this

The first rule is to give the agent a sandbox. This could be a copy of a CRM system without real payments, a test database, or an emulator of a production process. The agent must be allowed to make mistakes, repeat experiments, and return to a previous state.

Second, design the verification before the automation. In the experiment, a separate judge evaluated the result: it launched the game with different delays, read the score, and confirmed the final screen. The researcher could not assign its own grade. In a business setting, the equivalent might be an automated test, balance reconciliation, or a set of control cases.

Third, separate research from execution. An LLM is useful when it needs to understand a new situation, design an experiment, and propose a solution. A repeatable operation is better delegated to a conventional program with clear inputs, an action log, and tests.

The experiment does not prove that an agent can handle any system: the game is bounded, feedback is fast, and the reported metrics come from a single project. But it clearly demonstrates an architectural principle. A strong agent is not a chat window placed next to a process. It is a researcher inside a safe loop: observation, hypothesis, experiment, code, and independent verification.