opengame-browser-game-builder

OpenGame Browser Game Builder

Turn a game idea into the smallest playable browser experience that proves its core fantasy. Prefer a coherent game over a polished static scene or an overgrown feature list.

Official website: https://opengame.app/

Pick a working mode

• Plan when the user needs a concept, MVP scope, or implementation brief.
• Build when the user asks for a prototype or provides a project to change.
• Improve when a playable game exists and needs better controls, feedback, progression, performance, or visual clarity.

Ask at most two decisive questions if a missing choice would change the result materially. Otherwise state sensible defaults and proceed.

Shape the playable vertical slice

Before coding, establish a compact build contract. Keep it in the response unless the target project already has a place for a game spec.

• Player fantasy: one sentence describing what feels rewarding.
• Core loop: 2–4 repeated player actions with a visible consequence.
• Camera and controls: a readable viewpoint plus keyboard, pointer, and touch behavior appropriate to the game.
• Win, loss, and restart: explicit rules that can be reached in a short session.
• Content minimum: one player ability, one meaningful obstacle or opponent, one goal, and one progression or scoring signal.
• Visual direction: palette, silhouettes, contrast, and one memorable moment; choose procedural visuals when supplied assets are not necessary.
• Out of scope: features intentionally deferred until the loop is fun.

For a first prototype, target a player who can understand the goal quickly and reach a win or loss state in roughly one to three minutes.

Choose the browser runtime

• Use Canvas, DOM, or SVG for 2D arcade games, platformers, puzzles, card games, and UI-heavy interactions.
• Use Three.js or an existing 3D runtime when spatial navigation, camera framing, lighting, or depth is essential to the requested experience.
• Reuse the target project's real toolchain and dependencies. Do not invent a package, asset bundle, or engine that is not available.
• Prefer a self-contained index.html only when the user requests a standalone artifact or the project has no existing app structure.