View source for Collab session notes/2026-08-13 Ability-Skill-Affinity Progression Model

''Synthesized by an AI from a live Tyler ↔ Bembi design conversation on 2026-08-13. A record of what was discussed, not settled design — session notes, not canon.''

== Background ==
Starting point for this session: stats currently in the codebase are D&D-derived (STR/DEX/CON/INT/WIS/CHA) and were only ever placeholder — "just something we pulled in to have something." The session worked through what should replace them, building on the existing Pneuma affinity/mastery mechanic rather than starting cold.

== Decision: three-layer progression model ==
D&D stats are replaced entirely by three layers:

# '''Ability''' — the atomic unit. Every discrete thing a character can do (cast Fireball, net salmon, harpoon shark, swing a sword, jump, blink, pickpocket) tracks its own mastery, which grows from use. Abilities are also what gets keybound.
# '''Skill''' — a grouping of related abilities (e.g. Fishing = netting + harpooning + ...). Groupings are meant to be discovered '''bottom-up''': lay out the actual granular ability list first, then see what clusters naturally, rather than designing a taxonomy up front. Weapon-type distinctions (sword vs. mace vs. unarmed) are expected to fall out of this same pass rather than being decided now.
# '''Affinity''' — a passive, ''optional'' byproduct, global per element (not per skill). Any elementally-themed ability, across any skill, feeds and draws from the same element's affinity pool — e.g. heavy smithing/smelting use and fire-spell casting could both feed and benefit from one global Fire affinity. Not every ability produces or needs an affinity; it's not a gate or requirement, just a bonus layer that applies where thematically relevant (fishing and thievery, for instance, are not expected to have one).

An earlier "thematic quadrant" idea (grouping all abilities under broad stats like Might/Finesse/Mind/Spirit) was raised and set aside again — no payoff beyond a label, same reason it didn't stick previously. The bottom-up, per-ability approach was preferred instead.

HP and Pneuma remain two separate pools (RS/WoW-style), not unified into one resource. Pneuma is specifically the combat/magic resource (spellcasting and physical combat abilities draw from it); HP is bodily integrity. Spending Pneuma to heal HP (a heal spell) is normal and not circular under this split.

'''Wiki pages created this session:''' [[Ability]], [[Skill]], [[Affinity]] (the latter cross-links to the existing [[Pneuma]] page, which remains the canonical home for the deeper mastery/affinity mechanics).

== Combat resolution: dice vs. positioning ==
A related question came up: should combat outcomes lean on dice (RS-style accuracy rolls, mastery nudging hit chance) or should landing a hit be primarily a positioning/player-skill question, with mastery scaling magnitude and cost rather than whether an attack connects at all?

Both participants leaned toward '''positioning-based''' resolution: melee connects if you're adjacent and swing; spells/AoE resolve based on where they actually land; ability mastery scales damage, cost, and cooldown rather than hit chance. Auto-attack-style "basic attack" may still use a simpler always-hits-if-in-range model.

This pushes a real open engineering question onto the tick system: on a 400&nbsp;ms tile grid, if a target is moving when a tile-targeted ability (e.g. a fireball) is fired, which tile should it resolve against? The suggested approach is to reuse the tick-snapping logic already designed for movement timing — resolve against the target's committed position for the next tick boundary, rather than raw input-time position — but this hasn't been designed in detail and is flagged as the next real design question once ability targeting is actually built.

== Open / parked items ==
* '''Auto-attack''': currently in the game as a placeholder. Decision: leave it in for now rather than removing it, since removing it requires abilities to fully replace its role first.
* '''Ability-targeting resolution against moving targets''' (tick-boundary snapping, as above) — unresolved, deferred to implementation time.
* '''Damage formula''': no final formula was locked in. The existing code's accuracy-roll / max-hit / armor-mitigation shape (RuneScape-style) was discussed as a reference point, not a commitment — the group is not attached to it and may diverge, especially given the lean toward positioning-based hit resolution.

== Next step ==
Build out the actual granular ability list (per skill area — combat, fishing, magic, utility like jump/blink, etc.) so that skill groupings and any affinity assignments can be derived bottom-up, per the model above.

[[Category:Collab session notes]]