An exhaustive taxonomy of game types, organized by cooperation, conflict, timing, information, symmetry, player count, determinism, strategy, state space, time horizon, and special classes. Every category has a concrete software example. A reference for recognizing game structures in architecture.
game-theorytaxonomyreferencesoftware-engineering
Every software situation is a game. The game has a type. The type determines the appropriate analysis. This catalog classifies games along eleven independent dimensions. Each category includes a concrete software example. Use it to locate any situation in game-theoretic space. The location tells you what you're dealing with. What you're dealing with determines what you should do.
This catalog is a diagnostic tool. When a situation feels stuck — the migration isn't happening, the standard isn't being adopted, the teams keep breaking each other's APIs — locate it here. The name of the game tells you why it's stuck. The why tells you what to change. Most organizational interventions fail because they treat every stuck situation as a communication problem. Some are stag hunts. Some are chicken. Some are commons tragedies. The solution to a stag hunt is visible early adopters. The solution to chicken is a pre-committed rule. The solution to a commons tragedy is a governance mechanism. The solutions are different because the games are different. The catalog tells you which one you're in.
"Simplicity does not precede complexity, but follows it." — Alan Perlis
The catalog that follows is a map of the complexity. Use it to find the simplicity on the other side.
By cooperation
Category
Description
Cooperative
Players can form binding agreements. — SLA with penalty clauses. The SLA is the binding agreement.
Non-cooperative
No binding agreements. — Teams without API contracts. Communication is cheap talk.
Cheap talk
Communication allowed but unenforceable. — "We promise not to break the API." Without testing, this is cheap talk.
Bargaining
Two-player cooperative game over surplus division. — Two teams negotiating shared infrastructure costs.
Team problems
Non-cooperative structure, identical payoffs. — Team sharing the same OKRs. Incentives aligned by design.
By conflict of interest
Category
Description
Zero-sum
One's gain = another's loss. — Fixed headcount allocation. Every hire for Team A is one Team B doesn't get.
Non-zero-sum
Players can both gain or both lose. — API design. Both gain from clean contract. Both lose from broken one.
Coordination
No conflict. Players need to align. — Choosing a shared logging format. Everyone wants the same thing.
Mixed-motive
Both conflict and cooperation incentives. — Most real situations. Shared goals but private priorities.
By timing
Category
Description
Simultaneous
Players move without observing others. — Teams making independent tech choices in the same quarter.
Sequential
Players move in turn. — Deployment ordering. Stackelberg: first-mover advantage.
Repeated
Same game multiple times. — Sprint planning. Repetition enables reputation and reciprocity.
One-shot
Played exactly once. — A rewrite decision. No repetition.
Stochastic
State evolves probabilistically. — Incident response. Alerts arrive randomly.
By information
Category
Description
Complete information
All players know all payoffs. — Open-source. Everyone sees the code, issues, priorities.
Incomplete information
Private information. Bayesian games. — Team proposing rewrite has private info about true motivation.
Perfect information
All previous moves known. — Monolith. Every module observes every other module's state.
Imperfect information
Some moves unknown. — Microservices. Service A can't observe Service B's internal state.
Symmetric information
Same uncertainty. — Both teams uncertain about new CTO's priorities.
Asymmetric information
Different knowledge. — Senior engineer knows legacy weaknesses. New hire doesn't.
By symmetry
Category
Description
Symmetric
Payoffs depend only on strategies, not identity. — Two identical microservices with the same SLA.
Asymmetric
Changing identities changes payoffs. — Frontend vs. backend team. Different constraints, different strategies.
By player count
Category
Description
1-player
Decision theory. No strategic interaction. — Choosing an algorithm. Nature is the constraint.
2-player
Classic case. — Two teams negotiating an API contract.
N-player
Three or more. Coalitions possible. — Organization with many teams. Alliances form. Politics emerges.
Large/Many-player
Continuum. Atomic vs. non-atomic. — Open-source ecosystem. No single contributor changes equilibrium.
Mean field
Players interact through state distribution. — Microservices at scale. Each service interacts with aggregate behavior.
By determinism
Category
Description
Deterministic
No chance elements. — Deterministic deployment pipeline.
Stochastic
Some moves by nature/chance. — System with probabilistic failures.
Games of chance
All moves by one player and chance. — A/B testing. Nature randomizes users.
By strategy type
Category
Description
Pure strategy
Single deterministic action. — Always use the same database for every service.
Mixed strategy
Randomize over actions. — Random on-call assignment. Prevents predictable exploitation.
By state/action space
Category
Description
Finite
Finite actions and states. — Choosing between exactly three database options.
Scarcity is the universal engineering constraint. Time, attention, compute, complexity — every engineering decision is made within a budget. The budget is economic. The engineer who doesn't track the budget makes decisions blind. The engineer who tracks it makes decisions with full knowledge of the trade-off. The trade-off is the decision. The budget is the constraint. Scarcity is the unifying principle.