Ryan arcade builder

Original authored for Ryan's arcade, with AI assistance, from the project's own browser-game workflows. Not a downloaded skill or a claim of personal human authorship. No third-party skill text is imported. This publication does not grant a blanket license to the site's code, art, brands, or other content.

Scope

Use in Ryan's portfolio web project for /arcade.html, /pimp-my-ride.html, and /drive-my-ride.html. These public instructions are reusable; they contain no account IDs or credentials. Discovery, game play, and skill downloads are public; verified accounts are required only for community ride sharing and the showroom.

Procedure

1. Read the specific game's HTML, controller, pure simulation module, and corresponding tests files before changing behavior. Keep the physics/model layer separate from account, DOM, persistence, and rendering code. Use the existing local public/vendor/three/three.module.js import when extending existing renderers; do not introduce a CDN dependency or copy vendor code into skills.
2. Keep game play independent of account state. Verified Google/GitHub sign-in is required only for community ride sharing and showroom reads; await accountReady, reject stale asynchronous verification after account changes, and keep the Firestore rules and controller checks. A sign-in failure must not block a default ride, local customization, or a race.
3. Keep all JavaScript and CSS external for Firebase Hosting's strict CSP. Do not add inline event handlers, inline executable scripts, eval, or a new remote script origin to make a feature work.
4. Design for a narrow mobile viewport first, then landscape and desktop. Make canvas sizing follow its container, keep HUD text readable, respect safe areas, and test that controls do not overflow or cover the course. Support keyboard and touch together. Release held input on blur, visibility changes, pointer cancellation, account changes, and leaving play.
5. Reuse shared ride data rather than creating a second schema. Read public/ride-data.js before extending garage or race features. Use newRide, validateRide, serializeRide, and parseSavedRide; never trust saved gallery data simply because it came from the database.
6. Preserve model provenance. The cars are detailed GLBs in public/models/rides/: two original Blender-authored models and one adapted CC BY 4.0 concept car, recorded in provenance.json and credits.html. Follow the ride-customizer skill for creating or replacing vehicle assets, hometown-racer for racing, and eat-my-face for the maze game. Any new model needs documented source, author, license, permitted redistribution, attribution, and texture rights. Do not invent permission, claim vehicle-brand endorsement, or publish third-party skill collections.
7. Prefer deterministic, pure simulation tests before browser checks. From web, run node --test tests/arcade.test.js tests/arcade-screen.test.js tests/ride.test.js tests/ride-model.test.js tests/ride-ui.test.js tests/drive.test.js. Run account tests when access changes: node --test tests/account.test.js. Consult existing emulator setup before running Firestore-rule tests; never use production data as test fixtures.
8. Verify signed-out, unsupported-provider, failed-verification, signed-in, sign-out-during-load, keyboard, touch, and narrow-screen states. Check browser errors, canvas resize, pause/resume, and input cleanup. When working on racing, test AI finish progression, not just a moving car.

Acceptance

Report the behavior changed, targeted test commands/results, viewport checks, and any unverified account/emulator cases. Never imply an emulator test proved live authorization or deploy/bill without explicit authorization.