3D Frogger MP — a classic loop through modern design iteration.

The empty grid first needed something growing on it so it would register as ground to ignore rather than something to cross. The harder part wasn't the geometry. In Three.js many meshes can share a single material, so tweaking one bush at runtime would change all of them at once, and deep-cloning each instance avoided a whole class of shared-state bugs before they came up.

Fences mark the edges you can't cross. The fence is a GLB model that loads asynchronously, and if that load fails on a slow connection or a missing asset, the world falls back to generating a simple fence in code instead. That fallback matters because the edge is communicating a rule, and a missing fence would leave the player unsure where the boundary actually is.

A cel outline around players, vehicles, and logs ties the cartoon look together, but the reason I kept it is more practical, and the tunnels are the clearest case. A car can be most of the way behind a tunnel wall and still be a second or two from hitting you, and the outline draws a rim over the hidden part of the car, so even when the body is occluded the player still gets a clear warning that something is coming. The same pass keeps every object readable against a busy background, but in the tunnels it's doing actual safety work rather than just decoration.

The river side needed its own visual treatment. The waterfalls mark where the playable area ends, and they also just make the river feel like a river. They got built up in layers over time: rock backing first, then moss accents, then an animated water surface over the lip. Later I added a shader-driven pass with a foam line, a parallax sheet, and some drifting mist, and the layer count scales down on weaker hardware so the effect simplifies instead of breaking.

One rule here mattered more than it looks. The squish fires on a movement key press, not on every server position update. A frog riding a log drifts sideways on every tick without the player pressing anything, and if the squish fired on that drift, the animation would be showing intent the player never had. The state machine separates movement the player chose from movement they were carried into, so the squish only plays when the player actually decided to jump.

Late in the project I built the whole sound layer from scratch with the Web Audio API instead of using a sample library: a hop blip, the tongue zip, a squash thud, a death effect, and a goal arpeggio. Synthesizing everything kept the build free of audio dependencies and let me tune each sound to the moment it goes with. One choice that ended up mattering is that only your own frog makes sound. The AI opponents are silent, so a board full of them stays quiet instead of turning into a wall of noise.

Before tuning anything, I built a debug overlay that draws the AI's candidate moves on top of the world along with their scores. With it turned on you can see exactly what the AI is weighing at any moment, and with it off the AI just plays like a normal opponent. That overlay is what made the later tuning possible, since it's hard to adjust behavior you can't actually observe.

Round one slowed the AI's decision interval on logs, since the early version re-evaluated every tick and twitched around in a way that looked more like panic than skill. Round two added some safety thresholds and a backward-movement priority for drifters, because the calmer AI had started over-committing to waiting and would ride a log straight offscreen. Round three pulled the magic numbers out into named constants and settled the main rule: when it's on a log and not drifting, it should strongly prefer to wait rather than move for the sake of moving.

A whole dev menu of toggles effectively turned the game into a test harness. A range input for the AI count and a checkbox to pause log movement let me put one AI or twenty on the board, freeze the logs, and watch the effect of a single scoring change on its own. A grid overlay labels every cell so I could line behavior up against exact coordinates, and an FPS graph in the corner, with green, yellow, and red zones, kept the frame budget on screen while the experiments ran. The tuning rounds above really only came together because those controls were there to lean on.

The default is an isometric view that pulls back and shows the whole board, which helps when you're planning a long crossing. A follow mode sits just behind and above the frog for a closer, over-the-shoulder feel, and an angled mode sits in between the two. A single button cycles through all three, isometric to angled to follow, and its tooltip updates to name the current mode so it's clear what you're switching to.

The isometric view keeps most of the traffic in view while still keeping the player pointed toward the goal, so you can read the board and plan a crossing instead of reacting one row at a time. The angle also keeps the outer edges of the map out of frame, the parts I didn't want to spend detail on, so the view stays on where the play actually happens. And it puts a different enough spin on the original top-down Frogger to feel like its own thing rather than a straight copy.

The follow camera is the more immersive option, and some players will prefer it, but it only shows the next row or two of the board. That makes it better as something you switch to once you know the layout than as the view a new player has to plan a whole crossing from, so it sits one button-press away rather than being the default.

Before the game starts, players land in a lobby that shows the current roster, a copy-able invite link, and inline fields to edit their own name and color. The idea is to make a cold start feel like an actual room rather than an empty board: you can see who else is there, grab a link to pull a friend in, and set up your frog while you wait, instead of sitting on an empty board wondering whether anything is happening.

On a phone there's no keyboard, so a D-pad overlay handles directional input through touch events, and it also responds to mouse events so the same control works for a desktop developer testing in emulation. It sits behind a settings toggle so desktop players can hide it completely.

The tongue attack knocks an adjacent frog back, and since it's the one player-versus-player action in the game, it needed its own button on mobile. The actual design decision was the cooldown length. If it's too short, players just spam each other off the logs constantly, and if it's too long, nobody bothers using it. The value I landed on is short enough to feel responsive but long enough that firing it is a real decision, and the button reuses the same event handling as the D-pad so the two don't interfere with each other.