Arcade Crossing Game

Start with the player goal, camera angle, control scheme, lane types, and failure condition. Then specify how traffic moves, what counts as a safe row, how score increases, and which pickups change the route or risk calculation. That gives SEELE enough structure to generate a playable first pass instead of a vague scene.

Yes, if you name them clearly in the prompt. Ask for concrete effects such as shields, slow-motion, score multipliers, magnets, or temporary invulnerability, then define how they spawn and how long they last. The clearer the pickup rules are, the easier it is to review whether the run feels skill-based instead of random.

The goal of this page is a real playable Three.js prototype that you can run, test, and refine. You should still verify collisions, input handling, difficulty, responsive layout, and performance yourself, but the output should be an editable gameplay draft rather than a decorative static concept.

No. The proof image is an independently captured run of GeekBoySupreme/crossy-road, an MIT-licensed open-source Three.js Crossy Road clone. It is shown only as a verifiable genre reference for lane-crossing traffic-dodging gameplay, and it does not represent a SEELE-generated game, a SEELE product screenshot, or proof of your own pickup implementation.

A human should review collision fairness, pickup readability, control responsiveness, difficulty ramp, mobile behavior, accessibility, audio feedback, and asset licensing. You also need to confirm that the traffic pacing and reward cadence feel intentional, because a playable prototype can still be frustrating if the gaps and power-up timing are poorly tuned.

Run short playtests and change one variable at a time: traffic speed, lane density, safe-row spacing, pickup frequency, score rewards, or camera distance. Record where players fail, which pickups they ignore, and whether retries feel immediate. That makes the second and third SEELE iterations much more targeted than simply asking for a better game.