Hello Unity fans. In our previous video we managed to expand on our woodcutter’s functions to easily include stonemasons and some rock for them to go to work on. There’s a link to that video in the top-right and the description below. But both our resource gatherers are still walking straight through their cabins as if these do not exist. Today, we’ll fix that by specifying the directions from which certain hexes can be approached and letting the existing pathfinding methods find a path while incorporating these additional constraints.
Part0 (Introduction): https://youtu.be/92Gab40nufM
Part1 (Hexes to Water): https://youtu.be/2ktop35T2rI
Part2 (Features and Textures): https://youtu.be/V-iAaIYliBU
Part3 (Units, Visibility): https://youtu.be/ZfutE1LlTvA
Part4 (Random Maps): https://youtu.be/HpqD3m6VmVM
Part5 (Post Processing): https://youtu.be/ejbL2fNlaZk
Part6 (Resource Gathering): https://youtu.be/9ddQMTeRCa8
Part7 (Spinning Selector): https://youtu.be/0otHclifG9o
Part8 (Preparing for Resources): https://youtu.be/BsnlfoPkj5w
Part9(How Much Wood?): https://youtu.be/87800hX4idc
Part10(Dynamic Trees): https://youtu.be/uCulaS6H_bo
Part11(Meet The Meeples): https://youtu.be/sglozmOoPdE
Part12(Harvesting Wood): https://youtu.be/xwgK1BWWDjo
Part13(Harvesting Stone): https://youtu.be/LGtn9BIl1dU
In Parts 2 and 3 of this series, we’ve added walls and roads to our map, and developed a pathfinder that enables our units to walk around walls where a road, representing a gate, is present. We find ourselves in a similar situation now. We want to be able to block certain travel directions on certain hexes, forcing the unit to approach his cabin from the front, rather than walk through the walls. We can implement the same mechanics as the visible walls and roads, but we do not wish to actually show anything on screen this time around. Furthermore, we want to keep our current, visible, wall and road functionality intact, so we create copies for the invisible versions, and make sure we update the code everywhere to cater for this new functionality. We add an indicator for an invisible wall, and an array of invisible roads, representing invisible gates in the invisible walls. Now, we consider all the places where walls and roads play a part, and decide how to handle the invisible versions in each case. We need to be able to test whether and invisible road runs through an edge between any two hexes, and we need to be able to add an invisible road through the edge between any hex and any of its neighbours, and remove it as well if required. These new methods are exact copies of the visible versions for the most part, so rather than making copies we could generalise the functions to enable us to specify whether they should be applied to the visible or invisible versions, but for now we will keep them separate until we’ve got more certainty about all the functionality we will eventually cater for. Also note that we need to update our save and load functions to handle the additional pieces of information about our hexes correctly. Where the movement cost between hexes is calculated, we can see how the movement cost is 1 if there’s a road connecting the hexes, and that movement is not possible between hexes with different walled states if they are not connected by a road, since that is precisely where solid walls would be located. By adding to this if statement, we can also test for invisible walls and invisible roads.
Now, when we add a unit and also add his cabin, we need to make sure that we also activate the invisible walls and roads correctly. For now, we will let our cabin always face this way, and we’ll get to adjusting its rotation based on the proximity of resources in all directions a bit later. In this case we want the hex on which the cabin is placed to have an invisible wall, while only the edges with the neighbours to the South-East and East should have invisible roads passing through the invisible walls. This will force the unit to only be able to move to the hexes to the South-East and East when exiting the cabin, and only move into the cabin from those hexes as well, giving us the walled functionality without actually showing walls and roads.
If we test this, we see that it works as intended. Only the two hexes in front of the cabin is accessible to the unit, and he walks around the cabin the get to resources behind it, then around again to get to the front door of the cabin. We could give each cabin a randomized rotation, but we could actually rotate our cabin more intelligently when it gets placed, let’s say to face the nearest initial resource. When we create the unit, we can let it search for a resource and save the path it finds. Next we look at the first step of that path and figure out which direction that is.