Game Theory - Prisoner’s Dilemma

-

Game Theory · 8 min read

A few weeks ago I came across a Veritasium video on the Prisoner's Dilemma, one of those videos that starts as background watching and ends with you staring at the ceiling at midnight, turning an idea over and over. If you haven't seen it, I'd strongly recommend it before reading further. Derek does what he does best: takes a deceptively simple thought experiment and reveals a universe of consequence inside it.

Prisoner’s Dilemma GAME THEORY · STRATEGY · COOPERATION PLAYER 1 PLAYER 2 VS C D P2 C D P1 3, 3 mutual gain 0, 5 exploited 5, 0 temptation 1, 1 mutual loss CODEPUZ.COM · ART OF SCIENCE

But what made me want to go deeper was not just the mathematics. It was the news.

We are living through a period where the US-Iran standoff is once again sharpening: sanctions, nuclear timelines, back-channel signals, rhetorical escalation. Two players, each calculating whether to cooperate or push harder, each aware that the other is doing the same calculation. Neither trusting, neither able to commit credibly. I kept thinking: this is not just geopolitics. This is the Prisoner's Dilemma, played out at the level of nations, with enormously higher stakes.

So I built a simulator to see for myself, to actually watch the strategies play out round by round and understand intuitively why some approaches collapse and others hold. What follows is what I found. The mathematics surprised me, the real-world parallels unsettled me, and I think they will do the same to you.

Imagine you are sitting across from a stranger. Neither of you can speak. A referee slides two cards face-down in front of each of you: one says Cooperate, the other says Defect. You each pick one, simultaneously, and the payoff depends on the combination.

If you both cooperate, you both walk away with a modest reward.
If you both defect, you both walk away with almost nothing.
But if you defect while the other cooperates? You walk away with everything. They walk away with nothing.

Now here is the uncomfortable truth: no matter what the other person does, you are always better off defecting.

If they cooperate and you defect → you win big.
If they defect and you defect → at least you didn't get exploited.

The cold logic of self-interest says: always defect. And yet, societies function. Businesses form lasting partnerships. Evolution produced altruism. Something is wrong with the logic, or rather, something is missing from it.

What is missing is time.

The Setup: Numbers Behind the Dilemma

The Prisoner's Dilemma is usually presented as a one-shot game. But the real world is not one-shot. You interact with the same people repeatedly: colleagues, suppliers, neighbours, nations. The game theorists call this the Iterated Prisoner's Dilemma, and it changes everything.

The payoffs in our simulator follow the classic matrix:

Opponent Cooperates Opponent Defects
You Cooperate You: 3, Them: 3 You: 0, Them: 5
You Defect You: 5, Them: 0 You: 1, Them: 1

The numbers encode a subtle tension:

  • Mutual cooperation (3, 3) is better for both than mutual defection (1, 1)
  • But the temptation to defect is always there; you gain 5 instead of 3
  • And if you cooperate while the other defects, you get the worst outcome: 0

This is why it is a dilemma. The rational individual move and the collectively optimal move point in opposite directions.

Eight Strategies Walk Into a Room

Over the decades, game theorists have proposed many strategies for playing the iterated game. Here are eight worth knowing, and you can pit them against each other in the simulator below.

Always Cooperate (ALLC)
The eternal optimist. Cooperates every single round, no matter what. Generous to a fault, and fatally exploitable.

Always Defect (ALLD)
The pure opportunist. Defects every round, every time. Seems invincible in a one-on-one fight. We will return to this.

Tit for Tat (TFT)
The famous strategy from Robert Axelrod's 1980 computer tournaments. Simple: cooperate on round one, then do exactly what your opponent did last round. Mirror them perfectly, rewarding cooperation, punishing defection, and forgiving immediately.

Tit for Two Tats (TF2T)
More patient than TFT. Only retaliates after the opponent defects twice in a row. Resistant to noise and accidental defections.

Generous Tit for Tat (GTFT)
Like TFT but with a built-in forgiveness mechanism: it randomly cooperates about 20% of the time even after being betrayed. Prevents death spirals of mutual retaliation.

Grim Trigger
The unforgiving strategist. Cooperates faithfully until the moment you defect once, then defects forever. No second chances. Maximally retaliatory. Surprisingly effective as a deterrent, but brittle.

Pavlov (Win-Stay, Lose-Shift)
Psychologically intuitive: if your last round went well (score ≥ 3), repeat what you did. If it went poorly, switch. Learns to cooperate with cooperators and defect against defectors, without explicitly tracking the opponent.

Random
The coin-flipper. Cooperates or defects with equal probability. Useful as a baseline.

The Duel: Why ALLD Looks Invincible

Fire up the simulator and run a duel: Always Defect vs Tit for Tat, 50 rounds.

Watch what happens in the move tape. Round 1: ALLD defects, TFT cooperates. ALLD earns 5, TFT earns 0. From round 2 onwards, TFT mirrors the defection and both players lock into mutual defection, earning 1 each round for the remaining 49 rounds.

Final score: ALLD wins by exactly 4 points, the spoils of that single round-1 exploitation, carried forever.

Now try ALLD vs Always Cooperate. ALLD earns 5 every single round. ALLC earns 0. The gap compounds mercilessly.

In any duel, ALLD has a brutal property: it either wins or draws. It never loses. Against cooperators it exploits. Against other defectors it ties. It seems like the unbeatable strategy.

This is where most people stop thinking about game theory. And this is exactly where it gets interesting.

The Tournament: Why ALLD Finishes Last

In 1980, political scientist Robert Axelrod invited game theorists, economists, psychologists and computer scientists to submit strategies for a round-robin tournament. Every strategy played every other strategy for 200 rounds. The winner was determined by total score accumulated across all games.

Run the same tournament in the simulator above. Click the Tournament tab and hit Run.

What you will find, consistently, is that Always Defect finishes near the bottom.

The reason is arithmetic. ALLD's strategy poisons every relationship it touches:

  • vs Always Cooperate → ALLD earns 5 per round ✓
  • vs Tit for Tat → ALLD earns 5 once, then 1 per round for the rest ✗
  • vs Grim Trigger → same punishment, permanently ✗
  • vs Pavlov → locked into mutual defection quickly ✗
  • vs another ALLD → 1 per round, every round ✗

The round-1 theft of 4 extra points is overwhelmed by dozens of rounds of grinding mutual punishment. Meanwhile, TFT playing against the majority of cooperative strategies earns 3 points every single round. That compounds beautifully.

The mathematics is stark: 49 rounds x 3 points = 147 points for TFT vs 1 + 49 x 1 = 50 points for ALLD in a single head-to-head. Multiply that across the whole field and ALLD's total collapses.

The Insight: Cooperation is a Long Game

This is the central revelation of the iterated Prisoner's Dilemma, and it maps onto the real world with almost uncomfortable precision.

Why businesses build reputations: A supplier who cheats you once earns a short-term gain and loses a long-term customer. Repeated interaction makes honesty economically rational.

Why nations sign treaties: Even rivals cooperate when the game is expected to continue indefinitely. The shadow of future interaction disciplines present behaviour.

Why evolution produced altruism: In populations where individuals interact repeatedly, cooperative strategies can invade and dominate even when defection is locally optimal.

Axelrod distilled TFT's success into four properties that any robust strategy should have:

  1. Nice: never defect first
  2. Retaliatory: don't let defection go unanswered
  3. Forgiving: don't hold grudges too long
  4. Clear: be predictable enough that others can learn to cooperate with you

Grim Trigger fails on forgiveness. Always Cooperate fails on retaliation. Always Defect fails on being nice. Only TFT and its variants satisfy all four, and the tournament confirms it.

Try It Yourself

A few experiments worth running in the simulator above:

Experiment 1: The exploitation trap
Duel ALLD vs ALLC at 30 rounds. Watch the score gap open immediately and never close.

Experiment 2: The mirror effect
Duel TFT vs ALLD. Notice how TFT's score tracks ALLD's almost exactly after round 1. Punishment is immediate and symmetric.

Experiment 3: Forgiveness vs rigidity
Duel Generous TFT vs Grim Trigger. Both start cooperative. GTFT recovers from accidents; Grim Trigger never does.

Experiment 4: The full picture
Tournament at 50 rounds. Notice that every top-ranked strategy is conditionally cooperative; they want to cooperate but will retaliate.

The Cheater's Paradox

In any single encounter, cheating is the rational choice. But in a world of repeated encounters, nice strategies outperform selfish ones.

The lesson is not that people are naturally good, or that selfishness is wrong. The lesson is structural: the length of the shadow cast by the future determines how people behave today. When interactions are one-shot, as in anonymous transactions and disposable relationships, defection flourishes. When interactions are repeated and reputations travel, as in communities, professions and long-term partnerships, cooperation becomes the dominant strategy not by moral instruction but by simple mathematics.

The prisoner's dilemma does not tell us to be nice. It tells us that in the right conditions, being nice wins.

And that, perhaps, is more convincing.

Play with the simulator above and see if you can find a strategy that consistently beats Tit for Tat in the tournament. It is harder than it looks.

Further reading

Tagged: Game Theory · Mathematics · Decision Science · Complexity

Comments

Post a Comment

Popular Posts

RAlI - The Silent Guardian of Your C++ Code

-
Image
RAII - The Silent Guardian of Your C++ Code How a destructor saved my multithreaded system late at night It was late at night. A multithreaded simulation platform had just frozen solid, no crash, no exception, no log entry. Just silence. The kind of silence that means every thread is waiting for every other thread, and nothing will ever move again. A deadlock. The engineer staring at the thread dump traced it back to an early-return path buried three call levels deep. Someone had locked a mutex, hit an error condition, returned immediately, and never unlocked. Under light load the path was never triggered. Under the stress of a parallel workload with dozens of threads hammering the same subsystem, it was only a matter of time. The mutex stayed locked. The threads piled up. The system seized. The lock had been acquired manually. It had been forgotten manually. These two facts were never meant to be separated and yet they were, by twelve lines of error-handling code a...
Read more

Type Erasure in C++

-
Image
One Box, Any Type: Understanding Type Erasure in C++ Or: How std::function stores a lambda, a function pointer, and a functor in the same box C++ rewards precise thinking about types. Most of the time, that precision is a feature. But occasionally the type system and the design pull in opposite directions, and the compiler rejects code that is, by every conceptual measure, reasonable. Consider a transaction monitor for a SystemC simulation. Every time a TLM transaction arrives, four separate objects need to respond: a Logger records it, a LatencyTracker measures it, a ProtocolChecker validates it, a CoverageCollector bins it. They share no base class, and they shouldn't need one. What they have in common is purely behavioral: they all respond to a transaction. So the obvious thing gets written: std :: vector < TransactionHandler > handlers ; handlers . push_back ( Logger {}); handlers . push_back ( LatencyTracker {}); handlers . push_back ( Pr...
Read more

Circular Dependency: An Anti-Pattern and Techniques to avoid it in object oriented Design

-
Image
When I attempted to write my first object oriented program with some meaningful complexity I was hit by the problem of cyclic/circular dependency. As the name suggests the problem definition is very simple. If we need to design two classes which need to call functions of each other directly how do we accomplish that? And what are the issues we may land up into if we do not pay proper attention to avoid circular dependency among them. I am sure this problem would have come up with many other programmers like me. In this post I would like to get in depth of this problem and explain why its call an anti-pattern and what are possible approaches to avoid it.
Read more