Hi,
I have some confusion in blueprints. So may be you guys can suggest a good way.
What should be the ideal Blueprint structure for a RTS game like commandos, where the player plays with 4 or 5 characters?
I am working with a player controller blueprint as player controller class, and the characters are of character blueprints. Most of the actions are in the player controller blueprints. Is it right?
And there are a lot of casting to the character blueprints and some 4 to 5 tick events. And may be these tick events are making the gameplay laggy.
And can I cast from a character blueprint to a player controller blueprint? Is there is any hierarchy of blueprints on which casting depends? Because I cant have any tick information form other blueprint, only I get in player controller from all other bluprints. So, the player controller is getting very heavy.
As long as it’s single player you don’t need to worry at all. Only when it comes to multiplayer networked games is when you need to start worrying what is replicated to other players, what is executed client side and what is done on the server side.
For a single player game there’s nothing you can do wrong - if it works it works.
What you noticed correctly - if performance is getting a problem then try to be stingy with “on tick” events since these are fired at least every frame. Normally if there’s not very costly actions (Like “get all actors of type”) in them it’s still not a problem, usually it takes massive abuse to get a game laggy, but yeah if you have like a 1000 soldiers on screen and grab all of them with like “get all actors of type” serveral times a tick you’ll run into trouble. But most costly functions have a fair warning in the description.
Yeah big problem for beginners - there’s no “global” funcions or variables. You can cheat a bit by using something like “game mode” as a global and cast to it, but generally - if it works fine in your player controller then it belongs there.
Also neat to know - your level blueprint can access pretty much everything. Drawback is that you can’t access functions or variables FROM the level blueprint anywhere else (Exception is an event dispatcher, but it’s a bit annoying to use i find).
Sometimes i wish you could put every reference in every blueprint and call every blueprint function or variable from everywhere. But yeah that’s not how it works, so you gotta get used to determine which function fits into which blueprint well. But as long as you can cast it you’re doing it right.
For a final release you can compile blueprints to C++ which speeds up complicated stuff really a lot, but I’d keep that as “last resort”.