Hey Devs! I'm Ludy. Over the weekend, I decided to step away from my usual SaaS projects to build something purely for fun: a lightweight, instant-play browser game. I wanted to create a weather-themed puzzle game where players drop and merge elements—from tiny raindrops and sunny clouds all the way up to blizzards and massive typhoons.
You can play it instantly here: dropmergegame.com
Here is a quick look behind the scenes of how I built it, the tech stack I chose, and the challenges I faced along the way.
The Tech Stack
To keep the game incredibly fast-loading and accessible on both desktop and mobile web views (without any install barriers), I kept the stack as minimal as possible:
- Renderer: HTML5 Canvas API (no heavy heavy engines like Phaser to keep the bundle size tiny)
- Physics Engine: Matter.js (for managing 2D rigid body physics, gravity, and elastic collisions)
- State Management: Vanilla JavaScript with a simple custom Pub/Sub event emitter
The Big Challenge: "Physics Explosions" During Merging
One of the trickiest parts of physics-based merging games (often inspired by Suika Game mechanics) is handling the transition when two identical elements collide and merge into a larger one.
In early builds, when Element A and Element B collided, spawning the larger Element C at the midpoint would occasionally overlap with nearby elements. Matter.js would try to resolve these sudden overlaps by pushing elements away at infinite velocities—resulting in elements literally flying off the screen!
To fix this, I implemented a custom merge handler:
- Temporarily disable physics collisions for the merging pair.
- Animate a quick scale-down of the original elements while spawning the new, larger element at
scale = 0.1. - Rapidly scale the new element up to its actual size over 100ms while using a custom sensor to gently push adjacent bodies away before solidifying the collision bounds.
Mobile Performance Optimization
Mobile browsers are notoriously unforgiving with canvas rendering loops. To hit a consistent 60 FPS on older devices, I had to:
- Implement dynamic resolution scaling based on
window.devicePixelRatio. - Use offscreen canvas rendering to cache static assets (like the background grids and UI elements).
- Limit the maximum number of active physics bodies on screen to 12.
Building this was a refreshing break from typical database-heavy development. Check it out, try to reach the 12th tier typhoon, and let me know your thoughts on the physics tuning in the comments!
Top comments (0)