Working on a recent project I wondered how to find a good/perfect path to a target that is moving with a steady speed. I tried standart A* pathfinding but it failed, since the heuristic will be wrong the more the object moves and I just can´t find a way to make that work for me. Maybe you guys got another algorith that should work with just fine or some calculation tuning with A* that would work...
Thanks for your afford :)
A* should in general work, but then of course you need to recalculate every time the target moves. For 99% of cases, this is actually ok. For example, in video games you can get away with only recalculating the best path once every second or so, so it's generally not a huge performance hit.
However, if you really need something more powerful, check out Generalized Adaptive A*, an algorithm specifically designed to handle moving targets. And if you really want to be on the bleeding-edge, there are multiple adaptations of GAA* that are faster in certain cases - see this post (under "moving target points") for more details.
Using A* with a moving target is ok, but you must recalculate the whole path again. I don't think A* likes just having it's destination / goal changed.
Your A* needs to be very well optimised to run in real time and recalculate the new path every time the target moves.
Remember to play with your H to get a balance between working out the shortest path and the quickest to calculate. All depends on your map and obstructions really.
However A* may not be the best path finder for your application, but I'd need to see your map and more info..
Related
I have some questions.
The first question is which equipment should be used to recognize QR Code.
I'm thinking of two things.
The first is the QR code Scanner used in the industrial field.
The second is the camera module. (opencv will be used)
However, the situation to consider is that it should be recognized at the speed of 50cm/s.
What do you think about?
And if I use a camera, is there a library that you can recommend to recognize QR Code? (C/C++ only)
Always start with the simplest solution and then go more complex if needed. If you're using ROS/OpenCV, OpenCV has a QR Code scanner, ex. Other options include ZBar, quirc, and more, found by searching github or the internet.
As for a camera, if you don't need the intrinsic matrix, then you only need to decide on the resolution: more resolution takes (non-linearly) longer to compute, but less resolution prohibits seeing the objects well.
Your comment about "recognize at 50cm/s" doesn't make much sense. I assume you mean that you want to be able to decode a QR code that's up-to 50 cm away, and do it in less than a second (to have time to stop). First you'll have to check if the algorithm, running on your hardware, can detect the QR code at different desired distances, and how that changes with scaling the image up/down in OpenCV. Then you'll have to time how long it takes to detect/decode it at those distances/resolutions/scales. If it fails to be good enough, you can try another algorithm, try different compilation settings, perhaps give it it's own thread, change the scaling on the image, accept the limitations, or change the hardware.
I've been looking for a robust method of pathfinding for a platformer based game I'm developing and A* looks like it's the best method available. I noticed there is a demo for the AStar implementation in Godot. However, it is written for a grid/tile based game and I'm having trouble adapting that to a platformer where the Y axis is limited by gravity.
I found a really good answer that describes how A* can be applied to platformers in Unity. My question is... Is it possible to use AStar in Godot to achieve the same thing described in the above answer? Is it possible this could be done better without using the built in AStar framework? What is a really simple example of how it would work (with or without AStar) in GDscript?
Though I have already posted a 100 point bounty (and it has expired), I would still be willing to post another 100 point bounty and award it, pending an answer to this question.
you could repurpose the Navigation2D node for platformer purposes. The picture below shows an example usage. The Navigation2D node makes it possible to navigate the shortest path between two point that lie within the combined navigation polygon (this is the union of all NavigationPolygonInstances).
You can use the get_simple_path method to get a vector2 array that describes the points your agent/character should try to reach (or get close to, by using some predefined margin) in sequence. Place each point in a queue, and move the character towards the different points by moving it horizontally. Whenever your agent's next point in the queue is too high up to reach, then you can make the agent jump.
I hope this makes sense!
The grey/dark-blue rectangles are platforms with collision whereas the green shapes are NavigationPolygonInstance nodes
This approach is by no means perfect. If you were to implement slopes into your game then the agent may jump up the slope instead of ascending it normally. It is also pretty tedious to create all the shapes needed.
A more robust solution would be to have a custom graph system that you could place in the scene and position its vertices. This opens up the possibility to make one-way paths and have certain edges/connections between vertices marked as "jumpable" only. This is a lot more work though if you can not find any such solution online.
In this example (please see picture), the Manhattan heuristic delays the path because of the unwalkable block west of the destination block.
My question is how can I fix this? Do I need to keep checking the blocks on the open list (the gray blocks) even after I found the destination? I might as well use dijkstra if I have to do that. Do I have to live with an imperfection like this if I go with a-star or is there a solution?
I have done my research on it and implemented my own algorithm that works exactly as the tutorials / articles on the web have explained, but I keep running into specific instances like this where a* fails to find the shortest path.
Your heuristic needs to be admissible but is not. Use Diagonal or Euclidean distance instead.
I have an iOS app that uploads coordinates to a server. These coordinates can then be viewed in a map, through Google Maps. This is shown as a simple polyline. However, due to the GPS not being very precise, the polyline is often off-road.
I tried using Google's direction service, but it has a limit on how many requests you can send (and there can be a few thousand points on the polyline).
I have no idea how I can solve this problem. Could anybody help me?
I suspect the only way do do this is with manual intervention. The only way I can think of doing it programmatically would involve lots of queries to the directions service (to get "snap to road" functionality), and that probably would still need someone to check that it got it right (or at least need to include some code to look for extra loops to turn around or detours on to side roads that don't make sense).
Whereas if someone gets directions from start to end then drags them to match the track it would be pretty simple to get a version of the track that follows the roads.
The paper discussed in this thread might give you some ideas
I'm trying to create a game similar to this (Note:When you click 'play', there are SFX in the game which you can't seem to turn off, so you may want to check volume). In particular, I'm interested in knowing how the 'infinite' landscape is generated. Are there any tutorials/articles describing this? I came across procedural generation, but I'm not quite sure what topics I should be looking for (or if it's even procedural generation).
(I'm using C#, but I don't mind the language as I assume the theory behind it remains the same)
That one seems like it would be pretty easy to duplicate -- I would imagine an algorithm that calculates the next "step" of the landscape (the part that is off the screen). It would need to know the prior height (and maybe even the previous slope) in order to then (randomly) increment or decrement the step. You could then tweak the algorithm to be more fluid (gently sloping), or extreme (whipsawing back and forth) as time passes/levels are completed.
Before I clicked the link though, I thought you might have been talking about voxel landscapes -- which I haven't thought about for over a dozen years, but amazed me when I first saw them. I did some googling, and thought you might be interested in this:
http://www.gamedev.net/reference/articles/article655.asp
(Not sure if the Mars demo still exists, or if anyone has a DOS machine to play it on, but this is a good example that shows what it used to look like: http://www.codermind.com/articles/Voxel-terrain-engine-building-the-terrain.html )