Announcement

Collapse
No announcement yet.

[SUPPORT] Advanced Turn Based Tile Toolkit

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by Monokkel View Post
    Ok, that's a bit of a corner case, but I can see how it would be useful in such cases. However, having multiple grids that you are able to move between would require changes to both Pathfinding and Find Tiles in Range, which would for every tile checked also make sure there might be any tiles that can be moved to/seen outside the bounds of the current grid. This would in the very least require some new branches.

    This might not seem like that big of a deal, but every new addition to those very heavy function means a measurable slowing in the calculations. Even though this would probably not be noticeable to the user I would personally prefer map building to be a bit more awkward compared to making pathfinding less efficient if I was to make a T-map.
    I'd prefer that too tbh. I just wondered what was possible

    Keep up the amazing work!

    Comment


      Originally posted by Monokkel View Post
      I'm interested in knowing what People would use multiple grid managers for, as most cases I can think of are pretty niche. For dungeons one can simply use a single grid that is large enough to encompass all the rooms in the dungeon. The toolkit is efficient enough that there isn't that much to gain in terms of optimization for dungeons this way.
      I know that in XCOM, on some landed/crashed UFOs, the tiles on the UFO itself is rotated 45 degrees compared to the rest of the map. But in that case I think that it would be easier to let a single grid manager handle rotated tiles as well somehow. But you know it better than me.

      Comment


        Originally posted by AxelRantila View Post
        I know that in XCOM, on some landed/crashed UFOs, the tiles on the UFO itself is rotated 45 degrees compared to the rest of the map. But in that case I think that it would be easier to let a single grid manager handle rotated tiles as well somehow. But you know it better than me.
        Ok, didn't know that! I couldn't find any screenshot that showed this off well, but it's kind of hard to tell when they don't really show the grid. Could they have faked it doing something similar to this?

        Click image for larger version

Name:	GTBtKav.jpg
Views:	1
Size:	83.9 KB
ID:	1081932
        The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

        Comment


          Originally posted by Monokkel View Post
          Ok, didn't know that! I couldn't find any screenshot that showed this off well, but it's kind of hard to tell when they don't really show the grid. Could they have faked it doing something similar to this?
          I know that at least one of the medium ship maps does this. There may be more maps that does it, but I'm absolutely sure there are at least one map that does it.

          However, they might have faked it the way you show in the screenshot.

          Comment


            Ok i have just recently baught this toolkit and it is amazing!!! i realy like how everything has been designed so user friendly just some stuff that confused me and i would like to know more about!

            in the tutorial where you add destructable terrain you use a function that sets a variable named pawn array or something like that and then you access it this is really wierd because wouldn't it have been easier just for that function to have a result we can access?!?! and then set any variable we desire? beacuase right now it seems i would have to run that and then get the variable and set my own variable every time a procedure that i find no sense in?!?!

            for mobile development since we can't use decals as i recall! what would you advise on using to show tiles on terrains with height?



            the second is to do with multi level grid your system uses indexes to identify every tile you could use a 2d array and that would solve identifiers as for detecting you could use a multi line trace and have the results get compared to determine if it is two levels or not! as for path finding it wouldn't be that hard because the same edge system would work in a 2d array system only considering the first element! since you use cost to determine access this system should work realy well. and your visiblilty trace already works in hight and at least right now i can't think of anything tha would need to be considered! your continuing support of this product is epic and i hope i can help the toolkit get even better!!

            Comment


              Hey Monokkel, one last quick question, and then I'll get out of your hair. :P

              Where in the Blueprints does the cost of moving to specific tiles in the arrays get determined and calculated when determining what's in range of the pawn that they can move to?

              Rather, more specifically, where does the height cost get added into the tile's cost?

              I'd like to set pawns to be able to optionally ignore the height costs if they can "fly"(Possibly ignore "difficult terrain" as well), which I'm assuming can be done pretty easily with a branch node or two, I'm just iffy on where.

              I tried fiddling with the Search and add Tile function thinking I might be able to override the costs from there, but that gave me rather odd results (Character had a movement of 10, but could only move 2-3 spaces per movement phase)...

              Comment


                Originally posted by AxelRantila View Post
                I know that at least one of the medium ship maps does this. There may be more maps that does it, but I'm absolutely sure there are at least one map that does it.

                However, they might have faked it the way you show in the screenshot.
                Ok, thanks. I'm sure you're right. I'll keep collecting corner cases and if I find enough I'll move it up on my priority list, but needless to say the list is pretty long :P

                Originally posted by a_najafi View Post
                Ok i have just recently baught this toolkit and it is amazing!!! i realy like how everything has been designed so user friendly just some stuff that confused me and i would like to know more about!
                Thanks! I'll try to help as best I can.

                Originally posted by a_najafi View Post
                in the tutorial where you add destructable terrain you use a function that sets a variable named pawn array or something like that and then you access it this is really wierd because wouldn't it have been easier just for that function to have a result we can access?!?! and then set any variable we desire? beacuase right now it seems i would have to run that and then get the variable and set my own variable every time a procedure that i find no sense in?!?!
                You're thinking that it could have an integer array as input/output, so you could specify what array you want to fill yourself? I agree that that makes sense as people start experimenting with the functions some more. The main reason it is not like this at the moment is that Find Tiles In Range initially had a very specific use, and was only used for pawn visibility. As only one of this would ever be called at once, there was little reason to make the function messier to accommodate for different arrays. I will change the function to have an input/output array in the next update, and do the same witht a few other functions (such as pathfinding). Thanks for the suggestion

                Originally posted by a_najafi View Post
                for mobile development since we can't use decals as i recall! what would you advise on using to show tiles on terrains with height?
                You can still use instanced static meshes with heightmaps, as long as the terrain is composed of flat/slanted tiles, as the ISMs will rotate to fit the underlying tile. For stuff like moulded landscapes this looks really bad, though. I guess one could use a spline that connected all the outer tiles of the tiles in the CanMoveTo array which hovers a bit above the ground. You could also use floating orbs or similar on the edges, though this might not look that good. There might also be other possibilites than decals for projecting onto terrain, such as ligting/shadow that could acheieve similar effects to decals, but I haven't tested that out yet.

                Originally posted by a_najafi View Post
                the second is to do with multi level grid your system uses indexes to identify every tile you could use a 2d array and that would solve identifiers as for detecting you could use a multi line trace and have the results get compared to determine if it is two levels or not! as for path finding it wouldn't be that hard because the same edge system would work in a 2d array system only considering the first element! since you use cost to determine access this system should work realy well. and your visiblilty trace already works in hight and at least right now i can't think of anything tha would need to be considered! your continuing support of this product is epic and i hope i can help the toolkit get even better!!
                Ok, thanks for the input, but I’m having a somewhat hard time following what you’re saying. Are you suggesting that I simply make my 2D arrays into 3D arrays by doing the same thing as when I converted my 1D arrays into 2D arrays? What I mean is that if I have a 3*3*2 array, index 4 would be in the center on the bottom level, while index 13 would be on the top level etc.? That’s the way I have considered doing it myself. It requires larger arrays than if I use smaller sub-grids to represent higher levels, but arrays can be extremely big without any issues, and it will be a lot simpler to work with for users.

                Pathfinding would be easy in this case as I could do what I’m doing now, but also check up and down. If I check every up and down direction, though (upNW, upNE etc.), this would more than triple the amount of tiles search, slowing down pathfinding significantly. Therefore I would probably only want to check directly up/down and then check the surrounding tiles if the one directly above/below is marked as walkable.

                My visibility system does not work in height at the moment, but it would similarly be pretty easy to expand to a 3D array. I’d still need to check how seriously it will affect performance, though.

                So to sum it up, 3D arrays are easy, but might not be the best performance wise. I’ll test multiple solutions as I start working on multi-level grids for the next update after the coming one.

                Originally posted by Shenku View Post
                Hey Monokkel, one last quick question, and then I'll get out of your hair. :P
                Don’t worry about it. I honestly enjoy answering questions about the toolkit

                Originally posted by Shenku View Post
                Where in the Blueprints does the cost of moving to specific tiles in the arrays get determined and calculated when determining what's in range of the pawn that they can move to?

                Rather, more specifically, where does the height cost get added into the tile's cost?

                I'd like to set pawns to be able to optionally ignore the height costs if they can "fly"(Possibly ignore "difficult terrain" as well), which I'm assuming can be done pretty easily with a branch node or two, I'm just iffy on where.

                I tried fiddling with the Search and add Tile function thinking I might be able to override the costs from there, but that gave me rather odd results (Character had a movement of 10, but could only move 2-3 spaces per movement phase)...
                Various aspects of height/movement cost are set a few different places. Firstly, all actors of the Tile_Parent class have a public variable called EdgeCosts that determines the cost of entering that tile from a certain direction. These costs are added to the EdgeArray in the Add Viewport Terrain To Arrays function in BP_GridManager (inside the second comment box). If the toolkit is set to automatically change edge costs depending on height differences this is done in the third (hexagonal) or fourth (rectangular) comment boxes in the same function.

                If you want units to ignore terrain costs you could indeed change this in the Search And Tile function. Here’s one way to do this which will only have a very slight impact on pathfinding efficiency:

                Click image for larger version

Name:	KVl1BVh.png
Views:	1
Size:	189.4 KB
ID:	1082019
                The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

                Comment


                  Mutlitier support in the update after next?

                  This toolkit gets better and better

                  Comment


                    Originally posted by tamaster92 View Post
                    Mutlitier support in the update after next?

                    This toolkit gets better and better
                    That's the plan You can see the list in the first post for most of the major planned features. After the next update, which is mainly focused on mobile and 2D, the next will be for XCOM-style tactical squad based games, with multi-level grids, cover systems, advanced combat abilities (such as overwatch), fog-of-war etc.
                    The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

                    Comment


                      Thanks for the detailed explanation!

                      very smart on using an example! so i'm going to do the same to explain!

                      3*3*2 is a small enough example and good

                      i am actualy saying change the index to a 2d element instead of 4 use (4,0) and 13 would be (4,1)

                      now the tricky part might seem that path finding would have to change dramaticly but no! because in the same way 4 shares an edge with 1,3,5,7 it shares and edge with 10,12,14,16! or in the 2d way (4,0) and (4,1) both share an edge with {(1,n),(3,n),(5,n),(7,n)} n being the floor number in this case 0 and 1.

                      but obviously two tiles on top of each other share any edge but you would simply always consider it null or zero (none passable)! now for the search load in identifying all of the edge costs!

                      ok i am horrible at explaining so i'm going to upload a photo of a test map the same size you said 3*3*2 and this explanation is for that!
                      (i am not going to consider how your system acts with tiles out of the maps borders as i don't have it in mind and i am not going to consider diagnal movement either it is a complication but i don't think it could break any thing)

                      for the sake of this example i am going to consider that edges have the same cost of passage between two tiles example : going from tile a to tile b has the same cost of going from tile b to tile a (two tiles share an edge)
                      so a default tile will share an edge with every tile around it on the same floor with the cost of one (if they are default tile) and share an edge with every tile around it on its top and bottom floor with the cost of ( none passable) considering they are default tiles. As a default grid map would act in this example a 3*3 grid floating on top of another 3*3 grid
                      in this example I have made 5 of the second floor tile into nothing tiles which share an edge cost of 0 with every thing and I have added two walls making the cost between two tiles on the floor it is on into 0 and between the same tiles and the tiles in front of them but in the upper level also zero in other words:
                      (0,4)<->(0,5) cost = 0 / (0,4)<-> (1,5) cost = 0
                      (0,7)<->(0,8) cost = 0 / (0,7)<->(1,8) cost = 0
                      and one wall ladder that makes the cost between the two tiles on the same floor equal to zero but for one of the possible routes in between levels it makes the cost 1 or any number meaning passable!
                      In other words:
                      (0,0)<->(0,3) cost = 0 / (0,0)<->(1,3) cost = 1
                      So later when path finding check costs and it reaches (0,0) and it sees the cost of one it will add (1,3) as a possible destination and reachable tile

                      Now I now there is a lot to talk about doing to do with optimization for example right now in a 4 square grid not considering diagonal movement for a two floor map the checks will get twice the size for each tile!!!! For a 3 floor map saying we might want something like a ladder connecting the first and the third it woulf be three times the checks and so on and so forth so I think it woul be much better to have an outer level reach check of some sort but in the end we are talking about a three floor level the summed checks would already be a lot if the three floors where put next to each other.
                      If I was still not able to give a good explanation please pm me and we can talk over it on skype

                      Click image for larger version

Name:	FullSizeRender (1).jpg
Views:	1
Size:	675.5 KB
ID:	1082054
                      Last edited by a_najafi; 07-19-2015, 04:52 PM.

                      Comment


                        Originally posted by Monokkel View Post
                        That's the plan You can see the list in the first post for most of the major planned features. After the next update, which is mainly focused on mobile and 2D, the next will be for XCOM-style tactical squad based games, with multi-level grids, cover systems, advanced combat abilities (such as overwatch), fog-of-war etc.
                        I'll be interested to see how you do cover systems - i've started slowly adding one into the toolkit for my game but it's very basic atm - just volumes attached to certain tile types which tells the pawn he is in cover

                        Comment


                          @a_najafi: Thanks for providing such a thorough example. What you are describing is pretty much exactly what I had in mind myself. I will still need to fake a 3D-array just like I've faked a 2D-array, since blueprints do not allow for multi-dimensional arrays, but that's really not a problem. Making a multi-level grid is pretty much exactly like making a 2D-grid, and the only potential issue is performance.

                          I might not have understood your example correctly, but I do not see how it will be better performance-wise compared to other methods, something I think you acknowledge in the last part. A quirk of my toolkit compared to regular graph-based pathfinding algorithms is that I store every edge for every tile, even though those edges might be 0.

                          If I was using C++ I would simply remove those edges at startup, meaning they would never have to be searched, which would make multi-level grids almost as fast as 2D-ones. I have tried to implement such an approach in my toolkit before, using an array of arrays, each array containing all the edges of a tile. However, this method turned out to be significantly slower than my struct-based approach for almost all types of levels (2D ones), so I scrapped this solution. What is quick in C++ is not always the same as what is fast in blueprints, which is something I've had to learn through trial and error. So if I use my current approach I will always have to double or triple the amount of searched tiles if I use multi-level grids.

                          How much this will slow pathfinding down is an empirical question, and it might not be that bad, as most searches will quickly return false, but it's hard to know for sure. Therefore I've pre-planned a few approaches. I could mark certain tiles with a boolean as having access to other levels (say tiles with ladders), and only search up or down if this is set to true. I could also use a hybrid approach of my struct-based pathfinding for the 2D-grid, with arrays of arrays for searching up or down, where the amount of edges returning 0 would be much higher, making arrays more efficient.

                          I will begin testing all of this as soon as I'm done with my next update. I hope I understood what you wrote. If you feel I have missed some essential parts we could discuss it on Skype, as you suggest.

                          @tamaster92: I've shared my ideas on how to implement cover-systems with a few users before, but it might have been in PMs. There are two ways in particular I've considered using.

                          The first is a dynamic system using tracing similar to what I currently do for regular visibility. In addition to the head-to-head tracing I currently do I would also do a trace from the attackers head to the defenders torso (and/or legs). If all traces return false (have not hit any cover), this would give the highest hit-chance. This is very simple and efficient, and could work on many different types of map, but it's not my favorite approach, as I prefer something a bit more predictable for turn-based and grid-based games.

                          My current favorite solution is to have a cover-variable on all tile_parent actors, designating the amount of cover the tile gives in different directions. I would then feed this information into a grid-sized array that would store the cover values in their appropriate locations, granting a defense bonus if the unit in cover is attacked from a direction on the other side of the cover (by simply comparing X and Y locations of units). A benefit of this is that it's both very quick (since most stuff can be pre-calculated), and it can be easily used to display XCOM-style "shields" or similar for all tiles in move range, by using the indexes in the CanMoveTo Array to check the Cover array.

                          Something akin to this is what I plan to implement for the update after the next.
                          The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

                          Comment


                            Hey Monokkel, I'm working on implementing Line of Sight based visibility of enemy pawns. Most of it's working fine, but I'd like your suggestion in one last area. By default, the enemy pawns are set to invisible if the player doesn't have a line of sight to them. When a player unit moves through tiles which should technically grant a clear line of sight to an enemy unit, I'd like to make that particular enemy unit visible from the said tiles.

                            I figured that using 'Find Tiles in Range' for each tile in movement might be the most accurate approach, but may end up being a bit too costly. An alternative approach would be to have an invisible square/circle collision mesh that can detect enemy pawns during movement. If any enemy unit overlaps with the mesh during movement, we make them visible/hidden based on a line trace as well as whether they're already visible from any other unit from player team. It will give clean results for square line of sight, but is a bit inaccurate if we go for Diamond line of sight. Maybe checking the distance to overlapped units and comparing with the range of the unit could take care of that situation as well.

                            It's more of a hack approach as I really do not have any need for the storage of information regarding enemy pawns that the bot sees while it's moving. Would you suggest any alternate approaches to handling this particular situation?
                            Last edited by Stormrage256; 07-22-2015, 07:19 AM.
                            Unreal Possibilities
                            Tower Defense Starter Kit [50% OFF] | Line of Sight Visualization [50% OFF] | Wave Spawning System [70% OFF]
                            NEW: FPS Tower Defense Toolkit v3.11 Update [50% OFF]

                            Comment


                              Originally posted by Monokkel View Post
                              Various aspects of height/movement cost are set a few different places. Firstly, all actors of the Tile_Parent class have a public variable called EdgeCosts that determines the cost of entering that tile from a certain direction. These costs are added to the EdgeArray in the Add Viewport Terrain To Arrays function in BP_GridManager (inside the second comment box). If the toolkit is set to automatically change edge costs depending on height differences this is done in the third (hexagonal) or fourth (rectangular) comment boxes in the same function.

                              If you want units to ignore terrain costs you could indeed change this in the Search And Tile function. Here’s one way to do this which will only have a very slight impact on pathfinding efficiency:

                              [ATTACH=CONFIG]48648[/ATTACH]

                              Sorry for the delayed response, I got side-tracked into setting up other gameplay systems/map building, and forgot to check back here to see if you replied yet...

                              Anyway, I tried adding the node as you show there, but it doesn't seem to have any effect what so ever, movement over and around different height hexes remained unchanged (as in, the pawn couldn't jump off cliffs, or walk directly to the highest point of a cliff-side, it still went around the long way to gradually move to the top). I even tried just setting it to 1 without the Int Select node, and it too had no effect. Note that I am still running in 4.7 (too lazy to update just yet...), so could it be something that you changed in the 4.8 version that I'm missing, or possibly a bug with 4.7 itself...?

                              Comment


                                @Stormrage256: Ok, I've run some tests. I think using Find Tiles In Range will actually work pretty well. If you check "Find only Pawns" it's actually pretty **** quick, and testing with a unit with a range of 20 with 20 enemy units within range it found all pawns within range with tracing for RangeTrace in 65 milliseconds, much less than a frame. That being said, using a volume to check for overlapping actors is still orders of magnitude quicker, with 0.054 milliseconds without tracing and 0.60 milliseconds with tracing. Choosing one method or the other is highly unlikely to have any perceiavable impact on performance, but those are the numbers, in any case.

                                You can quite easily create volumes in UE4 that fit diamond shaped and hexagonal visibility. For diamond shaped, use a cone volume aligned to its side. For hexagonal visibility use a cylindrical volume with 6 sides. I'll be adding something like this myself in the update after the next, as it will be useful for overwatch-style events. Unsure what method I'll end up using. I'm pretty **** when it comes to choosing the most efficient solution possible, but I also prefer keeping things within the grid arrays if I'm able.
                                The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

                                Comment

                                Working...
                                X