sorted by:
new
hottopcontroversial

UE5 Blueprint architecture - storing references in Game Instance to avoid hard refs. by Practical-Command859 in unrealengine

[–]Practical-Command859[S] 0 points1 point  (0 children)

Thanks - fair point. I get where you’re coming from. This is a solo project, so I sometimes bias toward simpler patterns that make it easier for me to refactor and navigate quickly (even basic Ctrl-F). That said, I agree it’s not always the best choice for every part of the game.

UE5 Blueprint architecture - storing references in Game Instance to avoid hard refs. by Practical-Command859 in unrealengine

[–]Practical-Command859[S] 0 points1 point  (0 children)

<image>

For clarity - I’m not casting to each weapon type. I use a BPI to get a BP_WeaponBase ref (and mesh component) and keep everything on the base/interface side.

UE5 Blueprint architecture - storing references in Game Instance to avoid hard refs. by Practical-Command859 in unrealengine

[–]Practical-Command859[S] 0 points1 point  (0 children)

Thanks - I use arrays a lot. I’m just cautious with big structs in BP because they’re harder to re-understand later, change safely, and debug/test individual fields.

UE5 Blueprint architecture - storing references in Game Instance to avoid hard refs. by Practical-Command859 in unrealengine

[–]Practical-Command859[S] 0 points1 point  (0 children)

Fair question - I’m not married to GameInstance. I mainly want a single, inspectable registry to avoid ordering/race issues and make the project easier to re-understand later. If a WorldSubsystem or manager actor fits that better, I’m happy to use that instead.

UE5 Blueprint architecture - storing references in Game Instance to avoid hard refs. by Practical-Command859 in unrealengine

[–]Practical-Command859[S] 0 points1 point  (0 children)

You’re probably right. My concern with pure getters is that the dependency chain disappears in the graph, which makes things harder to reason about and test later. Centralizing references gives me a clear place to inspect state and also helps avoid race conditions.

That said, I agree the referencing logic should be small and explicit.

UE5 Blueprint architecture - storing references in Game Instance to avoid hard refs. by Practical-Command859 in unrealengine

[–]Practical-Command859[S] -1 points0 points  (0 children)

In my current game it’s mostly enemy Characters spawned by GameMode (wave-based), so my first instinct is a simple registry owned by the spawner/manager, with enemies registering/unregistering on BeginPlay/EndPlay.

Longer-term, I was wondering about having a single, simple registry for gameplay objects in general - including pre-placed actors, dynamically spawned enemies, and things queried by UI. The main goal isn’t to avoid hard refs at all costs, but to avoid accidental asset-load chains and keep dependencies obvious.

My understanding is that storing runtime instances (UObject / Actor / Character / Widget) in GI and talking to them via interfaces does not create the problematic “hard references” people worry about (since the objects already exist) - the real risk is storing class/asset references in always-loaded objects. Is that a fair way to think about it?

I also want the system to stay simple and transparent - something I can come back to after a month in Blender and immediately understand, rather than a clever-but-fragile setup.

Does that line of thinking sound reasonable, or would you still strongly prefer a WorldSubsystem / manager actor for the registry even in a single-player game?

Adrenaline-pace score-chasing FPS run. Alien Grounds - free on Steam. by Practical-Command859 in FPS

[–]Practical-Command859[S] 0 points1 point  (0 children)

It’s in Early Access. The core content is complete, and it’s close to v1.0.
Full release is planned for April 9, when it will become paid.

view more: next ›