Draw Road Escape Project Report
1. The Concept
Draw Road Escape is a lightweight, browser-based 2D physics puzzle game where players draw roads and bridges to help a vehicle safely cross gaps, avoid hazards, and reach the finish line.
I chose this concept for a one-day sprint because the core interaction is simple to understand but still requires several important game systems to work together correctly: drawing input, road collision, vehicle physics, obstacles, level progression, responsive landscape gameplay, rewards, and vehicle selection.
The main gameplay loop is:
**Observe the level → Draw a road → Release → Vehicle drives automatically → Avoid obstacles → Reach the finish → Win or retry.
**
The goal was not only to make a functional prototype, but to push it toward the feel of a polished casual mobile game with multiple worlds, vehicles, animated environments, premium UI, sound effects, and smooth touch controls.
---
2. The Stack
The Stack: HTML5, Vanilla CSS, Vanilla JavaScript, and HTML5 Canvas 2D.
No frontend or game framework was used.
The project was built without:
- React
- Vue
- Angular
- Phaser
- Three.js
- Bootstrap
- Tailwind CSS
- MVC frameworks
The game uses JavaScript for the main game loop, drawing system, simplified vehicle physics, collision detection, level data, obstacle logic, rewards, garage system, world progression, audio, and localStorage save data.
CSS handles the responsive interface, landscape layouts, menus, garage, world map, popups, HUD, animations, and mobile safe-area adjustments.
The AI Assist: ChatGPT handled the initial game analysis, gameplay structure, logic planning, UX direction, responsive requirements, progression planning, and detailed implementation prompts. Cursor was used for the development phase, translating those requirements into the actual HTML, CSS, JavaScript, assets, gameplay systems, and iterative fixes.
---
3. The 1 Day Sprint
Morning (Hours 1–3): We started by analyzing the reference concept and identifying the core mechanic: the player should control the environment by drawing the road instead of manually driving the vehicle. We planned the game states, drawing system, road collision, automatic vehicle movement, win/fail conditions, obstacle progression, responsive landscape behavior, and level structure.
We then created the first playable version using HTML5 Canvas and JavaScript. The priority was to make the core loop work:
**Level Start → Draw → Release → Drive → Win/Fail → Retry/Next Level.
**
The early implementation also established multiple worlds, vehicle data, a garage, level selection, coins, and localStorage progression.
Afternoon (Hours 4–6): Most of the development time became an iterative gameplay and UI/UX improvement process. Although the basic game worked, several areas initially felt like a prototype rather than a finished mobile game.
The vehicle looked too static, sometimes appeared to float above the road, and earlier versions had duplicate wheel graphics placed over vehicle images that already contained wheels. We had to repeatedly adjust vehicle scale, wheel-to-road alignment, visual grounding, suspension reactions, road contact, and physics-driven animation.
The road and level layouts also required major improvement. Some levels had oversized gaps, too much empty sky, weak obstacles, or could be completed too quickly by drawing one obvious line. We improved the level progression so early stages teach basic bridges, slopes, landing, hazards, route planning, and moving obstacles before combining mechanics in later stages.
At the same time, the Garage and World Map were redesigned from simple web-style scrolling layouts into more game-like carousel experiences with swipe/drag support, vehicle states, progression, additional levels, and direct navigation into gameplay.
The Finish Line (Hours 7–8): The final hours focused on polish and QA. We improved the Home screen, Garage cards, World Map, victory/failure popups, vehicle presentation, world animations, responsive landscape layouts, and audio planning.
Special attention was given to phone landscape screens to prevent overlapping UI, cut buttons, hidden popup sections, broken carousel layouts, or gameplay elements appearing under the HUD.
We also prepared the project for production cleanup by planning PNG-to-WebP optimization, unused asset removal, audio integration, and final documentation.
---
4. The Roadblocks
Roadblocks: The biggest challenge was not getting the first playable version working; it was making that version feel like a real game.
The first vehicle implementations often looked like static PNG images sliding across the screen instead of objects with weight. Some vehicles had visible wheels already included in their artwork while additional wheel graphics were rendered on top, creating an obvious duplicate-wheel effect. Even after that was corrected, the cars sometimes appeared to float because the artwork anchor, physics body, visible road surface, and wheel-contact positions were not perfectly aligned.
Another major challenge was visual scale. On wide desktop screens, the background could dominate the scene while the car, road, obstacles, and finish became too small. In other versions, the car was oversized compared with the platforms. This required separating game-world scaling from screen-size scaling and repeatedly tuning the camera, vehicle size, platform depth, road thickness, and level composition.
Level design was another roadblock. Simple gaps were easy to generate, but they quickly became repetitive. Some early levels could be solved in only a few seconds by drawing one straight line. We had to redesign progression around meaningful mechanics such as slopes, islands, spikes, saws, low ceilings, moving hazards, and route choices.
Responsive design was also more difficult than expected. The project must work on many phone landscape sizes while keeping the car, finish, HUD, popups, garage cards, world tabs, and buttons visible. Fixing one screen size sometimes created problems on another, so responsive QA became a major part of the sprint.
The final recurring issue was the difference between a technically correct UI and a premium game UI. Several iterations were functional but still looked like website cards, browser scroll areas, or generic modals. The project required repeated refinement of hierarchy, animation, spacing, button states, popups, carousels, and environmental motion.
---
5. Key Takeaways
**What was the part that worked the best?
** The core concept and structural planning. The game has a very understandable loop, and breaking the project into systems such as drawing, physics, level data, vehicles, obstacles, worlds, UI, audio, and saving made it much easier to identify problems during development.
The data-driven approach to vehicles and levels was also useful because additional cars, obstacles, worlds, and stages could be introduced without building completely separate game logic for every piece of content.
**What was the part that worked the worst?
** Visual polish and game feel required far more iteration than expected. A vehicle can technically move correctly while still feeling completely wrong if its wheels do not visually contact the road, its scale is inconsistent, its suspension is static, or the background dominates the gameplay.
The same problem appeared in the UI. A Garage can technically allow vehicle selection while still feeling like a basic horizontal web list instead of a premium vehicle showroom. A World Map can technically contain level buttons while still feeling static and disconnected from the gameplay flow.
The project showed that a playable game and a polished game are two very different milestones.
My final thought: If I had one more day, I would spend most of it on gameplay feel rather than adding many more features. I would continue tuning vehicle physics and suspension, improve road drawing feedback, add more meaningful obstacle combinations, complete vehicle-specific engine sounds, add world-specific music and ambience, optimize all PNG assets into WebP, remove unused project assets, and perform a full responsive QA pass on real mobile devices.
If I rebuilt the project from the beginning, I would establish the final camera scale, vehicle visual-anchor system, road-contact rules, reusable popup system, and responsive landscape safe area much earlier. Those foundations would reduce the amount of repeated visual correction needed later in development.