@nrm2112: The very question you’re asking there is actually the reason I started working on this in the first place! I wanted to test out if blueprints were viable for making an entire game.
Back when I started, even more than now, there were a lot of people who said you had to use C++ if you wanted to make anything serious. This toolkit handles all the heaviest operations you need when making most turn based strategy games, and does so in less than a frame for even long paths and visibility tracing. From this I can pretty confidently state that the assertion that you can’t make a full game in blueprints is simply false. Certainly for turn based games, at the very least.
I wrote a thorough writeup of my process of learning UE4 and making this toolkit on Reddit a few weeks ago. You might want to read it if you’re just starting out and have doubts about the power of blueprints, like I did.
Great!
I actually created a new custom function and attached it in the grid manager blueprint instead of your Sort “Pawns in initiative order”, but as I said before I had a lot of problems.
Actually I’m not completely sure that was my fault or perhaps I’ve found an Unreal Engine 4 bug or glitch.
When I will have time I will paste to you the old algorythm, just to let you understand what I did and maybe to understand what went wrong.
If you prefer I can send it on a private message or share the graph here, then if it is really an UE4 bug I can send the snapshot to Epic to help other unfortunate people.
Meanwhile, I’d like to implement your algorythm, but actually I’m not able to scroll the blueprint to see it entirely. How can I use keyboard or mouse to scroll the view in BlueprintUE.com?
Anyway thank you very much, you just saved me from another week-end of pain
No problem I needed to add this functionality sooner or later anyway. I won’t be adding it to the main blueprint, since it’s a bit too game specific, but I’ll be adding it when I make my dungeon crawler example map. As for the link, you don’t need to see the entire graph. Just copy the text code under the graph and paste it directly into your blueprint graph.
Feel free to post your old algorithm here, and we can try to figure out what went wrong.
Sorry if you see it badly but I had to let all blueprint boxes closest together as possible to put all in a single screenshot.
Anyway, I think that is pretty clear to understand.
I spent some time looking at your blueprint and I can’t find anything obviously wrong with it. I’m having a bit of a hard time debugging it, though. There are a lot of temporary variables changing that are dependent on one another so it’s hard to grasp everything that’s going on. I would suggest doing what I do sometimes and write down an array of pawns using pen and paper. Then go through the blueprint and adjust the array and variables on paper just like it would have happened in the graph. It takes some time, but when working with confusing, interdependent blueprints it’s sometimes what I have to do to find the error.
Sorry I couldn’t help you find the error, but I’m pretty tired after working on the toolkit all day. You should probably use the solution I gave you anyway, since it’s cleaner and requires no temporary variables. I can recommend you use more foreach loops, by the way. There are a couple of places where you could have simplified the graph significantly by using them instead of forloops.
Hi Oskarek,
I’m glad you asked. Finishing the update is taking longer than I originally planned for a variety of reasons. The main one is that I’ve decided to split the Grid Manager blueprint up and distribute it among Game Mode, pawns, the grid manager and player and AI controllers. Making the toolkit more modular will make adding future updates simpler, and prevent users from having to re-add every new feature they’ve made every time I add an update. I pushed this up to the highest priority as something that had to be in place before adding more updates, as it will serve as the base for all future additions. Reorganizations is tedious work and takes a lot of time. I’m working most free hours I’ve got on it, but it’s a bit slow going. I’m closing in on my goal, though.
For my next update I will probably add auto grid generation and meshes conforming to the landscape, but not the mobile support stuff. The auto generation is a big change to the underlying system, and is thus something I want to get out early. The mobile controls is something that can be added on top quite easily later, so I’m saving that for the update after.
To give you a straight answer to your question I estimate having the first update done in just over a weeks time.
I’ve tried your algorythm, it’s very clear and fast, so I’ve definitely chosen to use it in my project.
Meanwhile, I’ve also finally implemented an insertion sort working solution, if somebody needs this kind of sorting (mostly in the game projects where unit array is almost sorted every time: in this case the insertion sort it’s the best algorythm with a linear O(n) quantity of operations) you can find it here:
This insertion sort order elements with an ASC sort direction, so you should put the lower initiative value for the units you want to attack first.
You should probably also post it in the blueprint subforum where more people might see it. I did something similar back when I was using A* instead of Dijkstra where I was sorting several times every tick. For something that’s going to be sorted once it’s a bit overkill, which is why I made the simpler algorithm. I’ll be including it in the project at a later point, when I make my dungeon crawler example map.
In other news I’m done splitting up the Grid Manager and spreading it across the Game Mode, Player Controller, AI controller, Player Pawn Camera and Unit Pawns. It took four days of hard work, but now I can soon begin working on finishing up grid auto generation.
I haven’t started doing any major work (mostly just playing around and learning) because I know the structure of the blueprints is changing. I’m excited for modularity update so I can rest easy knowing that I will be able to integrate new features and changes that you add to the toolkit in the future.
Glad to hear you’re having fun with the toolkit. Even though I’ve done a lot of restructuring, the underlying logic is very special, so any modifications you do shouldn’t be too hard to convert. Just a warning, though. Even though I expect to be done in a week, Epic is often extremely slow with adding updates, so you can probably expect a couple of weeks more for them to upload the new version.
Hello, I was wondering what the best way to create a single tile preset that covers multiple tiles is. Say you have a wall with an entry way that spans three tiles. You want the end tiles to be blocked and the center one walkable.
@Gryphun: You mean for creating pre-made rooms of muliple tiles that you can place in your level without placing them individually? A similar question has been asked earlier in this thread. To give you the short answer I believe that the best way to do this currently is to place the tiles in the viewport, selecting them all and grouping them (ctrl + G). Then you can copy the groupl and place it elsewhere in the level. In the next update I’m releasing there will be a different way of doing this as well. You will be able to generate walkability of meshes and terrain placed in the level without having to place any tile actors. This way you can simply model rooms of any size in whatever software you prefer, set the collision to block PathTrace, place them in the level and check “auto generate walkability and height”.
Sorry, I should have included more details. I have a function that, right now, places random(blocking) tiles in the scene in BeginEventPlay callback. This works great for items that only cover a single tile. I want to be able to procedurally place items that cover multiple tiles.
I guess the one way to do this currently is to write the blueprint for each item that will spawn blockers at the correct locations.
Thought it sounds like your update will solve my issue. Thanks.
You should hopefully be able to fix the problem with the next update. You would have to run the auto grid generation function after spawning the tiles.
Edit: Another way to do it that would take some more work is to create a child actor of tile_parent with an additional integer array and edge cost array. The integer array would hold the array indexes on the grid of the surrounding tiles to be modified while the edge cost array would hold the edge costs of the same tiles. The indexes in the array would have to be set automatically depending on the index of the main tile. Then in the event graph of the Grid Manager you would get all actors of your new tile type and set the indexes in their integer arrays to the costs of the corresponding structs in their edge arrays. Significantly more complicated, I know. But that’s one way to do it before the new update hits the marketplace.
I had a quick question about making a multi-layered grid. Figured out how to make multiple layers that a player can move up and down on, the problem I’m trying to make it so a player can travel under a space, for example, having a building with multiple floors. One way I was going to try is having multiple layers, and the pawn would “teleport” between them, but I wondered if there was an already built in way of handling something like this.
@Saffron: If you look at the planned features list in the original post you can see that overlapping grids is a planned feature, but it has not been implemented yet. It is not something that is trivial to add, and will mean having to modify features, such as pathfinding and visibility tracing quite heavily. Depending on how proficient you are with blueprints I must warn you that adding it yourself might be a pretty big challenge. If you need this feature now and cannot wait a month or two for me to implement it while you work on other parts of the game I wish you luck, and will be very interested in following your progress.
If you’re interested, this is the way I am currently planning to implement multilayered grids, though this is just a rough sketch that I haven’t tested the viability of yet: I would create a new sort of actor called a subgrid that would share some, but not all features of the Grid Manager. It would have its own arrays for things like walkability and the position of pawns as well as its own array that would store what indexes in the subgrid correspond to what indexes in the Grid Manager in their XY location (this would be calculated in a similar way to how tiles and units placed on the grid are assigned their indexes). Pathfinding, visibility etc. would be driven from functions in the Grid Manager. Connection tiles would have to be designated for where the Grid Manager is connected to a subgrid, either in its own array or as a separate up/down direction in the Edge Costs array that would be checked during pathfinding. For visibility the same indexes would be checked on both the Grid Manager and the subgrid, using a macro to translate indexes on the Grid Manager to the corresponding indexes on the subgrid.
That’s roughly what I’ve got planned at the moment, but I’ve got a few more features to add before I start working on it myself (check the planned features list). I might end up doing something else entirely, but I can’t be sure until I start experimenting.
Hi, so I’ve recently started tinkering with the Advanced Turn Based Tile Toolkit, and in doing so a question has come up that I haven’t been able to find an answer to in reading through the thread thus far. I should note that I’ve an extremely limited understanding of UE4 and its machinations as I’ve only recently begun learning the how-to:s of the engine and working with blueprints, so bear with me. In any case;
I’ve created a project using the ATBTT package, after which I went on to try creating a new level in which I’ve placed the grid manager, grid camera as well as a single player-faction melee character for testing purposes. When I hit play the camera ended up fixed at what appeared to be the grid manager’s origin point (0, 0, 0), regardless of how I moved the character. After some tinkering I ended up manually reseting the “BP Grid Camera Ref” to the current area’s “BP_Tile_Camera” object (even though it was already set to that). When I did this, the camera instead only displays what the editor’s camera position happens to be when I hit play, which makes even targeting tiles to move to difficult. In either case, I’m wondering if you know of a reason or something I’ve missed (the likely scenario here) which would cause this issue to occur, and how I can go about setting up the camera properly in a newly created level.
It’s worth noting that right now the sample map and new map both have grid managers and tile cameras. Is this a problem? Do they need to be named differently to avoid conflicts? Am I just being silly? It’s also worth noting that I’ve imported another content package into the current project, but none of that content should influence any of the ATBTT functionality (and I’ve removed all the other content and tested again to make sure of this).
I’m at a bit of a loss, and I’m sure I’m just missing something glaringly obvious here as an UE4 beginner. Any help/pointers is much appreciated. Thanks!
welcome to the forums and to Unreal Engine! I hope my toolkit will be helpful as you’re learning to use blueprints. There might be various reasons why the camera is not working properly, so what I want you to do is to follow these instructions exactly and see if you get it working:
Create a brand new project with the toolkit. Click “add to project” on the toolkit in the vault, but do not add it to an existing project (I know this is confusing. I’ve tried to ask Epic to change it to Create Project). Select a new folder and a new name and create.
Create a new level using the default setup. Delete the included floor mesh and player start.
Drag the grid manager into anywhere in the viewport. Set Grid Size X and Grid Size Y to something a bit larger than default. Say 9*9.
Drag BP_Grid_Camera into the viewport and place it anywhere.
Modify any public variable on the Grid Manager. For instance click “Snap to Custom Grid” off and on. This is to get the construction script of the Grid Manager to update and discover the Grid Camera. I have changed this in the next coming update so you don’t have to place a grid camera at all and it will spawn automatically. But for now do it like I described. This is a bit counterintuitive and I suspect it might be the reason for the issue you’re having.
Place any of the player units onto the grid and click play. The camera should follow the unit and can be panned with WASD, rotated with Q and E and zoomed with the scroll wheel.
Please tell me whether this works or not. Whatever happens this will help inform me as to why the camera wasn’t working properly for you.