DEV Community: PatilRB

Tap-to-move is harder than it looks

PatilRB — Wed, 26 Aug 2026 08:57:50 +0000

Tap-to-move is the first input scheme most 3D web games implement and the first place they get subtly wrong. Not broken — wrong in ways that feel like the game is cheap.

The naive version is four lines and it mostly works:

canvas.addEventListener('pointerdown', e => {
  const ndc = toNDC(e.clientX, e.clientY);
  raycaster.setFromCamera(ndc, camera);
  const hit = raycaster.intersectObject(ground)[0];
  if (hit) player.target.copy(hit.point);
});

Here is what that misses, roughly in the order you'll discover it.

Normalised device coordinates need the canvas, not the window

clientX is relative to the viewport. The raycaster wants coordinates relative to the canvas, in the range −1 to 1, with y flipped. If your canvas is inset, letterboxed, or sits below a header, using window dimensions puts every tap at a small offset from where the player aimed — and it will feel like input lag rather than a mapping error.

const r = canvas.getBoundingClientRect();
const x = ((e.clientX - r.left) / r.width) * 2 - 1;
const y = -((e.clientY - r.top) / r.height) * 2 + 1;

Recompute the rect on resize and on orientation change, or cache it and invalidate — reading it per tap is fine, reading it per frame is not.

Raycast a plane, not the ground mesh

Intersecting the visible ground works until the ground has holes, decorative geometry, or a mesh whose collider does not match its silhouette. Then taps near edges do nothing, which reads as unresponsiveness.

Raycast a mathematical plane at the gameplay height instead. It always hits, it costs nothing, and it decouples input from art.

`pointerdown`, and only pointer events

Not mousedown plus a touch path bolted on later. pointerdown covers mouse, touch and pen in one code path. Also set touch-action: none on the canvas, or mobile browsers will helpfully scroll and pinch-zoom your game while the player tries to play it.

Move with delta time, and check the unit

const step = speed * dt;              // dt in SECONDS
if (player.position.distanceTo(target) > step) {
  player.position.addScaledVector(dir, step);
} else {
  player.position.copy(target);       // snap, or you oscillate forever
}

Two traps in four lines. THREE.Clock.getDelta() gives seconds; a raw requestAnimationFrame timestamp gives milliseconds, and passing the wrong one produces motion that is wrong by a factor of 1000 without erroring. And omitting the snap leaves the player jittering around the target forever, because it can never land exactly.

The part that makes it feel good

Everything above makes tap-to-move correct. What makes it feel deliberate is the acknowledgement: a small burst at the tap point, fired on pointerdown, before the character has moved at all.

That single effect does more for perceived responsiveness than any amount of movement tuning, because it answers the player's real question — did it hear me? — in the same frame as the input.

This tutorial goes end to end on the mobile-first version: renderer with a capped pixel ratio, scene and camera, the loop, pointer input, and a tap-burst effect wired into the same per-frame update.

What I'd tell someone starting today

Write the input layer yourself and get the mapping right, because it is small and everything else sits on top of it. Then borrow the feedback layer, because hand-rolling a particle system teaches you about object pooling rather than about your game.

Zero allocation is a habit, not an optimisation pass

PatilRB — Wed, 26 Aug 2026 08:51:26 +0000

"We'll optimise later" works for most code and fails specifically for allocation, because by the time you notice, the allocations are structural.

A garbage collection pause does not show up as a slow function. It shows up as a stutter with no obvious owner, at a moment unrelated to whatever caused it, and profiling tells you the collector ran — not who fed it. The fix is not a pass you schedule; it is a habit you hold in the paths that run every frame.

Hot path, cold path

The whole discipline rests on one distinction. A hot path runs every frame, or per particle, per entity, per collision. A cold path runs on load, on level start, on menu open.

Cold paths can allocate freely. Write the clear, idiomatic version — map, filter, spread, objects wherever they help.

Hot paths get treated as if allocation were a correctness bug. Not because a single object matters, but because a single object multiplied by 60 frames and 500 entities is 30,000 objects a second, and that is a collection you scheduled without meaning to.

The four habits

Indexed loops instead of iterator chains. arr.map(f).filter(g) allocates two intermediate arrays per call. In a per-frame path, write the loop.

// cold path: fine
const visible = entities.filter(e => e.alive).map(e => e.sprite);

// hot path: reuse a caller-owned buffer
function collectVisible(entities, out) {
  out.length = 0;
  for (let i = 0; i < entities.length; i++) if (entities[i].alive) out.push(entities[i].sprite);
  return out;
}

Scratch objects instead of fresh ones. Vector maths is the usual culprit — every add() that returns a new vector is an allocation. Keep module-level scratch instances and write into them.

Bounded, prewarmed pools for anything bursty. Particles, projectiles, damage numbers. Prewarm at load so the first burst does not allocate, and bound the pool so a pathological case degrades instead of exploding.

Update renderer objects, never recreate them. Recreating a sprite or a material per frame is the most expensive version of a cheap operation, and it is easy to do accidentally inside a React-style render function.

The part that is not about allocation

Two settings will outweigh all of the above on mobile, and both are one line:

Cap the device pixel ratio. A phone reporting DPR 3 renders nine times the pixels for a difference nobody perceives on a moving particle. Math.min(devicePixelRatio, 2).
Bake vectors into atlases. Procedural drawing each frame is the most expensive route to a shape you could have drawn once at load.

The full write-up is here — the pooling patterns, the draw-call guidance, and the debugging order to follow when something already stutters.

The rule I would actually enforce

When a game already stutters: profile on a real phone, find the root cause, fix it. Do not fake the win by quietly shrinking the feature.

That last clause is the one worth taping to a monitor. Halving a particle count improves the frame time and makes the game worse, and because nobody writes down that the trade happened, six months later the effect is "just how it looks" — while the uncapped DPR that actually caused it is still there, waiting for the next feature.

The reward moment is the product

PatilRB — Wed, 26 Aug 2026 08:47:19 +0000

Free-to-play UI is not decoration. It is the reward loop made visible, and the moment a player taps "claim" is closer to being the product than anything in your feature list.

That sounds like marketing copy until you look at what actually differs between a game people keep opening and one they don't. It is rarely the systems. It is whether collecting something feels like collecting something.

The reward moment, decomposed

A reward tap that reads well is doing four things in about 400 milliseconds:

Acknowledging the input — something happens on press, not on release, so the tap never feels ignored.
Showing the value — the thing you earned is visibly a thing, moving from where you claimed it to where it lives.
Marking significance — scale, timing and particle density say "this was a big one" or "this was routine".
Getting out of the way — it resolves fast enough that a player tapping through twenty of them is not fighting your animation.

Point 4 is the one that gets missed. Juice is easy to add and hard to bound, and a reward sequence that delights on first sight becomes the thing players complain about on day thirty.

Where the effort actually goes

Not into the particle system. Into the timing relationships between the layers:

onClaim() {
  spark(button.position);              // t=0    input acknowledged
  setTimeout(() => fountain(tray), 80); // t=80  value appears, after the spark reads
  setTimeout(() => countUp(amount), 140); // t=140 number climbs into place
}

Those offsets are the design. Fire everything at t=0 and it reads as one undifferentiated flash; space them too far and it reads as lag. The 60–150 ms band is where "responsive but legible" lives, and finding it is iteration, not calculation.

Which is why the authoring loop matters more than the feature set. If changing an 80 to a 110 requires an engineer, a rebuild and a redeploy, nobody will tune it, and the reward moment will ship at whatever numbers the first implementation happened to use.

Making it tunable by the person with the taste

Two properties get you there:

Effects as data, not code. A named effect loaded from a bundle can be re-authored by whoever has the eye for it. A drawCoinBurst() function can only be changed by whoever writes functions.

Timing in one place. The offsets above belong in the presentation layer next to each other, not scattered across the handlers that trigger them. You want a person to be able to read the whole sequence at once.

This walkthrough builds the concrete version for PixiJS v8 — a claim button that sparks on press and a coin fountain for the reward popup, both authored in an editor and played from the ticker. What I'd take from it is less the particles than the shape: the game says a reward happened, and a separate layer owns how that reads.

The test

Ask whoever has the best instinct for game feel on your team to change how a reward reads — not to describe it, to change it.

If they can do it alone in a few minutes, your pipeline is right. If they have to file a ticket, then the most commercially important 400 milliseconds in your game are being tuned by whoever has build access, which is not the same person and never was.

I judge tools on the first ten minutes

PatilRB — Wed, 26 Aug 2026 07:38:49 +0000

I have started judging developer tools almost entirely on the first ten minutes, and I think the instinct is correct rather than lazy.

Not because the first ten minutes are the important part of the work — they obviously are not. Because they are the only part you can evaluate before committing, and because a tool that respects them is usually a tool built by someone who watched a real person use it.

What the first ten minutes are actually measuring

Time to first visible result. For a VFX tool, the moment something moves on screen that you caused. For a database library, the first successful query. Every step before that is unpaid setup, and users are entitled to resent it.

How many decisions you are forced to make while ignorant. This is the one most tools get wrong. Asking me to choose a project name, a package manager, a rendering backend, and a directory layout before I have seen the thing work is asking me to make four decisions with no information. Every one of them is a chance to get stuck, and none of them can be made well yet.

Whether the happy path is honest. If the quickstart works only because it skips the part that will bite me — no error handling, no build step, a demo asset that hides the asset pipeline — then it was marketing, not onboarding, and I will discover this at the worst moment.

The pattern I now look for

The best onboarding I have encountered lately does something slightly unusual: it hands you a prompt for your coding agent rather than a sequence of commands to run yourself.

That looked like a gimmick until I thought about what it actually optimises. A command list requires you to be correct at every step; a spec handed to an agent means the tedious, error-prone parts — scaffolding, installing the right peer dependency, wiring the loop — happen in one shot and produce a diff you can read. The verification is at the end, where it belongs, rather than distributed across eight steps you might mistype.

NixieFX's quick start is built this way: copy one prompt into whichever agent you use, and it sets up a Vite + TypeScript project, installs the runtime and its renderer peer, scaffolds an effect, exports the bundle, plays it in a scene, and tells you how to run the result. Ten minutes with one decision in it — which renderer — rather than six.

Two details in it are worth stealing regardless of your stack:

The prompt names the packages explicitly. Removes an entire class of hallucinated dependency.
The prompt links the docs and the machine-readable site index. An agent with the real reference stops inventing option names, which is the single biggest cause of confidently wrong scaffolds.

Where I would push back on my own heuristic

The obvious failure mode: optimising for the first ten minutes can produce a tool that is delightful to start and miserable at month three. Magic scaffolding, hidden configuration, a golden path that collapses the moment your project stops resembling the tutorial.

So the heuristic needs a second half. After the ten minutes, ask: can I see everything the tool did? If the scaffold is a readable diff and the configuration is a file in my repo, the fast start cost me nothing. If it materialised state I cannot inspect, I have borrowed against my own future.

Fast start, legible aftermath. Either one alone is a trap.

The curve editor is the actual interface

PatilRB — Wed, 26 Aug 2026 07:34:23 +0000

Most particle editors present themselves as a wall of numeric fields, and most tutorials teach you to fill them in. Both are a distraction from where the actual authoring happens, which is the curve editor.

Constants describe nothing that moves

A particle's size is not a number. It is a shape over the particle's lifetime: bursting outward fast, holding, then shrinking as it fades. Its colour is not a value either, it is a gradient — white-hot at spawn, orange in the middle, dark smoke at the end.

Author those as constants and you get the characteristic look of a first attempt: technically a fire effect, reads like a spray of orange dots. Nothing about the individual parameters is wrong. What is missing is that every interesting property changes over the life of the thing, and a single number cannot express change.

This is why the curve and gradient editors are the real interface. Everything else is plumbing.

size over lifetime     0 ▁▃▅▇▇▆▄▂▁ 1     ← fast rise, slow decay
alpha over lifetime    0 ▇▇▇▆▅▃▂▁▁ 1     ← hold, then fade late
colour over lifetime   [white ▸ orange ▸ ash]

Three curves and a gradient is the difference between "orange dots" and "fire". No additional modules required.

The rules I have converged on

Alpha should fade late, not linearly. A linear fade reads as the particle being dimmed. A fade held flat and dropped in the last third reads as the particle dying. Same duration, entirely different impression.

Size should not fade to zero at the same time as alpha. If both hit zero together the particle vanishes twice, which reads as a pop. Let size finish first and alpha carry the tail, or the reverse — just not both.

Put the variation on the curve, not the value. Randomising a constant gives you particles that differ from each other. Randomising where on the curve each particle starts gives you particles that differ over time, which is what makes a group look like a phenomenon rather than a set.

Gradients want three stops, not seven. Every extra stop is a decision someone has to preserve when they tune it later. I have never regretted removing one.

The part that took me longest to internalise

The timeline is a separate axis from the curves, and confusing them causes a specific kind of frustration.

A curve describes what happens over one particle's lifetime. The timeline describes what happens over the effect's duration — when each emitter starts, how long it runs, when the second stage fires. When an effect looks wrong "in the middle", the instinct is to reach for curves, and about half the time the actual problem is timeline: two emitters are overlapping when they should be sequential, or a burst is landing before the thing it is supposed to accent.

Asking "is this a per-particle problem or a per-effect problem?" first has saved me a lot of pointless curve-dragging.

Where the reference lives

The NixieFX editor manual documents the curve and gradient editors, the timeline, and per-field tables for every emitter module — which is the part I actually needed, because particle systems are full of fields whose label suggests slightly more than the implementation does. Guessing from a slider and a name is how you lose an afternoon.

The transferable bit

If you are building any authoring tool, the lesson generalises: find the parameters that are secretly functions of time, and give them a real editor. Users will forgive a plain form for everything else. They will not produce good work while expressing a curve as a number, and most of them will not be able to tell you that is what is wrong.

Delegating VFX work to a coding agent: what actually made it reliable

PatilRB — Mon, 24 Aug 2026 09:56:30 +0000

I have spent the last few months handing real work to coding agents, and particle effects turned out to be an unexpectedly good test case. Not because the task is hard, but because it fails in a specific, informative way.

Ask an agent to "add a fire burst to the boss intro" in a project it has not been taught about, and you get code that looks right and is wrong. Plausible imports. Invented option names. An update call in the wrong place in the host lifecycle. It compiles, it renders nothing, and the failure gives you no hint about which of the four layers broke.

The failure is a vocabulary problem

The agent is not confused about JavaScript. It is guessing at three things it has no way to know:

Where authored assets live in this project, and what a valid effect file looks like.
Which capabilities the backend actually supports — a 3D world effect and a 2D UI effect are not interchangeable, and the constraint is not visible from the call site.
Where in the host lifecycle loading, per-frame simulation, and cleanup belong. This is the one that produces silent no-ops: the code is fine and it runs in the wrong place.

None of that is inferable from a function signature. It is project knowledge, and if you do not supply it the model supplies a guess.

Splitting authoring from integration

What worked was refusing to treat this as one task. Authoring an effect and wiring an effect into a game are different jobs with different failure modes, and giving the agent one combined instruction sheet made both worse.

NixieFX ships two agent skills split exactly on that seam:

authoring — create project-safe effect files, check them against what the backend supports, produce the export bundle.
runtime — load an exported bundle, wire the providers the engine owns, keep simulation and cleanup in the right lifecycle hooks.

Naming the one you want is what makes the run predictable:

Use the authoring skill to create, validate, and export a fire burst for a PixiJS boss intro in this project.

Use the runtime skill to load the exported fire-burst effect from out/vfx, wire its texture provider, and update it once per frame.

Two prompts, two reviewable diffs. When something is wrong you know which half to look at, which is most of the value.

The validator is what makes it safe

The reason this works better than a longer prompt is that there is a machine-checkable step in the middle. The authoring loop is create, edit, validate, export — and validate is read-only and exits non-zero on error.

That gives the agent a ground truth it can act on instead of a vibe. It is also the difference between reviewing an agent's VFX work in thirty seconds and reviewing it by launching the game and squinting. If validate passes and export produces a bundle, the authoring half is done; anything still broken is integration, and integration is the other skill's problem.

I would generalise this past VFX: any task you want to delegate to an agent needs a check the agent can run itself. Not a test you run afterwards — a command it can invoke, read the exit code from, and iterate against. Tasks with that property go well. Tasks without it produce confident, plausible, unverifiable diffs, and you end up doing the work twice.

What I would not delegate

Judgement about whether the effect is any good. An agent can produce a valid fire burst that matches the spec and still looks wrong for the scene, because "reads clearly at 400 px on a phone during a screen shake" is not a property a validator can check.

Authoring and wiring: delegate. Deciding it looks right: still a person, still watching it in context.

Curious whether others have found the same pattern — that the deciding factor in agent-delegated work is the presence of a self-service validation command rather than the quality of the prompt.

The particle effect that looks different on every machine

PatilRB — Mon, 24 Aug 2026 09:54:42 +0000

"It looks different on my machine" is the worst bug report you can get about a particle effect, and it is also the most common one.

Nobody can reproduce it, nothing is thrown, and the only artefact is a teammate insisting the explosion is "wetter" on their laptop. Then someone records a video, and they are right.

Two separate causes wearing the same costume

Almost every one of these turns out to be one of two things, and they are worth separating because the fixes are unrelated.

Cause one: you are feeding the simulation the wrong unit.

Every runtime picks a convention for its update step, and the two popular ones differ by a factor of 1000. If the API wants seconds and your host loop hands it milliseconds, the effect does not error — it just runs a thousand times too fast, which reads as "the particles vanish instantly" or, at low emission rates, as "it looks kind of aggressive". On a fast machine with a 4 ms frame you get one appearance; on a throttled laptop at 30 ms you get another. Same code, different vibe, no exception.

// three.js: THREE.Clock.getDelta() already returns seconds
vfx.update(clock.getDelta());

// but a raw rAF timestamp does not
let last = performance.now();
function frame(now) {
  vfx.update((now - last) / 1000); // <- the /1000 is the whole bug
  last = now;
  requestAnimationFrame(frame);
}

I have written that missing / 1000 more than once. It is worth a comment on the line, because it is invisible in review — both versions are a number being passed to a function that takes a number.

Cause two: the simulation is genuinely random per run.

Particle systems are stochastic by design. If the randomness is seeded from the clock, then two machines, two reloads, and two QA passes all produce different motion. That is fine for ambient smoke and actively hostile for anything you need to verify, screenshot, or regression-test.

Seeded runs are the feature to look for

The property you want from a runtime is: same effect, same seed, same motion — on every machine and every backend. The NixieFX Three.js runtime exposes it directly on effect creation:

const effect = vfx.createEffect(fireBurst, { seed: 1234 });

Pass a seed and the run is reproducible. Leave it out and you get variety.

That single parameter changes what is possible downstream:

Screenshot tests work. Fixed seed plus fixed delta means frame 30 is byte-comparable across CI runs. You can diff VFX like you diff a component render.
Bug reports become artefacts. "Seed 1234, frame 30" is a reproduction. "It looks wetter on my laptop" is not.
A/B comparisons are honest. Comparing two parameter sets under different random draws tells you nothing; under the same seed it tells you exactly what the parameter did.
Variety stays available. Seed per spawn from your own counter and every explosion differs, but deterministically — replayable from the same game state.

The discipline, compressed

Two rules cover the whole class of bug:

Advance the simulation with seconds, exactly once per frame, from the host's own clock — never from a value you computed twice or reused across systems.
Seed anything you intend to verify. Ambient effects can float; anything in a test, a screenshot, or a bug report gets a number.

Neither is clever. Both are the kind of thing you only write down after losing an afternoon to a "wetter" explosion.

Related trap, for anyone chasing frame time rather than appearance: updating the simulation inside a loop that already runs per-object means you advance it N times per frame. It looks like a performance problem and it is actually a correctness one.

Put your particle effects in CI

PatilRB — Mon, 24 Aug 2026 09:51:47 +0000

Particle effects are the last asset class most web teams still treat as an opaque blob. Textures get optimized in CI, shaders get linted, JSON configs get schema-checked — and the VFX sit in a binary editor file that exactly one person on the team can open.

That asymmetry has a cost you only notice on the day someone's effect stops rendering and the git history says Modified: fire_burst.vfx (binary).

Text assets are reviewable assets

The fix is not clever, it is just a format decision: keep effects as plain JSON in the repo, next to the code that loads them. Then all the tooling you already own starts working for free.

git diff shows that someone raised the emission rate from 40 to 400, which is why the boss intro now costs 12 ms a frame.
Code review can happen at all. "Why is this effect spawning 6 sub-emitters?" is a question a reviewer can ask on a line number.
Merge conflicts become conflicts you can resolve instead of a coin flip between two binaries.
Rollback is a revert, not an archaeology project in someone's Downloads folder.

The pipeline that makes it stick

A text format only helps if there is a validation step, otherwise you have traded an unreadable file for a readable file that is also broken. The loop I settle on looks like this:

Author — scaffold the effect file, then edit it in an editor or by hand.
Validate — read-only check over every effect in the project, non-zero exit on error.
Export — compile to a bundle the game actually loads.

Step 2 is the one that earns its keep, because it is the step you can put in CI. A validator that exits non-zero is a merge gate. The same command a developer runs before committing is the command the pipeline runs on the pull request, which means "it worked on my machine" stops being a defence.

The tool I use for this is the NixieFX CLI — three commands, no browser required:

npx nixie-fx effect create --project . --name "Fire Burst" --profile three-world-3d
npx nixie-fx validate .
npx nixie-fx export .

validate walks every effect, touches nothing, and exits 1 if anything is wrong. That is the whole contract, and it is enough.

# .github/workflows/vfx.yml
- run: npx nixie-fx validate ./vfx

Nine lines of pipeline config, and a broken effect can no longer reach main.

What the export step buys you

Keeping the source readable does not mean shipping the source. export writes a bundle — a manifest, compiled effect JSON, and byte copies of every referenced asset — and that bundle is what the game loads at runtime. Authoring format and shipping format are allowed to be different things, and separating them is what lets the authoring format stay verbose and diff-friendly.

It also means the deploy artifact is self-contained. No "works locally, missing texture in staging", because the bundle carries its assets rather than pointing at wherever they happened to live on the author's disk.

The part I underestimated

I expected the win to be about git hygiene. The actual win was that non-specialists could participate. When an effect is a text file with named fields and a validator that tells you when you are wrong, a gameplay programmer with no VFX background can adjust a lifetime or swap a texture and know within a second whether they broke it.

The binary format was not protecting anything. It was just the reason only one person touched the effects.

If you keep VFX in your repo, what is your validation story? I am curious whether anyone has gone further and put a perf budget in the same gate — failing the build when an effect exceeds a draw-call count would be the logical next step, and I have not built it yet.

The particle features I stopped hand-rolling

PatilRB — Thu, 20 Aug 2026 11:16:22 +0000

Every web game I have worked on grew its own little particle system. It always starts the same way: a pool of sprites, a velocity, a lifetime, a fade. Two hundred lines and you have sparks.

Then the requests arrive. Can the smoke curl? Can the trail taper? Can the explosion spawn embers that themselves fall and fade? Each one is reasonable, and each one is another week bolted onto code nobody wants to own.

Here is the list of things I used to write by hand that an authored VFX pipeline just has, which is roughly why I stopped.

Values that change over a lifetime

Size, colour, alpha, rotation, velocity — all driven by curves and gradients rather than lerps hard-coded at the call site. Multi-point curves with per-point bezier tangents, colour and alpha gradients that can blend or step. The moment an artist can edit these without a rebuild, the iteration loop stops going through you.

Emission shape

Not just "spawn at a point". Shapes, with the direction of emission following from the shape. This is the one I always half-implemented, because a cone is easy and a ring is easy and then someone wants a mesh.

Forces and noise

Gravity is trivial. Turbulence is not, and turbulence is the difference between smoke that reads as smoke and smoke that reads as a sprite moving upward.

Trails, flipbooks and sub-emitters

Sub-emitters are the honest breaking point for a hand-rolled system. Once a particle can spawn its own emitter with its own lifetime and its own modules, you are no longer maintaining a particle effect. You are maintaining a particle engine, and that was never the job.

A material graph

A node-based shader editor with live per-node previews is not something I was ever going to write for one game. I would have shipped three hand-written shaders and told the artist those were the options.

What actually changed

The pitch I did not expect to care about is that the effects stay in my repo as plain JSON, in my own project folder, exported into a self-contained bundle the game loads. So this is not the usual trade where you adopt a tool and hand over your content in exchange. The diffs are still readable, the files are still mine, and the engine-side integration is a renderer, a create call and one update per frame.

What I gave up is the two hundred lines. I do not miss them.

The full module list — emission shapes, curves, gradients, forces, noise, trails, flipbooks, sub-emitters, the shader graph, and which of them each backend supports — is in the NixieFX feature reference. The editor itself is free and runs in the browser at nixiefx.com/editor.

A practical checklist for UI-triggered particle effects in PixiJS

PatilRB — Wed, 19 Aug 2026 12:28:54 +0000

Game-feel effects often start as a visual task: add a burst, tune the color, ship it. In browser games, the more durable question is how an effect enters and leaves the frame loop.

For small PixiJS projects, I use a short checklist before adding any particle system:

Tie the trigger to a real interface event. Button success, a streak increment, or a completed quest gives the effect a clear job.
Keep the emitter lifetime explicit. Create it, emit for a bounded interval, then destroy or return it to a pool.
Pass the current delta time through the update path. A burst that looks good at 60 FPS but races on a high-refresh display is a hidden regression.
Budget texture changes and blend-mode changes. The prettiest spark is not worth a stuttering menu.
Test the “quiet” path too. Opening and closing the UI repeatedly should not grow memory or leave particles updating off-screen.

The implementation details and an editor-oriented workflow are in this PixiJS particle-effects guide. The useful takeaway is not a particular emitter preset; it is treating visual feedback as part of the UI’s lifecycle.

That framing also makes reviews easier. A designer can judge whether the cue communicates the intended state, while an engineer can verify that it is bounded, frame-rate independent, and removable. Small web games benefit from both kinds of clarity.

Five hot-path rules for 60 FPS HTML5 games

PatilRB — Wed, 19 Aug 2026 11:51:07 +0000

A web game can look simple and still miss its frame budget. The usual culprit is not a single expensive feature; it is small amounts of work repeated every frame until the garbage collector, renderer, or GPU stalls.

Here are five rules that consistently help.

1. Treat per-frame allocation as a bug

Avoid creating vectors, arrays, closures, and temporary objects inside update loops. Reuse scratch values and keep object shapes stable. A tiny allocation multiplied by thousands of particles becomes visible hitching.

2. Prewarm pools

Pooling only helps if the pool is ready before the action begins. Prewarm projectiles, particles, and transient UI effects during a loading phase. The first explosion should not also be the moment the game constructs hundreds of objects.

3. Use texture atlases deliberately

Atlases reduce texture switches, but a giant atlas is not automatically better. Group assets that are rendered together, keep filtering and color-space settings consistent, and verify that batching actually improves in the profiler.

4. Budget draw calls, not just triangles

Many transparent particle layers can become expensive even when the geometry is tiny. Watch draw calls, overdraw, blend modes, and material changes. Sort only when the visual result truly needs it.

5. Measure frame time, not average FPS

An average can hide a periodic 50 ms hitch. Capture frame-time distributions and inspect the worst frames. Fix the spike before reducing the whole game's visual ambition.

These constraints shaped the NixieFX runtime: authored effects are useful only when their update path stays predictable in a real HTML5 game.

The full guide includes practical pooling, atlas, and profiling examples:

https://nixiefx.com/html5-game-performance/

The dual prompt: why your AI task handoffs keep failing

PatilRB — Tue, 18 Aug 2026 15:28:01 +0000

A while back a teammate ran a task I wrote and it came back wrong. Not subtly wrong — it had refactored a file I never mentioned. The model was fine. My prompt was the problem: I had written one set of instructions for two completely different readers.

Two readers, one prompt

When you hand an AI task to someone else — they run it on their own Claude Code or Codex subscription and send you the result — there are two audiences.

The human needs to know what this is, why it matters, what "done" looks like, and what to sanity-check before sending it back.

The agent needs exact scope, hard constraints, which files or systems are in play, and what it must not touch.

A single prompt serving both ends up too vague for the agent and too jargon-dense for the person. And the second failure is the expensive one: if the person can't tell whether the output is right, they forward it unchecked. Your review becomes the only gate, which defeats the point of delegating at all.

What the split looks like

Here is the version I used to write:

Clean up the analytics module and make sure the tests pass.
Should be quick.

And here is the same task written for both readers:

## For you (the human)
We're removing the last of the legacy event names before the
rename ships Friday. There are 11 call sites.

Done looks like: `rg "track_legacy" src/` returns nothing, and
the analytics test suite is green.

Before you send it back, check the diff does not touch
src/analytics/schema.ts — another team owns that file and
changing it will block the release.

## For the agent
Scope: src/analytics/**, excluding src/analytics/schema.ts

Task: replace every `track_legacy(<name>)` call with
`track(<name>)`, preserving arguments and ordering.

Constraints:
- Do not modify schema.ts
- Do not reformat or touch unrelated lines
- Run `npm test -- analytics`; report failures rather than
  fixing ones outside this scope

Out of scope: renaming events, the dashboard package.

The second is four times longer. It is also the difference between a delivery you can merge and one you have to redo.

The "for you" half matters more than it looks

The reflex is to skip it. The human is just going to paste the agent half anyway, right?

But the human half does something the agent half cannot: it gives the person enough context to reject a bad result. An agent will confidently hand back something plausible. If the person running it has no idea what correct looks like, plausible and correct are indistinguishable. One sentence — "check the diff does not touch schema.ts" — turns a passive relay into an actual reviewer.

That is the whole return on writing the second half.

The constraint underneath

There is a reason this pattern comes up at all. You cannot hand someone else's Claude or Codex subscription a task without handing over the login. So the work has to travel as instructions, not as access — and that is exactly why the writing quality carries so much weight. With shared access you can course-correct mid-run. With a handoff, the prompt is the entire interface.

We have been building Wagglet at Rockbite Games around this shape of work (disclosure: I work there). The dual prompt is a pattern we kept re-deriving by hand until we made it the default structure of a task. If you want the longer reasoning there is a write-up on the dual prompt, and the full request-to-delivery workflow if you want to see where it sits end to end. For wiring an agent in directly there is an MCP endpoint.

None of that is required to use the pattern, though. It is just two headings in a markdown file.

A checklist that mostly works

Before sending a task for someone else to run:

Can they tell, without asking you, whether the result is wrong?
Have you named at least one thing that must not change?
Is scope stated as paths and systems, not as a description?
Have you said what to do on failure — report it, or fix it?
Would this still make sense to them in three days?

If any of those are a no, the prompt is not finished. It will come back wrong and you will blame the model.

Curious whether other people have landed on the same split, or something better — particularly anyone running handoffs across a team rather than solo.