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

#gamedev #enginedev

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

#gamedev #enginedev

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)

#gamedev #enginedev

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

#gamedev #enginedev

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

#gamedev #enginedev

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

#gamedev #enginedev

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

#gamedev #enginedev

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)

#gamedev #enginedev

on top of all that, it's probably also possible to resolve-and-resave the prefab format anyway so even if I do need edit-time resolving, having two different data formats for basically the same thing isn't especially efficient

actor templates had the special ability to do subtemplates with remaps of actor-unique component IDs, which allowed them to combine many things into one actor

now it might be possible to allow doing the same thing with prefab components

#gamedev #enginedev