Upload files to "Planning"

Planning/01-corporate-ladder-brainstorm.md

@@ -0,0 +1,231 @@
+# 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?