172 lines
7.3 KiB
Markdown
172 lines
7.3 KiB
Markdown
# 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.
|