That looks incredibly good, Gaara! It’s fantastic to see the toolkit used with proper visuals, and I love the modifications you’ve done. Some of these I was planning to add at a later point, such as displaying enemy visibility on hover, attacking from flanking etc., and it’s comforting to see that you’ve got it working so well. Did you find the toolkit easy to work with? Are there any recommendations you have for improving usability and commenting?
As for my next update, it will be a pretty big overhaul, but the core system is mostly the same. Converting your additions should hopefully not be too hard, and if you’re running into any particular issues you can always ask me in this thread, and I’ll try to respond quickly.
Thanks! I’m just happy to see people using something I’ve made, and solving people’s problems is both enjoyable and will help me improve the toolkit in the future.
Indeed I am. What tipped you off? I own both Oculus developer kits and I’m using virtual reality in my day-job as a cognitive neuroscientist. My own game development plan is also to develop a turn based strategy game for virtual reality, so I’m excited to see what you accomplish. One word of warning, though: The pathfinding and visibility generation in my system is fast, and are done in less than a frame for paths of moderate length. For very long paths or when running on weaker hardware the pathfinding might however take more than one frame. This almost isn’t noticeable for most games, but for VR keeping a constant framerate is essential and it might potentially pose a problem. I haven’t tested it out myself, but it’s a suspicion. To combat this I will in two updates be including an optional macro for calculating paths over multiple ticks. It might not be an issue at all depending on the move values of your troops, but I thought you should have a heads up.
To be fair I consider myself a noob in many areas of UE4 as well. It’s less than a year since I was only able to print “hello world”, but I am of course pretty knowledgeable about the specifics of my toolkit.
How are you scaling the grid? You should not scale it by using the regular scale widget. Instead scale it by using larger meshes as the default tile mesh and increasing Grid Size X and Grid Size Y. Is this what you’re doing?
Current SplineDistance tells where the current pawn is located on its movement spine during movement. I have not intended for it to be called outside of movement, so I’m not surprised it yields confusing results. I would instead use the length of the Path Index Array. The Path Index Array (I might have changed the name since, but it’s something like that) stores all the indexes on the grid that a pawn will move during its movement. I think the best way to do what you’re describing is to create a new integer variable on Unit_Parent called LastMove or something and at the beginning of a unit’s movement set LastMove of Current Pawn to PathIndexArray.length (set it to 0 if the unit does not move this turn). Then when attacking calculate to hit chance modified by the LastMove values of the attacker and the defender.
This one is tricky. If you read some of the previous posts on this page you can see some of the problems associated with implementing multiple floors. This is actually pretty tricky to do, and I have not found the ideal solution yet, though I do plan to add this in a later update. Expect that to take a while, though. You can of course use height maps, rooftops etc., but there can be no overlapping, walkable tiles directly above/below each other at the moment.
This requires a bit of tinkering, but there are certainly ways you can do this. You would use the toolkit as usual, but would have to create individual path splines for each unit. When you click to move somewhere you would not animate the unit or move it along the spline, but would update arrays in the same ways as in the begin- and end movement parts of the blueprint. Then when you press go you would move all pawns at once, modifying the move pawn section of the Grid Manager to accommodate multiple units. This will probably be easier come my next update, where movement is handled within each unit’s individual blueprint.
This is a bit tricky, but not impossible. The difficulty would depend on how you do it. If the AI should be able to decide what to do every step of its movement it’s harder than if it moves to a point and then decides what it can shoot, similar to how it is now. The most important thing to be aware of is to design things so that all visibility traces are done before it is needed, and not simultaneously, as multiple units checking visibility at once would surely drop the framerate.
This one is a bit hard for me to estimate. Like I’ve mentioned I’m still a complete beginner when it comes to many aspects of UE4. Multiplayer is one of these aspects, so any guess to how much time it will take will be rather poorly founded. I can say that I intend to look at multiplayer after I’ve implemented touch controls, multi-level grids and a couple of game examples. What this means is that I almost certainly won’t be done with multiplayer before your deadline. Hot-seat is a lot easier, but I guess you don’t want people switching their headgear every minute 
You’re welcome!