Character Creation & Appearance

Canonical GDD content

Overview

Players define their survivor's look at character creation, and can change it later at an in-game barber. The system is mostly curated (preset + hairstyle from authored lists; skin/eye via color pickers) and cosmetic-only — appearance never grants a stat or gameplay advantage. Characters are MetaHuman-based; see ../06-Art-Audio/01-Art-Direction-and-MetaHuman.md.

What the player can customize — v1 — [CONFIRMED]

Locked to exactly four options for v1:

There is no face morph and no body scaling in v1. Skin/eye use pickers, not swatch data assets. Additional options (facial hair, tattoos, starting outfit, etc.) are [TBD].

Identity model — [CONFIRMED]

• The player selects one preset, which fixes the face/head shape and body base.
• On top of the chosen preset, the player sets hairstyle (curated list), skin color (picker, server-clamped), and eye color (picker).
• No facial morphing — identity is preset + hair + skin/eye colors.

Gender / base bodies — [CONFIRMED]

• Two base bodies: male and female. Presets are authored and selectable per gender.
• Both base bodies must work with the shared player Anim BP / locomotion (via retarget or a shared skeleton). [RISK] — supporting two base bodies roughly doubles the character authoring and animation-retarget work for a solo dev. Keep locomotion/combat animation driven from one source and retarget, rather than authoring per-body.

No body-size customization — [CONFIRMED]

• Body scale is fixed for all characters. (Adjustable body size was considered and intentionally cut.)
• Why: this is a PvP, full-loot game — a variable body size means a variable hitbox, which is a competitive fairness/exploit problem. All characters therefore share a consistent collision capsule and hitbox geometry regardless of preset/gender. Any visual silhouette difference between presets must not change effective hit volumes meaningfully.

Barber / later editing — [CONFIRMED]

• An in-game barber station lets the player re-open the full character-creation UI and change everything, including switching to a different preset (i.e., changing the face), not just hair/skin/eye.
• The barber is an interactable station — it reuses the Interaction system (see ../05-Technical/ and the Reusable systems catalog in Plan.md) and re-uses the same creation widget (WBP_CharacterCreation).
• Phase 1 stub: barber is interactable and opens the full creation UI with no item cost — same validation/replication as initial creation.
• Deferred (backlog): barber use will require a scissor item (DA_Item_Scissor or equivalent) at a mirror prop on the station mesh. No resource-cost logic in the stub; add mirror + scissor content when implementing the cost gate.
• [TBD] (owner call): whether using the barber costs resources beyond the scissor gate, and where stations are available (craftable/placeable in a base vs. only at safe zones / a starting hub).

Technical approach — [RECOMMENDATION]

Because v1 is curated with no morph and no scale, the system avoids runtime MetaHuman rig/DNA manipulation — the expensive, fragile part of MetaHuman customization in a packaged game. Realistic pipeline:

• Presets: author each as a complete MetaHuman (MetaHuman Creator / the in-engine MetaHuman plugin), stored under Content/Lambeer/Characters/Player/MetaHumans/. 🧍 You author these.
• Hairstyle: swap the groom / hair asset at runtime from a curated set. Grooms are costly to render — provide hair-card LODs for distant players. [RISK] perf at 40–60 players in view (e.g., at a boss/raid); cap detailed grooms and fall back to cards.
• Skin color: FLinearColor via Material Instance Dynamic SkinTint on body/face meshes; server clamps HSV to authored min/max in LambeerAppearanceConstants.
• Eye color: FLinearColor via IrisTint; no hue/sat/value clamp (RGB 0–1 only).

Data model — [CONFIRMED implementation]

• Data-driven: DA_CharacterPreset per preset, DA_* hair registry — no skin/eye swatch assets.
• FAppearanceState: { gender, presetId, hairId, skinColor, eyeColor } — compact, replicated, persist-ready. Blood and wetness on hair/skin are not part of appearance cosmetics; they are separate character visual state. Eyes are not mesh-stained or mesh-wetted. See 10-Blood-Visual.md and 11-Wetness-and-Rain.md.

Replication & authority — [CONFIRMED implementation]

• Replicate FAppearanceState; clients resolve preset/hair IDs → meshes/groom; apply colors locally via ULambeerAppearanceLibrary.
• Server-authoritative: validates preset/hair IDs for gender; sanitizes/clamps skin, sanitizes eye RGB; rejects invalid combo. See ../04-Multiplayer/01-Network-Architecture.md.

Persistence — [RECOMMENDATION]

• Persist FAppearanceState in the player record (IDs + two colors) when SQLite backend lands (Phase 1.9).

UI — [CONFIRMED implementation]

• UMG: preset carousel (by gender), hair list, skin/eye color pickers, live preview (WBP_CharacterCreation).
• The same widget is reused by the barber (the barber simply re-opens it).

Open items — [TBD] (owner decisions; do not guess)

• Number of presets per gender (cap for memory budget) — content decision.
• Number of hairstyles — content decision. Skin HSV box tuning — design/art after PIE.
• Barber cost & placement (free vs. resource cost; where it can be used) — stub is free; scissor-at-mirror gate is backlog.
• Barber scissor + mirror prop — deferred item gate and station art (see Barber section).
• Future options (facial hair, tattoos, scars, starting outfit) — deferred past v1.

Base MetaHuman assets — [CONFIRMED]

• Male base: MHC_Man — Content/Lambeer/Characters/Player/MetaHumans/MHC_Man
• Female base: MHC_Whoman — Content/Lambeer/Characters/Player/MetaHumans/MHC_Whoman
• Preset data assets reference these bodies; placeholder hair IDs until DA_* hair content exists; skin/eye use default colors from code (no swatch assets).

Cross-references

• Player character & components: 02-Player-Character.md
• Blood stains on body/hair (not eyes) and HUD overlay: 10-Blood-Visual.md
• MetaHuman pipeline & cost: ../06-Art-Audio/01-Art-Direction-and-MetaHuman.md
• Persistence: ../04-Multiplayer/01-Network-Architecture.md
• Build order: Plan.md (Phase 1.1)