Ridge Runner Relay Project Report
1. The Concept
Ridge Runner Relay is a browser-based 2D physics platformer inspired by classic side-scrolling bike games. Players ride a bicycle across handcrafted obstacle courses filled with ramps, water hazards, TNT crates, spikes, moving platforms, conveyors, and checkpoints. Success depends on balancing the rider, controlling speed, and carefully timing jumps rather than simply holding the accelerator.
I chose this project for a one-day sprint because physics games are deceptively difficult to build. While the mechanics appear simple, they require stable collision detection, responsive controls, fair level design, and smooth camera behavior. This made the project an excellent stress test for a multi-AI workflow where one AI planned the game while another generated the implementation.
---
2. The Stack
The Stack: HTML5, Vanilla CSS, JavaScript, and Three.js.
The AI Assist: ChatGPT handled the game planning, gameplay systems, UI/UX direction, level progression, physics balancing recommendations, and technical handoff documentation. OpenAI Codex handled the implementation, transforming the design documents into a playable browser game using a single HTML, CSS, and JavaScript codebase without MVC or external frameworks.
---
3. The 1 Day Sprint
Morning (Hours 1–3):
We began by researching classic physics bike games and identifying the core gameplay loop: balance, acceleration, braking, leaning, checkpoints, and obstacle navigation. The first few hours focused on designing the game architecture, player controls, camera behavior, HUD layout, level progression, and a reusable obstacle system that could support ramps, moving platforms, TNT, spikes, water, and future mechanics.
Afternoon (Hours 4–6):
The implementation phase started with Codex generating the initial game engine. While the core systems came together quickly, many gameplay problems appeared during testing. Physics occasionally became unstable, the camera drifted away from the player, obstacle spacing created impossible jumps, rider animations felt static, and many generated levels reused nearly identical layouts. Considerable time was spent refining collisions, camera movement, responsive UI behavior, and improving overall game feel.
The Finish Line (Hours 7–8):
The final hours focused on polish instead of adding new features. We improved the HUD, redesigned menus and popups, implemented checkpoints, refined the garage and level-selection interface, optimized responsive layouts, upgraded sound effects, improved loading screens, balanced obstacle placement, and repeatedly tested every level to eliminate impossible sections. While additional polish is still possible, the final result became a complete and playable prototype with multiple handcrafted levels.
---
4. The Roadblocks
Roadblocks:
The largest challenge was translating design intent into reliable gameplay. Although ChatGPT produced detailed gameplay specifications, Codex occasionally interpreted them too literally or omitted important design principles such as fairness, responsive level progression, and polished UI hierarchy.
Physics-based gameplay also exposed problems that traditional applications rarely encounter. Small adjustments to ramps, jump distances, collision boxes, or wheel placement often caused entire sections of a level to become impossible. Many generated levels initially reused similar terrain, obstacle patterns, and layouts instead of creating unique gameplay experiences.
Additional challenges included:
- Balancing bicycle physics without making controls feel frustrating.
- Designing levels that always provide at least one fair solution.
- Creating responsive layouts that work across desktop and mobile devices.
- Integrating illustrated assets while preserving invisible collision geometry.
- Preventing duplicate popups, broken loading screens, and inconsistent UI components.
- Making rider animations and bicycle movement feel natural instead of static.
Because of the strict one-day time limit, several advanced features—including richer rider animation blending, dynamic obstacle interactions, and more sophisticated environmental effects—were postponed for future development.
---
5. Key Takeaways
**What worked the best?
**
The planning phase was the project's biggest success. Defining gameplay systems, reusable obstacle types, progression rules, level validation guidelines, UI hierarchy, and technical architecture before coding dramatically reduced development time. ChatGPT produced detailed specifications that acted as a blueprint throughout the sprint.
**What worked the worst?
**
Generating polished gameplay automatically proved much harder than generating code. Codex could quickly produce functional mechanics, but it frequently required multiple refinement passes to improve level fairness, responsive design, UI polish, rider animation, bicycle positioning, obstacle spacing, and overall game feel. Physics games demand extensive playtesting that cannot be fully replaced by code generation alone.
My final thought:
If I had one more day, I would focus entirely on polish rather than adding features. My priorities would include improving rider animation, refining bicycle suspension, expanding obstacle variety, introducing more dynamic environmental interactions, enhancing audio with adaptive ambient sound, and making each of the ten levels visually and mechanically unique. The project demonstrates that modern AI tools can dramatically accelerate game development, but physics tuning, level design, and gameplay polish still benefit greatly from careful human iteration and repeated testing.