Character progression

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.

• Path length and structure

  How many stages the player passes through, whether the main scale has a cap, and what continues afterward: power, access and traversal, or convenience.

• Progression axes

  How many independent cumulative progression tracks exist and how investment in one changes the value of another. Choice axes are recorded separately.

• Specialization choice

  How strongly choosing a role, branch, or build changes play. Reversibility and the decision point are recorded separately.

• Role of equipment

  How much power and long-term goals equipment carries, and how independent its loop is through its own upgrade scales, sources, and currencies. Equipment turnover is recorded separately.

• Progression sources

  Which activities provide progress, whether the player chooses a path, and whether other players take part in development.

• Progress persistence and carry-over

  How long progress lasts, whether it survives the end of a cycle, and how many layers with different lifetimes operate at once.

• Game integration

  How strongly progression determines content access, group composition, and roles in the economy and competition.

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 — NoneNo assessment has a derived final level

  There is no capability-changing progression that persists between sessions.

  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 — Unlock layerNo assessment has a derived final level

  Progression is limited to a short track or a set of unlocks.

• 2 of 5 — Basic progressionNo assessment has a derived final level

  There is a meaningful path and capability growth, but choice and integration are limited.

• 3 of 5 — Developed progressionNo assessment has a derived final level

  Persistent accumulation with a developed direction: connected axes, meaningful specialization choices, an equipment loop, or a post-cap path.

• 4 of 5 — Core progression systemNo assessment has a derived final level

  Progression determines content access, roles, and goals across a substantial part of the game.

• 5 of 5 — Progression-shaped gameNo assessment has a derived final level

  Progression layers connect core game loops and determine the player's long-term position.

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.

• Progression unit

  What develops. A path to the cap for one account and a separate path for each of thirty heroes are different quantities. There is one value: the unit in which the path is measured.

  Value type:

  List, custom values allowed, single value

  Requirement:

  Required

  Methodology section:

  16.1, 16.3

  Allowed values:

  • Whole account
  • Individual character
  • Character on a specific server
  • Individual class or specialization within one character
  • Seasonal character lasting one cycle
  • Collectible hero roster — Each hero develops separately.
  • Account-developed base, settlement, or fleet
  • Army or vehicle roster
  • Other — The methodology does not declare this value set closed. The value is meaningful only with an explanation (section 7). (Requires an explanation)
• Assessment subject: account or character

  Without this note, the same game can equally justify both an assessment under this module and an "adjacent mechanic" label. The list is closed because the attribute is binary.

  Value type:

  List, fixed options, single value

  Requirement:

  Required when applicable

  Methodology section:

  16.1

  Required when: When most progression belongs to a base, settlement, fleet, or army.

  Allowed values:

  • Assessment covers account development
  • Assessment covers character development
• Progression cycle type

  An eight-week season that deletes the character and an eight-week equipment scale refresh work in opposite ways. The list is explicitly closed by the methodology (16.3). There is one value: a second cycle type means a second progression mode, which receives its own card.

  Value type:

  List, fixed options, single value

  Requirement:

  Required

  Methodology section:

  16.3

  Allowed values:

  • Permanent — This cycle has no fixed length.
  • Seasonal scale refresh without a character reset
  • Parallel seasonal mode with a separate character that is deleted at the end
  • Seasonal event without a progression reset
  • Full world wipe
• Progression cycle length, weeks

  Cycle length in weeks. Shown beside the Progress persistence and carry-over component score: neither cycle length nor cycle type is sufficient alone.

  Value type:

  Number, single value

  Requirement:

  Required when applicable

  Methodology section:

  16.3

  Required when: When the cycle type has a length. A permanent cycle has no length, so a number must not be invented for it.

• Carry-over layers

  What survives a reset and what is lost. The component names the layers as account, character, seasonal, and mode. There can be several layers, each recorded separately: score 4 requires at least two layers with different lifetimes.

  Value type:

  Text, multiple values

  Requirement:

  Required

  Methodology section:

  16.3

• Main scale cap

  The top level of the main progression scale. "No cap" and "Unknown" are different answers and must not be recorded the same way.

  Value type:

  Text, single value

  Requirement:

  Required

  Methodology section:

  16.3

• Post-cap progression

  The Path length and structure component score depends on this value. The list is closed because this is a module scale with every value defined (16.3). The reasoned Unknown required by 16.12 is recorded as a reason instead of a value.

  Value type:

  List, fixed options, single value

  Requirement:

  Required

  Methodology section:

  16.3

  Allowed values:

  • Post-cap progression is available
  • No post-cap progression
• Pace limiters

  What limits progression speed. Limiters can be combined, so all active ones are recorded.

  Value type:

  List, custom values allowed, multiple values

  Requirement:

  Required

  Methodology section:

  16.3

  Allowed values:

  • No limiters — Recorded instead of the other values, not alongside them.
  • Accrual while away
  • Weekly caps
  • Energy and timers
  • Seasonal window
  • Other — The methodology does not declare this value set closed. The value is meaningful only with an explanation (section 7). (Requires an explanation)
• Progression-based content access requirements

  Confirms the link between progression and content access. There may be several requirements, each recorded separately.

  Value type:

  Text, multiple values

  Requirement:

  Required

  Methodology section:

  16.3

• Post-cap continuation type

  The type does not affect the score: both power growth and access growth count as continuation. Types can be combined, so all applicable ones are recorded.

  Value type:

  List, custom values allowed, multiple values

  Requirement:

  Required when applicable

  Methodology section:

  16.4

  Required when: When post-cap progression exists.

  Allowed values:

  • Power continues
  • Access and traversal continue
  • Convenience continues
  • Other — The methodology does not declare this value set closed. The value is meaningful only with an explanation (section 7). (Requires an explanation)
• Cumulative and choice axes

  Each axis is recorded separately with its type, unit, pace, and source. Score 4 requires at least three cumulative axes with different units, pace, and sources. Choice axes are recorded alongside them but do not raise the score.

  Value type:

  Text, multiple values

  Requirement:

  Required when applicable

  Methodology section:

  16.4

  Required when: Beside the Progression axes component score.

• Specialization choice reversibility

  The methodology records reversibility for every module assessment (16.4). This describes the system, not its level: free switching does not mean a shallow system, and irreversibility does not mean a deep one. The list is closed: ordered values cover the full attribute from free switching to irreversible choice.

  Value type:

  List, fixed options, single value

  Requirement:

  Required

  Methodology section:

  16.4

  Allowed values:

  • Free switching — At any time and at no cost.
  • Switching costs time or resources
  • Limited switching — Rare, rule-bound, or requiring a special resource.
  • Irreversible — Changing requires a new character.
• Specialization choice point

  The methodology requires the choice point (16.4). Only unlocking the available set raises the score. Freely choosing a character before a match is not progression and is recorded alongside it. Choice points can be combined: progression unlocks the set, then the player chooses from it before a match, so all applicable values are recorded.

  Value type:

  List, custom values allowed, multiple values

  Requirement:

  Required

  Methodology section:

  16.4

  Allowed values:

  • Choice during progression — Progression unlocks the available set.
  • Choice before a match — The player chooses from options already unlocked.
  • Choice during combat
  • Other — The methodology does not declare this value set closed. The value is meaningful only with an explanation (section 7). (Requires an explanation)
• Equipment turnover

  The risk of losing equipment is not a score and is recorded as a separate attribute in every module assessment (16.4). The earlier wording ranked a full-loot sandbox above a game with the most developed equipment loop. The list is closed: ordered values cover the full attribute from no loss to total loss.

  Value type:

  List, fixed options, single value

  Requirement:

  Required

  Methodology section:

  16.4

  Allowed values:

  • No loss
  • Wear and repair
  • Loss on death
  • Total loss
• Encounter mode

  A field in the repeating encounter group. The mode in which players meet one another. It differs from progression scope: an arena and the open world can share one progression scope but have different values. Each group record has one mode. The field is required in every record because matching text is the only link between records for one mode; without it, the progression role on the second dimension cannot be assigned to the same encounter. Spelling must stay consistent: the collector treats "arena" and "Arena" as one name written inconsistently and rejects the batch.

  Value type:

  Text, single value

  Requirement:

  Required

  Methodology section:

  16.6

• Progression role dimension in an encounter

  A field in the repeating encounter group. The methodology requires progression role values on two dimensions (16.6), so a dimension is required in every record: each dimension has its own role value, and one group record contains one dimension. Both dimensions are needed for at least one encounter mode; the exception is Not applicable with a reason (16.12). The list is closed because the methodology names the two dimensions explicitly.

  Value type:

  List, fixed options, single value

  Requirement:

  Required

  Methodology section:

  16.6

  Allowed values:

  • Equipment and stats
  • Available characters, abilities, and roles
• Progression role in an encounter Required with final level

  A field in the repeating encounter group. A mandatory note beside the final level that is not part of Depth. It is recorded for every encounter mode and both dimensions, so the group record number links mode, dimension, and role: "equipment is normalized, the role roster is horizontal" creates two records for one mode. The list is closed because this is a module scale with every value defined (16.6). Unknown is recorded as a reason instead of a value.

  Value type:

  List, fixed options, single value

  Requirement:

  Required

  Methodology section:

  16.5, 16.6

  Allowed values:

  • Not applicable — Not applicable: there are no encounters between players within this scope. The methodology requires a reason (16.12), so the value is meaningful only with an explanation of why no encounters exist.
  • Conditions normalized — Normalized: progression is disabled or equalized within the encounter mode.
  • Horizontal progression — Horizontal: progression unlocks options and roles without raising the power ceiling.
  • Bounded advantage — Bounded advantage: power grows, but the cap is reachable within a reasonable time or opponents are separated by progression level.
  • Persistent advantage — Persistent advantage: a progression gap consistently determines the encounter outcome.
• Acceleration source

  A field in the repeating acceleration group. Values are not mutually exclusive; several may apply, each with its own group record and active period. The list is closed because this is a module scale with every value defined (16.6). Unknown is recorded as a reason instead of a value. The competitive PvP module uses this attribute as evidence for the skill expression component.

  Value type:

  List, fixed options, single value

  Requirement:

  Required

  Methodology section:

  16.3, 16.6

  Allowed values:

  • Play time only — Play time only: all progress is earned through play.
  • Player exchange — Player exchange: part of progression is acquired from other players within the game.
  • Paid acceleration — Paid acceleration: real money speeds up the same progression path.
  • Paid power — Paid power: real money buys capabilities that are unavailable or practically unreachable through play.
  • Platform entitlement — Platform entitlement: a subscription, edition, or platform store unlocks capabilities.
• Acceleration source active period

  A field in the repeating acceleration group. The start and end of the period for the source in the same group record. The methodology requires a period for every source value (16.6), so the field is required in every record. Without a period, a discontinued attribute looks like an error in the earlier observation.

  Value type:

  Text, single value

  Requirement:

  Required

  Methodology section:

  16.6

• Temporary paid-only window, weeks

  Window length in weeks: an option is initially available only for paid currency, then becomes available for in-game currency.

  Value type:

  Number, single value

  Requirement:

  Required when applicable

  Methodology section:

  16.6

  Required when: When this window exists.

• Information and interface advantages

  Build suggestions, opponent statistics, or an expanded interface sold for money or through a subscription. These are not character progression and are not covered by the cosmetic exclusion, so they are recorded separately instead of silently dropping out of the assessment. There may be several advantages, each recorded separately.

  Value type:

  Text, multiple values

  Requirement:

  Required when applicable

  Methodology section:

  16.1

  Required when: When these advantages are sold.

• Progress transferability

  Progress tied to a tradable item is assessed here but marked separately because it overlaps with the player economy. The list is closed because the attribute is binary.

  Value type:

  List, fixed options, single value

  Requirement:

  Required when applicable

  Methodology section:

  16.1

  Required when: When progress is tied to a tradable item.

  Allowed values:

  • Progress is bound to the character
  • Progress is bound to a tradable item — Transferable progress overlaps with the player economy (section 12).
• Mode state

  Whether the mode is active now: abandoned seasonal modes, closed modes, fewer progression sources, and public developer explanations. Stored separately from depth and reach because a fading mode 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.

• Version 0.3 Current Adoption date not recorded

  Revised after a six-game pilot. Rewrote the Progress persistence and carry-over component so it once again measures progression longevity rather than account structure, and a persistent world no longer receives the same score as a seasonal mode that deletes the character. Raised the persistence threshold for levels 4 and 5 to 3. Moved the risk of equipment loss from the top Role of equipment score into the equipment turnover attribute. Removed long-term commitment from Specialization choice because it duplicated reversibility, and added the decision point. Added progression scope, a closed list of cycle types, cumulative axes and choice axes, the post-cap continuation type, an exclusion for information advantages, the Base and Army progression units, Platform entitlement with an active period, and two measures of progression's role in an encounter.

• Version 0.2Adoption date not recorded

  First written module version: concept and two presence conditions, implementation types, assessment scope, seven components, final-level rules, progression's role in an encounter and acceleration source, usage signals, classification errors, and minimum evidence.

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.3:214 assessments across 200 games