agentleFS
leaf76leaf76/agent-skills/develop-web-game/SKILL.md

develop-web-game

Skill0 starsChanged 3 months agoMITView on GitHub

Use when Codex is building or iterating on a web game (HTML/JS) and needs a reliable development + testing loop: implement small changes, run a Playwright-based test script with short input bursts and intentional pauses, inspect screenshots/text, and review console errors with render_game_to_text.

  • Installs packages

3 other projects use a version of this, 2 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. 7 are common, 0 are distinctive, and 9 are very specific to this project.

  • 7

    Common

    Most of the 3 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Verify Playwright availability: Ensure playwright is available (local dependency or global install).

    line 28
  2. Common:

    Reset between scenarios: Avoid cross-test state when validating distinct features.

    line 36
  3. Common:

    Test any new features added for the request and any areas your logic changes could affect.

    line 58
  4. Common:

    Prefer a single canvas centered in the window.

    line 78
  5. Common:

    Keep on-screen text minimal.

    line 81
  6. Common:

    Avoid overly dark scenes unless the design calls for it.

    line 82
  7. Common:

    Keep the payload succinct and biased toward on-screen/interactive elements.

    line 102
  8. Very specific:

    Use a single key (prefer f) to toggle fullscreen on/off.

    line 119
  9. Common:

    When fullscreen toggles, resize the canvas/rendering so visuals and input mapping stay correct.

    line 121
  10. Very specific:

    Create a progress.md file if it doesn't exist, and append TODOs, notes, gotchas, and loose ends as you go so another agent can pick up …

    line 125
  11. Very specific:

    If a progress.md file already exists, read it first, including the original user prompt at the top (you may be continuing another agent's …

    line 126
  12. Very specific:

    Update progress.md after each meaningful chunk of work (feature added, bug found, test run, or decision made).

    line 127
  13. Very specific:

    Prefer a local playwright dependency if the project already has it.

    line 132
  14. Very specific:

    If unsure whether Playwright is available, check for npx:

    line 133
  15. Very specific:

    If npx is missing, install Node/npm and then install Playwright globally:

    line 137
  16. Very specific:

    Do not switch to @playwright/test unless explicitly asked.

    line 141

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Develop Web Game

Build games in small steps and validate every change. Treat each iteration as: implement → act → pause → observe → adjust.

Skill paths (set once)

export AGENT_SKILLS_HOME="${AGENT_SKILLS_HOME:-$HOME/.agents/skills}"
export WEB_GAME_CLIENT="$AGENT_SKILLS_HOME/develop-web-game/scripts/web_game_playwright_client.js"
export WEB_GAME_ACTIONS="$AGENT_SKILLS_HOME/develop-web-game/references/action_payloads.json"

User-scoped skills install under $AGENT_SKILLS_HOME (default: ~/.agents/skills).

Workflow

  1. Pick a goal. Define a single feature or behavior to implement.
  2. Implement small. Make the smallest change that moves the game forward.
  3. Ensure integration points. Provide a single canvas and window.render_game_to_text so the test loop can read state.
  4. Add window.advanceTime(ms). Strongly prefer a deterministic step hook so the Playwright script can advance frames reliably; without it, automated tests can be flaky.
  5. Initialize progress.md. If progress.md exists, read it first and confirm the original user prompt is recorded at the top (prefix with Original prompt:). Also note any TODOs and suggestions left by the previous agent. If missing, create it and write Original prompt: <prompt> at the top before appending updates.
  6. Verify Playwright availability. Ensure playwright is available (local dependency or global install). If unsure, check npx first.
  7. Run the Playwright test script. You must run $WEB_GAME_CLIENT after each meaningful change; do not invent a new client unless required.
  8. Use the payload reference. Base actions on $WEB_GAME_ACTIONS to avoid guessing keys.
  9. Inspect state. Capture screenshots and text state after each burst.
  10. Inspect screenshots. Open the latest screenshot, verify expected visuals, fix any issues, and rerun the script. Repeat until correct.
  11. Verify controls and state (multi-step focus). Exhaustively exercise all important interactions. For each, think through the full multi-step sequence it implies (cause → intermediate states → outcome) and verify the entire chain works end-to-end. Confirm render_game_to_text reflects the same state shown on screen. If anything is off, fix and rerun. Examples of important interactions: move, jump, shoot/attack, interact/use, select/confirm/cancel in menus, pause/resume, restart, and any special abilities or puzzle actions defined by the request. Multi-step examples: shooting an enemy should reduce its health; when health reaches 0 it should disappear and update the score; collecting a key should unlock a door and allow level progression.
  12. Check errors. Review console errors and fix the first new issue before continuing.
  13. Reset between scenarios. Avoid cross-test state when validating distinct features.
  14. Iterate with small deltas. Change one variable at a time (frames, inputs, timing, positions), then repeat steps 7–13 until stable.

Example command (actions required):

node "$WEB_GAME_CLIENT" --url http://localhost:5173 --actions-file "$WEB_GAME_ACTIONS" --click-selector "#start-btn" --iterations 3 --pause-ms 250

Example actions (inline JSON):

{
  "steps": [
    { "buttons": ["left_mouse_button"], "frames": 2, "mouse_x": 120, "mouse_y": 80 },
    { "buttons": [], "frames": 6 },
    { "buttons": ["right"], "frames": 8 },
    { "buttons": ["space"], "frames": 4 }
  ]
}

Test Checklist

Test any new features added for the request and any areas your logic changes could affect. Identify issues, fix them, and re-run the tests to confirm they’re resolved.

Examples of things to test:

  • Primary movement/interaction inputs (e.g., move, jump, shoot, confirm/select).
  • Win/lose or success/fail transitions.
  • Score/health/resource changes.
  • Boundary conditions (collisions, walls, screen edges).
  • Menu/pause/start flow if present.
  • Any special actions tied to the request (powerups, combos, abilities, puzzles, timers).

Test Artifacts to Review

  • Latest screenshots from the Playwright run.
  • Latest render_game_to_text JSON output.
  • Console error logs (fix the first new error before continuing). You must actually open and visually inspect the latest screenshots after running the Playwright script, not just generate them. Ensure everything that should be visible on screen is actually visible. Go beyond the start screen and capture gameplay screenshots that cover all newly added features. Treat the screenshots as the source of truth; if something is missing, it is missing in the build. If you suspect a headless/WebGL capture issue, rerun the Playwright script in headed mode and re-check. Fix and rerun in a tight loop until the screenshots and text state look correct. Once fixes are verified, re-test all important interactions and controls, confirm they work, and ensure your changes did not introduce regressions. If they did, fix them and rerun everything in a loop until interactions, text state, and controls all work as expected. Be exhaustive in testing controls; broken games are not acceptable.

Core Game Guidelines

Canvas + Layout

  • Prefer a single canvas centered in the window.

Visuals

  • Keep on-screen text minimal; show controls on a start/menu screen rather than overlaying them during play.
  • Avoid overly dark scenes unless the design calls for it. Make key elements easy to see.
  • Draw the background on the canvas itself instead of relying on CSS backgrounds.

Text State Output (render_game_to_text)

Expose a window.render_game_to_text function that returns a concise JSON string representing the current game state. The text should include enough information to play the game without visuals.

Minimal pattern:

function renderGameToText() {
  const payload = {
    mode: state.mode,
    player: { x: state.player.x, y: state.player.y, r: state.player.r },
    entities: state.entities.map((e) => ({ x: e.x, y: e.y, r: e.r })),
    score: state.score,
  };
  return JSON.stringify(payload);
}
window.render_game_to_text = renderGameToText;

Keep the payload succinct and biased toward on-screen/interactive elements. Prefer current, visible entities over full history. Include a clear coordinate system note (origin and axis directions), and encode all player-relevant state: player position/velocity, active obstacles/enemies, collectibles, timers/cooldowns, score, and any mode/state flags needed to make correct decisions. Avoid large histories; only include what's currently relevant and visible.

Time Stepping Hook

Provide a deterministic time-stepping hook so the Playwright client can advance the game in controlled increments. Expose window.advanceTime(ms) (or a thin wrapper that forwards to your game update loop) and have the game loop use it when present. The Playwright test script uses this hook to step frames deterministically during automated testing.

Minimal pattern:

window.advanceTime = (ms) => {
  const steps = Math.max(1, Math.round(ms / (1000 / 60)));
  for (let i = 0; i < steps; i++) update(1 / 60);
  render();
};

Fullscreen Toggle

  • Use a single key (prefer f) to toggle fullscreen on/off.
  • Allow Esc to exit fullscreen.
  • When fullscreen toggles, resize the canvas/rendering so visuals and input mapping stay correct.

Progress Tracking

Create a progress.md file if it doesn't exist, and append TODOs, notes, gotchas, and loose ends as you go so another agent can pick up seamlessly. If a progress.md file already exists, read it first, including the original user prompt at the top (you may be continuing another agent's work). Do not overwrite the original prompt; preserve it. Update progress.md after each meaningful chunk of work (feature added, bug found, test run, or decision made). At the end of your work, leave TODOs and suggestions for the next agent in progress.md.

Playwright Prerequisites

  • Prefer a local playwright dependency if the project already has it.
  • If unsure whether Playwright is available, check for npx:
    command -v npx >/dev/null 2>&1
  • If npx is missing, install Node/npm and then install Playwright globally:
    npm install -g @playwright/mcp@latest
  • Do not switch to @playwright/test unless explicitly asked; stick to the client script.

Scripts

  • $WEB_GAME_CLIENT (installed default: $AGENT_SKILLS_HOME/develop-web-game/scripts/web_game_playwright_client.js) — Playwright-based action loop with virtual-time stepping, screenshot capture, and console error buffering. You must pass an action burst via --actions-file, --actions-json, or --click.

References

  • $WEB_GAME_ACTIONS (installed default: $AGENT_SKILLS_HOME/develop-web-game/references/action_payloads.json) — example action payloads (keyboard + mouse, per-frame capture). Use these to build your burst.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.