[SUPPORT] Advanced Turn Based Tile Toolkit

[Skulldug]

Hello Monokkel, noticed on trello you did some more work, awsome but did you forget what is on the "Current WIP" ?.....bah hah..how is it going with your Phd ? thanks for the latest update also!

[Monokkel]

Hello Monokkel, noticed on trello you did some more work, awsome but did you forget what is on the "Current WIP" ?.....bah hah..how is it going with your Phd ? thanks for the latest update also!

I'm on the end stretch now, so I've actually been able to avoid working on the toolkit. Hard to stop my brain from working when I take a shower or when I'm trying to fall asleep, though, and I make sure to enter such ideas into the trello. So the additions are not reflective of work, but rather future plans.

[Darthlatte]

Hi, is it possible to run around freely until you engage in combat and then the game becomes turn based, like in Mutant Year Zero? Thanks

EDIT: Just found out about the free roam feature, but how do I activate it?

[Monokkel]

Hi, is it possible to run around freely until you engage in combat and then the game becomes turn based, like in Mutant Year Zero? Thanks

EDIT: Just found out about the free roam feature, but how do I activate it?

Hi there, sorry for the last answer. Turns out I must have deleted the free roam ability by accident when auto-clearing unused blueprints a couple of updates ago. I wasn't satisfied with just migrating it over from an older project and also made some improvements, now allowing for changing move direction before the unit has reached a target. I have added this ability and also removed some debug nodes that was still in BP_GridManager. For those here who do not use the FreeRoam ability there is no reason to update the project, but make sure to delete the event that is called by pressing X in the event graph of BP_GridManager, or you'll get some weird behavior if the player presses X.

Epic usually take a few days to process a new update so you can add the ability directly by downloading this file and adding it to you project in [Project Name]/Content/Base/Abilities.

To enter free roam mode, activate the Free Roam ability, with the unit you want to use it selected in the input. To exit free roam and activate the unit as normal, call SelectUnit on the same unit. Here is some debug code I added to the player controller to quickly test this, though you would want to call it server side somewhere else as part of your gameplay logic:



Edit: Forgot to add the link I sent you in the PM while fixing this for the benefit of other developers. We recently discussed various ways of implementing free movement a couple of pages ago in this thread. Head over here to see the discussion.

[Darthlatte]

Thanks a lot for the help :-)

EDIT: You're obviously busy so I'll stop spamming your with PM's, instead I'll post here, then maybe others can benefit from the posts.

Hi, sorry to bother you again, but I don't have a [Project Name]/Content/Base/Abilities folder instead I have a [Project Name]/Content\AdvancedTurnBasedTileToolkit\Core\Abilities folder. Is that the right one?

When I copy the uasset file into the folder via file explorer i can't see it anywhere, even after restarting the editor. Any ideas?

Also I'm having a really hard time understanding the asset. It seems that all the videos on YT are for an older version as there are a lot of differences in the naming/setup.

I'm, trying to create a new project/level based on the advanced template, but when I add a new terrain to the scene I can no longer play in editor (nothing happens when pressing play). How do I properly add a terrain to the scene?

Thank you

[Monokkel]

Thanks a lot for the help :-)

EDIT: You're obviously busy so I'll stop spamming your with PM's, instead I'll post here, then maybe others can benefit from the posts.

Hi, sorry to bother you again, but I don't have a [Project Name]/Content/Base/Abilities folder instead I have a [Project Name]/Content\AdvancedTurnBasedTileToolkit\Core\Abilities folder. Is that the right one?

When I copy the uasset file into the folder via file explorer i can't see it anywhere, even after restarting the editor. Any ideas?

Also I'm having a really hard time understanding the asset. It seems that all the videos on YT are for an older version as there are a lot of differences in the naming/setup.

I'm, trying to create a new project/level based on the advanced template, but when I add a new terrain to the scene I can no longer play in editor (nothing happens when pressing play). How do I properly add a terrain to the scene?

Thank you

Yes, the second project path is the correct one. That should be enough, but no longer necessary. The hotfixed version that includes the Free Roam ability is now live.

Many of my videos are indeed out of date. A lot of the same principles still apply, though there are also some deeper changes. I intend to make new beginner-facing tutorials, but I have put it on hold until I'm done with my PhD (in a couple of months). Until then, try to make use of the tutorials as best you can and ask here if you run into any problems.

I would not really recommend starting with the advanced template when you are learning the toolkit as it is, well, advanced, but up to you. It should work well with any terrain in theory. This is provided the terrain overlaps the grid manager, that it is not higher or lower than the values designated in MaxGridHeight and MinGridHeight in BP_GridManager and the terrain blocks the PathTrace collision channel. Have you done all of this and still having issues?

[Darthlatte]

Yes, the second project path is the correct one. That should be enough, but no longer necessary. The hotfixed version that includes the Free Roam ability is now live.

Many of my videos are indeed out of date. A lot of the same principles still apply, though there are also some deeper changes. I intend to make new beginner-facing tutorials, but I have put it on hold until I'm done with my PhD (in a couple of months). Until then, try to make use of the tutorials as best you can and ask here if you run into any problems.

I would not really recommend starting with the advanced template when you are learning the toolkit as it is, well, advanced, but up to you. It should work well with any terrain in theory. This is provided the terrain overlaps the grid manager, that it is not higher or lower than the values designated in MaxGridHeight and MinGridHeight in BP_GridManager and the terrain blocks the PathTrace collision channel. Have you done all of this and still having issues?

Hi :-) I can't see the hotfix anywhere (no updates in the launcher). I got the terrain working by moving it up a bit over the grid manager. Thank you

[Monokkel]

Hi :-) I can't see the hotfix anywhere (no updates in the launcher). I got the terrain working by moving it up a bit over the grid manager. Thank you

Sure you have the latest version (and UE4.21)? It works at my computer. The exact path at my computer is C:\Users\[user name]\Documents\Unreal Projects\[Fresh ATBTT project name]\Content\AdvancedTurnBasedTileToolkit\Core\Abilities. The ability is called BP_AbilityBase_FreeRoam

Happy to hear you got the terrain issue solved, though. Do you now know what you had set up incorrectly?

[Darthlatte]

Sure you have the latest version (and UE4.21)? It works at my computer. The exact path at my computer is C:\Users\[user name]\Documents\Unreal Projects\[Fresh ATBTT project name]\Content\AdvancedTurnBasedTileToolkit\Core\Abilities. The ability is called BP_AbilityBase_FreeRoam

Happy to hear you got the terrain issue solved, though. Do you now know what you had set up incorrectly?

Ahh, I'm using UE4 4.20, that's probably why the uasset file doesn't work ;-)

The problem was that I had the new terrain above the grid manager threshold, so it didn't work.

On another note, I'm trying to create a rather large grid for my rather large game world, and am running into issues with the "infinite loop detetcted" when generating the grid tiles. I've read that this can be solved by increasing the iteration count, but that doesn't seem like the best way to handle large worlds (at least for me), and I'm pretty sure that it doesn't work with level streaming (I may be wrong here). So my question is this, wouldn't it be better and more flexible to generate the grid around each player per turn? Say, maybe just generate a 20x20 grid around the player pawn on each turn, or am I missing something obvious?

Thanks

[Justo]

I've been slowly but steadily putting more hours into this real-time-to-turn-based project...There's something I'm wondering now about the camera: if I wanted the same camera controls (Zoom, Pan, Rotate) for both gameplay situations, what would be an elegant way of solving it?

I see that they way its set up now, the PlayerController detects the input events, and triggers in the GridCamera BP other events which execute these actions.

For my real-time moments, right now I have a camera parented to a SpringArm in my character blueprint (Monokkel, in the future I will follow your advice and turn this character BP to an Actor BP that spawn a character and attaches itself to it, like you mentioned in post #2374). I was trying to copy the events and setup, but I was wondering if there was a more intelligent way of doing this rather than copying the same code, and creating the same variables, twice.

Anyone who's willing to share their thoughts on this would be super appreciated! Cheers.

[Monokkel]

Ahh, I'm using UE4 4.20, that's probably why the uasset file doesn't work ;-)

The problem was that I had the new terrain above the grid manager threshold, so it didn't work.

On another note, I'm trying to create a rather large grid for my rather large game world, and am running into issues with the "infinite loop detetcted" when generating the grid tiles. I've read that this can be solved by increasing the iteration count, but that doesn't seem like the best way to handle large worlds (at least for me), and I'm pretty sure that it doesn't work with level streaming (I may be wrong here). So my question is this, wouldn't it be better and more flexible to generate the grid around each player per turn? Say, maybe just generate a 20x20 grid around the player pawn on each turn, or am I missing something obvious?

Thanks

Ok, that explains the missing ability. Whenever I release a new update of UE4 it is always for the newest version. That is the version I use when developing and it is not possible to convert projects to older versions of UE4, so updating multiple versions would be too time consuming. Hope the free roam ability gives you a good starting point to achieve your intended goal.

As for large maps, I would generally recommend calculating at startup. The map generation stuff are some of the heaviest operations in the toolkit, so if you want to run a limited version of them every time you run pathfinding etc. it could quickly slow the game down. You could increase the iteration count, and if it is possible to reset this to the normal value after the first tick of the game, there aren't many drawbacks to doing it this way. Another possibility is to run the startup function over multiple ticks using my ForLoopPerTick and ForEachLoopPerTick macros. It will take some reordering of things, but should not be terribly difficult to do.

How large a map are we talking here, by the way, and what options are you using (multi-level, trace for walls etc.)?

I've been slowly but steadily putting more hours into this real-time-to-turn-based project...There's something I'm wondering now about the camera: if I wanted the same camera controls (Zoom, Pan, Rotate) for both gameplay situations, what would be an elegant way of solving it?

I see that they way its set up now, the PlayerController detects the input events, and triggers in the GridCamera BP other events which execute these actions.

For my real-time moments, right now I have a camera parented to a SpringArm in my character blueprint (Monokkel, in the future I will follow your advice and turn this character BP to an Actor BP that spawn a character and attaches itself to it, like you mentioned in post #2374). I was trying to copy the events and setup, but I was wondering if there was a more intelligent way of doing this rather than copying the same code, and creating the same variables, twice.

Anyone who's willing to share their thoughts on this would be super appreciated! Cheers.

Any reason you can't just use the grid camera in both modes of play?

[Justo]

Monokkel Yes, I thought of that too! The reason why I didn't know if it would be a good option was because I thought that the SpringArm + Camera combo inside the character blueprint needed to be there yes or yes, for no reason at all other than Justo blocking himself like s knucklehead.

So, I could have the gridcamera as a separate actor, always following my main character, and then move it to the correct position once combat starts (and activate all the setup stuff inside the gridcamera for turn-based combat). Sounds elegant enough, right?

[Monokkel]

Monokkel Yes, I thought of that too! The reason why I didn't know if it would be a good option was because I thought that the SpringArm + Camera combo inside the character blueprint needed to be there yes or yes, for no reason at all other than Justo blocking himself like s knucklehead.

So, I could have the gridcamera as a separate actor, always following my main character, and then move it to the correct position once combat starts (and activate all the setup stuff inside the gridcamera for turn-based combat). Sounds elegant enough, right?

yep, the easiest is often the best

[Darthlatte]

Ok, that explains the missing ability. Whenever I release a new update of UE4 it is always for the newest version. That is the version I use when developing and it is not possible to convert projects to older versions of UE4, so updating multiple versions would be too time consuming. Hope the free roam ability gives you a good starting point to achieve your intended goal.

As for large maps, I would generally recommend calculating at startup. The map generation stuff are some of the heaviest operations in the toolkit, so if you want to run a limited version of them every time you run pathfinding etc. it could quickly slow the game down. You could increase the iteration count, and if it is possible to reset this to the normal value after the first tick of the game, there aren't many drawbacks to doing it this way. Another possibility is to run the startup function over multiple ticks using my ForLoopPerTick and ForEachLoopPerTick macros. It will take some reordering of things, but should not be terribly difficult to do.

How large a map are we talking here, by the way, and what options are you using (multi-level, trace for walls etc.)?

Ok, I understand that it's easier to just maintain one version of your asset ;-)

My current game map is big, as in 12km x 12km big, and it will probably be expanded upon in the future... I'm using all the options that are in the advanced template as they fit many of my gameplay needs ;-)

What would you say are the most intensive calculations grid wise?

I could probably find a way to reset the iteration count after the initial calculations. I'll try to look at that (or just do it manually).

I haven't looked at your ForLoopPerTick and ForEachLoopPerTick macros yet. That may be a solution.

Thinking out of the box - wouldn't it be possible to do this at runtime for a small grid around the player? I was thinking of having a fixed point in the world and then reference the point coordinates for the generation of tiles to make it all snap and consistent. I would love your input about this idea, and especially why it wouldn't work :-)

As I see it there's another caveat of statically generating the grid and that is consistency when thing change. For example if I would resize the grid tile sizes, then all the positions of the placed blueprints would be invalid. Or am I wrong here? Maybe there's some logic to rearrange the units etc. upon change?

Btw. I think your asset is great :-)

Thank you

[Monokkel]

Ok, I understand that it's easier to just maintain one version of your asset ;-)

My current game map is big, as in 12km x 12km big, and it will probably be expanded upon in the future... I'm using all the options that are in the advanced template as they fit many of my gameplay needs ;-)

What would you say are the most intensive calculations grid wise?

I could probably find a way to reset the iteration count after the initial calculations. I'll try to look at that (or just do it manually).

I haven't looked at your ForLoopPerTick and ForEachLoopPerTick macros yet. That may be a solution.

Thinking out of the box - wouldn't it be possible to do this at runtime for a small grid around the player? I was thinking of having a fixed point in the world and then reference the point coordinates for the generation of tiles to make it all snap and consistent. I would love your input about this idea, and especially why it wouldn't work :-)

As I see it there's another caveat of statically generating the grid and that is consistency when thing change. For example if I would resize the grid tile sizes, then all the positions of the placed blueprints would be invalid. Or am I wrong here? Maybe there's some logic to rearrange the units etc. upon change?

Btw. I think your asset is great :-)

Thank you

Ok, well that is certainly a much bigger map than what I've had in mind when designing the toolkit. I don't think I've ever heard of a 12 square kilometer turn based strategy game before. I mean, you could always split it up into multiple adjacent levels, but since you want to have it seamless and presumably enable turn based combat in the border between two such maps this becomes more tricky.

Ok, so I don't think I would generate the grid around each unit every time it moves, but you can probably generate a grid up to a certain distance around a unit when combat first starts. Since you probably want combat to happen on a large map this would very likely cause a very noticeable frame dip when it is generated. There are a few possible ways around this. The laziest is to have some sort of banner fly in with a "begin combat" text, generate the map while it is stationary and then fly it out again. Pretty hacky solution, though. Another is to spread grid generation over multiple ticks, possibly in an expanding circle around the active unit. You could either start combat once this had reached a certain size, or you could even have it continue slowly in the background to an even larger size. In any case you are now doing the sort of thing where you would benefit a lot from using C++ instead of blueprint. I would probably recommend rewriting the grid generation algorithm in C++ for this.