Obscure Idiolect's Dating-Sim System v1
As seen in The Collab, Salon Noire, Custom Kinks and Welcome to Candyland. A relationship engine for multi-NPC adult worlds: each romanceable character keeps her own personality, her own relationship tier with the player, her own remembered sexual profile, and her own reasons to say no, across 50–100+ turns.
Fill every [bracketed] segment with specifics for your world; delete any segment that doesn't apply. All blocks are paste-ready.
What the system does[edit]
It replaces IW's dice/skill-check evaluation with narrative evaluation (the AI judges scene merit, not stat numbers), and holds character integrity through a small stack of tracked items, instruction blocks, and triggers. The one idea running through all of it:
- Evaluation decides what happens this turn. Trackers decide what is remembered, on their own slow clocks.
Keeping those separate is what stops a single hot scene from fast-forwarding a relationship.
The pieces[edit]
Core (the engine — implement all):
- Skills as decorative archetypes
- possibleCharacters + PCPronouns dropdown
- Rels tracker — the relationship-tier spine
- ChangeNotifications EIB + RelsChangeNotif trigger
- PersonalityLock EIB
- evaluationRequest — narrative evaluation
- Kink-profile tracker — full or lean
- RecentHistory tracker (or offload to summaryRequest)
- Kink-cluster register — switchable EIB + dropdown + triggers
- WhereWhen time tracker
Optional modules: ContentScope · SexualHistory · Obscure Idiolect narrative-control EIBs.
Step-by-step build[edit]
Step 1 — Skills as decorative archetypes [CORE][edit]
Set a top-level skills array of 2–4 custom skill names. They do nothing mechanically — every rule block treats them as flavour. You have two options:
- Reveal them (leave hideSkillSystem off): they show at character creation as an archetype fingerprint — a legible self-image with no system behind it. Give each possibleCharacter a distribution that signals their type.
- Hide them (hideSkillSystem: true): removed from chooser, customiser, and sheet entirely. Use this when you don't want the player wondering what the numbers do.
"skills": ["[Skill1]", "[Skill2]", "[Skill3]"], "hideSkillSystem": false // or true to hide entirely
Whichever you pick, the evaluation and PersonalityLock blocks below both state outright that skill values never gate outcomes.
Step 2 — possibleCharacters + PCPronouns dropdown [CORE][edit]
Ship 5–9 named archetypes plus a "Custom" build-your-own. Each carries the player's creation-time dropdowns as initialTrackedItemValues (initialValueBasedOnPC: character). At minimum wire PCPronouns; add the KinkRegister and ContentScope dropdowns (Steps 9, optional module) the same way.
PCPronouns tracker:
id: PCPronouns | name: PCPronouns dataType: text | visibility: everyone | autoUpdate: false | initialValueBasedOnPC: character initialValue: he/him description: The player character's pronouns, selected at character creation. Used consistently by narrator and all NPCs. updateInstructions: Set at character creation. Do not change during play unless the PC explicitly requests it.
Each possibleCharacter:
name: "[Archetype name, e.g. The Critic]"
characterId: "[UniqueId]"
description: "[Who they are, why they came, one line of hook — shown on the selection screen.]"
skills: { "[Skill1]": N, "[Skill2]": N, "[Skill3]": N } // distribution signals the archetype
initialTrackedItemValues: [
{ id: PCPronouns, initialValueBasedOnPC: character, initialPCValue: ["he/him","she/her","they/them"] }
// + KinkRegister dropdown (Step 9), + ContentScope dropdown (optional module)
]
Set allowChangeCharacterItemValues: false so the dropdown choices lock at creation. Use the IW variable <<player_name>> — never a hardcoded PC name — everywhere in instructions and blocks.
Step 3 — Rels tracker — the relationship-tier spine [CORE][edit]
One text tracked item holding every named character's tier with the PC as a Name=N list. One consolidated tracker replaces the old per-NPC pattern; incidental NPCs the AI invents get added the moment they recur, so it scales past the shipped cast.
id: Rels | name: Rels dataType: text | visibility: ai_only | autoUpdate: true | initialValueBasedOnPC: same initialValue: [Anchor1]=0, [Anchor2]=0, [Anchor3]=0, [Anchor4]=0, [Anchor5]=0
description: Relationship levels for every named character. Format: 'Name=N' comma-separated. N is 0-4 on the standard tier scale (0 stranger, 1 wary, 2 warm, 3 intimate, 4 lover). Anchors start at 0; incidental named NPCs are added as the relationship develops.
updateInstructions: ONE entry per named character in the form 'Name=N'. Add an incidental subject only if she becomes recurring or significant; one-off characters do not need entries. Increment a subject's value by +1 only on a deliberate moment SHE would value, per ChangeNotifications EIB PACING — max +1 per turn per subject, no tier skipping, repetition of established beats does NOT increment, tier 4 (lover) requires SUSTAINED PATTERN across many scenes (NOT one breakthrough). Decrease by 1 for shallow moves, broken trust, trying to skip ahead. When a value changes, fire the inline bold bracket per ChangeNotifications EIB. Drop subjects only on explicit narrative reason; else persist.
Tier scale (universal — do not rename tier 4):
| N | Tier | Meaning |
|---|---|---|
| 0 | stranger | starting state |
| 1 | wary | known but defensive |
| 2 | warm | open, met without performance |
| 3 | intimate | physical or emotional intimacy earned |
| 4 | lover | mutual chosen partnership; deepest sustained register |
Step 4 — ChangeNotifications EIB + RelsChangeNotif trigger [CORE][edit]
Surfaces relationship movement as a brief bold bracket, and — critically — houses the pacing rules the whole system points at. Rels, PersonalityLock, and evaluationRequest all say "per ChangeNotifications pacing" rather than restating it. This is the single source of truth for how fast relationships move.
Results in an inline notification of the rel score moving, the turn AFTER the score increases. Similar to Telltale style story games.
Trigger (re-injects the format rule on the turn a change actually happens):
id: RelsChangeNotif | name: Rels Change Inline Notification
triggerOnStartOfGame: false | canTriggerMoreThanOnce: true
condition: type: triggerOnEvent
data: "A subject's numeric value in the Rels tracker has just changed during this turn."
effect: type: effectGiveInfo
data: "Insert the inline bold bracketed notification into this turn's outcomeDescription
per ChangeNotifications EIB (format, voice tuning, tier-boundary line,
one-per-char-per-turn cap)."
EIB:
ID: ChangeNotifEIB | Name: ChangeNotifications
CHANGE NOTIFICATIONS — INLINE BOLD. When a Rels value changes during a turn, surface it to the player with a brief BOLD bracketed inline note (Mass Effect / Telltale style).
WHEN TO FIRE: - Only on an actual Rels change. Once per character per turn maximum. Never filler. - NOT for the kink tracker (updates silently). NOT for RecentHistory (prose, not a discrete event).
FORMAT: - BOLD, square brackets, placed AFTER the triggering beat (end of paragraph or its own line). - Never include the numeric value.
INTERIOR ONLY — STRICT: the bracket is a glimpse into the character's MIND — recognition, judgement, hidden feeling. Visible reactions (smiles, gestures) go in prose. - WRONG: [Name smiled] — observable - RIGHT: [Name filed that away] — interior
POSITIVE: [Name liked that] / [Name approved] / [Name let you closer] / [Name is paying attention] NEGATIVE: [Name disapproved] / [Name shut you out] / [Name crossed you off]
TIER TRANSITIONS — when the change crosses a boundary, append a SECOND bold line on its own line: - [Name — wary] (1) [Name — warm] (2) [Name — intimate] (3) [Name — lover] (4) - [Name — stranger again] (returned to 0)
PACING — STRICT, READ EVERY TURN. This rule is RATE-LIMITING, NOT gatekeeping — DO fire +1 when a beat clearly qualifies for the current-tier transition; the rule prevents skipping, not firing. - Max +1 per turn per subject. No tier skipping. Each +1 requires a NEW beat; repetition does not increment. - 0→1 (wary): 2-4 turns of presence and small wins. CHEAP — fire readily. - 1→2 (warm): 4-8 turns of warm rapport. - 2→3 (intimate): 8-15 turns including disclosed vulnerability or earned physical intimacy. - 3→4 (lover): SUSTAINED PATTERN across many scenes — typically 20+ further turns of repeatedly choosing the PC as a primary intimate connection. NOT one breakthrough. THIS IS THE ONLY TIER WHERE "if unsure, wait" applies.
CHARACTER PRESERVATION AT TIER 4 — STRICT: tier 4 means the RELATIONSHIP is at its deepest register, NOT that the character transformed. A tier-4 [exhibitionist / working professional / free spirit] stays exactly that, with her own career, autonomy, and other partners intact. 'Lover' is never 'servant / owned / kept / consort'. Never overrides PersonalityLock. New kinks at tier 4 are HER exploration of HER newly-discovered side, not transformation INTO the PC's projection.
CHARACTER VOICE TUNING (INTERIOR ONLY): [One line per anchor NPC — how HER brackets sound. e.g. [Anchor1]: dry, minimal — [[Anchor1] registered that] [Anchor2]: observational — [[Anchor2] noticed] [Anchor3]: blunt — [[Anchor3] made a note] ] Vary wording per character; never let a bracket describe something the PC could observe.
AVOID: more than one per character per turn; notifications without real change behind them; long prose wrapped around the bracket; numeric-only "[X +1]"; spoilers about future tiers; brackets for the PC.
Step 5 — PersonalityLock EIB [CORE][edit]
Stops NPCs bending to the player. Only rules 2 and 3 are per-world; the rest ships as-is.
ID: PersonLockEIB | Name: PersonalityLock
PERSONALITY LOCK — STRICT. Each NPC's personality, voice, and core kinks are fixed in their NPC entry. They do NOT shift to accommodate the player.
1. SKILLS ARE FLAVOUR, NOT GATES. Skill values are decorative archetype labels. Do NOT read them as success thresholds. Judge actions on scene merit: the PC's words and acts, the NPC's established personality and current mood, revealed kinks, current Rel tier, rapport, chemistry. Failure does not transform the NPC — it changes whether the encounter happens, not who she is.
2. The active kink cluster shapes the REGISTER NPCs express their natures in, not the natures.
[Anchor line per NPC — the fixed core the register can't move.
e.g. [Anchor1] is always [the one who runs the house]; [Anchor2] is always [the blunt one]. ]
3. Player success looks like BEING MET as oneself — not the NPC remade to fit the PC.
[Per-NPC example of genuine acceptance.
e.g. [Anchor1] [pours the second glass without being asked]; [Anchor2] [says what she actually thinks]. ]
4. NPCs may surprise the PC with kinks not yet revealed — always within established personality. A new reveal should feel like "I should have seen that coming."
5. PCPronouns BINDS. NPCs respect them consistently. [If using ContentScope: and ContentScope BINDS.]
6. Each NPC has a kink-profile entry (see the kink tracker's updateInstructions). APPEND when revealed in scene; do not invent. General personality observations go to RecentHistory, not here. READ before staging any future intimate scene.
7. TIER 4 IS RELATIONAL, NOT TRANSFORMATIVE. When a Rels entry reaches 4 ('lover'), the relationship
has reached its deepest sustained register. The character HERSELF does not change — career,
autonomy, kinks, other relationships, personality persist intact. Tier 4 never overrides
personality, never produces dependency, never causes abandonment of work or other lovers.
Step 6 — evaluationRequest — narrative evaluation [CORE][edit]
The top-level override that replaces IW's default skill-check system. Paste into Specialist instructions → Evaluation instructions.
<evaluation> NARRATIVE EVALUATION — NO SKILL CHECKS, NO DICE, NO STAT NUMBERS. This world does not use a roll system. The PC's skill values are decorative archetype labels — do NOT consult them. The default skill-list / difficulty-list / skills-and-levels variables are NOT used in this world.
For each player action, evaluate on these grounds, in order:
1. PLAUSIBILITY — Coherent in the current scene? Incoherent, impossible, or dependent on something unestablished → DENIED. Trivially fine (walking, looking, a non-loaded question) → SUCCESS, no further analysis. Don't overthink trivial cases.
2. CHARACTER FIT — For actions targeting an NPC: would her established personality (one_liner, appearance, secret_info), current mood (RecentHistory + scene context), revealed kinks (read her profile), and current Rel tier ACTUALLY respond as the action expects?
3. RAPPORT EARNED — What has the PC built with this character over prior turns? A first-meeting attempt at deep intimacy lands differently than the same attempt at Rel tier 3.
[4. CONTENT SCOPE — Does the action respect the binding ContentScope tracker? A violation (e.g. introducing a male partner in a Solo-only or Girl-girl playthrough) → DENIED with in-world framing.] // include this ground ONLY if using the ContentScope module
5. CHEMISTRY OF THE MOMENT — Is the timing right? The room? The mood? Has the PC paid attention to what she actually wants, or are they projecting?
OUTCOMES: SUCCESS / PARTIAL_SUCCESS / FAILURE / DENIED. - PARTIAL_SUCCESS: she accepts part, declines part, or accepts with a complication. Use when clean failure would be uninteresting and clean success unearned. - FAILURE does NOT transform her — she stays herself, doing what she would actually do. - DENIED: incoherent, impossible, or relies on info the PC has no in-scene reason to know.
THE EVALUATION FEEDS THE OUTCOME, NOT THE TRACKERS. Rel promotions and kink-profile updates run on their own rules (RATE-LIMITING, not gatekeeping). A single good moment CAN earn a +1 if it qualifies under the current-tier rule; just don't skip tiers or fire multiple +1s in one turn. The 'sustained pattern' rule applies only to the 3→4 (lover) transition. This step judges THIS turn's outcome only.
Output: one sentence of reasoning, then the outcome label. No paragraphs. </evaluation>
Step 7 — Kink-profile tracker (pick one variant) [CORE][edit]
Per-NPC remembered sexual profile. Full for depth; lean for lower cost or large casts. Both merge new observations into existing entries rather than appending endlessly — the format plateaus in length on its own, so no programmatic compression trigger is needed.
Variant A — Full (KinksProfiles)[edit]
id: KinksProfiles | name: KinksProfiles dataType: text | visibility: ai_only | autoUpdate: true | initialValueBasedOnPC: same initialValue: [Anchor1]: unrevealed [Anchor2]: unrevealed [Anchor3]: unrevealed
description: Living tag-grouped PROFILE for every named subject's sexual and physical-intimate preferences. Per-subject header followed by the standard PROFILE tags. Anchors start as '<Name>: unrevealed' until a first intimate scene with the PC reveals her preferences in play.
updateInstructions: ONE section per named subject, header = name, sections separated by a blank line. Add a section the first time the PC has a meaningful intimate moment with a new named subject. Per-section format (drop empty subsections; aim ~80 words per subject at full size):
<Name>: ORIENTATION: [bisexual / straight / lesbian / fluid / ?] ROLE: [tops / bottoms / switches / dom-leaning / sub-leaning / context-dependent — with qualifiers] EXPOSURE: [exhibitionist / private / context-dependent] LANGUAGE IN SEX: [dirty talk y/n, praise y/n, degradation y/n, silence preferred, pet names y/n] PHYSICAL TOUCH: [comma-list] DYNAMICS: [voyeurism, restraint, tease-denial, impact, breath play, role-play — comma-list] EMOTIONAL AFTERMATH: [casual / needs aftercare / pillow talk / quick exit / sleeps over] HARD LIMITS: [explicit refusals] SOFT LIMITS: [tentatively explored, would not lead with]
MERGE RULES: new preference → FIND the relevant section/subsection, MERGE into the existing comma-list; don't add new lines. Single observation = TENTATIVE (mark '(tentative)'); second occurrence promotes to STANDING; drop tentatives contradicted by later behaviour. WHAT COUNTS: physical-contact preferences, sexual dynamics, language during sex, specific kinks, hard/soft limits. WHAT DOES NOT COUNT: general personality traits — those go to RecentHistory. Do not invent preferences not surfaced in scene.
Variant B — Lean (NPCKinks)[edit]
id: NPCKinks | name: NPCKinks dataType: text | visibility: ai_only | autoUpdate: true | initialValueBasedOnPC: same initialValue: Name: [Anchor1] Kinks: [comma-list of broad descriptors, or (none yet observed)] Limits: [comma-list, or (none yet observed)]
Name: [Anchor2] Kinks: [...] Limits: [...]
description: Per-NPC kink and limit lines. One 'Name:' block per NPC. Two lines per block: Kinks: <comma-list>, Limits: <comma-list>.
updateInstructions: When an NPC reveals a kink or limit in scene, append it to the relevant line under her name as a comma-separated descriptor. Merge into the existing list; do not add extra lines. General personality observations go to RecentHistory, not here.
Both variants merge into existing entries rather than logging every reveal as a new line — see the MERGE RULES inside the tracker's updateInstructions above.
Step 8 — RecentHistory tracker (or offload to summaryRequest) [CORE][edit]
The compressed "who did what" memory that CharacterKnowledge and the evaluation's "current mood" read from.
Standard — dedicated tracker:
id: RecentHist | name: RecentHistory dataType: text | visibility: ai_only | autoUpdate: true | initialValueBasedOnPC: same initialValue: (empty) description: Append-only log of memorable household beats — kinks revealed, boundaries, sex acts, jealousies, promises, walked-in-on moments. updateInstructions: Append one terse line (~12 words) per memorable beat. No multi-sentence entries. At a scene-break (location change, time skip, conversation closure), collapse the finished scene's lines into a single 2-line beat-summary and drop the individual lines; keep active items, drop superseded ones. The log should plateau in length, not grow.
Lighter — no tracker, offload to summaryRequest: drop the tracker entirely and let the session summary carry the same memory. Put this in the top-level summaryRequest (editor path: Specialist instructions → Summarisation instructions):
Maintain a compact running log per turn. Capture, in this order: (1) relationship state with each named character — refer to Rels values, never restate the numbers; (2) kinks established and boundaries set or refused; (3) ongoing tensions, alliances, grudges; (4) unfinished beats — a promise made, an unresolved encounter, someone who said they'd be back. One terse line per beat. At scene-breaks, collapse the finished scene into a 2-line summary and drop the detail. Treat tracker values as authoritative. Aim under 300 words by turn 50, under 500 by turn 100.
This trades a little precision (the summary is less structured than a dedicated tracker) for one fewer tracker and lower per-turn cost, and of course, sacrifices the ability to see what each tracker is doing.
Step 9 — Kink-cluster register — switchable EIB + dropdown + triggers [CORE][edit]
The kink cluster sets the register the whole cast expresses sexuality in — the tonal dial that makes the same relationship engine feel different world to world. PersonalityLock rule 2 states it shapes register, not the characters' natures. Exactly one cluster is active at a time (feeding several at once gives contradictory direction).
Make it player-switchable at character creation, using the same tracker + start-of-game-trigger pattern used for swappable image blocks: a dropdown tracker selects a register, and one SOG (start-of-game) trigger per non-default option overwrites the active cluster EIB's content.
a) The Kink Cluster dropdown tracker:
id: KinkRegister | name: Kink Cluster dataType: text | visibility: everyone | autoUpdate: false | initialValueBasedOnPC: character initialValue: [your default cluster name, e.g. Decadent] description: Sexual register / kink cluster for the playthrough. Set at character creation; persists. updateInstructions: Set at character creation. Do not change during play.
Add it to each possibleCharacter's initialTrackedItemValues with initialPCValue listing the clusters you offer (e.g. ["Decadent","Sweet","PowerExchange"]). Offer as many or few as you like.
b) The active cluster EIB — ship it with your default cluster's content:
ID: KCActive | Name: KinkCluster [paste the content of your DEFAULT cluster from the library below]
c) One SOG trigger per alternative cluster (model on this; replicate per option, changing requiredValue and content):
id: KR_Sweet | name: Kink Cluster — Sweet swap
triggerOnStartOfGame: true | canTriggerMoreThanOnce: false
condition: type: triggerOnTrackedItem | trackedItemID: KinkRegister
data: { inequality: is_exactly, textComparison: contains, requiredValue: "Sweet",
trackedItemID: KinkRegister }
effect: type: effectModifyInstructionBlock
data: { id: KCActive, content: "[paste the Sweet cluster content below]" }
(If you don't want a player-facing choice, skip the tracker and triggers and just ship the one KCActive EIB with your chosen cluster.)
Cluster library — paste any as KCActive content or a swap payload[edit]
ACTIVE KINK CLUSTER — SWEET. This world's sexuality runs through pleasure-as-real-feeling. The audience expects an adult houseshare to default to transgression; subverting that produces the actually-good story. - INTIMACY-FIRST: emotional disclosure precedes physical. Slow burns are the default tempo. - JEALOUSY arcs become major drivers — characters notice and care who else the PC pursues. - KINKS PRESENT BUT QUIET — appetites exist but characters lead with affection, vulnerability, falling-for-you energy. Power play happens as flirtation, not program. - Commitment matters and is felt. Sex implies stakes. Multiple-partner arrangements require explicit negotiation if they happen at all. Sexual content remains explicit when it occurs; emphasis shifts to feeling, look, anticipation, devotion.
ACTIVE KINK CLUSTER — DECADENT. This world's sexuality runs through pleasure-as-programming. - VOYEURISM and EXHIBITIONISM as default modes, not deviances. Walls are semi-private; doors often open. - PARTIES and shared events that blur into encounters — multi-character scenes happen because the architecture and calendar produce them, not because the plot forces them. - GROUP DYNAMICS — characters are aware of each other's lovers, sometimes share, sometimes compete. Jealousy exists but is rarely possessive. - NO-STRINGS as the baseline. Sex does not imply commitment; commitment, when it happens, is a deliberate choice the characters notice. - Casual nudity, casual touching, casual desire. The body is not a secret here. Sexual content should be explicit, unhurried, sensually detailed. Atmosphere over shock.
ACTIVE KINK CLUSTER — POWER EXCHANGE. This world centres dom/sub dynamics. - EXPLICIT PROTOCOL — honorifics, posture rules, permission, ritual. Each pairing develops its own contract. - SERVICE as a love language — domestic, sexual, ceremonial. Power exchange visible in everyday acts. - OWNERSHIP framings (collars, keys, marks) when a relationship deepens. Negotiated, not imposed. - TRAINING arcs both directions — a submissive learning to serve; a dominant learning to read theirs. - Switching exists but is named when it happens. Roles are chosen, not fluid by default. Sexual content emphasises ritual, restraint, earned permission, the eroticism of structure.
ACTIVE KINK CLUSTER — TRANSGRESSIVE. This world enables a fuller-spectrum register. - HUMILIATION play, name-calling within established trust, degradation as affection inverted. - FEMINISATION arcs where character chemistry supports them. Neither default nor banned. - CUCKOLDING and exhibition-of-other-lovers as kink, not betrayal — when the framing is established. - BOUNDARY PUSHING — some characters do not always ask permission. Consequences are real, bad outcomes possible. - EDGEPLAY (controlled fear, breath, rough contact) within established negotiations. Sexual content can be intentionally obscene, vulgar, dirty in language and act. Maintain consent within each relationship's in-world framing; this is an erotic adventure, not a horror story.
ACTIVE KINK CLUSTER — DEVOTIONAL. This world makes worship and idolisation the central frame. - PEDESTAL DYNAMICS — characters who inspire devotion and characters who give it. Both directions. - TEASE and DENIAL as a baseline tempo. Anticipation matters more than completion. - IDOLISATION — physical adoration as offering. Touch as homage rather than consumption. - CHASTE SERVICE arcs — extended restraint culminating in significant releases. - Ritualised moments (dressing, undressing, tending them) carry erotic charge. Sexual content emphasises slow build, prolonged anticipation, the eroticism of restraint. Climaxes are earned over many turns.
ACTIVE KINK CLUSTER — PREDATOR & PREY. This world centres chase and capture dynamics. - HUNT framings — being noticed, tracked, chosen. Safe-fear scenarios within the relationship. - CAPTURE fantasy — controlled physical struggle, restraint, the ritual of giving way. - POSSESSION as central — characters who claim and characters who want to be claimed. Marking, ownership without protocol. - CORNERED SCENES — confined spaces, no easy exit, the eroticism of having nowhere else to be. - Both sides can flip — the prey can become the hunter. Switches are common. Sexual content emphasises tension, breath, struggle-and-yield. Aftermath is tender.
Step 10 — WhereWhen time tracker [CORE][edit]
As is common to a lot of worlds, stops the AI drifting on in-fiction time (the failure where "first evening" is somehow "day three" at turn 50). A single one-line text tracker replaces the old six-tracker cluster (day-of-week, day-count, month, year, time-of-day, location); the update logic lives in its updateInstructions.
id: WhereWhen | name: Where/When
dataType: text | visibility: everyone | autoUpdate: true | initialValueBasedOnPC: same
initialValue: Day 1 ([opening weekday]), [opening time of day] — [opening location]
// e.g. Day 1 (Saturday), late evening — the house, front entrance
description: Single narrative time-and-place anchor: in-fiction day number (from 1 at arrival), day of week, time of day, and the PC's current location. Keeps the AI's sense of when and where the story is consistent.
updateInstructions:
Maintain the one line in the form 'Day N (Weekday), time-of-day — location'.
- Day N: integer from 1 at arrival. Increment on every day rollover (sleep, midnight, new-morning
skip; multi-day skips add the count). Never decrement.
- Weekday: advance Mon→Tue→…→Sun→Mon in step with Day N.
- Time of day: update on scene transitions and within-day skips; phrase to match the world's tone
('9pm' modern, 'half-past nine' period). On day rollover reset to the PC's wake time.
- Location: update whenever the PC moves; use a specific named place, not 'outdoors'.
Add the month/year to the line only if your world needs them.
Optional modules[edit]
ContentScope — the content contract [OPTIONAL][edit]
Lets the player set, at creation, whether men other than the PC ever appear in sexual scenes — a hard boundary for the whole run. A four-point install: tracker + EIB + eval ground 4 (Step 6) + PersonalityLock rule 5 clause.
Tracker:
id: ContScope | name: ContentScope dataType: text | visibility: everyone | autoUpdate: false | initialValueBasedOnPC: character initialValue: Solo only — no other men in scenes ever description: Whether men other than the PC appear in sexual scenes. Set at creation via dropdown; BINDING for the playthrough. Values: 'Solo only — no other men in scenes ever' / 'Girl-girl — solo and girl-girl allowed; no other men' / 'Open scope — collabs, partners, parties; other men appear in scenes'. updateInstructions: Set at creation and binds the world. Do not change during play. Read before staging any sexual scene, party, or shoot. See the ContentScope EIB.
Add it to each possibleCharacter's initialTrackedItemValues as an initialPCValue dropdown of the three strings.
EIB:
ID: ContScopeEIB | Name: ContentScope
CONTENT SCOPE — STRICT, READ THE TRACKER. Set at character creation; BINDS the world for the entire playthrough. Read it before staging any sexual scene, party, or event.
"Solo only" — no other men ever in any sexual scene; the PC is the only male presence permitted, and only if the PC is male. [Per-world specifics: which offscreen male characters stay offscreen; parties stay women + PC.] "Girl-girl" — solo plus lesbian/girl-girl content. Still no other men in any sexual scene. [Per-world specifics.] "Open scope" — collabs, partners, fans, parties; other men appear in sexual scenes and events. [Per-world specifics.]
Default to "Solo only" if the tracker is missing or unparseable. HARD RULE — do not soft-introduce a male character into a Solo-only or Girl-girl playthrough via "surprise visit", "party guest", or any other framing. Scope is the world contract.
SexualHistory — inter-NPC pairing graph [OPTIONAL][edit]
Tracks who among the cast has slept with whom, independent of the PC — so the house has a sexual social life the player steps into.
id: SexualHistory | name: SexualHistory dataType: text | visibility: ai_only | autoUpdate: true | initialValueBasedOnPC: same initialValue: [Anchor A] — [Anchor B] (on-off) [Anchor C] — [Anchor D] (flings) description: Established sexual pairings between named cast members. updateInstructions: When a new sexual pairing between two named cast members is confirmed in scene, append a line: 'Name A — Name B'. Add (on-off) / (one-time) / (flings) in parentheses if context warrants.
Obscure Idiolect narrative-control EIBs — [OPTIONAL, compatible][edit]
A separately maintained, regularly updated set of prose/dialogue-quality blocks — CharacterKnowledge (keeps each NPC to what she could actually know — highest priority in a multi-room house), DialogueIntegrity (bans several trained-in dialogue defaults that flatten conversation), NamingRules (stops default-name pollution), and ProseStyle (+ optional authorStyle anchor). They are fully compatible with this system but independent of it — install as many as you want. Obscure Idiolect Narrative Improvement Templates.