DEV Community: Hiroshi TK

Footstep dust in Three.js with a pool of four effects

Hiroshi TK — Wed, 14 Oct 2026 12:53:44 +0000

A footstep effect has two separate rates: how often the character asks for a puff, and how many particles each puff emits. Keeping those separate makes it possible to budget a repeated effect without tying it to the display refresh rate.

This NixieFX tutorial uses an intentionally simple character proxy, a moving box, with a dust request every 15 simulation frames. At a fixed step of 1/60 second, that is four requests per simulated second. Each request restarts one available effect containing a 12-particle burst.

The effect contract

The tested scene uses nixie-fx 0.1.20 and Three.js. The emitter uses procedural unlit billboards, world-space simulation, no continuous emission, a burst at time zero, and a particle lifetime of 0.7 seconds. The effect timeline lasts 0.8 seconds; the emitter's emission duration is 0.05 seconds. There are no texture or mesh downloads.

That short emission duration matters. A pool member is available only after its effect is inactive. Leaving a long emitter duration on a short visual puff can keep the pool occupied after the visible particles have gone away.

const pool = Array.from({ length: 4 }, (_, i) =>
  vfx.createEffect(dustDefinition, { autoStart: false, seed: 42 + i })
);
let requests = 0, reused = 0, dropped = 0;

function onFootstep(position) {
  requests++;
  const puff = pool.find(instance => !instance.isActive);
  if (!puff) { dropped++; return; }
  puff.setTransform({ position });
  puff.restart();
  reused++;
}

// In this test harness, frame advances at a fixed simulation step.
if (frame % 15 === 0) onFootstep([characterX, 0, 0]);
vfx.update(1 / 60);
renderer.render(scene, camera);

The fragment assumes a constructed renderer and the dust definition described above. In an actual game, trigger on the animation's foot-contact event instead of a frame counter. Update the owning renderer once per simulation step; do not also update its instances individually.

The position belongs to the contact at emission time. Moving an active puff to follow the character would create a different effect. The test moves only an available member immediately before restarting it.

What the run measured

In one Chrome run on macOS, 180 simulation frames produced 12 requests, 12 pool reuses, zero dropped requests, and four retained effect instances. The final frame contained 24 active particles. The recorded p95 CPU duration around the runtime update was 2.0 ms, while the p95 animation-frame interval was 17.2 ms.

These are observations from a three-second demonstration with other browser tabs open. They include startup samples and debug-transform capture. They are not GPU measurements, a mobile-device budget, or evidence that pooling is faster than allocating a fresh instance. The useful functional result is narrower: the four-member pool served the requested cadence without allocating another effect instance after setup.

Saturation is a behavior to choose

This implementation drops a cosmetic puff when the pool is full. That avoids stealing an active instance and visibly cutting off its particles. A different game may choose a larger pool or allow a controlled fallback allocation. Measure the number of dropped requests so the decision is visible.

Four members are a test parameter, not a universal recommendation. A faster character, multiple characters, longer particle lifetimes, or a slower completion condition can change occupancy. Test those cases separately before selecting the production capacity.

Limits and cleanup

The runtime reported the tested Three.js effect as supported with no warnings or blockers. This example does not implement ground collision, terrain normals, animated character feet, lighting, or mesh particles. Those settings were not validated by this run and should not be inferred from the result. The Three.js runtime documentation covers integration and backend support checks.

Remove every retained instance when the owning scene is released, or destroy the renderer if that scene owns it. An inactive effect is still a retained instance. The pool has to be bounded and its lifetime explicit even when nothing is visible.

Rank the work you can verify, not the tokens you can spend

Hiroshi TK — Wed, 14 Oct 2026 11:53:31 +0000

The example below is hypothetical and does not report a production result.

An AI task handoff for teams needs a queue that rewards useful outcomes. Token use measures an input. It cannot tell you whether a migration was necessary, a bug was fixed, or a reviewer can reproduce the result.

Use four fields before assigning work: impact, risk, readiness, and verification. Keep the last three visible instead of hiding every judgment inside a single priority score.

Start with gates

Readiness means the runner has the necessary repository access, environment instructions, and a bounded request. Verification means someone can describe the evidence required for acceptance. If either is missing, put the task in preparation. A high-impact request does not become executable because it earned a large number.

Risk describes the potential cost of a mistake. A public typo correction and a billing migration should not share an approval route. High-risk work needs its specialist and release controls before it enters the ready queue.

Among ready tasks, rank impact first and use expected review effort as a tie-breaker. This is a starting rubric, not a universal scoring formula:

Field	Low	Medium	High
Impact	Local convenience	Repeated team friction	User-facing failure or blocker
Risk	Reversible text change	Bounded behavior change	Data, access, or release consequences
Readiness	Missing owner or access	One unresolved dependency	Scope, access, and environment ready
Verification	Subjective request	Evidence partly specified	Named checks and reviewer

Copy a task card

outcome: Export button stays disabled while an export is running
scope: Export panel and its existing interaction tests
excluded: Export API, file format, unrelated styling
impact: Repeated duplicate export requests
risk: Medium; changes a user interaction
prepared_by: Product engineer
runner: Teammate with authorized repository and agent access
reviewer: Export-panel maintainer
acceptance:
  - Second click during an export starts no additional request
  - Button becomes available after success or failure
  - Keyboard activation follows the same rule
evidence:
  - Focused diff
  - Reproduction steps and observed outcomes
  - Test commands, results, and any skipped checks
stop_when:
  - Fix requires changing the export API contract

The author prepares the card and checks that the requested behavior is actually desired. The runner executes it with their own authorized tools and access. The maintainer judges the evidence. A deployment owner decides whether and when the accepted change ships. These can be overlapping people on a small team, but the decisions should still be explicit.

Work one handoff

Imagine three requests: polish a tooltip, prevent duplicate exports, and redesign the export API. The tooltip is ready and low risk but has limited impact. The duplicate-request fix has a clear failure and a bounded test. The API redesign has an important goal but no compatibility decision.

Prepare the redesign before assigning it. Put the bounded fix first among ready work. Keep the tooltip available for a smaller work window. Nothing in that ordering depends on which request consumes the most tokens.

If the runner discovers that the duplicate originates in the server rather than the panel, they should stop and return the evidence. That is useful progress even without a patch. Rewarding only merged changes would push them toward a superficial client-side fix.

Review the outcome and the rubric

A reviewer should be able to repeat the relevant checks without reconstructing a long agent conversation. Record a verdict, the evidence used, and any remaining limits. Do not turn a passing test into a claim that every export path is safe.

The Wagglet discussion of bounties and rewards is a useful context for designing incentives around accepted work. This template is an independent example, not a description of an automatic scoring feature.

Try the rubric on a small queue. If apparently ready tasks repeatedly need clarification, improve preparation. If review dominates the work, tighten scope. Treat those observations as workflow feedback, not a ranking of people's value.

A localization handoff that design, QA, and engineering can all use

Hiroshi TK — Tue, 13 Oct 2026 07:49:24 +0000

AI disclosure: This tutorial was generated with AI. The reward dialog is a hypothetical example; no production screenshot or test result is claimed.

Describe the failure at the string level

A localization issue often arrives as “German breaks the popup.” That report mixes several decisions: whether the translation is correct, whether the layout can accommodate it, and whether the right resource reaches the UI. Give each decision an owner before requesting a fix.

Use a small example: a reward dialog has a button with the English source string “Claim reward.” In the German locale, the approved translation is longer than the available space at the smallest supported viewport. The designer owns the layout rule, a locale reviewer owns the language, and engineering owns how the component applies both.

Do not shorten the translation solely to fit an arbitrary character count. Characters have different widths, and a short phrase can still be semantically wrong.

Create a task from this template

task: Fix reward-dialog action-label clipping
string_key: rewards.claim_cta
source_locale: en
source_string: Claim reward
target_locale: de
target_string: use the locale reviewer's approved resource value
screen: daily reward confirmation dialog
state: reward available; no network request in progress
viewport: smallest supported mobile viewport, exact dimensions required
font: record actual family, weight, size and fallback behavior
context_screenshot:
  before: attach a real capture showing the whole dialog and clipped label
  after: capture the same viewport, locale, state and build configuration
scope: this dialog's action-label layout
exclude: translation rewrites, reward logic, global typography changes
preparer: QA with design
executor: UI engineer using their own authorized development tools
reviewers:
  language: locale reviewer
  layout: designer
  acceptance: QA lead

The screenshot entries are evidence requirements, not links to nonexistent images. Before using this as a real ticket, attach a capture from the affected build and record its revision. Crop out private account information, but retain enough surrounding UI to explain what the button does.

Work the handoff in three decisions

First, QA reproduces the clipping and records the locale, device scale, viewport, and loaded font. A fallback font can change the result, so a screenshot without font context is insufficient. QA also checks whether the defect appears before or after the translation resources finish loading.

Second, design specifies an acceptable layout behavior. For example, permit the action region to grow vertically while preserving the existing minimum touch target and the approved gap to the secondary action. This is an example decision, not a universal prescription. If the product requires a single-line button, design must instead define an approved width strategy or language-review escalation.

Third, the engineer changes only the relevant component and returns the diff with comparable before/after captures. If the implementation discovers a shared component issue, expand the scope explicitly before changing every dialog in the game.

An assistant can help find uses of the string key, draft a test matrix, or propose a constrained component change. That is expert supervised AI execution when the human owners provide the context and review the evidence. Wagglet's studio-stack discussion provides a related framework for coordinating those roles. It does not make an AI-generated translation an approved resource.

Verify content and layout separately

Use this acceptance checklist for the example:

The exact approved target string renders without clipping or ellipsis.
The label remains inside the action area at each supported narrow viewport.
The button still performs the same reward action exactly once.
English remains readable and the secondary action remains reachable.
The locale reviewer approves meaning and tone independently of layout.
QA captures the final state using the same setup as the original report.

Add an automated layout assertion if the application exposes suitable bounds. Check the rendered text against its actual containing region after fonts and translations are ready. A character-count check cannot establish that the text fits. For a canvas UI, use the engine's text and container bounds and retain a visual capture; DOM text measurements may not represent the canvas renderer.

The engineer should record what ran, what failed, and what was not checked. “All locales fixed” is too broad if only English and German were exercised.

Keep the limits visible

Pseudo-localization helps expose constrained layouts, but it does not certify grammar, right-to-left behavior, or cultural suitability. This example does not supply a real failing build or screenshot. Treat it as a reusable handoff recipe and replace the evidence fields when applying it to your game.

The final acceptance decision belongs to the named reviewers. A clean diff and a plausible screenshot are inputs to that decision, not substitutes for it.

Budget waterfall mist with particle lifetime before adding density

Hiroshi TK — Tue, 13 Oct 2026 06:52:00 +0000

Waterfall mist can consume a surprising amount of a scene's visual budget because it is usually continuous. A burst ends; an ambient emitter remains active while the player explores. The useful first question is how many particles the effect keeps alive, not how dense it looks in the editor.

This NixieFX tutorial uses a small Three.js fixture: a rectangular waterfall prop, a soft emitter at its base, and a visible runtime readout. The prop is ordinary host geometry. The mist is a NixieFX 0.1.20 billboard effect rendered with Three.js r185.

Set the population before tuning the appearance

The emitter creates 24 particles per second, with a lifetime of three seconds and a capacity of 96. Ignoring boundary timing, the expected steady population is approximately 24 × 3 = 72 particles. Capacity is a hard ceiling, not a promise that all 96 particles are always present.

emitter.maxParticles = 96;
emitter.spawn.rate = 24;
emitter.spawn.rateValue = constant(24);
emitter.initializeParticle.lifetime = constant(3);
emitter.spawn.shape = 'box';
emitter.spawn.box = [1.8, 0.2, 0.4];

The code uses createConstantParticleScalar as constant. The complete source initializes the remaining fields from createDefaultParticleEffect, enables a fade over lifetime, and gives each particle a small upward velocity. Depth testing stays enabled and depth writing stays disabled for the translucent billboards.

Place the effect relative to a readable prop

Place the effect at [0, 0.2, 0]. The demonstration waterfall sits behind it and supplies a stable scale reference. The scene is deliberately plain: mist density should be readable without a complex material, lighting rig, or postprocessing chain.

A dark background makes soft particle overlap visible. It can also make an additive effect seem more impressive than it will appear in a bright level, so this fixture uses alpha blending. Test against the actual level colors before treating its appearance as final.

The emitter does not collide with the waterfall or surrounding terrain. It does not simulate water volume, spray breakup, or moisture. It is a visual layer placed near a prop.

Keep simulation accounting separate from rendering accounting

Advance the runtime once per fixed simulation step, then render the scene. Do not advance an instance separately when its renderer already owns the update.

while (accumulator >= 1 / 60) {
  vfx.update(1 / 60);
  accumulator -= 1 / 60;
}
renderer.render(scene, camera);

The fixture caps the elapsed time added after a long frame. That prevents a large catch-up burst when a tab resumes, but it also means the demo is not a wall-clock simulation under stalls. Its fixed-step sequence is useful for comparisons.

The readout reports active particles, visible particles, capacity, instanced draw calls, and legacy particle draw calls. These are different quantities. A particle whose alpha is zero at birth may exist in the simulation while contributing nothing visible.

Read the observed result carefully

At a recorded simulation time of 60 seconds, the fixture showed 73 active particles, 72 visible particles, capacity 96, and one instanced draw call. The peak active count was 73. The extra particle around the simple 72-particle estimate reflects spawn and lifetime boundaries in the stepped simulation; it is not evidence that the capacity limit failed.

The runtime's support report was supported, and its unsupported-feature list was empty for this definition. A separate repeatability check compared two 90-step runs with seed 2444 and found identical particle debug transforms.

This is not a performance benchmark. A single emitter does not reproduce a full level's overdraw, resolution, effects, or device limits. The particle counter is a useful diagnostic, but it cannot replace a frame capture on the target hardware.

Change one budget variable at a time

First hold lifetime at three seconds and adjust the emission rate. Then restore the rate and adjust lifetime. Finally, test billboard size, because larger translucent quads can increase overdraw even when the particle count stays constant.

Keep the same camera and seed during each comparison. If you add a flipbook, material graph, or other feature, inspect the rendering path again instead of assuming the original draw-call result still applies.

The NixieFX Three.js runtime guide documents the counters and integration controls used here. A useful ambient effect is one whose visual contribution and resource cost can both be explained.

A task record is not an execution contract: a handoff template for coding agents

Hiroshi TK — Mon, 12 Oct 2026 07:57:20 +0000

Disclosure: This draft was generated with AI assistance. The worked example is illustrative and has not been run against a production repository.

A ticket can accurately describe a bug while leaving the executor unable to start. “CSV export loses filters” tells us what hurts. It does not identify the repository revision, the supported command, the intended output, or the person who can accept the change.

When comparing task tracking with managed agent execution, compare responsibilities rather than labels. A task tracker can be part of a well-managed execution system. An agent runner can also be poorly managed. The difference is whether the handoff specifies the following four things.

Compare context, runner, evidence, and acceptance

Context: Can the executor find the exact starting revision, relevant behavior, constraints, and allowed files? A long conversation is not a substitute for a small, current specification.

Runner: Is there an authorized operator and a known environment? Naming an agent is insufficient if nobody has installed the dependencies or can grant the necessary repository access.

Evidence: Does delivery identify the patch, actual commands run, results, and untested cases? “Done” is a state label, not a verification record.

Acceptance: Is a person responsible for deciding whether the result satisfies the requirement? The executor should not silently replace the requested behavior with an easier interpretation.

These criteria are useful when evaluating project management for coding agents because they apply before a particular tool enters the picture.

Write the execution contract

Here is an original template for an illustrative CSV repair. Values in angle brackets must come from the actual project. Command names are deliberately not invented.

task: Preserve the selected filters in CSV export
context:
  repository: <authorized repository>
  base_revision: <verified commit>
  reproduction: Select status=open, then export CSV
  expected: Export contains exactly the rows matching the filter
  fixtures: <sanitized fixture path>
scope:
  allowed: Export query and focused regression coverage
  excluded: Authentication, schema migrations, unrelated UI changes
execution:
  operator: <developer or authorized agent operator>
  setup_command: <verified command from this repository>
  test_command: <verified command from this repository>
  permissions: Existing authorized development access only
delivery:
  patch_revision: required
  commands_and_results: required
  sample_output: sanitized CSV from the fixture
  untested_cases: required, even when empty
acceptance:
  product_owner: Confirms filtering semantics
  engineer: Reviews implementation and regression evidence

Do not paste credentials into that contract. The person executing the task uses their own authorized tools and access. If the environment is unavailable, that is an execution blocker to resolve, not an invitation to share an account.

Walk one handoff through the template

The product owner prepares a fixture containing three records: two open and one closed. The expected filtered export contains the two open records. An engineer confirms the expected behavior and identifies the relevant export path.

The executor first reproduces the failure at the recorded revision. If it does not reproduce, the next useful delivery is the attempted command, environment details, and observed output. Editing code before resolving that mismatch risks fixing a different problem.

After reproducing the issue, the executor implements a scoped change and adds coverage for the filtered export. The normal unfiltered export is also checked, because repairing one path can narrow the other accidentally. Those are proposed checks; no passing results are claimed here.

The delivery attaches the patch revision and actual output from the verified test command. The engineer reviews the change. The product owner inspects the sanitized sample and confirms that the selected filters mean what users expect. If either review fails, the same task records the reason and the next attempt.

Keep the tool comparison honest

Wagglet's engineering-team page is the assigned product reference for this workflow. The template above is a proposed operating practice, not evidence that any particular platform supplies every field, runner, or verification step automatically.

A task tracker may already be sufficient if the team supplies the missing execution contract through its development process. A managed execution tool may reduce coordination work, but it still cannot decide an ambiguous product requirement without an acceptance owner.

The useful comparison is therefore concrete: take one real repair and ask where its context, execution authority, proof, and decision live. Any blank answer identifies work the team still has to do.

Hand off the feature-flag implementation without handing off the release decision

Hiroshi TK — Fri, 09 Oct 2026 08:46:50 +0000

The scenario and rollout values below are illustrative, not results from a production release.

A feature flag separates deployment from exposure only if the handoff preserves that distinction. “Implement the new checkout behind a flag” leaves several decisions open: who may deploy the code, who may change the flag, and what evidence is needed before more users see it?

Write those boundaries before assigning the implementation. A developer can prepare a change and return evidence. The release owner still needs a clear decision point.

Start with the flag off

Consider a hypothetical checkout summary that recalculates shipping after a user changes an address. The task is to implement the new summary behind checkout_summary_v2, with the existing behavior retained when the flag is off.

The product owner defines the expected user behavior. An engineer prepares the repository context, tests, and constraints. The runner executes with their own authorized tools and environment. A reviewer judges the implementation, and the release owner authorizes deployment and exposure changes separately.

Neither access to a flag dashboard nor a passing test implies permission to enable production traffic.

Use a brief with separate exit conditions

Feature: checkout_summary_v2
Default: off

Implementation scope:
- Add the alternate summary path behind the flag.
- Preserve the existing path when disabled.
- Do not change payment authorization or order persistence.

Required checks:
- Flag off: existing address-change behavior remains intact.
- Flag on: displayed totals match the approved calculation fixture.
- Flag changes: no duplicate charge or duplicate order request.
- Missing flag configuration: retain the approved safe default.

Delivery package:
Revision, changed files, exact test commands and outputs,
screenshots from the same fixture, known limits.

Implementation acceptance: [named engineering reviewer]
Product acceptance: [named product owner]
Production deployment: [named release owner]
Exposure changes: [named flag owner]

Stop boundary:
Return the reviewed change. Do not deploy or enable production traffic.

This is a task template, not a record of completed checks. Replace the placeholders with real owners and attach actual evidence before acceptance.

Make the staged rollout a separate decision

An illustrative rollout could progress from internal users to 1%, then 10%, then broader exposure. Those percentages are planning examples, not universal recommendations. The release owner must define observation windows, relevant metrics, and rollback thresholds for the actual service.

Require explicit approval at each stage. A quiet dashboard over a short interval may simply mean that too few users exercised the feature. Include a minimum useful sample or a representative manual check instead of assuming that elapsed time proves safety.

For the checkout example, inspect calculation mismatches and failed completion attempts. Also check whether the old path still works when the flag is disabled. Document who may halt the rollout and where that decision is recorded.

Make rollback a behavior, not a slogan

Turning a flag off is only a rollback if the old path can still operate with the state produced by the new one. If a migration or irreversible side effect has occurred, disabling exposure may not restore the previous behavior.

The example deliberately excludes payment and persistence changes to keep the task narrow. If implementation discovers that either must change, stop and revise the brief. Do not stretch a UI task into a transaction-system change without a new review.

A useful rollback rehearsal records the starting state, the disabling action, and the resulting user behavior. An unexecuted runbook is still a plan, even if the commands look correct.

Keep the delivery and the approval connected

Teams that manage work in one system need to preserve the difference between “a runner returned a change” and “the accountable owner accepted it.” Wagglet’s request-to-delivery workflow describes that separation; this brief makes the responsibilities explicit regardless of the tracking tool.

The reviewer should be able to identify the accepted revision, the evidence supporting it, and any unresolved limitation. The release owner should see the same information before approving exposure. If new evidence invalidates the decision, the task history should explain why the rollout stopped.

The flag’s default, the delivery’s acceptance, and the release’s approval are three different facts. Write each one down, assign each decision to a person, and let the implementation handoff end at the boundary you actually authorized.

NixieFX tutorial: trigger a PixiJS combo flare only when the meter crosses its threshold

Hiroshi TK — Thu, 08 Oct 2026 10:02:27 +0000

A combo-meter flare should mark the moment a player earns a new state. If it runs on every update while the meter is full, the signal becomes background noise and repeated effects can overlap unnecessarily.

This NixieFX tutorial separates two responsibilities: plain JavaScript decides when the threshold is crossed, and the PixiJS scene renders a short effect. Reduced-motion mode keeps a persistent “Combo ready” message while omitting the decorative burst.

Define the trigger before authoring the effect

For this example, the threshold is 100. Moving from 99 to 100 should trigger once. Moving from 100 to 105 should not trigger again. Dropping below 100 rearms the cue. These are proposed gameplay rules; change them if your meter uses a different reward model.

Keep the rule independent of the renderer so it can be checked without a canvas:

export function createThresholdGate(threshold = 100, initial = 0) {
  if (!Number.isFinite(threshold) || !Number.isFinite(initial)) {
    throw new TypeError('Use finite meter values');
  }
  let previous = initial;
  return (next) => {
    if (!Number.isFinite(next)) throw new TypeError('Invalid meter value');
    const crossed = previous < threshold && next >= threshold;
    previous = next;
    return crossed;
  };
}

Initializing the gate at an already-full value deliberately does not play an entrance flare. A saved game opening with a full meter should still display the ready state. Treat “ready on load” and “became ready during play” as separate events.

Author a short, readable flare

Create a Pixi-oriented effect named “Combo Flare” in a local NixieFX project. Start with one unlit billboard emitter, a single burst of 12 particles, no continuous emission, and a lifetime of 0.35 seconds. Use a soft texture, modest outward movement, and an alpha fade to zero. These values are design starting points, not measured performance recommendations.

Place the origin beside the meter rather than over the number. Preview against the actual HUD background and reduce the burst if it obscures useful information. Keep prepared 3D meshes, mesh-surface emission, lit shading, and GPU-depth-dependent behavior out of this Pixi recipe.

The NixieFX PixiJS integration guide covers exporting the effect and loading it into the Pixi adapter. Follow that setup first, then use the event wiring below in the initialized scene. Confirm that the exported effect ID is combo-flare.

Connect the gate to the existing scene

The following integration fragment assumes app, vfx, and the validated bundle already exist. It also assumes a real HTML status element named combo-status beside the canvas. The runnable lab and embedded source supply a complete isolated fixture. Configure PixiVfxRenderer with createPixiVfx2dProjection({ yAxis: "down" }) when passing screen coordinates, and rotate the circle emitter 90 degrees around X into the XY plane.

const crossedThreshold = createThresholdGate(100, 0);
const status = document.querySelector('#combo-status');
const motion = window.matchMedia('(prefers-reduced-motion: reduce)');
const definition = bundle.effectsById.get('combo-flare');
if (!status || !definition) throw new Error('Missing status or effect');
const live = new Set();
let ready = false;

export function setCombo(next, x, y) {
  const crossed = crossedThreshold(next);
  const nextReady = next >= 100;
  if (nextReady !== ready) {
    ready = nextReady;
    status.textContent = ready ? 'Combo ready' : 'Combo charging';
  }
  if (crossed && !motion.matches) {
    live.add(vfx.createEffect(definition, { position: [x, y, 0], seed: 42 }));
  }
}

function clearFlares() {
  for (const fx of live) vfx.removeEffect(fx, true);
  live.clear();
}
function onMotionChange() { if (motion.matches) clearFlares(); }
motion.addEventListener('change', onMotionChange);

// Use this as this scene's single VFX update path.
function tick(ticker) {
  vfx.update(ticker.deltaMS / 1000);
  for (const fx of live) {
    if (!fx.isActive) {
      vfx.removeEffect(fx, true);
      live.delete(fx);
    }
  }
}
app.ticker.add(tick);

export function disposeComboCue() {
  app.ticker.remove(tick);
  motion.removeEventListener('change', onMotionChange);
  clearFlares();
}

Use coordinates in the VFX parent’s local space. If the meter belongs to a scaled or translated container, convert its position before calling setCombo. Do not add a second VFX update loop if the scene already owns one. Initialize the HTML status as “Combo charging” and use role="status"; update it on state changes rather than every frame.

Reproduce the important cases

Feed the sequence 0, 99, 100, 105, 80, 100 into the gate. The expected crossing count is two. Repeat with reduced motion enabled: the threshold logic is unchanged, but no decorative flare should be created. Toggle reduced motion while a flare is active and confirm it clears.

Also check repeated values, an initial value above the threshold, a scene exit, and missing assets. The gate does not prevent legitimate rapid recrossings; add a game-specific cooldown or hysteresis only if that matches the intended rules.

Observed runtime result

The fixture uses NixieFX 0.1.17 and PixiJS 8.22.0. The sequence produced two threshold events, two created effect instances, and zero remaining instances after completion. Reduced motion preserved two threshold events while creating zero instances. At the frozen 0.10-second capture, the renderer reported twelve active particles. The export validated for pixi2d and three3d with no errors. These are functional observations from an isolated fixture, not a performance benchmark.

Limits

The JavaScript gate can be verified independently. Visual quality, exported-effect compatibility, and device performance require the real PixiJS build. Reduced motion is implemented by the host application here; it is not an automatic property of the authored effect. Do not infer a frame-rate guarantee from the small particle count.

Validate the review packet before you review the patch

Hiroshi TK — Wed, 07 Oct 2026 10:25:20 +0000

A green build can arrive with evidence for the wrong commit. A detailed delivery can leave the security reviewer unnamed. Neither problem requires reading every line of the patch to detect.

This tutorial builds a small evidence gate for a fictional search-filter change. The gate checks that a review packet is ready for human inspection. It deliberately does not decide whether the code is correct.

Separate implementation from acceptance

The task author prepares the outcome, fixture, scope, and acceptance criteria. The runner implements the change using their own authorized tools. A qualified reviewer judges the technical evidence, and the authorized task reviewer records the final decision.

If your requirement is “delegate AI task without sharing account,” place repository access and tool authorization in the runner’s setup checklist. The task should carry context and expected results, not somebody else’s login or provider token.

In this example, a search field should trim surrounding whitespace without changing authorization, query scope, or result ranking. If the implementation reaches those areas, the runner stops for technical review.

Create the evidence packet

Use actual revision identifiers and attach the full output of the checks you run. The values below are fictional placeholders illustrating the shape, not successful test results.

{
  "candidate": "REPLACE_WITH_COMMIT",
  "runner": "runner-name",
  "reviewer": "qualified-reviewer-name",
  "checks": [
    {
      "criterion": "search-trims-whitespace",
      "revision": "REPLACE_WITH_COMMIT",
      "result": "not-run",
      "evidence": ""
    },
    {
      "criterion": "empty-search-keeps-existing-behavior",
      "revision": "REPLACE_WITH_COMMIT",
      "result": "not-run",
      "evidence": ""
    }
  ],
  "escalations": []
}

Save that as review-packet.json. A task-specific required list matters: otherwise an empty or conveniently shortened checklist can pass a generic gate.

Check completeness with a small script

Save this as check-review-packet.mjs and run node check-review-packet.mjs review-packet.json with a current Node.js release.

import { readFileSync } from "node:fs";

const required = [
  "search-trims-whitespace",
  "empty-search-keeps-existing-behavior"
];
const problems = [];
const hasText = x => typeof x === "string" && x.trim().length > 0;
let p;
try {
  p = JSON.parse(readFileSync(process.argv[2], "utf8"));
} catch {
  console.error("Provide a readable JSON review packet.");
  process.exit(1);
}
if (!p || typeof p !== "object" || Array.isArray(p)) {
  console.error("The packet must be an object.");
  process.exit(1);
}
if (!/^[a-f0-9]{40}$/i.test(p.candidate ?? "")) {
  problems.push("Use the full candidate commit SHA.");
}
if (!hasText(p.runner) || !hasText(p.reviewer)) {
  problems.push("Name the runner and qualified reviewer.");
} else if (p.runner.trim() === p.reviewer.trim()) {
  problems.push("This task requires an independent reviewer.");
}
const checks = Array.isArray(p.checks) ? p.checks : [];
for (const criterion of required) {
  const matches = checks.filter(c => c?.criterion === criterion);
  if (matches.length !== 1) {
    problems.push(`${criterion}: expected exactly one record.`);
    continue;
  }
  const c = matches[0];
  if (c.revision !== p.candidate || c.result !== "pass" ||
      !hasText(c.evidence)) {
    problems.push(`${criterion}: missing current passing evidence.`);
  }
}
if (!Array.isArray(p.escalations) || p.escalations.length > 0) {
  problems.push("Resolve and document escalations before review.");
}
if (problems.length) {
  console.error(problems.join("\n"));
  process.exitCode = 1;
} else {
  console.log("Packet complete. Human review is still required.");
}

Work through a handoff

The author records the existing empty-search behavior before work starts. The runner changes the input normalization and gathers evidence for the two named criteria. They record the candidate commit once the implementation is stable.

Now imagine a follow-up edit changes that commit after the tests run. The packet gate rejects check records carrying the previous revision. The runner either reruns the relevant checks or obtains a documented review decision about which evidence remains applicable; they do not simply relabel old output as new evidence.

If the runner discovers that trimming is happening inside an authorization-sensitive query builder, they add an escalation describing the affected path. The qualified engineer decides whether the proposed scope is still appropriate. A founder can understand that blocked state without personally certifying the query implementation.

Understand what the gate cannot prove

The script accepts text supplied by people. It cannot verify that a named reviewer is qualified, that an evidence link is accessible, that a command really ran, or that the chosen tests are sufficient. It does not inspect Git or enforce identity. Use it as a completeness check before review, never as a replacement for review.

Wagglet’s human–AI pairing article discusses why a useful human role includes judgment and a clear route to expertise. The same principle applies here: automate the missing-field check, then leave the consequential decision with somebody who can assess the result.

The final review note should name the candidate revision, explain the verdict, and retain unresolved limits. “Packet complete” means the reviewer has something coherent to inspect. It does not mean the patch is accepted, merged, or ready to deploy.

Put a compatibility gate between your particle export and your game

Hiroshi TK — Tue, 06 Oct 2026 10:05:32 +0000

This article was prepared with AI assistance. The code below is an original application-side check. The helper was checked with synthetic inputs; the cross-backend rendering steps below are a proposed integration procedure, not a completed visual benchmark.

A particle effect can look right in an editor and still be the wrong export for a game scene. The practical question is not whether the editor supports a setting somewhere. It is whether the selected runtime can represent the effect the team is shipping.

This tutorial adds a small compatibility gate to a proposed PixiJS and Three.js comparison. The purpose is to make unsupported behavior visible before someone evaluates the screenshots.

Choose one effect and a narrow comparison

Create an original short burst with a simple unlit particle appearance. Use a portable target, disable looping, and avoid imported meshes for the first comparison. Keep the same authored source and random seed for both hosts.

The comparison should answer three separate questions: does the export declare support, does each host load the required files, and does the effect look acceptable in the intended scene? Passing the first check does not answer the other two.

The NixieFX runtime documentation describes the export and renderer boundaries for this 2D and 3D particle editor. PixiJS and Three.js should not be treated as visually interchangeable: PixiJS lacks mesh-surface emission and lit shading, and editor preview bloom is not exported.

Make a strict review policy explicit

The helper below consumes the documented per-backend status fields. Its deliberately strict policy accepts only an explicit supported status. A partial report may be usable after a human reviews its approximations, but this particular comparison should stop there until that decision is recorded.

export function inspectTargets(compiledEffect, targets) {
  if (!Array.isArray(targets) || targets.length === 0) {
    throw new Error("Choose at least one target");
  }
  const reports = compiledEffect?.support?.backends ?? {};
  return targets.map(target => {
    const status = reports[target]?.status ?? "missing";
    return { target, status, allowed: status === "supported" };
  });
}

const sample = {
  support: { backends: {
    pixi2d: { status: "partial" },
    three3d: { status: "supported" }
  }}
};
console.table(inspectTargets(sample, ["pixi2d", "three3d"]));

The sample is synthetic. It demonstrates the helper's decision and makes no claim about an actual exported effect. Local checks confirmed that a partial report is rejected, a supported report is allowed, a missing report is rejected, and an empty target list throws. These checks exercise the helper only, not particle rendering. Do not manufacture a report object in the real integration: read it from the compiled export and retain the original warnings for review.

Implementation steps for a reproducible render

Record the installed NixieFX and renderer versions in the project lockfile. Keep the authored effect in source control.
Validate and export that project. Save the generated manifest, compiled effect, referenced assets, and diagnostics together.
Run the helper on the compiled effect with pixi2d and three3d as the target list. Stop if either result is missing, partial, or blocked under this tutorial's strict policy.
Build one minimal PixiJS host and one minimal Three.js host using the installed package's integration examples. Load the export through the official bundle loader; the helper does not replace its validation.
Use the same fixed seed. Choose a documented scene scale for each host and a fixed camera for Three.js. Advance each renderer once per host frame using elapsed seconds.
Capture the burst at a recorded simulation time, then let it finish. Remove finished instances and destroy the owning renderer on scene teardown.

For a UI burst, the PixiJS host can place the effect beside a stationary marker. The Three.js host can place it at a stationary world point. Those are different coordinate spaces; equal numeric positions do not establish an equivalent composition.

Record evidence without claiming parity

The review record should include the source revision, package versions, export status, seed, scene scale, camera, capture time, and cleanup observation. Keep loading failures in the record rather than replacing them with an editor screenshot.

When implementing the comparison, capture one frame from each actual runtime at the same recorded simulation time. Label each capture with the backend, viewport, seed, and export revision. No cross-backend runtime captures are presented here.

The expected reproducible result is a compatibility decision followed by two independently inspected renders. The images need not be pixel-identical. Different cameras, scaling, material representation, and scene composition can change their appearance even when the shared effect data is valid.

What this gate does not prove

The helper does not parse assets, benchmark rendering, validate the complete export schema, or inspect visual quality. It only makes a team's acceptance policy for backend status explicit. Keep the official loader, actual screenshots, and human review in the workflow.

The useful failure is an early, readable stop: this effect needs a compatibility decision before it becomes a runtime claim in a tutorial or a shipped scene.

Resume an abandoned agent patch with a failing test, not a fresh prompt

Hiroshi TK — Mon, 05 Oct 2026 07:48:34 +0000

An agent has changed a retry helper, left a short note about “finishing the defaults,” and stopped. The developer who started the task is unavailable. Another teammate can run the project, but the conversation alone does not establish what the patch actually does.

Instead of starting with “continue the previous agent's work,” give the next runner a small failing behavior to investigate. A reproducible boundary turns a vague recovery assignment into a task someone else can execute and a reviewer can assess.

Here is a deliberately small, hypothetical example. The function and input contract are invented for this tutorial; they are not taken from a production incident.

Establish the input contract first

Suppose an internal worker accepts a retry limit. The agreed contract is:

None means use the default of three retries.
Zero means do not retry.
A positive integer is an explicit limit.
Negative values, booleans, strings, and floats are invalid.

Those choices belong to the application owner. If zero might mean “unlimited” in the real service, settle that decision before implementing this example. An agent should not infer the contract from a convenient language idiom.

The partial patch contains:

def retry_limit(value):
    return value or 3

That looks compact, but it collapses two different inputs into one result. Both None and 0 return three. It also accepts values the contract rejects.

Turn the uncertainty into a reproduction

Create a scratch file, retry_example.py, with the function above and this check beneath it:

assert retry_limit(None) == 3
assert retry_limit(0) == 0, "zero must disable retries"
assert retry_limit(2) == 2

Run it with an approved local Python interpreter:

python3 retry_example.py

The zero assertion fails against the partial implementation. That is useful evidence about this function. It is not evidence that a deployed worker has retried a real job, nor that fixing this helper will repair every call site.

In a real repository, record the exact revision and runtime version beside the reproduction. Keep existing uncommitted changes intact. Use the project's normal isolated-work workflow before experimenting, especially when another person may resume their own branch later.

Prepare a handoff that names the next action

The recovery coordinator writes a record like this. Replace the bracketed fields with observed values, rather than copying an old agent's assurances.

task: preserve explicit zero in retry policy
prepared_by: [recovery coordinator]
source_revision: [full commit identifier]
state:
  available: partial retry helper and original requirement
  unavailable: original author's unsaved local work
  acceptance: pending
evidence:
  reproduction: retry_example.py
  observed: zero is converted to three
  integration_checks: not run
next_action:
  implement: validate the agreed input contract
  verify: default, zero, positive, and rejected input cases
boundaries:
  exclude: queue behavior changes, deployment, new dependencies
  stop_if: a caller relies on coercing strings or booleans
handoff:
  runner: [teammate with authorized repository and tool access]
  reviewer: [owner of retry behavior]
  return: revision, diff, test output, unresolved callers

The coordinator prepares the work. The runner uses their own approved tools and identity to inspect and change it. The reviewer decides whether the result satisfies the contract. A task brief transfers context; it does not transfer an account, credentials, or another person's tool allowance.

An AI work handoff needs these boundaries even when everyone uses the same coding assistant. Wagglet for startups describes routing prepared work to teammates or agents without sharing accounts. The concrete artifact being routed here is the reproduction plus its acceptance record, not an instruction to trust a previous conversation.

Make the smallest change the contract supports

One implementation for this specific contract is:

def retry_limit(value):
    if value is None:
        return 3
    if type(value) is not int or value < 0:
        raise ValueError("retry limit must be a non-negative integer")
    return value

The exact-type check is intentional: Python booleans behave as integers in several contexts, but this contract rejects them. A service that accepts integer subclasses would need a different validation decision.

Extend the reproduction with rejected inputs:

for invalid in (-1, True, False, "2", 2.0):
    try:
        retry_limit(invalid)
    except ValueError:
        pass
    else:
        raise AssertionError(f"unexpected acceptance: {invalid!r}")

These checks exercise the chosen function contract. The runner must still inspect callers: configuration parsing may already coerce inputs, or another component may treat zero differently. Finding such a dependency is a reason to report a scope decision, not silently broaden the patch.

Return a reviewable result

The final handoff should distinguish the failing baseline from the submitted change. Include the tested revision, exact command, result, and any checks that were not run. Do not describe a successful scratch reproduction as a passing repository test suite.

The reviewer can then ask a focused question: does the patch preserve the agreed retry semantics at the relevant boundary? They may accept the helper change while requiring integration evidence before deployment.

This process will not recover inaccessible edits or resolve missing product decisions. It gives the replacement runner a concrete starting point, and makes the remaining uncertainty visible to the person responsible for acceptance.

A review contract for an AI-assisted VFX change

Hiroshi TK — Fri, 02 Oct 2026 11:36:20 +0000

An AI workflow for VFX integration needs a definition of success that survives beyond the agent session. A short contract can make that definition inspectable before the implementation starts.

Suppose a game already exposes an objective-completed event. The proposed change adds a brief visual response. It must not change how rewards are awarded.

Write the contract

Use the following as a task template. The durations are design targets for this example, not measured results.

change: objective-completion-feedback
trigger: existing_confirmed_objective_completion_event
scope:
  - one_visual_effect
  - event_binding
  - lifecycle_cleanup
out_of_scope:
  - reward_amounts
  - authentication
  - backend_schema
  - native_plugins
behavior:
  max_visual_duration_ms: 700
  repeated_event: no_duplicate_reward_or_parallel_feedback
  reduced_motion: static_label_and_icon
evidence:
  - exact_revision
  - reproduction_steps
  - normal_and_repeated_event_recording
  - teardown_check
  - actual_test_environment
review:
  visual: assigned_artist
  integration: assigned_engineer
  release: assigned_release_owner

Before starting, replace role labels with the people responsible and the event label with the actual repository symbol. If the event does not exist, stop and agree on the expanded scope.

Keep state and presentation separate

For a project using SpacetimeDB, route the visual from the game’s existing confirmed state. Do not add a second reward operation to an animation callback.

For a PixiJS HUD or a Three.js scene, define where the effect lives and who owns its cleanup. In a project that uses both, decide whether both layers need feedback; two celebrations may compete for attention.

For a Capacitor build, include a real device check before claiming mobile support. Browser playback answers a narrower question.

Exercise the failure paths

The happy path is one completed objective and one visual response. The review should also cover a repeated event, a scene exit during playback, a failed asset load, and reduced-motion mode.

If the asset fails to load, preserve the underlying completion state and text feedback. If the scene closes, remove its event subscription and effect resources. If reduced motion is enabled, communicate the same outcome without requiring the animation.

Record observations for each case. A checklist is a plan until someone runs it.

Make the handoff readable

The delivery should let the reviewer locate the code, reproduce the behavior, and distinguish checked conditions from assumptions. That is the organizational problem discussed in Wagglet’s game studio workflow article.

A finished implementation is only one stage. Visual approval, technical acceptance, and release remain separate decisions, each tied to the same revision.

Tie Human Approval to the Exact Version an AI Agent Delivered

Hiroshi TK — Thu, 01 Oct 2026 11:23:27 +0000

A reviewer approves a change. An agent then makes another edit. The task still shows “approved.”
That is an easy workflow mistake to make when approval belongs to a task rather than a particular delivery.
A practical review process should answer three questions: what was reviewed, who reviewed it, and what changed afterward? You can model those questions without building a large approval system.
Keep the delivery and review separate
Consider a hypothetical task to improve a form’s validation message. The agent prepares the change. A teammate checks the interaction and error wording. An engineering reviewer checks the implementation.
The delivery record should identify the submitted version and its evidence. The review should identify the same version and record the acceptance decision.
Here is a small JavaScript example:
`

javascript function canAccept(task, delivery, review, actorId) { return task.status === 'awaiting_review' && Boolean(delivery.revision) && delivery.revision === task.currentRevision && Boolean(delivery.evidenceUrl) && actorId === task.reviewerId && actorId !== delivery.runnerId && review.revision === delivery.revision && review.decision === 'accept' && Boolean(review.note?.trim()) && task.criteria.length > 0 && task.criteria.every(id => review.checks[id] === true); }
`
This function assumes the records have already been validated for their expected shape. It illustrates a workflow rule; it is not a complete authorization system.
Try it with these sample records:

const task = {
  status: 'awaiting_review',
  currentRevision: 'rev-2',
  reviewerId: 'reviewer',
  criteria: ['behavior', 'scope']
};

const delivery = {
  revision: 'rev-2',
  runnerId: 'runner',
  evidenceUrl: '/evidence/rev-2'
};

const review = {
  revision: 'rev-2',
  decision: 'accept',
  note: 'Checked the error message and confirmed the change stayed in scope.',
  checks: {
    behavior: true,
    scope: true
  }
};

console.log(canAccept(task, delivery, review, 'reviewer'));
// true

console.log(
  canAccept(
    { ...task, currentRevision: 'rev-3' },
    delivery,
    review,
    'reviewer'
  )
);
// false: the approval does not cover the current version.

The revision labels and evidence path are illustrative. In an implementation, use an immutable revision identifier and evidence tied to that revision.
Make each criterion inspectable
A checkbox called “looks good” leaves too much interpretation to the reviewer.
For the validation-message example, define observable checks:

Submitting an empty required field displays the agreed message.
Correcting that field clears its error.
The change leaves unrelated validation behavior unchanged. A review note should explain what was inspected and any remaining limits. Checking a field in a record does not prove the underlying behavior works. During preparation, the function was checked against six illustrative cases: a valid acceptance, the wrong actor, an outdated review, missing evidence, an unchecked criterion, and a newer task revision. Those cases passed their expected assertions. They do not establish production security or integration correctness. Enforce the rule where acceptance happens In a real application, derive the reviewer’s identity from the authenticated session. Do not trust an identity supplied in a request body. Load the current task and delivery from trusted storage. Check their revisions and apply the acceptance update atomically, so a new delivery cannot arrive between the check and the update. Keep an audit record of the decision. An AI team management platform can store those records, but the team still has to decide which judgments belong to qualified reviewers. Wagglet’s discussion of meaningful work with human–AI pairs provides the broader context for making that human contribution explicit. Preserve the work behind the approval The person who reproduces an issue, identifies an ambiguous requirement, or rejects an incorrect fix has contributed to the outcome. Keep that work visible. Record why a delivery was returned, what evidence was missing, and which specialist was needed. Include that review time when evaluating the process. A new version should create a new review obligation. Otherwise, the approval stops describing what a person actually checked. https://wagglet.com/blog