7.3 KiB
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.