Character Creation & Appearance

Authoritative project 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 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 — [CONFIRMED 2026-09-14]

[CONTINUE CORRECTION 2026-09-15; OWNER-REPORTED PASS 2026-09-16] A committed returning character must be read before the initial RestartPlayer chooses its entry screen, even before world BeginPlay activates periodic capture. The former readiness guard falsely returned Missing and reopened creation. See the corrected load-order diagnosis and teardown preservation. Saved-position spawn recovery restores the existing character and requires town selection after a successful fallback spawn, or refuses entry explicitly if no pawn can be created. No appearance recreation or data reset. Owner reported Continue/town/move/save/restart persistence passed.

• Persist FAppearanceState in the player record (IDs + two colors) with the SQLite backend. Canonical P07 record: TECH-NETWORK-ARCH.
• [IMPLEMENTED 2026-09-15] Persist bInitialSpawnChosen with the same record. A fresh character commits validated appearance on the server, then selects a starter town; a returning character skips both creation and initial-town selection and restores the persisted state/position.
• [HARDENED 2026-09-15; OWNER-REPORTED PASS 2026-09-16] Appearance commit and first starter-town selection require an explicit player-scoped snapshot write and readback verification. Lambeer.SaveFlush uses the same path, so it cannot report success when the current committed player row is absent or unreadable.

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).
• [P08 IMPLEMENTED 2026-09-15; OWNER-REPORTED PASS 2026-09-16] WBP_CharacterCreation compiles/saves/readbacks cleanly and inherits a native activatable layout with gender, preset, hair, skin HSV, eye RGB and SceneCapture portrait preview. Initial creation cannot cancel and commits through a server RPC; barber reuse retains the existing update path.
• [P08 TRAVEL-ROOT FIX REVISION 2 OWNER-VERIFIED 2026-09-15] Owner PIE confirmed that selecting the world and entering it now presents Character Creation after OpenLevel. The UI manager records the exact world that created its root and requires both controller and world to match before reuse; creation presentation is also retried from gameplay controller BeginPlay/possession and emits a successful-open log. Pre-creation/Error states are not captured as player rows.
• [P08 PORTRAIT REVISION 2026-09-15; OWNER-REPORTED VISUAL PASS 2026-09-16] Owner feedback showed the live model as a dark oversized silhouette. The preview now matches the render-target aspect to the live portrait panel, derives camera distance from capsule height, horizontal FOV and a framing margin, includes attached actors, and uses an unlit SceneColor HDR capture with inverse opacity so authored colors remain readable independently of map lighting. Closed-Editor native build plus Frontend 3/3, Persistence 6/6 and HUD 24/24 regressions pass (33/33); owner later reported remaining visual checks passed.
• [P08 PORTRAIT ALPHA CORRECTION 2026-09-15; OWNER-REPORTED VISUAL PASS 2026-09-16] Owner reported that the previous brightness revision made the preview disappear. MCP verified that the shared portrait material computes opacity as one minus texture alpha; FinalColorLDR does not provide the required inverse-opacity channel. Character Creation now uses SceneColor HDR with a float render target and retains unlit capture and panel-derived framing. During initial creation, the local pawn and attached primitives are visible only to scene captures; their original flags are restored when the widget closes or is destroyed. Barber mode does not apply this hiding. The backdrop fills its overlay slot. Preview appearance uses the actor-owned appearance component and explicit body/face mesh accessors. Persistence schema and creation commit remain unchanged. Owner later reported remaining visual checks passed.

Dedicated creation stage — owner-selected direction

[FOLLOW CAMERA CUT AFTER CREATION 2026-09-16; OWNER-REPORTED PASS 2026-09-16] Owner dedicated PIE showed a first-time client looking from inside the MetaHuman after Character Creation commit (reproduced on a new pie-3 client; returning pie-1/pie-2 characters that skipped creation were normal). Closing the streamed stage cuts view target to the possessed pawn, zeros inherited pitch/roll, and snaps the hip spring arm without a same-frame collision probe so attached cosmetics cannot pin the camera at the capsule. Extra dedicated clients can possess after the stage CameraActor is gone, so restore also retries until the pawn is the view target and the follow camera is outside the capsule, then repeats from possession, initial-spawn Ready, and living presentation. Owner reported the extra-client first-time-creation follow camera now sits behind the pawn. This does not close G5; Steam/Feedback/production-map work stays open.

[OWNER-REPORTED VISUAL PASS 2026-09-16] Owner reported the remaining Character Creation visual checks passed: lighting/framing, travel-flash, streamed-stage presentation, Escape-to-Main confirmation, exposure parity and commit/rejoin presentation. Final environment assets and art lighting/time of day remain later content and do not reopen this visual acceptance. G5 remains open only for deferred Steam/session/production-map work.

[ART DIRECTION CONFIRMED 2026-09-15; BLOCKOUT AUTHORED] The owner rejected the current visual presentation and selected a street with wrecked cars and buildings for the proposed dedicated Character Creation scene. This supersedes the suggested safehouse/interior and outdoor camp settings. The owner authorized construction and confirmed that no final environment assets are available; use ordinary rectangular boxes for this pass. Final assets and art lighting/time of day remain later content. Runtime loading/integration is implemented; owner later reported remaining visual checks passed. This selection does not close G5.

[BLOCKOUT SAVED 2026-09-15] /Game/Lambeer/World/Maps/L_CharacterCreation/L_CharacterCreation is a separate authored map, created through Unreal MCP from a copy of the empty Main Menu map. It contains 28 cube mesh actors: road, two sidewalks, ten building volumes, three two-box wreck placeholders, eight road markings and one subject placeholder. CreationCamera, CreationSubject and three movable point lights establish provisional framing and illumination. Actors are organized under Blockout, Presentation and Lighting folders. Camera and subject tags are Lambeer.Creation.Camera and Lambeer.Creation.Subject. These are editable blockout settings, not final art approval. MCP actor-count readback, viewport inspection and save/clean-state checks passed. The following runtime integration replaces the original portrait for initial creation; owner later reported remaining visual checks passed. Final environment assets remain later content.

[STAGE RUNTIME INTEGRATION 2026-09-15; OWNER-REPORTED PASS 2026-09-16] Initial creation streams the authored map as a temporary client-only presentation level, preserving the active server connection and gameplay pawn position. ULambeerCharacterCreationStage locates the tagged camera/subject, hides the blockout subject proxy, and spawns the preset's cosmetic PreviewActorClass separately from gameplay. Complete MetaHuman assemblies preserve body, face and groom relationships; compatible bodies reuse the existing retargeted A_INP_Idle animation. Gender/preset updates replace the preview assembly; skin/eye colors apply to its meshes. The original project hair-binding backlog is unchanged. The widget hides passive HUD and the original portrait surface while the stage camera fills the screen. Loading errors remain visible and Commit stays disabled until ready. Server-owned initial appearance commit still transitions to starter-town selection and uses existing persistence. Deactivation/destruction restores the prior camera, HUD and pawn visibility, destroys the transient preview, and unloads the stage. Repeated entry notifications preserve the active draft. The map is explicitly included in cooking. Barber retains its existing portrait path. Owner reported remaining visual, commit/spawn and return/rejoin checks passed.

[BLUE-VIEW ROOT CAUSE CORRECTED 2026-09-15; OWNER-REPORTED VISUAL PASS 2026-09-16] The owner retest disproved the earlier claim that camera rotation explained the blue screen. The authored camera correction and alignment assertion remain valid, but did not solve this failure. Agent Standalone PIE under a one-round owner exception identified gameplay height fog covering the deep-offset stage; the permanent view-scoped fog suppression and loading-POV gate remain. Owner later reported remaining lighting/framing, travel-flash, commit/rejoin and streamed-stage visual checks passed. This does not close G5.

[STAGE LIGHTING ISOLATION + EXIT CONFIRMATION 2026-09-15; OWNER-REPORTED PASS 2026-09-16] Owner evidence showed the creation street and preview heavily overexposed and showed Escape revealing L_Dev_Sandbox. The streamed stage now assigns its authored geometry, lights and transient preview assembly to Lighting Channel 1, while the creation-camera view suppresses host-world atmosphere, clouds, sky lighting and fog. This prevents the gameplay world's daytime environment and default-channel lights from contaminating the stage without inventing final art-light values or changing the three authored point lights. Initial Character Creation now consumes CommonUI Back itself: first Escape opens an in-screen confirmation asking whether to return to /Game/Lambeer/World/Maps/L_MainMenu/L_MainMenu; Escape or No, Stay dismisses the prompt; Yes, Return fades to black, tears down the local stage and opens Main Menu. Barber Back still performs its existing cancel/close behavior. Owner reported remaining brightness, dialog, cancel path and Main Menu travel checks passed. Final environment assets and art lighting/time of day remain later content.

[STREAMED EXPOSURE PARITY CORRECTION 2026-09-15; OWNER-REPORTED PASS 2026-09-16] The owner manually adjusted the lighting and camera in L_CharacterCreation and confirmed that direct PIE matched the intended result, while Main Menu → Enter World remained severely overexposed. MCP inspection established that the creation map has no Post Process Volume and its camera uses the normal authored/default exposure range, whereas L_Dev_Sandbox contains an unbound Post Process Volume at full weight that pins minimum and maximum exposure to EV100 0. Because the creation map is streamed into that persistent gameplay world, the host volume was still controlling eye adaptation despite lighting-channel and show-flag isolation. The creation-camera view now restores its own exposure range after world-volume blending and marks the switch as a camera cut so gameplay eye-adaptation history is discarded. The map's owner-edited camera transform, FOV and light values remain authoritative and unchanged. Owner later reported streamed-stage exposure parity passed.

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)