Thanks for the suggestion! For games that includes character advancement of persistent characters between levels, some sort of solution similar to what you have mentioned will need to be implemented. I would want to add something like that in addition to and not as a replacement to the current solution. ATBTT’s built-in drag and drop placement is very easy to work with and is suitable for many sorts of TBS games, so I’ll always want to keep that as the default. The Spawn Unit function is included to easily add units dynamically during gameplay, but it will always create a default unit of the class selected, so it is not sufficient for persistent units with changing abilities and attributes. The best solution for persistent units is something I believe is pretty genre dependent, so if I add this in the future I think I would want to do so in a game example. For my next game example I would like to make something similar to a tabletop rpg like D&D, and for this I’d want to add some sort of database solution for tracking character advancement. I won’t be adding this in the next update, but somewhere further down the line.
Few more ideas for ya:
So I had to add a Boolean on Spawn Unit() of Grid Manager, as right now it adds unit to the initiative by default. Adding the boolean allows you to avoid adding it by default.
Also, I added a “Load All Player Units” function call to Grid Manager, and call it from Game Manager right before the “Sort Pawns In Initiative Order()”. The “Load all Players()” loads characters or creates based on a save slot, and Spawn Unit()s each unit.
Init Character () is a helper class I made to make setting all variables much much easier. It also sets up the unit references at the start.
And now, my game board has no player units places in the editor; they are all loaded dynamically. The Sort Pawn In Initiative Order() call right after Load All Player Units() then adds all the editor Pawns AND the dynamically created one to the Initiative order at this time. If the character had data in the save slot to load, than all the inputs are mapped to the Init Character() instead of the defaults or manually set variables (not shown in photo).
The next goal is to kinda figure out a better way to place them. By Index could work I figured out, but I need a helper class of some sort to figure out what index a particular square is IN EDITOR.
You got any ideas for that? Setting by location kinda works, that is just super lame as I have to create an object in editor to drag around and then copy the coordinates that way. Maybe there is a way to create an editor object that displays Index is possible?
How are you saving Arrays of Arrays? Array of Pawns with an Array of Skills. If you are implementing multiplayer you are using gamestate I assume and that you require the use of that right? My guess is moving to an set of Boolean values for knowing a skill or not. Any other ideas?
Thanks for answering my questions earlier, just bought the toolkit. I’m trying to play around with using the grid in a map that is already compiled and I’m using the Simple Office demo level for this. I’m using a grid that is larger than the intended playing area and was planning on walling off the outside of the map with the invisible wall pieces. I’m finding that the pawns can’t move when inside the level even though I don’t have the invisible walls setup yet.
Is there a way to get the grid to ignore the collision of anything that isn’t the intended invisible wall pieces or am I just doing something completely wrong collision wise here? Also I do believe collision is active for all of the meshes in place but turning them off seems to change nothing.
How do I get the pawns to move inside the level?
@Curiosichi: Thanks for your suggestions and showing me your own solution
Spawning the units early on before Sort Units in Initiative makes sense. Your functions for adding the units seems a bit cumbersome, however. If you have to specify all attributes and the location of each unit manually I don’t really see the benefit compared to placing the actors directly in the viewport. At the very least I would create a sub-function that you could loop through using a custom struct array containing all relevant variables. That way it would extend to any number of units. Other than that it is hard to provide input when I’m uncertain of the goal you wish to achieve.
If I did something like XCOM, for instance, I would probably store each character in a custom struct array in the game instance, or possibly use a data table. The attributes would in this case be created by a combination of base stats, random variation and player input. If you tell me your goal I can provide better suggestions for a good way of solving it.
As for figuring out which index a particular square is, you can check Precalculate Gameplay Grids and then check Show Tile Indexes. Note that if you make any changes to the map that would affect pathfinding after this point you need to re-check Precalculate Gameplay Grids.
As for arrays of arrays, the easiest way is to make a custom struct that contains an array and then make an array of these structs.
@OperatorCrux: To be honest I have no idea what is going on here… When the path is displayed pathfinding seems to work fine for the tiles inside the walls, so the grid setup is not affected. I think the only explanation is that the trace under the mouse pointer is being blocked somehow, but you say that removing collision from all the other meshes did not work, so that is odd. I would try one more time to be sure. Check through the scene outliner and make sure that collision is disabled for all meshes and volumes in the scene. You don’t really need to disable all collision, just the one for PathTrace, but as a quick test just disable collision for them. Come ask me again if you’re positive all collision is disabled (except for the Grid Manager, of course) and I’ll think hard to find out what might be causing this.
Cumbersome in this use case, but it isn’t actually ever used.
My game creates all the character data before we get into game mode / grid manager, so when loading player units, it loads from the save file. In the picture I linked above, that is the false side of a branch checking for that save data. And in early development, I just load a few characters as if they were placed on the grid.
So since I have to save each stat individually, I iterate over the arrays of the save file data and create the characters. Granted yes, the stats will likely be generated by the items the character has equipped, this is more just a proof of concept.
I create Starter Tile objects that are placed in the grid manager, and use their locations to map starting locations for the loaded character units. I select, from the top of the saved character list, one by one to place on those tiles. For example, if I have 2 starting grid locations, I pull the top two character’s save data and load them onto the map on those two tiles. In the same way, If I had N starting tiles, I select first N characters to place on those tiles. A simple Is Valid() check on the retrieved character data array avoids any problems trying to fill a character start tile with an invalid character.
Do note, that Skills are still not saving since I have not remedied the array of arrays issue, but i’ll look more into the structs. Or maybe i’ll do a list of Boolean values for “know skill” for each skill in the game, and if they know the skill add it to their list of skills here.
My desired result:
Save character data if it doesn’t exist
Load desired battle map / game manager
Load character data/skills/items
place units on grid
do the battle
Save experience gains / new items acquired for all player units
I also need to keep in mind if I make/want multiplayer (which I will probably wait for your implementation) I will have to change both the save data with game state. I haven’t researched it much yet.
@Curiosichi: Ok, that seems a lot more reasonable. I’d really recommend you to look into structs, though. Not only can you easily make nested arrays, but you can also simplify your above function substantially by using an array of structs containing all unit attributes instead of having a separate attribute for each one. The game state is kind of like an extension of the game mode for variables that need to be replicated, such as a list of players etc. Useful in multiplayer, to be sure, but I don’t think it is warranted for the spawning of units at the start of the game.
Alright so I solved the problem! I had disabled collision for everything except the ceiling. So it turns out that the ceiling tiles were having some weird collision error because the collision box went lower than the mesh itself. Disabled the ceiling collision and it works perfectly now.
Ok, good. That was the only possible cause I could think of, so I’m glad taking a second pass did the trick.
Hey, this is the thing I’m thinking about now. Before you spawn the skill actor you need to know if your pawn has learned it or not. Obviously you can’t do that based only on “learned” boolean or something like that in skill class. The most crude but the simplest way is to create a few booleans (one for each skill) in pawn class and this is fine enough if you have relatively small number of skills. But if you have (let’s take Final Fantasy Tactics as an example) over a hundred of those skills? And if all booleans will be in the same function it will literally look like Tower of Babel. I’m sure there are more elegant ways but I’m still looking for them.
Well my thinking is if not Boolean, the current setup has each pawn spawning an actor and holding a reference, so whether its a Boolean or a skill reference, one way or anther there is going to be a huge list of skills. Unless I can think of a bit flag and corresponding map on a single variable, but I haven’t had to think in binary and how that might work in Unreal yet.
Don’t think it gets any smaller then a bit flag, but its still the same principle, maybe just less memory though.
I’d probably go for a Set of skill class references. I highly doubt this would become a memory issue. There would have to be an extremely large number of skills per unit + stored units for that to be the case.
How are multi tile units coming :)?
Haven’t made any more progress on that progress specifically. As mentioned I’ve planned to split the next update into two so I can get it out faster. First I’ll finish the update with everything but multi-tile units (networked multiplayer, major refactoring, transform-independent grids), as adding multi-tile units before this would just complicate making these changes later. I’m making great progress at that front, though, so in that sense I’m getting closer The next update is mostly feature-complete at this point, but there is still a long process remaining of testing, bug-fixing, structuring, commenting etc. Summer holidays is also going to slow down my progress the next few weeks, but I’m putting a lot of my free time towards getting it done in a timely fashion.
Neato. Really looking forward to it.
Currently attempting to get the units to spawn dynamically, however the pack doesn’t seem to like that as I get dozens of accessed none errors if there are no units on the grid when it starts(most likely the custom unit spawns is getting called after the other begin plays already initiated), however there never is a certainty of which items will spawn as it’s generated from another level(how and why is not relevant).
Are there events I need to delay until after I spawned the units myself? If so, could you point me to which ones I need to callback after spawning the units? PC/Pawn/GM/Etc? I can callback all of them but to avoid breaking anything I find it safer to just ask.
Currently just calling back the gamemode and it seems to work.
Hey! You’ve got it right. The game mode is what you need to call back, as it signals the start of the first unit’s turn, focuses the camera on the active unit and sorts units in initiative order. I’ll be making it so starting the game with no units in place will work without issue in the next update.
this is your fault
real talk though, is this the method you’re using for your implementation of multi tile units?
@Selentic: Haha, I’ll take full responsibility Yeah, that is what I’m doing in general terms, though the devil is in the details. If your game uses a square grid, has a single level and no thin walls between two adjacent tiles, then implementation is fairly straightforward. You would pregenerate an array like the one in your picture by checking larger and larger square combinations of tiles until you reach an impassable tile (The CheckIfPassable function can be used for this) and then log the size of the unit that can fit into that square in an integer array. You then use a custom pathfinding function (in the Custom Pathfinding macro) for large units where you check this array after the branch where you check if a tile’s cost equals zero and do not continue if the integer is smaller than the size of the unit (which you store as a public variable in BP_Unit).
That mostly solves things for pathfinding. However, large units will be able to overlap each other like this, as units are not stored in the big units array. You can do this by checking all appropriate tiles for every pathfinding search step during gameplay, which is a bit cumbersome. You can also check with an appropriately sized collision box that overlaps all units for each step, which is what I am doing currently.
Now you have some more problems, as you will need to have the toolkit know that you select a unit (for say attacking) when clicking any of the tiles it occupies and not just the “real” tile in the upper left corner of its occupied spaces. You could get most of the way here by using the unit array and filling up all appropriate tiles with a reference to the unit. You would need to change this dynamically during gameplay. I did this by storing all the currently occupied tiles in the actor of each large unit and removing the references when the unit moves/is destroyed. You would still need to update most functions involving selecting units to work with this new system.
Alternatively you can swap to a system of directly clicking a unit’s mesh instead of the tiles it occupies. This would require some work, of course, but should be fairly straightforward.
Now for the visuals. All meshes that show unit selection/targeting etc. need to be dynamically resized and shifted appropriately to fit under a large unit. Showing tiles in move range is another beast entirely. I’ve found a solution for this, but explaining it will take some time. If you manage to implement the rest I’ll explain it to you. Also, if you are using units that are 22, 44 etc. where the center of the unit is on the intersection between four tiles, you can no longer use simple tile locations to do stuff like place spline points for movement, placing markers etc. and will need to shift this by half a tile width/length as needed.
That should be most of what you need. If you want hex grid support as well it becomes more difficult, as the “corner” your unit is placed cannot be transferred simply from square to hex grids. Thin walls between tiles are very tricky, as you can no longer simply check “IsTilePassable”, but need to check every edge for every tile and see if it an edge exists pointed in the appropriate direction. Multi-level grids might be the most difficult of all, as the grid does not a priori know if tile 101 is physically right next to tile 100 or if it is next to 200, 300, 400 etc. This makes pregenerating the large unit array a bit of a nightmare.
As mentioned, I think I’ve found solutions for all of this, but it is no small undertaking. I hope you can see why I wanted to wait with implementing this until I was done with all the other major changes, as it relies on many other part of the toolkit, many of which will be changed quite a bit in the next update.
If you want to tackle this beast I wish you the best of luck, and feel free to ask here if you need help along the way
I probably wouldn’t have thought of it right off the bat if you hadn’t decided you were going to add it into the toolkit. At the time I was sitting there with an absurd 15x15m tiles to fit vehicles, where infantry were incredibly difficult to see as a result. I realized that was awful but didn’t really have a solution for how to keep tiles big enough for vehicles, but not be ridiculously huge for much smaller footsoldiers.
Then boom, you announced it.
That’s more or less where I’m at with this. I piggybacked it into the existing pathfinding exactly as you said. As far as units go, It should be trivial enough to regenerate the array and treat units as obstructed tiles the same way it treats terrain entities. Seems to work fine during run time on a relatively small grid, but even if it ends up expensive to run I can probably find ways to cut out a good portion of tiles that do not need to be updated, and run it at a point where the game doesn’t accept input anyway, so no one would notice a half second of it being regenerated. I hadn’t thought about thin walls, but I don’t use too many of them, so I can probably store their indexes as well and add in a more complex check when it runs into them.
That’s exactly how I was planning to do it. Getting a series of indexes in a square is pretty simple math to pull off, and just write a reference to it in the pawn array whenever it moves.
I think I have some idea of how to have tiles in move range represent themselves properly visually, and that’s what I’m going to implement next (after a quick nap). I’ll check back in with the results. Offsetting/resizing the other ui elements should be simple enough.
Luckily I’m not using Hex grids. I would have absolutely no idea how to approach them.
Did it. (There’s some weirdness here because tile costs don’t make logical sense yet for this unit) Basically just did a simpler version of the clearance algorithm where I take each tile that can be moved to, and make a unit size squared grid from that position, then add it to the list of tiles to spawn movement tiles on. I’m curious to see how this is going to play with visibility tiles, but I’m not quite there yet.
I solved walls by deleting the south and east ones, and only using north and west then adding them to an array. Since I search from the top left, I can just assume that if I hit a tile that’s marked as having a wall, it can be treated exactly the same as one that’s fully obstructed.
Still gotta offset the UI elements and whatnot.
I also had a few ideas for how to lower the cost of the clearance check, since I have to run it every time a unit is activated. I don’t actually need to regenerate the whole grid, I only need to update unit size -1 away from the unit on activation, and after moving. I can also ignore any 0 tiles, since those will always be 0, and aside from rare occasions where a tile could go from blocked terrain, to open that will remain accurate. For those situations, re-running the algorithm on all the open tiles to the top left of that up to the maximum search can solve that.