We Put a Tiny Platformer on Our Website

Idea

Some website experiments begin with research, requirements and a sensible measure of success. This one began with a simpler question: could a little holeaf sidekick run and jump around a real web page?

The aim was to learn about basic browser platformer mechanics by building one without a game engine. An AI coding agent received a loose description of the desired result, then we tested whatever came back and adjusted it one problem at a time. The page itself would become the level, with containers and other HTML elements acting as platforms.

Keeping the scope loose was part of the experiment. We wanted to find the problems we did not yet know enough to predict: collision detection, moving through a document, choosing which elements should be solid and making the character feel responsive without turning a small joke into a six-month games project.

Useful for developers and small teams curious about browser games, playful website features and feedback-led AI coding.

Status

You can try it at holeaf.uk/sidekick. The sidekick can move around the page, jump onto parts of the interface and occasionally make a convincing argument against gravity.

It works well enough to communicate the idea and badly enough to remain entertaining. Controls respond, the character moves with the page and many visible elements behave like platforms. It is not polished, balanced or especially exciting, but those were never the useful measures for this version.

The experiment reached the point where further progress would require a more deliberate approach to design, collision rules and testing. For a first pass built around discovery, that is a reasonable place to stop.

Problems Faced

Using a live web page as a platformer level creates a basic disagreement between the browser and the player. The browser sees boxes arranged for reading and clicking. The player sees floors, ledges and suspicious gaps that should clearly be jumpable.

Collision detection exposed that disagreement quickly. If the platform selector includes too many elements, invisible containers and overlapping layout boxes can make the sidekick appear to stand in mid-air. If it includes too few, visible elements that look solid allow the character to fall straight through them.

Responsive layouts add another complication. A platform that sits neatly beneath the character on desktop may move, resize or disappear at a narrower viewport. Collision boxes must be recalculated as the page changes, otherwise the game starts using a map that no longer matches what the player can see.

There is also a limit to how far testing by feel can take the project. Quick manual checks helped us find obvious problems, but they did not produce a clear definition of which page elements should count as platforms or how collisions should behave at their edges. The larger fixes needed more structure than the experiment was meant to receive.

Techniques That Helped

A short feedback loop did most of the useful work. We gave the coding agent a loose target, ran the result in the browser, described the most visible failure and repeated the process. That kept attention on behaviour the player could actually notice.

Testing between each change mattered. Movement code can be technically valid while still feeling unpleasant, and collision bugs often depend on the exact page layout. Frequent browser checks made those failures obvious before more code was built on top of them.

Using the existing DOM as the level also made the first version quick to produce. Standard element bounds can provide enough geometry for an experiment, and the page already contains plenty of possible platforms. The trade-off is that layout markup was never designed to behave like a game map, so broad element selection creates strange results.

For a second version, we could mark intended platforms explicitly with data attributes, recalculate their bounds after layout changes and separate movement rules from page-specific platform discovery. A small set of repeatable collision tests would also help catch cases such as landing on an edge, jumping beneath an element and resizing the viewport mid-movement.

Lessons Learned

More websites should contain tiny games, provided the joke serves the site rather than getting in the visitor's way. A playful interaction can make a page memorable, reveal some personality and create a useful technical exercise at the same time.

AI coding agents are well suited to experiments like this when the goal is discovery rather than production-ready software. A loose prompt can get something moving quickly, but human testing still decides whether the result feels right and where the shortcuts have started to show.

The biggest lesson was that browser game mechanics become much easier to reason about once the page clearly declares what belongs to the game. Reusing every convenient DOM element is fast for a prototype. Explicit platforms, defined collision rules and repeatable tests are the route to a version other people could safely reuse.

Given more time and a respectable pile of LLM credits, this could become a rebrandable sidekick for other developers and small businesses with similar sensibilities. If you are exploring a playful web idea or need guidance turning an experiment into something dependable, get in touch with holeaf.