# Side-Scroller Terminal Trainer Roadmap Purpose: track the move from a static terminal trainer into a proper side-scrolling workplace game where terminal labs are launched from rooms, workstations, story events, and game progression gates. Use the checkboxes as the build contract. A step is only complete when its completion criteria are met and tested on mobile. Current focus lock: complete **Phase 1A: First Office Art Direction Pass** before starting new rooms, new labs, new mechanics, arcade work, or unrelated projects. ## Core Concept The player is a new employee on their first day. A manager gives a short briefing, asks them to log into the company training terminal, and sends them through workplace tasks that map to the Windows beginner labs. The side-scroller is the main experience. The terminal labs remain the skill checks. Long-term direction: make this feel like a real game first, with terminal learning embedded inside it. The player moves through side-scrolling office, help desk, server room, and network spaces; fights increasingly difficult digital/office threats; and stops at workstations or story gates to complete terminal lab challenges. Each terminal lab should get harder, and the enemies or obstacles between labs should also get harder. This is the differentiator: not another static training app, but an interactive game where terminal skills unlock progress. Design target: players should feel like they are playing a platform adventure and only gradually realize they are learning terminal skills. The world should teach through goals, doors, hazards, repairs, pickups, NPC requests, and room unlocks. Commands should feel like tools the player uses to change the world, not like isolated quiz answers. Core progression loop: - [ ] Game stage. - [ ] Locked lab lesson. - [ ] Completion key, badge, part, or evidence reward. - [ ] Reward unlocks a door, route, workstation, lift, or room gate. - [ ] Next game stage. - [ ] Repeat the loop with slightly harder traversal, enemies, and terminal tasks. - [ ] Keep this loop working before adding more story, video, rooms, or advanced effects. Intro and briefing direction: - [ ] Use a full Patch/manager intro only at the start of the game or at major lab-type changes. - [ ] Do not play a full intro video before every stage. - [ ] Add short transition briefings when the curriculum changes category, such as directories/files to IP configuration, local troubleshooting to network troubleshooting, or basic commands to security challenges. - [ ] Use manager radio calls, terminal messages, or tiny cut-ins for normal stage-to-stage guidance. - [ ] Treat videos as chapter transitions, not routine lesson wrappers. - [x] Prototype the first Patch/manager pre-level briefing as an in-engine skippable story scene before Level 1. - [ ] Decide whether chapter-change briefings should be short video clips, comic-panel overlays, or in-engine radio calls. - [ ] Keep normal stage-to-stage story beats short enough that the player gets back to running, shooting, and lab gates quickly. Platformer style target: - Build levels from long readable landmasses, catwalks, bridges, ducts, server-room floors, and office maintenance platforms rather than short stair-step blocks. - Use horizontal traversal first, then vertical changes as moments: run across a platform, climb or jump to a new route, cross back, unlock a door, reach a terminal. - Keep the visual surface and gameplay landing zones aligned. If it looks standable, it should be standable; if it is decoration, it should not look like the main route. - Make every lab station a destination in the level: lighting, signage, NPC reaction, terminal beacon, or a locked door should tell the player why they are going there. - Use room-specific materials instead of generic platforms: - Office: desks, cable trays, maintenance catwalks, filing shelves. - Help desk: counters, ticket boards, rolling carts. - Server room: rack bridges, raised floor panels, cable ladders. - Network closet: ducts, patch panels, hanging cable bridges. - Break room: tables, vending machines, arcade props. - Hide learning inside play loops: collect evidence, restore power, open a door, clear a virus, find a note, copy a file, verify a system, then watch the world react. - Increase difficulty in both layers together. Later command tasks should be paired with harder traversal, tougher enemies, tighter timing, or more complex room layouts. First Day Office layout direction: - Replace the current small upward platform stack with a more complete side-scroller route. - Include at least one long lower platform, one mid-level platform that crosses back across the screen, one upper platform, and a clear terminal destination platform. - Use ladders, cable bridges, or service lifts later as connectors between long horizontal routes. - Keep the first route forgiving, readable, and mobile-friendly; it should teach movement, jumping, shooting, and reaching a terminal without feeling like a tutorial screen. ## Game Designer Build Order Use this as the broad production order for turning the trainer into a run-and-gun side-scroller. The main idea is to create the reusable game kit before building large layouts. 1. Define the core loop. 2. Create the world kit. 3. Create the character kit. 4. Create gameplay objects. 5. Build one tiny test level. 6. Tune movement, combat, camera, and terminal interaction. 7. Expand into more levels only after the test level feels good. ### Section 1: Core Loop Brainstorm Working loop: ```text Run through the office -> dodge or fight workplace/digital threats -> reach a terminal station -> complete a short terminal lab -> unlock a route, door, tool, or story beat -> continue running -> reach the level exit ``` Core player promise: - The player is playing a real side-scrolling action game. - Terminal labs are world interactions, not separate school exercises. - Every command task should cause something visible to happen in the level. - The first office should teach the rhythm quickly: move, react, reach terminal, solve, advance. First level version: - Start in the office lobby or first-day hallway. - Manager gives a brief objective. - Player runs through a simple office route. - Player gets a basic pulse tool or action ability. - One small threat appears before the first terminal. - First terminal lab unlocks a blocked door, elevator, or workstation gate. - Player exits into the next office area. Design questions for Section 1: - What is the player's default action tool: pulse blaster, scanner, keyboard zap, or repair beam? - Are early enemies physical office hazards, digital virus blobs, or both? - Does the terminal lab pause the action completely, or does it happen inside a safe terminal zone? - What does completion reward first: door unlock, movement route, story progress, or new tool? - How long should one run segment be before a terminal stop? Locked direction: - The first terminal should appear after a real run-and-gun sequence, not immediately. - Target time to first terminal: about 60-90 seconds for an average player. - Target first level length: about 3 minutes before repeat/failure time. - The level should include multiple enemy waves, not one or two isolated enemies. - Enemies should be revealed gradually across levels so the first level does not show every threat type. - Early enemies should be basic and readable; later enemies should become physically scarier, faster, tougher, and more mixed. - Randomization should use designed wave pools, not fully random spawns. - Obstacles should be mixed into the route: gaps, cable spikes, ethernet black holes, firewall beams, exposed electricity, Trojan crates, and corrupt floor tiles. - Power-ups should appear along the way and can include temporary weapons, shields, health, extra lives, score/XP, and terminal hint tokens. - Temporary weapon upgrades should last until the player gets hit. - The player should have lives and checkpoints/save points. - Checkpoints should appear before terminal labs, after terminal labs, and before major boss or mini-boss moments. - The terminal station should feel like an earned safe zone after a combat/traversal sequence. - The default player character should lean toward Patch the mascot. - Later versions can allow player customization or alternate playable characters. First level encounter shape: ```text Start -> movement warmup -> enemy wave 1 -> small obstacle -> enemy wave 2 -> platform/gap section -> enemy wave 3 -> hazard set-piece -> terminal safe zone -> Lab 1 -> unlocked route -> level exit ``` Early enemy reveal curve: - Level 1: virus crawlers, simple glitch drones, basic gaps, cable spikes. - Level 2: faster crawlers, first Trojan trap, larger enemy waves. - Level 3: firewall turrets, timed beams, enemy/hazard combinations. - Level 4+: scarier variants, mixed waves, mini-bosses, tighter platforming. Open progression decision: - Decide how many terminal labs must be completed before each new level unlocks. Environment progression rule: - Keep the same broad environment for a cluster of related terminal labs. - Change the environment when the subject, topic, operating system, or responsibility changes. - Early Windows beginner labs should stay in the First Day Office / workplace onboarding environment. - Network labs should move into network closet, server room, or infrastructure spaces. - Linux or later operating-system-specific labs can introduce a different visual world so the player feels the subject shift. - Environment changes should feel like promotions or new responsibilities, not random background swaps. Suggested environment clusters: - Windows beginner basics: First Day Office, help desk, records area, IT desk. - Windows networking: network closet, server room, cable routes, infrastructure floor. - Linux basics: operations lab, shell training room, darker server/admin environment. - Security topics: incident response floor, quarantine zone, corrupted office variant. - Advanced/optional content: arcade room, hidden terminals, challenge rooms. ### Section 2: Level Layout Rules Reference direction: - Use classic Mario-style readability for route design: clear ground, obvious gaps, visible platforms, simple jumps first, harder combinations later. - Use classic Ghosts 'n Goblins-style pressure for combat: enemies arrive in waves, the player has limited lives, mistakes matter, and power-ups feel valuable. - Do not copy either game directly. Borrow the broad design principles: readable traversal, escalating hazards, enemy rhythm, checkpoints, and memorable set-pieces. Basic level structure: ```text Start safe zone -> movement warmup -> combat/traversal section 1 -> checkpoint or power-up -> combat/traversal section 2 -> obstacle set-piece -> combat/traversal section 3 -> terminal safe zone -> lab unlock -> final route or exit ``` Layout rules: - A level should be long enough to feel like a real run, not a short hallway. - Target first level length: about 3 minutes for an average successful run. - Target first terminal arrival: about 60-90 seconds into the level. - Each level should include 3-5 combat/traversal sections. - Each section should have a clear purpose: teach movement, introduce an enemy, combine enemy plus hazard, reward the player, or build tension before a terminal. - Keep the first screen readable and forgiving. - Place terminals after the player has earned them through action. - Put a checkpoint before major terminal labs. - Put another checkpoint after completed terminal labs. - Give the player short safe spaces after intense waves. - Do not place hazards where the player cannot see them before reacting. - Do not create long empty walks unless they are used for story, reward, or tension. Mario-inspired traversal rules: - Use long readable ground sections. - Introduce one jump idea at a time. - Show hazards before forcing the player to commit. - Use coins, pickups, signs, lights, or cable trails to guide the route. - Let early gaps be forgiving. - Make platform surfaces visually match collision surfaces. - Use vertical movement as occasional variety, not constant stair-stepping. Ghosts 'n Goblins-inspired pressure rules: - Enemies can arrive in waves. - Enemy timing should pressure the player without feeling random or unfair. - Power-ups should matter because getting hit can remove the current weapon upgrade. - Lives and checkpoints should create tension without making mobile play frustrating. - Later levels can mix enemies and hazards more aggressively. - Mini-bosses should appear at the end of topic clusters, not necessarily every level. First level layout sketch: ```text Office entrance -> lower hallway movement warmup -> virus crawler wave -> cable spike/gap section -> glitch drone plus crawlers -> checkpoint printer/save terminal -> Trojan crate ambush -> ethernet black hole hazard -> terminal safe zone -> Lab 1 -> security door opens -> short exit route ``` Level readability checks: - Can the player tell where to run within one second? - Can the player tell what is solid and what is decoration? - Can the player see the next danger before committing to a jump? - Is there a safe space before and after each terminal? - Does every terminal have a visible reason to exist? - Does the route feel like a game level rather than a menu with enemies? ### Section 3: Asset And Environment Kit Purpose: - Design and approve the reusable game kit before building full levels. - Keep the existing First Day Office style as the starting art direction. - Make assets feel like they belong to one run-and-gun game, not separate AI-generated props. - Do not assemble the full level until the core assets, environment pieces, and mobile controls are approved. - Visual approval board: `first-day-office/asset-kit.html`. Asset approval order: 1. Player character. 2. Enemy family. 3. Hazards and obstacles. 4. Power-ups and rewards. 5. Checkpoints and save objects. 6. Terminal and unlock objects. 7. Office environment kit. 8. Mobile control UI. 9. HUD and feedback effects. #### Player Character Kit Default direction: Patch should be the first playable character or the basis for the player character. Required states: - Idle. - Run. - Jump. - Fall. - Shoot/use pulse tool. - Interact. - Hurt. - Respawn. - Victory/success. Design rules: - Patch must read clearly at mobile size. - The silhouette should be simple and recognizable. - The player should face left and right cleanly. - The action tool should be visible without cluttering the sprite. - Later character customization should not be required for the first playable version. Open character questions: - Is Patch a human mascot, robot mascot, animal-like mascot, or small cyber helper? - Does Patch hold a pulse tool, wear it as a wrist tool, or fire from a built-in device? - Should the player look like a new employee, a mascot hero, or a mix of both? #### Enemy Family Kit Early enemies: - Virus Crawler: basic ground enemy. - Glitch Drone: simple flying enemy. - Packet Swarm: weak group enemy. - Trojan Crate: disguised object that activates or spawns enemies. Later enemies: - Firewall Turret: stationary shooter. - Corrupt File: jumping/lunging enemy. - Bug Brute: slow tougher enemy. - Data Leech: enemy that chases or drains player resources. - Mini-boss variants for topic-cluster endings. Enemy design rules: - Level 1 enemies should look readable and not too scary. - Later enemies should become physically scarier, sharper, larger, faster, or more corrupted. - Each enemy type needs a distinct silhouette. - Enemy color and motion should show behavior before the enemy attacks. - Enemies should belong visually to the office/digital-threat theme. - Randomization uses approved wave pools, not uncontrolled spawns. Enemy asset states: - Idle or patrol. - Move/fly. - Attack. - Hit. - Defeated. - Spawn or wake-up for ambush enemies. #### Hazards And Obstacles Kit First-level hazards: - Floor gaps. - Cable spikes. - Ethernet black holes. - Exposed server electricity. - Corrupt floor tiles. - Trojan crates. Later hazards: - Firewall beams. - Moving laser gates. - Falling ceiling panels. - Conveyor belts. - Data storms. - Rising corruption zones. Hazard design rules: - Hazards must be readable before the player commits to movement. - Hazard visuals must not look like harmless decoration. - Office hazards should still feel workplace-themed. - Digital hazards should feel connected to terminal/security/network problems. - The first level should introduce only a small number of hazard types. #### Power-Up And Reward Kit Power-ups: - Temporary weapon upgrade. - Shield hit. - Health pickup. - Extra life. - Speed boost. - Double shot. - Spread shot. - Terminal hint token. - Score/XP pickup. Power-up rules: - Temporary weapon upgrades last until the player gets hit. - Health and extra lives should be rare enough to matter. - Pickups should guide the route without replacing clear level design. - Power-ups should be visually distinct from enemies and hazards. - Mobile players should be able to recognize pickups quickly. #### Checkpoint And Save Kit Checkpoint ideas: - Save terminal. - Sync station. - Office printer checkpoint. - Security badge scanner. - Break-room backup station. Checkpoint rules: - Place before terminal labs. - Place after terminal labs. - Place before mini-bosses or major set-pieces. - Use a clear activation animation or sound cue. - Make checkpoints feel like part of the office world. #### Terminal And Unlock Kit Terminal objects: - Main lab workstation. - Locked security terminal. - Broken server console. - Elevator control panel. - Door access panel. - Hidden optional terminal. Terminal rules: - Terminal stations are safe zones. - Terminal stations must look important from a distance. - Lab completion should visibly change the world. - Terminals can unlock doors, elevators, bridges, power, story progress, or boss weakness. - Hidden terminals can hold optional challenges or rewards later. Unlock objects: - Security door. - Elevator. - Bridge/platform activation. - Power switch. - Server rack gate. - Quarantine barrier. #### First Day Office Environment Kit Environment role: first cluster for Windows beginner basics and onboarding. Required pieces: - Long office floor pieces. - Raised platform pieces. - Metal catwalk or cable bridge pieces. - Wall panels. - Ceiling lights. - Pipes and cable trays. - Doors. - Elevator or security door. - Desks. - Workstations. - Whiteboards. - Signs. - Boxes and office clutter. - Server/IT props. - Background windows or city hints if useful. Environment rules: - Gameplay platforms must be visually distinct from decoration. - If it looks standable, it should be standable. - Background decoration must not compete with the route. - Terminal destination should be one of the clearest visual objects. - The office should still feel like "first day at work" even after enemies and hazards appear. - Art should support horizontal movement first, with vertical movement used as variety. #### Mobile Control UI Kit Target mobile controls: - Left side: virtual joystick or thumb pad. - Right side: jump button. - Right side: shoot/action button. - Context-sensitive interact button near jump/shoot or near the prompt area. - HUD: lives, health, current weapon/power-up, lab progress, score/XP if used. Control rules: - Controls must not cover terminals, dialogue, enemies, or landing zones. - Buttons should be large enough for mobile play. - Jump and shoot should be easy to press together. - Interact should appear only when relevant if possible. - The joystick should feel like a real game control, not a web form control. - Keyboard controls remain available for desktop. #### HUD And Feedback Kit HUD items: - Lives. - Health. - Current weapon/power-up. - Checkpoint status. - Lab objective marker. - Score/XP or level rank if used. Feedback effects: - Player hit flash. - Enemy hit flash. - Enemy defeated burst. - Power-up pickup effect. - Checkpoint activation effect. - Door unlock effect. - Terminal success effect. - Lab completed banner. Approval criteria: - [ ] Player character direction approved. - [ ] Enemy family direction approved. - [ ] Hazard direction approved. - [ ] Power-up direction approved. - [ ] Checkpoint direction approved. - [ ] Terminal/unlock direction approved. - [ ] First Day Office environment kit approved. - [ ] Mobile control UI direction approved. - [ ] HUD and feedback direction approved. - [ ] Only after the above approvals, begin full Level 1 assembly. ### Section 4: Sprite Prep And Animation Test Purpose: - Convert approved concept sheets into individual runtime-ready sprite files. - Keep all runtime sprites on transparent backgrounds. - Prove Patch, enemies, hazards, props, and controls in a tiny test arena before building the full first level. - Do not start full Level 1 assembly until this section is complete. Sprite-prep steps: - [x] Slice Patch concept into a runtime-ready source sprite. - [x] Slice enemy sheet into individual enemy sprites. - [x] Slice hazard sheet into individual hazard sprites. - [x] Slice power-up sheet into individual pickup sprites. - [x] Slice prop sheet into individual terminal/checkpoint/door sprites. - [x] Confirm every sliced sprite is PNG RGBA with transparent edges. - [x] Create a simple asset manifest for names, file paths, and rough collision boxes. - [x] Keep source concept sheets available for review, but use sliced sprites for gameplay. Patch animation steps: - [x] Create Patch idle runtime animation state. - [x] Create Patch run runtime animation state. - [x] Create Patch jump/fall runtime animation states. - [x] Create Patch shoot/pulse runtime animation state. - [x] Create Patch hurt runtime animation state. - [x] Create Patch victory/success runtime animation state. - [x] Export Patch hand-drawn animation frames as optimized transparent sprites or a sprite sheet. - [x] Define Patch collision box separately from the visible art. Gameplay-object steps: - [x] Define first-pass crawler behavior. - [x] Define first-pass cable spike damage behavior. - [x] Define first-pass shield pickup behavior. - [x] Define first-pass terminal/checkpoint/door interactions. - [x] Define first-pass hit flashes, pickup flashes, and unlock feedback. - [x] Add first-pass animated crawler and cable spike runtime sheets. - [ ] Expand enemy behaviors: drone, packet swarm, Trojan crate, turret, brute. - [ ] Expand hazard behavior: pit/void, timed beam, collapsing tile. - [ ] Expand pickup behavior: health, double shot, spread shot, hint token, extra life. Tiny test arena steps: - [x] Build a small non-story test arena. - [x] Add joystick-style mobile movement. - [x] Add jump and shoot buttons. - [x] Add keyboard movement, jump, and shoot. - [x] Add double jump with visible jump-charge HUD feedback. - [x] Add Patch idle/run/jump/shoot state switching. - [x] Add one enemy, one hazard, one pickup, one checkpoint, and one terminal prop. - [x] Verify Patch can double jump to a higher catwalk and reach the terminal platform. - [x] Upgrade test arena platforms, backgrounds, and signs toward the polished sprite style. - [x] Verify the arena is smooth on a 390px mobile viewport. - [x] Verify no controls cover key gameplay objects. Completion criteria: - [x] Runtime sprite files exist and are transparent. - [x] Patch can visibly idle, run, jump, and shoot in the test arena. - [x] At least one enemy and one hazard can be placed and detected. - [x] At least one pickup can be collected. - [x] At least one checkpoint/terminal prop can be interacted with. - [x] Mobile controls are comfortable enough to continue. - [x] Double jump is proven before full Level 1 layout begins. - [x] Only after this section passes, begin full Level 1 layout. ### Section 5: Level 1 First Slice Assembly Purpose: - Turn the approved test arena into the first real playable slice. - Approve the whole route as a simple schematic before building the level. - Keep the first slice punchy and readable: fast arcade pressure, clear jumps, earned terminal stop. Planning artifact: - [x] Create first black-and-white whole-level schematic: `docs/level-1-first-slice-schematic.svg`. First slice build steps: - [x] Convert schematic into playable world dimensions. - [x] Build the start zone and movement warmup. - [x] Add wave 1 with basic virus crawlers. - [x] Add first spike/gap obstacle. - [x] Add mid-catwalk crossback route. - [x] Add wave 2 with crawler plus first drone. - [x] Add checkpoint before the terminal approach. - [x] Add Trojan crate ambush set-piece. - [x] Add ethernet pit or black-hole hazard. - [x] Add terminal safe zone and Lab 1 handoff. - [x] Make Lab 1 completion unlock the security door. - [x] Add short exit route after the terminal. - [x] Test the full slice on desktop and mobile. First playable route: - Page: `first-day-office/level-1-slice-v2.html`. - Test: `tests/functional/phase5-level-1-slice.spec.js`. - Current state: rough first playable slice is complete enough for difficulty, pacing, and layout tuning. ## Phase 0: Product Decisions - [x] Confirm the side-scroller is the primary beginner experience, not a separate optional mode. - [x] Decide whether the existing terminal page remains available as a direct fallback. - [x] Decide account behavior: - [x] Real user login path. - [x] Guest play path. - [x] Progress persistence for guests. - [x] Decide first prototype scope. Phase 0 decisions: - The side-scroller becomes the main Windows beginner entry path. - The existing direct terminal route stays available for QA, bookmarks, recovery, and future advanced users. - Account behavior is guest-first for the prototype. "Play as guest" must work without sign-in. - Guest progress uses local browser storage first. - Real login can appear in the story flow as a visible option, but it must not block guest play during the prototype. - The first prototype includes only the first-day intro, a login/guest choice, one office hallway, one manager NPC, one workstation, Lab 1 launch, and return after Lab 1 completion. - The prototype must be usable on mobile before new rooms, arcade content, or later labs are added. Agreed target flow: ```text Home -> First-day side-scroller intro -> Login or Play as Guest -> Office hallway -> Manager briefing -> Workstation interaction -> Windows Beginner Lab 1 -> Lab 1 completion -> Return to office hallway -> Manager reacts and points to the next task ``` Mobile control expectations: - Movement uses fixed on-screen left and right controls. - Interaction uses one clear on-screen action control. - Shooting uses the mobile Action control once the player has the pulse tool. - Keyboard users can move with ArrowLeft/ArrowRight or A/D, and interact with Enter, Space, or E. - Keyboard users can shoot with a dedicated key once the player has the pulse tool. - Controls must not cover important dialogue, workstation prompts, or terminal launch actions. - The smallest supported mobile viewport for prototype testing is 390px wide. Completion criteria: - [x] One agreed target flow is written down. - [x] The prototype scope is small enough to build quickly. - [x] Mobile control expectations are agreed. ## Phase 1: First-Day Intro Scene skeleton: `docs/phase1-first-day-scene-skeleton.md` - [ ] Create a short first-day scene. - [ ] Introduce the player as a new employee. - [ ] Add a face-to-face manager/player dialogue moment. - [ ] Add manager briefing with funny, dry workplace dialogue. - [ ] Add simple sound-backed dialogue cues, and leave room for actual voice/audio later. - [ ] Keep the briefing short enough to read in about 30 seconds. - [ ] Establish that this is a side-scrolling game world, not just a menu before labs. - [ ] Move the existing big cyber/network intro out of the first screen. - [ ] Add transition from briefing to login choice. - [ ] Add keyboard shoot binding for the side-scroller prototype. - [ ] Replace stair-step platforms with a readable side-scroller route made from longer platforms and horizontal traversal. - [ ] Keep the first route fun enough that it feels like a game before it feels like a lesson. Completion criteria: - [ ] New users understand why they are using the terminal. - [ ] New users understand they are playing a game that contains terminal challenges. - [ ] First manager/player exchange is readable, funny, and characterful. - [ ] Intro does not block replay. - [ ] Intro works on mobile and desktop. - [ ] First route uses longer platform sections that visually match the landing zones. - [ ] The terminal destination is clear without making the route feel like a vertical staircase. ## Phase 1A: First Office Art Direction Pass Scope lock: finish every item in this phase before starting new rooms, new labs, new mechanics, arcade work, or unrelated visual experiments. The goal is to make First Day Office look intentionally designed rather than assembled from disconnected props. Art direction rules: - [x] Define the visual hierarchy: gameplay route first, characters and threats second, terminal destination third, background decoration last. - [x] Define scene layers: - [x] Background wall layer: lights, pipes, posters, whiteboard, signs. - [x] Gameplay route layer: platforms, bridges, ledges, ladders/service connectors. - [x] Foreground floor layer: characters, cable pile, doors, grounded props. - [x] UI layer: speech bubbles, prompts, controls, HUD. - [x] Define placement rules: - [x] Background props must attach to the wall grid or ceiling lines. - [x] Floor props must sit on the floor or a visible surface. - [x] Gameplay platforms must be visually distinct from decoration. - [x] Decorative objects must not look like standable platforms. - [x] Terminal/workstation must read as the destination. - [x] Define shared style rules: - [x] Shadows use one consistent direction. - [x] Side faces use one consistent pixel-perspective angle. - [x] Labels/signs use consistent sizes and placement. - [x] Materials repeat by purpose: route metal, wall signage, floor props, terminal glow. Implementation passes: - [x] Pass 1: Background wall cleanup. - [x] Remove or reposition random floating notes/signs. - [x] Align lights, pipes, posters, and whiteboard to believable wall zones. - [x] Reduce visual competition behind the main route. - [x] Pass 2: Gameplay route cleanup. - [x] Keep long readable horizontal platforms. - [x] Add or reserve connector space for ladders, bridges, or service lifts. - [x] Confirm visible platforms match collision/landing zones. - [x] Make the first route readable without needing instructions. - [x] Pass 3: Door and terminal destination cleanup. - [x] Make doors feel grounded and useful, not randomly placed. - [x] Make terminal platform the clearest destination. - [x] Keep destination markers visible but not noisy. - [x] Pass 4: Foreground/floor cleanup. - [x] Anchor cable pile, boxes, arcade/water cooler if visible, and character positions to the floor. - [x] Remove or simplify props that distract from the route. - [x] Keep hazards readable separately from decoration. - [x] Pass 5: Speech and prompt UI cleanup. - [x] Keep speech bubbles near the speaking character and in negative space. - [x] Keep prompts compact and close to the relevant object. - [x] Confirm UI does not cover the route, terminal, or mobile controls. - [x] Pass 6: Mobile composition pass. - [x] Check 390px mobile viewport. - [x] Confirm route, characters, terminal, viruses, and UI are readable. - [x] Confirm no important object is clipped or hidden by controls. - [x] Pass 7: Desktop composition pass. - [x] Check desktop viewport. - [x] Confirm background props feel aligned and intentional. - [x] Confirm empty space supports readability rather than feeling unfinished. Completion criteria: - [x] First Day Office no longer looks like randomly placed objects. - [x] Every visible decorative object has a believable anchor point. - [x] The gameplay route is the clearest visual layer. - [x] The terminal destination is obvious at a glance. - [x] Speech bubbles and prompts stay compact and near the relevant character/object. - [x] Mobile screenshot passes visual review. - [x] Desktop screenshot passes visual review. - [x] `npx playwright test tests/functional/phase1-first-day-office.spec.js` passes. - [x] Changes are committed and pushed. - [ ] User confirms the art direction pass is complete before new project work starts. ## Phase 2: Login / Guest Entry - [ ] Create login screen inside the story flow. - [ ] Add "Log in" option for real credentials. - [ ] Add "Play as guest" option. - [ ] Route successful entry into the office scene. - [ ] Show current player state in the game wrapper. Completion criteria: - [ ] User can enter without friction as guest. - [ ] Logged-in users can resume progress. - [ ] Login failure does not trap the player. ## Phase 3: Prototype Office Scene - [ ] Build one side-scrolling office hallway. - [ ] Add player character. - [ ] Add manager NPC. - [ ] Add one workstation. - [ ] Add interaction prompt near workstation. - [ ] Add mobile controls: - [ ] Move left. - [ ] Move right. - [ ] Jump. - [ ] Interact. - [ ] Shoot/action. - [ ] Add keyboard controls: - [ ] Left/right movement. - [ ] Jump key. - [ ] Interact key. - [ ] Dedicated shoot key. Completion criteria: - [ ] Player can move comfortably on mobile. - [ ] Player can jump and shoot comfortably on mobile and keyboard. - [ ] Player can interact with workstation. - [ ] Scene is readable on small screens. - [ ] No important UI overlaps controls. ## Phase 4: Lab 1 Integration - [ ] Launch `win-dir-incident-triage` from the workstation. - [ ] Return to the office scene after Lab 1 completion. - [ ] Manager reacts to completion. - [ ] Preserve the Lab 1 hidden Patch Ping Run easter egg. - [ ] Ensure the easter egg can still launch Patch Ping Run. Completion criteria: - [ ] Lab 1 starts from the side-scroller. - [ ] Lab 1 completion returns the player to the game wrapper. - [ ] Existing terminal-only path still works or has a clear fallback. ## Phase 5: Labs 1-5 As Onboarding - [ ] Map Labs 1-5 to office onboarding tasks. - [ ] Add room/interaction context for each lab. - [ ] Add light side-scroller enemies or obstacles between lab stations. - [ ] Increase enemy/obstacle difficulty as the terminal labs get harder. - [ ] Keep these labs focused on files, folders, notes, hidden files, copying, and basic system identity. - [ ] Avoid network-heavy story framing before Lab 6. - [ ] Design each lab approach as a small platformer route with a different shape, not just a terminal placed after a hallway. - [ ] Let successful commands visibly change the game world: bridges power on, doors unlock, enemies clear, lights return, or NPCs move. Suggested mapping: - [ ] Lab 1: First workstation / incident folder triage. - [ ] Lab 2: Notes desk / folder navigation. - [ ] Lab 3: Records area / file reading and log review. - [ ] Lab 4: Help desk station / system identity checks. - [ ] Lab 5: IT desk / local network configuration basics. Completion criteria: - [ ] Labs 1-5 run in order from the side-scroller. - [ ] Each lab has a clear room reason. - [ ] Each lab is paired with a game segment that feels slightly more challenging than the previous one. - [ ] Player always knows where to go next. ## Core Flow Lock: Stage, Lab, Key, Door Goal: prove the repeatable game loop before expanding the lesson catalog or adding more presentation. - [ ] Build Stage 1 route to terminal. - [ ] Launch isolated Lab 1 from the terminal. - [ ] Complete Lab 1. - [ ] Award a visible key, badge, evidence item, or access token. - [ ] Use the reward to unlock the next door or route. - [ ] Move into Stage 2. - [ ] Launch isolated Lab 2 from the Stage 2 terminal. - [ ] Complete Lab 2. - [ ] Award the next visible reward. - [ ] Unlock the next route. - [ ] Repeat until the loop feels natural without needing old terminal hub screens. Completion criteria: - [ ] Player can explain the loop after one stage without reading instructions. - [ ] The reward appears only after lab completion. - [ ] Locked doors do not open early. - [ ] The next stage is clearly reachable after the reward. - [ ] No old lesson hub or course navigation appears during the loop. ## Stage Power-Ups And Level-Ups Goal: add optional game-only progression so combat and traversal waves can get harder without making every reward a terminal lesson reward. - [ ] Define optional power-ups that appear inside stages, not inside terminal lessons. - [ ] Add health pickups for longer stages. - [ ] Add shield pickups for enemy-heavy routes. - [ ] Add temporary weapon upgrades that last until the player gets hit. - [ ] Add jump, dash, or movement upgrades only when the level design needs them. - [ ] Add hint-token pickups separately from required lab keys. - [ ] Add score, XP, or badge pickups for optional mastery. - [ ] Keep required door keys tied to lab completion, not random pickup collection. - [ ] Scale enemy waves after each lab unlock. - [ ] Introduce new enemy behaviors slowly as the lab categories become more advanced. - [ ] Keep optional power-ups useful but not required for basic completion. Completion criteria: - [ ] A player can finish the main route without optional pickups. - [ ] Optional pickups make hard waves easier or more rewarding. - [ ] Required lab keys stay visually and mechanically distinct from optional power-ups. - [ ] Enemy difficulty increases feel fair because the player has better tools, checkpoints, or power-up opportunities. ## Long Campaign Pacing Guard Goal: stop a 100+ lab campaign from becoming an endless difficulty climb. - [ ] Group related labs into mission episodes instead of making one full stage per lab. - [ ] Use multiple terminal stations inside some stages, with save points before and after each station. - [ ] Keep required mission episodes around 6-12 minutes. - [ ] Use optional side terminals for extra practice, coins, posters, hints, or upgrade currency. - [ ] Reset the pressure curve at chapter changes instead of making every new lab harder than the last forever. - [ ] Use controlled random wave pools so replay attempts feel fresh without becoming unfair. - [ ] Cap randomization by stage tier: early stages use simple variants, later stages mix enemy types and hazards. - [ ] Let manager assist, checkpoints, and recovery rewards stop repeated failure loops. Completion criteria: - [ ] No chapter requires constant perfect play to progress. - [ ] A struggling player can still clear the main route with saves and assists. - [ ] Random waves are selected from designed pools, not fully random spawns. - [ ] Optional difficulty rewards mastery but does not block story progress. ## Next 10 Lab/Level Schematics Goal: use a single approved difficulty curve for the next Windows beginner stages before building more playable levels. - [x] Draft a 10-level schematic showing each lab's route, enemy pressure, agility pressure, reward, and Patch support mechanic. - Schematic: `docs/next-10-lab-level-schematics.md` - [x] Create a visual schematic board for the next 10 lab levels. - Visual board: `docs/next-10-lab-level-schematics.html` - [ ] Review Level 2 and Level 3 before building them. - [ ] Convert approved schematic rows into level config tickets one at a time. - [ ] Keep each level focused on one or two new pressures only. - [ ] Add a matching Patch support mechanic whenever a level adds a new pressure type. - [ ] Confirm every lab in the schematic maps to a side-scroller stage, terminal gate, reward, and next-door unlock. - [ ] Confirm each level's end reward offers a fair coin, gun upgrade, utility, or movement choice based on performance. Completion criteria: - [ ] Level 2 can be built from the schematic without inventing new rules mid-build. - [ ] Each level lists lab scenario IDs, traversal pressure, enemies, hazards, power-up support, and a fairness rule. - [ ] The difficulty curve works on mobile portrait and landscape. - [ ] Enemy speed, jump precision, and terminal complexity do not all increase in the same level. - [ ] Upgrade choices are optional bonuses after stage completion, not extra lesson gates. ## Future Level Hook Idea Bank: Hold For Later Source reference: `C:\Users\Owner\Downloads\mobile_terminal_labs_level_hook_reference.docx` Status: captured for a later design pass only. Do not implement these ideas yet, and do not use them as a reason to rewrite current playable levels, terminal lessons, command validation, accepted commands, scenario success checks, lesson order, or package/runtime files. Purpose: preserve a menu of 100 mobile-first level-hook ideas that can make each stage feel less repetitive. Use the ideas as game-facing wrappers around existing labs: level silhouette, mission reason, environmental hook, terminal purpose, and unlock payoff. Safe integration rules for later: - [ ] Keep terminal lab content and validation unchanged unless a separate lesson edit is deliberately approved. - [ ] Use one strong opening silhouette per level: shelves, cable lane, server bay, cabinet maze, vertical shaft, lift route, archive vault, and similar readable shapes. - [ ] Make the terminal feel like the tool that changes the world: open a door, restore power, disable a turret, reveal a route, copy a key file to USB, or drop a shield. - [ ] Keep mobile rhythm short: quick action section, short terminal decision, clear reward. - [ ] Randomise or vary metadata, geometry hooks, reward text, NPC requests, room dressing, and route purpose before touching lesson logic. - [ ] Do not add a hook unless it answers: why Patch needs this terminal, what file/note/key he gets, and what visibly changes afterward. Idea families captured from the reference: - [ ] Facility / Warehouse Geometry: Training Gate through Storage Cage Rescue. - [ ] Cable / Maintenance / Utility Spaces: Cable Lane Crawl through Maintenance Bot Escort. - [ ] Server / Data Centre Silhouettes: Server Bay Start through NOC Balcony. - [ ] Security / Surveillance / Stealth Geometry: Camera Cone Hall through Prison Cell Block. - [ ] Network Cabinet / DNS / Routing Spaces: DNS Cabinet Maze through Proxy Mirror Room. - [ ] Power / Industrial / Environmental Hazards: Generator Pit through Emergency Light Run. - [ ] Malware / AI / Digital Threats: Malware Pursuit through Quarantine Airlock. - [ ] Rescue / Objective / Heist Scenarios: Technician Rescue through Lab Specimen Escape. - [ ] Boss / Set-Piece / High-Memory Moments: Shielded Turret Boss through Escape Countdown. - [ ] Finale / Remix / Advanced Geometry: Vertical Mainframe Shaft through Post-Credits Training Remix. Carry-over design reminder: - [ ] The player should not feel like the game paused for homework. The terminal should feel like Patch's tool for beating the room. ## Next Work Session: Game-Native Terminal Missions Goal: make terminal labs feel like short game missions that drop straight into CMD, not lesson pages. - [x] Replace long terminal briefings with a tiny mission header. - [x] Hide all mission choice, roadmap, previous, next, reset, and lesson-navigation UI in side-scroller terminal embeds. - [x] Start only the required scenario for the current door/key gate. - [x] Auto-focus the CMD prompt as soon as the terminal opens. - [x] Reduce in-terminal text to short game prompts: - [x] `MISSION: Find the incident note.` - [x] `START: C:\Lab>` - [x] `DO: Check files. Open the right folder. Read the note.` - [x] Convert helper text from explanations into short action prompts, such as `Check what is here`, `Open Incidents`, and `Read note.txt`. - [x] Only award the USB key after the required scenario reports completion. - [x] Replace the visible hand-in shortcut with completion status or `Take USB key` after the lab is genuinely complete. - [x] Close or return from the terminal quickly after the USB key is issued. - [ ] Keep full lesson explanations available outside the game flow, but remove them from side-scroller mission embeds. Completion criteria: - [x] Opening a level terminal feels like a mission console, not a course selector. - [x] The player cannot choose another mission from inside the game terminal. - [x] The terminal can be completed with minimal reading. - [x] The USB key reward is tied to the one required mission. - [x] The embedded terminal modal has no ugly horizontal layout overflow. Carry-over note: - [x] Recheck Patch Ping Run launch/return flow. User reported running Patch Ping Run but the issue report was cut off; ask what happened before changing it. ## Next Work Session: Legacy Lesson Reconfiguration Plan Goal: stop side-scroller players from escaping into old terminal-course screens, while preserving the old lesson hub as an archive for later reference. Rules for this cleanup: - [ ] Change one lab route at a time. - [ ] Test that lab before touching the next lab. - [ ] Keep the old terminal lessons backed up before removing or hiding any UI. - [ ] Archive legacy pages instead of deleting them. - [ ] Do not ship a side-scroller terminal embed that exposes Home, track switching, mission picking, roadmap links, previous/next lesson controls, or old helper panels. - [ ] Apply this isolation pattern to every lesson that appears in the game, not only the first six labs. - [ ] Treat each new side-scroller stage as the launcher for exactly one locked lesson mission or one intentionally grouped mission chain. Backup and archive steps: - [x] Create a dated backup of the current terminal lesson files before restructuring. - [x] Record the backup location in this roadmap. - Backup path: `backups/legacy-terminal-lessons-20260610-113353/legacy-terminal-lessons.tar.gz` - Manifest path: `backups/legacy-terminal-lessons-20260610-113353/manifest.txt` - [x] Move or copy the old terminal labs hub into an archive path. - Archive path: `archive/legacy-terminal-hub-20260610/` - [x] Keep archived hub assets reachable for developers, not players. - [x] Add a short archive note explaining that the old hub is retained for reference only. - [ ] Confirm the side-scroller no longer links to the old terminal home page. - Audit note: old Level 1 links were retired and `Level 1` now routes to `first-day-office/level-1-slice-v2.html`. Isolated lesson page strategy: - [ ] Create one isolated page per game lab mission. - [ ] Give each isolated lab page one required scenario ID. - [ ] Map every old terminal lesson to a future game stage, room, workstation, door, NPC request, or reward gate before migration. - [ ] Give every mapped lesson its own locked game mission route before exposing it to players. - [ ] Load only the assets needed for that lab. - [ ] Remove global terminal navigation from isolated lab pages. - [ ] Remove track switching from isolated lab pages. - [ ] Remove mission browsing from isolated lab pages. - [ ] Remove saved-progress resume prompts from isolated lab pages. - [ ] Keep the command engine and scenario validation shared where practical. - [ ] Keep full lesson explanations outside the game flow, not inside the side-scroller modal. Lab migration order: - [ ] Lab 1: isolate Incident Note Triage. - [ ] Test Lab 1 launch from side-scroller. - [ ] Test Lab 1 cannot reach Home, old hub, track switcher, or mission picker. - [ ] Test Lab 1 completion grants the USB key and returns cleanly. - [ ] Lab 2: isolate folder navigation mission. - [ ] Test Lab 2 launch, lockout, completion, and return. - [ ] Lab 3: isolate file reading/log review mission. - [ ] Test Lab 3 launch, lockout, completion, and return. - [ ] Lab 4: isolate system identity mission. - [ ] Test Lab 4 launch, lockout, completion, and return. - [ ] Lab 5: isolate local configuration basics. - [ ] Test Lab 5 launch, lockout, completion, and return. - [ ] Lab 6: isolate connectivity mission and Patch Ping Run handoff. - [ ] Test Lab 6 launch, lockout, completion, Patch Ping Run, and return. - [ ] Continue the same isolate-and-test cycle for every remaining Windows beginner lesson. - [ ] Continue the same isolate-and-test cycle for every Linux lesson that becomes part of the game. - [ ] Continue the same isolate-and-test cycle for every Cisco lesson that becomes part of the game. - [ ] Continue the same isolate-and-test cycle for every security/challenge lesson that becomes part of the game. - [ ] Do not add a lesson to a playable stage until its isolated mission route passes launch, lockout, completion, and return tests. Unnecessary content audit: - [ ] List every page, script, stylesheet, modal, overlay, and helper panel loaded by side-scroller lab embeds. - [ ] Mark each item as keep, archive, isolate, or remove from game flow. - [ ] Remove visual chrome that makes the game feel like a generic course portal. - [ ] Remove duplicated emergency CSS once the isolated pages are stable. - [ ] Remove stale mobile menu, roadmap, dashboard, and track-switch code from embedded lab pages. - [ ] Keep developer/admin smoke pages out of player navigation. - [ ] Keep old docs and reports out of player navigation. Visual quality cleanup: - [ ] Establish one game-terminal visual style for all side-scroller lab modals. - [ ] Use compact mission-console copy, not course-card copy. - [ ] Remove oversized cards, nested cards, generic menu tiles, and unrelated dashboard elements from lab embeds. - [ ] Verify portrait mobile, landscape mobile, tablet, and desktop modal layouts. - [ ] Verify no controls overlap the terminal prompt, footer, close button, or reward status. Completion criteria: - [ ] Each game lab opens directly into its mission. - [ ] Players cannot navigate from a game lab back into the old terminal lesson hub. - [ ] Archived lessons remain available for developer reference. - [ ] Every migrated lab has a launch, lockout, completion, and return test. - [ ] Every lesson used by the game has a stage/room/reward mapping. - [ ] No next lab migration starts until the current lab passes its checklist. ## Phase 6: Move Network Intro After Lab 5 - [ ] Remove the big network intro from the initial onboarding. - [ ] Add network briefing after Lab 5. - [ ] Introduce server room / network closet. - [ ] Explain that the player is moving from local terminal basics into network troubleshooting. Completion criteria: - [ ] Network concepts appear when they become relevant. - [ ] Lab 6 feels like a new responsibility, not random content. ## Phase 7: Lab 6 Connectivity And Patch Ping Run - [ ] Launch Lab 6 from the network room or network closet. - [ ] Include `win-ping-fileserver`. - [ ] Include `win-tracert-and-pathping-web-lab`. - [ ] After the final Lab 6 completion check, launch Patch Ping Run as part of the main flow. - [ ] Return player to the side-scroller after Patch Ping Run. Completion criteria: - [ ] Patch Ping Run starts from the end of Lab 6. - [ ] Patch Ping Run is no longer missed by the learner. - [ ] Player returns to the correct story state after the game. ## Phase 8: Room Expansion - [ ] Add server room. - [ ] Add network closet. - [ ] Add lunch room. - [ ] Add help desk. - [ ] Add training room. - [ ] Add locked doors that unlock after lab milestones. - [ ] Add enemy types that match each room and lab theme. - [ ] Add simple combat progression: faster targets, tougher targets, and timing challenges. Completion criteria: - [ ] Rooms are useful, not decorative only. - [ ] Room unlocks match lab progress. - [ ] New rooms introduce new game threats or mechanics. - [ ] Player travel time stays short. ## Phase 9: Optional Arcade / Break Room - [ ] Add old arcade machine in lunch room. - [ ] Let player launch optional mini games. - [ ] Include Patch Ping Run as one arcade/game option after discovery. - [ ] Consider later mini games: - [ ] Space-invaders-style packet defense. - [ ] Worm/snake style cable routing. - [ ] Simple terminal reflex game. Completion criteria: - [ ] Arcade games are optional. - [ ] Arcade does not block lab progress. - [ ] Mini games work well on mobile. ## Phase 10: Progress And Save State - [ ] Track current room. - [ ] Track completed labs. - [ ] Track unlocked rooms. - [ ] Track completed mini games. - [ ] Support guest local progress. - [ ] Support logged-in cloud progress if available. Completion criteria: - [ ] Refreshing the page does not lose meaningful progress. - [ ] Guest and logged-in paths behave predictably. ## Phase 11: Mobile Quality Pass - [ ] Test smallest supported mobile viewport. - [ ] Confirm movement controls do not cover important scene content. - [ ] Confirm terminal modal/lab handoff is readable. - [ ] Confirm return-from-lab flow works. - [ ] Confirm arcade/game controls are usable. Completion criteria: - [ ] No horizontal overflow. - [ ] No hidden primary controls. - [ ] No clipped modal headings. - [ ] Player can complete at least Labs 1-6 on mobile. ## Phase 12: Release Checklist - [ ] Add smoke tests for first-day intro. - [ ] Add smoke tests for guest login. - [ ] Add smoke tests for Lab 1 launch and return. - [ ] Add smoke tests for Lab 6 Patch Ping Run launch. - [ ] Update existing flowchart docs. - [ ] Update QA handoff notes. - [ ] Push to GitHub. Completion criteria: - [ ] Side-scroller beginner flow is test-covered. - [ ] Existing terminal direct flow is not broken. - [ ] GitHub has the final release commit. ## Open Questions - [ ] Should the player be customizable? - [ ] Should the manager be voiced, silent text, or both? - [ ] Should the terminal appear as a full-screen modal or embedded workstation screen? - [ ] Should movement/combat become physics-based or remain simple side-scroller controls? - [ ] Should arcade games give XP or remain pure easter eggs? - [ ] Should the side-scroller replace the current home route or be a new route first? - [ ] What is the final objective/boss/gate that proves the player has completed the beginner path?