Rens Roosloot

Game URS

Volledige gerenderde weergave van gameURS.md.

Laatst gesynchroniseerd: 13 april 2026

Game URS - Cooperative Shared-Control Platformer

Version: 1.0
Date: March 8, 2026
Author: Rens Roosloot / Codex collaboration

1. Purpose

This document captures the user requirements for a small browser game concept to be hosted on roosloot.com.

The game goal is to create a short, accessible, playful 2D side-scrolling platformer where two players control one character together.

2. Scope

In scope:

  • A 2D side-scrolling platformer playable in the browser
  • One shared character controlled by two players on one keyboard
  • Simple puzzle-platform interactions (climb, switches, blocks, platforms)
  • Short levels, low difficulty, quick play sessions
  • Hand-built levels as the primary first release direction
  • Pixel-art / flat-sprite visual style (e.g. Pico Park-like readability)

Out of scope (initial concept phase):

  • Online multiplayer
  • Accounts, saves, backend services
  • Combat-heavy gameplay
  • Infinite/procedural endless mode in initial release
  • Complex inventory systems

3. Core Concept

Two players must cooperate to move a single character through a short platform level.

The twist:

  • Each player only controls part of the move set
  • The control split can change between levels or be triggered during gameplay

Example split:

  • Player 1 (WASD) controls Left + Jump (Up)
  • Player 2 (Arrow keys) controls Right + Interact/Crouch (Down)

This creates intentional coordination friction and communication-based gameplay.

4. Players and Input Model

4.1 Players

  • The game shall support local co-op for 2 players on one keyboard.
  • The game may optionally support 1-player practice mode later, but 2-player mode is the primary design target.

4.2 Input Devices

  • Primary input shall be keyboard.
  • Default key groups:
    • Player 1: W, A, S, D
    • Player 2: ArrowUp, ArrowLeft, ArrowDown, ArrowRight

4.3 Split Control Rules

  • The game shall assign only a subset of character actions to each player.
  • Both players must be required to cooperate to complete the level.
  • The mapping of actions to players may change:
    • between levels, and/or
    • during a level after a trigger (switch, checkpoint, event)

4.4 Initial Action Set (target)

  • Move left
  • Move right
  • Jump
  • Interact / crouch / down-action

5. Gameplay Requirements

5.1 Game Style

  • The game shall be a 2D side-scrolling platformer.
  • The level shall fit a short play session (roughly a few minutes).
  • Difficulty shall be light-to-moderate and focus on cooperation, not precision punishment.

5.2 Objective

  • The primary objective shall be reaching an exit/end point.
  • Secondary objective (optional later): finish time or low mistake count.

5.3 Level Design Features

The game should include simple platforming and environmental interactions such as:

  • climbing to higher ledges
  • pushing/moving blocks to create height
  • switches that lower/raise platforms
  • timing or sequencing interactions

5.4 Progression / Variation

  • The game shall include at least one level where shared controls are switched or remapped.
  • Control remapping should remain understandable and communicated clearly to players.
  • The preferred first release structure shall be a sequence of hand-built levels played one after another (old-school progression feel).
  • Restarting the campaign may return players to the first level.
  • The first campaign arc should use a teaching progression where:
    • Level 1 introduces the shared-control core mechanic
    • each subsequent level introduces one additional gameplay element
    • later levels combine previously introduced elements

5.4.1 Initial Campaign Progression (Target, Levels 1-5)

  • Level 1: shared-control movement onboarding (intro level)
  • Level 2: movable block introduction
  • Level 3: switch + bridge/platform introduction
  • Level 4: control remap introduction plus a later in-level player key-role swap (WASD/Arrow groups)
  • Level 5: combination level (block + switch/bridge + remap/key-role swap concepts) as the first campaign "exam" level

5.5 Failure / Recovery

  • Failure within a level (e.g. falling) should return players to the most recent checkpoint, not immediately restart the full campaign.
  • Checkpoint recovery should be fast to preserve play flow and reduce frustration in the shared-control mechanic.
  • The game should support a small old-school lives system (target: 3 lives) to add tension while keeping checkpoint recovery.
  • Losing a life should respawn the character at the latest checkpoint.
  • When all lives are lost, the game should restart from the start of Level 1 with lives restored.
  • Each level should include at least one clear fail condition / hazard so progression feels game-like rather than only demonstrative.
  • Early levels should use simple, readable hazards first (e.g. falling into pits) before adding more complex hazards.

6. Level Generation (Future Direction)

  • Procedural or semi-procedural generation is a future direction, not the first release target.
  • Generated levels shall remain short, solvable, and readable.
  • Generation logic shall avoid impossible states (e.g. jumps too high, blocked progress).
  • A hybrid approach is preferred if/when procedural mode is added:
    • hand-authored room chunks
    • procedural sequencing / variation

7. Character and Visual Style

  • Character(s) shall be rendered as simple 2D flat sprites.
  • Visual style should prioritize readability and charm over realism.
  • Inspiration direction: clean, playful, Pico Park-like simplicity.
  • Animation can be minimal (idle, run, jump, interact) if needed for scope control.

8. UX / Communication Requirements

  • The game shall clearly communicate the current control split for both players.
  • If controls change, the game shall clearly indicate the new mapping.
  • Restarting a level shall be quick and frictionless.
  • The game should support short onboarding (simple instructions before play starts).

9. Technical / Implementation Constraints

  • The game shall run client-side in the browser (static-site compatible).
  • No backend or login requirement.
  • Performance shall be acceptable on typical desktop browsers.
  • The implementation should remain small and maintainable within the existing static site structure.

10. Accessibility and Input Considerations

  • Controls shall be keyboard-based and documented on-screen.
  • The game should avoid requiring extremely fast key repetition.
  • Visual contrast between platforms, interactables, and character should be clear.
  • Reduced-motion-safe behavior should be considered if camera effects are added.

11. Acceptance Criteria (Concept-Level)

  • AC-01: Two players can control one character using WASD + arrow keys.
  • AC-02: Each player controls only part of the action set.
  • AC-03: The level contains at least one simple interaction puzzle (e.g. block or switch/platform).
  • AC-04: The level can be completed in a short session without high difficulty.
  • AC-05: The game communicates current controls clearly to both players.
  • AC-06: Control mapping changes at least once (level-based or trigger-based).
  • AC-07: The game runs as a static browser page without backend dependencies.

12. Open Design Questions (Next Step)

  • Should the character be one shared avatar, or a visually split "two minds / one body" style character?
  • Should procedural generation be full-run generation or chunk-based variation (for a later mode)?
  • Should there be a score/timer, or only completion?
  • Should there be a 1-player assist/debug mode for testing?
Terug naar home