Create Level class?

[RumbleMonk]

Hi, I'm trying to be a bit smart with how I create my levels. Currently I have some stuff that gets run once when the map gets loaded, but I aim to have lots of levels and any change I make to how I handle my level data in the future would mean I'd have to go into every single level BP and copy/paste nodes.

Is there a way to make a level class that has all my level BP nodes and create level sub classes from that?

If there's a better way to deal with this I'm all ears.

Thanks!

[arbopa]

Would like to know this one too, as it seems you can not make 'children' levels like you can with BPs.

[Staggerlee]

blueprint function library springs to mind as a work around

[jwatte]

Another option is to have a "level populator actor" which you can place into each of the levels, and have that actor (rather than the level blueprint) do the heavy lifting.

In general, the level blueprint should have as little code/nodes as possible. Just a few event handlers that immediately delegate to GameInstance, GameMode, or some known Actor in the level.

[arbopa]

What is a level populator actor? Have not run across such a thing.

[jwatte]

What is a level populator actor? Have not run across such a thing.

It's an actor of some class that you define, which you make do all the heavy lifting. There's no pre-defined class for this, but a pattern of building a blueprint actor that does all the work, rather than doing the work in the level blueprint.
The level blueprint could find this actor (for example using "all actors of class") and tell it to do its thing. All you need to do in other levels is to copy/paste this start-up code; any changes are made in the blueprint actor, which is re-used/referenced in each level.

[Slavq]

I've had the same idea about making some parent class for levels But since it's impossible, the "level populator" object seems like a good idea.
BTW, with 4.9 there came some new 'level interfaces', but they probably won't help here.

[Variss]

All of my level data/calculations are done using a custom GameMode class rather than the level blueprint (i use GameMode as sort of a level manager). I then just set the GameMode for each level as my custom class. Should be able to make any changes needed then and it will copy through to every level that uses that GameMode. Would something like that work for your project?

[ZoltanJr]

Yep GameMode is definitely the way to go for this. Then You could use a data table to store the values for what each of the levels should do.

[jwatte]

GameMode is great for things that can happen on the server. The GameMode is not available on the client if you run multiplayer.
GameState is sometimes a good alternative.

[Slayemin]

I stopped putting logic in the level blueprint because I wanted to have the same behavior across multiple levels. I made an effort to put as little 'code' as possible in the level blueprint, and instead, put it into the game mode class, game state class, game instance class, or use blueprint communications to have objects talk to each other. This lets me create any kind of level I want and just set a game mode for it and all of the game logic is brought over.

Some props and blueprints will need to know about other ones. Maybe you have a button which opens a door blueprint. That's pretty easy to setup with instanced references which bind the button to the door you want it to activate (preferably using Blueprint interfaces).

[arbopa]

I stopped putting logic in the level blueprint because I wanted to have the same behavior across multiple levels. I made an effort to put as little 'code' as possible in the level blueprint, and instead, put it into the game mode class, game state class, game instance class, or use blueprint communications to have objects talk to each other. This lets me create any kind of level I want and just set a game mode for it and all of the game logic is brought over.

Some props and blueprints will need to know about other ones. Maybe you have a button which opens a door blueprint. That's pretty easy to setup with instanced references which bind the button to the door you want it to activate (preferably using Blueprint interfaces).

All makes sense. I was gonna ask about where you put the code for something like a door that opens.

[eXi]

All makes sense. I was gonna ask about where you put the code for something like a door that opens.

Simply into the Door Blueprint.
The door might open by an Overlap combined with enabled Input and pressing a 'E' Key.
Or you press a button next to the door that opens it. The button could be created as a StaticMesh + Collisionbox in the DoorBP too
or it is an extra BP with a Reference variable of the door that is set to "editable" and you can just use the pipette to fill the reference with
the placed door.

Check out my "reference and blueprint interaction" project that you can find in my Free Learning Projects thread that i have linked in my
description right under this post.

LevelSubclass can be created in C++ as far as i know, but BP has its limitations (again a limit that you might want to tell someone if he asks
what BPs can't do). But you can use the GameMode class for things like this, or the GameState class.
Also spawning and referencing ManagerClasses like someone above suggested is a good idea.

[arbopa]

Check out my "reference and blueprint interaction" project that you can find in my Free Learning Projects thread that i have linked in my
description right under this post.

Thanks, will check it out.