browser-enginelisted

# Browser Engine — playable games, not tech demos Most AI-built browser games look like a game and play like a screensaver. A rock is drawn but you walk through it. The "physics" is `x += speed` with an `if` that half-works. It runs at 60fps until three enemies spawn, then it's a slideshow. **That is the failure this skill exists to prevent.** A game is not done when it renders. It's done when it's **playable**: solid things are solid, movement feels good, and it holds 60fps under load. Rendering is the easy 20%. ## BANNED (the default AI-game look — never ship any of these) - **Decorative "solid" objects** — a sprite/mesh drawn on screen with no collision body. If you asked for a rock and got a picture of a rock, that's the bug. See [game-collision](../game-collision/SKILL.md). - **Whole-sprite hitboxes in top-down** — making the entire tree image solid so there's an invisible wall around the leaves. Collision is the *footprint*, not the picture. - **Homemade `if (ax < bx + bw && ...)` as the entire physics system** for anything non-trivial. Fine for one AABB check; a trap as a game's collision foundation. - **Framerate-dependent movement** — `x += 5` every frame. Runs double-speed at 120Hz, half-speed under load. Movement must be `* dt` or on a fixed timestep. - **Allocating in the game loop** — `new Bullet()` / `[].filter()` every frame → GC stutter. Pool it. See [game-optimization](../game-optimization/SKILL.md). - **No debug view** — shipping collision you've never *s