Now this might be a piece of cake to most of you, but it took me several attempts to create a satisfying result regarding this.Since I didn't find much regarding Collision Avoidance on the internet, I thought I post my function here. For two reasons!

Reason number 1, I have a feeling I am overcomplicating this and it could be done with much fewer lines of code. I know .. I shouldn'teven worry about that because my function does work perfectly fine (it seems). But yeah, I'm still very curious. I commented the codefor easier readability, please take a look!

Reason number 2, if my approach to Collision Avoidance does get your seal of approval I thought this might help others that struggle with it, since I didn't find much resources on that topic out there.

Thank you!

EDIT: The code is intented for a topdown 2D game in which you can move in all four directions (up, down, left, right).

Check if an object intersects before sorting. Why sort a hundred objects when all you need is usually one or zero?Your distance equation can be simplified. Do not bother with abs because a positive or negative number square is always positive. Do not bother with square root because it doesn't change the relative order of values. Why do you use ints? Can't a float work as well?Why sort at all? Am I missing something?If you want to simplify offset distances, you can use center coordinates and half-widths and half-heights.

Your distance equation can be simplified. Do not bother with abs because a positive or negative number square is always positive. Do not bother with square root because it doesn't change the relative order of values.

But why sort at all?You could use a SortedFloatList, although I am not sure why the order would be essential if the fractional part of a number can be discarded.I just saw body.x + body.width, so I thought you were working with corners.

Good question. Because I'm running into an issue if I dont! I guess there's again, a much simpler way to solve that, but that's my solution so far.

Take a look at followig example:

If I dont adjust the dx, dy values with the nearest obstacles first the Entity will get stuck at corners.In the example the Entity is moving down left (hence dx and dy have the same negative value. Now if it slidesalong the blue Obstacle it comes to the point (illustrated in the picture) where it's right at the edge of the red obstacle.If I dont adjust dy with the nearsest obstacle first (the blue one) it could pick the red obstacle first. And if that happensthe code would set both dx and dy to 0, because the Entity intersects right at the edge and hence the Entity would get stuck.

By checking the nearest Obstacle first I prevent that because the blue Obstacle would have already set dy to 0 and the Entitywould have never intersected with the red Entity.

That won't work if your obstacles are different sizes. The center of a small object may be father away than the corner or edge of a really big object.

You should to this: Don't update your coordinates until the end. Find all objects which may collide in one turn. (0 <= t <= 1) Check each potential collision and save the one with the smallest t value.

I'm sorry I'm afraid I still dont understand, but thanks for helping me.

Maybe a picture of what I have so far will help.EDIT: The dark-red square is the player and is moved around in realtime with WASD.

It's realtime and checks for collisions every frame so I dont understand how using 'time' will help me. If the Player interesects withtwo obstacles at the same time, how will that help me to decide which obstacle to adjust the Player's values to?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org