Multiplayer RPG – Game Design Document

This is the design baseline for the post-MVP restart. Once the MVP is finished, the game is rebuilt from this document, applying what was learned during the MVP.

1. Project Overview

We are developing a multiplayer, top-down action RPG in Godot 4 using GDScript.

The game is inspired by the dungeon-running and progression systems found in games like World of Warcraft Mythic+, but uses a top-down camera and WASD movement.

The primary gameplay loop revolves around repeatable, increasingly difficult dungeons featuring:

• Randomized dungeon layouts.
• Increasing dungeon tiers.
• Helpful and harmful affixes.
• Boss encounters and optional side rooms.
• Personal loot and gear progression.
• Class abilities, talent trees, and build customization.
• Group-based multiplayer.

The target is a relatively short dungeon experience of approximately 10–20 minutes.

The architecture must support multiplayer from the beginning. We should not build a single-player implementation and attempt to retrofit networking later.

Visual style and assets

The game is built with placeholder art (simple shapes and stand-in models) until the gameplay is proven. Final art is decided later.

The target look remains a polished old-school Warcraft III style.

Systems should not depend on specific models or animations, so placeholders can be swapped for real assets without gameplay changes.

2. Technical Architecture

Core principles

• Godot 4 and GDScript.
• Server-authoritative multiplayer.
• Data-driven game definitions.
• Composition over inheritance.
• Reusable runtime components.
• Clear separation between definitions, runtime state, and persistence.
• Stable IDs for anything that needs to be saved or referenced.
• Avoid unnecessary abstractions and overengineering.

The game should be designed so that adding new classes, abilities, talents, enemies, affixes, items, and status effects primarily involves creating new data definitions rather than writing new systems.

Three architectural layers

Definitions

Static game data, preferably represented by custom Godot Resources (.tres).

Examples:

• ClassDefinition
• SpecializationDefinition
• TalentDefinition
• TalentTreeDefinition
• AbilityDefinition
• AbilityModifierDefinition
• ItemDefinition
• StatusEffectDefinition
• AffixDefinition
• DungeonDefinition
• EnemyDefinition

Definitions should be immutable during gameplay. Runtime systems must never modify shared Resource definitions.

Runtime

Active game state and gameplay logic.

Examples:

• CharacterBuild
• EquipmentInstance
• ActiveEffect
• CharacterStats
• DungeonRun
• GroupState
• CombatManager
• DungeonManager

Runtime objects reference definitions through stable IDs or direct Resource references where appropriate.

Persistence

Responsible for saving and loading player data.

Examples:

• Character progression.
• Unlocked classes and content.
• Saved builds.
• Equipped gear.
• Inventory.
• Dungeon progression.
• Currency.
• Settings and keybindings.

Do not save entire Resource objects as player data. Save stable IDs and the necessary instance-specific values.

GameDatabase

Use a central GameDatabase to resolve definitions by stable ID.

It should provide access to definitions such as abilities, talents, classes, items, and status effects.

This avoids scattering resource-loading logic throughout gameplay systems.

The database should be initialized once and made accessible to the relevant systems.

3. Multiplayer and Server Authority

The game is multiplayer from the beginning.

The server is authoritative over all gameplay-critical state.

This includes:

• Character health and resources.
• Damage and healing calculations.
• Cooldowns.
• Ability activation and validation.
• Status effects.
• Loot generation and ownership.
• Equipment and build validation.
• Dungeon progression.
• Affix behavior.
• Deaths and respawns.
• Checkpoints.
• Dungeon completion and failure.
• Group resurrection.

Clients should send requests to the server, not directly modify authoritative state.

For example, when a player activates an ability:

1. Client sends an ability activation request.
2. Server validates the ability is unlocked and equipped.
3. Server validates cooldowns, resources, range, targets, and other requirements.
4. Server executes the ability.
5. Server replicates the resulting state and events.

Never trust client-provided damage, healing, cooldown, resource, or loot values.

Keep networking concerns separate from gameplay logic where possible. The underlying combat and build systems should not need entirely different implementations depending on whether they are running on the server or client.

4. Entity and Component Architecture

Use composition-based entities.

Players, enemies, bosses, summons, and other combat-capable entities should reuse common components.

Suggested components:

StatsComponent

Responsible for:

• Primary attributes.
• Secondary stats.
• Tertiary stats.
• Temporary stat modifiers.
• Calculating final stat values.
• Exposing stat-change signals.

Stats should be derived from multiple sources:

• Base character values.
• Primary attributes.
• Equipment.
• Talents.
• Abilities.
• Buffs and debuffs.
• Temporary modifiers.

Avoid having each system independently calculate final stats. Systems should request calculated stats from StatsComponent.

Stat conversions and scaling formulas should be centralized and data-driven where appropriate. See Section 12 for the canonical stat definitions.

HealthComponent

Responsible for:

• Current health.
• Maximum health.
• Taking damage after mitigation has been calculated.
• Receiving healing.
• Health-related signals.

It should not be responsible for:

• Armor, Toughness, or Magic Resistance calculations.
• Damage mitigation.
• Combat rules.
• Death and respawn semantics.

ShieldComponent

Responsible for:

• Active damage absorption shields.
• Shield amounts.
• Shield expiration.
• Shield consumption.

Support multiple shields if needed, with a clearly defined consumption order.

EffectsComponent

Responsible for:

• Managing active buffs and debuffs.
• Applying and removing effects.
• Updating durations.
• Handling stacking and refreshing.
• Handling dispels and immunities.
• Emitting effect-related signals.

CombatComponent

Responsible for character-specific combat functionality, such as:

• Ability activation.
• Cooldowns.
• Resource costs.
• Combat state.
• Target validation.

The exact division between CombatComponent and other ability-related components can be refined as implementation progresses.

5. Combat Architecture

Use a centralized CombatManager to coordinate damage and healing.

Combat calculations should not be implemented independently in every ability.

DamageInfo

Create a reusable DamageInfo object, potentially extending RefCounted.

It should contain the information required to process a damage event:

• Source entity.
• Target entity.
• Base damage.
• Damage type (physical or magical), which determines whether physical mitigation (Armor and Toughness) or magical mitigation (Magic Resistance) applies.
• Ability or effect source.
• Critical information.
• Relevant metadata.

The structure can evolve as the combat system becomes more advanced.

Damage pipeline

The pipeline must distinguish between the following categories of defensive mechanics:

• Avoidance: Dodge and Parry.
• Physical mitigation: Armor and Toughness.
• Magical mitigation: Magic Resistance.
• General damage reduction: Abilities, talents, buffs, and other effects.
• Absorption: Shields.

A suggested damage pipeline:

1. Resolve avoidance (Dodge and Parry) for eligible physical attacks. This comes first: a dodged or fully parried attack stops here, with no critical roll and no damage calculation.
2. Calculate attacker-side modifiers (Attack Power for physical damage, Spell Power for magical damage).
3. Calculate critical hit (Critical Chance).
4. Check immunities.
5. Apply physical mitigation (Armor and Toughness) or magical mitigation (Magic Resistance), based on damage type. A partial parry's reduction is applied here as well.
6. Apply general damage reductions.
7. Apply shields.
8. Apply remaining damage to health.
9. Emit combat events.
10. Trigger relevant procs and effects, including Life Steal.

The exact order of certain modifiers can be tuned, but it must be centralized and consistent.

Armor and Toughness both reduce incoming physical damage. The calculation must combine them without accidentally applying the same mitigation twice. The exact mitigation formula is a balance decision.

Dodge, Parry, and Block in the pipeline:

• Dodge avoids the attack entirely.
• Parry requires a melee weapon. It prevents a portion of the damage, with a chance to prevent all of it.
• Block requires a shield. It removes a fixed amount from every physical hit, with no chance roll. The Block amount is subtracted after Armor and Toughness have reduced the hit (between steps 5 and 6).

Core combat rules

• Moving cancels a cast by default. Abilities that can be cast while moving say so in their description.
• A global cooldown applies to all class abilities. Rest and potions are not affected by it.
• Melee classes auto-attack their target.
• Abilities require range and line of sight.
• There is no friendly fire.
• The critical multiplier is ×1.5 (tunable).
• Interrupts and crowd control exist, but not every class has both.

Enemy behaviour

• Enemy archetypes: melee, caster, ranged, and healer.
• Combat starts when a player engages an enemy or enters its aggro range.
• Enemies in a pack pull together.
• Enemies do not leash or reset when kited.
• An enemy that cannot reach its target moves toward it until it can.
• Ranged enemies stand still at their maximum range.
• Enemy healers heal the most damaged ally.
• A boss resets when all players are dead.

Threat

Enemies attack the player with the most threat.

• Damage generates threat. Healing generates a small amount of threat.
• Tank abilities generate extra threat, stated in the ability description.
• A taunt forces the enemy to attack the taunting player.
• An enemy switches target when another player exceeds the current target's threat by a 10% margin (tunable).
• Each enemy shows a threat bar.
• Bosses and elites face their highest-threat target, so frontal attacks are a positioning mechanic.

Threat is calculated and stored on the server.

Life Steal

Life Steal is a tertiary stat. It heals the attacker based on actual health damage dealt, not the damage before mitigation.

It should not calculate healing from:

• Damage completely absorbed by shields.
• Damage prevented by mitigation.
• Damage avoided through Dodge or Parry.
• Damage that never reaches the target's health.

This prevents Life Steal from generating healing from damage that was never actually dealt.

Healing pipeline

Healing should also go through centralized combat logic.

It should support:

• Spell Power scaling.
• Critical healing.
• Healing received modifiers, including the Healing Received tertiary stat.
• Healing bonuses and reductions.
• Healing absorption or other future mechanics.

Spell Power increases both magical damage and healing.

There is no separate Healing Power stat.

Critical Chance affects both damage and healing, allowing healing spells to critically hit.

Damage and healing abilities can have different critical multipliers if required for balance, but they use the same Critical Chance stat.

6. Status Effects

Use static definitions and separate runtime instances.

StatusEffectDefinition

A Resource describing a status effect.

It may contain:

• Stable ID.
• Name and description.
• Icon.
• Duration.
• Maximum stacks.
• Stacking behavior.
• Whether it can be dispelled.
• Whether it is a buff or debuff.
• Periodic damage or healing.
• Stat modifiers.
• Other effect behavior.

ActiveEffect

Each application creates a separate runtime instance.

It should track:

• Definition reference.
• Source entity.
• Target entity.
• Remaining duration.
• Current stacks.
• Periodic timers.
• Runtime-specific values.

EffectsComponent

Manages active instances and handles:

• Applying effects.
• Removing effects.
• Refreshing durations.
• Increasing stacks.
• Expiration.
• Dispel.
• Immunity.
• Periodic effects.
• Temporary stat modifiers.

Effect durations on a target are affected by that target's tertiary stats:

• Inspiration increases the duration of beneficial buffs on yourself.
• Resolve reduces the duration of harmful debuffs on yourself.

Never store runtime state inside shared definitions.

Pay particular attention to:

• Source attribution for periodic damage and healing.
• Configurable stacking behavior.
• Immunity handling.
• Synchronizing effects in multiplayer.
• Keeping maximum health and other derived stats synchronized when modifiers expire.

7. Classes and Specializations

The game has multiple classes. Each class has 2 or 3 specializations, depending on what fits the class.

A class owns its abilities. Specializations provide different ways to build and use that class.

The ability pool belongs to the class, not individual specializations.

This means players can unlock abilities from different specialization trees and combine them in a single build, provided the talent requirements are met.

Current class concepts

There are currently 22 classes, and more are being designed:

• Arcanist
• Bard
• Chronomancer
• Cryomancer
• Dragoon
• Druid
• Elementalist
• The First Mind
• Hex Doctor
• Knight
• Monk / Martial Artist
• Necromancer
• The Nullifier
• Paladin
• Priest
• Pyromancer
• Ranger
• Rogue
• Shaman
• Shapeshifter
• Veilwalker
• Warlock

Warrior and Mage from the MVP are not in this list. Pyromancer, Cryomancer, and Chronomancer are now classes of their own, and Druid and Shapeshifter are separate classes.

The roster is expected to grow, so nothing in the architecture may assume a fixed number of classes or a fixed number of specializations per class.

The first playable version of the new game ships with every class that is fully designed at that point.

The exact class and specialization designs are still subject to refinement.

Roles

The game recognizes four general roles:

• Tank
• Healer
• Damage
• Support

Roles are useful for matchmaking, loot generation, and dungeon composition.

They should not restrict players from creating unusual group compositions.

Support is a loose role for a player who is not the tank, the healer, or a pure damage dealer. Depending on the class, a Support mixes buffs and debuffs, off-healing and shields, and control and utility (crowd control, interrupts, dispels, movement tools).

A player chooses a role when entering a dungeon, limited to the roles their class can fill. The role is locked for the run.

Role packages

Each role comes with a role package: a small personal buff that supports that role. Packages are small and never fight-changing.

Abilities are typed as damage, healing, or utility. The Support package applies to every ability typed Utility.

All values are tunable.

Group passives

Every class brings a passive group buff instead of long-duration buff spells. It does not use an ability slot.

• Each class chooses between two passives.
• The choice is saved in the build and locks when the run starts.
• The same passive does not stack if several players bring it.
• Passives are small and additive, never fight-changing. There are no loot or gold passives.

8. Talent System

There are no character levels and no talent-point progression.

Players have access to all 21 talent points from the beginning.

Talent points are shared across all specialization trees belonging to a class.

Talent tree structure

Each specialization has a talent tree with:

• 4 columns.
• 5 rows.
• 4 talents in each of the first four rows.
• 2 mutually exclusive capstones in the fifth row.

Each normal talent can have up to 3 ranks.

The two capstones are mutually exclusive. A player can only select one of them in a given tree.

Row requirements

Players must invest enough points in earlier rows to unlock later rows.

The current requirements are:

These requirements apply independently to each specialization tree.

Build point allocation

Each build has a total budget of 21 talent points.

Points can be distributed across the class's specialization trees.

There is no leveling or earning additional talent points.

A build is simply a configuration of how those 21 points are allocated.

Talent definitions

A TalentDefinition should contain:

• Stable ID.
• Name.
• Description.
• Icon.
• Tree reference.
• Row and position.
• Maximum rank.
• Rank-specific effects.
• Optional ability unlocks.
• Optional ability modifiers.
• Optional choice group.

Talents should define what they unlock or modify, not implement their own gameplay systems.

9. Builds

Players have separate builds for each class.

Each class starts with one available build slot.

Players can purchase additional build slots with gold, up to a maximum of three builds per class.

A saved build contains:

• Talent allocation.
• Equipped ability loadout.
• Any other relevant build configuration.

Each build has its own independent talent allocation and ability loadout.

Switching between builds should not require spending talent points again.

Every build has its own full 21-point budget.

Build switching should be handled by a dedicated build system that validates the selected build before applying it.

Changing talents, abilities, and the group passive is free. There is no respec cost. It can be done in the hub, the training ground, and the Bubble Room.

The build locks when the run starts and cannot be changed until the run ends.

10. Abilities

Abilities are owned by classes and can be unlocked through talent investments.

The player has a maximum of 10 equipped class abilities at a time.

There is a distinction between unlocking an ability and equipping it.

AbilityDefinition

An ability definition should contain:

• Stable ID.
• Name.
• Description.
• Icon.
• Resource cost.
• Resource type.
• Cooldown.
• Cast time.
• Range.
• Targeting type.
• Area of effect.
• Base damage or healing values.
• Damage type.
• Optional status effects.
• Optional talent requirements.
• Other relevant gameplay parameters.

Ability unlocking

Abilities may be:

• Available by default.
• Unlocked by a specific talent.
• Modified by talents.

The unlock requirements must be explicit and unambiguous.

Avoid having multiple independent systems that can accidentally disagree about whether an ability is unlocked.

Ability modifiers

Talents can modify abilities.

Examples:

• Increase damage.
• Increase healing.
• Reduce cooldown.
• Reduce resource cost.
• Add an additional effect.
• Change an ability's behavior.

Use reusable AbilityModifierDefinition Resources where appropriate.

Ability calculations

A centralized ability calculation system should calculate the effective values of an ability based on:

• Base ability definition.
• Talent ranks.
• Character stats.
• Equipment.
• Temporary effects.

Stat interactions relevant to ability calculations:

• Attack Power scales physical damage.
• Spell Power scales magical damage and healing.
• Critical Chance applies to both damage and healing.
• Haste affects attack speed and casting speed. It does not directly reduce cooldowns.
• Cooldown Reduction (tertiary stat) reduces ability cooldowns.
• Efficiency (tertiary stat) reduces the primary resource cost of abilities.

The UI should display effective values, not just the base definition.

For example, the tooltip should show the modified cooldown and damage after talents and other applicable modifiers.

Do not duplicate ability calculations between UI and server-side execution.

11. Resource System

Classes can use different primary resources.

Current resource concepts include:

• Mana
• Energy
• Rage

Classes may also use secondary resources such as Combo Points or other class-specific mechanics.

Resources should be data-driven where possible.

A resource definition should describe:

• Stable ID.
• Name.
• Icon.
• Maximum value.
• Regeneration behavior.
• Whether it regenerates naturally.
• Other relevant properties.

Resource rules

• Rage is generated by attacking. The amount is set per ability.
• Mana regenerates at the same rate in and out of combat.
• Energy regenerates at a flat rate that is not affected by Haste.

Vigor

Vigor is a secondary stat that increases primary resource generation.

Examples:

• Mana regeneration.
• Energy regeneration.
• Rage generated by attacks and abilities.

Vigor does not replace the underlying resource systems. It modifies their generation.

Vigor does not directly increase maximum resource capacity.

Other resource-related stats

• Intelligence increases Maximum Mana.
• Efficiency (tertiary stat) reduces the primary resource cost of abilities.

12. Character Stats

This is the canonical character stat system. All other systems must use these definitions consistently.

Stat categories

Character stats are divided into three categories:

• Primary attributes: Core character attributes that improve other stats.
• Secondary stats: Directly affect combat performance and survivability.
• Tertiary stats: Additional bonuses, primarily obtained through randomized gear rolls.

Armor and weapon values are item properties that contribute to combat calculations. They are not character attributes or secondary stats.

Primary attributes

There are exactly four primary attributes.

Primary attributes can appear on equipment and contribute to the character's final stats.

They do not directly replace secondary stats. For example, Might increases Attack Power, while Attack Power remains a separate stat that can also appear directly on equipment.

There is no Spirit attribute.

There is no primary Toughness attribute.

Agility does not increase attack speed. Attack speed is affected by Haste.

Secondary stats

Secondary stats directly affect combat performance.

Important secondary stat distinctions

Attack Power and Spell Power

These are separate offensive stats.

• Attack Power scales physical damage.
• Spell Power scales magical damage and healing.

Spell Power is not a healing-only stat. There is no separate Healing Power stat.

Critical Chance

Critical Chance applies to both damage and healing.

Damage and healing abilities can have different critical multipliers if required for balance, but they use the same character stat.

Haste

Haste affects:

• Attack speed.
• Casting speed.

Haste does not directly reduce ability cooldowns. Cooldown Reduction is a separate tertiary stat.

Vigor

Vigor increases the generation of a character's primary resource.

Examples:

• Mana regeneration.
• Energy regeneration.
• Rage generated through attacks and abilities.

Vigor does not directly increase maximum resource capacity.

Magic Resistance and Toughness

These are separate defensive stats.

• Magic Resistance reduces incoming magical damage.
• Toughness reduces incoming physical damage.

Neither replaces Armor.

Dodge and Parry

Both are defensive avoidance mechanics.

• Dodge avoids an eligible physical attack entirely.
• Parry requires a melee weapon. By default, a successful parry prevents a portion of the incoming damage. A successful parry also has a chance to prevent the entire attack.

Starting values, both tunable: a parry prevents 30% of the damage, and 10% of parries prevent the entire attack.

Block

Block is a defensive mechanic that reduces damage rather than avoiding the attack.

Block is always on while a shield is equipped. There is no chance roll: every incoming physical hit is reduced by the character's effective Block value.

The effective Block value comes from the shield's base Block and the character's Block stat.

Tertiary stats

Tertiary stats provide additional bonuses and are primarily obtained through randomized gear rolls.

Life Steal clarification

Life Steal is calculated from actual health damage dealt, not the damage before mitigation.

It does not generate healing from:

• Damage absorbed completely by shields.
• Damage prevented by mitigation.
• Damage avoided through Dodge or Parry.

Fortune affects gold only. It never changes gear drop rates or rarity odds; those come from affixes, tiers, and loot tables.

Equipment values and defensive calculations

Armor and Block are also influenced by equipment.

They must not be confused with the character's secondary stats.

Armor

Armor is an equipment value.

• Most armor pieces provide base Armor.
• Weapons, rings, and amulets do not provide base Armor by default.
• Shields provide base Armor.
• Armor contributes to physical damage mitigation.

Toughness is a separate secondary stat that also reduces incoming physical damage.

The damage calculation must combine Armor and Toughness without accidentally applying the same mitigation twice.

Shield Block

Shields provide:

• Base Armor.
• Base Block.

Base Block and the Block secondary stat together form the character's effective Block value, the amount removed from every physical hit.

How the two combine can be tuned later.

Damage mitigation

The combat system should distinguish between:

• Avoidance: Dodge and Parry.
• Physical mitigation: Armor and Toughness.
• Magical mitigation: Magic Resistance.
• General damage reduction: Abilities, talents, buffs, and other effects.
• Absorption: Shields.

These mechanics should be applied through the centralized combat pipeline (see Section 5).

Stat sources and calculation

Final character stats are calculated from all applicable sources:

• Base character values.
• Primary attributes.
• Equipment.
• Talents.
• Abilities.
• Buffs and debuffs.
• Temporary modifiers.

The StatsComponent is responsible for combining these values.

Systems should request calculated stats from StatsComponent rather than independently calculating them.

Stat conversions and scaling formulas should be centralized and data-driven where appropriate.

The exact conversion rates, diminishing returns, caps, and mitigation formulas are balance decisions and should not be hardcoded into individual abilities or equipment definitions.

Gear stat generation

Gear can roll three categories of stats:

• Primary attributes.
• Secondary stats.
• Tertiary stats.

The number of stats rolled depends on rarity:

The roll counts, the chance of each count within a range, and the stat value ranges must all be tunable data, not hardcoded.

Legendaries are hand-made with unique effects and do not use these roll rules.

Role-based secondary stat pools contain five stats each.

Vigor is included in every role pool.

The Support role needs its own stat pool. Its contents are an open design decision.

Damage and healer pools also include a defensive stat so that defensive rolls are not entirely wasted.

Armor type determines equipment eligibility, not which stats an item can roll.

For example, a healer whose class wears plate can receive plate armor with Intelligence and Spell Power.

Primary attributes and secondary stats remain separate rolls. An item can have Might and Attack Power, for example, because they contribute to the same offensive direction through different mechanisms.

See Section 13 for loot generation steps and equipment slot rules.

13. Equipment and Gear

There are nine equipment slots:

1. Head
2. Chest
3. Hands
4. Legs
5. Feet
6. Main Hand
7. Off-hand
8. Amulet
9. Ring

Weapons and off-hand equipment

The off-hand slot can contain:

• Shields.
• One-handed weapons for dual-wielding.
• Tomes.
• Orbs.
• Other class-specific equipment.

Shields have base Armor and base Block. Base Block contributes to the character's effective Block value; the exact conversion can be tuned later (see Section 12).

Two-handed weapons occupy both the main-hand and off-hand slots.

Two-handed weapons compensate for occupying two slots through higher stat values. They roll the same number of stats as a one-handed weapon of the same rarity, but with larger values. How much larger is tunable.

Armor types

There are four armor types, from lightest to heaviest:

• Cloth
• Leather
• Mail
• Plate

Base Armor rises in clear steps from cloth to plate: each heavier type has noticeably more base Armor per piece. The values are tunable.

Which class wears which armor type is pending. The assignment will be added here once provided.

A class can have a tank specialization without wearing the heaviest armor. Its abilities and talents must then compensate for the lower base armor compared to plate tanks.

Armor type determines equipment eligibility, not which stats an item can roll.

For example, a healer whose class wears plate can receive plate armor with Intelligence and Spell Power.

Base armor

Armor is an equipment value, not a character attribute or secondary stat. It contributes to physical damage mitigation alongside the Toughness secondary stat.

• Most armor pieces provide base Armor.
• Weapons, rings, and amulets do not provide base Armor by default.
• Shields provide base Armor.

Shields separately provide Armor and Block.

Other off-hand items, such as tomes and orbs, have no base Armor or other base value. They carry only the normal stat rolls for their rarity.

Randomized gear stats

Each gear piece receives randomized stats based on rarity.

The number of primary, secondary, and tertiary stats depends on rarity. See the roll table in Section 12 (Gear stat generation).

Primary attributes and secondary stats are separate rolls. An item can have both Might and Attack Power, for example.

Personal and role-aware loot

Loot is personal.

The loot generation process has two steps.

Step 1: Determine the item type

Select a random valid equipment slot and item type based on:

• Player class.
• Armor eligibility.
• Weapon restrictions.
• Off-hand restrictions.

Step 2: Roll the stats

Roll stats from a gear pool. A gear pool is selected by combining the player's class and dungeon role:

• The class selects the armor type.
• The role selects the three primary attributes the item can roll.

Example for a Paladin, who wears plate:

Each pool holds three primary attributes. This fits the roll table in Section 12: Common items roll 2 of the 3, Rare items 2 or 3, and Epic items all 3.

For the Damage role, the player also picks a loot focus, physical or magical, in the Bubble Room. It decides whether Damage gear rolls Might or Intelligence, and it locks with the role when the run starts.

Gear pools are data. The pools for the remaining class and role combinations are still to be defined.

Role-based secondary stat pools contain five stats each.

Vigor is included in every role pool, with its contribution subject to balance tuning.

Damage and healer pools also include a defensive stat so that defensive rolls are not entirely wasted.

Stat pools should use role templates with optional class-specific adjustments.

The player's role should be captured for the dungeon run and used consistently for loot generation.

Players should not be able to manipulate their role immediately before loot drops to influence the result.

Boss loot tables

Each boss has its own loot table.

• A boss favours certain equipment slots or item types.
• A boss has its own hand-made Legendaries.

Bosses are fixed per dungeon and are not randomized (see Section 16), so players can choose a dungeon to hunt specific bosses and loot, and prepare for them.

Stats on boss drops are still rolled from the player's role pool.

14. Gear Progression and Economy

Players can improve their gear through several systems.

Gear upgrades

Gear can be upgraded using gold.

The maximum upgrade level is limited by the highest dungeon tier completed on the current class.

Progression is tracked per class.

Salvaging

Unwanted gear can be salvaged into crafting materials.

Selling

Unwanted gear can instead be sold to a vendor for gold. Salvaging gives materials; selling gives gold.

What gold and materials are for

• Gold: gear upgrades, extra build slots, and stash space.
• Materials: the three reroll services.

Materials cannot be bought with gold, the reroll services do not cost gold, and there are no cosmetics bought with gold.

Stash

Secured loot goes to the stash. The stash is shared across the account.

The stash has a limited number of slots, which can be expanded with gold. The limit pushes players to salvage gear they do not need.

The starting size, expansion size, and gold prices are tunable.

Rerolling

A hub NPC offers three separate services, each paid for with materials:

1. Reroll stats: rerolls which stats the item has, as if it had dropped again. Rarity stays the same.
2. Reroll values: keeps the item's stats and rerolls only their values.
3. Rarity upgrade: a chance to raise the item's rarity by one step. The chance is low, so players still hunt for Epic drops.

Legendaries cannot be created through a rarity upgrade.

All three services are balanced through their material costs. The exact costs and the upgrade chance are tunable.

15. Dungeon Groups and Matchmaking

Dungeon groups can contain 3–5 players.

The design target is three players, with one tank, one healer, and one damage dealer being the default composition.

Players can form groups with friends or use matchmaking.

Matchmaking is leader-driven. A leader lists a run with the roles they want, and matchmaking fills those slots with players queueing in those roles. The leader is free to ask for any composition.

There are no hard role restrictions.

Groups can choose unusual compositions, such as:

• Two damage dealers and one healer.
• Two tanks and one damage dealer.
• Three damage dealers.
• Other combinations.

The game should allow players to experiment with different group setups.

Group leader

The group leader selects:

• Dungeon.
• Dungeon tier.
• Affixes.

The server validates that the group is eligible to enter.

Dungeon tier progression

The highest selectable tier is based on the lowest completed tier among all group members, using their current class.

The group can select one tier above that lowest completed tier.

Progression is tracked per class and across all dungeons, not independently per dungeon.

A player starting a new class cannot use progression from another class to immediately access high tiers.

Long-term goals

Tiers are endless. There is no maximum tier, and pushing higher tiers is the main long-term goal, with gear upgrades following the tier reached.

How enemy health and damage grow per tier is an open design decision, to be settled once gear upgrade costs are known. The curve must be tunable data.

Because progression is per class, gearing and pushing tiers on more classes is the second long-term goal. A wide class roster is part of the game's replayability.

Group-size scaling

Three players is the design target. For groups of 4 or 5, only enemy health scales.

The respawn pool stays at 10, and the kill counter and objective targets stay fixed.

Leaving and disconnects

Penalties are lighter than in the MVP:

• A player who leaves a run loses their unsecured loot.
• A disconnected player can reconnect to the run within 2 minutes. After that it counts as leaving.
• There is no matchmaking lockout.

Abandoning a run:

• The group can abandon a run by majority vote.
• Everyone loses their unsecured loot, gold, and materials. Secured loot is kept.

When a group drops below 3 players:

• The run continues for the remaining players.
• The leader decides whether to reopen the empty slot to matchmaking, so a new player joins mid-run. There is no automatic refill.
• Enemy health does not change while the group is short-handed.

Hub and training ground

Between runs, the hub starts as a set of menus: builds, gear, NPC services, group, and matchmaking. A walkable social hub can come later.

There must be a training ground from the start. It is a playable area with target dummies where players can practice and try different builds. Talents, abilities, and saved builds can be changed freely there.

16. Dungeon Structure and Generation

Dungeon runs should last approximately 10–20 minutes.

Each run should ideally have a randomized layout.

Use predefined room templates and connections rather than attempting to generate every room procedurally from scratch.

A dungeon layout should be reproducible from a seed.

This makes debugging, testing, and multiplayer synchronization easier.

What changes between runs of the same dungeon:

• The order of rooms.
• Which side rooms and checkpoints appear.
• Which enemy packs spawn.

What never changes:

• The dungeon's bosses. Bosses are fixed so players can choose a dungeon for specific bosses and loot, and prepare for them.

Run objectives

To complete a dungeon, the group must:

1. Kill the final boss.
2. Fill a mob kill counter. The target is tuned per dungeon and can be finished before or after the boss.

Each run also draws 2 optional objectives at random, such as "interrupt 10 times" or "explore a side room".

• Objectives are group-wide and visible from the start of the run.
• Optional objectives are always completable and never depend on a chance spawn.
• Optional objectives pay extra gold, only if the dungeon is completed successfully.

Dungeon composition

A dungeon can contain:

• Main progression rooms.
• Enemy encounters.
• Boss rooms.
• Optional side rooms.
• Chests.
• Extra bosses.
• Checkpoints.

The layout should combine relatively linear progression with optional exploration.

Optional rooms can provide additional rewards or encounters.

Bubble Room

Every dungeon starts in a safe preparation area called the Bubble Room.

Players can:

• Adjust talents.
• Change equipped abilities.
• Switch saved builds.
• Prepare for the dungeon.

Each player has an orb.

Interacting with the orb signals that the player is ready.

The dungeon begins once all players are ready.

Checkpoints

Checkpoints are optional, and not every run contains one.

Reaching a checkpoint has a cost, which is what makes it a risk-versus-reward choice:

• A checkpoint sits off the main path, so it is a detour.
• A checkpoint is guarded and must be fought for.

The group decides whether to go for a checkpoint.

Checkpoints have two important functions:

1. Secure any unsecured loot carried by the player.
2. Refill the player's potions.

Loot security is personal. Each player manages their own secured and unsecured loot.

Checkpoint interactions must be validated by the server.

17. Loot Security and Dungeon Failure

Loot dropped during a dungeon run is initially unsecured.

Players have two states for their loot:

• Unsecured.
• Secured.

Unsecured loot is at risk.

It becomes secured when:

• The dungeon is successfully completed.
• The player interacts with a checkpoint.

If the dungeon run fails, all unsecured loot is lost.

Secured loot survives.

Each player tracks their own loot. One player's checkpoint interaction does not automatically secure loot for the entire group.

This creates a risk-versus-reward decision when deciding whether to take optional checkpoints.

18. Deaths, Respawns, and Group Resurrection

Shared respawn pool

Each dungeon run starts with a shared pool of 10 respawns.

The group collectively has 10 respawns available.

A dead player chooses to release or to wait. Releasing costs 1 respawn from the pool and respawns the player at the last used checkpoint, or at the dungeon start if none was used.

Once the pool is empty, nobody can release. The run continues for the players who are still alive and ends only when all players are dead.

When the run ends this way, unsecured loot is lost.

Group resurrection

There is exactly one group resurrection available per dungeon run.

It is not a class ability.

In the game's fiction, the resurrection uses the remaining energy from the keystone that opened the dungeon. The keystone is flavor only. It is not an item, and runs are started by the leader's selection (see Section 15).

The resurrection does not cost a respawn from the pool.

The group decides when to use it.

It can be used both in and out of combat.

Once used, it cannot be used again during that run.

The server validates the resurrection and handles the resulting state changes.

19. Dungeon Affixes and Difficulty

Affixes modify dungeon gameplay and create additional challenges or advantages.

Affixes should be implemented as independent, reusable systems rather than hardcoded directly into the dungeon manager.

The dungeon manager should coordinate affix activation and lifecycle, while individual affixes respond to relevant gameplay events.

Affix categories

There are two types of affixes:

Helpful affixes

Provide advantages or beneficial modifications to the players or dungeon run.

Harmful affixes

Introduce additional challenges, disadvantages, or dangerous mechanics.

Affix limits

A dungeon can have a maximum of 10 affixes total.

The leader picks freely from the game's full affix list. Every affix is available for every dungeon, and picking none is allowed.

The combination can contain any mix of helpful and harmful affixes.

Examples:

• 10 harmful affixes.
• 7 harmful and 3 helpful.
• 5 harmful and 5 helpful.
• 2 harmful and 8 helpful.
• 10 helpful affixes.

There is no requirement for a fixed number of either category.

Timer

Runs are untimed by default. The timer is a harmful affix.

When the timer affix is active, each dungeon has its own timer length. If the timer runs out, the run fails and unsecured loot is lost.

Affix reward scaling

The balance between helpful and harmful affixes affects dungeon rewards.

• More harmful affixes increase rewards.
• More helpful affixes decrease rewards.

Each affix carries its own two modifiers:

• A gold modifier.
• A gear modifier (drop rate).

Harmful affixes have positive modifiers and helpful affixes have negative ones. The run's reward modifier is the sum of the modifiers of all active affixes, calculated separately for gold and for gear.

This means which affixes are active matters, not just how many.

The modifier values per affix are still to be balanced and must be tunable data on the affix definition.

Affix architecture

Each affix should have a definition describing:

• Stable ID.
• Name.
• Description.
• Icon.
• Category: Helpful or Harmful.
• Relevant parameters.
• Any restrictions or compatibility rules.

Runtime affix instances should handle the actual behavior.

Affixes should subscribe to or react to relevant gameplay events.

Examples of possible event sources:

• Enemy spawned.
• Enemy died.
• Player took damage.
• Player used an ability.
• Boss encounter started.
• Boss phase changed.
• Checkpoint activated.
• Dungeon room entered.

Avoid building a large collection of special cases into the DungeonManager.

20. Player Movement and Camera

The game uses a high top-down camera that follows the player.

Movement

• WASD for movement.
• Space for jumping.
• Players and enemies do not collide with each other.
• Players and enemies still collide with walls and terrain.

Jumping is cosmetic to begin with. The design keeps two options open for later: jumping over certain ground effects or shockwaves, and traversal such as gaps or ledges. The movement system should not rule either out.

Facing direction

The character's facing direction follows these rules:

1. If a target exists, face the target.
2. Without a target, face the movement direction.
3. When standing still, keep the last movement direction.
4. Casting a ground-targeted spell does not rotate the character.

Facing direction has no mechanical effect on player abilities.

21. Targeting and Controls

The mouse is used to select targets and place ground-targeted abilities.

The mouse does not aim normal attacks.

Targeting

• Tab: Cycle through enemies, similar to WoW tab targeting.
• F1–F5: Target party members.
• F1 targets yourself.

Auto-targeting for harmful abilities

Like in WoW, using a harmful ability without a valid enemy target automatically targets the nearest enemy.

Rules:

1. If the player has a valid hostile target, the ability uses that target as normal.
2. If the player has no target, or the current target is not a valid hostile (a party member, yourself, or a dead enemy), the game selects the nearest valid enemy.
3. A valid enemy is alive, hostile, within the ability's range, and in line of sight.
4. The selected enemy becomes the player's current target, so the facing rules in Section 20 apply as usual.
5. If no valid enemy exists, the ability fails with a "No target" message. No resource is spent and no cooldown or global cooldown is triggered.

"Nearest" is measured by distance from the player. Facing direction does not matter, since facing has no mechanical effect on player abilities.

Selection is always pure distance. Idle enemies are not skipped in favour of enemies already in combat, so an accidental pull is the player's responsibility.

Enemies under crowd control that breaks on damage, such as a sheep, are not skipped. If such an enemy is the nearest valid enemy, it is selected. Players are responsible for avoiding breaking crowd control.

Auto-targeting does not apply to:

• Ground-targeted abilities, which are still placed with the mouse.
• Abilities without a target, such as self-centered area effects.

Auto self-cast for helpful abilities

Like WoW's auto self-cast, using a helpful ability without a valid friendly target casts it on yourself.

Rules:

1. If the player has a valid friendly target (a party member or yourself), the ability uses that target as normal.
2. If the player has no target, or the current target is an enemy or a dead ally, the ability is cast on yourself.
3. Self-casting does not change the player's current target. An enemy target stays selected.

Like auto-targeting, the server makes the final target decision using the same shared targeting function.

Multiplayer: the server makes the final target selection using authoritative positions and the same selection rule. The client can run the same rule to preview the target for responsiveness, but the server's choice wins and is replicated back.

The selection rule should live in one shared targeting function used by both the client preview and the server, not be reimplemented per ability.

Ground-targeted abilities

• Left-click: Place the ability.
• Right-click or Escape: Cancel placement.

Casting a ground-targeted ability does not change the character's facing direction.

Interaction

• F: Interact with checkpoints, chests, and the start orb.
• Right-click: Also interact with relevant objects.
• C: Open character and stash interface.
• Enter: Open chat.
• Middle mouse: Place a ping.

Action bar

There is one action bar with 14 slots.

All keybindings can be rebound.

Votes, such as abandoning a dungeon, are answered using the mouse.

22. Potion System

Players have a health potion and a resource potion.

Potions are part of the utility action bar rather than the 10 equipped class abilities.

Potion usage should be handled by a dedicated system.

It should support:

• Cooldowns.
• Charges or other usage limits if introduced.
• Server-side validation.
• Healing or resource restoration.
• UI updates.
• Checkpoint refills.

Interacting with a dungeon checkpoint refills the player's potions.

The refill should be handled by the server and replicated to the client.

Potion rules:

• Each potion has 3 uses.
• The two potions share a 30-second cooldown.
• Potions refill at checkpoints and when a player first loads into the dungeon. Reconnecting does not refill them.

Rest

Rest is a utility ability every class has, outside the 10 class abilities.

• An 8–10 second channel that restores health and resources.
• The player cannot move while resting.
• Usable out of combat only.
• 60-second cooldown. An interrupted Rest still starts the cooldown.
• Rest and potions are not affected by the global cooldown.

A player in the Healer role can Rest in combat. Damage does not interrupt it, but moving cancels it.

All Rest and potion numbers are tunable.

23. UI Architecture

UI should subscribe to runtime systems through signals rather than directly modifying gameplay state.

Examples:

• Health bars listen to HealthComponent.
• Resource bars listen to resource changes.
• Ability bars listen to cooldown and ability state changes.
• Buff and debuff displays listen to EffectsComponent.
• Character sheets read calculated stats.
• Talent trees read and modify build state through validated requests.
• Inventory reads equipment and item state.

The client can optimistically update non-critical presentation where appropriate, but the server remains authoritative over gameplay.

Avoid putting gameplay calculations inside UI scripts.

HUD layout

The combat HUD carries over from the MVP:

• WoW-style floating frames, kept minimal.
• Player buffs and debuffs in the top-right corner, buffs above debuffs.
• Objective tracker below them, with a minimize button.
• Enemy nameplates show health, resource, and cast bar.
• Crowd-control icons with a timer appear above enemy nameplates and to the right of party frames.

Nameplates

Nameplates must never overlap. When several units stand close together, their nameplates stack so that every nameplate stays readable and clickable.

Rules:

1. Each nameplate is anchored above its unit.
2. If a nameplate would overlap another one on screen, it is pushed upward until it no longer overlaps.
3. The nameplate's full height counts when checking for overlap, including the cast bar and crowd-control icons.
4. Units closer to the bottom of the screen are placed first and keep their anchor position. Units further up are pushed. This keeps stacking stable as the top-down camera moves.
5. The current target's nameplate is always drawn on top and highlighted.
6. Nameplates move smoothly to their stacked position rather than snapping, to avoid jitter when units move around each other.
7. Nameplates are clamped to the screen edge rather than being pushed off-screen.
8. No line is drawn between a pushed nameplate and its unit.

Nameplate stacking is purely client-side presentation. It does not affect gameplay and is not replicated.

Nameplates above party members are a setting, off by default. When turned on, they stack by the same rules as enemy nameplates.

There is no limit on how far a nameplate can be pushed from its unit. Nameplates keep stacking upward as far as needed and are only stopped by the screen edge. This is the starting rule, to be checked in playtesting with large pulls.

Navigation

There is no minimap and no map screen. Players find their way by exploring, helped by pings from other players and by world dressing.

World dressing is the only hint system: torches, banners, paths, and lighting lead toward the main route, and side rooms look visibly different. There are no HUD arrows or markers.

Room templates must therefore be built with readable main-path and side-room dressing.

24. Persistence

Player data should be saved using stable identifiers.

Persist:

• Player account and character data.
• Unlocked content.
• Class progression.
• Dungeon tier progression per class.
• Saved builds.
• Talent allocations.
• Equipped abilities.
• Equipment and inventory.
• Currency.
• Purchased build slots.
• Settings and keybindings.

Do not persist temporary dungeon state as permanent character progression unless explicitly required.

Dungeon runs should have their own runtime state and lifecycle.

The persistence system should be designed so that adding new fields or changing definitions does not unnecessarily invalidate existing player data.

25. Suggested Project Structure

The exact folder structure can evolve, but keep related definitions and runtime systems organized.

Example:

res://
  assets/
    icons/
    models/
    audio/
    textures/
  data/
    classes/
    abilities/
    talents/
    items/
    resources/
    effects/
    affixes/
    dungeons/
    enemies/
  scenes/
    characters/
    enemies/
    dungeons/
    ui/
    world/
  scripts/
    core/
      game_database.gd
    data/
      definitions/
      runtime/
        builds/
        equipment/
        effects/
        dungeons/
    components/
      stats_component.gd
      health_component.gd
      shield_component.gd
      effects_component.gd
      combat_component.gd
    combat/
      combat_manager.gd
      damage_info.gd
    abilities/
      ability_manager.gd
      ability_calculator.gd
    progression/
      progression_manager.gd
    inventory/
      inventory_manager.gd
    multiplayer/
      network_manager.gd
      server_authority.gd
    ui/

This is a starting point, not a requirement to create every folder immediately.

26. Implementation Priorities

Implement the systems in a way that allows each layer to be tested independently.

Suggested order:

1. Core definitions and GameDatabase.
2. Character stats and stat modifiers.
3. Health, shields, damage, and healing.
4. Status effects.
5. Resources and resource generation.
6. Abilities and ability calculations.
7. Talent trees and build validation.
8. Equipment and randomized stat generation.
9. Inventory and persistence.
10. Authoritative multiplayer integration.
11. Group and matchmaking systems.
12. Dungeon generation and room progression.
13. Checkpoints, loot security, and potions.
14. Dungeon affixes and reward scaling.
15. Death pool and group resurrection.
16. UI and player-facing systems.
17. Balancing and content expansion.

Multiplayer authority should be established during the implementation of each gameplay system, not postponed until the end.

27. Existing Starter Project

A code-first Godot starter project has already been generated.

It contains:

• Resource definitions for classes, specializations, talent trees, talents, abilities, modifiers, and resources.
• Runtime character build representation.
• Build validation.
• Ability calculations.
• Dummy content for a Vanguard class.
• Two sample specialization trees: Bulwark and Ravager.
• A demo scene.

The starter demonstrates:

• Shared 21-point talent allocation.
• Class-wide ability pools.
• Talent-gated abilities.
• A maximum of 10 equipped abilities.
• Ability modifiers and effective tooltip values.
• Primary and secondary resources.

It is a starting point for the build system, not a complete implementation of the architecture described here.

It has not been verified in the Godot editor and should be reviewed before being used as the foundation for production systems.

Known issues in the starter

1. BuildValidator.remove_rank

The current implementation removes a talent rank and validates before removing equipped abilities that may have become locked.

The correct behavior should be:

• Snapshot the old talent rank and equipped abilities.
• Remove the talent rank.
• Remove abilities that are no longer unlocked.
• Validate the remaining build.
• Restore both the talent rank and abilities if validation fails.

2. Ability unlocking

The current is_ability_unlocked implementation can return true when required_talent_id is empty, even if a talent explicitly lists the ability in unlocks_abilities.

Unlock rules need to be explicit and unambiguous.

3. AbilityCalculator multiplicative modifiers

The current calculation uses pow(1.0 + amount, rank) where amount already includes rank.

This effectively applies the rank twice.

The calculation should use:

pow(1.0 + modifier.value_per_rank, rank)

4. Redundant ability unlock definitions

The dummy bulwark_slam ability has a required talent and is also listed in talent unlock arrays.

Choose one clear unlocking approach rather than maintaining redundant requirements.

5. Talent unlock rank

TalentDefinition.unlocks_abilities currently uses one unlock rank for all abilities listed.

If different abilities need different unlock ranks, this should eventually be represented per ability.

6. Demo point allocation

The demo spends 11 points and is valid:

• 3 points in Bulwark Guard.
• 2 points in Bulwark Mastery.
• 3 points in Ravager row 1.
• 3 points in Bulwark Bash row 1.

7. Capstone validation

_choice_group_is_valid currently handles mutually exclusive capstones.

Keep this behavior when improving build validation.

8. Talent rank removal

Rank-zero entries are removed during rank removal. Allocation increments ranks.

28. Important Design Constraints

Keep these decisions consistent throughout implementation:

• The game is multiplayer and server-authoritative.
• There are no character levels.
• Players have 21 talent points from the beginning.
• Talent points are shared across specialization trees belonging to a class.
• Each specialization has a 4×5 talent tree.
• Normal talents have up to three ranks.
• Only one of the two capstones in a tree can be selected.
• Classes own their ability pools.
• Players can equip a maximum of 10 class abilities.
• Each class starts with one build slot and can purchase up to two more.
• There are exactly four primary attributes: Might, Intelligence, Agility, and Stamina.
• Attack Power affects physical damage.
• Spell Power affects magical damage and healing. There is no Healing Power stat.
• Critical Chance applies to both damage and healing.
• Vigor affects primary resource generation, not maximum resource capacity.
• Haste affects attack speed and casting speed, not cooldowns. Cooldown Reduction is a separate tertiary stat.
• Agility affects Critical Chance and Dodge, not attack speed.
• Toughness is a secondary stat.
• Armor and shield Block are equipment values, not character attributes or secondary stats.
• Armor and Toughness must be combined without applying the same mitigation twice.
• Life Steal is based on actual health damage dealt.
• Parry requires a melee weapon and prevents part of the damage, with a chance to prevent all of it.
• Block requires a shield and removes a fixed amount from every physical hit, with no chance roll.
• Fortune increases gold only, never gear drops.
• Avoidance is resolved first in the damage pipeline; Block is subtracted after Armor and Toughness.
• Base Armor rises in clear steps from cloth to plate.
• Two-handed weapons roll the same number of stats as one-handers, with higher values.
• The Support role package applies to every ability typed Utility.
• Final stats are calculated by StatsComponent; other systems do not calculate stats independently.
• Gear drops are personal and role-aware.
• Checkpoints secure loot and refill potions.
• A dungeon can have up to 10 helpful and harmful affixes combined.
• More harmful affixes increase rewards; more helpful affixes decrease rewards.
• Each run has a shared pool of 10 respawns. At zero, the run continues for survivors and ends when all players are dead.
• Each run has exactly one group resurrection. The keystone is flavor only, not an item.
• Dungeon layouts are randomized using predefined room templates and connections. Room order, side rooms, and enemy packs vary; bosses are fixed.
• Each boss has its own loot table.
• There are four roles: Tank, Healer, Damage, and Support. Each has a small role package.
• There are currently 22 classes and the roster will grow. Each class has 2 or 3 specializations.
• Changing a build is free, and the build locks when the run starts.
• Leaving a run costs unsecured loot; there is no matchmaking lockout.
• There are four armor types: cloth, leather, mail, and plate.
• Tiers are endless.
• For groups of 4 or 5, only enemy health scales.
• The leader picks up to 10 affixes from the full affix list. The timer is a harmful affix, not a base rule.
• Gear roll counts depend on rarity and are tunable data.
• Gear stats roll from gear pools selected by class (armor type) and role (primary attributes).
• Each affix has its own gold modifier and gear modifier; a run's reward modifier is their sum.
• Unwanted gear is salvaged for materials or sold for gold. Gold buys upgrades, build slots, and stash space; materials pay for rerolls.
• Movement cancels casts by default, and a global cooldown applies to class abilities.
• Rerolling stats, rerolling values, and rarity upgrades are three separate services.
• Checkpoints are a guarded detour.
• There is no minimap.
• The hub starts as menus, plus a training ground with target dummies.
• Harmful abilities used without a valid enemy target automatically target the nearest valid enemy; the server makes the final choice.
• Helpful abilities used without a valid friendly target are cast on yourself.
• Nameplates never overlap; they stack on the client.
• The server validates all gameplay-critical actions.

29. Instructions for the Next Development Session

When continuing development:

1. Read this handoff before making architectural decisions.
2. Inspect the existing Godot project and its current implementation.
3. Do not assume that every planned system already exists.
4. Preserve the design decisions documented here unless explicitly asked to change them.
5. Prefer complete, working implementations over isolated snippets when implementing a system.
6. Keep systems modular and data-driven without introducing unnecessary abstractions.
7. Consider multiplayer authority in every gameplay-related implementation.
8. Explain important architectural decisions and trade-offs.
9. Identify existing bugs before building additional functionality on top of them.
10. Do not silently change established game design decisions.

The goal is a maintainable multiplayer RPG architecture that can support a growing amount of classes, abilities, talents, items, enemies, dungeons, and affixes without requiring major rewrites every time new content is added.