[Unity3D Hex Map Game Dev] 3: Units, Pathfinding, Vision and Fog of War
Hello Unity fans. It’s time for Part 3 of my series of videos in which I’m reviewing, and also adding on to, Catlike Coding’s hex map tutorial. I’ll link to the previous videos in the description, or you can follow the link in the top right, right now to start at the beginning. At the end of Part 2 we had populated our base geography with all kinds of features – roads, rivers, buildings, plants and walls. We are now ready to add units. To facilitate unit movement, we need to consider distances, path finding and movement animation. Exploration is usually an important component of hex map games, so we also cover fog of war, uncovering the map when exploring and advanced vision, where the terrain influences a unit’s vision.
Part0 (Introduction): • [Unity3D Hex Map Game Dev] 0: Introdu...
Part1 (Hexes to Water): • [Unity3D Hex Map Game Dev] 1: Hexes t...
Part2 (Features and Textures): • [Unity3D Hex Map Game Dev] 2: Feature...
Catlike Coding's Website: https://catlikecoding.com/unity/tutor...
Animated Human model: http://www.quaternius.com/
---*----* My Playlists *----*---
Unity Journey Of Discovery (Tutorials): • Unity Journey of Discovery: Hello Wor...
The Main Course (Maths and Science Concepts Explained Visually: • Sun, Earth and Moon: Introduction and...
Eco-Pool Natural Swimming Pool (Build and Progress): • Green/Eco/Natural Pool, Part 1: Plann...
4K Treats (Ultra HD content): • Marine Life Photos Part 1 4K UHD
Finger Snacks (Shorter, Unclassified Videos): • Ribbon Eel (Rhinomuraena Quaesita) Sw...
*----*----*----*----*----*----*----*
To make it easier to visualize our workings, we add a grid texture to the terrain shader. Adding a multi-compile directive to the shader gives us variants with and without the grid. This can be toggled on and off as required by adding a UI component as well. Next, we add an “edit” mode toggle to swap between the map editor and the unit movement mode. We also adjust our coordinate display system so that we can rather display distances between hexes. We start off by just calculating the lowest number of hexes from each cell on the map to the selected cell, or the shortest path. However, this does not take obstacles into account. In preparation for navigating obstacles, breadth-first search is implemented and tested on an empty map. The search process is visualized and slowed down so we can track what it’s doing. Next we let the search algorithm treat water and cliffs as obstacles it cannot pass, and it looks for a way around them. This leads to islands that cannot be reached. These obstacles are binary, completely blocking the passage. We add another binary obstacle, namely walls. But we also want to add non-binary movement costs – certain terrain should be more difficult to get through, but you should still be able to travel through it. On the other hand, a road should make travel easier or faster. So, we add movement cost to the calculation, making roads much easier to travel, and hexes with features more difficult to get through. Travelling across slopes also leads to higher movement cost. The breadth-first search cannot handle these variable costs properly, so a priority queue is added to the search algorithm, indicating which of the cells on the frontier should be visited first. It now happens that a certain path to a specific hex found later in the search process could be a shorter path than a path found earlier in the process. In these cases, the movement cost to the hex need to be updated. This approach is called the Dijkstra algorithm.
But knowing distances between hexes is not enough. We also need to be able to find a path between selected starting and destination hexes. To show the workings, we implement a visualization method by which a highlighted hexagon outlines all hexes on the chosen path. In order to remember the path taken, you have to store the hex from which each hex in the path has been reached. As soon as the destination hex has been found, you can follow the references back to the starting hex. This algorithm does find the shortest path, but it spends a lot of time investigating possibilities that, to us at least, are obviously pointless. The next step is to make the search algorithm smarter. We achieve this by adding a search heuristic. This is a factor that is added to the movement cost between neighboring hexes whenever a decision needs to be made on which hexes to try next in the search. The heuristic we add is the shortest possible movement cost from the next candidate hex to the destination hex, as if it they were connected by the most easily traveled terrain on the shortest path between them.