Pac-Man, in Real Time

The Pac-Man algorithm I developed reached the maximum score in our game under its four-life settings: 3,333,180 points. It started a fresh game, cleared the first 255 boards without losing a life, and collected the last available points on the corrupted final board. The recorded qualification ran for four hours and 32 minutes on an Apple M4 Pro, with a fixed seed and timing phase.

I used Gemini Argon because I had already run out of tokens on OpenAI Astra and I didn’t want to wait for the weekly reset. Moving between frontier models is easier when the project has a harness with explicit rules and tests. Here, the game engine, the player interface and the scoring and timing requirements give another model a concrete problem to work against. The next model still needs the code and enough context to understand the unfinished work, but it can test its changes against requirements that exist outside the conversation.

The harness can reject a promising-looking algorithm because it misses a fruit, returns an action too late or fails a replay. The model helping with development can change while the standard for a successful run stays the same.

My previous article described the browser recreation and the perfect path replay we used to check that our game harness is a faithful recreation of the original arcade game. This algorithm did not have access to the recorded paths. It receives the live game state and uses the engine's rules to simulate possible moves, with no language-model calls during play.

The harness advances the game every 16.5 milliseconds whether the player is ready or not. A late input is rejected, and Pac-Man continues under the last accepted control. The planner has to arrange complete sequences of captures while keeping up with that clock.

The implementation separates the background search from the controller that returns each action. At startup, the controller prepares up to four seconds of moves while a worker begins searching farther ahead. The worker sends back plan segments covering roughly eight seconds of play, or longer when carrying a ghost-herding sequence through. It keeps extending the plan as the game advances, including across board transitions. Before and after each frame, the controller checks that the actual game state matches the prediction. A mismatch causes it to discard the queued moves and start again from the current state.

The game and harness exchange state and actions with a real-time controller. A background planning worker supplies a move queue with predicted checkpoints. Below, three paths explain planning for blue-ghost boards, zero-blue-time boards and the split-screen finale. — The real-time controller and background planner, followed by the algorithm's three board strategies. Open the diagram to inspect it at full size.

During the qualification run, the controller's average response time was 0.0057 milliseconds across 989,574 callbacks. The slowest took 1.82 milliseconds, and the harness recorded no missed actions. These timings cover the controller callback. The more expensive search runs separately in the background, supplying the moves the controller can deliver quickly.

A maximum score requires capturing all four ghosts after every energizer that turns them blue. There are 68 of those opportunities across 17 boards, for 272 captures. On several boards, the blue window lasts only one second. A ghost that is across the maze when Pac-Man eats the energizer is already out of reach.

The planner avoids the energizers while collecting ordinary dots and fruit. With all four ghosts out of their central house, a beam search explores routes that bring them close to the chosen corner. It tests small delays before activating the energizer and simulates alternative capture orders, including how Pac-Man will leave safely afterward. Shifting activation by a fraction of a second can change which corridor a ghost commits to. Clyde retreats toward the bottom-left corner when Pac-Man gets too close, so the planner tries the upper and right energizers first and leaves that corner until later.

The algorithm plays board 1 at 1× speed and reaches the board's perfect score of 14,800 points, collecting both cherries and a four-ghost capture chain after each energizer. Silent individual-board demonstration, not the full-game qualification.

A cherry is worth 100 points; eleven ordinary dots are worth 110. A search that rewards immediate score can prefer the dots and allow the cherry to expire, making the maximum score impossible. The planner therefore weights fruit more heavily when comparing routes. Its actual point value in the game remains unchanged.

On the 238 boards with no blue-ghost window, the program has to survive while collecting every dot, all four energizers and both 5,000-point keys. Eating an energizer reverses the ghosts, but they remain dangerous. The planner checks routes around nearby ghosts and simulates detours to the keys before committing to them. Clearing these boards without a death preserves the lives needed at the end.

The algorithm plays board 255 at 1× speed and reaches the board's perfect score of 12,600 points: 240 regular dots, four energizers and both 5,000-point keys. The ghosts remain dangerous throughout this final full maze before the split screen. Silent individual-board demonstration.

Energizer note. Under the original arcade rules at normal difficulty, blue time is zero on board 17 and boards 19–255; board 18 has a one-second window. On those zero-blue-time boards, energizers still award 50 points and trigger a ghost reversal, but do not make ghosts edible or grant invulnerability. A detected collision with a dangerous ghost remains fatal on board 255.

Board 256 cannot be cleared. The arcade game's overflow bug corrupts half the maze, and nine dots on that side return after each death. The program collects the reachable dots, energizers and key on its first life, then deliberately loses that life so those nine dots return. It repeats the sweep on each remaining life. There is something comic about an algorithm spending more than four hours refusing to let a ghost touch it, then deliberately seeking one out.

Our game starts with three lives and awards one more at 10,000 points. The arcade perfect score of 3,333,360 uses six total lives, allowing two additional sweeps of those nine dots. Under our four-life settings, 3,333,180 accounts for every available point.

The harness checks that accounting throughout the run. It records the required fruits and ghost chains, deaths, and final-board collectibles rather than accepting the final score alone. An outcome replay reconstructs the game from the recorded inputs and checks the resulting states and events. A separate policy replay rebuilds the controller from fresh memory, supplies the recorded observations and background-worker replies, and checks that its decisions and outgoing worker requests match the transcript. Both checks passed in the recorded qualification.

The algorithm is available as open source in the Pac-Man algorithm repository, and the evidence archive is public. The evaluation harness remains private, but is available on request to anyone who wants to replicate these results. The accompanying recordings show the algorithm playing boards 1 and 255 at 1× speed, reaching perfect scores of 14,800 and 12,600 points respectively. They are individual-board demonstrations. The continuous qualification ran in headless Node against our recreation, with a fixed seed and timing phase. Success under those conditions does not establish performance across arbitrary seeds, a full campaign under browser timing, or the original arcade hardware.

At the end of the last article, I wrote that four ghosts had been haunting us since 1980 and that it was time to call the Ghostbusters. Consider the trap closed, all 272 times the rules allow.

This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.