So I'm making a 2D Tower Defense-game in Unity with C# where the enemy has to go to the base, but can go to the wrong path randomly and then turns around when the road ends. How can I achieve this?
2
-
\$\begingroup\$ It's difficult to help when you provide so little about what you know/can do. Do you know how to do the random choice? How are you moving your character? etc. \$\endgroup\$– Gazihan AlankusJul 28, 2016 at 11:28
-
\$\begingroup\$ @GaziAlankus Right now I'm using a code to move the enemies by making them follow empty transforms, but I don't know how to make them change the one they're going to and just decided to scrap it and start fresh. I don't know how to make the random choice. \$\endgroup\$– PogsNfiddlesJul 28, 2016 at 12:01
Add a comment
|
3 Answers
\$\begingroup\$
\$\endgroup\$
1
check the manual for navigation, https://docs.unity3d.com/Manual/nav-NavigationSystem.html. I am guessing that you are able to set a nav mesh even on 2D. And have a value in your enemies that if they reach a point where they can't move forward (combine it with a raycast from the object) they turn back...
I hope i was of some help
-
1\$\begingroup\$ Worth noting that NavMesh only works on a 3D object (i.e. something with a mesh). However, there's nothing stopping you using a 3D NavMesh and NavMesh Agent and then have all sprites rendered in 2D. Then it's just a case of randomly selecting your end point and then re-selecting (excluding attempted paths) after the end point is reached \$\endgroup\$– hobnobJul 28, 2016 at 9:53
\$\begingroup\$
\$\endgroup\$
2
Dig up your Dijkstra shortest path algorithm and make the enemy go to the current active node before advancing it.
-
\$\begingroup\$ Sounds helpful for shortest path. Does not sound helpful for allowing the choice of the wrong path. \$\endgroup\$– GnemlockDec 9, 2016 at 1:54
-
\$\begingroup\$ Actually I think it does. It's rather an ingenious solution, although might require a hierarchical search methodology (when you hit the dead-end you now need to pathfind back to the new current search node and that search shouldn't fail!) Would be tricky to implement, but still a clever solution. \$\endgroup\$ Dec 9, 2016 at 6:05
\$\begingroup\$
\$\endgroup\$
In order to do the behavior you describe your enemies are going to have to be aware of where there is a choice on which direction to go and (to guarantee they get to the base eventually) what they have already tried.
One way to do this is to treat the path as a simple graph of nodes with a position and one or more linked nodes. Once you've done that, your enemies can simply walk from their current position to their next target node. Once they've reached a node, they then pick their next node based on simple logic:
- Increment the value for the path from the new node that goes to my previous node (note these values should be located on the monster, not the actual shared node, each monster has to figure it out for themselves!)
- Store the node that goes from this one that has lowest value. If there is a tie choose randomly from the lowest ones available.
- Increment the value on the current node for the way you're going (this is to make sure we don't turn around unless we're at a dead end)
- Start walking towards the next target node.
This will cause a monster to wander until it finds the base while always trying the most recent other option when one is available.
- When reaching a dead end (node with 1 linked node) the monster will increment the way it came, and then choose the lowest value path which is... the way it came from (since there are no others)
- When continuing a path (node with 2 linked nodes, think of a corner) the monster will increment the way it came from and continue on to the other option naturally (The increment the way we're going step keeps us from returning to this node with all directions at the same value).
- When reaching an intersection with more than one path forward (node with 3+ linked nodes, your example has 4) the monster will pick randomly from the available nodes one it hasn't tried yet, since the nodes it has tried will all have higher values. In the case that all directions are dead ends, then the lowest valued path will be back the way the monster originally came.
Note that this method makes some assumptions. If your monsters can be teleported then it will cause issues with this method. Likewise if your path has intersections where both paths meet further ahead then you're going to need a better way to keep track of tried paths as this method assumes that the path was exhaustively searched before returning. This will however give you a good start to your framework which you should be able to expand upon, while also allowing twisty paths for free as a bonus.
