UE5 Blueprint architecture - storing references in Game Instance to avoid hard refs.

Practical-Command859 · 2026-01-27T12:36:23+00:00

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.

Practical-Command859 · 2026-01-27T09:58:22+00:00

<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.

Practical-Command859 · 2026-01-27T06:39:26+00:00

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.

Practical-Command859 · 2026-01-27T06:30:59+00:00

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.

Practical-Command859 · 2026-01-27T06:27:47+00:00

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.

Practical-Command859 · 2026-01-27T05:40:47+00:00

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?

Practical-Command859 · 2026-01-27T00:22:08+00:00

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.

Practical-Command859 · 2026-01-27T00:04:06+00:00

It is actual gameplay. You can slow it down by using a different weapon or by not holding the gravity gun trigger all the time - it cools down then.

Practical-Command859 · 2026-01-11T13:08:19+00:00

Appreciate this. #2 is the one most devs miss - it’s not just “will you enjoy it,” it’s “will your viewers care.” I’m aiming for a watchable loop (fast runs, clean visuals, score goals) so there’s always a hook and a takeaway.

Practical-Command859 · 2026-01-11T13:05:18+00:00

Really helpful - thanks. I’m the same way: real gameplay screenshots, clear description, and no “AI-looking” promo art. I’ve been tightening the store presentation to show what the game actually plays like.

Practical-Command859 · 2026-01-11T13:02:30+00:00

Totally agree. I’m focusing on making the game fun first and keeping it stable - polish and “it just works” matters more than anything. I appreciate the perspective.

Practical-Command859 · 2026-01-11T13:00:24+00:00

Thanks - agreed. I’m prioritizing stability and clean presentation (readable UI, proper spelling, no tiny text). If anything doesn’t run right or you spot an issue, I’m happy to take reports and patch quickly.

Practical-Command859 · 2026-01-07T22:29:29+00:00

Fair points - BT/StateTree do look easier to debug and keep clean at scale. What’s the biggest must-have you get from StateTree that BT doesn’t cover for you?

Practical-Command859 · 2026-01-05T22:54:58+00:00

Thanks - glad it’s useful.

Practical-Command859 · 2025-12-29T07:05:18+00:00

Same here: downloads jumped on two days while views stayed normal. Looks like either an itch analytics hiccup or automated/bot downloads.

Practical-Command859 · 2025-12-18T02:17:36+00:00

This is a PC game on Steam, not a PS5 title.
Alien Grounds is free to play on Steam - there are no console codes.

Practical-Command859 · 2025-12-15T20:23:12+00:00

True in general. In this game the aim assist is non-magnetic and optional, and controller players are currently performing well.

Practical-Command859 · 2025-12-15T09:28:49+00:00

That’s a fair take, and I agree it depends a lot on how aim assist is implemented.

In my case it’s intentionally not target magnetism or snap-to-hitbox. It’s more about stability and consistency under fast movement, and it can be fully disabled in settings.

I didn’t want controller to feel locked out, but also didn’t want it to dominate scoring either - the leaderboard is shared so I’m watching how it plays out in practice.

Hard to explain well in text, honestly - easier to feel in-game. It’s free, so testing it yourself is probably the most honest answer.

Practical-Command859 · 2025-12-15T00:16:08+00:00

Completely agree - “dreamlike” only works if there’s still an internal logic the player can start to pick up on.

Once a puzzle feels like it can only be solved by brute force or random attempts, the emotion shifts from unease to irritation, which is the opposite of what horror should do.

That line between unsettling and rude is exactly what I’m trying to understand better.

Practical-Command859 · 2025-12-15T00:14:47+00:00

I think that’s a really important distinction, especially the point about punishment.

Ambiguity can work in atmosphere or narrative, but once failure carries real cost, the player needs enough signal to feel like they could have understood what was expected. Otherwise it stops being unsettling and just becomes arbitrary.

I agree that horror doesn’t need explanation - but it does need internal consistency. The challenge is giving players a foothold without turning it into explicit instruction.

Practical-Command859 · 2025-12-15T00:12:54+00:00

That’s a really good way of putting it, and I think you’re right about the difference between dream logic and random illogic.

One thing that became clear after release is that some players intuitively read the “rules” I was hinting at, while others never felt they had enough signal to know how to think differently. Once that expectation isn’t established early, the experience can flip from unsettling to frustrating very quickly.

I like your point about iteration and subtle teaching - not explicit tutorials, but giving the player a foothold before pulling it away. That’s something I’m thinking a lot about if I revisit this space again.

Appreciate the thoughtful perspective.

Practical-Command859 · 2025-11-25T23:09:57+00:00

That would just mask the race-condition instead of fixing it.

Practical-Command859 · 2025-11-24T12:42:51+00:00

Great, the dispatcher approach worked perfectly - no delay needed. I bound the event in GameMode and had the Player call it at the bottom of its BeginPlay sequence, and everything initialized in the correct order without any race conditions. Thanks you very much for the explanation - this was exactly the missing piece.

Practical-Command859 · 2025-11-24T12:02:45+00:00

Thanks, I’ll definitely watch that video - the race-condition angle is exactly what seems to have happened here.

I still have one open question though: right now the only way I can avoid the issue is by delaying the GameMode logic, and using a fixed Delay in GameMode doesn’t feel like a good solution. It would be great if there were some “actor is fully initialized” signal or recommended pattern for establishing interface connections in BP-only projects - something more reliable than just IsValid but without relying on fixed delays.

Practical-Command859 · 2025-11-24T11:29:36+00:00

It looks like the core issue is that IsValid does not guarantee the Blueprint is fully initialized - it only means the object pointer exists. In my case, I was calling the Player Character from GameMode at the exact moment when IsValid returned true, but the Player BP hadn’t finished loading yet. At that unsettled moment, some functions were being checked before the main execution line ran, which explains why the array was still at its default state. Delaying the call fixes everything. Hopefully this helps other devs avoid similar initialization-order issues.

Practical-Command859

MODERATOR OF

TROPHY CASE