Youtube video link
So in this simulation, agents (represented by dots) choose one direction to move according to surrounding circumstances. Theoretically all agents make the decision and move simultaneously, but what if two dots decided to move to the same position and collide with each other? How in practice does the program solve this?
My guess is it actually executes the calculation one by one in order but this somehow violates the presumed requirement of simultaneous interaction. Because any dot's calculated move advanced in time might change the other one's surroundings of status quo, thus alters the intended move of the latter. On the other hand this seems to be the only way to avoid collision problems.
Any help thanks!
Related
I'd like to add some sort of "properties" to different areas of the level so they can affect NPC behavior.
Level layout:
level layout
What NPC behavior I want to achieve:
NPC can freely walk around Area #1
NPC isn't allowed to go to Area #4 in general but it may decide to go there in some exceptional cases
If NPC wants to interact with the player he has to go to Area #2 and check if player is in Area #3. If player is not there, NPC have to wait until player enters Area #3
I know that I can affect the path NPC chooses by using navigation modifier volumes and changing navigation cost in some areas.
But, based on goals above, I also need at least the following
I need to get random point within specific area (for goals #1 and #3)
I need to check if some actor is in specific area (for goal #3)
And I guess I don't really need "navigation cost" feature, since if I could get random point in specific area, I would be able to control where NPC goes anyway
The questions are:
What actor should I use to mark some areas as "NPC can go here if they want to walk around", "NPC can go here if they want to interact with player", etc?
If volume is the best option, what volume should I use? My concerns about Navigation Modifier volume is that I don't really need to modify navigation process by blocking it completely or adjusting its cost.
I have used the NavMeshBoundsVolume to define the area that my AI character is allowed to be in.
Then I used blackboards and set points the AI could walk around too, adding variables enabling or disabling a point. In your case you could have a variable that is true when the player is in area #3.
I've included a picture of my Behavior Tree, so that you can get an idea of the how a flow might look. This is for an "enemy," but you could simply have the AI follow the character to a specific area instead of playing the attack animation and applying damage.
Here is a really good series on AI in Unreal Engine. It's UE4 but if you are familiar with the engine you shouldn't have a problem applying it to UE5.
I am using Unity's navmesh system to make an RTS game with tanks.
When the tanks get close to each other, the avoidance system kicks in and they try to get out of each other's way. However, they often bump into each other and end up pushing others out of the way. This shouldn't be possible with vehicles as heavy as tanks, and it looks unnatural.
Is there a way to have the navmesh agents try and avoid each other, but not bump into each other, and if they do, definitely not push each other around?
I have tried altering the obstacle avoidance priority, but there is still at least always one tank that pushes others out of the way.
I have also tried altering the rigidbody, for example making stationary tanks work with gravity and making them really heavy. I have also frozen all rigidbody constraints. However, other tanks are still able to push them out of the way with ease.
At the moment, when tanks stop moving I have made a navmesh obstacle appear under them, which helps with avoidance. However, this only works if they are stationary - moving tanks can still be pushed around by others.
Any ideas or suggestions for how to solve this would be greatly appreciated!
Though not an expert at either Unity or NavMeshAgents, I have also recently been struggling with a similar issue of agents unrealistically shoving each other around. In my case it's people lining up to scan boarding passes at an airport, but it looks no less ridiculous than tanks I assure you.
Having spent several hours scouring the internet and several more hours in trial and error, I regret to say that there is no quick or simple solution. Frankly put, Unity's inbuilt pathfinding AI system is both crude and twitchy. Remember how way back in 2006's "Company of Heroes" the tanks would back up rather than turn around if only going a short distance? Yeah, 15 years later Unity's NavMeshAgents still can't do that without extensive custom scripting...
A couple of thoughts though!
Thought #1: Before we get into possible suggestions, a different appraoch to this issue would be to have the environment or gameplay discourage tanks from bumping into each other to begin with. I mean, sure it may occasionally happen during the messy heat of a chaotic battle in the center of an urban space, but from my personal understanding of real-life tank warfare they almost never actually physically touch each other... Something has gone terribly wrong if your huge long-range artillery with all-terrain-tread-based mobility has been dented by another tank like some parking lot fender-bender. Come to think of it the bigger issue I see with this NavMeshAgents shoving around issue would be when infantry push the tank around. They would, in a real-life scenario, be vastly more likely to run right next to the treads, or lean out of cover behind the tank, or duck under the main turret barrel. So if your RTS game has both tanks and infantry, and all of them have the pathfinding dealt with via NavMesh and NavMeshAgents, you have several other reasons to be concerned.
Anyhows, my point is perhaps you could implement some sort of script that makes tanks on the same side keep formation? Try as best they can to maintain a minimum distance from allied tanks? Maybe have the script lower their forward speed to zero when too close to another one, or some other form of hard/soft check to keep allied tanks from even attempting to get within bumping distance of each other. As to enemy tanks, again only in a very cartoony situation would they ever ram into each other when both tanks are in active fighting condition. If one tank is a smoking heap of rubble or has been abandoned by its crew, then disabling the NavMeshAgent and plopping a NavMesh Obstacle in its place would work fine.
Actually have you ever played/seen the 2005 Nintendo game "Battalion Wars"? Now there is a game that I think can be fairly described as following a loose interpretation of tank warfare, let alone the laws of physics... And even in that silly game tanks very rarely collided with one another. Remember the 2003-ish game "Think Tanks"? A very fast-paced rough-and-tumble tank melee, and on the rare occasion a tank bumped into another one somebody got flipped over and everyone had a good chuckle.
If you are making an abstracted game or a light-hearted silly one, nobody is going to care if a tank or two is nudged a little bit. If it's a serious game or a historical simulation type RTS, why are the tanks bumping into each other at all?
I digress. My point is that this issue of tanks unrealistically pushing each other can be minimized by either gameplay strategy or behind-the-scenes code limiting how close tanks even get to other tanks. Then it doesn't matter if they hypothetically would push each other, because it will very rarely come up and when it does come up, it is likely to be in a very active and brief situation when the player is highly unlikely to notice or care.
Thought #2: But what do I know? So here's a few ideas to limit the bumping! I've seen a few forum threads and blog posts that discuss the idea of only using the NavMeshAgent component to determine the path, and using a separate script to make the object with the actual Animator or what-have-you endlessly "chase" the NavMeshAgent. This is usually brought up in the context of cars. But cars and tanks are not so different, in a fundamental movement way. "Chasing" an invisible NavMeshAgent might be a little clunky in tight spaces, but tanks are hardly nimble compared to the humanoids on foot the component was presumably designed for. Perhaps this might be a viable solution for you, depending on the number of tanks you expect to be active at any given time. The RigidBody physics and other collision stuff would be more predictable and easier to control, and the only thing you'd rely on the NavMeshAgent for would be "steering" a tank which moves using some other script.
Thought #3: Completely different idea would be partially decoupling the NavMeshAgent from the root position of the main GameObject. The official online Unity manual even mentions this here, where they give a few simple tricks to minimize foot sliding. Tanks don't have feet, but the entire tank sliding around is basically the same problem right? Perhaps you can knowingly allow the tanks to shove each other a bit, if visually speaking the tank does not actually move because you are resetting its transform location by script.
Thought #4: I found that the Priority setting of the NavMeshAgent component was pretty useless. It only made a practical difference when you were very sure the exact order you wanted agents to move, almost in a pre-scripted way. Not very helpful in a dynamic procedural RTS game. That said, would it be possible to implement some sort of script that changes the set Priority of individual tanks based on a few battlefield criteria? It wouldn't completely stop tanks from shoving each other around of course, but might dynamically limit it. For example, you could have two moving tanks which bump into each other automatically set the tank moving faster to the lower Priority. Or a tank which is larger than any nearby tanks, determined by some tag value perhaps, be set to a Priority lower than the other ones. This would help more than all the tanks having a static default Priority value assigned at the start, because the Priorities of tanks would change depending on which other tanks are physically nearby and relevant variables.
Damaged tanks would thus be less likely to push around fresh ones. Tanks going backwards would be less likely to push other tanks than ones going forwards. Tanks in the middle of a shallow river or whatever would not be able to push tanks sitting on firmer ground up on the bank. If you can implement a dynamic Priority setting in the NavMeshAgent component via script, it might help. Sensible gameplay is ultimately more important than visual realism anyways right?
Thought #5: I don't like telling people to solve their problems by using third-party plugins. Especially ones I don't personally use. That said you could also consider looking into the capabilities of Unity Asset Store items such as A* (Pronounced A-Star) or other plugins designed to either replace or at least improve the in-built Unity system. 100USD or so is expensive and pirating these plugins is unethical, so if you do pursue such a route I'd suggest contacting the people that make them directly and asking about your specific issue before taking that plunge. Again, I don't personally use them but it would be irresponsible of me to not mention them here.
I'll add more thoughts via editing this response if they come to me, but I hope I might have given you a few inklings of what you can do. And please, if you do figure out a solution that works please let us know!!! RTS game developers need all the help they can get and many other people have similar issues with Agents that are not tanks. Good luck.
I'd like to show congestion areas on a conveyor network by using the density map included into the Material Handling Library, but so far I haven't find a way to do so, as material agents movement cannot be tracked by the density map, but it only accepts transporters or pedestrians (both in free space movement mode).
So I thought I could create a "parallel" agent (for instance, a pedestrian) that could get attached to my material and move along with it. Then I could set the pedestrian visible property to "no" so that it does not show in the animation, or make it really small as an alternative approach.
The problem when doing the pickup/dropoff logic is that the pedestrian disappears from the scene when it gets picked up (although it's internally batched with the material) so the density map shows nothing.
Same thing happens if I try to seize/release a transporter, as they do not travel along the conveyor with the material agent.
Any idea on how to get this?
Thanks a lot in advance!
You won't be able to drag pedestrians, they actively move via PedMoveTo blocks. This is a creative idea but it will not work.
You will have to code your own heatmap using dynamically colored rectangles that you animate on top of conveyors. Doable, but might be more work than is really required for your purpose ;)
I'd like to use compression forces to keep detached objects suspended in the air. Here's a photo of what I'm trying to accomplish:
Ideally, they would stay in the position illustrated above until acted upon by another force.
However, the boxes become all wonky and seemingly ignore the friction between each other.
If I put them closer together, they sort of explode in every direction, and if I put them exactly touching or further apart, they simply fall straight down.
Is this possible in Unity3d? or is this beyond the scope if the standard physics engine.
I haven't seen this implemented in any physics engine without intervention through code. Basically you'll have to make the objects immovable until some event triggers them to be movable.
There's no such thing as "compression force" in physics engines. The problem here is that even the slightest compression means two bodies are intersecting (overlapping) and any rigid-body physics engine will try to resolve that by moving the bodies out of the way.
A soft-body engine would be able to cope with that, but they're special use cases and not commonly used. For instance BeamNG.drive uses a soft-body physics engine to model the deformation of cars, and that's not ideal either as you'll sometimes notice that even strong metal connections have a slight wobble to them.
You can only model this behavior in a rigid-body physics engine if you were to attach the bodies through joints to keep them suspended in air, but even so they would either be allowed to intersect (might not look good unless intersection is minimal) or they'll start moving, possibly going wild. Or like I said at the beginning, have the bodies suspended at their position - put them to sleep, make sure once one of them wakes up they all wake up. Something like that.
I've been trying to find a way to do this but I'm not sure how. I've gone through A* pathfinding but could find anything on this. What I'm looking for is pathfinding for something kind of like a super smash bros level with different platforms. Can anyone point me in the right direction?
Think of the path as being made of game states instead of locations; you are looking for a gamestate in which your character is alive and on the platform. The branches of your search would be button presses.
Imagine it this way; the computer pretends it clicked a button and estimates how the game would be x milliseconds after that. Then the computer looks at the buttons it may click and chooses the best alternate reality. It then clicks that button. Lo and behold, the game turns out exactly like the computer imagined.
You will need to limit the rate at which the computer may imagine pressing new buttons (if you don't want to lose performance). In order to do this, you may limit it to only pressing a button every 10 ms in its imagination. That may lead it to stand still when it had the option to move. You may also limit the button presses by game state; it can't click 'jump' if it already has jumped.
In essence, use an A* prediction algorithm instead of an A* pathfinding algorithm. Also consider minimax, which is already a prediction algorithm.