Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path. #36

Closed
juliolitwin opened this issue May 30, 2020 · 3 comments
Closed

Path. #36

juliolitwin opened this issue May 30, 2020 · 3 comments

Comments

@juliolitwin
Copy link

Hi,

Is there any possibility that I could find missing paths by using some condition?

For example, I want to use the grid for an online game, as I am working with udp, so in this case there may be packet loss and I am also using interpolations. The grid can have walls and so on, so sometimes the interpolation can end up taking a path in which it is blocked, so my idea is to try to "recover" by calculating some points from packet losses. As each movement works with sequences or timestamp, then the idea of filling in, would be being able to limit the searches of the path, to find such a path, it needs to go through amount of time or sequence. He does not need to find the slowest or the fastest, but the necessary condition.

Thanks,
Regards.

@roy-t
Copy link
Owner

roy-t commented May 30, 2020

Hey,

I'm sorry I don't fully understand the question. Is it correct that your problem is that clients are missing changes to the path finding graph because you sync it over UDP?

Most games use two streams of data. UDP for fast positional data which is overwritten by every new packet (things like, where is the player). And a TCP stream for important game data (things like state changes). In this case of adding or removing connection between two nodes on your path finding graph I would send those over the reliable (TCP) stream. As the changes aren't very often but it is very important that every client knows about them.

Of course I have now made a lot of assumptions about your game. But I hope this helps a bit. Feel free to expand on your problem so I can give a better answer :).

@juliolitwin
Copy link
Author

Yo,

Sorry, maybe I didn't explain it so well.

Image: https://i.imgur.com/rtgvWxh.png

What I meant, is about a new implementation to FindPath (), adding some new "conditions" to limit the search for paths. I tried to explain about UDP, since UDP may have packet losses, in those losses, if I have it viable, I would like to be able to "recover" something close to the position of the lost packets. With that, FindPath could have the option of limiting to find from start to finish, with a sequence of a maximum of 6 steps and from a certain distance in each path.

Cheers.

@roy-t
Copy link
Owner

roy-t commented Jun 3, 2020

Sorry but, I'm really having trouble with understanding what problem you're trying to solve. FindPath only gives you the path that a unit should take. The server then moves that unit along the path.

Say the server executes FindPath() which results in a path with the following positions: {a, b, c, d, e} for unitA to get from a to e.

Then the server sends the following packets to the client:

1: unitA is now at a
2: unitA is now at b
3: unitA is now at c
4: unitA is now at d
5: unitA is now at e

Due to packet loss the client might receive:

1: unitA is now at a
2: unitA is now at b
3: LOST
4: unitA is now at d
5: unitA is now at e

Is this the problem you are describing?

In this case what you could do (but is very much outside of the scope of this path finding library). Is to have the client store the current position and the velocity vector of the unit. Something like

After packet 1: position of unitA is a, velocity = 0
After packet 2: position of unitA is b, velocity = (b -a)
Packet 3 is lost, but let's assume the position of unitA is its last know position plus its velocity vector so the position of unitA is b + (b - a).
After packet4: position of unitA is d 
After packet5: position of unitA is e

So the client predicts where the unit will be if the packet is lost, or late. Of course if the unit was about to take a turn the prediction is wrong, you can add some smoothing between the predicted position and the actual position to deal with that.

Does this help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants