@Selentic: Haha, I’ll take full responsibility Yeah, that is what I’m doing in general terms, though the devil is in the details. If your game uses a square grid, has a single level and no thin walls between two adjacent tiles, then implementation is fairly straightforward. You would pregenerate an array like the one in your picture by checking larger and larger square combinations of tiles until you reach an impassable tile (The CheckIfPassable function can be used for this) and then log the size of the unit that can fit into that square in an integer array. You then use a custom pathfinding function (in the Custom Pathfinding macro) for large units where you check this array after the branch where you check if a tile’s cost equals zero and do not continue if the integer is smaller than the size of the unit (which you store as a public variable in BP_Unit).
That mostly solves things for pathfinding. However, large units will be able to overlap each other like this, as units are not stored in the big units array. You can do this by checking all appropriate tiles for every pathfinding search step during gameplay, which is a bit cumbersome. You can also check with an appropriately sized collision box that overlaps all units for each step, which is what I am doing currently.
Now you have some more problems, as you will need to have the toolkit know that you select a unit (for say attacking) when clicking any of the tiles it occupies and not just the “real” tile in the upper left corner of its occupied spaces. You could get most of the way here by using the unit array and filling up all appropriate tiles with a reference to the unit. You would need to change this dynamically during gameplay. I did this by storing all the currently occupied tiles in the actor of each large unit and removing the references when the unit moves/is destroyed. You would still need to update most functions involving selecting units to work with this new system.
Alternatively you can swap to a system of directly clicking a unit’s mesh instead of the tiles it occupies. This would require some work, of course, but should be fairly straightforward.
Now for the visuals. All meshes that show unit selection/targeting etc. need to be dynamically resized and shifted appropriately to fit under a large unit. Showing tiles in move range is another beast entirely. I’ve found a solution for this, but explaining it will take some time. If you manage to implement the rest I’ll explain it to you. Also, if you are using units that are 22, 44 etc. where the center of the unit is on the intersection between four tiles, you can no longer use simple tile locations to do stuff like place spline points for movement, placing markers etc. and will need to shift this by half a tile width/length as needed.
That should be most of what you need. If you want hex grid support as well it becomes more difficult, as the “corner” your unit is placed cannot be transferred simply from square to hex grids. Thin walls between tiles are very tricky, as you can no longer simply check “IsTilePassable”, but need to check every edge for every tile and see if it an edge exists pointed in the appropriate direction. Multi-level grids might be the most difficult of all, as the grid does not a priori know if tile 101 is physically right next to tile 100 or if it is next to 200, 300, 400 etc. This makes pregenerating the large unit array a bit of a nightmare.
As mentioned, I think I’ve found solutions for all of this, but it is no small undertaking. I hope you can see why I wanted to wait with implementing this until I was done with all the other major changes, as it relies on many other part of the toolkit, many of which will be changed quite a bit in the next update.
If you want to tackle this beast I wish you the best of luck, and feel free to ask here if you need help along the way