Why Web Technologies

Every game project eventually gets asked why it is not using one of the big obvious engines. It is a fair question: engines solve real problems. They also arrive with a house style, a workflow, and the quiet promise that your weird little idea can be made to look like everyone else’s weird little idea. Look around long enough and you will find plenty of people complaining that Unreal Engine games all have the same look, which is unfair to the engine, but a reality.

Candlemark is a roguelite stealth game about one night in a city: loot what you can, read the patrols, leave before sunrise, and pretend you know what you do. I am building it with web technologies because the browser is a ridiculous place to make a 3D game, and ridiculous places are good at exposing the real constraints.

Constraints Make Better Shapes

three.js is a lower-level tool. That means more decisions, more plumbing, and more soul.

A stealth game lives or dies on its vibe: light, darkness, silhouettes, readable movement, and the tiny visual lies that tell the player what is safe. If I want Candlemark to have its own visual identity, I would rather fight the renderer directly than spend years sanding the default personality off a larger engine.

three.js might lack the optimizations of AAA engines, and the web might not be the most performant platform. But the truth is that I am not chasing photorealism. I could use any engine I want, and I still would not be displaying a full open-world city with dynamic lights everywhere at 120fps. three.js is not going to be the bottleneck, it is just going to show the limits of my execution sooner.

Constraints are not a punishment. They remove a lot of expensive convenience and leave behind the parts that actually need taste.

Feedback Should Be Immediate

The web is very good at one thing: making changes show up before your doubt has time to put on shoes.

three.js and React make it possible to build an iteration loop where the scene stays alive while the code changes around it. With hot module replacement, I can tune systems, adjust components, and eventually hot swap models inside the running scene without performing the sacred ritual of stop, rebuild, relaunch, regret.

For a game where the smallest difference in spacing, timing, or light can change the whole feel of a room, that matters. Waiting is where ideas go to become Jira tickets.

Debugging Is Already There

Browser debugging tools have become absurdly good over the last decade, presumably by accident while everyone was trying to make dropdown menus profitable.

That matters for a web game because the same tools used to profile ordinary web applications can be aimed at the game loop. Frames, memory, network, workers, GPU pressure, React updates: it is all sitting there in the same place.

Tools Are Part of the Game

We spent decades being forced to build interfaces for every human activity, including several that should have been stopped by a committee.

People often confuse a game engine with a renderer. But what makes a game work is a pile of pieces: sound, physics, editors, AI, and every other small system that quietly waits to ruin your evening. I plan to build a specialized tool every time I need one.

Blender is excellent open-source software, and I could use it. That is exactly the problem here: Blender allows anything. I want tools that limit my possibilities so I have something to push against. My modeler allows only the things Candlemark needs, in a concise and expressive way.

Building my own tools lets me integrate them deeply with my renderer. In the modeler, I can mark which faces should generate a baked lightmap, define what kind of surface they are, and feed that information directly into the editor. The editor can then show the available surfaces on that model and let me choose the textures I want.

React is good at this kind of UI. The browser is good at distributing it. The same stack that runs the game can run the tools around it.

Portability Is Not Romantic, But It Matters

If a recent Chrome with WebGPU can run, Candlemark should have a path to run there.

This does not make performance free. Nothing does. It does mean the project starts from a runtime that already knows how to travel. Desktop, laptop, maybe handheld, maybe some future slab of glass pretending to be a computer. The browser is already there, waiting politely, consuming all available memory like a professional.

The Bet

The web is not the easiest way to make a stealth game, that would be a stupid bet. The bet is that constraints, instant feedback, debugging, custom tools, and portability are worth more to Candlemark than the comfort of a heavier engine. The web gives me fewer defaults and weirder constraints. For this project, that feels about right.