I’d switch out using a mesh based system and start working purely with grid based math and materials. It’s not too difficult to do and would be more flexible (if you needed thousands of tiles, or something like a landscape or detailed world, this mesh based approach isn’t going to work!). It’d take some time to set up,but you could port across your theory relatively easy after the fact 
It is already based purely on grid based math, actually. You don’t need a single tile mesh to use the system in its current state. The meshes in the screenshots are just a visualization of the underlying arrays.
The only thing that is kind of mesh based at the moment is the level editor, as I think it’s the easiest and most intuitive to understand for new users. However, even these meshes are just blueprints with interfaces modifying the grid array, and can actually be deleted before running the game, and everything is still stored in the arrays. I’m planning to include other options for designing levels when using very large grids.
Sounds great! I’m keen to see it and offer advice if I can find any to give
[=;201341]
In the screenshot I’m using a grid of instanced static meshes generated in the construction script. Here is a closeup:
The tiles are just for show, however. The system works just as well with just a single collision plane for the entire grid. You don’t need individual collision volumes or anything, as everything is calculated using arrays and vectors. I’m going to include some various options for displaying the grid with the marketplace release, but how the grid is visualized is unconstrained by the system. If you wanted to make something really optimized, but still visualize the tiles, you could possibly use something like 's perfect tile system, where the entire level would just be a single mesh with a single texture.
[/]
Thanks for reminding me that existed. I was looking at that and I am still interested, but I don’t really know how it is supposed to work. You have a big plane and at Vector A you apply texture X, and at Vector B you apply texture Y? How do you talk between the blueprint and the material to make that happen?
As long as I can reach in and specify things procedurally, and I can get it to work on non-flat surfaces, I think it would pretty much be all I need except for the forests. I would also have to be assured that I could regenerate the entire thing reasonably fast with a new layout.
[=;201690]
Sounds great! I’m keen to see it and offer advice if I can find any to give 
[/]
Hope you’ll like it! I’ll keep working on the blueprint after it’s released and update it whenever I add something significant. Any suggestions for features are welcome, though I’ve built up a large backlog already. I try to figure most things out by myself, and only ask for advice when I’m really stumped (I see designing a game as a puzzle game in itself), but thanks for the offer!
[=;201698]
Thanks for reminding me that existed. I was looking at that and I am still interested, but I don’t really know how it is supposed to work. You have a big plane and at Vector A you apply texture X, and at Vector B you apply texture Y? How do you talk between the blueprint and the material to make that happen?
[/]
Honestly I know very little about materials. I’ve worked up a lot of very specialized knowledge about certain aspects of UE4 while still being a complete beginner in others. However, it seems reasonable that a system similar to ’s can generate a tile texture based on an array, and avoid the need for separate tile meshes for rendering a tile map. I believe this will be a corner case, though, and for almost all cases instanced static meshes will probably suffice (and even regular static meshes for some).
[=;201698]
As long as I can reach in and specify things procedurally, and I can get it to work on non-flat surfaces, I think it would pretty much be all I need except for the forests. I would also have to be assured that I could regenerate the entire thing reasonably fast with a new layout.
[/]
You shouldn’t have any trouble generating things procedurally with my system. That’s how I’m planning to handle it for my own game, so I’ve made sure it can be implemented easily. Everything is array based, so it should be as simple as feeding the procedural generation algorithm into these arrays. I might even include a basic procedural generation example if I have the time (though I’m sure you’re the last person who would be needing that :P)
[=;201746]
Honestly I know very little about materials. I’ve worked up a lot of very specialized knowledge about certain aspects of UE4 while still being a complete beginner in others. However, it seems reasonable that a system similar to ’s can generate a tile texture based on an array, and avoid the need for separate tile meshes for rendering a tile map. I believe this will be a corner case, though, and for almost all cases instanced static meshes will probably suffice (and even regular static meshes for some).
[/]
Yeah same here. I still haven’t had time to figure out how to UV my own hexagons. 
One system at a time. I have been content to stay mostly in BP logic as more features get fleshed out in the engine. After pathfinding I think I will be working on some UMG elements for various map features. Loading bars, tile interaction, etc. Hopefully I will become an expert in each area as I move along.
[=;201746]
You shouldn’t have any trouble generating things procedurally with my system. That’s how I’m planning to handle it for my own game, so I’ve made sure it can be implemented easily. Everything is array based, so it should be as simple as feeding the procedural generation algorithm into these arrays. I might even include a basic procedural generation example if I have the time (though I’m sure you’re the last person who would be needing that :P)
[/]
Yeah I was referring to 's material thing. I feel like if I can plug an array into something I can pretty much do whatever I want with a feature.
[=;202105]
Yeah same here. I still haven’t had time to figure out how to UV my own hexagons. One system at a time. I have been content to stay mostly in BP logic as more features get fleshed out in the engine. After pathfinding I think I will be working on some UMG elements for various map features. Loading bars, tile interaction, etc. Hopefully I will become an expert in each area as I move along.
Yeah I was referring to 's material thing. I feel like if I can plug an array into something I can pretty much do whatever I want with a feature.
[/]
I’ve got the same feeling. I’m feeling really proficient with arrays at this point, and will probably want to push array math into anything I’m making in the future I’ve started working with UMG myself. It’s a really neat feature, and very easy to work with. Having built in support for 3D-widgets in game is incredibly cool and useful.
[=;202162]
I’ve got the same feeling. I’m feeling really proficient with arrays at this point, and will probably want to push array math into anything I’m making in the future I’ve started working with UMG myself. It’s a really neat feature, and very easy to work with. Having built in support for 3D-widgets in game is incredibly cool and useful.
[/]
Yeah I am looking forward to 3D widgets. When I made my little resource icons I just used a blank circular mesh and hit it with a decal. Pretty ghetto.
Getting a context menu to pop up when I click the map will also be a huge bonus to development, especially as the number of information overlays increases.
One new feature and some major optimization. Using construction scripts It’s now possible to snap tiles and pawns to any custom grids (including hex grids) in the viewport when building levels. This can be turned on and off on in the level as a whole as well as on individual tiles. I’ve also overhauled the vision system, making it possible to create large visibility grids in milliseconds. This also works with any sort of custom grid. Here is a video of both features in action:
https://.com/watch?v=F22sayGn5p4
edit: A small clarification. The visibility grids in the video above are not generated on tick, but only when I click. Generation takes about 2 milliseconds for each grid above, with the grid being only slightly larger than what is visible in the video.
Looks great - generating when required is certainly the way to do it - I’m assuming you’re using a render-target of appropriate size, which is definitely the approach I’d be using too
Eager to get to play with it!
Like the visibility grids. Did you use a method similar to Nisshoku’s with rasterization, or something else?
I’m not using a render target. That would probably also be pretty efficient, but I’m not sure how I would get it to interact with the grid arrays. What I’m doing is closer to raterization, though still pretty different. It’s a combined approach of of a quick tiles in range algorithm and tracing. I also have a much quicker version that only calculates visibility to certain tiles of interest, such as only those containing enemy pawns,which I’m currently using for AI.
Using a render target is a good way of doing it, it may be worth investigating; the first thing you need to realise is that a hexagonal grid is just a square grid with every row offset. If you use a render target you can use said target directly with your material and shading setup, converting each pixel ‘point’ to a hexagon in world-space using shader math. It’s very easy to do 
[=;202690]
Using a render target is a good way of doing it, it may be worth investigating; the first thing you need to realise is that a hexagonal grid is just a square grid with every row offset. If you use a render target you can use said target directly with your material and shading setup, converting each pixel ‘point’ to a hexagon in world-space using shader math. It’s very easy to do 
[/]
Hehe, yeah I’m pretty proficient at the math behind hex grids at this point, but when it comes to materials I’m still a complete beginner. I’m still trying to understand how much of the visibility search you’re saying can be done with a render target, though. Would it be used only for rendering, or would it also be possible to feed information from the render target into an array to store which array indexes (tile locations) are visible from a certain location?
It’d primarily be used for rendering purposes; whilst you can indeed read from a render target, I’m not sure how cheap it would be to do so. It does mean you don’t have to store some kind of additional data structure for your check based output though (visibility, line drawing etc).
Are you using a lot of 2d arrays to handle things? That sounds fairly inefficient to me, there is probably a decent way to refactor that if it is the case.
I guess given arrays that could be in the thousands, it would be cheaper to use EQS or traces to do a vision check?
You could use either of those things depending on the needs for your particular game, however most games will want to use the grid (that is after all, what the grid is for).
I don’t think is duplicating the entire grid, he’ll only be using a representation of what is presently visible
[=;203261]
It’d primarily be used for rendering purposes; whilst you can indeed read from a render target, I’m not sure how cheap it would be to do so. It does mean you don’t have to store some kind of additional data structure for your check based output though (visibility, line drawing etc).
Are you using a lot of 2d arrays to handle things? That sounds fairly inefficient to me, there is probably a decent way to refactor that if it is the case.
[/]
I’m using quite a few 2d arrays through the entire blueprint (or, really, modified 1d arrays). As everything is grid-based I don’t see how I can be more efficient by not using arrays, as they are the most grid-like data structure. I have a hard time seeing how I could make the pathfinding faster by using something else than arrays, and everything needs to interact with the pathfinding, which is simpler if the other systems are also array-based. I’m open to any efficient solutions I might have overlooked, though. I’ve strived to have as few arrays as possible, and keep them limited in size when possible, and everything runs really smoothly at this point. Calculating visibility might be one of the areas where it’s possible to do the biggest improvements in efficiency, even though it is currently fast enough for most games. However, rendering the visible area takes less than a tenth of the time compared to calculating what tiles are visible, so if I am to have any large performance improvements from using a render target it would have to do more than just rendering. The current visibility algorithm also interacts with the path finding grid to calculate the range in tiles to each node, as well as generating an array of potential goals for the AI, which I’m unsure how I would do without arrays. Could you give me a quick step-by-step explanation of how you would go about generating visibility with a render target?
[=;203300]
I guess given arrays that could be in the thousands, it would be cheaper to use EQS or traces to do a vision check?
[/]
[=;203330]
You could use either of those things depending on the needs for your particular game, however most games will want to use the grid (that is after all, what the grid is for).
I don’t think is duplicating the entire grid, he’ll only be using a representation of what is presently visible
[/]
I’ll have to look into EQS, Zeus. Hadn’t heard about it until now, but after reading a few desciptions I think it seems promising. I’m indeed not duplicating the entire grid, , and the visibility arrays are never bigger than the amount of visible tiles.
Miezko showed off EQS in whichever stream he was last in. I think it is still in prototype stage, but we may see it in a few updates. I don’t really know how it works other than it looks like it does a 360 trace to determine visibility and has a nice visualization.
I’ll definately look into that. Sounds perfect for what I’m making, though it will all boil down to how easy it is to get it to interact with the data arrays that control the game logic.