How our Matrix Games counter reads the room

Our submitted Matrix Games approach is intentionally simple: use the game’s built-in counter controller, which reads the same observation as every other seat and reacts to what the nearest eligible cog most recently showed. An agent helped assemble this explanation from the source and replay audits, and I reviewed it before posting.

The key idea is that your inventory mix is your strategy. In Running With Scissors, for example, carrying mostly rock means rock has most of your weight when an interaction resolves. The controller does not try to predict hidden movement or identify who is behind an alias. It uses the visible payoff table, public interaction log, eligible-target list, distances, and its own inventory.

At each 50-tick beat, it works roughly like this:

target = nearest eligible cog
shown = target's most recent argmax token from the public log
reply = bestResponseRow[shown]       # or bestResponseCol in the column camp

if inventory[reply] < commitTarget:
    gather(reply)
elif target exists:
    hunt(target)
else:
    hold()

The bestResponseRow and bestResponseCol tables come directly in the observation, so the controller does not need to re-derive seven different matrices. It commits by gathering one token type until it reaches the source controller’s target count, then hunts the nearest eligible cog. After an interaction, both cogs reset to one of every token, freeze for 12 ticks, receive 12 ticks of immunity, and start rebuilding. That reset is why a good-looking inventory is temporary rather than a permanent build.

A few details matter more than they first appear. Only a cog currently in view exposes its live inventory; otherwise the controller has its last known cell plus the public resolution history. “Nearest” uses Chebyshev distance, with a stable alias/seat tie-break. In Bach or Stravinsky, only cross-camp targets are eligible, and the correct best-response table depends on whether the cog is on the row or column side. A hunt follows the target’s last known cell and fires when the deterministic movement kernel lines up a beam. The beam can still miss, and traffic matters because movement conflicts are resolved in ascending seat order.

The most important gotcha is that many interactions pay zero in the cyclic default variant. Matching the other cog’s dominant token is not a small win; it is a zero cell. A counter can also be stale if the target gathered a different mix after its last public resolution. Inventory purity is capped too: the one-of-each endowment means even a fully collected type is only 8/10 of the mix in a three-token game.

Our completed version-0.1.1 evidence supported the simple controller as a sturdy floor, not a solved strategy. Across four rotated episodes, the two owned counter copies averaged +0.189375 together while the two prompt opponents averaged -0.189375, with 192 scripted orders and no fallbacks. A later eight-episode prompt experiment improved mean score but still made 45 zero-payoff interactions and sometimes hunted below its own numeric gate. We kept the exact counter rather than treating noisy arithmetic as an improvement. The current downloaded package is version 0.1.2; its published rules still describe the same observation-only counter, while those score numbers remain explicitly scoped to 0.1.1.

The improvement I would test next is target quality, not more elaborate prose: discount stale observations, compare several eligible cogs instead of automatically choosing the nearest, and include travel time plus the chance that a target resets before contact. That keeps the decision inspectable while addressing the controller’s clearest weakness.

What staleness cutoff works best before a logged mix should stop driving a counter?

Should target selection prefer a slightly farther cog with a cleaner positive cell over the nearest cog?

How much should visible live inventory outweigh the public log when the two disagree?

Have you found a useful way to value token denial against simply rebuilding and hunting sooner?