Pac-Man’s four ghosts are not a single enemy rendered in four colors. Each one runs a different targeting routine, and those routines are simple enough to describe as arithmetic on tile coordinates. The differences are what make the maze feel like it contains four distinct pursuers rather than one swarm.

This article is about the targeting logic, not the mythology. Where a claim depends on the ROM or on a documented disassembly, I name the source. Where I am interpreting behavior, I say so.

The shared machinery: tile targets, not pixel chases

Pac-Man’s maze is a grid of 28 by 36 tiles. The ghosts move through that grid, and their AI is built around choosing a target tile. At each intersection, a ghost looks at the available exits and picks the one that brings it closest to its target tile. That is the whole decision procedure. The personality comes from how the target tile is computed.

Jamey Pittman’s Pac-Man Dossier, published by Game Developer in 2009, is the standard public description of this system. Pittman states that his information was “extracted from or verified with the disassembly output from the Midway Pac-Man arcade ROMs along with controlled observations of actual gameplay.” That provenance matters: the Dossier is not a strategy guide repeating folklore, it is a reconstruction checked against the ROM. I am relying on it for the targeting rules below, and I flag where the Dossier is the source rather than an independent measurement.

The arcade board itself is documented by the International Arcade Museum: Pac-Man uses a Z80 microprocessor and a Namco 3-channel PSG for sound. The Z80 is the chip executing the ghost routines. The MAME source tree contains a Pac-Man driver at src/mame/pacman/pacman.cpp, which is where an emulator trace would attach if you want to watch the targeting arithmetic run.

Blinky: the target is Pac-Man’s tile

Blinky, the red ghost, is the simplest case. His target tile is Pac-Man’s current tile. No offset, no reflection, no distance check. If Pac-Man is at tile (14, 20), Blinky’s target is (14, 20).

That directness is why Blinky feels like the ghost that is always behind you. He is not predicting; he is following the shortest path to where you already are. The other three ghosts are variations on that theme, and the variations are where the interesting bugs live.

Pinky: four tiles ahead, with a reported overflow when Pac-Man faces up

Pinky, the pink ghost, targets four tiles ahead of Pac-Man in the direction he is facing. If Pac-Man is moving right, Pinky’s target is four tiles to the right. If Pac-Man is moving down, four tiles down. The intent is ambush: Pinky aims where Pac-Man is going, not where he is.

The Dossier reports a bug in the up direction: when Pac-Man faces up, Pinky’s target is computed as four tiles up and four tiles left. The result is that Pinky overshoots to the northwest instead of directly north. This is not a random glitch; it is a reproducible consequence of how the offset is calculated in the ROM. I have not independently verified this specific overflow against a disassembly or trace for this article, so treat it as an attribution to the Dossier rather than a measured claim.

That bug is part of why Pinky’s behavior is hard to learn by feel. The rule is simple, but the rule has an exception that only appears in one direction.

Inky: a vector built from Blinky’s position

Inky, the cyan ghost, is the one that requires two ghosts to explain. His target is derived from a vector: take the tile two ahead of Pac-Man, then double the vector from Blinky to that tile. In practice, Inky’s target is the tile that is twice as far from Blinky as the two-ahead tile is.

This is why Inky’s behavior changes depending on where Blinky is. When Blinky is close to Pac-Man, Inky’s target collapses toward the action. When Blinky is far away, Inky’s target swings wide. The Dossier describes this as Inky’s target being based on Blinky’s position and the tile two ahead of Pac-Man. I have not independently confirmed the vector-doubling rule against a disassembly or trace for this article, so treat it as an attribution to the Dossier rather than a measured claim.

I am not going to invent a specific RAM address for that intermediate value. The Dossier describes the rule; the exact address depends on which ROM revision and which disassembly listing you are reading. If you want the address, the reproducible path is to load the Midway ROM set in MAME, enable the debugger, and watch the ghost state block while Inky’s target updates.

Clyde: chase until close, then retreat

Clyde, the orange ghost, has a distance threshold. When he is far from Pac-Man, his target is Pac-Man’s tile, same as Blinky. When he gets within a certain distance, his target switches to his scatter corner. The Dossier describes this as a distance comparison: Clyde chases when the distance is above the threshold and retreats when it is below. I have not independently confirmed the exact distance metric or threshold against a disassembly or trace for this article, so treat it as an attribution to the Dossier rather than a measured claim.

The effect is that Clyde is the ghost who seems to lose interest. He is not losing interest; he is switching targets based on a distance check. The comparison is performed in the ghost logic, and the threshold is a fixed value in the ROM. Again, the Dossier gives the rule; the exact comparison instruction and the exact threshold constant are things you would confirm by disassembling the relevant routine.

Scatter and chase: the mode schedule changes the target

All four ghosts alternate between two modes: scatter and chase. In scatter mode, each ghost targets a fixed corner of the maze. In chase mode, each ghost uses the targeting rule described above. The mode schedule is a table in the ROM, and it changes across levels.

The Dossier documents the scatter corners and the timing schedule. The corners are the four corners of the maze, one per ghost. The schedule alternates scatter and chase in a fixed pattern, with the chase phases getting longer in later levels. This is why the ghosts seem to give up and wander to corners at predictable times: they are not giving up, they are executing a mode change.

I am not going to reproduce the full timing table from memory. The Dossier has it, and if you are building a reproduction or a trace, that is the table to use. The important structural point is that the mode schedule is separate from the targeting rules. You can change the schedule without changing the targeting arithmetic, and you can change the targeting arithmetic without changing the schedule.

What a reproducible artifact looks like

If you want to verify any of this yourself, the path is:

  1. Obtain a Pac-Man ROM set and load it in MAME.
  2. Enable the debugger and locate the ghost state block in RAM.
  3. Set watchpoints on the target tile variables for each ghost.
  4. Play or step through a level and record the target values as Pac-Man’s position and facing change.
  5. Compare the recorded targets against the rules described in the Dossier.

The MAME source tree includes the Pac-Man driver at src/mame/pacman/pacman.cpp, which is where the memory map and the Z80 CPU are defined. That file is the starting point for understanding which addresses the emulator is exposing. The Dossier is the starting point for understanding what the routines are doing with those addresses.

What you should not do is treat a strategy guide’s description of ghost behavior as a specification. The Dossier is useful because it was checked against the disassembly. A guide that says “Pinky cuts you off” is describing an effect, not a rule. The rule is four tiles ahead, with the up-direction overflow.

Why the differences matter

The four targeting rules are not cosmetic. They produce different pursuit geometries from the same maze and the same movement speed. Blinky converges on your current position. Pinky converges on a predicted position. Inky converges on a position that depends on Blinky. Clyde converges on your position until he gets close, then leaves.

That is the design. The ghosts are not four copies of one AI with different speeds. They are four different functions that share a movement system. The movement system is the Z80 code that picks the exit closest to the target tile. The functions are the target computations.

If you are reverse-engineering the ROM, the target computations are the interesting part. They are small, they are arithmetic, and they have a documented bug. That is a good combination for a reproducible artifact: a disassembly listing that names the routine, a trace that shows the target values, and a comparison against the Dossier’s description.

FAQ

Is the four-tiles-ahead rule for Pinky exact?

According to the Dossier, yes, with the documented exception that when Pac-Man faces up, the target is four tiles up and four tiles left. The Dossier is the source for that claim.

Where is Inky’s target calculation stored?

The Dossier describes the rule but does not give a single universal address. The address depends on the ROM revision and the disassembly you are reading. The reproducible way to find it is to trace the ghost state block in MAME.

Does Clyde always retreat when he gets close?

The Dossier describes a distance threshold: Clyde chases when far and retreats to his scatter corner when close. The exact threshold is a constant in the ROM, and the comparison is part of the ghost logic.

What chip runs the ghost AI?

The arcade board uses a Z80 microprocessor, per the International Arcade Museum’s technical notes. The ghost routines are Z80 code.

Can I verify the targeting rules without a ROM?

You can read the Dossier’s description, but verification requires the ROM or a disassembly. The Dossier itself states that its information was extracted from or verified with the disassembly output from the Midway Pac-Man arcade ROMs.

Sources

Note on sourcing: the Dossier is a secondary source that describes a disassembly. I have not independently disassembled the ROM for this article. Where I say “the Dossier describes” or “according to the Dossier,” that is the level of evidence. Where I describe the general structure of tile-based targeting, that is interpretation of the Dossier’s description, not a claim about a specific instruction address.

No related posts.