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.
