[SUPPORT] Advanced Turn Based Tile Toolkit

[Monokkel]

Hey,

Currently attempting to get the units to spawn dynamically, however the pack doesn't seem to like that as I get dozens of accessed none errors if there are no units on the grid when it starts(most likely the custom unit spawns is getting called after the other begin plays already initiated), however there never is a certainty of which items will spawn as it's generated from another level(how and why is not relevant).

Are there events I need to delay until after I spawned the units myself? If so, could you point me to which ones I need to callback after spawning the units? PC/Pawn/GM/Etc? I can callback all of them but to avoid breaking anything I find it safer to just ask.

Currently just calling back the gamemode and it seems to work.

Hey! You've got it right. The game mode is what you need to call back, as it signals the start of the first unit's turn, focuses the camera on the active unit and sorts units in initiative order. I'll be making it so starting the game with no units in place will work without issue in the next update.

[Envieous]

this is your fault

real talk though, is this the method you're using for your implementation of multi tile units?

[Monokkel]

[MENTION=16997]Selentic[/MENTION]: Haha, I'll take full responsibility :P 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 2*2, 4*4 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

[Envieous]

Selentic: Haha, I'll take full responsibility :P

I probably wouldn't have thought of it right off the bat if you hadn't decided you were going to add it into the toolkit. At the time I was sitting there with an absurd 15x15m tiles to fit vehicles, where infantry were incredibly difficult to see as a result. I realized that was awful but didn't really have a solution for how to keep tiles big enough for vehicles, but not be ridiculously huge for much smaller footsoldiers.

Then boom, you announced it.

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.

That's more or less where I'm at with this. I piggybacked it into the existing pathfinding exactly as you said. As far as units go, It should be trivial enough to regenerate the array and treat units as obstructed tiles the same way it treats terrain entities. Seems to work fine during run time on a relatively small grid, but even if it ends up expensive to run I can probably find ways to cut out a good portion of tiles that do not need to be updated, and run it at a point where the game doesn't accept input anyway, so no one would notice a half second of it being regenerated. I hadn't thought about thin walls, but I don't use *too* many of them, so I can probably store their indexes as well and add in a more complex check when it runs into them.

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.

That's exactly how I was planning to do it. Getting a series of indexes in a square is pretty simple math to pull off, and just write a reference to it in the pawn array whenever it moves.

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 2*2, 4*4 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.

I think I have some idea of how to have tiles in move range represent themselves properly visually, and that's what I'm going to implement next (after a quick nap). I'll check back in with the results. Offsetting/resizing the other ui elements should be simple enough.

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

Luckily I'm not using Hex grids. I would have absolutely no idea how to approach them.

[Envieous]

I think I have some idea of how to have tiles in move range represent themselves properly visually, and that's what I'm going to implement next (after a quick nap). I'll check back in with the results.

Did it. (There's some weirdness here because tile costs don't make logical sense yet for this unit) Basically just did a simpler version of the clearance algorithm where I take each tile that can be moved to, and make a unit size squared grid from that position, then add it to the list of tiles to spawn movement tiles on. I'm curious to see how this is going to play with visibility tiles, but I'm not quite there yet.



I solved walls by deleting the south and east ones, and only using north and west then adding them to an array. Since I search from the top left, I can just assume that if I hit a tile that's marked as having a wall, it can be treated exactly the same as one that's fully obstructed.

Still gotta offset the UI elements and whatnot.


I also had a few ideas for how to lower the cost of the clearance check, since I have to run it every time a unit is activated. I don't actually need to regenerate the whole grid, I only need to update unit size -1 away from the unit on activation, and after moving. I can also ignore any 0 tiles, since those will always be 0, and aside from rare occasions where a tile could go from blocked terrain, to open that will remain accurate. For those situations, re-running the algorithm on all the open tiles to the top left of that up to the maximum search can solve that.

[mortsnort]

Hello. I really like the toolkit and am looking forward to multiplayer updates. Anyways, I want to run a function whenever a unit moves, and I notice there's a unit enters new tile function, but it doesn't appear to do anything. How do I use this function or how else could I check to see if a unit moved to a new tile?

[mortsnort]

Nevermind, I figured out that I need to check update indexes on movement

[Monokkel]

[MENTION=16997]Selentic[/MENTION]: Seems like you're making great progress, and for the most part you seem to have found similar solutions to my own. I've had to make several changes to allow for hex grids/multi-level, but for your game what you are describing should be perfect. The only thing I'm uncertain about is your solution for walls. Do you mean that you do not have south and east walls in your game anymore or that they are not added to the big unit array? A Size 3 unit would not work with any thin wall bordering the middle tile it occupies, so I'm not sure if this works with anything but size 2 units.

Your thoughts about regenerating part of the grid is also similar to what I did initially and will certainly be far superior to regenerating the entire grid each round.

[MENTION=709952]mortsnort[/MENTION]: Hi there! Glad you figured it out. I've been debating whether or not to have that boolean be true by default. Might even change the default for the next update.

[Envieous]

Selentic:The only thing I'm uncertain about is your solution for walls. Do you mean that you do not have south and east walls in your game anymore or that they are not added to the big unit array? A Size 3 unit would not work with any thin wall bordering the middle tile it occupies, so I'm not sure if this works with anything but size 2 units.

I mean the literal entities. A north wall can become a south wall just by simply moving it down an index. Since with just the two they're all facing the same direction, I can simply add them to an array, and when I generate clearance if I hit a tile with a wall, I can treat it just like one of the full obstructed tiles in my first grid image, since I know that the top or left is what's blocked meaning there isn't clearance, and not the bottom or right which would mean that tile did have clearance. If that makes sense.

PS got everything working now, I might have some fun stuff to show you in a month or so

[Monokkel]

I mean the literal entities. A north wall can become a south wall just by simply moving it down an index. Since with just the two they're all facing the same direction, I can simply add them to an array, and when I generate clearance if I hit a tile with a wall, I can treat it just like one of the full obstructed tiles in my first grid image, since I know that the top or left is what's blocked meaning there isn't clearance, and not the bottom or right which would mean that tile did have clearance. If that makes sense.

PS got everything working now, I might have some fun stuff to show you in a month or so

Ok, that makes a lot more sense. Again this is not something I can do for my generic solution as I want it to work with auto-generated edges for terrain. Sigh, a word of advice for future development of your game. When adding a feature, don't simply consider how long time it will take to implement, but also how long it will take to make sure all future new features work along with it :P

Awesome that you've got it working, though! This is very advanced manipulation of ATBTT and shows that you have truly mastered it. Can't wait to see your future progress!

[Envieous]

Sigh, a word of advice for future development of your game. When adding a feature, don't simply consider how long time it will take to implement, but also how long it will take to make sure all future new features work along with it :P

Luckily, this is the last significant thing I needed to add.

Awesome that you've got it working, though! This is very advanced manipulation of ATBTT and shows that you have truly mastered it. Can't wait to see your future progress!

It seems like just yesterday I came here asking how to see enemy movement. Brings a tear to my eye :'^)

[Veliandr]

Hi! Can you please explain, how can I increase distance between tiles? I found Gap variable, but when I changed it nothing happened

[ClaimedInfinity]

Not really asking a question, more like asking for a recommendation. Let's say I have an AI pawn armed with a main weapon and a sidearm. Each of 2 weapons has different set of skills and it costs some action points to switch between weapons. What would be better (based on sci-fi example) - to add function to evaluate which weapon is best to use (based on damage and range) the same way as to evaluate skill OR to just add weapon change cost to skill evaluation formula (for example IF skill is not available without weapon change - THEN skill effectiveness for AI/2)?

[Monokkel]

It seems like just yesterday I came here asking how to see enemy movement. Brings a tear to my eye :'^)

To be fair it really wasn't that long ago. You're a quick learner

Hi! Can you please explain, how can I increase distance between tiles? I found Gap variable, but when I changed it nothing happened

Change the default tile mesh and the rest of the variables adjust automatically.

Not really asking a question, more like asking for a recommendation. Let's say I have an AI pawn armed with a main weapon and a sidearm. Each of 2 weapons has different set of skills and it costs some action points to switch between weapons. What would be better (based on sci-fi example) - to add function to evaluate which weapon is best to use (based on damage and range) the same way as to evaluate skill OR to just add weapon change cost to skill evaluation formula (for example IF skill is not available without weapon change - THEN skill effectiveness for AI/2)?

I think your second idea sounds the most likely to result in an accurate AI judgement of skill effectiveness. I would probably have done something to that effect.

[Monokkel]

The toolkit is currently 30% off! If you have been following this thread, but have not bought the toolkit yet, now might be the time!