I’m building a Fallout Shelter–style game (2.5D side view base building), but with a different theme and new mechanics. I’ve hit a wall at the very beginning with the build grid architecture.
I want a grid where each cell is 2×2 meters, and rooms/objects snap to those cells. I understand the basic idea, but I’m unsure what the “right” UE5 approach is.
A quick note about my workflow: I’m not very comfortable with Blueprints, so I work mostly in C++. Because of that, I really need a solution that’s practical to debug and easy to extend in code.
What I’ve considered / tried:
Actor per cell (array of actors) — very easy to debug and visualize (highlighting buildable cells, clicking, hover, etc.), but it feels heavy and “dirty” in terms of performance/memory if the grid gets large.
Data grid using structs (TArray of USTRUCTs) — seems like the correct way to store cell state, but:
debugging is mostly through the Details panel, which is not great;
it’s harder for me to implement visual cell highlighting (buildable/unbuildable), selection, hover feedback, etc., without spawning an actor per cell.
Questions:
What would you recommend as the best approach in UE5?
Should the “source of truth” be a struct-based data grid, with visualization handled separately?
If the grid is structs, what’s the typical way to do cell highlighting / debug rendering (without spawning an actor per cell)?
Or is it totally acceptable to use actor-per-cell for this type of game if the grid isn’t huge?
Any advice on a clean architecture for grid data + visualization + interaction would be really appreciated.
Yeah a huge array of actors would most likely cause hitching, especially if you iterate over them.
Maybe a detection actor with a 2mx2m overlap volume, updated every tick to the world location projected from the cursor. Change the color of a visual element (i.e. plane/building) based on overlap result.
Spawn multiple detection actors offset from the projected location based on the building’s required cell dimensions, and only allow building if no actors in the array of detection actors are overlapping landscape/meshes/blocking volumes? You’d have to store the required cell dimensions per-building in a struct containing arrays of integers or booleans or something.
Thanks — I like the detection/overlap idea for validating placement under the cursor and driving the green/red preview. That part makes a lot of sense.
However, it doesn’t fully solve my main problem: how to represent the grid itself long-term.
I’m currently stuck between two approaches:
A large array of cell Actors
I agree this can hurt performance (especially iteration / ticking / replication later), but it gives the grid a real world representation, which makes debugging and developing future mechanics (highlighting, occupancy, adjacency rules, pathing hooks, etc.) much easier.
A pure data grid (TArray of USTRUCT cells)
This is clearly better for performance and scalability, but then the grid has no physical presence in the world, which makes debugging/visualization and some interactions harder unless I build additional tooling (debug draw, instanced meshes, overlay rendering, etc.).
So my question is: in a Fallout Shelter–style base builder, what’s the best practice here?
Do you usually keep the grid as pure data (struct array) and build separate debug/visualization tools, or is there a reasonable hybrid approach that avoids thousands of Actors but still keeps the grid easy to work with?
If you have a recommended hybrid pattern (e.g., data grid + instanced visual overlay + a small number of helper actors for interaction), I’d really appreciate a concrete direction.
Gotcha, made my last post after working all day. Creating cell actors for the whole world would probably be fine as long as they’re lightweight (box, plane, bOccupied, bBlocked, etc.), and you’re initializing them all once and only updating/checking a couple at a time. I know large slot based drag/drop inventory widget containers have similar limitations.
If you want to debug visualizations of the entire grid at once, I don’t think there is a solution but to have many lightweight actor instances or a single actor/gridcontroller with many dynamically spawned boxcollision/static mesh components.
This would probably be the better choice; editor debug tools causing hitching wouldn’t be an issue, as long as you’re getting the desired result in a packaged game. It depends on whether you want visual representation of the grid at runtime.
If you just need the outlines of the grid cells visible in the packaged game, you could precompute a texture and project it to the landscape. You may also be able to use a rendertarget similarly to how snow/sand/grass interaction is done, and store occupancy / buildable location data that way.
This sounds pretty concrete to me . The fact that you’re planning on doing it in C++ gives you a huge leg up in terms of performance as well. Sorry I can’t help you past the overview, I’m a blueprint monkey.
Thanks a lot for your reply. I wasn’t sure what the best way was to implement the grid, and I’ve tried a bunch of different approaches so far since I don’t have much experience yet. But your answer was really helpful and gave me more confidence in the “array of structs” direction.
I’m going to leave the question open for now because I’d like to hear what other people think as well, but at this point I’m planning to move forward with a struct-based grid.
. The fact that you’re planning on doing it in C++ gives you a huge leg up in terms of performance as well. Sorry I can’t help you past the overview, I’m a blueprint monkey.