A devlog by Neeraj Kotwani, who builds every game on Elipar.
Jungle Quest is the 2D side-scrolling platformer here — temple ruins, moving platforms, ladders, spikes, three lives. It is also the game that became the template for building more of them, which means its structural decisions got re-examined more carefully than most.
Three of those decisions are worth writing down, because each one quietly removes a whole class of bug rather than fixing an instance of one.
Author in a fixed world, scale at the edge
The problem a browser game has that a console game does not: you have no idea what size box you will be given. Here it depends on the player's phone, the orientation, and the frame the site wraps it in.
The tempting approach is to lay levels out in percentages, or in pixels, and adjust. Both are miserable. Percentages make a jump arc depend on the container's aspect ratio — the same tap clears a gap on a tablet and falls short on a phone. Pixels mean every level has to be re-tuned per size.
Instead everything in the game — platform coordinates, gravity, move speed, jump velocity, the player's own dimensions — is expressed in a fixed reference space 540 units tall. A single scale factor is recomputed on resize as the canvas height divided by 540, and every draw call multiplies by it.
The payoff is that the physics never changes. Gravity is 2200 units per second squared whatever the container is; the jump velocity is 820 units; a gap that is four units too wide to clear is four units too wide on every device that will ever load the page. Level design happens once and is correct everywhere.
It also means a level is pure data. A platform is four numbers in a reference space, with no knowledge of pixels, DPI or aspect ratio anywhere in it.
The actor's Y is its feet
A small convention that pays for itself constantly: the player's stored position is the point on the ground, not the centre and not the top-left corner.
Nearly everything a platformer asks about an actor is a question about its feet. Am I standing on something? Did I land? Am I touching the spikes? Which platform am I on? With feet-anchored coordinates those are all direct comparisons against the position you already have.
The collision rectangle is derived when needed — x minus half the width, y minus the full height — so the one place that cares about the body as a box computes it, and nowhere else carries half-height offsets around. Those offsets are the source of the classic platformer bugs: the sprite that sinks into the floor by a few pixels, the one that stands on air, the hitbox that is right for landing and wrong for spikes.
Top-left anchoring is what a canvas API naturally hands you, which is exactly why this is worth deciding deliberately rather than by default.
One input flag per intent, not per key
Input is a small set of named intents — left, right, up, down, jump — and every source writes to the same flags. Keyboard, on-screen touch buttons, and swipes all set input.jump; nothing in the game logic knows which one did.
Without that, the movement code grows conditionals about input sources, and then the touch path and the keyboard path drift. The classic symptom is a game where a feature works with a keyboard and silently does nothing on a phone, because a new branch was added to one and not the other. Since half the players here are on phones, that is not a hypothetical.
One flag per intent also makes the whole game scriptable for free. A test can set a flag and step a frame, which is how the levels get verified without a human playing them.
Why these three are in a skill rather than this post
All of the above now lives in a reusable skill with a working template, so the next platformer here starts from a tested base instead of from an empty file.
That is worth mentioning because it is the honest reason this game has fewer dramatic bug stories than most of the others on this site. Its conventions were settled early and the games built on top of them inherited the fixes. The interesting failures moved downstream — into the games that adapted this one and got one convention subtly wrong.
The clearest example: a submitted exploration game built from a sibling template arrived with its starting camera yaw set to the exact value that faces the camera away from the objective, with a comment saying it faced toward it. Pressing forward walked the player backwards off the map. The template taught the structure and also taught the bug.
Which is the general cost of a template, and the reason the skill documents its own known traps alongside its conventions. A pattern you copy without understanding is a pattern you will copy wrongly.
Jungle Quest is free in a browser, no account, no download. The same jump clears the same gap on every screen.