Turning Our Web Game Prototype Into A Desktop Sidekick

Idea

We already had a small web-based game, so the obvious next question was: could we ask Codex/GPT to turn it into a desktop companion?

The idea was simple enough. Take the existing browser version, wrap it as a desktop app, and see how far an AI coding agent could get without too much hand-holding. A tiny character living on the desktop has a very particular kind of charm. It is part toy, part UI experiment, and part “we probably should have stopped five commits ago”.

For this version, the desktop sidekick needed to behave like the web game but feel more native to the machine. That meant a transparent app window, character movement that was not trapped inside a normal browser rectangle, and some extra behaviour around crawling or climbing along screen edges.

Useful for small teams and developers who want to understand where AI agents help with quick prototypes, and where they still need a human to make the early technical calls.

Status

Working, with a few raised eyebrows.

The desktop version runs, builds cleanly enough, and feels close to the original web game. The main addition is wall movement, so the sidekick can climb and crawl around in a way that makes more sense for a desktop pet than a standard web character.

There are rough edges, though. The app works more like a web project wearing a desktop jacket than a desktop app designed from first principles. It is fine for a benchmark and a bit of fun. It is less fine if you are trying to make something stable, portable, and easy to maintain over time.

Problems Faced

The agent begun by copying the web version a little too faithfully.

It saw JavaScript, browser assets, and an existing game loop, then made the shortest reasonable jump: use Tauri, keep most of the original code, and package the thing. That was not a ridiculous choice. In fact, for a quick proof of concept of gameplay, it was probably the most obvious choice.

The problem was that we did not correct the direction early enough. We treated the exercise as a quick benchmark for AI-assisted game creation, so we let the agent keep moving. The result was a useful prototype, but not necessarily the architecture we would choose if this were a product.

Transparent desktop windows were one sticking point. The app needed the character to appear on the desktop without a visible rectangular frame around it, which meant dealing with platform behaviour rather than normal web layout. Browser CSS can do a lot, but it cannot politely ask the app to stop being a window.

Accurate window position detection was another awkward bit. Once the character starts reacting to screen edges or other windows, the project stops being “just a wrapped website” and starts asking proper desktop questions. Where is the window? What bounds matter? How does the app behave across displays, scaling settings, and different operating systems?

Those are solvable problems, but they are not problems you want to discover by accident halfway through a prototype.

Techniques That Helped

The most useful technique was boring and effective: feeding back our own research for specific desktop behaviours.

Instead of asking broad questions like “how do we make a desktop pet?”, we looked for the individual pieces:

• making a Tauri window transparent
• removing standard window chrome
• keeping click and drag behaviour predictable
• reading window position and size
• detecting screen bounds
• deciding where game physics should stop and OS behaviour should begin

That made the work easier to reason about. Each search had a clear job, and each answer could be fed to the hungry agent and tested against the prototype quickly.

It also helped to separate “game logic” from “desktop wrapper logic” as much as possible. The character movement, animation, and state belong in the game layer. Transparent windows, screen bounds, and platform quirks belong in the app layer. Mixing those together too early is how a fun side project becomes a cupboard full of extension cables.

For AI-assisted builds, the biggest practical win is giving the agent a firm technical frame before it starts writing code. If the stack is fixed, say so. If there are platform targets, say so. If the goal is a throwaway prototype, say so. If it needs to become maintainable later, definitely say so.

The agent can move quickly, but it will usually optimise for the path that looks most available from the files in front of it. That is useful when speed matters. It is risky when the first path is merely convenient rather than suitable.

Lessons Learned

Pick the stack before starting where possible.

That is the main lesson from this one. A clearer technical decision at the start would probably have produced a more stable app, a faster build process, and fewer moments where the prototype had to negotiate with desktop behaviour it did not really understand.

Tauri was not the villain. It did what we asked of it, and for wrapping a web game into a lightweight desktop app it is an obvious option. The issue was that we let the existing codebase choose the direction by gravity, then only started asking product-level questions after the direction had momentum.

With more upfront guidance, we would have been more specific about the shape of the app:

• not to re-use the existing web app code
• which desktop behaviours needed native handling
• which platforms mattered first
• how much polish was expected from the prototype
• where the agent should ask before making stack-level decisions

That is the useful pattern for small business owners and developers using AI tools. The more experience you can put into the brief, the better the result tends to be. Not because the agent needs a novel-length instruction manual, but because a few early constraints can prevent a lot of tidy-looking wrong turns.

AI helped us get a working desktop sidekick quickly. Human judgement was still needed to decide whether “working” was enough, or whether the foundations matched the thing we might want to build next.

If you are experimenting with AI-assisted builds, prototypes, or small product ideas and want a bit of guidance before the technical choices start breeding, holeaf.uk can help you shape the project into something useful.