Keep crafting sparks inside the inventory slot’s visual budget

This post specifies a bounded effect and host integration; the art values are proposed targets rather than results from a supplied effect bundle.

A crafting success cue belongs to a specific inventory slot. If its particles spill across item counts or nearby controls, the effect makes the result harder to read. The integration should bound both the event count and the visual area.

Start with one successful crafting transaction and one slot anchor. Do not trigger the effect when crafting begins, because a rejected request should not look like a completed item.

Use success identity, not button activity

A double click can create repeated UI callbacks even when the application accepts only one craft. Drive the cue from the confirmed transaction identity and ignore repeated delivery of the same success event.

export function makeCraftCue(play) {
  let lastTransaction = null;
  return function confirmed(transactionId, slot) {
    if (!transactionId || transactionId === lastTransaction) return false;
    lastTransaction = transactionId;
    play(slot);
    return true;
  };
}

This intentionally small controller remembers only the most recent transaction. If older events can arrive out of order, use a bounded ID cache or an authoritative event sequence instead. Do not claim general network deduplication from a one-value memory.

Author a restrained burst

A proposed first asset uses eight particles, no continuous emission, a maximum lifetime of 0.3 seconds, and an upward-biased spread. Keep the brightest area above the slot center, with a short fade before particles reach the neighboring label. These are design targets for review, not measured runtime performance.

Use a distinct effect ID such as craft-slot-spark. Export for PixiJS and inspect the support report. A web game particle editor can make this visual envelope easy to revise; NixieFX's PixiJS workflow explains the bundle path to the host application.

Convert coordinates at the boundary

The slot may live inside a scrolling or scaled container. Obtain its anchor in the effect layer's local coordinates before spawning the cue. If the slot scrolls out of view, skip the decorative effect while still updating the item count and success state.

Choose one policy for overlapping crafts. For example, replace the existing cue for that slot instead of adding unlimited new instances. That bounds visual density during rapid crafting without changing the number of successfully crafted items.

Confirmed craft -> update inventory state
               -> update visible count and success label
               -> reduced motion? keep static confirmation
               -> visible slot? convert anchor to VFX-layer coordinates
               -> replace that slot's previous cue
               -> play one verified bounded burst

Make the result inspectable

Capture the actual Pixi screen with the item count and adjacent slot visible. Include the effect source and host integration with the post, so another developer can reproduce the envelope rather than judging only a cropped image.

Test one craft, a repeated event, rapid distinct crafts, a scrolled slot, and reduced motion. After all bursts finish, confirm that the host removes finished instances. On screen teardown, release the owned resources even if a burst is still active.

Limits worth preserving in the write-up

This controller is not the inventory transaction system. The particle effect cannot confirm a purchase, award an item, or prove a server operation succeeded. Those facts come from application state.

This guide does not establish a device performance budget. Profile the actual asset in the intended layout. Unsupported settings are those blocked by the export's Pixi report; any partial support needs a specific explanation after the asset is available. Publish the visual result only after those checks, and distinguish the tested source from the proposed art targets.