Just a few BP rules I live by. Which do you agree/disagree with? What would you add?
I wrote this to a small team I've assembled for my next game and was thinking about "what do I like to see/do in BP?"
* I tend to colorcode things: * **Yellow** \- Upmost important (init, tick, begin play only) * Think cautionary, lots of important stuff that is potentially fragile happens here. * **Green** \- The way the actor interacts with the world. * I call these "gates" for gameplay logic to enter the character. * Inputs, Collisions (yeah I know one of them isnt green here) etc. This is how the actor gets informed of stuff going on or has to respond * These tend to be very simple, with simple questions to get us into: * **Grey -** the grey matter of the actor! (get it?) * These are the important logic things. Once you're through the gate, you gotta figure things out, react, do all the complicate stuff. The "thinking" Grey. * **Red - TODOs, Questions, or Help** * Something that isn't done yet or, I need help on as I don't know the right path. Requires revisiting very soon.
Rarely I use blue, I haven't found a good reason for it yet. Maybe In Progress? That could be a good idea.
Other rules I like:
* Try to Square things off. Noodles floating all around is silly. Having them squared off is easier to read * Have them lined up in logically makes sense. Inputs in one area, Interacting with the world, Collisions, all those logical groupings. * Once sorted, try and keep them sorted. That way everyone knows where to look when we open up the BP * It's ok to make a first best guess * Start monolithically, try and figure things out * Use comment blocks to psuedocode out ideas first before writing actual blueprint/code * Once I have to zoom out to -12 (middle mouse wheel out, top right you'll see -12) **that is a sign that you need to break things into components now.** * Up until then, I am still trying to figure things out * An event should try and do one thing * Break up events so you don't have super long chains. Each event or function tries to accomplish one thing * Always avoid Casting, force yourself to Interface and/or GetActorByTag * Blueprints are notorious for loading too much too quickly. eg. an old project of ours had a single shipping BP that *loaded the entire Developers folder*. Blueprints just quickly waterfall! * Building events as Interfaces forces you to figure out exactly how each actor should talk to each other, with as minimum data as possible. This leads me to: * **An Actor is Responsible for Itself** * Does Actor A have to tell Actor B to move with a force or be destroyed? Actor A then sends an interface message to Actor B to forcefully move or die, and Actor B actually has the AddForce or Destroy events. * This makes it so if you're troubleshooting issues, you know if it's with a particular actor, it's within the logic of that Actor, and not scattered throughout BP. * Inherit as much as possible. Build parent actors that do most of what you want and then special sauce the inherited as you need. * eg the tools probably all pull from the same tool for general logic * Always turn off: * Tick Enabled at first on BP. Turn it on if you need of course. Disabling project wide causes weirdo issues though * Turn off Generate Overlaps at first. Same as the above, turn it on as you need. * No silent failures. Every Failed/etc (like cast failed) should result in a print string * Take advantage of functions not everything needs to be a event on the events graph * Use Categories on properties/functions to group things together * Leverage multiple event graphs grouped by functionality/use case when functions or macros will not work
\----
Figured I'd share and see what you all think 😄