Player economy

Rubric components

Components describe the mechanic as observed. Each is scored from 0 to 4, or marked unknown or not applicable. The final level reflects the overall pattern, not an average. Component-level definitions are not stored in the database; they remain in the methodology’s source document.

• Breadth of exchange

  How broad a range of objects, services, and assets players actually trade.

• Price formation

  How much player supply and demand shape prices instead of the system setting them.

• Player production and supply

  The share of supply created through player gathering, crafting, and production chains.

• Specialization and interdependence

  How strongly professions and roles create lasting reasons to trade and depend on one another.

• Space, logistics, and information

  How distance, local markets, transport risk, and information shape decisions.

• Value sinks and turnover

  Destruction, loss, repair, taxes, and upkeep that sustain repeat demand.

• Market institutions and tools

  Listings, orders, auctions, history, contracts, and other market institutions.

• Gameplay integration

  How much the market affects equipment, progression, warfare, and long-term strategies.

Final level steps

All steps are shown, including those with no games. At levels 1–5, zero means no matching games were found; it is different from an unassessed step. A game with multiple scopes at different depths appears at each relevant step, so totals can exceed the number of assessed games. Required conditions for levels 3–5 are documented outside the database.

The first count shows games with an exact result. “No higher than N” results and results with no recorded form are shown separately and are not added to the exact count.

• 0 of 5 — No player economy0 games in the Catalog

  There is no built-in economic loop between players.

  Level 0 is empty by design. An absent mechanic is recorded through presence, not as depth level 0, and receives no depth level. The mechanics page shows assessment and presence counts.

• 1 of 5 — Transfer layer0 games in the Catalog

  Gifts or narrow direct exchange without a persistent market.

• 2 of 5 — Limited market2 games in the Catalog; 1 more marked “at most”

  Pricing or a marketplace exists, but its breadth, production, or integration is limited.

• 3 of 5 — Developed player market1 game in the Catalog; 1 more marked “at most”

  Regular player-driven pricing, market tools, and meaningful exchange.

• 4 of 5 — Core player economy0 games in the Catalog

  Production, specialization, and the market materially shape progression or the core loop.

• 5 of 5 — World-shaping economy0 games in the Catalog

  Production, markets, logistics, risk, and sinks connect core loops and change the persistent state of the world.

Module fields

Observations the module requires with each assessment. They help verify that the conclusion follows from the observed implementation. Section names are stored as free text and may reference more than one section.

• Market type

  A category of market implementation, not a quality level; the methodology defines it in a separate section (12.3). Without it, value transfer with no price, a managed marketplace, and a player market share one component profile and become indistinguishable. The list is closed because this is a module scale with every value defined (12.3). Unknown is recorded as a reason instead of a value. There is one value: a second market type means a second economic mode, which receives its own card (12.2).

  Value type:

  List, fixed options, single value

  Requirement:

  Required

  Methodology section:

  12.3

  Allowed values:

  • No meaningful exchange between players
  • Transfers only — Value can be transferred, but there is no market or price.
  • Direct barter — No developed infrastructure.
  • Managed marketplace — A marketplace exists, but the system largely determines supply, prices, or fulfillment.
  • Platform-mediated player market — Players place and fulfill orders through a platform layer.
  • Hybrid player market — A player market combined with substantial system supply, binding, and other constraints.
  • Player-driven market — Players create most of the supply, trading, and price formation.
  • External exchange only
• Player influence on supply and price

  The player influence axis (12.6). Stored separately from developer control because both can be high at once: the developer sets rules and sources while players form prices within them. The list is closed because this is a module scale with every value defined (12.6). Unknown is recorded as a reason instead of a value.

  Value type:

  List, fixed options, single value

  Requirement:

  Required

  Methodology section:

  12.6

  Allowed values:

  • No influence on supply or price
  • Influence a small part of the mode
  • Regularly influence supply or prices
  • Players determine most supply and prices within the mode
• Developer control

  The developer control axis (12.6). A deep player market does not imply a lack of control, so this axis sits beside player influence rather than replacing it. The list is closed because this is a module scale with every value defined (12.6). Unknown is recorded as a reason instead of a value.

  Value type:

  List, fixed options, single value

  Requirement:

  Required

  Methodology section:

  12.6

  Allowed values:

  • Low — The system mainly defines ownership and safety rules.
  • Moderate — The developer actively manages fees, sinks, sources, and restrictions.
  • High — The system largely determines supply, availability, binding, price limits, and turnover.
  • Total — Players only purchase and spend under predefined rules.
• Mode state

  Whether the mode is active now: declining transaction or marketplace counts, closed market institutions, and public developer explanations. Stored separately from depth and reach because a shrinking market has the same component profile as a growing one.

  Value type:

  Text, single value

  Requirement:

  Required when applicable

  Methodology section:

  4

  Required when: Wherever the mode may be fading.

Version history

Changes recorded for each module version. Assessment versions are matched against this history because different rubric versions may produce different levels.

no version history

Versions used for recorded assessments

This list is based on assessments, not version history. Versions with no recorded assessments are omitted. Reassessment replaces the previous record, so zero for an older version would misleadingly imply that it was never used.

• Version 0.2:206 assessments across 200 games