[SUPPORT] Advanced Turn Based Tile Toolkit

[Gryphun]

Per-Unit edge costs

I have seen some mention of this before. Just wondering at current best practices. Say you have a forest tile where it costs an infantry unit 1 point to move through it, but a vehicle takes 2.

Would it be better to keep separate edge cost arrays for each unit type and then use custom pathfinding or just update the one edge cost array when the unit selection change to a new unit type? The second option seem simpler, but I'm unsure if there would be a real performance cost.

Thanks.

[tutkarz]

I have seen some mention of this before. Just wondering at current best practices. Say you have a forest tile where it costs an infantry unit 1 point to move through it, but a vehicle takes 2.

Would it be better to keep separate edge cost arrays for each unit type and then use custom pathfinding or just update the one edge cost array when the unit selection change to a new unit type? The second option seem simpler, but I'm unsure if there would be a real performance cost.

Thanks.

We have to make this flexible enough so when we make a game that will allow players to create their own units, they will have to be able to specify cost to enter for each tile for their unit. This makes choosing pathfinding method useless. I don't think there is any other method that will be better than making an array of movement types for each terrain type. Because even if we will come with some kind of modifier for difficult terrrain it still will be limited and will create other problems for unusual units.

Btw is this really important to have cost to enter neighbor tiles saved as array in each tile? In my previous game I had cost to enter tile as number in that tile. So when you wanted to enter neighbor tile you were asking it how much it will cost to move there. I don't know why current solution is better, maybe I am missing something.

Maybe we could do something like this: leave current array with entering neighbour tile cost but change it for cost multiplier and add base tile cost for each movement type for that tile. That way if in base tile cost will be 1 as default then old mechanic will be saved and by changing it to other numbers we could have plenty of flexibility. For example:

right now
(base tile cost that is hardcoded) 1 x 2 edge cost N = 2 cost to enter forest north tile

new solution
(value stored in tile for each move type) base tile cost for forest 2 x 1 edge cost changed to multiplier = 2 cost to enter forest
but it is possible now for example to do
base tile cost for forest 2 x 1.5 edge multiplier cost when moving NE = 3 cost to enter NE tile

I don't know if this is making any sense

[Monokkel]

I just added a branch to the pre-existing click event for when you click an allied tile. I didn't change anything with pathfinding, etc. I simply turned the Boolean to true when switching to the proper ability.

When clicking an allied unit with this ability, it successfully places a shield around the allied unit, but the unit that places it, either follows the wrong path-finding or will teleport to index 0. Sometimes it seems to work correctly. I should also mention this seems to only happen when show all possible visible tiles is set to True. I also noticed it will use the path from the last time it displayed a path while hovering.

I will send you a video.

Okay, I figured out the problem. You need to also modify the nodes in Display Path on Hover as well. Add the following:

I have seen some mention of this before. Just wondering at current best practices. Say you have a forest tile where it costs an infantry unit 1 point to move through it, but a vehicle takes 2.

Would it be better to keep separate edge cost arrays for each unit type and then use custom pathfinding or just update the one edge cost array when the unit selection change to a new unit type? The second option seem simpler, but I'm unsure if there would be a real performance cost.

Thanks.

Since you are modifying the very core of the pathfinding it is worth thinking about performance. The Search And Add Adjacent Tiles function is repeated a ton of times during pathfinding, so it pays to keep it as efficient as possible. I have worked hard to make it as efficient as possible, so you should be able to add a lot to it without noticing any frame dips for most games, but you should still try to be smart about it. The simplest and most efficient way I can think of is to add new custom Search And Add Adjacent Tiles functions and add them to the Custom Pathfinding macro and use these in conjunction with a new grid sized array for terrain.

First create a new enum for terrain, including the terrain types you wany (I added none, forest, ocean and mountain). Then create a new actor parented to GridActor (which has code for getting the correct index based on its placed location), maybe called GA_Terrain. Add a terrain enum variable to this class. Make a separate child actor of this actor for each type of terrain and add meshes/sprites to those (for my tests I just used a text render).

Then in BP_GridManager add a new array of terrain enums called Terrain Array (or whatever) and resize this to be the size of the grid. This probably makes the most sense to do in the Generate Gameplay Grids function. Like so:



In the Add Viewport Terrain to Arrays function add the terrain enum values of the terrain tiles you have placed in the world to the Terrain Array at the appropriate indexes like so:



Next expand the PathfindingType enum and add names for the various movement setups, like infantry, naval and heavy. For planes you can just use the Ignore Difficult Terrain pathfinding type. Duplicate the Search And Add Adjacent Tiles function and follow the example of implementation of other such functions in the Custom Pathfinding macro in BP_GridManager. Like so:



In these custom functions add a switch on the enum of the tile edge to be checked and set a terrain cost/refrain from adding the tile to be searched in the open list based on the terrain enum value of the Terrain Array at the grid index you are considering. Also, replace connections from the the EdgeArray ForEachLoop with a terrain cost based on the result of the switch. Like so:



In the function I made for infantry above I set cost to be 1 if no terrain is specified, 2 for forest and impassable for ocean and mountains. For naval units I only proceeded with the function if the terrain was ocean. Heavy is the same as infantry, but without proceeding with the function if the terrain is forest. You would add more such types of pathfinding is necessary. There are more elegant ways to do this where you can contain everything in one function, but it will be less efficient. If you have a limited amout of such movement classes this would be my recommended solution. Here is a screenshot of Mr. unit_boat being a boat:

We have to make this flexible enough so when we make a game that will allow players to create their own units, they will have to be able to specify cost to enter for each tile for their unit. This makes choosing pathfinding method useless. I don't think there is any other method that will be better than making an array of movement types for each terrain type. Because even if we will come with some kind of modifier for difficult terrrain it still will be limited and will create other problems for unusual units.

If the method above is not flexible enough (though I think it should be in most cases) you could add a terrain array and a cost array to Unit_Parent. Then you would get a reference to the current unit during Search And Add (make sure to set this up early in the pathfinding so you do not need to cast every loop), and check the cost value of the unit's cost array against the terrain type of the tile being entered. It would be a lot less efficient, though. If the first method is impossible and you need to do something like this instead I'll try to think up a more efficient solution.

Btw is this really important to have cost to enter neighbor tiles saved as array in each tile? In my previous game I had cost to enter tile as number in that tile. So when you wanted to enter neighbor tile you were asking it how much it will cost to move there. I don't know why current solution is better, maybe I am missing something.

For most games it does indeed not make a difference, but I've always strived to make the toolkit as flexible as possible and having the possibility of having various costs for entering the same tile from various directions can be utilized in some games. You could for instance set things up so that it costs more to walk up, but not down a slope, have rivers that slow you down when you walk upstream, but speed you up downstream etc.

I hope my answers have been helpful and that they will help you add the features you need.

[LDodds]

Been a while since I posted on here!
Hope you are doing well Monokkel!

Debating a new type of map for my game, *sorry if this issue has come up previously
The map would basically be an ocean, but platforms where the units can walk.
Now as it stands the grid doesn't need a mesh to be there for units to walk (so by default they could walk in the air)
So I was trying to think of the best way to check where there are spaces, or rather not spaces, and make those tiles impassable.
Just did this with a plane -400 from the grid and a extra linetrace in the "Add Viewports to Array" function.
Here i checked visibility, if the hit location Z = X make that tile impassable, which worked too well and now ALL tiles are impassable.

Any suggestions?

[Monokkel]

Hello LDodds! Long time no see The sort of functionality you are describing is included in the toolkit by default. If you disable collision plane walkable and make sure your bridge tiles block PathTrace and your water does not it should work automatically.

[Gryphun]

This is awesome. Thanks. It looks like it will let me do what I want. I think my only suggestion would be find some way to make the custom pathfinding a proper function for overriding.. As it is, you have to alter the base class to make this work which will make it more difficult to integrate any future updates you release.

Thanks again.

[tutkarz]

I hope my answers have been helpful and that they will help you add the features you need.

Yes, they did. Thank you for your time and waiting for new version so I can start making changes there.

[Monokkel]

This is awesome. Thanks. It looks like it will let me do what I want. I think my only suggestion would be find some way to make the custom pathfinding a proper function for overriding.. As it is, you have to alter the base class to make this work which will make it more difficult to integrate any future updates you release.

Thanks again.

No problem! I had been wanting to test something like this out for a while. I agree that it would be much more elegant to use some form of function that can easily be overridden. However, in this particular part of the toolkit I am even less inclined than usual to sacrifice performance for elegance. But if I think up a better solution I'll make sure to post about it here. I'm also open to suggestions.

Yes, they did. Thank you for your time and waiting for new version so I can start making changes there.

For the most part the new update is fairly close to the current version and most of the new features are contained in child blueprints of the various standard toolkit blueprints. I have still done quite a few minor alterations and fixes on the standard blueprints, but it is close enough that you should not worry too much about adding your changes now. Just make sure to mark them clearly so they are easy to port over once the new update is out.

[Envieous]

Okay, I've figured out the issue here. The problem is the Reachable Index Closest To Target function, which assumes units cannot pass through friendly units. This function does not fire if the target unit is in move range, so the bug only appears in cases where a unit which is set to pass through friendly units is not able to reach its desired target and there is a friendly unit between it and its target. I've found a solution that works, but I'll try to think up something more elegant to include in the update. For now you can do this:

In ATBTT_AI_Controller in the middle of the Select unit and find path comment box:
[ATTACH=CONFIG]124742[/ATTACH]

The new function from the screenshot above:
[ATTACH=CONFIG]124743[/ATTACH]

Alright I'm working with this part again. I'm running into an issue where pawns will go to index 0 when an enemy target is within movement range, but inaccessible do to the available spaces being occupied by either impassable terrain or other enemies. I'm not sure whether the issue stems from this fix, or something I changed elsewhere, but you may want to check into it.

I'll let you know if I find the solution myself.

[Envieous]

I found the issue, and I can reproduce it in a blank project.



Just do this, set default pathfinding to pass through friendlies.



This is why. The AI sees that tile as visible even though there's no tile it can actually attack it from

You can also reproduce this with player units, they'll run to index 0 as well, but properly path there atleast.

[Monokkel]

Hey Selentic, I'm looking into this. I'm only able to reproduce it if I also set "square visibility" to false for the unit. If this is also the case in your project I know the reason for the issue, as the diagonal tile from the target is incorrectly thought of as adjacent during pathfinding if Pass Through Friendlies is true. I'll get right on finding a fix, but could you confirm that you are not seeing this bug if square visibility is set to true?

[Envieous]

Hey Selentic, I'm looking into this. I'm only able to reproduce it if I also set "square visibility" to false for the unit. If this is also the case in your project I know the reason for the issue, as the diagonal tile from the target is incorrectly thought of as adjacent during pathfinding if Pass Through Friendlies is true. I'll get right on finding a fix, but could you confirm that you are not seeing this bug if square visibility is set to true?

This is correct. I use diamond visibility.

[Monokkel]

Ok, so diamond visibility was not really the cause of the problem (though it was necessary to reproduce the bug with the exact setup you pictured). The problem is that the AI naively assumes that any unit it finds during pathfinding can be reached and attacked from an adjacent tile. Normally this holds true. However, if the unit can pass through friendly units the pathfinding will find units that might be surrounded by other friendly units, meaning there is no unoccupied tile from which to attack. Sorry that you have been a bit of a guinea pig for the "pass through friendlies" option, as it is not something I have tested as much as units with standard pathfinding.

The good news is that all this is fixed in the coming update. I have made big changes to the AI controller which makes it quicker, less convoluted and more stable, and in the process I also solved your problem by accident. However I'm hoping you can live with this issue until the update is out. I could certainly think up a solution within the current framework, but it would be outdated as soon as the update is out.

[Envieous]

Ok, so diamond visibility was not really the cause of the problem (though it was necessary to reproduce the bug with the exact setup you pictured). The problem is that the AI naively assumes that any unit it finds during pathfinding can be reached and attacked from an adjacent tile. Normally this holds true. However, if the unit can pass through friendly units the pathfinding will find units that might be surrounded by other friendly units, meaning there is no unoccupied tile from which to attack. Sorry that you have been a bit of a guinea pig for the "pass through friendlies" option, as it is not something I have tested as much as units with standard pathfinding.

The good news is that all this is fixed in the coming update. I have made big changes to the AI controller which makes it quicker, less convoluted and more stable, and in the process I also solved your problem by accident. However I'm hoping you can live with this issue until the update is out. I could certainly think up a solution within the current framework, but it would be outdated as soon as the update is out.

My AI controller is significantly extended from the original, so it'd be preferable to know what I need to change to solve the issue with the system I have now, unless it's something that I can easily integrate afterwards into my system.

Also isn't the issue in pathfinding, since it affects players as well?

[Monokkel]

My AI controller is significantly extended from the original, so it'd be preferable to know what I need to change to solve the issue with the system I have now, unless it's something that I can easily integrate afterwards into my system.

It should be something that is easy to integrate. It is a combination of several functions I now use to determine what units are reachable by the AI. These should be easy enough to replace with the old ones, but it will take some time to post all the nodes related to these new functions in this thread. Therefore I hope you can wait until the update is done. If you feel after the update is out that you will not want to use the new nodes for whatever reason I'll think up a custom solution for you.

Also isn't the issue in pathfinding, since it affects players as well?

Well yes, sort of. It is a problem with what units the pathfinding considers to be reachable. This could be fixed within the pathfinding function itself. However, that would require taking all units reached by the pathfinding and for each of them look at all surrounding tiles to determine if at least one of them is reachable and unoccupied (which is expensive). This can be done much more efficiently in the AI and Player controllers where it is possible to narrow down the amount of units you want to check. I would still prefer the Reachable Pawns Array to only contain the units which are actually reachable, though, so I will give this some more thought.