“And what, Gul’dan, must we give in return?” - “Everything.”
And I’m ready to do that - time, nerves, sleep - I’m here to learn.
The plan is to make a tiny prototype, in which the playable character can move tile-by-tile across a handcrafted hex map similar in style to “Reefland” (Reefland on Steam).
So far, I managed to create a HexGrid (instanced mesh spawning an instance/child actor for each tile) that allows me to select how many tiles the map should have along the x- & y-axes, as well as offset between tiles, and scale. Here’s a list of the most burning questions that a google search didn’t do the trick for - any pointers, tutorial links, keywords to look up, handy blueprint nodes etc. are much appreciated.
Make the HexGrid (instanced mesh) number each tile (instance/child actor)
Create a selection tool that lets me select any given tile (identified by its number) in the HexGrid (instanced mesh), and adjust its height. This will influence terrain type.
Create a turn-based movement system based on the HexGrid (instanced mesh), which has the player character move from tile to tile on a mouse click.
Make the hex grid number each tile-
if the tiles are added to an array when spawned (Say, HexArray) they will be given an index number automatically. There’s a multitude of things you can do with that index integer, plus they’ll be in an array in case you need to search them
Create a selection tool that will select any given tile in the hexgrid instanced mesh and adjust its height-
If you’re meaning in game? You can do a cast by channel under mouse cursor and return the first “HEX STATIC MESH” or whatever and then with that returned object, make functions to move it up/down/ change material/what have you.
Turn based movement system based on hexgrid? Honestly I can’t help you with that one. I have done square-grid but not hex, so I’m lost there. BUT you will definitely need to use the Navmesh for movement. You’ll need to attach a movement node of some kind to the hexes since they will be dynamic. You will HAVE to use a dynamic Navigation mesh, for sure.
Hi @Mind-Brain, thanks a lot for your input
It seems like hex grids might perhaps be a bit too advanced & starting with a square-grid is the more viable approach. If you have more insights on that, I’d be equally happy to hear them!
I’m internally debating similar questions… instanced static meshes vs spawning new actors. most advice seems to lean toward ISMs.
i can generate a significant sized map either way and there is no doubt ISMs are substantially more performant initially. however I need my hexes to store or be associated with a decent amount of information - some of which can and will change at run-time - and by the time i start looking at workarounds and hacks to calculate/get this info that performance advantage quickly dwindles.
take for example, constantly showing the row/column the users mouse is howvering over through the ui. with spawned actors this is a simple mouse over event call passing a couple of ints to the ui and bob’s your mothers brother… with ISMs the mouse call is a manual check per tick. on success pass in the index to an array to pull (i assume) the relevant vector3 (unless you’re runinng an STR array, which… whoa f$&k that). calculate the hex’s row and col based on the vector then pass that to the ui. every. single. tick.
point is, it really does depend on need. if your hexes can be ‘dumb’ then ISMs are usable. for me, writing a 4X type game, i don’t think they’re an option.
