Making a game that runs well

Why it matters so much here

A Galatrix game runs in a browser, on whatever the player has: a gaming desktop, a school laptop, a phone on a train. That reach is the point of building on the web. It also means the game that wins is the one that feels good on all of them.

The engine does a lot of this for you. It draws on WebGL 2 everywhere and WebGPU where the browser offers it, and its own per-frame work is tuned to avoid the memory churn that causes hitches. The rest comes down to what your game asks the device to do, and the editor gives you the tools to see that and shape it.

What a frame is spent on

Every frame, the device does roughly four kinds of work:

• Drawing. How many separate things are on screen, how many pixels each covers, and how expensive their materials, shadows and effects are.
• Scripts. Everything your behaviours do in their update methods.
• Physics. Bodies, colliders and the queries your scripts make.
• Network, in multiplayer. How much state arrives from the server, and how often.

A smooth game keeps the total inside the frame. The useful question is never “is my game heavy?” but “which of these four is the biggest, and what is it spending on?”

Measure first

The editor has a profiler built in. Open it during a play-test and it shows a strip of recent frames, counters for what is being drawn, the scripts that cost the most, and the spikes worth chasing. The same panel can be opened over a published game too, where it adds a table of the network messages arriving from the server.

Two habits make it far more useful:

• Profile on a modest device. Your own machine is probably the fastest one your game will ever run on. A mid-range laptop or a phone shows you what most players see.
• Look for spikes, as well as averages. A game that averages fine but stalls for a moment every few seconds feels worse than one that is steadily a little slower. The profiler marks spikes so you can find their cause.

The levers

Once you know where the time goes, these are the usual fixes, roughly in order of how often they help.

Draw fewer separate things. Each separate object is its own draw. A scene of many identical coins, crates or trees can turn on instanced drawing, so copies that look alike draw together while each one still moves, collides and runs its scripts.

Set a render budget. The project’s Quality settings cap or coarsen what the GPU spends a frame on: render scale, frame-rate cap, shadow distance and resolution, how many lights cast shadows, particle density, grass and detail distance. Each one starts at “no effect”, so you decide exactly what to trade. Render scale is often the single biggest win on a phone.

Let players choose. Players have graphics settings of their own, and a game can ship its own options menu on top. Someone on an older laptop can turn down what they do not need and keep the game smooth.

Keep scripts light per frame. Work that does not need to happen every frame can run on a timer or in response to an event. Physics belongs in the fixed update, and visuals in the frame update.

In multiplayer, send less. A per-map replication distance updates far-away objects less often. Motion that is a pure function of time, like a spinning obstacle or a moving platform on a loop, can run from the shared room clock on every screen without sending anything at all.

Ship only what the game uses. A standalone export can leave out engine modules your game does not need and minify its scripts, and the result is a single HTML file or a ZIP.

Building it in from the start

Performance is easiest when it is part of the design. A few choices pay off early:

• Strong shapes and lighting. Clear geometry, good lighting and a considered colour palette look great and cost little.
• Reuse. Build a thing once, save it as a prefab, and use it many times. That is also what makes instancing work.
• Set your target device. Decide early whether a phone is a first-class way to play your game, and test on one as you go.

The same applies when you build with AI Chat. Ask it for the game you want, then profile the result like any other map, and ask for the specific change the profiler points to.

Where to go next

When the game is ready to share, publishing and what review means covers how a map goes live. Afterwards, after you publish covers how players find your game and how to keep improving it.