TheLadder/Planning/01-corporate-ladder-brainstorm.md

# Corporate Ladder Game — Big Picture Brainstorm

This document captures the full vision for the game: everything on the table, from
the near-term prototype through the long-term dream version. Not everything here
gets built at once — this is the idea space the architecture needs to be able to
grow into.

## Core Concept

A browser-based career simulation game. The player starts at the bottom of an
organization (e.g. the mailroom in a modern corporate setting) and plays through
turns (a day or a week each), making choices that shape their career, finances,
relationships, and reputation.

It is **not** a pure narrative experience — there is real scoring, real numeric
state, and real progress to track. It is also not a spreadsheet optimization
game — the numbers exist to give the story stakes and a scoreboard, not to reward
min-maxing. The target feel is **light and fun**, with enough rigor underneath
that choices matter.

## Gameplay Pillars

### 1. Choose-Your-Own-Adventure + Simulation Hybrid

- Early version: scripted choices. Each turn presents a small, fixed set of
  options (e.g. 2–3 actions).
- Later version: free-text player input. The player types what they want to do
  in their own words, and an AI layer interprets that into a game action (e.g.
  "I stay late and grind it out" → *hard work* action; "I look for a way to
  duck out early" → *shortcut* action). The AI can also generate more colorful,
  varied dialogue and flavor text around the outcome.
- Underneath both modes, the same numeric engine runs: money, stats,
  relationships, skills.

### 2. Multidimensional Success

- Title/promotion is one axis of success, not the only one.
- Other axes: skills learned, relationships built, reputation, personal
  satisfaction.
- Strategic depth: a player might deliberately stay at a lower level longer to
  build skills or relationships before pushing for a promotion, rather than
  always rushing upward. Rushing every promotion should be able to create real
  downstream problems (skill gaps, thin relationships) — but this should
  emerge from the choices available, not from punishing math.

### 3. Skills as Gates, Not Just Flavor

- Skills (e.g. negotiation, technical ability) are tracked stats.
- Low skill in an area can lock out certain choices entirely, or make them
  much riskier.
- Skills grow **organically**, as a side effect of taking related actions and
  events — not through a dedicated "go train" menu. The goal is to avoid a
  grindy, click-here-click-there feel. Growth should feel like something that
  happens to you as a consequence of living the story, not a chore you manage.

### 4. Characters with Real Weight

- Every character has flavor description text (appearance, personality quirks
  — tall, charismatic, particularly attractive, gruff, etc.) purely for color.
- Underneath, characters carry real relationship stats toward the player:
  - How much they **like** you
  - How much they **fear** you
  - How much they're willing to **help** you
- A darker mechanic: leverage/pressure material — not necessarily
  "blackmail" in the extreme sense, but things a character wouldn't want to
  come out, which the player can use as a lever to influence behavior. This
  gives the player a second currency beyond money: information and
  reputation as power.
- Influence is central to gameplay — persuading a boss to let you leave
  early, or a coworker to cover your shift, might work because you've been
  kind to them (they like you) or because you've been intimidating (they fear
  you). Different relationship paths should lead to similar outcomes through
  different means.
- Characters should have extensive, distinct backstories, so that even when
  the underlying stat skeleton is the same across playthroughs, individual
  characters feel different and memorable each time.

### 5. Random Events, Built to Scale

- The initial version should have a small, tightly scoped set of random
  events.
- Critically, the underlying data structures for events (and everything else)
  should be built so that adding new events later is just adding new data —
  never a rewrite of game logic. Events and choices should be treated as data
  the engine reads generically, not hardcoded logic scattered through the
  codebase.

### 6. Soft Failure, Not Game Over

- No hard "you lose" state.
- Failure is a spiral of **suffering and reduced options**, not a dead end:
  - Bankruptcy might force taking out a loan.
  - A demoted or struggling player might have to do menial work for, or take
    orders from, someone they used to outrank.
  - The player can always keep pushing to climb back out, at a cost.
- A player can choose to walk away because it's "too painful," but the game
  itself doesn't force an ending on them.
- This keeps players engaged in the story even at rock bottom, and it opens up
  strong narrative beats — being humbled by a character you were dismissive of
  earlier should hit differently than being humbled by a stranger.

### 7. Open-Ended Pacing with a Natural Ceiling

- No fixed turn count or forced ending.
- The game naturally self-limits: once a player becomes, say, company
  president with influence over everyone, there's nowhere higher to climb —
  the sandbox is exhausted, not because a clock ran out.
- The "ending," whenever a player stops, is the same regardless of how far
  they got: a **career retrospective** — what you did, what you didn't do,
  key relationships, notable moments (and eventually notable
  images/videos), presented uniformly whether the player "won" or "lost."

### 8. Single Player Only

- No multiplayer, no competitive syncing across players. This simplifies a
  large amount of design and technical complexity and keeps the focus on the
  player's individual story.

### 9. Infinite Themes via Data-Driven Design

This is one of the most important architectural commitments:

- The game engine, mechanics, and code should **never need to change** to
  support a new setting or theme.
- Theme is purely a data layer: character archetypes, job titles, event
  flavor text, tone, and even the *boundaries of allowed content* are all
  swappable data/content packs.
- Example themes: modern corporate (primary/default), auto manufacturing,
  high-tech startup, Wild West, medieval guild, sci-fi/Star Trek-style,
  textile mill, or even a kid-friendly "lemonade stand" version for younger
  players.
- Content packs also control maturity level: a kid-friendly theme keeps
  everything light, while a more adult theme could unlock sharper-edged
  mechanics (like real blackmail-style pressure points) — the mechanics
  underneath stay identical; only the data changes what's permissible and how
  it's flavored.
- Replayability also comes from randomized competitive density — e.g. one
  playthrough might have five rivals competing for the same mailroom
  promotion, another might have just one. Same mechanics, very different felt
  experience.

### 10. AI Integration (Long-Term)

- **Dialogue and interpretation**: free-text player input gets interpreted by
  an AI into structured game actions, and the AI generates more natural,
  varied dialogue for NPCs and outcomes.
- **Stateless inference architecture**: this is an important technical
  decision. The inference engine itself (e.g. a local Llama-class model) is
  stateless — it's a pure function that takes an assembled prompt and returns
  a response. It does not maintain any memory or state of its own.
  - All state — player situation, history, current stats, active theme/genre,
    scene context — lives at the **application/game engine layer**.
  - The game engine is responsible for assembling the right context and
    building the prompt fresh on every call.
  - This keeps the game portable across different inference backends and
    keeps behavior predictable and debuggable.
- **Configurable inference endpoint**: rather than the game hosting or
  depending on a specific AI service, the configuration should include a
  pointer to an inference engine (e.g. a local Llama-equivalent server) that
  the user points at themselves. The core game should never require Jesse to
  run or pay for a hosted inference service.
- **Generated media (further out)**: AI-generated images or short video
  vignettes for big narrative payoff moments — e.g. an award ceremony
  producing a generated image of the player receiving a medal, or a short
  video vignette for a major win. This is explicitly a "big picture" /
  aspirational feature, well downstream of the prototype.

### 11. Logging & Feedback, Built In From Day One

This should exist even before any AI is involved, starting with the very first
scripted-only prototype:

- **Full instrumentation**: every player action and its resulting effect
  should be captured/logged from turn one. This serves two purposes:
  1. Playtesting research — understanding what players actually do and want.
  2. Future AI tuning — once AI-driven dialogue/interpretation exists, having
     a baseline of real scripted interactions to compare against.
- **In-game feedback widget**: a persistent "feedback to game designer"
  element on the turn screen (can be optionally hidden later once trust in
  the game is established, but visible by default early on):
  - Thumbs up / thumbs down / neutral rating per turn.
  - Optional free-text comment field.
  - If the player doesn't interact with it, nothing happens — it's fully
    passive/optional.
  - This is also the natural place to capture "I wanted to do something that
    wasn't an available option" feedback, which is gold for identifying where
    the scripted choice set is too narrow.
- **Separate export stream**: feedback/logging data is captured as its own
  independent export, distinct from the game save file. It's meant for
  Jesse's review and analysis, not for reloading into a playthrough.

## Technical Direction (Big Picture)

- **Browser-based, client-heavy**: strong preference for a simple tech stack
  that runs entirely client-side (HTML/CSS/JavaScript), with no heavy backend
  services required. Ideally the only server-side requirement (if any) is
  serving the static page.
- **Saves**: browser local storage as the default/primary save mechanism, with
  an explicit export/import (save-to-file) option so an accidental cache
  clear or browser crash doesn't destroy a career in progress.
- **Data schema**: characters and events should carry tags/flags (e.g.
  department, role type like rival/mentor/peer for characters; stage/level
  and which stats are affected for events) so the engine can query and filter
  generically, instead of hardcoding per-entity logic.
- **Extensibility as a first-class constraint**: every system (events,
  characters, themes) should be structured as data the engine reads, so that
  adding new content later doesn't require reworking the engine.

## Relationship to Jesse's Other Project

Jesse is separately building an **interactive story** project that is purely
narrative-focused, with no game mechanics or scoring layer. This corporate
ladder game is explicitly the opposite emphasis: it must have real scoring and
measurable progress, not just storytelling. There may be shared code or
techniques between the two (especially around AI-driven dialogue/story
generation), but they are distinct projects with distinct goals.

## Open Questions / Things to Revisit Later

- What's the full list of core character fields beyond name, role/title,
  relationship stats (like/fear/help), and flavor description? (Tags for
  department and role-type like rival/mentor/peer were agreed as a good
  addition.)
- What's the full list of core event fields beyond description and effects?
  (Tags for stage/level and affected stats were agreed as a good addition.)
- How exactly does a player move between tiers/levels once promotion is
  introduced (post-MVP)?
- What does the "career retrospective" screen actually look like/contain in
  detail?
- How should the feedback widget's visibility toggle work, and when should it
  default to hidden vs. shown?