Map Generator- Please Critique!

[Zeustiak]

@;28426

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.

Cool. Maybe I will play around with nav mesh to see how it handles, but manual movement sounds fairly straightforward for a grid map too. Can’t wait to start working on units!

@;28426

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.

Sounds good!

@;28426

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

Currently using a Class Blueprint for the generator, but game mode it is! Funny, I was thinking the same thing about the bucket, though I was going to put the whole generator in it.

So your generator is in the game mode, and all the variables that it references are in a hidden actor sitting somewhere in the world? So the one of the first thing my map generator will do is spawn the actor in the world that holds all the variables my generator is about to use? This actually seems pretty brilliant since it can then spawn a different actor that holds different variable values based on what options the player chooses in game setup. So maybe in that case it could be multiple actors. An actor for each player chosen map option; Temperature, Precipitation, Geologic Age, etc.

Of course I could just use a single actor and update the variables as well. I will play around with it and see which one works out the best.

@;28426

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.

That makes sense.

Have placeholder arrays to hold all the updated information and then have them transfer their information to the main gameplay arrays at the end of the operation?

@;28426

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…

Yeah, I will definitely try your base idea out first, scale it up to some huge map sizes, and see how it handles. If it bogs down or there are other performance/graphical problems I can see about parsing up the load.