[SUPPORT] Advanced Turn Based Tile Toolkit

[Envieous]

[MENTION=422736]Curiosichi[/MENTION]: What you're saying is understandable and for all updates save the next one, keeping the base toolkit unmodified and working with child blueprints etc. should be possible without too much of a hassle. However, the next update is special in that I'm doing a large reorganization and refactoring. Any updates after the next one should be primarily additive rather than transformative and should be a better fit with your preferred way of working. I'm sorry if this makes things temporarily more difficult for you, but for this particular update I felt like I needed to disregard easy backwards compatibility in order to make the toolkit the best it can be.

How difficult will it be to integrate multi tile units into the old version?

[Monokkel]

How difficult will it be to integrate multi tile units into the old version?

I don't think it will be much more difficult than integrating it into the refactored version. For the most part the underlying logic is the same for the new and the old version, but how it is structured, variable names etc. is different. So problems will mostly arise if you want to do something like [MENTION=422736]Curiosichi[/MENTION], where you make all your changes to child blueprints and then update the underlying parent blueprints. Updating through copy-paste of new features should not be that much more difficult compared to earlier updates.

[ClaimedInfinity]

Just bought it, so a couple of noob questions.

1. Is there some way to control camera rotation with mouse?
2. When playing "simulation" I get multiple cases of error "Blueprint Runtime Error: Accessed None trying to read property Grid Camera Ref from function: 'ExecuteUbergraph_ATBTT_PlayerController' from node: Branch in graph: EventGraph in object: ATBTT_PlayerController with description: Accessed None trying to read property Grid Camera Ref". Is it just because I'm playing "simulate"?

[Monokkel]

Just bought it, so a couple of noob questions.

1. Is there some way to control camera rotation with mouse?
2. When playing "simulation" I get multiple cases of error "Blueprint Runtime Error: Accessed None trying to read property Grid Camera Ref from function: 'ExecuteUbergraph_ATBTT_PlayerController' from node: Branch in graph: EventGraph in object: ATBTT_PlayerController with description: Accessed None trying to read property Grid Camera Ref". Is it just because I'm playing "simulate"?

Hi there! There is no included functionality for rotating the camera using the mouse. It should not be very difficult to add, though. Were you thinking rotation at a fixed angle or more of a free look?

As for simulate, then yeah, that is not something I really use during development, so that there are some errors are unsurprising. I would recommend not using simulate with ATBTT for the time being and just using "play in editor". I'm planning to look into it and fix it by the next update, though.

[Askyl]

edit: double post.

[Askyl]

Seems like my questions disappeared so I'll try again!

1. Can you add the entire toolkit to a existing project or is it only "start new project" that works?
2. If you have to start a new project, can you move/migrate just the grid, unit and movement to another project easily and leave the rest behind with no big issues?
3. How small can you make the hexagon grid? I'd want it really small (think.. 1/8th of Civilization 5 tiles in size)

I'm looking for a very good working grid system (with small tiles), a unit with working movement you can base other characters and units on is a big plus which is why I'm considering to purchase your toolkit! Either that or doing it my self, but 46 bucks or weeks of work, I choose the first!

[Monokkel]

Hello Askyl! I'll do my best to answer your questions.

1. Can you add the entire toolkit to a existing project or is it only "start new project" that works?

The reason you cannot choose "Add to Project" with ATBTT is that I have altered the .ini files to include input events and new trace channels. Adding it to a different project is as easy as migrating the AdvancedTurnBasedTileToolkit folder to the content folder of the other project and copying over the .ini files.

2. If you have to start a new project, can you move/migrate just the grid, unit and movement to another project easily and leave the rest behind with no big issues?

The toolkit is fairly modular. Just don't use the stuff you don't need. Just make sure you don't remove any dependencies.

3. How small can you make the hexagon grid? I'd want it really small (think.. 1/8th of Civilization 5 tiles in size)

ATBTT is designed for tiles of arbitrary sizes. There is no hard limit on how big or small you can make the tiles. Just change the default tile mesh to the size you wish and the grid will automatically resize itself.

I'm looking for a very good working grid system (with small tiles), a unit with working movement you can base other characters and units on is a big plus which is why I'm considering to purchase your toolkit! Either that or doing it my self, but 46 bucks or weeks of work, I choose the first!

I hope you'll like it if you decide to buy I've spent a couple of years refining and expanding the toolkit at this point, so though I'm biased here I think I can safely say it is good value for your money. Let me know if you have any more questions!

[ClaimedInfinity]

Hi there! There is no included functionality for rotating the camera using the mouse. It should not be very difficult to add, though. Were you thinking rotation at a fixed angle or more of a free look?

Actually for my project I don't need mouse camera rotation at all, I just thought that maybe I missed something in tutorials.

One more question: is it hard to implement any rpg-style character development screen and inventory screen with your kit? or maybe there are separate kits out there just for this thing that you can recommend? I know there are some in the marketplace, I just haven't looked into it yet and I don't know if it's easier to make the functions that I need from scratch or to buy some ready solution and merge it with ATBTT.

[Askyl]

Hello Askyl! I'll do my best to answer your questions.

The reason you cannot choose "Add to Project" with ATBTT is that I have altered the .ini files to include input events and new trace channels. Adding it to a different project is as easy as migrating the AdvancedTurnBasedTileToolkit folder to the content folder of the other project and copying over the .ini files.
The toolkit is fairly modular. Just don't use the stuff you don't need. Just make sure you don't remove any dependencies.
ATBTT is designed for tiles of arbitrary sizes. There is no hard limit on how big or small you can make the tiles. Just change the default tile mesh to the size you wish and the grid will automatically resize itself.
I hope you'll like it if you decide to buy I've spent a couple of years refining and expanding the toolkit at this point, so though I'm biased here I think I can safely say it is good value for your money. Let me know if you have any more questions!

Thank you for your reply! That sound great! So far it's still a free time hobby project but time is money, so I'll go for it! Been watching your tutorial videos today and it looks very good. You can see that there's years of polish there that I wouldn't come close even if I managed to get working functions in a few weeks. Will save a lot of time.

As a start I guess I'll just copy it all and remove the features I don't seem to need as time goes by. Seems easier. Again, thank you for your quick reply!

[Monokkel]

One more question: is it hard to implement any rpg-style character development screen and inventory screen with your kit? or maybe there are separate kits out there just for this thing that you can recommend? I know there are some in the marketplace, I just haven't looked into it yet and I don't know if it's easier to make the functions that I need from scratch or to buy some ready solution and merge it with ATBTT.

It should at least not be any harder than adding it to any other game. I'd waged it would be somewhat easier since I've already implemented units with a few stat variables (health, damage etc.). I'm afraid I don't have a good overview of the marketplace inventory systems, so I cannot give you any specific recommendations. I know it is one of the most submitted type of asset, though, so I'm sure there are many good ones to choose from.

Thank you for your reply! That sound great! So far it's still a free time hobby project but time is money, so I'll go for it! Been watching your tutorial videos today and it looks very good. You can see that there's years of polish there that I wouldn't come close even if I managed to get working functions in a few weeks. Will save a lot of time.

As a start I guess I'll just copy it all and remove the features I don't seem to need as time goes by. Seems easier. Again, thank you for your quick reply!

Ok great! I hope you'll like it. One of my primary aims has always been to keep the base toolkit pretty generic so that it can be adapted to suit most kinds of TBS games. Just use what you need and when your game is done you can strip away anything unneeded to reduce file size.

[Askyl]

It should at least not be any harder than adding it to any other game. I'd waged it would be somewhat easier since I've already implemented units with a few stat variables (health, damage etc.). I'm afraid I don't have a good overview of the marketplace inventory systems, so I cannot give you any specific recommendations. I know it is one of the most submitted type of asset, though, so I'm sure there are many good ones to choose from.



Ok great! I hope you'll like it. One of my primary aims has always been to keep the base toolkit pretty generic so that it can be adapted to suit most kinds of TBS games. Just use what you need and when your game is done you can strip away anything unneeded to reduce file size.

Haven't had much time to play with your toolkit yet. Mid Summers Eve and all. But I've been playing around and looking through your blueprints. I'll make sure to give you an update with my progress! Might take some time since it's rather big, but this'll get me started just fine!

While I'm here, when I make a grid (hex) too big (let's say 320x208) I get an error: Infinite Loop Detected in BP_Grind_Manager, asset during ForLoop with the following Call Stack:

Script call stack:
Function /Game/AdvancedTurnBasedTileToolkit/Blueprints/Gameplay/ATBTT_GameMode.ATBTT_GameMode_C:ReceiveBeginPlay
Function /Game/AdvancedTurnBasedTileToolkit/Blueprints/Gameplay/ATBTT_GameMode.ATBTT_GameMode_C:ExecuteUbergraph_ATBTT_GameMode
Function /Game/AdvancedTurnBasedTileToolkit/Blueprints/Gameplay/BP_Grid_Manager.BP_Grid_Manager_C:Activate Grid Manager
Function /Game/AdvancedTurnBasedTileToolkit/Blueprints/Gameplay/BP_Grid_Manager.BP_Grid_Manager_C:ExecuteUbergraph_BP_Grid_Manager
Function /Game/AdvancedTurnBasedTileToolkit/Blueprints/Gameplay/BP_Grid_Manager.BP_Grid_Manager_C:Add Viewport Terrain To Arrays
Function /Game/AdvancedTurnBasedTileToolkit/Blueprints/Gameplay/BP_Grid_Manager.BP_Grid_Manager_C:Create walls on grid edges



As well as the same error message for Reverse for each loop:



Next time I tried (reloaded the entire project) I got 320x208 to work with "LogScriptCore:Warning: Script Msg: Attempted to access index ###(different number) from array VectorFieldArray of length 66560!".

Can you just explain the errors a bit?

[Monokkel]

[MENTION=717421]Askyl[/MENTION]: The error you're seeing is because you are hitting the loop limit, roughly meaning you're going above the maximum set limit of calculations to do during a tick. This makes UE4 assume that there is an infinite loop in progress which crashes the program instead of letting it freeze forever.

The reason for this in your case is that ATBTT does a lot of precalculation at begin play to reduce the need for heavy calculation during gameplay. How much is done depends on how you have set up the grid manager. If you have heightmaps enabled, for instance, a line trace is sent downwards on each tile location to determine their height. For multi-level grids several such traces are used, if you enable trace for walls one such trace is used between all neightboring tiles etc. Since you have a 320x208 grid that means that each such calculation is done 89600 times(!).

There are ways to get around this limit, but I’m curious why you need to have such an absolutely massive map. Even the “huge” map in CIV VI has a map size of only 128*80 tiles, making it roughly one 9th of your map in size.

For the solutions, though, there are two things you can do. The first is simply to increase the loop limit in project settings. It can be found in Project Settings -> Engine -> General Settings -> Maximum Loop Iteration Count. Try adding another zero to this, and I think the error should disappear. However, for maps of this size I would recommend pregenerating the grid before the game starts, so that clients would not have to do these calculations once the game has been built. Pregenerate Gameplay Grids is a public boolean in the grid manager. This uses the construction script, which also has a much higher loop limit. If you do this, note that any changes you make to the map after checking this boolean will not affect the map, so make sure to re-check this boolean if you make any changes.

[ClaimedInfinity]

How does it affect performance if you have each skill spawned as a separate actor in a map? Like in the Jungle Raid example. Let's assume there are around 30 pawns in a map, each pawn has around 20 skills (average) and 7 pieces of equipment. This raises a number of actors to around 1000. Maybe it's better to have a number of bool variables and spawn/destroy specific skills when needed looking at those variables? I'm not a big specialist in coding so I can be completely wrong of course.

[Monokkel]

How does it affect performance if you have each skill spawned as a separate actor in a map? Like in the Jungle Raid example. Let's assume there are around 30 pawns in a map, each pawn has around 20 skills (average) and 7 pieces of equipment. This raises a number of actors to around 1000. Maybe it's better to have a number of bool variables and spawn/destroy specific skills when needed looking at those variables? I'm not a big specialist in coding so I can be completely wrong of course.

Yeah, I gave this quite a bit of thought when I first made the skill system. Unreal Engine has a really high threshold for invisible actors, so it is very unlikely to be an issue. Ian Shadden, who made a turn based strategy system in parallel with me used invisible actors to represent all tiles of his grid. From his reports this did not affect performance much and for a large grid this could reach 50000 actors or more. I prefer to refrain from using loads of invisible actors unless I have to and use arrays instead, but this is mostly personal preference.

This preference extends to the skill system, though, and initially I did as you suggest and spawned skill actors when needed. However, having individual actors had benefits like storing the number of remaining charges, cooldowns etc.

One of the things I'm currently working on for the next update is making the skill system a part of the base toolkit and as such I am trying to make it cleaner, simpler and more flexible. What I'm doing now is to have all units with the same skill share the same skill actor. When a unit with a skill system component is spawned, the map is checked for instances of its skills. If the skills do not exist in the map and instance is spawned. If not, a reference is set up tied to the already existing skill actor. This way there will never be more skill actors in a map than there are skills in play.

To solve the issue with charges and cooldowns units now have an optional skill sysytem component that tracks its skills and their cooldowns/charges etc.

But like I said this mostly comes down to taste. For the number of actors you are describing this should not really matter.

[Curiosichi]

Might I suggest:

Right now pawns are placed on the grid in the editor ahead of game time, with their skills chosen from a public editor variable drop down list. Simple, static, and handy, right?

Soon as I got deeper into working on my game did I realize that these skills and player stats need to persist to the next battle, and the static placement and selection of stats doesn't work for that, so characters needed to load from a data file.

Perhaps you might consider loading the characters/pawns and all their stats, placement locations, and skills from an start up struct file, and placing them dynamically on the grid at game (grid manager init) start.

Thoughts?