Abilities, Loadouts, And Progression
What This System Is
The ability catalog is the canonical authored source for player abilities, named hotbar loadouts,
and the player experience/stat curve. It is shared by preview, the runtime client, and game-server
authority through aether-world-domain.
The first shipped slice migrates the Dragoon hotbar without changing its gameplay values. Other legacy combat actions continue to use their compatibility definitions until they are migrated.
How Authors Use It
Authors edit the ability catalog, named loadouts, and progression policy in the authored asset, then validate the shared world-domain projection before changing client or server adapters.
Authored Asset
Edit assets/gameplay/ability_catalog.json. The root document contains:
abilities: identity, UI copy, execution kind, animation action, aliases, requirements, costs, combo links, effect applications/consumption, trusted combat values, and presentation cues;loadouts: named one-based slot assignments referencing ability ids;progression: experience per level, level-one stats, per-level stat growth, and per-second resource regeneration.
IDs are case-insensitive at lookup boundaries but should be authored in lower-case snake case. Animation action IDs and aliases retain compatibility with existing wire and preview action tokens. Effect ids resolve through the Status Effects And Combat Modifiers catalog; unknown cross-catalog references reject runtime hot reload.
Rules And Invariants
Ability ids, aliases, animation action ids, and loadout slots are stable gameplay contracts. Server authority owns costs, cooldowns, combat values, requirements, progression, and resource regeneration.
Authority Contract
Clients request an action by id. Combat authority resolves that id through the ability catalog and owns its base amount, damage kind, cooldown, target offsets, presentation cues, and knockback rule. It rejects abilities whose minimum level, required character tags, or unlock IDs are not satisfied.
The equipped tool is projected to an authority tag such as weapon:polearm; clients cannot supply
that tag. Quest and gameplay rewards can satisfy authored unlock_ids through the existing
authoritative unlock state.
Player level and maximum health, mana, and stamina are derived from the catalog progression policy. The current linear values remain 100 XP per level and growth of 12 health, 8 mana, and 6 stamina. Those base values feed the Character Stats And Equipment Modifiers resolver, which adds authoritative equipped-item contributions before publishing player stats.
Ability activation also debits stamina and mana on the server and starts the catalog cooldown only after authority accepts the action. The server regenerates resources from the authored progression rates before validating each activation. A client-reported resource value or cooldown cannot make an otherwise unaffordable action succeed.
Client And Hotbar Contract
The default Dragoon hotbar is projected from the dragoon.default loadout. Slot order, labels,
descriptions, passive readiness, and runtime action identity come from the referenced abilities.
Input bindings remain a client adapter keyed by the authored one-based slot.
Players can submit an AbilityLoadoutCommand with an expected revision and up to twenty unique
one-based slots. The server validates the loadout and every ability against level, authoritative
equipment tags, and unlock state, then persists the canonical projection in the existing character
gameplay-state document. The namespaced keys are ability_loadout.revision,
ability_loadout.id, and ability_loadout.slot.XX. Replicated gameplay-condition snapshots apply
that persisted projection to the client hotbar after login and after successful edits.
Runtime Authoring
The client/editor watches assets/gameplay/ability_catalog.json and atomically swaps in a changed
catalog every 500 ms, but only if parsing and validation succeed. A rejected edit leaves the last
valid catalog active and writes a diagnostic. The Items editor includes an Abilities & Loadouts
inspection card with counts, costs, requirements, cooldowns, named slot projections, and a manual
Reload and validate catalog action.
Game-server authority deliberately keeps its startup catalog for the lifetime of the process so a live client edit cannot silently change trusted combat balance. Deploy catalog balance changes with the server content revision/restart workflow.
Validation And Debugging
Catalog loading rejects:
- unsupported schema versions;
- missing or duplicate ability IDs;
- colliding aliases or animation action IDs;
- attacks without combat definitions;
- melee attacks without target offsets;
- missing damage kinds;
- loadouts with zero or duplicate slots;
- loadout or combo references to missing abilities;
- a zero experience-per-level policy.
Run cargo test -p aether-world-domain ability_system for schema and projection checks. Run the
game-server progression/combat tests and the client hotbar tests after changing shipped values.
Examples
Migrating one Dragoon action means adding its authored ability row, preserving existing wire and animation aliases, adding it to the intended loadout slot, validating the catalog, and only then removing legacy combat rows.
Migration Guidance
Migrate one action family at a time. Add the authored definitions and loadout first, preserve the existing animation/wire aliases, then remove that family's legacy combat rows only after client, server, and replay fixtures pass. Do not create a second UI-only description or balance table.