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.
Related
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.
so I've been trying to see if I can make use of Wheel Colliders for the past several months now. As much as I've managed to figure out more and more things about how to set them up properly, there's some things I've been noticing that seem impossible to avoid:
Even if your friction sideways stiffness is lower, there's a chance that your car will continue to "spin" or "rotate" in the direction you were steering if you JUST hold down your input long enough to get the car beyond just rotating. I've noticed this will happen, whether for example the "SteerHelper" or "TractionControl" functions are doing their work or not. This will put a dent in ensuring smooth turn movement. Now, I don't know if maybe this is just due to realistic car physics (I mean, I can picture the car skidding in scenarios where they lost grip of the road for sure), but it just feels kinda glitchy. Sometimes, even when I'm not turning, the car will start to turn a little to the left or right and then gradually seem to "lean" that way in terms of applied torque to the rigidbody. I've seen many suggestions for trying to stop the rigidbody from doing this. Here is one way I'm trying to work against this:
rb.AddTorque(-rb.angularVelocity * 2);
However, it seems that the car will still "spin" more than intended. What would be ideal is to be able to MAYBE allow the car to turn a little extra after the left or right steer buttons were released (maybe more or less depending on the vehicle), and no more than that to ensure there is maximum control to give the engaged and maybe arcadey game play I've been going for for a long while.
It's been difficult to adapt an ideal friction curve value that would give the most ideal feel of a drift turn, especially a more arcadey one. I'm not trying to go for wide turns that slow you down, I'm trying to go for tight (yet controllable) turns that allow you to preserve most of your speed. I find that especially at higher values of stiffness, as I know many people have observed in other posts, that again, the car will turn back an extremely high amount sometimes (you drift left enough, a force is turning your vehicle way to the right). It's sad, because I've wanted to be able to say I've "mastered this beast" and used it for my purposes, but I don't know if that's really a good practical expectation for anyone. I even worked my own alternate friction curve values that would be used in the controller:
But I guess as some people say, you can't polish something that's broken? Moving to the third point...
I've read so many posts that show how to adjust a vehicle's center of mass, or to add more colliders in different spots to correct it, using scripting to add an offset to the center of mass, etc. So many tips that say, "lower the center of mass, you'll find it" and I give that a try. When the center of mass is too low, my car can get pretty shaky on the terrain (not that it hasn't in the past, but it's often been things I could correct, like the weird initialization of the attachedRigidBody of the wheel colliders themselves in the beginning, etc). High enough, and of course, (even when it's lower sometimes???) the car will just start spinning in the air on either multiple axes or specifically the forward z, when you drive off a ledge or bump into something with a high enough speed. It just seems inevitable.
I've been trying to give my benefits of a doubt. I like to think there's a correct way to use this thing, and that I'm just not familiar enough with Unity3D physics concepts. However, it just seems more and more that I'm investing too much time in a broken component - or, maybe I just never got the best grip of physics.
I was about ready to try just convex mesh colliders around my tires, and just abandon the idea of gripping physics altogether, but I'd love to hear suggestions to either address anything I've mentioned above, or just a more ideal package to move onto. I've glanced at packages like Vehicle Physics Pro, but I do want to be sure I'm getting something that makes sense.
Full disclosure: I'm in the middle of trying to make a game that feels incredibly similar to F-Zero, but with wheels.
Thanks in advance for any thoughts or suggestions you can provide.
(Maybe not an answer per se, but hopefully helpful.)
Note Unity also suggests to possibly give the car a constant downward force via script. It might be telling that such workarounds are officially given, one would think proper physics would, well, properly work without them.
There's some assets you might want to give a try generally:
One is the Unity Asset Store asset called Arcade Car Physics, and it's free. I've tried it and it works (but not sure if it works for your needs). It's using Unity's native Wheel Collider plus extra scripts.
Another is the Arcade Car Physics github project. It has nice plane stabilization and more, and works well. It's not using the native Wheel Collider.
Then there's this asset called Vehicle Physics. Instead of native Wheel Colliders, they've create a fully custom wheel system so that it would be more physically workable. The asset is not free, but they offer a free demo executable where you can drive around different vehicles, and that works quite well. (I haven't yet bought this asset myself.) As a downside, some reviews mention there's some complexity in setting this up (and I suppose future support for this custom Wheel Collider hinges on the company continuing to exist).
Good luck!
I'm working on a VR project in Unreal and I'd like my player hands to form to certain objects whenever the user grabs them. (I.e. the way our hands work) Unfortunately, I haven't really found any examples online of others doing this.
For example, I'd like when the user picks up say a hand held tool like a hammer that the hand would wrap around the handle. When the user grabs a basketball the hand shouldn't be closed but, expanded like a you would if you were to palm a basketball in real life.
I haven't done a lot of testing with this but, I'm pretty sure since the hands are based off of a Animation Blueprint that they simply ignore collisions and follow the animation.
I guess the simplest solution would probably be based off of collision where the hand plays an animation and as the fingers of the hand wrap around the object they stop at that position where they collide with the object in question. If it is even possible that is.
I am working, or about to be working, on a project where I would like to move a monitor along a railed track, left to right and vice versa, and have the camera in Unity update its movement left or right to follow the track movement. I am attempting to do something like this Video Example but on a smaller scale, and have, at certain points along the track, triggers that will spawn different animations based on where on the track the monitor is, sort of like a timeline.
I guess my question is, does anyone have any thoughts or ideas on how this is accomplished? My initial thought is using a accelerometer to get movement data and use that with some scripting to control the camera, but I am not sure how big a factor the potential error may be with this approach. Another idea would be to use some sort of Laser Range Finder to get a constant distance strapped to the back of the monitor or the track, right now I am really just brainstorming.
On the unity side of things I will be fine, I am just wondering if there are other ways, or if people may have other ideas on how this is done, before I jump into spending money on trial and error modes. Thanks for any insight that anyone may be able to offer in advanced!
There's a puzzle game called Zen Puzzle Garden, and I just wrote a program that solves the puzzles in the game. Right now, it does a brute force search for a solution, then spits out the necessary moves to solve the puzzle: up, down, left, and right.
But what I want is to run the game on my computer, and feed those moves from my program into the game, so I watch the game being solved automatically.
What is the easiest way to do this?
I should mention probably that my code is written in C.
System.Windows.Forms.SendKeys.SendWait("String you want");
Or
System.Windows.Forms.SendKeys.SendWait(Keys.Up.ToString());
Note that if you enter a string it will send the whole string. So you should probably make a switch/case to see what Key you want to compute.