koobas.hobune.stream
The 'correct' way to deal with animations in a grid-based game?
I have a hexagonal grid generated in runtime with a script (so as far as I know, using NavMesh isn't an option), and related pathfinding and movement is working decently, but I've ran into a wall when it comes to applying animations. I've tried creating specific animations to move from one hex to all surrounding ones and letting root motion do the actual moving, and also tried reading relative speeds and angles of my other movement system with a script and passing them to a blend tree, neither of which I could get working properly. So what would be the 'correct' way to go about doing animations in a turn based game with a grid? I tried looking for any examples or guides, but couldn't find anything suitable. Would much appreciate a point in the right direction. Animations are where my projects generally grind to a halt
I'm not sure if I understand the problem correctly, but what I would do is it to create generic animations for walking etc., without any of that fancy root motion stuff, and then just move characters from one tile to the next via script (transform.Translate, Vector3.Lerp or whatever works for you) and play the animation while moving.
I would have each of your grid cells having a waypoint in the center of them. This isn't necessarily required, seeing as you could just use the transform, but I'm not sure how you have that part set up. Either way, by associating a waypoint to the center of each grid cell, you now have a place to go. How you get there is a different story. I wouldn't count a NavMesh just yet. If the entire world is flat, and the grid cells don't have a collider or aren't supposed to be an obstacle, you could use a NavMesh and then just set the destination to the waypoint above the selected grid cell. Now, there are obviously other methods to go about this, but it again, really depends on how you want to make it. Another solution would be to create paths to all nearby grid cells. This will allow you to create your own waypoint system. Then you just have to determine how you will get your character to move.
A simple movement like Vector3.Lerp would work work just fine. However, make sure you use it correctly. At this point, you would want to set the parameter of speed to whatever speed you would like inside the attached Animator. Then have the animation to blend from idle to walking if the speed parameter is greater than 0.1 or something just a tiny bit above 0. Why? Well it offers a nice dead zone padding when testing the variable just in case it wasn't set directly to 0. This should get you started.
I recommend the creating the custom waypoint system. To make paths, you should test if any waypoints are in a certain range, which all grid cells should be equal distance from a single grid cell. You don't want the range to encompass other waypoints beyond the distance of 1 cell away because then you will have a large number of paths being created and it will bog up memory. I recommend looking into the A* Pathfinding AI Design Pattern. They have a unity package called that, but I wouldn't use that unless it now offers dynamic waypoints. You will have to create this yourself unfortunately. The end result will be very awesome though! NavMesh may be the easiest thing to setup however. You could also just setup the character to go to the target waypoint, but making the paths would allow your character to do so in a more specified way! So if you told the path to go 3 cell blocks away, it travels to each cell block's center before going to the next cell block as opposed to just cutting through cell block's to get there. Also, having a waypoint system will allow you to count how many cells you have to move to get to the destination. So if you limit them to 3 cell block movements per turn, this would be the approach to use. Your choice, hope that helped!
Oh wow, yeah, I didn't actually think of doing the Nav$$anonymous$$esh like that. I do have a pathfinding system that is based on A*, and adding a physical waypoint generation system to that shouldn't be too big of a deal (and honestly I need to do something like that at some point anyway, so that's nice). I'll definitely see if I can get a Nav$$anonymous$$esh to work like that and report back, thanks!
Just came back to say that I did some extra testing, ironed out all the nonsense and it's working like goddamn clockwork and I love you for pointing that Nav$$anonymous$$esh thing out. $$anonymous$$uch love, man
Pre-creating a plane for the Nav$$anonymous$$esh definitely worked and I'm only slightly ashamed I didn't think of that myself, thank you! Feels good to actually progress again, though my animator goes absolutely goddamn bonkers, so I still have some fixing to do, but the theory holds up. Thanks a bunch, man
Sorry for not replying, I try to check back after a few days to see if there are any extra questions. I'm glad to see that the Nav$$anonymous$$esh is holding up! I wasn't sure how you had the terrain in which a static Nav$$anonymous$$esh might not have worked with dynamic grids. $$anonymous$$y recommendation is go with what works! Don't feel the need to create your own path system if the Nav$$anonymous$$esh is working. It's when it stops working or you want it to do more that you will need to create your own thing. Best of luck with your game!
