what is the convention for loading bulky script?

Has anyone else ever tried to nest arrays by nesting blueprint structures? I’m trying to create a 2d game inside a widget; that’s the best way I’ve found to display the sprites and the png image sequence animations. Once a level is selected the layout is randomized, then the level is displayed. I’ve created the randomization functionality inside a function graph inside the widget using the blueprint visual scripting system. The “script” is already pretty bloated, and the entire editor crashes when trying to add an array of integers to an array of arrays of arrays of arrays of integers; a few hundred times.

This can’t be the correct approach. I kind of need to use that structure format but
1: is there any way to get the blueprint visual script to run asynchronously so it can just take as much time as it needs?
2: should I be running this script elsewhere and feeding the resulting values back into the widget? somewhere associated with loading?
3: Do i need to be using CPP? it seems things can be done in CPP which just can’t be achieved elsewhere.

There isn’t much information out there about creating your own loading sequences in UE. it would stand to reason there should be an established convention for doing so. I know it’s kind of a big question. Thanks for your consideration, any advice at all would be greatly appreciated.

do not code inside widgets. Communication there is bad, also they inherit from object, not actor (missing a lot of functionality). Cannot be really destructed etc.

Use umg to what it was designed for ie. displaying stuff.

So create code in something like game mode. store your screen state in some array there. Read it and update widgets. Then do game loop in game mode, or player controller (it has it all: player input, knows its hud, widgets can get their player controller).

But honestly doing all those hoops for 2d game in unreal is like developing low level functions (direct drive access, or tcp ip functionality) in java script.

And on top of that if you ever want to deploy for mobiles, remember in unreal is almost impossible to fit game under that size limit of 100mb.

If its for fun project then sure, if you plan to release on mobiles, do GODOT.

ps.
If you (or anybody) are scared of CPP try chatGPT. Prototype function in bleuprints, then feed chat with precise prompt about what you want in function, it mostly creates ok results for CPP. Sometimes mixes things, but with bp prototype you can compare and fix code yourself.

3 Likes

thanks alot! I’ll paste everything over to a game mode BP for testing!

the script still crashes the engine when run in a game mode blueprint. The custom structures specifically. Ill move on to scripting in CPP next.
When I search about how to create a loading sequence in unreal all the results are about how to create a loading splash screen but never about how to script a sequence across multiple runtimes. Ive tried using delays to pass in to the next tick but it doesnt work quite right

that arrays of arrays of arrays … part.

You need to optimize code, split game in smaller subsystems.

Best way would be to create separate actors that have code, then inherit from them and make variations for different visuals. Like you make level tile parent class with all code, then inherit from it and make bricks , grass door etc. So you have single place with code , then child can have custom look while having same code.

So try to split whole script by type of game actor. also events, use events and dispatchers unreal is object oriented, but it really is driven by events, not OOP stuff.

I would say you should prototype game in 3d using sprites or plane meshes with textures. Do not worry about pixelated or fuzzy looks. That you can improve when you have code. For eg run game in 2d then copy game state (level tiles, character etc) into 2d in HUD.

However whole idea of game in umg is weird, you lose lighting for eg. And there are methods to render clear 2d objects.

Ps.
About arrays in arrays in arrayss part.
If you split game systems into actors, each actor can have actors inside or blueprintable components. And each of those can have multiple variables and structs insside.
On top of that they will be spawned and maintaned by unreal (like garebage collecotr etc).
So you can make hierarchy of actors. Each doing its own part. Then build wholes stuff like with lego.

1 Like

Unreal engine is so complex how does anybody ever get good at multiple facets of it? not to digress. from what Ive seen, renders produced in blender can be displayed exactly as produced pretty easily in a widget as a UI material or UI video material for animations. Im reasoning this will result in both entirely efficacious graphics and minimizing any processing strain asssociated with lighting in 3d. Im kinda proud, there hsnt been any quality playtesting yet but its really looking like it should work pretty alright!

Some years ago i learned it hard way to not go against what unreal was designed for.
And it was designed for creating FPS games. Yes epic did a lot to make it easier for kinds of projects, but that “multiplayer FPS” coder design is still there. Further you go from it more trouble you will have.

It is like “kicking contest with horse” you cannot win horse always will kick you back just much stronger.

And in case of unreal you have “kicking contest with multiple herds of invisible horses”.

You fix or overcome one horse, then another will appear because you did dirty fix at some place.

Recently i had about 1 month of struggle because that load order, and silly me wanted “modular” widgets that work for multiple scenarios/places. So i fixed widget referencing to just discover widget components on actors cannot do same, because they are constructed before actors they are on. Unreal is full of such “invisible kicking horses”

PS.
Have you found how to reliably place user custom widget at x,y coordinates in hud?
That is together with rescaling etc. And i am curious how do you calculate collisons?

1 Like

Ha! invisible kicking horses that got me. thats interesting Id be curious to see that project to see what you mean but I havent shared any projects online before I dont knwo how to safely.
I havent yet encountered an issue with widget positioning. things get funky when the window is resized so I include code to limit window dimensions to selectable presets is that what your refering to?
the game level is a 15 by 15 unit 2d grid the collisions nothing special:

if (currentPosition+1!=emtpySpace)
         return false;

return true;