since I'm probably only going to need like 5 different types of effects, this is a mechanically hardcoded effect (details can still be configured though)
was considering making a particle system but it's unlikely to add value for me
idk if you've noticed but particle systems kind of suck at mechanical customizability but also require a lot of work (with the amount of work being roughly proportional to modularity; UE spends something like ~0.5MLOC on particle system alone)
here's some particle generation code so far
a component of velocity is a sinc(-ish) wave based on particle's distance from last impact
particle size depends on prior recorded impacts - with the assumption being that the previously damaged areas would result in smaller particles
how does one even begin to make a system for any of that? custom per-instance data passing protocols? how do we encode an array?
particle systems are as much of an insanity as any precog design
that said, there is a role for being able to operate with easy primitives and quickly iteratively tweak things with live preview
I can't say I have *the* answer for how things should be developed
and this definitely wouldn't work for beginners (basic inflexible systems still help there)
but stuff like UE Niagara to me isn't the answer either
apart from the prefab behaviors (rendering, physics) that it offers, it's no less complex than writing the code, arguably even more
another funny thing that I had also noticed most AA-AAA effects are still pre-rendered (or pre-designed) sprites/spritesheets
because effect quality generally doesn't increase with pure particle count
so most effects are so basic that they'd have no issues running on the CPU
there's basically one exception which is sparks - since they are small and require world collision
but upending your entire design for just one exception doesn't make a ton of sense to me
https://mamoniem.com/behind-the-pretty-frames-pragmata/ here's one of the most recent examples (the full game isn't even out yet)
IIRC there were just two GPU particle systems, and they were used to drive 10s of particles (maybe up to low 100s, haven't played it myself)
did that genuinely require a GPU particle system at all?
and out of the effects described in the post, all the remaining effects were just layered designed sprites
IIRC in Doom (2016+) blood spatter was individual spritesheets as well
returning to my own game projects for a bit, I expect to avoid the need for GPU particles for most effects as well
the effect types I'll probably have:
- damage & splatter decals (already done)
- fragmentation (doing now)
- dual-slice animation (prototyped a year ago)
- smoke (both focused and diffuse/fog-like)
- [maybe] rain
- [maybe] sparks
all of them are fundamentally different systems (with some overlap for focused smoke/sparks)
out of these, decals and rain have nothing to do with typical particles
decals are mesh slices or projections
rain is a combo of fog, animated cards wrapped around the camera, splashes on surfaces (where the sky is visible) and maybe screen-space droplets if you look up
but the rest also have complications:
(see above for fragmentation)
- dual-slice needs anim sync between slices
- smoke ideally needs some area adaptiveness
- sparks need to simulate camera motion blur
but the other issue with particle systems is that they're like 100x more code than doing the minimal thing directly
the main difference being UI (IIRC roughly half of UE's Niagara was editor code)
but also when you go from one struct/one array to generic attribute arrays and configurable steps, the overall complexity tends to skyrocket
suddenly a "generate random velocity" half-line of code becomes a module where you configure which attribute even is velocity
Arvīds Kokins