Files
Naked-Desire/CLAUDE.md
T
2026-05-17 22:44:49 +03:00

5.8 KiB

Working in this repo

Instructions for Claude when assisting on Naked Desire. Read this first; it is short by design.

What this project is

  • Unreal Engine 5.7 game. Single primary module: NakedDesire.
  • NSFW exhibitionist sandbox / life-sim. Adult content is part of the design, not a bug.
  • Single-player only. Multiplayer is out of scope (GDD §17.3) — do not add networking complexity.
  • C++ for systems, Blueprint for content / animation hookups / UI widgets (GDD §17.5).

Canonical documents (read in this order before non-trivial work)

  1. README.md — Game Design Document. The design source of truth. Per GDD §23: when this doc and the code disagree, the doc wins until updated.
  2. PLAN.md — phased dev plan + live status of what's implemented / partial / missing / conflicting. Update this when state changes.
  3. The relevant Source/NakedDesire/<Subsystem>/ folder.

If a request would change the design, update README.md first, then PLAN.md, then code. If a request changes implementation status, update PLAN.md in the same change.

Repo layout

Source/NakedDesire/
  Clothing/         # Definitions, instance data, manager, slot data
  Global/           # GameMode, GameInstance, Constants, user settings, movement enums
  Interactables/    # Wardrobe, base interactable
  InteractionSystem/# Interaction manager + target interface
  Locations/        # LocationData + LocationTrigger (gameplay tag-driven areas)
  MissionBuilder/   # Mission/Goal/Restriction composition + concrete Goals/Restrictions
  NPC/              # NPC pawn, AI controller, spawner, target locations
  Player/           # NakedDesireCharacter, body part type, impostor, cinematic
  SaveGame/         # GlobalSaveGameData (single slot today)
  Stats/            # StatsManager (custom, not GAS yet)
Content/Blueprints/ # GameMode, GI, Player, NPC, Interactables, Data
Content/UI/         # Phone, HUD, Wardrobe, Shop, Inventory, etc. (BP widgets)

Code conventions observed

  • Copyright header on every C++ file: // © 2025 Naked People Team. All Rights Reserved. (some older files use the default "Fill out your copyright notice..." — replace when editing).
  • #pragma once at the top of every header.
  • Module export macro: NAKEDDESIRE_API.
  • One class per file; folder per subsystem.
  • DataAssets for static definitions (UPrimaryDataAsset); UObjects for instance / runtime data.
  • BlueprintAssignable DECLARE_DYNAMIC_MULTICAST_DELEGATE_* for BP-exposed events; DECLARE_MULTICAST_DELEGATE_* for C++-only events.
  • Localized strings use LOCTEXT with a #define LOCTEXT_NAMESPACE "..." / #undef block per file.
  • Magic constants live in Global/Constants.h (e.g., SLOT_NAME, IS_DEMO).
  • BlueprintImplementableEvents are widely used (time of day, end-game) — assume non-trivial logic lives in BP and grep Content/ for asset usage when something seems "missing" from C++.

Architectural rules (load-bearing)

  • Item identity (GDD §6.1): every item is a unique physical instance with a stable runtime ID. The current UClothingItemData does not satisfy this — Phase 1 of PLAN.md fixes it. Don't pile new content on top of the broken identity model.
  • Session loss (GDD §4.4): all "what gets lost" logic must live in a single SessionLossResolver. Do not scatter loss-handling into multiple components.
  • GAS-friendly attributes (GDD §17.2): attributes should map to a UAttributeSet eventually. Until Phase 4 lands, the custom UStatsManager is the source of truth — add new attributes there, but write them so they can migrate to GAS.
  • Data-driven content (GDD §17.4): clothing / commissions / food / NPC templates are DataAssets. Don't hardcode content into C++.

When making changes

  • Match the surrounding code — naming, copyright header, UPROPERTY metadata patterns, delegate style. If a folder has a convention, follow it before introducing a new one.
  • No premature abstractions — three similar lines beat a half-built generic system. The GDD is detailed; let the actual systems drive shared interfaces, not speculation.
  • No backwards-compat shims unless the user explicitly asks for one. Single-player game, no shipped saves to preserve unless the user says otherwise.
  • Don't mass-rename or restructure without clearing it with the user first — Blueprint references to C++ classes / properties break silently when names change.

Build / verify

  • Mac project file: NakedDesire (Mac).xcworkspace. Can be built via Xcode or xcodebuild from CLI for a quick compile check.
  • The user typically runs the editor — don't assume you can launch UE from CLI. After a code change, the build verification path is:
    1. Static code review (Read + reason).
    2. If unsure, ask the user to compile in-editor and report errors.
  • Do not run destructive git actions (force push, reset --hard, branch -D) without explicit approval.

Things to avoid

  • Adding GAS bits piecemeal before Phase 4 (creates a split system).
  • Editing EClothingSlotType casually — it currently mixes equipment slots and body parts; the cleanup is sequenced in Phase 1.
  • Indexing MissionsConfig->DailyMissions[DaysPassed] without bounds checking — this is a known crash path (NakedDesireGameMode.cpp:69).
  • Treating Money on ANakedDesireCharacter as authoritative — it is duplicated on the save game; both will be reconciled in the Phase 1 save refactor.
  • Adding new persisted state to UGlobalSaveGameData directly — the schema is going to be rewritten in Phase 1. Coordinate before adding fields.

Communication style

  • The user is the game's developer (Oleh). Skip over-explanation of UE5 basics; do explain non-obvious design tradeoffs.
  • Keep responses tight; cite file:line so the user can jump.
  • If a task is ambiguous, ask before implementing. The GDD is long; assumptions are risky.