The primary way to move things about in CCBK.
storage workers moving items, hunters collecting meat, architects inspecting buildings
An important field of the Walker Component is the Pivot. The Pivot is a transform in the center and root of the Walker. It is used to transform and rotate the Walker. If any of these things go wrong check that the Pivot is correctly assigned.
Among other base functions Walkers have a setting for PathType which specifies the kind of pathfinding it will use to get to its destination.
Check out the scenes in …/CityBuilderCore.Tests/Other/MovementPlayground for interactable examples!
Simple A* Pathfinding inside the road network on the map. Usually used for all kinds of destination walkers.
carriers delivering goods, workers walking to a monument site, …
Same as Road but points with RoadBlockers are removed. Usually used for all kinds of roaming walkers.
water carrier distributing out water,
This Pathfinding uses Unity NavMesh. All demo scenes have a gameobject called Navigation that is used purely to generate the NavMesh. To change the NavMesh follow these steps.
- activate Navigation gameobject
- adjust the objects inside Navigation
- make sure Navigation Area is correctly set to Walkable/Not Walkable
- bake the NavMesh
- deactivate Navigation gameobject
If you want the walker to use a NavMeshAgent instead of strictly following the path you can assign one to the Agent field.(as seen in MovementPlaygroundMap test scene)
immigrants walking to their new homes, hunters walking to pray, …
Simple A* pathfinding of all points on the map that are not occupied. Only feasible for small maps, on larger maps use Map pathfinding instead.
The Path Tag field on WalkerInfos can be used to pass any kind of Object along to Pathfinding. The following ways to use this are already built into CCBK.
Either assign the WalkerInfo itself to the field or check the Path Tag Self checkbox to send the WalkerInfo itself to Pathfinding. By using the checkbox an additional Object can be assigned to the Path Tag field.
For example the Three demo has RoadBlocker buildings with RoadBlockerComponent components that block off certain WalkerInfos that can be changed in a dialog window.
By using a MultiRoadManager instead of the DefaultRoadManager and creating Networks for each Road it is possible to have multiple road networks that can even overlap. The Road object assigned to the walkers Path Tag then decides which network a walker can use. If the Path Tag is left empty in this scenario the walker can use any network.
The Urban Demo uses this for the Road and Rail Networks. The Urban Demo also has an example of road switching in an extra scene called Tunnel which demonstrated the RoadSwitcherComponent that can be used to switch walkers between different RoadNetworks. Keep in mind that the start- and endpoint has to be on the same network.
Multi roading is also demonstrated in the MultiRoadDebugging test scene. (/CityBuilderCore.Tests/City/Movements/MultiRoadDebugging.unity)
The DefaultStructureManager has a field called PathOptions which can be used to define additional Pathfinding Networks on the Map. These Networks differ from the normal one either by only using certain GroundOptions(Tiles) or by restricting the level of structures that block it. The Tag on the path option has to match the one in the WalkerInfo for it to be used. This could technically be anything but one of the Tiles is probably intuitive.
Structure pathing is demonstrated in the StructurePathDebugging test scene. (Assets/SoftLeitner/CityBuilderCore.Tests/City/Movements/StructurePathDebugging.unity)
The walker base class includes helper methods for various modes of walking. These save their states automatically and can easily be continued on loading.
Directly pass a WalkingPath for the Walker to follow it immediately.
used when the path is checked before the walker is even spawned like storage walkers
Tells the walker to try to find a way to a target or give up after a certain time. The walker can be given a target building or position to check pathfinding by itself or a function that returns one.
deliver walkers spawned by production are spawned and have to figure out a path afterwards
The walker randomly walks around while trying to avoid points already visited. It does for a set number of steps specified in Range, how many positions it remembers is defined in Memory.
well workers handing out water, bazaar workers selling food
Moves to a random adjacent point
These allow encapsulating the state and logic of an action a walker can take. A series of these actions can be started as a process on a walker which will then perform them in order. For example a lot of the tasks in the town demo use a WalkPointAction followed by some animated action like WaitAnimatedAction.
In the earlier demos(three, defense, urban) walkers were more or less single purpose so the actions they take are baked into the implementation of the walker. The newer town demo uses a single walker to perform a wide variety of actions which is why this higher level way of controlling them was created.
To create an action with new custom logic simply create a class that derives from WalkerAction. For a minimal example check out the WaitAction which simply waits for a set duration before letting the process continue(or finish if it’s the last one).
The persistence of walker actions is a bit atypical for CCBK, instead of having some save method that returns their state they are directly serialized. This means that [Serializable] and [SerializeField] attributes have to be set up and fields that can’t be directly serialized have to be converted using ISerializationCallbackReceiver. A simple example of this can be found in WalkBuildingAction which has a reference to a building which has to be turned into an id for serialization.