"Best" practices for organizing blueprints.

[bokuden]

Hey guys,

So I'm prototyping my game right now and I'm coming to a point where I think I might need to take a look at where I have the logic in blueprints placed. For instance, my player controller blueprints contains pretty much all of my movement mechanics, gun controls, etc.. Also, should I have separate blueprints for different weapons that handle their own unique firing modes and mechanics? This would be triggered by a custom event or..?

I've read varying things regarding this setup.

I know the basics of blueprint communications but I guess what I'm looking or is a higher-level overview of how these should all be organized. If there are any other visual people out there like myself, a graph or something would be great!

Thanks guys!

[Narghile]

Hi Mate

As simple overview. Keep you data close to the BP.

You could run everything in one BP, but OMG, save time is horrible, I made a game from 1 BP, every save takes 5-10 seconds.

You could have all gun data in one BP, would cut back on casting.

Casting could also be your downfall, if you can, reducing casting if possible.

So guns in one BP, Player Data in another, inventory in another, etc.

This does a few simple things, allows debugging easier, neaten your work up.

Do not discount functions to get a lot of stuff done.

I know it is not the perfect answer, but will give you a basic guide.

Narg

[Stuckbug]

Generally, you want to figure out the best way to make things modular, and break it down in that way.

So in the case of different guns, it probably depends on how different each one is, but you'd probably want to create a base class that contains shared functionality (ammo counts, reload times, etc) and make a child for each one that contains the data that's not shared (mesh, animations, sound & FX).

You also want to think about which way information needs to flow. Typically, since the pawn & controller are high level classes, they are good managers for general information. In the case of the gun, I'd probably build something into the pawn that allows for the pawn to hold a general "weapon" blueprint type (an array of BP_Weapon for example). That way you can assign different weapons and aren't carrying the data for everything at all times.

As far as triggering, I'd probably use an interface... like each gun implements something like BPI_GunCommunication and on input event "fire weapon" you call the interface on a reference to whatever gun is equipped, and a "stop firing" on release of the "fire weapon" event.

I'm not working on anything that uses that sort of system personally, but I think generally you want to figure out how much functionality you can make modular, and cascade down through the children. Also, architecturally, you should think about what needs to communicate with what. The controller needs to tell the pawn to fire which needs to tell the gun to fire, but does the gun need to tell the pawn anything? Probably not, so it makes sense as a child.

[bokuden]

Thanks for the tips guys.

When I get off of work I will update the thread with some questions I have!

Regards.

[bokuden]

So I hate to ask this, but can anyone provide some screenshots of "properly" organized controller and character bp?

I just need a visual reference when looking at mine to really understand the flow that is supposed to be represented with these.

Thanks for any help!

[Nawrot]

You say you would like tutorial (or bunch of small examples) about all tiny things that make blueprints more tidy?
While developing our game we worked out some tricks to make our life with blueprints easier.
And we probably share this soon, I was not sure if there is need for such tips, but apparently there is.

Easiest way to organize pawn and controller is by thinking like names suggest.
Pawn is a puppet (your puppet on screen) while you are inside player controller.
Yes pawn can get input, but then you will create all input and character logic (like inventory etc) in single pawn.
What will happen if you later want add different pawn? You will recode all input and pawn logic, instead of just pawn.

So Player controller collects all input. And has dispatchers for events like "go left" "jump" etc.
Then pawn on begin play binds all those dispatchers.
Same goes for hud, you make dispatchers in pawn or player controller which fire off when hud update is needed.

[C-Arch]

One tip is to find color schemes that work for you.
For example for me... anything movement related is green, attacks are red, blue is begin play events or logic that runs at the start, orange is anything connected to a tick and so forth.
Collapse nodes, make use of Macros and functions.

I have a color highlighted sticky note with the names written on them in case i forget which color is which.