So I tried just using navmesh in the beginning, but it solves on the mesh, so it’ll cut corners and look sloppy on a grid. I was ok with it at first, but given that navmesh was in process at the time, it didn’t solve around other characters (it may do better now, haven’t checked).
So then I implemented A* to get points on the grid to move to using the navmesh and then I’d just update where the guy was moving as he got close enough. But I kind of wanted precise movement all the time, so I went ahead and just started manually moving the characters.
I can see about posting up my pathfinder stuff, but it’s really based on what I’ve been doing so there’s a ton of assumptions about offsets.
If the tile doesn’t have any depth or is not a closed surface, the Auto Convex Collision tool will probably fail. I’d advise importing a new hex specifically for collision, don’t over write your render hex, just create a new slightly extruded one.
How are you creating your map generator? Level Blueprint?
I recently moved the creation of everything to my Game Mode (btw, everything has access to the game mode, you should totally use a game mode), so in my level there is one actor, basically a bucket that just holds values for the map generator. At the start of the game, the Game Mode creates the 2 actors needed for the map generation: my random quadtree generator and the actor that will house all the renderable tiles (and that also does all the leg work for creating the tiles). Once the map is made, the Game Mode creates the pathfinder using the array of walkable tiles from the tile generator. Finally, the Game Mode makes the unit manager because it now has an array of tiles for legal spawn points. The unit manager spawns your team, then your camera actor, then a random number of other teams based on map size and individual room size.
There’s a ton of custom events, functions, and variables being passed around. So the Game Mode stores references to all the major actors for later communication (the tile generator may not know about the pathfinder, but the game mode knows both and can request from one to pass to the other).
So where my mind was at in what I mentioned is that each map (or cell) would actually be 2 actors, one hidden, one rendering, and they’d both reference each other. The Game Mode or some other uber blueprint would create them and reference them. When a major change occured on the map, you could send a custom event + the new hex array to the hidden map/cell. This event would cause it to build the new instanced static meshes, then make itself visible, and then call a function/event on its sister map. This function/event would hide that actor, and clear its instanced static mesh actors.
Then there’s some bits in figuring out which one to send to but really it could be as simple as “which one is hidden.”
Potentially, this could occur in parallel with other stuff going on, and it will just finish up and pop in.
Right, but it’s about balance. Maybe you don’t need to do that, it could be the regeneration of the map is actually really quick because all you’re doing is clearing the static mesh actors then re-adding instances, and no crazy memory stuff happens (don’t really know). The worst case for that would be Cells*Total Tile Types in draw calls. But you’d have to balance that against units, tile flare, how many cells can be visible, vfx, tiles having more than one material, lights, etc…
Nice! =) What was the generation time on that?