Game Design Document

Working title: Naked Desire Genre: NSFW exhibitionist sandbox / life-sim Engine: Unreal Engine 5 (C++ primary, Blueprint for content) Platform: PC Perspective: Third-person Audience: 18+ Reference titles: Naked Order, Roshutsu, Roxanne's ENF Exhibitionist Game, Secret Flasher Sereka

This document is the canonical design reference. It is written to be consumed by Claude Code (or any contributor) during implementation review and planning. When the design changes, this document should be updated first, then code.

---

1. Vision & Pillars

1.1 One-line pitch

A sandbox exhibitionist life-sim where the player accepts fetish commissions from an underground forum, balances rent and recognition against the thrill of public exposure, and progresses down one of three character paths over a 90-day time limit.

1.2 Design pillars

1. Risk vs. reward, every second. Walking outside is never neutral — coverage, time of day, NPC density, recognition, and lust all push the embarrassment meter constantly. Every decision (what to wear, which street to take, when to strip) is a calibration against a session-loss state.
2. Persistent physical world. Items are real objects in the world. A discarded skirt is there until something happens to it. The player's anxiety about losing clothing is mechanical, not flavor.
3. Three distinct fantasies, one system. Slut / Exhibitionist / Slave aren't cosmetic tags — they unlock different clothing, missions, attribute trees, and play styles. A Slave-path session looks fundamentally different from a Slut-path session.
4. The forum is the spine. Commissions drive minute-to-minute play, weekly missions drive medium-term goals, followers/reputation drive long-term progression. The forum is also the diegetic UI for most player-facing systems.
5. Time pressure. 90 in-game days. Rent every week. The clock never stops; the player must choose what to ignore.

1.3 Non-goals

• This is not a dating sim. NPCs are reactive systems, not relationships.
• This is not a combat game. Threats are evasion-based (police, stalker, harasser).
• This is not a story-driven linear game. The story is a framing device; the loop is the product.

---

2. Story & Setting

2.1 Premise

Yumi, while browsing the internet after a rent increase, discovers a hidden fetish forum that pays for exposure-themed commissions. After completing her first task she realizes she enjoys it. She begins taking commissions to cover rent and explore the new feelings.

2.2 Setting

A modern Japanese-style city. Currency is Yen. The city is the entire playable map: residential, commercial, parks, alleys, a beach, a train station, a casino, a gym, a beauty salon, an electronics shop, multiple other shop types, the player's apartment. See §10.4 for the locked location list.

2.3 Tone

Sexual, playful, transgressive. The player character is a willing participant, not a victim. The "stalker" NPC is the only non-consensual antagonist and exists as a session-loss threat, not a narrative one.

2.4 Time structure

• Total run length: 90 days (3 months).
• Day: 08:00 → 20:00 in-game. Real-time duration ~45 min (half of the 1h 30m day/night cycle).
• Night: 20:00 → 08:00 in-game. Real-time duration ~45 min.
• Week: 7 days. Rent due at end of each week.
• Sleep: fast-forwards 8 hours, restores energy. Available at the player's apartment bed.

---

3. Core Gameplay Loop

3.1 Macro loop (per day)

1. Wake up at home. New daily commissions appear on the forum. Weekly commissions remain visible.
2. Plan: check commissions, check bank, check pending deliveries, check news/recognition.
3. Equip outfit from wardrobe. Pack bag (optional).
4. Leave the house → session begins.
5. Travel to commission locations, complete tasks, manage attributes. Each completion immediately wires money to the bank, credits XP, and updates followers — no return-to-home collection step.
6. Return home → session ends, optional sleep.
7. Spend earnings (shops, gym, beauty salon), level up attributes, post photos.
8. Repeat. Pay rent at end of week.

3.2 Micro loop (during a session)

Move → observe NPC density and types → make a coverage/exposure decision → embarrassment/lust rises → action (complete commission step, take photo, flee, masturbate, redress) → reward or threat resolution → repeat.

3.3 Win / lose conditions

• Win (campaign): Survive 90 days. Endings are gated by progression path level and total followers (TBD specific thresholds).
• Endless mode: Unlocked after first campaign completion. Disables rent-based eviction. All other systems (session loss, embarrassment, lust, recognition, etc.) remain active. Lets players keep playing their character indefinitely. Implementation cost is minimal — a single flag on the run.
• Lose (run): Cannot pay rent → evicted → game over. Disabled in endless mode.
• Lose (session): Energy → 0, OR embarrassment → max, OR caught by police. Session loss has consequences (see §4.4 and the summary table in §6.6) but does not end the run.

---

4. Session System

A session is the unit of "going outside." It is where 90% of gameplay happens.

4.1 Session start

Triggered by leaving the apartment. Snapshots current equipment, attributes, and time. All world items remain where they are.

4.2 During session

• Player moves freely. The world simulates NPCs, time, day/night.
• Attributes (embarrassment, lust, stamina, energy) update in real time per §7.
• Commissions can be progressed or completed.
• The player can freely re-enter the apartment to safely end the session at any time.

4.3 Session end (safe)

Player returns home. All carried items persist. Embarrassment resets toward baseline. Commission rewards (money, XP, followers) are not finalized at session end — they were already credited at the moment each commission completed (§13.1 / §13.2). If a Snitch reported the player to police during the session (§10.2), the player keeps the wanted tag even after a safe return — see §7.7.

4.4 Session end (loss)

Triggered by any session-loss condition (§3.3).

Precedence — police chase wins. If the player is being actively chased by police (between detection and the disengage timer, §10.3) at the moment another loss condition fires, the loss is always resolved as police capture. The cops catch them as they collapse or freeze; the chase outcome supersedes embarrassment-max and energy-zero outcomes (including the energy-zero sleep cutscene). This applies whether or not the player has the wanted tag in advance — being mid-chase is the trigger, not the tag.

On loss:

• The player returns to the apartment. The route home depends on the cause:
  • Energy = 0 — a cutscene plays of the player trudging home, exhausted, and going to bed. The player never sleeps outside; the apartment bed is the only sleep location. Time advances by one sleep cycle.
  • Embarrassment = max — fade to apartment. No extra cost beyond the session loss itself (no time skip, no money penalty, no reputation hit).
  • Police capture — the player is processed (money penalty below) and returned home.
• Equipped clothing is never forcibly removed by loss. Whatever the player was wearing at the moment of failure stays equipped on arrival home.
• A bag placed in the world (not carried) is lost along with its contents — the player did not retrieve it before the failure.
• Unequipped clothing left on the ground can be lost two ways:
  1. In-session theft — a chance-based roll while the player is away from the item. See §6.3.4 for the model.
  2. Sleep — any clothing left outside the apartment when the player sleeps is guaranteed lost. This fires both for the energy-zero cutscene (forced sleep) and for voluntary sleep at home with items still outside.
• Police capture during pursuit applies a money penalty. If the player can cover it, the debt is paid and they are returned to the apartment. If they can't cover it, a short cutscene plays of the player in a holding cell, then time fast-forwards to the next in-game morning — the night served settles the penalty, no money is owed afterward. The cutscene is non-interactive; the player does not actually inhabit the cell. Capture clears the wanted tag (§7.7) in either case. Already-accepted commissions still expire at day end with their normal failurePenalty (§13.4); the cutscene does not pause that clock.

Implementation note: session loss must be a clearly defined transactional state. All "what gets lost" logic should live in a single SessionLossResolver to keep this deterministic and debuggable.

---

5. The Three Progression Paths

The player chooses how they level up but is not locked into one path. XP is a single shared pool — every commission, mission, and stream feeds the same number. The player decides which path's attribute pool to spend it on. Given enough XP, every attribute on every path can be upgraded; there is no requirement to earn "Slut XP" before buying a Slut-path upgrade.

5.1 Slut

• Unlocks: revealing clothing (mini skirts, high heels, lingerie variants), masturbation action, masturbation-related missions.
• Attribute access: lust-related attributes (max lust, lust gain rate modifiers, masturbation energy efficiency).
• Playstyle: pushes lust as a resource. Risks blackout effects (§7.2).

5.2 Exhibitionist

• Unlocks: "expose-capable" clothing (coats, pleated skirts), public-display missions.
• Attribute access: embarrassment-related attributes (max embarrassment, embarrassment decrease rate, pulse).
• Playstyle: longer sessions, denser crowds, tolerance-building.

5.3 Slave

• Unlocks: BDSM clothing (latex suits, gags, cuffs, bars), restraint-themed missions.
• Attribute access: stamina-related attributes (max stamina, stamina recovery, energy efficiency).
• Playstyle: physically demanding, restriction-based puzzles (cuffs require NPC help to remove).

5.4 Path level

Each path has a level (e.g., 1–10). Level gates clothing, missions, and attribute upgrades within that path's pool. A path's level is derived from how much the player has invested into that path's attribute upgrades (§7.10), not from any per-path XP counter — XP itself is a single shared pool.

---

6. Items

6.1 Item identity rule

Every item is a unique physical instance. Two blue tops can have different states (torn vs. pristine). Items do not teleport, do not duplicate, and persist with their internal data wherever they are placed or dropped.

Implementation contract:

• Each item has a unique runtime ID.
• Each item has a definition (immutable, shared) and an instance state (mutable, per-object).
• Items in the world are AActors. Items in containers are owned by the container's inventory component but retain identity.
• Saving and loading must preserve item identity, position, and per-instance state.

6.2 Carriable item categories

• Clothing (§6.3)
• Bags (§6.4)
• Phone (one active at a time, but the player may own multiple models simultaneously — §9, §9.9)
• Consumables (food, §6.7)
• Toys — sex toys for the toy slots (§6.5). Bought at the Adult Shop (§10.4).

There are no other gadget categories. The phone is the only electronic device the player carries.

6.3 Clothing

Attributes per clothing instance:

• type — equipment slot. See §6.5 Equipment slots for the canonical 18-slot list (body clothing, accessories, restraints, toys), exclusion rules, and which slots drive the face-cover bypass.
• covers — set of body parts: { boobs, ass, genitals, ... }.
• progressionPath — Slut / Exhibitionist / Slave / None.
• color — primary color enum.
• coverage — float [0,1]. Authored per item to reflect how much it conceals — including the psychological "this is just underwear" discount. There is no separate underwear flag; an item in UnderwearTop / UnderwearBottom is simply authored with a lower coverage than a similarly-sized non-underwear garment.
• condition — float [0,1]. Starts at 1.0 (new). Decreases via §6.3.4.
• canExpose — list of body parts this garment can momentarily reveal without unequipping (e.g., coat → boobs, ass).
• restrictions — list of restriction entries that fire while this item is equipped (e.g., wrist cuffs block phone use and changing top clothing; ankle cuffs block running). Most items have an empty list. See §6.3.7 for the full vocabulary.
• containerSlots — optional inventory (e.g., pants pocket for phone).

6.3.1 Container slots

Container slot allows player to carry items there.

• size: S, M, L - Size of the container slot
• count: Count of the container slots

6.3.2 Coverage resolution

For each body part b:

• Find the set of equipped garments whose covers set includes b.
• Effective coverage of b = max(coverage of garments covering b). Only the highest-coverage garment per body part counts; layering does not stack.
• Body part is "exposed" if effective coverage = 0.
• Lower coverage → faster embarrassment gain when observed (§7.1).

Authoring guidance: underwear in UnderwearTop / UnderwearBottom should be authored with lower coverage than equivalently-shaped outerwear in Top / Bottom, so being seen in just underwear correctly reads as more exposed than being seen in a thin shirt of the same physical coverage. The math itself does not special-case underwear — the value in the editor is the contribution, full stop.

6.3.3 Equipping & unequipping

• Equip/unequip anywhere in the world via the quick action menu.
• Unequipped clothing becomes a world AActor at the player's location.
• Clothing on the ground can be picked up when the player is in range.

6.3.4 Theft

Theft applies to lose clothing on the ground and to bags placed in the world (see §6.4). The model has two layers — a chance-based in-session roll and a deterministic sleep-loss handled in §4.4. Tuning placeholders below are resolved in §21.

• Grace period. Loose clothing on the ground is safe for T_grace minutes (TBD) after the player leaves it unattended. Bagged contents (bag set down in the world) get a longer grace period T_grace_bag (TBD, longer than T_grace); the bag protects its contents until then.
• Chance roll. Once an item is past its grace period, each check tick is an independent roll at a flat probability P_theft (TBD %). The probability does not ramp with time — leaving an item out for 20 minutes is not strictly riskier per minute than leaving it out for 5 minutes; the only thing time does is give more independent rolls.
• Resets. The grace timer resets when the player re-enters proximity of the item or when the player is inside a safe zone (apartment).
• Sleep is not handled here. Sleeping (voluntary at home or via the energy-zero cutscene) is the deterministic side of the model — any clothing left outside the apartment at sleep time is guaranteed lost, regardless of where it sits in the grace / roll cycle. See §4.4.
• Hiding spots Items can be hidden in hiding spots where they're less likely to be stolen. Has chance to be stolen after sleeping.

6.3.5 Rip & tear

• Moving through bushes, against walls, or other rough collisions decrements condition.
• Damaged clothing renders visually torn and exposes additional body parts (coverage drops).
• Damage is irreversible. Damaged clothing cannot be repaired.
• When condition reaches 0, the item disappears.
• New clothing always starts at condition = 1.0.

6.3.6 Exposing

• Some clothing (e.g., coat, pleated skirt) supports a per-garment expose action.
• Triggering expose temporarily reveals listed body parts without removing the garment.
• Blocked if another garment covers the same part (e.g., pants block coat's ass-expose).
• While exposed, the body part counts as fully uncovered for embarrassment math.

6.3.7 Restrictions

Each clothing item carries an optional restrictions list. Most items have none. Restraint-slot items (§6.5 slots 13–15) declare meaningful lists; a few non-restraint items (heels, tight skirts) can declare lighter restrictions too.

Restrictions are the union of all entries on all equipped items — any restraint that declares a given flag activates it for the player, regardless of which equipped item provides it.

Vocabulary:

Restriction	Effect while at least one equipped item declares it
BlockRun	Player cannot run. Movement capped at walk speed.
BlockCrouch	Player cannot enter the crouch state.
BlockPhoneUse	The phone (§9) is unusable — no apps, no camera, no livestream, even when in hand / pocket / bag.
BlockItemPickup	Cannot pick up world items.
BlockMasturbate	The masturbate quick action (§14.1) is disabled. A commission objective requiring masturbation cannot progress until cleared.
BlockExposeAction	The per-garment expose action (§6.3.6) is disabled.
BlockSlotChange(slot)	The named equipment slot cannot be (un)equipped while the declaring item is on. Multiple BlockSlotChange(...) entries on one item are allowed and stack.

Authored examples:

• Wrist cuffs (WristRestraint): BlockPhoneUse, BlockItemPickup, BlockMasturbate, BlockExposeAction, BlockSlotChange(Top), BlockSlotChange(Outerwear), BlockSlotChange(UnderwearTop), BlockSlotChange(Bodysuit).
• Ankle cuffs (AnkleRestraint): BlockRun, BlockSlotChange(Bottom), BlockSlotChange(Footwear), BlockSlotChange(Socks), BlockSlotChange(UnderwearBottom).
• Spreader bar (AnkleRestraint): same as ankle cuffs, plus BlockCrouch.
• High heels (Footwear, non-restraint): BlockRun only.
• Tight pencil skirt (Bottom, non-restraint): BlockRun, BlockCrouch.

Removal:

• Restraint-slot items typically declare BlockSlotChange(<their-own-slot>), which means the player cannot remove them via normal unequip. These require the Key + timed-unlock action in §10.4.1.
• Non-restraint restrictive items (heels, skirts) remove via normal unequip as long as no other equipped item is blocking the slot change.

Commission interaction: an accepted commission whose objective needs a blocked action (e.g., PerformAction(masturbate) with BlockMasturbate active) does not auto-fail; it simply cannot progress until the restriction is cleared. The commission's day / week deadline still applies normally.

6.4 Bags

• Bag is an equippable item with its own inventory.
• Player can equip one bag at a time.
• Bag can be placed in the world (set down) — persists as an AActor.
• Bags follow the same theft rules as clothing (§6.3.4) and the same session-loss rules as other items (§4.4 / §6.6).

6.5 Inventory & Equipment

The player has 18 equipment slots in four groups, plus a bag slot, a hand slot, and container slots exposed by what's currently equipped.

Equipment slots

Body-clothing slots (layering, with one exclusion rule):

#	Slot	Examples
1	Outerwear	Coat, jacket, hoodie
2	Top	T-shirt, blouse, crop top
3	Bottom	Skirt, pants, shorts
4	UnderwearTop	Bra, sports bra, bikini top
5	UnderwearBottom	Panties, thong, bikini bottom
6	Bodysuit	Latex catsuit, leotard
7	Socks	Stockings, tights, socks
8	Footwear	Shoes, heels, boots, sandals

Bodysuit is mutually exclusive with Top, Bottom, UnderwearTop, and UnderwearBottom. Equipping a bodysuit auto-unequips all four of those slots; equipping any of those four while a bodysuit is on auto-unequips the bodysuit. Outerwear, Socks, Footwear, and the accessory / restraint slots are unaffected by bodysuit equipping.

Accessory slots (cosmetic unless noted):

#	Slot	Examples	Notes
9	Head	Hat, hood, headband	Cosmetic only.
10	Face	Mask, face shield	Face-cover for recognition bypass (§7.6).
11	Eyes	Glasses, sunglasses, blindfold	Face-cover for recognition bypass (§7.6).
12	Neck	Necklace, choker, scarf	Cosmetic.

Restraint slots (independent — all three can be active simultaneously):

#	Slot	Examples
13	WristRestraint	Wrist cuffs, rope bindings
14	AnkleRestraint	Ankle cuffs, spreader bar
15	NeckRestraint	Collar (restraint variant), gag

Restraint slots are governed by §6.3.7 (effects) and §10.4.1 (removal). NeckRestraint is distinct from cosmetic Neck; a restraint collar and a necklace do not auto-exclude — content authoring is responsible for ensuring they don't visually collide (e.g., hide the necklace mesh when a collar is present).

Toy slots (independent — all three can be active simultaneously):

#	Slot	Examples
16	Nipples	Nipple clamps, nipple suckers, pasties with vibrators
17	Anal	Butt plug, anal beads
18	Vagina	Vibrator, dildo, internal egg

Sex toys are bought from the Adult Shop (§10.4) and follow the standard item-identity rules (§6.1). Toys do not contribute to coverage (§6.3.2); a butt plug under panties leaves UnderwearBottom's coverage value unchanged and the ass remains "covered" by panties for embarrassment math. Toys can be hidden beneath clothing or worn while otherwise nude — the slot is orthogonal to the body-clothing layering rules. Effects (lust modifier, embarrassment modifier, pulse modifier, audible vibration that NPCs may detect) are per-toy and authored on the toy's UItemInstance.

Other equipment

• Bag slot — 1 (see §6.4).
• Hand slot — 1. Holds one carriable item at a time (phone, food, key, etc.). Hand-dependent actions (phone use, item pickup, masturbate, expose action) are disabled when an equipped item declares the corresponding Block* restriction (§6.3.7); wrist cuffs are the canonical case.

Container slots

• Each equipped clothing item may expose container slots (e.g., pants pocket). The equipped bag exposes container slots as well. Each container slot has a size class (S / M / L, §6.3.1) that constrains what fits.
• There is no abstract "backpack" inventory. Total carry capacity = sum of container slots provided by currently equipped items.

6.6 Item loss summary table

Situation	Outcome
Session ends safely	All carried / equipped / placed items persist.
Session lost, item equipped	Item persists, fully equipped. Loss never forcibly removes worn clothing (§4.4).
Session lost, item in equipped bag	Item persists (bag is on the player).
Session lost, bag placed in world	Bag and contents are subject to the same theft chance as clothing (§6.3.4) and to sleep-loss if the player sleeps before retrieving them.
In-session, clothing past the grace period	Each check is a flat chance of theft (§6.3.4). Picking the item back up resets the grace timer.
Sleep with clothing left outside the apartment (voluntary or forced energy-zero cutscene)	Guaranteed loss of every clothing item left outside, regardless of grace / chance state.

6.7 Consumables — Food

Food items live in the UItemInstance system (§6.1). They come from two sources: ingredients at the Convenience Store (require cooking) and pre-made food at the Café (eat immediately). Eating consumes the item and applies any combination of the effects below.

Built-in effect (applies on any eating action, not per-food authored):

• Effective max energy fully restored — eating resets the hunger decay (§7.3). Effective max energy returns to the base max. This effect is universal — every food, no matter how small, fully clears hunger.

Instant effects (one-shot on consumption, no timer, per-food authored):

• Energy restore — adds a fixed amount of current energy (§7.3), clamped to the (just-restored) effective max.
• Lust decrease — subtracts a fixed amount of lust. Particularly relevant for non-Slut players who cannot masturbate to reset lust (§7.2).

Timed buffs (run for a per-item duration):

• Stamina regen + — raises staminaRecoveryRate above baseline (§7.4). The original ramen example.
• Max stamina + — additive bonus to base max stamina before the energy multiplier in §7.4 applies.
• Embarrassment-gain resistance — multiplier < 1 on the embarrassment-gain rate (§7.1).
• Lust-gain resistance — multiplier < 1 on the lust-gain rate (§7.2).

The effect list above is locked. No pulse-specific buffs, no caffeine "energy trickle," no other categories at launch.

Stacking:

• Different effect types always stack and run in parallel.
• Same effect type stacks additively up to a per-type cap. Two ramens (each +X stamina regen for 3h) compose to min(2X, cap) for 3h, with timers tracked independently.
• Per-type caps and the instant-effect amounts are TBD per §21.

Cooking:

• Ingredients from the Convenience Store must be cooked at the apartment before they become edible.
• Cooking runs through three minigames: slice (fruit-ninja-style), stir (rhythm / timing-mash), and cook (timing-stop). Performance on each minigame modulates the buff strength of the resulting dish; failing badly produces a weaker variant of the intended effect, never poison or negative buffs.
• Pre-made Café food has no cooking step — eat directly.

---

7. Attributes & Simulation

All attributes update in real time. Indoor and outdoor behavior is identical — being inside the apartment does not pause or slow attribute simulation. The apartment is a "safe zone" only in the sense that no NPCs are there to observe the player, which means embarrassment naturally decays toward baseline. Lust and energy continue to behave normally.

7.1 Embarrassment

• Increases when NPCs observe the player while:
  • Wearing revealing clothing (coverage-weighted).
  • Body parts exposed (full weight per uncovered part).
  • Performing "perverted actions" (masturbation, exposing, completing commission objectives).
• Increase rate is modulated by:
  • Base embarrassment increase rate (attribute).
  • Coverage of each visible-to-observer body part.
  • Pulse (higher → faster gain).
  • Day/night (day rate > night rate, see §10.1).
  • Recognition (higher → faster gain).
• Decreases over time when not being observed (embarrassment decrease rate).
• Reaches maxEmbarrassment → session lost.

7.2 Lust

• Increases passively in the background (rate TBD, possibly tied to coverage).
• Higher pulse increases lust gain rate.
• At maximum:
  • Blurred peripheral vision.
  • Player cannot tell whether NPCs are calling police or taking photos.
  • No indicator of which NPCs noticed them.
• Reset by masturbating (consumes more energy than usual, modified by energyDrainMasturbateModifier). Masturbation is a Slut-path unlock (§5.1) — players who haven't taken that path cannot reset lust within a session and must accept the max-lust handicaps above until they go home and masturbate in home before sleep.

7.3 Energy

• Drained by all activity. Base rate plus modifiers:
  • energyDrainRate (base, passive)
  • energyDrainRunModifier (running)
  • energyDrainWorkoutModifier (gym)
  • energyDrainCookingModifier (cooking)
  • energyDrainMasturbateModifier (masturbation)
• Recovered during sleep at energyRecoveryRate.
• Hard floor at 0 → session lost.
• Low effective energy reduces effective max stamina (see §7.4).

Max energy has two layers:

• Base max energy — the player's underlying ceiling. Raised by gym training (the progression lever).
• Effective max energy — the current ceiling on energy. This is what the player's energy bar can actually reach. Effective max decays over time at a hunger rate (maxEnergyDecayRate, TBD per §21), down to a floor (TBD, expressed as a fraction of base max) so the player is never fully starved into a forced game-over.
• Eating any food (§6.7) restores effective max energy fully to base max — this restoration overrides all other buffs and is the canonical way to reset hunger. It is a built-in effect of the eating action, not a per-food authored flag; every food does it.
• Recovered energy (sleep, instant-restore foods) is always clamped to effective max — sleeping does not also reset hunger; only eating does.

Together these mean a player who never eats slowly loses their available energy headroom each day, even with full sleep. The 90-day campaign forces a steady food cadence rather than allowing pure sleep cycling.

7.4 Stamina

• Used for running and other burst physical actions.
• Recovers at staminaRecoveryRate when not running.
• Base max raised by Slave-path leveling.
• Distinct from energy: stamina is short-term, energy is the daily budget.
• Effective max stamina is derived from base max in two passes (applied in order):
  1. Food buffs — additive; can raise effective max above base.
  2. Energy multiplier — scales the result by staminaEnergyFactor, where 0% energy → 50%, 80–100% energy → 100% (linear in between).
• Net effect: a well-fed but exhausted player has lower effective max stamina than a well-fed, rested player; food buffs cannot fully compensate for low energy.

7.5 Pulse

• Simulated heart-rate / arousal-rate attribute. Tracked alongside the other attributes in §7.
• Rises with:
  • Physical exertion (running, masturbation, sex acts).
  • Exposure events (a body part becoming uncovered, an expose action triggering).
  • Being observed while exposed.
• Decays toward a personal baseline when at rest.
• Modifies embarrassment gain (§7.1) and lust gain (§7.2) — both scale with pulse.
• Exhibitionist-path attribute pool: leveling can raise / lower baseline pulse and adjust pulse-response curves (tuning TBD).

7.6 Recognition

• Each photo taken by a Blogger NPC and published increases recognition.
• Higher recognition → faster embarrassment gain (NPCs recognize the player).
• Reducible by reporting articles on the city news site (PC, §11.1).
• Can be bypassed by hiding the face. Each of the face-cover slots — Face (mask) and Eyes (glasses / sunglasses / blindfold) — applies an additive recognition-resistance modifier when occupied. Either one alone provides a partial bypass; both equipped stacks toward a full bypass. The Head slot (hat / hood) is cosmetic only and does not contribute. Per-slot resistance magnitudes are TBD per §21.

7.7 Wanted

• Boolean. Set when a Snitch (§10.2) successfully reports the player to police during a session. The tag persists even if the session ends safely afterward (§4.3).
• While set, police patrols spawn during both day and night until the tag is cleared (§10.3). The day/night cycle does not gate patrols once the player is wanted.
• Cleared by either:
  • Tearing down every wanted poster in the city (§10.3), or
  • Being caught by police (§4.4) — capture also clears the tag along with applying the money penalty.

7.8 Reputation

• Earned by completing commissions; lost by failing or skipping them.
• Degrades passively over time, faster at higher values.
• Affects follower gain: positive/neutral → followers grow; negative → followers shrink.

7.9 Followers & Money

• Followers — running total of forum followers. Used in subscriber-style follower-gain math when posting photos.
• Followers generate money each day.
• More followers means more money for completing commissions.
• Money (Yen) — earned from commissions, livestream donations, selling worn underwear. Spent on rent, clothing, food, gym, beauty salon.

7.10 Attribute leveling

Each attribute upgrade in a path's pool costs only XP — no money, no separate currency. XP is a single shared pool, not per-path (§5): every commission, mission, and stream credits the same number, and the player decides which path's attribute pool to spend it on. With enough XP a player can max all three paths. Per-level XP costs (flat, escalating, or stepwise) are tuning numbers, not design decisions; they live in the per-path attribute table and are calibrated in playtest.

---

8. Movement

States: stand, walk, run, crouch, crouchWalk.

Design implications:

• Crouching reduces NPC detection radius (TBD multipliers).
• Running drains stamina and energy faster but is required for escape.

Movement should be implemented as a state machine on the character with clear transitions. UE5's enhanced input + ALS-style or GASP-style animation graph is appropriate (Oleh has prior GASP/Motion Matching context).

---

9. Phone

The phone is the player's diegetic UI hub. It can be used if it is in: hand, pocket (pants with phone-sized container slot), or equipped bag. Exception: the livestream app (§9.1.1) continues to operate while the phone is placed in the world, so the player can keep streaming after setting the phone down for a back-camera shot.

The phone is battery-powered (§9.8). A dead phone is unusable until charged — no forum, no camera, no maps. Plan accordingly.

9.1 Camera

• Front camera — held in hand, framed selfie shot.
• Back camera — phone is placed in the world via place camera action. A floating window shows the camera's view. Photos are triggered via hotkey while the camera is placed.
• All photos saved to Gallery.
• Photo follower gain is multiplied by the equipped phone's camera quality stat (§9.9). Better phone → more followers per equivalent shot.

9.1.1 Livestream

• Available at any time via the phone, regardless of whether the player is holding it or it is placed in the world.
• Same dual-mode setup as the camera: front-facing while held, back-facing when placed.
• Generates donation income in real time. Income rate scales with exposure visible in the stream (similar logic to photo follower-gain math, but continuous).
• Also grows followers in a continuous trickle. The live streamQualityScore is fed into FollowerGainCalculator (§13.5) per tick at a tunable rate; gains accumulate over the stream. Reputation sign applies — streaming with negative reputation shrinks the audience instead of growing it.
• streamQualityScore is multiplied by the equipped phone's livestream quality stat (§9.9). Better phone → higher donation rate and faster follower trickle from an identical scene.
• Recommended implementation: livestream is a StreamSession object owned by the phone, tickable, with viewerCount, tipRate, and streamQualityScore (a function of what the camera sees and player attributes).
• Ending the stream returns earnings to the bank and finalizes the accumulated follower delta.
• Tip requests. During an active stream, viewers post named action requests with a fixed yen reward attached. Each request is a small commission expressed in the §13.4 typed objective vocabulary — e.g. ExposeBodyPart(boobs, 8s) for a small tip, BeFullyNaked(15s) for a medium tip, TakePhotoAtLocation(fountain) for a large tip. The full tip-size range is wide; occasional high-roller requests pay several times a normal commission for correspondingly demanding objectives.
  • Requests appear as a phone popup with Accept / Decline hotkeys and a short countdown. Ignoring the popup until it times out is treated as a decline.
  • Decline has no penalty — viewers keep watching and baseline tip rate is unaffected. Players who don't want to engage with the request system can ignore it indefinitely and still earn passive donation income.
  • Accept spawns a live objective tracker for the duration of the request. Completing it in time deposits the tip into the bank along with the rest of the stream earnings.
  • Failing an accepted request drops the viewer count slightly (less passive income for the remainder of the stream) but does not damage reputation (§7.8). A failed accept is a missed opportunity, not a breach of contract.
  • Request frequency, tip-size distribution, acceptance countdown, and the viewer-count-drop magnitude on failure are TBD per §21. Higher viewer count generally → more frequent and higher-value requests.

9.2 Gallery

• Lists all captured photos with metadata (time, location, equipped state, exposed parts).
• Photos can be posted to the forum profile from here.

9.3 Forum (phone)

The phone is the primary access point for the forum. See §13.

9.4 Bank app

• Track balance, income, spending. Pay rent (or auto-pay).
• Income line items break down by source: commissions, livestream donations, in-stream tip-request completions, underwear sales (§15.1), and the weekly follower-income auto-deposit (§7.9) that lands at each week boundary.

9.5 Feetex (deliveries)

• Track pending online orders (clothing, food). Items arrive at the apartment door one in-game day after purchase.

9.6 Maps

• City map with marked shop locations, commission objectives, player position.

9.7 Health Tracker

• Displays the player's attribute readouts (energy, stamina, lust, embarrassment, recognition).
• Shows effective max energy alongside current energy so the player can read hunger state (§7.3) — the gap between base max and effective max is the "how hungry am I" signal.

9.8 Battery

The phone has a finite battery that drains while powered on and recharges at the apartment.

• Drain. Two layers, multiplied together:
  • Passive base — slow tick whenever the phone is powered on (idle in pocket, hand, or bag).
  • Per-app multiplier — foreground app raises the drain rate above baseline. Indicative ranking (concrete numbers TBD per §21):
    • Forum / Bank / Feetex / Maps / Gallery / Health Tracker: ~1× (baseline + minor UI cost).
    • Camera placed in the world (back-camera mode): ~3×.
    • Livestream: ~5× — heaviest drain. Livestream is the only app that ticks in the background and stacks its drain on top of whatever app is in the foreground.
• Charging.
  • Apartment charger — primary source. A charger spot in the apartment recharges the phone at a fixed rate (TBD) while the phone is placed on it.
  • Portable powerbank — purchasable consumable (Convenience Store, §10.4). Single-use; consuming one restores a fixed percentage of charge (TBD). Occupies one container slot (size S, §6.3.1) in the player's inventory and follows normal item-identity / theft rules.
• Dead battery (0%). Hard shutdown:
  • All apps lock. Opening the phone shows a "dead battery" overlay; no input passes through.
  • An active livestream ends immediately. Earnings accrued up to the cut-off are deposited; further viewers / tips that would have arrived are forfeit.
  • The phone can still accept a powerbank charge from the player's inventory — consuming a powerbank wakes the phone at the powerbank's restore percentage. Without a powerbank, the phone stays dead until the player reaches an apartment charger.
• Sleep. Sleeping at the apartment always charges the phone to 100%, whether or not the player explicitly docked it on the charger. This applies equally to voluntary sleep and to the energy-zero cutscene (§4.4) — that cutscene's sleep cycle includes the charge-to-full step.
• Persistence. Current battery percentage is part of the phone's UItemInstance state and persists across saves.
• Capacity scales with phone tier — total charge budget is multiplied by the equipped phone's battery capacity stat (§9.9). Per-app drain rates are unchanged; a Pro phone simply has more battery to spend.

9.9 Phone models

Three phone models exist. The starter model is owned at game start; the other two are purchased at the Electronics Shop (§10.4). The player may own multiple phones simultaneously — they are regular UItemInstance items (§6.1) that live in the wardrobe / inventory, and only the equipped phone is active per the §9 usage rules.

Tier	Model name	Camera quality	Livestream quality	Battery capacity	Source
1	Starter	1.0×	1.0×	1.0×	Owned at game start
2	Mid	> 1.0× (TBD)	> 1.0× (TBD)	> 1.0× (TBD)	Electronics Shop
3	Pro	highest (TBD)	highest (TBD)	highest (TBD)	Electronics Shop

Stat axes:

• Camera quality — multiplier on the exposureScore input to FollowerGainCalculator (§13.5) when posting a photo. A better camera turns the same scene into a higher-follower-gain photo.
• Livestream quality — multiplier on the per-tick streamQualityScore (§9.1.1). Better optics + mic → higher donation rate and faster follower trickle.
• Battery capacity — multiplier on total charge budget (§9.8). Per-app drain rates are unchanged; the better phone simply runs longer between charges.

The multipliers apply to new photos and stream ticks only. Buying a Pro phone never retroactively improves a tier-1 photo already posted.

Switching phones:

• Hot-swap at the apartment wardrobe. Equipping a different phone moves the previously-equipped phone back to the wardrobe.
• Battery percentage is per-phone-instance. Swapping does not transfer charge — a Pro phone left uncharged stays uncharged when you swap to it.
• Gallery, livestream history, and account state live on the player profile, not the phone. Swapping never loses photos, follower count, or stream stats.

Tier prices and exact stat multipliers are TBD per §21.

---

10. The City

10.1 Day / Night

Phase	In-game time	Real time	Effects
Day	08:00 → 20:00	~45 min	High NPC density. Faster embarrassment gain. Most shops open.
Night	20:00 → 08:00	~45 min	Low NPC density. Slower embarrassment gain. Most shops closed.

Police patrols ignore the day/night cycle: when the player has the wanted tag (§7.7), patrols spawn in both phases (§10.3).

Sleeping at home fast-forwards 8 hours.

10.2 NPC types

NPC	Behavior
Walker	Doesn't stop; reacts (animation/audio) but keeps walking. Low embarrassment contribution.
Stalker	Stops, stares. Sustained observation → faster embarrassment gain.
Blogger	Stops, takes photo. Photo → recognition increase.
Snitch	Stops, calls police. Triggers police spawn / wanted state if observed long enough.
Harasser	Walks toward player, attempts to grope. Player must evade.
Police	See §10.3.

10.3 Police

• Spawn during both day and night while the player has the wanted tag (§7.7). Patrol fixed routes.
• Detect player if face not hidden, or if revealing/no clothing.
• On detection: chase begins.
• If player breaks line of sight: police patrol last known position for a timer, then disengage.
• wanted persists across sessions until cleared.
• Wanted poster mechanic: wanted posters spawn in the city. Tearing them all down clears the wanted tag and stops police spawning until a new Snitch report retriggers it.

10.4 Locations

• Apartment — safe zone. Wardrobe, bed, PC, kitchen.
• Convenience store — cooking ingredients; portable phone powerbanks (§9.8).
• Café — pre-made food.
• Clothing shops — various types, each with a different inventory mix.
• Gym — increase max energy. Costs energy in the process. Costs money.
• Beauty salon — boobs size, ass size, makeup, hairstyle, hair color.
• Adult shop — Buy sex toys for the Nipples, Anal, and Vagina toy slots (§6.5).
• Electronics shop — Buy upgraded phone models. Sells the Mid and Pro tiers (§9.9). In-person only; no online variant.
• Streets / parks / alleys — commission space.
• Beach — open sand, daytime crowds, nighttime privacy. Strong fit for exhibitionist / swimwear content.
• Train station — platforms, concourses. Dense voyeur space; an indoor-transit setting distinct from streets.
• Casino — money-and-clothing gambling. Main floor + VIP room. See §10.4.2.

The location set above is locked for launch. School exterior and hot springs (onsen) were considered and explicitly cut.

10.4.1 Cuff / restraint removal

A restraint that blocks its own slot (i.e., declares BlockSlotChange(<own-slot>), §6.3.7) cannot be removed by normal unequip and requires the Key + timed unlock action:

• The player must possess the matching key for the restraint instance.
• Performing the unlock takes time; movement and all other actions are disabled for the duration. The restraint always comes off when the timer completes — the only question is how quickly.
• Unlock minigame. While the unlock action runs, a DBD-style skill-check minigame plays: a rotating pointer sweeps a circular meter that includes a small target zone, and the player presses a hotkey when the pointer crosses the zone. Each successful hit advances the removal progress faster than the baseline tick. Missed checks carry no penalty — they simply fail to grant the speed bonus, and the baseline timer keeps ticking down. There is no noise alert, no key loss, no fail state. The minigame is a pure accelerator for engaged players; impatient or unskilled players can ignore the checks and wait out the baseline timer.
• Per-restraint baseline timer length, skill-check frequency, target-zone size, and per-hit speed bonus are TBD per §21.
• There is no Helper NPC, no adult-shop unlock service, and no break-out option. If the player loses the key, the restraint stays on until a key is acquired again.

10.4.2 Casino

The casino is a location for spending time and (potentially) earning money. It splits into a main floor (always open) and a VIP room (gated; see below). The house edge means the expected value per session is intentionally negative — variance is the appeal, not steady income.

Games (main floor):

• Slots — single-button pull, instant outcome. Small-to-medium bets per pull. Pure RNG; rapid chase loop. Time cost is the player's choice — keep pulling as long as you want.
• Blackjack — vs. a dealer NPC. Skill-light card game. Each hand burns a few in-game minutes (dealer + decision pacing).
• Roulette — multiple bet types on a single spin. Each round burns a couple of in-game minutes.

The mixed pacing is deliberate: slots are the "fast burn," tables are the "time investment." Spending an afternoon at blackjack visibly eats into the commission window.

VIP room:

• Access is gated by a per-day entrance fee paid at the reception. One payment grants access for the rest of the in-game day; access expires at the next day boundary and must be paid again. No permanent unlock, no progression-based gating — anyone with enough money in the bank can enter, but every visit-day costs.
• Higher bet limits (higher floor on losses, higher ceiling on wins).
• Lower NPC density and a permissive dress code — nudity is socially accepted inside the VIP room, so the few NPCs present contribute less embarrassment than the main floor would.
• Strip-game tables live exclusively in the VIP room.
• The entrance fee functions as a built-in negative EV floor — even a winning night at the tables has to clear the day's entry cost before it's net profit.

Strip variants (VIP-only):

• A separate set of blackjack and roulette tables let the player bet clothing items as stakes (in addition to, or instead of, money).
• Losing a hand transfers the bet garment from the player's equipped slot to the casino lost-and-found — a safe inventory at the casino reception. The garment retains its UItemInstance identity (§6.1); it is not destroyed.
• Reclaiming a lost garment: win it back at the same table, or buy it back at reception for a flat fee (TBD).
• Strip outcomes don't bypass the normal embarrassment model — being stripped at the table and then walking out through the VIP room (low NPC density) or the main floor (higher density) still ticks embarrassment per §7.1.

Player attributes during casino play:

• Casino games themselves do not drive embarrassment, lust, energy, or pulse. Only the normal observation-driven model applies based on what other NPCs in the room can see.
• Energy is not consumed by gambling actions; food, sleep, and run-driven drain remain the only energy levers.

Economy hook:

• Casino is both an income source and a money sink. Net EV per session is negative on average; spikes are possible.
• Casino income is logged in the Bank app's income breakdown (§9.4) as a distinct line item; net losses appear in the corresponding spending breakdown.

---

11. PC (at home)

11.1 City News

• Random news plus articles about the player (posted by Blogger-driven events).
• Player can report articles with their photo → reduces recognition.

11.2 Clothing shop (online)

• Order clothing. 1-day delivery.

11.3 Food shop (online)

• Order food. 1-2 hours delivery.

---

12. Shops & Services Summary

Service	In-person	Online	Notes
Clothing	Yes (multiple shop types)	Yes (PC)	Online has 1-day delay.
Food (ingredients)	Convenience store	Yes (PC)	Cooking required.
Food (pre-made)	Cafe	Yes (PC)	Eat immediately.
Gym	Yes (city)	No	Increases max energy.
Beauty salon	Yes (city)	No	Body, hair, makeup customization.

---

13. The Forum

The forum is accessed via phone or PC. It is both diegetic and the primary mission UI.

13.1 Weekly missions

• Generated at week start, semi-random, weighted by player path progression.
• Rewards: money, XP, followers. Money / XP scale larger than daily commissions (week-long commitment); follower payouts are correspondingly larger.
• The player must accept a weekly mission from the forum before it counts as committed (same accept lifecycle as daily commissions in §13.2). Un-accepted weekly missions stay visible as goals and carry no penalty.
• An accepted weekly mission that the player fails to complete by the end of the week is marked failed and applies the template's failurePenalty (§13.4), which is heavier than the daily equivalent.
• A mission visible on the board that requires a path level the player hasn't reached is shown for context but cannot be accepted yet.
• Rewards land instantly on completion — money wires to the bank, XP credits to the shared pool (§7.10), and followers update on the profile. There is no return-to-home "collect rewards" step.

13.2 Daily commissions

• Generated at day start, semi-random, weighted by path progression.
• Rewards: money, XP, followers.
• The player must accept a daily commission from the forum to commit to it. Accepted commissions that aren't completed by day end trigger the template's failurePenalty (§13.4) — typically a reputation / followers loss. Un-accepted commissions sitting on the board carry no penalty; they are offers, not obligations.
• Multiple commissions can be accepted simultaneously; there is no built-in cap. The day timer is the natural limit on workload.
• Rewards land instantly on completion — money wires to the bank (visible in §9.4 as a commission-completion line item), XP credits to the shared pool, followers update on the profile. No return-to-home step is required.

13.3 Profile

• View stats, progression, path levels, posted photos.
• Post photos → follower gain (calculated from exposed body parts + visible coverage in the photo via the FollowerGainCalculator, §13.5).
• Livestream is initiated from the phone at any time (see §9.1.1), not from the forum profile. The profile displays livestream history and lifetime earnings.
• Level up attributes — paid for from the shared XP pool (§5, §7.10). The profile is the UI surface for choosing which path's attribute to upgrade.
• Displays weekly follower-income summary: current follower count, next weekly payout estimate, lifetime earnings from followers (the underlying auto-deposit lives in the bank app, §9.4).

Forum scope: The forum surface is intentionally minimal — the commission board (§13.1 / §13.2) and the player's own profile. There are no other users to browse, no threads, no popular-posts feed. The forum exists to drive the gameplay loop, not to simulate a social network.

13.4 Commission generation

Commissions should be procedural with template-driven content. Recommended template structure:

CommissionTemplate {
  id,
  pathRequirement: { path, minLevel },   // path ∈ { None, Slut, Exhibitionist, Slave }; None = path-neutral
  steps: [ list of typed objective steps ],
  rewardMoneyRange,
  rewardXPRange,
  rewardFollowersRange,
  failurePenalty,                         // canonical penalty when an accepted commission expires unfinished;
                                          // empty/zero = generator applies a default appropriate to the reward tier
  validLocations: [ ... ],                // locations where the commission can run; applies to the whole commission
}

Generator rules:

• The generator never emits a template the player cannot complete: pathRequirement (including path: None for path-neutral commissions) is respected, and templates whose steps reference path-locked actions (e.g., PerformAction(masturbate) for non-Slut players) are filtered out before they reach the board.
• The failurePenalty field is authoritative. When empty / zero, the generator substitutes a default penalty scaled to the reward range.
• Weekly templates and daily templates draw from the same pool; the daily/weekly distinction lives on the template tier (longer step chains, higher reward bands).

Typed objective steps (initial set):

• ExposeBodyPart(part, durationSeconds)
• BeFullyNaked(durationSeconds) — fully unclothed for the duration; no NPC requirement.
• BeFullyNakedNearNPCs(count, durationSeconds)
• WalkNakedDistance(meters)
• MoveDistanceFromClothing(meters)
• PerformAction(actionId) (e.g., masturbate) — actions with path gating are only used in templates whose pathRequirement matches; generator filter enforces this.
• BeObservedByNPCType(type, durationOrCount)
• TakePhotoAtLocation(locationTag)
• DeliverItemTo(npcOrLocation) — the player must source the item from their own inventory. The commission does not auto-issue items on accept. Worn-underwear sales (§15.1) are the canonical use case. "Deliver this pre-issued package to X" is intentionally not supported by this primitive — if that flavor is needed later, add a separate DeliverIssuedItemTo step rather than overloading this one.

Steps compose: a single commission step list may chain primitives that must all be satisfied (concurrently or sequentially as specified by the template).

Example commissions from the brief that should be representable:

• "Get naked in front of 1 person" → BeFullyNakedNearNPCs(1, ~3s).
• "Walk with breasts exposed for 10 seconds" → ExposeBodyPart(boobs, 10).
• "Walk naked for 30 seconds" → BeFullyNaked(30).
• "Move 50m away from your clothing while naked" → BeFullyNaked(durationSeconds) + MoveDistanceFromClothing(50) (both must hold).

13.5 Subscriber math (rough)

followerGain = base(exposureScore) * reputationFactor * (1 / log(followerCount + e))

• exposureScore is the input — for a posted photo it is computed from exposed body parts + visible coverage in that photo, then multiplied by the equipped phone's camera quality stat (§9.9); for a livestream tick it is the current streamQualityScore, which already includes the phone's livestream quality multiplier (§9.1.1).
• reputationFactor is signed. Positive / neutral reputation → positive followerGain (followers grow). Negative reputation → negative followerGain (followers shrink). This is the §7.8 "positive vs. negative reputation" branch expressed in one number.
• The 1 / log(followerCount + e) term enforces diminishing returns: at followerCount = 0 the divisor is 1.0; growth slows as the audience grows.

Both photo posts and livestreams run through the same FollowerGainCalculator. Photos compute once on submission; livestreams call it per tick at a tunable rate and accumulate. Completed in-stream tip requests (§9.1.1) apply an additional follower bonus on top, treated as a mini-commission completion.

Concrete numbers to be calibrated in playtest. Keep this isolated in FollowerGainCalculator for tunability.

---

14. UI / UX

14.1 Quick action menu

Radial or hotbar accessible mid-session. Actions:

• Unequip / equip clothing (per slot).
• Expose body part (per garment with canExpose).
• Open phone.
• Drop bag / pick up bag.
• Masturbate (Slut-path unlock, §5.1 — entry hidden until unlocked).
• Crouch / stand.

14.2 HUD (in-session)

• Attribute bars (energy, stamina, embarrassment, lust) — minimal/peripheral when low, more prominent when nearing thresholds.
• Equipped clothing summary (small icons).
• Day/night and clock readout.
• NPC awareness indicator (who has noticed you) — disabled at max lust per §7.2.
• Active commission objective text.

14.3 Out-of-session UI

Forum, bank, gallery, shops are all in-fiction screens (phone/PC). Avoid out-of-fiction menus where possible.

14.4 Accessibility & comfort

• Subtitle support for any voiced dialogue.
• Camera "place" via voice command must have a non-voice fallback (hotkey).
• Photo-sensitive warning if any flash/strobe effects are used.

---

15. Economy

15.1 Income sources

• Daily commissions (largest reliable source).
• Weekly missions (larger lump-sum payouts).
• Livestream donations (variable, riskier, always available via phone).
• Selling worn underwear — two delivery methods:
  • Feetex shipping — drop the item in a Feetex shipping box at the post office or convenience store. Payment arrives 1 in-game day later (mirrors Feetex's existing 1-day delivery delay).
  • Drop-off — travel to a specified location (varies per order) and leave the underwear there. Immediate payment, but the location may be in a high-risk area depending on the order. Tactical trade-off: convenience vs. drop-off-style commission tension.
• Photo posts (indirect) and accumulated followers — drive the weekly passive follower income (§7.9). Higher follower count → larger weekly payout and larger commission payouts.
• Casino winnings (§10.4.2) — high-variance, negative-EV-on-average. Not a reliable income source; treat as gambling, not as a salary.

15.2 Costs

• Weekly rent — flat across the campaign. No escalation, no event-driven spikes. The pressure comes from the 90-day timer and other expenses, not from a moving rent target.
• Clothing.
• Food / ingredients.
• Gym membership / beauty salon.
• Adult shop.
• Casino losses (§10.4.2) — the dominant cost over time, by design. Strip-game losses additionally cost clothing inventory (reclaimable but not free).

15.3 Tuning targets (placeholder)

Tier	Daily income	Weekly rent	Notes
Early	¥3–8k/day	¥20k/week	Pressure forces commissions.
Mid	¥10–20k/day	¥30k/week	Player can save / invest.
Late	¥25k+/day	¥50k/week	Livestream meta unlocked.

Numbers are placeholders for playtest calibration.

---

16. Save / Persistence

16.1 What must be saved

• Player attributes and progression.
• All world items (position, orientation, condition, container relationships).
• All NPC state? (probably just template + scheduling seed; full NPC state is too heavy)
• Forum state: active commissions, weekly missions, followers, reputation, photos posted.
• Calendar: current day, current time, week number.
• Wanted state, recognition, pending deliveries.
• Apartment state.

16.2 Save points

• Automatic on sleep.
• Automatic on safe session end.
• Manual save in apartment (recommended).
• No mid-session save (preserves tension) — design call, open for revision.

16.3 Item identity in save

The unique-instance rule (§6.1) means save must serialize each item by instance ID, not by template. Container parent references must be stable across save/load.

---

17. Technical Architecture (UE5)

17.1 High-level systems

• PlayerCharacter (Pawn + ASC) — movement, equipment slots, attribute set.
• AttributeSet — embarrassment, lust, energy, stamina, recognition, money, reputation. GAS-based.
• EquipmentComponent — slot management, equip/unequip, expose actions.
• InventoryComponent — generic, reused by player, bags, containers.
• ItemActor — base for all world items. Wraps ItemInstance.
• ItemInstance (UObject) — runtime data, serialized with save.
• ItemDefinition (DataAsset) — static data per item template.
• SessionManager (GameMode or subsystem) — session start/end, loss resolution.
• TimeOfDaySubsystem — clock, day/night, week, calendar.
• ForumSubsystem — commissions, missions, profile, followers, reputation.
• NPCManager — spawning, density, type weighting by location and time.
• RecognitionSubsystem — photo-to-news pipeline, article state, reporting.
• PoliceManager — patrols, wanted state, line of sight, chase.
• PhoneSubsystem — tickable phone state: battery drain (passive base + per-app multiplier, §9.8), active app, livestream session lifecycle, charger interaction at the apartment. Owns the phone's UItemInstance extension for battery percentage.
• SaveSubsystem — orchestrates serialization across all of the above.

17.2 GAS usage

GAS is well-suited here: attributes, modifiers (clothing-based, recognition-based, day/night), and gameplay effects (food buffs, wanted status, lust max) all map cleanly. Use:

• UAttributeSet for all numeric attributes in §7.
• GameplayEffects for buffs, debuffs, passive drains.
• GameplayTags for NPC observation state, body part exposure, clothing flags.
• GameplayCues for visual/audio reactions.

17.3 Replication

None

17.4 Data-driven content

Clothing, commissions, food, NPC templates all live as DataAssets (or DataTables for tabular content). Designers (eventually) should be able to add items without touching C++.

17.5 Class boundaries

• C++ for: attribute math, simulation tick, equipment/inventory mechanics, session loss resolution, save/load, AI controllers, time-of-day, commission validation.
• Blueprint for: animation event hookups, cosmetic feedback, individual mission template wiring, UI widgets, world placement.

17.6 Open technical questions

• Animation system: borrow GASP/Motion Matching approach? Custom?
• Crowd density: instanced NPCs vs. full pawns? Hybrid (full pawns within awareness radius, instanced beyond)?
• Cloth/clothing rendering: skeletal mesh swap vs. modular character system? Modular is strongly recommended given the dressing system depth.
• Photo system: in-engine render-to-texture (preferred) vs. screenshot-with-overlay.

---

18. Content Inventory (initial scope target)

18.1 Minimum viable content for vertical slice

• 15–20 clothing items spread across paths (5 Slut, 5 Exhibitionist, 5 Slave, 5 neutral).
• 3 bag variants.
• 8 food items (4 cooking ingredients, 4 pre-made).
• 5 NPC types (Walker, Stalker, Blogger, Snitch, Harasser) + Police.
• 1 functional city district with all shop types.
• 20 commission templates yielding ~5x procedural variation.
• Apartment + PC + phone fully functional.
• 1 full week of gameplay playable end-to-end.

18.2 Full launch target (TBD)

• 60+ clothing items.
• All NPC types polished, multiple visual variants each.
• Full city, 4+ districts, including the Beach, Train Station, Casino (main floor + VIP room), and Electronics Shop locations (§10.4) added on top of the vertical-slice shop set.
• 100+ commission templates.
• All 3 paths leveled to cap with distinct content.

---

19. Risks & Mitigations

Risk	Likelihood	Mitigation
Item-identity persistence is complex and error-prone.	High	Build save/load and item ID system first, before any content. Heavy testing.
GAS attribute interactions create unintended feedback loops (e.g., embarrassment ↔ recognition).	Med	Centralize modifier sources in a debug overlay. Lock down formula tests.
Procedural commissions feel repetitive.	High	Strong template variation, location/time-of-day modifiers, themed weekly arcs.
NPC density vs. performance.	Med	LOD'd AI: full pawns near player, instanced "extras" at distance.
Adult-content distribution constraints.	High (business)	Plan for Steam-incompatible content split / Patreon / itch / direct distribution from day one. Out of scope for this GDD but flag now.
Scope (90-day timer × 3 paths × commission variety).	High	Vertical slice first. Cut path content before cutting systems.

---

20. Resolved Design Decisions

Decisions previously open, now fixed:

1. Camera perspective: Third-person.
2. Dangerous-stalker NPC: Removed. Was a documentation typo, not an intended NPC. The Stalker (watching, low-threat) is the only stalker-type NPC.
3. Indoor attribute behavior: Identical to outdoor. No pause or slowdown. The apartment is safe only because no NPCs are present to observe.
4. Player customization: Beauty salon only. No separate character creator at run start.
5. Livestreaming: Available any time via the phone, held or placed. Mirrors photo capture (front-facing held, back-facing placed). See §9.1.1.
6. Selling worn underwear: Feetex shipping (1-day, convenient) or specified drop-off location (immediate, risk-based). See §15.1.
7. Rent: Flat. No escalation.
8. Run length: 90-day campaign. Endless mode unlocked after first completion (rent-eviction disabled, all other systems intact). See §3.3.
9. Cuff/restraint removal: Key + timed unlock action only. No Helper NPC, no paid adult-shop service. See §10.4.1.
10. Voice commands: Not used. Hotkey-driven only.
11. Equipment slot list: 18 slots, locked. Body clothing (8): Outerwear, Top, Bottom, UnderwearTop, UnderwearBottom, Bodysuit (exclusive with the prior four), Socks, Footwear. Accessories (4): Head, Face, Eyes, Neck. Restraints (3, independent): WristRestraint, AnkleRestraint, NeckRestraint. Toys (3, independent): Nipples, Anal, Vagina. Face-cover bypass for recognition is driven by Face and Eyes. Toys do not contribute to coverage. See §6.5 for the full table.
12. City location list: locked for launch. Apartment, Convenience Store, Café, Clothing Shops, Gym, Beauty Salon, Adult Shop, Electronics Shop, Streets / Parks / Alleys, Beach, Train Station, Casino. School exterior and hot springs (onsen) were considered and cut. Vertical slice (§18.1) covers the basic shop set; Beach, Train Station, Casino, and Electronics Shop are full-launch additions. See §10.4.
13. Attribute level-up cost: XP only. XP is a single shared pool (not per-path); the player chooses which path's attribute pool to spend it on, and may eventually max all three. No money, no separate currency. See §7.10.
14. Food effect vocabulary: locked. Two instant effects (energy restore, lust decrease) plus four timed buffs (stamina regen +, max stamina +, embarrassment-gain resistance, lust-gain resistance). Stacking: different types parallel; same type additive up to a per-type cap. No pulse buffs, no caffeine trickle. See §6.7.
15. Carriable categories: locked. Clothing, Bags, Phone, Consumables (food), Toys. No other gadget categories beyond the phone. See §6.2.
16. Casino: added to the city (§10.4, §10.4.2). Main floor (slots, blackjack, roulette — money only). VIP room — gated by a per-day entrance fee (no permanent unlock; pay each day you want in). Permissive dress code; strip-game blackjack and roulette tables that bet clothing. No poker. Mixed pacing: slots instant, table games take in-game minutes. Net EV negative — variance is the appeal.
17. Police capture, can't pay: short non-interactive holding-cell cutscene, then time fast-forwards to the next morning. The night served settles the debt; no money owed afterward. Replaces the earlier "skip days proportional to unpaid amount" rule. See §4.4.
18. Loss precedence during a police chase: if the player is actively being chased by police (per §10.3) and any other loss condition fires (embarrassment max, energy zero), the loss resolves as police capture — the chase wins. The cops catch the player as they collapse. Applies even without a prior wanted tag. See §4.4.
19. Phone models: 3 tiers (Starter / Mid / Pro). Three stat axes per tier — camera quality (photo follower-gain multiplier), livestream quality (streamQualityScore multiplier), and battery capacity (total charge budget multiplier). Bought in-person at the new Electronics Shop (§10.4). Player may own multiple phones simultaneously; gallery / followers live on the profile, battery is per-phone-instance. See §9.9.
20. No isUnderwear flag on clothing. Coverage math no longer special-cases underwear. Authors set coverage directly to reflect concealment (including the psychological "just underwear" discount); the value in the editor is the contribution to coverage math. See §6.3 / §6.3.2.
21. Per-item restrictions list replaces isRestrictive boolean. Each clothing item carries an optional restrictions list with granular entries: BlockRun, BlockCrouch, BlockPhoneUse, BlockItemPickup, BlockMasturbate, BlockExposeAction, and parameterized BlockSlotChange(slot). Restrictions union across equipped items. Restraints typically declare BlockSlotChange(<own-slot>) to force the §10.4.1 Key removal flow. Non-restraint items (heels, tight skirts) can declare lighter restrictions. See §6.3.7.
22. Restraint-removal unlock minigame. DBD-style skill-check minigame (rotating pointer + target zone). Successful hits speed up the removal. Missed checks have no penalty — they just don't grant the speed bonus. The restraint always comes off when the baseline timer expires. No noise alerts, no key loss, no fail state. See §10.4.1.
23. Commission rewards land on completion, not on return home. Money wires to the bank instantly, XP credits to the shared pool, followers update on the profile. No "collect rewards" step at the apartment. See §13.1 / §13.2 / §4.3 / §3.1.
24. Hunger via max-energy decay. Effective max energy decays over time (a hunger rate); eating any food restores effective max to base max as a built-in universal effect (no per-food authoring). Sleep restores current energy but does NOT reset hunger — only eating does. Floors at a TBD fraction of base max so the player can't be starved into a forced game-over. See §7.3 / §6.7.

21. Open Design Questions

These remain genuinely unresolved and should be addressed during implementation:

1. NPC theft tuning: grace periods (T_grace, T_grace_bag), per-tick chance (P_theft), and check-tick interval — see §6.3.4.
2. Concrete tuning numbers for embarrassment / lust / energy / stamina / pulse rates.
3. Specific ending conditions for the 90-day campaign (path level + follower thresholds).
4. Manual save in apartment: enabled or auto-save only?
5. Photo system implementation: render-to-texture vs. screenshot-with-overlay (§17.6).
6. Crowd density: full pawns vs. instanced extras with awareness-radius promotion (§17.6).
7. Modular character system specifics — base mesh, layering scheme, attachment sockets.
8. Photo-post follower decay curve and per-photo cap.
9. Stamina ↔ energy multiplier curve specifics (linear vs. eased between 0% and 80% energy, §7.4).
10. Phone battery tuning (§9.8): passive base drain rate, per-app multipliers, total capacity (target ~real-time minutes of livestream), apartment-charger recharge rate, powerbank restore percentage, and powerbank price.
11. Livestream tip-request tuning (§9.1.1): request frequency curve vs. viewer count, tip-size distribution (including high-roller frequency), countdown length on the accept popup, and the per-failure viewer-count drop magnitude.
12. Face-cover recognition resistance per slot (§7.6, §6.5): per-slot resistance magnitudes for Face and Eyes and the stacking curve.
13. Food tuning (§6.7): instant-effect amounts (energy restore, lust decrease), per-buff durations and magnitudes, per-type stacking caps, and the cooking-minigame scoring → buff-strength curve.
14. Casino tuning (§10.4.2): RTP per game (slots, blackjack, roulette), bet ranges per tier (main vs. VIP), the VIP per-day entrance fee, in-game-minutes burned per table-game round, and the strip-garment buy-back fee.
15. Phone-tier tuning (§9.9): exact multiplier values for Mid and Pro on each of the three stat axes (camera quality, livestream quality, battery capacity), and the Electronics Shop purchase prices for each tier.
16. Restraint unlock-minigame tuning (§10.4.1): per-restraint baseline timer length, skill-check frequency, target-zone size, and per-hit speed bonus.
17. Hunger tuning (§7.3): maxEnergyDecayRate (effective max energy lost per in-game hour), the effective-max floor as a fraction of base max, and any per-food bonus on top of the universal full-restore (if we ever want a "big meal heals you faster" lever).

---

22. Glossary

• Coverage — clothing's 0–1 score for how much it conceals a body part.
• Commission — short, accept-now mission, daily-generated, from the forum.
• Mission — weekly task, generated at week start.
• Session — the active outdoor play state between leaving and returning to the apartment.
• Path — Slut / Exhibitionist / Slave progression track.
• Pulse — heart-rate / arousal-rate attribute. Higher pulse multiplies embarrassment and lust gain. Exhibitionist-path attribute pool. See §7.5.
• Recognition — how known the player is in the city. Multiplies embarrassment gain.
• Wanted — binary police-target flag. Set by Snitch reports; cleared by tearing down posters or by capture. See §7.7.
• Feetex — in-fiction package tracking and shipping service. Handles both incoming deliveries (1-day delay) and outgoing worn-underwear shipping.
• Endless mode — post-campaign unlock; rent eviction disabled, all other systems active.

---

23. Document Conventions

• "TBD" = explicit pending decision, must be resolved before relevant code is finalized.
• Code names in monospace. Final names should match these unless decided otherwise.
• All numeric values without units are placeholders for tuning.
• When this doc and the code disagree, this doc wins until updated.