# 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?