[SUPPORT] Advanced Turn Based Tile Toolkit

[Skulldug]

Thanks! : )
Increasing the loop iteration count won't increase the maximum grid size I guess? So we need to figure out a workaround for the 1km x 1km sized map - of course we don't need turnbased pathfinding for the whole map in a single turnbased fight - so positioning the grid to the player's position when the combat starts would be fine. Which methods from the GridManager's construction script are required for repositioning the grid at runtime? Do we need to clear arrays or TMaps etc?

Increasing loop iterations only affects how many computations that can be done.. thus you can increase the size of grid and do more computations..
I dont think moving grid is a good idea because all the math for tile finding would be off..
Are you using alot of "foreach" nodes by any chance ? if you are try putting in a macro with "foreachwithbreak" setting break to 0.1 or 0.2 and make sure "oncomplete" has a return node, or use "foreach" with a delay of 0.1 - 0.2
try using "pregenerate gameplay grid" for sure..
Hope this helps some..

Do you use sub grids to get four grids in one level at the same time?

I have an old copy that has a multi level map and using that as template, My map is set up like a 3d chess game and only way to reach another level is through a teleporter/wormhole.

[Monokkel]

Dan.Ott: Ah, now I see what you're getting at. I've indeed capped the grid size to 200 in the variable settings of BP_GridManager, though you can easily increase this cap. I've added the cap to signal that you're going beyond what the toolkit is tested for. I've tested at roughly twice the size of the largest Civ and XCOM maps, but if you start going greatly beyond this it is mostly untested.

In principle you should be able to have very large grids without issue, as it mostly boils down to storing some large arrays, but modern computers have very high limits when it comes to that. Unlike in early versions of the toolkit, there are no functions run during the game that loop over the entire grid, so it should be pretty scalable. The exception is the startup code for generating the grid, which explains the loop limit stuff you've run into.

How big do you want to make this grid, though (in terms of number of tiles X*Y?). If you want to do something very big indeed you might not want to generate the entire grid at startup.

Edit: By the way, subgrids are not used for multi-level grids. For this select MultiLevel in heightmap settings for BP_GridManager. The subgrids are used for extending the size of the grid in the X and the Y axis beyond the base size of the grid, which can be useful for optimization in cases where you have a total play area that conforms very poorly to a rectangular shape.

[Dan.Ott]

Thanks for your replies

Increasing loop iterations only affects how many computations that can be done.. thus you can increase the size of grid and do more computations..
I dont think moving grid is a good idea because all the math for tile finding would be off..
Are you using alot of "foreach" nodes by any chance ? if you are try putting in a macro with "foreachwithbreak" setting break to 0.1 or 0.2 and make sure "oncomplete" has a return node, or use "foreach" with a delay of 0.1 - 0.2
try using "pregenerate gameplay grid" for sure..
Hope this helps some..


I have an old copy that has a multi level map and using that as template, My map is set up like a 3d chess game and only way to reach another level is through a teleporter/wormhole.

Would be perfect to figure out a way to move the grid and recalculate the reachable tiles and realign the tile decals.
Yap - we tried pregenerate gameplay grid, will definitely use that in the build version! No, currently there are not many foreach nodes in the blueprints.

Dan.Ott: Ah, now I see what you're getting at. I've indeed capped the grid size to 200 in the variable settings of BP_GridManager, though you can easily increase this cap. I've added the cap to signal that you're going beyond what the toolkit is tested for. I've tested at roughly twice the size of the largest Civ and XCOM maps, but if you start going greatly beyond this it is mostly untested.

In principle you should be able to have very large grids without issue, as it mostly boils down to storing some large arrays, but modern computers have very high limits when it comes to that. Unlike in early versions of the toolkit, there are no functions run during the game that loop over the entire grid, so it should be pretty scalable. The exception is the startup code for generating the grid, which explains the loop limit stuff you've run into.

How big do you want to make this grid, though (in terms of number of tiles X*Y?). If you want to do something very big indeed you might not want to generate the entire grid at startup.

Edit: By the way, subgrids are not used for multi-level grids. For this select MultiLevel in heightmap settings for BP_GridManager. The subgrids are used for extending the size of the grid in the X and the Y axis beyond the base size of the grid, which can be useful for optimization in cases where you have a total play area that conforms very poorly to a rectangular shape.

The biggest map has a size of one squarekilometer - whilst our tiles are one squaremeter (half the size of ATBTT's standard tiles). So we want the grid to be 1000x1000 tiles big. But of course it would also be nice to just relocate a way smaller grid as we actually only need a grid 128x128 sized grid for the combats, so in terms of performance simply relocating the grid to the player's position when ever a combat starts would be great - but unfortunately we're facing many problems when changing GridManager's positon and it's unclear which functions of e.g. SetupCoreBlueprints such as SetupCollisionPlane etc we need to call at what moment in order to get the grid align to the new location & it's obstacles / heightmap.

[TrasanTheHero]

Hi, I'm helping my son on a project and he have purchased your toolkit as a start for a game.

We are pretty new to Unreal and take it step by step. The toolkit is a great resource!

We are trying to get a random damage system to work and I search for and found a simple solution, I thought :-( I just added a new variable Damage_min in BP_Unit and use it in BP_Ability_MoveAttack with the Damage varible for maximum damage as input to a RandomFloatInRange, the output is the new input to the TakeDamage function, as shown in the picture.


But it will break the KillUnit, in the TakeDamage function, logic in some way so the unit gets killed but is still in the game somehow and when it's turn next you can't do any more actions.

We have followed the path in the BP_Unit function Take Damage and can se that it call,s The Kill function but are lost in how to follow it longer.

It's not possible to watch the Damage variable in the Take Damage function, it's says (not in scope), but I can se that the Current Health change so the damages works.

Have I made it to simple or is it just one newbie mistake because I don't understand the UE4 yet?

We are using a clean example map for this testing.

[Monokkel]

Thanks for your replies

No worries

The biggest map has a size of one squarekilometer - whilst our tiles are one squaremeter (half the size of ATBTT's standard tiles). So we want the grid to be 1000x1000 tiles big. But of course it would also be nice to just relocate a way smaller grid as we actually only need a grid 128x128 sized grid for the combats, so in terms of performance simply relocating the grid to the player's position when ever a combat starts would be great - but unfortunately we're facing many problems when changing GridManager's positon and it's unclear which functions of e.g. SetupCoreBlueprints such as SetupCollisionPlane etc we need to call at what moment in order to get the grid align to the new location & it's obstacles / heightmap.

I see. At that point you're even reaching the hard limits on grid size, which is 999*999 (though this can also be increased with more work). In any case this is big enough that you likely want to do something like move the grid, as you've suggested. Note that 128*128 is still really big, with the biggest Civ maps being 106×66. The main issue with repositioning the grid during gameplay is that you'll have to run the code for generating walkability at runtime. This is bound to create a noticable frame drop even on powerful computers. You would want to disguise and/or reduce this as much as possible. First consider how big you really need the combat area to be, as this has the largest impact. Next you can add a fly-in "combat start" menu covering the screen or something that can disguise the dropped frames. Converting the grid generating functions to C++ would also help quite a bit, though it would not alleviate the problem, since the line traces are still just as slow. Spreading out the generation over multiple ticks can also help, though requires quite a bit of work.

As for the specific code that needs to be rerun, you're going to need everything contained in the SetupGridArrays function as well as AddViewportUnitsToGridUnitsArray.

Hi, I'm helping my son on a project and he have purchased your toolkit as a start for a game.

We are pretty new to Unreal and take it step by step. The toolkit is a great resource!

That is great to hear! Seems like a great way to both bond and learn together. I'll do my best to help you along.

We are trying to get a random damage system to work and I search for and found a simple solution, I thought :-( I just added a new variable Damage_min in BP_Unit and use it in BP_Ability_MoveAttack with the Damage varible for maximum damage as input to a RandomFloatInRange, the output is the new input to the TakeDamage function, as shown in the picture.


But it will break the KillUnit, in the TakeDamage function, logic in some way so the unit gets killed but is still in the game somehow and when it's turn next you can't do any more actions.

We have followed the path in the BP_Unit function Take Damage and can se that it call,s The Kill function but are lost in how to follow it longer.

It's not possible to watch the Damage variable in the Take Damage function, it's says (not in scope), but I can se that the Current Health change so the damages works.

Have I made it to simple or is it just one newbie mistake because I don't understand the UE4 yet?

We are using a clean example map for this testing.

Your setup is reasonable, but you're making some mistakes when it comes to features specific to this toolkit, which is understandable. The most unconventional part of this toolkit is what I call the Action System, which keeps gameplay logic and what is shown to the player cleanly separated. This is done in order to make it simpler to queue up several different events without having to call back and forth through event dispatchers and the like. It was also added to make networked multiplayer much easier to setup.

If you look at the node right before the TakeDamage node in your screenshot you'll see a QueueAction macro. This macro communicates with the action system to show the attack animation and to change the health bar of the target when it is hit/show a death animation if the health bar is empty. TakeDamage, in contrast, modifies the CurrentHealth variable of the target unit and removes references to the unit from the grid arrays and initiative order if it reaches 0. Since you're only randomizing damage for this second part you could have a unit that is animated as if it is dead, but which is still considered alive by the game logic and vice versa.

So in short what you need to do is to input the same damage value into the macro as into TakeDamage. However you cannot simply use RandomFloatInRange for both, as you'll still likely end up with differing (random) values. So what you need is to get a random float before the QueueAction macro, store this in a local variable and then input this local variable as the damage input for both QueueAction and TakeDamage.

The action system takes some getting used to. I highly recommend watching my tutorials on this, which can be found here.

[TrasanTheHero]

Thanks for a quick replay!

Your setup is reasonable, but you're making some mistakes when it comes to features specific to this toolkit, which is understandable. The most unconventional part of this toolkit is what I call the Action System, which keeps gameplay logic and what is shown to the player cleanly separated. This is done in order to make it simpler to queue up several different events without having to call back and forth through event dispatchers and the like. It was also added to make networked multiplayer much easier to setup.

If you look at the node right before the TakeDamage node in your screenshot you'll see a QueueAction macro. This macro communicates with the action system to show the attack animation and to change the health bar of the target when it is hit/show a death animation if the health bar is empty. TakeDamage, in contrast, modifies the CurrentHealth variable of the target unit and removes references to the unit from the grid arrays and initiative order if it reaches 0. Since you're only randomizing damage for this second part you could have a unit that is animated as if it is dead, but which is still considered alive by the game logic and vice versa.

So in short what you need to do is to input the same damage value into the macro as into TakeDamage. However you cannot simply use RandomFloatInRange for both, as you'll still likely end up with differing (random) values. So what you need is to get a random float before the QueueAction macro, store this in a local variable and then input this local variable as the damage input for both QueueAction and TakeDamage.

That's explains the behavior we got and a very good explanation of the whole logic. I will give it a try creating a local variable.

The action system takes some getting used to. I highly recommend watching my tutorials on this, which can be found here.

I will watch them, again... ;-), and hopefully this time I will get the grasp on it :-)

[Illusive_S]

Hi there, im trying to find a hex behind the hex that i am targetting (for the purpose of long attack hitting 2 enemies in a line in front of unit). How do you suppose i should do that? I guess get tile in direction will be helpful here, but im kinda lost.

[Monokkel]

Hi there, im trying to find a hex behind the hex that i am targetting (for the purpose of long attack hitting 2 enemies in a line in front of unit). How do you suppose i should do that? I guess get tile in direction will be helpful here, but im kinda lost.

Double the difference in the GridIndexes of the source tile and the target tile and add it to the GridIndex of the source tile. So if the attacking unit is at GridIndex 10005005 and targeting GridIndex 10006006 the difference is 10005005 - 10006006 = 1001. 1001*2 = 2002. The GridIndex behind the target is 10005005 + 2002 = 10007007.

This math would only work if the source is adjacent to the target, as you describe in your post. For a more general solution you would need to do something a bit more involved.

[Daniel.Otto]

I see. At that point you're even reaching the hard limits on grid size, which is 999*999 (though this can also be increased with more work). In any case this is big enough that you likely want to do something like move the grid, as you've suggested. Note that 128*128 is still really big, with the biggest Civ maps being 106×66. The main issue with repositioning the grid during gameplay is that you'll have to run the code for generating walkability at runtime. This is bound to create a noticable frame drop even on powerful computers. You would want to disguise and/or reduce this as much as possible. First consider how big you really need the combat area to be, as this has the largest impact. Next you can add a fly-in "combat start" menu covering the screen or something that can disguise the dropped frames. Converting the grid generating functions to C++ would also help quite a bit, though it would not alleviate the problem, since the line traces are still just as slow. Spreading out the generation over multiple ticks can also help, though requires quite a bit of work.

As for the specific code that needs to be rerun, you're going to need everything contained in the SetupGridArrays function as well as AddViewportUnitsToGridUnitsArray.

Allright we will figure out the best approach for our needs - thanks for your help!

As recalculating the big grid on every level load & engine startup takes a lot of time we came up with a simple serialization solution. Especially when working in a team this can be helpful as you don't need to recalculate the grid all the time once it's done.

Here are the blueprints with the additions to BP_GridManager if anyone is interested in this:


Save Grid Function:
https://blueprintue.com/blueprint/az4fmqh6/

Load Grid Function:
https://blueprintue.com/blueprint/gvq3ie01/

Within the EventGraph we added these nodes to the event ActivateGridManager:


In the GridManager we added a function PegenerateAndSave with the CallInEditor property to have a button in the editor.


We added a blueprint class deriving from SaveGame with these arrays & maps:

[Monokkel]

I've sent a new version of the toolkit to Epic. The major change in this version is a modification to the ActionQueue system that allows you to insert new actions into the action queue while it is being animated. This is very useful for actions that interrupt other actions, such as overwatch shots, spike traps and the like. It seems to work pretty well, but I have one remaining concern. Early in testing I encountered a bug that prevented the action system from continuing during combat. I have not been able to replicate this issue, but neither do I feel that any of the changes I later made should be sufficient to prevent such a bug from occurring. As such I've included abilities and actions that use the new ActionQueue options in the experimental folder for now.

Now I've begun refactoring the Turn Manager, which is well overdue. If the bug I observed still remains I expect it is tied to the Turn Manager somehow, so refactoring this would also likely resolve this issue.

I've first tried to make the Turn Manager more flexible by trying to take into account several kinds of initiative systems in a single blueprint. It quickly became apparent that this would be messy, however. I've instead opted for creating child blueprint options that override various turn order functionality as needed. I'm a bit uncertain what I want to have as the default, though. The original toolkit had a very D&D-style initiative system where everyone goes in order without switching between units, and where units act in an order determined solely by their initiative value regardless of their faction. As I kept modifying the toolkit I bent this into more of an XCOM-style, with code for switching between units, keeping units separate in initiative based on their faction etc.

From seeing what people make with my toolkit I get the feeling that most people use a faction-based turn system where the player can choose freely between units and chooses when to end the turn, at which point the entire next faction gets to act. As this seems so popular I'm considering making this the default. I'm interested in what you guys think. The developers who choose to follow this thread might of course not be a representative sample, but I'd still like to know what sort of initiative system each of you are using. Feel free to post below and tell me about any quirks of your current system/how your ideal turn order system would work. As I'm in the middle of refactoring, now is the best time to influence how I'll modify the toolkit going forward.

[Methosborgoff]

Awesome! I have been watching the other devs and your progress on this for a while. for my project I would like to have options for both d&d and xcom style turns.

[Monokkel]

Awesome! I have been watching the other devs and your progress on this for a while. for my project I would like to have options for both d&d and xcom style turns.

great, thanks for the input. Just to clarify: Both options will be available, but I'm deciding which one shall be the toolkit default and which shall be set in the derived Turn Manager child class.

[DarvisA]

Hi Knut, I already bought your Blueprint, but I have some trouble, how can I use another Model outside from your given source? I try to replace your mannekin with my model but my model cannot animate walking, please teach me, Im very2 new in unreal engine.. thanks before

[Monokkel]

Hi Knut, I already bought your Blueprint, but I have some trouble, how can I use another Model outside from your given source? I try to replace your mannekin with my model but my model cannot animate walking, please teach me, Im very2 new in unreal engine.. thanks before

Hey DarvisA, I've made some tutorials on this. Here is a link to video 1/3 on adding custom units. Hope that is enough to get you where you want to be.

[leo bar]

hi knut

sorry for the late input (just came back home).

In my project I am using both method. more of the x com style method, but in some phases I use something like a chess turn.

anyway I just looked at your new update and again it is awesome!! every time you are making this tool so much more Versatile And the freedom to create new abilities in a much easier way which is great !! (you have some minor error in the experimental folder - the BP_GA_Trap -QueueAction and in the path line high, but there are easy fix).

my wife hate you

cheers

leo