Upload files to "Planning"

2026-09-10 00:27:28 +00:00
commit 6c7d31371e
3 changed files with 553 additions and 0 deletions
@@ -0,0 +1,171 @@
+# Claude Code Build Prompt — Corporate Ladder Game MVP
+
+Copy everything below the line into Claude Code as your starting prompt.
+
+---
+
+I want to build a browser-based career simulation game called (working title)
+"Corporate Ladder." This is a **minimum viable prototype** — please treat this
+as the first phase of a larger project, and follow a research/plan-first
+approach before writing code: propose a file/folder structure and data schema
+first, surface any open questions, and get my explicit go-ahead before you
+start implementing.
+
+## Core Concept
+
+A turn-based career sim. The player starts in the mailroom of a modern
+corporate office. Each turn (treat a turn as one day), the player is shown a
+short scripted scenario and picks from 2–3 choices. Choices affect the
+player's money, a skill stat, and relationship stats with two NPCs (a boss and
+a coworker rival). The game has no fixed length — the player can keep taking
+turns indefinitely — and at any point can trigger a "wrap up my career"
+retrospective screen summarizing what happened.
+
+This is explicitly a **prototype/foundation**, not the full game. The most
+important requirement is that everything be **data-driven**: characters,
+events, and choices should live in data structures (JSON or equivalent) that
+a generic engine reads and processes. Do not hardcode character-specific or
+event-specific logic in the engine — the engine should not need to change to
+add a new character or event, and eventually should not need to change to
+support an entirely different theme/setting (e.g. Wild West instead of
+corporate office). Please design the schema with that future flexibility in
+mind, even though this build only needs to ship the corporate/mailroom
+content.
+
+## Tech Stack
+
+- Fully client-side: plain HTML, CSS, and JavaScript. No required backend —
+  it should be able to run by opening a static HTML file (or via a trivial
+  static file server for local dev).
+- Keep dependencies minimal. Avoid heavy frameworks unless you think there's
+  a strong reason — I'd rather this stay simple and easy to reason about.
+- No database, no accounts. State lives client-side.
+
+## Required Features for This Build
+
+### 1. Core Turn Loop
+- Player starts a new game in the mailroom with starting values for money,
+  one skill (e.g. "negotiation"), and neutral relationship stats with the two
+  NPCs.
+- Each turn presents a short text scenario and 2–3 choices.
+- Choices apply effects to money / skill / relationship stats.
+- Some choices may require a minimum skill level to be available (a simple
+  gating mechanism).
+- No fixed number of turns — the player can keep playing.
+
+### 2. Two NPCs
+- A boss and a coworker rival.
+- Each has: name, a short flavor description (personality/appearance text,
+  purely for color), a role-type tag (`boss` / `rival`), and three numeric
+  relationship stats toward the player: `likes_you`, `fears_you`,
+  `wants_to_help_you`.
+- Design the character schema so additional role types (e.g. `mentor`,
+  `peer`) could be added later without changing engine code.
+
+### 3. Random Events
+- Implement a small handful (4–6) of simple random events using the *same*
+  data structure as regular scripted turns — i.e. an event is just another
+  entry in the event/turn data with a tag marking it as a random event and
+  some trigger condition (e.g. a probability or a stat threshold). Do not
+  special-case these in the engine logic.
+
+### 4. Soft Failure State
+- If money drops below zero (or some defined threshold), don't end the game.
+  Instead, surface a distinct "hard times" branch of choices — e.g. take out
+  a loan (debt that must be paid down over time) or do a demeaning favor for
+  the rival (which affects relationship stats and possibly unlocks money).
+  The player should be able to work their way back out.
+
+### 5. Retrospective / Ending Screen
+- A "wrap up my career" action the player can take at any time.
+- Shows: final money, final relationship stats with each NPC, and a short
+  list of notable moments/events from their playthrough (pull from a simple
+  history log kept during play).
+- This screen's structure should be the same regardless of how the
+  playthrough went — it's a summary, not a win/lose screen.
+
+### 6. Save System
+- Auto-save to browser local storage as the player progresses.
+- An explicit "Export Save" button that downloads the current game state as a
+  JSON file, and an "Import Save" option to load one back in.
+
+### 7. Feedback & Logging System
+- On every turn screen, include a small, always-visible (for now) feedback
+  widget: thumbs up / thumbs down / neutral buttons, plus an optional
+  free-text comment box. The player is never required to interact with it.
+- Also include an optional field where the player can note "something I
+  wanted to do that wasn't an option here."
+- Log every turn's chosen action and its effects, along with any feedback
+  given, to a **separate log** that is exportable independently from the game
+  save (a separate "Export Feedback Log" button/JSON file). This should not
+  be mixed into the save-game file.
+
+## Data Schema (Starting Point — feel free to refine, but keep me in the
+loop on changes)
+
+```
+Character:
+  id: string
+  name: string
+  role_type: string        // e.g. "boss", "rival"
+  description: string      // flavor text
+  likes_you: number
+  fears_you: number
+  wants_to_help_you: number
+
+TurnEvent:
+  id: string
+  stage_tag: string         // e.g. "mailroom" (for future level filtering)
+  is_random_event: boolean
+  description: string
+  options: [
+    {
+      label: string
+      effects: { money?: number, skills?: { [name]: number },
+                 relationships?: { [character_id]: { likes_you?: number,
+                 fears_you?: number, wants_to_help_you?: number } } }
+      requires?: { skill: string, min: number }
+    }
+  ]
+
+PlayerState:
+  money: number
+  skills: { [name]: number }
+  relationships: { [character_id]: { likes_you, fears_you,
+    wants_to_help_you } }
+  history: [ { turn_id, event_id, choice_label, timestamp } ]
+
+FeedbackLogEntry:
+  turn_id: string
+  action_taken: string
+  rating: "up" | "down" | "neutral" | null
+  comment?: string
+  desired_but_unavailable_action?: string
+```
+
+## What NOT to Build Yet
+
+- No promotion mechanic or second tier/level — mailroom only for this build.
+- No AI/LLM integration of any kind yet — this build is fully scripted.
+- No AI-generated images or video.
+- No multiple themes/settings — corporate/mailroom only, but keep the schema
+  theme-agnostic in spirit (i.e. don't bake "mailroom" assumptions into the
+  engine logic itself, keep it in the data).
+- No multiplayer — this is a permanent design decision, not just an MVP gap.
+- No account system or server-side persistence.
+
+## Process
+
+Please:
+1. Propose a project structure and confirm the data schema with me before
+   writing implementation code.
+2. Flag any open questions (e.g. exact starting stat values, exact effect
+   magnitudes) rather than guessing silently — reasonable defaults are fine
+   but call them out.
+3. Build incrementally, and let's check in after the core turn loop works
+   before layering on the feedback system, save/export, and random events.
+4. Keep commits small and incremental rather than one giant commit at the
+   end.
+
+Let me know once you've reviewed this and have a proposed structure, or if
+you have clarifying questions before we start.