Ink Rider Project Report
1. The Concept
Ink Rider is a lightweight, web-based 2D physics drawing puzzle game where players create their own vehicle by drawing a single line, attach wheels automatically, and let physics determine whether the vehicle can overcome obstacles and reach the finish line.
I chose this concept for the one-day sprint because it combines simple player input with more challenging game systems such as drawing conversion, vehicle physics, moving obstacles, camera behavior, responsive layouts, level progression, and quick retry mechanics.
The main gameplay loop is:
Observe → Draw → GO → Watch Physics → Retry or Finish
The project contains 30 levels divided into five themed worlds, with increasing difficulty, different obstacle types, medals, background themes, sound effects, music, and saved progress.
2. The Stack
The Stack: HTML5, Vanilla CSS, JavaScript, HTML5 Canvas, Matter.js, and LocalStorage.
The AI Assist: ChatGPT handled the initial game analysis, gameplay structure, physics logic, UI/UX planning, responsive strategy, level progression, QA requirements, and technical prompts. Cursor/OpenAI Codex was then used during the coding phase to translate those requirements into the working game, fix bugs, improve physics behavior, polish the UI, and optimize the final project.
3. The 1 Day Sprint
Morning (Hours 1–3): We began by analyzing the reference gameplay and identifying the most important mechanic: the player should not directly drive the vehicle. Instead, the player's drawing becomes the vehicle body, with wheels attached to the first and last drawing points. We planned the main state flow—Drawing, Ready, GO, Simulation, Success, Failure, and Retry—and then started implementing the drawing system, ink limit, Matter.js physics, wheel constraints, and basic Level 1 gameplay.
The first major goal was to make the core loop work correctly:
Draw → GO → Vehicle Moves → Reach Finish
Afternoon (Hours 4–6): The main coding and debugging phase focused heavily on physics and game feel. Early versions became unstable after pressing GO. Cars could shake, jump, render duplicate chassis shapes, spawn with incorrect wheel positions, or behave unpredictably.
We fixed the drawing-to-physics transition by simplifying drawing points, creating the vehicle only once per attempt, separating visual drawing from invisible physics collision geometry, improving wheel constraints, preventing self-collision, smoothing motor startup, and improving camera movement.
After the core physics became stable, we worked on UI/UX. The Home screen, Gameplay HUD, Level Select, Settings, popups, buttons, drawing area, finish indicator, and responsive layouts went through several iterations. A major challenge was preventing the desktop design from becoming too large or square while also making the complete game work properly in landscape mode on phones.
The Finish Line (Hours 7–8): The final hours focused on polish and QA rather than adding more features. We improved the five world background themes, premium Home buttons, level cards, Settings and popup design, gameplay backgrounds, music, sound effects, obstacle feedback, mobile landscape support, and responsive typography.
We then concentrated on testing the complete gameplay flow, checking obstacle reset behavior, camera smoothness, collision stability, Retry reliability, level progression, LocalStorage, audio settings, and performance across desktop and mobile screen sizes.
4. The Roadblocks
Roadblocks: The biggest roadblock was balancing physics stability with UI/UX and responsive design.
The first major issue appeared during the Draw → GO transition. The player's drawing sometimes generated unstable physics geometry, oversized or incorrectly positioned wheels, duplicate visual chassis elements, and unpredictable movement. Fixing this required separating rendering from physics and carefully controlling how the vehicle was created.
Another major roadblock was responsive design. Several attempts to make the game support every screen size caused new problems such as:
- Gameplay becoming too small on large displays
- Incorrect square layouts
- Excessive empty space
- Camera framing cutting off the drawing area
- Controls overlapping terrain
- Desktop screens incorrectly showing the Rotate Device overlay
- Mobile landscape layouts becoming clipped
- White scrollbars appearing on game panels
- UI elements becoming either too large or too small
Instead of continuing to patch individual CSS problems, we had to establish clearer rules for desktop scaling, mobile landscape behavior, camera framing, safe areas, and responsive UI sizing.
Level design also required careful testing. Moving platforms, rotating obstacles, crushers, bridges, boosts, and other physics objects had to move smoothly and reset correctly after Retry. Because the game depends heavily on physics, even small timing or collider problems could make a level feel unfair.
5. Key Takeaways
What was the part that worked the best? The strongest part was defining the core gameplay loop before adding visual polish. Once the project focused strictly on Draw → GO → Move → Retry, it became much easier to identify which systems were actually causing problems. Separating visual drawing from simplified physics geometry was especially important for making the vehicle movement stable while preserving the player's original drawing.
What was the part that worked the worst? The most difficult part was repeatedly changing UI/UX and responsive behavior while the game was still evolving. Broad requests such as "make it more premium" sometimes improved one screen but damaged another screen or introduced new responsive problems. The project became much more manageable when improvements were restricted to one specific area at a time, such as Gameplay, Home, Levels, Settings, camera framing, or mobile landscape support.
Another important lesson was that physics puzzle games need extensive real playtesting. A level can look correct in code but still feel unfair, inconsistent, repetitive, or impossible when played.
My final thought: If I had one more day, I would spend almost all of it on level-by-level QA and physics tuning rather than adding new features. I would test all 30 levels repeatedly with different vehicle shapes, optimize every moving obstacle, improve difficulty progression, fine-tune the camera, balance music and sound effects, and profile performance on lower-powered mobile devices.
If I rebuilt Ink Rider from the beginning, I would lock the responsive architecture and core physics much earlier, complete one polished benchmark level first, and only then expand the same proven systems across the remaining levels. This would reduce unnecessary redesign cycles and make the development process faster, safer, and more consistent.