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:

Propose a project structure and confirm the data schema with me before writing implementation code.
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.
Build incrementally, and let's check in after the core turn loop works before layering on the feedback system, save/export, and random events.
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.

7.3 KiB Raw Permalink Blame History Unescape Escape