My recent browser projects take different forms: an island defense game, an atmospheric puzzle game, and an ink-inspired action prototype.
Looking across them, I find it useful to separate two questions. Does the program behave as intended? Can someone opening it for the first time understand and complete a meaningful action?
A striking image can earn attention. The next input, the explanation of a failure, and the cost of trying again determine whether the player stays.
A power line explains a rule
In Last Beacon, towers need a connection to the lighthouse's grid, and limited capacity determines which facilities can operate.
A tower that does not fire can leave the player with several hypotheses: it is disconnected, the grid lacks capacity, or there is no suitable target. A stationary tower alone cannot explain which condition matters.
Connection lines, offline markers, and capacity information are therefore part of the game's interface to its rules. Selling a relay recalculates downstream power, and the feedback needs to help the player understand what changed. Project rules
That shifts the test away from merely checking that enemies lose health. I also want to know whether building, connecting, observing, and adjusting form an understandable loop from the first session.
A puzzle game should preserve the player's place in a thought
Silent Meridian has four chapters and thirteen puzzles. Players move between the Present and its Echo to interpret different states of the same world.
As puzzles accumulate, remembering the investigation becomes part of the experience. Where was that symbol? Which combination has already been tested? Does a hint add information or repeat what the player knows?
The evidence journal, personal notes, progressive hints, and local saves address that burden. They help a player continue reasoning. Changing the language should likewise preserve progress rather than forcing a choice between understanding the text and keeping the current state. Features and save behavior
The storage boundary belongs in the explanation too. Progress lives in the current browser and does not automatically move across origins. Starting without a previous save after changing browsers or domains is different from the game having no save feature.
Action games expose the gap between visuals and rules
Ink Blade is currently a playable 2.5D action prototype. It combines layered character art with a Three.js / WebGL 2 scene and independent fixed-step combat logic.
Small inconsistencies become conspicuous in an action game. A blade appears to cross an enemy without dealing damage. A character moves while the feet seem to tread in place. An input fails before the preceding animation makes its timing readable.
More particles cannot resolve those mismatches. The important relationship is between input, action, and outcome: when a combo can continue, why a parry succeeds, and what opportunity appears after an enemy loses its stance.
Automated checks can inspect combat state and numbers. Playing the game is still necessary to assess whether those changes are visible and readable at the intended pace.
The repository keeps the prototype's limits explicit. Touch controls need more testing on real devices; controller support, saves, and equipment progression are not implemented. Code-driven deformation of layered illustrations is also different from hand-drawn animation frames. Implementation and current limits
Calling a prototype a prototype gives the next iteration an honest starting point.
Test a whole piece of the experience
For a small browser project, I would rather finish a short, complete play path before expanding the amount of content:
- Enter from the initial page without relying on an explanation from the author.
- Complete a core action through normal inputs and inspect whether the feedback explains the result.
- Fail deliberately and check the restart point and recovery cost.
- Pause, leave the window, and return.
- Check whether language, hints, and saving preserve the relevant progress.
The emphasis changes by project. Tower defense needs legible dependencies. Puzzle play needs usable evidence. Action needs timing and reliable correspondence between movement and combat.
AI assistance can contribute code, assets, and exploratory ideas. Finishing an initial generation is rarely enough to establish that the experience is complete. I find it more useful to put assistance inside a practical cycle: build a playable segment, go through it, identify a specific rough edge, and return to the rules and implementation.
These projects still have room to improve. The most useful progress is being able to describe what the next iteration should change, beyond asking for a richer-looking screen.