I’m away from my PC this weekend, but was thinking about the refactor task I need for Building the Gameplay Loop
Basically I wrote down the thought for pulling the particle logic into its own actor component, and determined the name should probably be something like ParticleController
This way I can avoid doing too much C++ work with the particle system itself, because its something that works so much more intuitively with blueprints.
DIdn’t want to go too far down the rabbit hole with this one though, as I’m thinking about this away from the computer.
I do like how this pattern of thinking about things in terms of controllers is starting to repeat itself in the codebase naturally. It reduces the conceptual overhead of the project if the software design develops naturally repeating patterns.
I’d like to explore this thought:
A controller manages the lifetime of an object
Having this really clear separation of what a thing does vs. when a thing does it is so important.
I think much of the spaghetti in my code comes from conflating the two- coupling connections between distinct objects because I need a way of triggering some logical event after another logical event.
The major concern of my design in 
Designing Core Gameplay Loop is through decoupled event management.
Although it occurs to me this is achieved through controller managers, which buddy considered a code smell.
Is there a CRUD equivalent for Lifetime management?
Create, Initialize, Update, Destroy?