Design — Characters & Traits

High-level design for what a character is. Answers to the pillars in ../GAME_DESIGN.md; see especially §2 (positions need living vessels), §4 (the generational layer), §5 (elections). This is a design doc — the model and its rules, not an implementation plan.

The five-attribute model, the attribute→effect mapping (§2), and attributes-as-skills (§3) are signed off. Remaining 〔WM〕 marks and open questions are collected in the last section.

1. What a character is

A character is the atom of the whole game. Every family member who fills an office, manages a shop, crafts a good, trades at market, or stands for election is a character. Characters age, work, learn, reproduce, and die. The dynasty is nothing but its living characters (§4, §6 — bloodline extinction is the only hard loss).

A character is defined by three things:

Identity — name, dynasty membership, age, lifecycle stage, alive/dead.
Attributes — five numbers that quantify capability (below).
Traits — discrete named qualities, some of which adjust attributes and some of which change behaviour or lifecycle (§4).

Already in code (the foundation we build on)

The attribute pipeline exists and is well-shaped — traits and position bonuses plug straight into it:

CharacterComponent — base stats: name + strength, dexterity, constitution, handcraft, charisma (loaded from the DB).
AttributeModifiersComponent — a vector of AttributeModifiers, each a delta to the five attributes “from any source (equipment, buff, debuff…)”.
CharacterAttributesComponent — the resolved values after all modifiers; explicitly “the ONLY struct gameplay systems should read from”.
AttributesDirtyComponent — recalc trigger.

So base → modifiers → resolved already flows. Traits, office bonuses, and manager bonuses are all just additional modifier sources feeding it. We define content, not machinery.

2. Attributes and what they drive (signed off)

Five attributes, no more — each does distinct, non-redundant work (the deliberate counter to Guild 2’s redundant stat sprawl). The mapping of attribute → game effect:

Attribute	Drives	Notes
handcraft	crafting quality / production bonus in workshops	confirmed in code: `CraftStep` keys off `handcraft`
strength	extraction yield (mining, farming, hauling) and combat	resolves the old “extraction keys off handcraft” oddity (CHALLENGES); also the martial stat — see §5.1
dexterity	speed of work — crafting & gathering rate; finesse in a fight	quality (handcraft) vs speed (dexterity) split
constitution	health, stamina, lifespan, surviving wounds	the aging hook (§4); higher con → longer life and harder to kill
charisma	trade prices and election odds / influence	the economic and political lever (§5)

This means a member’s best role is legible from their attribute spread: a high-strength member runs a mine or makes a good enforcer, a high-charisma member is your Trademaster or stands for council. Putting the right member in the right seat (§2 positions) is a real decision because attributes are uneven.

3. Growth — characters develop with use (signed off)

Attributes are not fixed: using an attribute raises it. Crafting raises handcraft, mining raises strength, trading and campaigning raise charisma. Consequences for the design:

Attributes double as skills. There is no separate “skills” layer — the five attributes are the skill axes, and growth-with-use is the skill system. (This is the simplest reconciliation of “grow with use” with the existing five-stat model; flagged for sign-off.)
You groom talent over a lifetime. A mediocre young member assigned to the forge becomes a master smith over years. This makes the generational horizon (§3) matter: investment in a member pays off across their life.
Growth has diminishing returns toward a soft cap, so members specialise rather than max everything, and a member’s potential (cap) can itself be set by inheritance/traits — good stock has higher ceilings.
Implication for the pipeline: growth mutates the base CharacterComponent values over time (then re-resolves). Modifiers stay reserved for equipment/traits/age/office. A growth driver does not exist yet (see tensions).

4. Traits — bundles and behaviours

A trait is a discrete named quality a character carries. Traits come in two kinds (per your decision):

(a) Attribute traits — named bundles of attribute modifiers. These plug directly into AttributeModifiersComponent and need no new machinery:

Gifted Smith (+handcraft), Silver-Tongued (+charisma), Hardy (+constitution), Nimble (+dexterity) … and negatives: Frail (−constitution), Clumsy (−dexterity), Plain-Spoken (−charisma).

(b) Behavioural / lifecycle traits — special effects beyond the five attributes. These need hooks in other systems, and are the genuinely new work:

Reproduction: Fertile / Infertile — change odds of producing heirs (§4).
Lifespan: Long-Lived / Sickly — shift expected age of death independent of constitution.
Learning: Quick Learner / Set in Ways — modify the growth rate of §3.
Decision / AI: Greedy, Cautious, Ambitious, Ruthless, Honest — bias how a delegated member runs a shop or plays politics (§2 control mode). This is what makes a delegated/AI member feel like its holder, and is the same flavour for player-delegated and rival-AI members (the symmetry of §2).

Where traits come from 〔WM〕

Per your decision — inherited stock + acquired through life:

At birth: a child draws traits (and base-attribute ceilings) partly from its parents, plus random variation. Good stock breeds good members → marriage and breeding are strategic levers (detail deferred to the dynasty/positions doc).
Through life: characters gain or lose traits via life events — mentorship grants a skill trait, a war wound inflicts Frail, hardship forges Hardened, a scandal brands Disgraced. This implies a lightweight events hook (a future system; not designed here, just reserved).

5. Lifecycle — aging, stages, death 〔WM〕

The generational layer (§4) requires characters to age and die. Working model:

Stages: Child (cannot work, hold an office, or manage a shop) → Adult (full participation; can be seated in positions, reproduce) → Elder (attributes begin to decline, but accumulated traits/experience are at their peak — the ideal advisor, the failing labourer).
Death: by old age (expected lifespan derived from constitution + lifespan traits + randomness) or killed (see open question on violence). A death that empties a key seat is a succession crisis (§2 hard paralysis).
Reproduction: adults produce children, who inherit per §4. The marriage / pairing mechanics belong to the dynasty/positions doc, not here.

5.1 Violence is real — characters can fight and be killed

Death is not only old age. Characters can fight, and combat is a genuine third front in the conflict of §5 (alongside economic and political), heavily in the spirit of Guild 2:

Combat as tasks. Fighting flows through the same task substrate (§2): an attack task; a patrol that can escalate into an attack on contact. Combat is resolved primarily by strength (+ dexterity for finesse, constitution for durability) — the martial role of those attributes.
Martial positions. A dynasty can seat guard / enforcer members (a position, per §2) used to defend its businesses and to attack rival characters and buildings. So combat capability is another reason to breed and seat capable members.
Crime. Some workshops are criminal — beyond producing, they post tasks like pickpocketing and theft, which can end in a fight with guards. This opens a whole Crime & conflict system.

Scope note: the full Crime & conflict system (criminal workshops, theft, guards/enforcers, sabotage, the law/justice response) is designed in crime.md. This section only records what it means for characters — they have a martial dimension, they can kill and be killed, and strength/dexterity/constitution carry it; crime.md resolves combat as an abstract stat contest over those attributes.

6. ⚠ Tensions with current code

What the vision needs that the code does not yet have:

No traits at all. There is no trait component, no trait DB category, and no behavioural-effect hooks. Attribute traits are cheap (they’re just AttributeModifiers); behavioural traits need wiring into reproduction, lifespan, growth, and the (future) AI decision layer.
No lifecycle. CharacterComponent has no age, birth, death, or stage. The entire aging/death/reproduction loop is greenfield, and §4/§6 depend on it.
No growth driver. The pipeline can re-resolve attributes, but nothing mutates base attributes from use. Growth-with-use (§3) is a new system, plus a potential/ceiling concept that doesn’t exist.
handcraft is currently the only production key. Adopting the §2 mapping (strength→extraction, dexterity→speed) means production systems must read the right attribute per work type — today they only read handcraft. This is the concrete fix for the long-standing extraction-yield oddity.

These are listed so the build order is honest: attribute traits + the attribute→effect mapping are low-cost (reuse the pipeline); lifecycle, growth, and behavioural-trait hooks are the substantial new systems.

7. Open questions (next pass)

~~Sign-off on the attribute→effect mapping and attributes-as-skills~~ — done (§2, §3 signed off).
~~Violence / combat~~ — resolved (§5.1): characters fight and can be killed; combat is a third front; strength/dexterity/constitution carry it; the full Crime & conflict system is now designed in crime.md.
Growth curve: rate, diminishing-returns shape, soft cap, and whether the cap (potential) is inherited.
Lifespan numbers & age thresholds: child→adult→elder boundaries, base lifespan, decline rate in old age. (Also: how long is a “generation” in play time? — ties to §3’s time horizons.)
Initial trait catalog: the concrete starting set of both kinds, and their magnitudes/rarities.
Acquired-trait events: how rich the life-events hook is, or whether v1 ships with inherited traits only and events come later.