I know this has been asked before, but it hasn't quite answered my question.

So, I am trying to find out how to get path finding working with AI on my game. I honestly just started programming this game and after a few weeks came across this problem.

The game itself is not a tiled based game, though it looks like one and the "walls" (or collide-able objects) are placed in a tiled way. (at this point) I did consider turning it into a tile based game, but the problem comes in when you make a map in the in-built level creator. It allows the walls to be placed anywhere at all. not on tiles. it also allows the square walls to be rotated. Walls can also be destroyed.

So, here is an example of what one user made map might look like. (this one is without rotation and every wall is locked to the tiles for simplicity right now)

How can my enemy (Green square) get to the player? (yellow square) while avoiding the walls (red areas)

Now, every object in the game has a set of properties. so far the one that is the most useful for this is the objects bounds (so a rectangle of their: x, y, width and height) Hopefully I can use this to calculate their path around walls. In the game there will be different types of enemies, in different sizes, so one path might not work with all.

I do admit I will probably need to use some form of the A* method. but in that case i would have to generate "nodes" in places where it would be needed. I am not sure where to start with that.

Thank you for the help in advance. If i need to add more info, please ask and will be happy to reply with it.

It doesn't need to be too advanced. In-fact its probably best not to since there could be a lot on the map at once. I have never done pathfinding at all, so i have no idea where to start. that's my problem right now.

Then loop through all the objects in your Level that represents a wall of some kind (that prevents movement through it). For each of these objects, set the gird values that they touch (based on their position, size and rotation) to blocked.

Ughh. I did the search I suggested and wasted a bunch of time looking at stuff developed since the last time I looked. Jump point search looks like it might be interesting. Now...I don't need any pathfinding...I don't need any pathfinding....

So I had a bit of time and implemented A* into the game as well as what jonjava said about converting it into a grid.

Here is my result:

No, it works... mostly. its not that optimized, but I still have lots of work for that and I am getting there.

my problems that I have encountered are:

1. They do not handle corners very well.

If the object that needs the path-finding is bigger then a tile, it might actually get stuck on a wall. So far, I can get around that with rotated collision detection. but this would be temporary as I will have bigger objects that need pathfinding later. So, I am not sure what to do in that sense. I will have more of a look later, I think someone was asking about the same issue on this forum.

2. their paths are wonky

As you can see in the image, the blue square down the bottom left of the image is actually going to go up before it goes down. This is something that popped up and I'm not sure whats wrong. It will most likely be due to some bad math on my part, but still annoying anyway.

3. The objects on the grid

Because of the way that the objects are being converted on the grid, you can see that both the (badly drawn) mines and the (badly drawn) boxes do not appear as blocked correctly. now again, this is probably due to some bad math on my part. but, lets get down to the root of this problem:

My tile's size is 16x16. so, if an object, much like those boxes, were not constrained to that relative size, it would create problems. those boxes are actually 30x30 pixels, close but not the same as 2x2 tiles. You might be able to see that later I could have a quite a lot of objects that are not contained by the tile's relative size. this might create wonky pathfinding and places where the pathfinding algorithm cant see a path, but to the user there clearly is one (between two objects).

So, those are my problems that have arisen so far.

I will have a look at the suggestions and resources that you all sent me and see if i can improve it a lot more (I most likely can)

Also, just a side note, the map sizes themselves are multiplies of 50, from 100 all the way up to 500 (e.g. 100, 150, 200, 250...). so, i'm guessing this could get quite taxing when a lot of objects are on screen at once.

Thanks again for the help p.s. I have been programming so much lately that it was so hard not to put a semicolon on the end of each line...

Ok, i fixed my problem with number 2. It was a very silly problem, just me overlooking data values.

It was some a conversion problem. they were using ints instead of floats for the pathing calculation. While I would rather ints (whole numbers are fun ) it was actually cutting off the decimal that I got from my calculations.

My calculations look very much like what Gibbo had. so, imagine ints where the floats are.

Hint for future people looking into A* pathing: Don't use ints unless your calculations result in whole numbers.

Hi, FewCode, are you still working on this? I have a working solution for almost exactly this situation.

I don't use tiles. I use nodes which are generally located around the corners of the walls. I found this to work nicely and avoid the issue your image shows with the odd paths.

I assume by now you are familiar with implementing the A* algorithm, given that image and the content of your last posts.

Basically, in my system, the world has positive space (can be traveled through, like your gray areas) and negative space (can not be traveled through, like your walls).The nodes are generated as follows:

For each positive space, generate nodes near the corners, and on the inside of the positive space.

For each negative space, generate nodes near the corners, and on the outside of the negative space.

If a node ends up being too close to any negative space (or in it), ignore it during the pathfinding process, or delete it. (the closeness is an issue if you don't allow your characters to intersect negative spaces at all)

Generate a beginning node for the character's current position, and a destination node for the destination.

I use rectangles for negative and positive spaces, but I think as long as the spaces are convex polygons (such as a rectangle), the system stays reasonably simple.

On a side note, my characters are strictly not permitted to intersect any negative space, which brings up an issue of how far away nodes should be from the corners (vertices) of positive and negative spaces. I have a policy in place that addresses this, but this may be irrelevant for you, so I'll refrain from describing it in this post.

Let me know if you have any questions or interest in knowing more about the solution I use. By the way, I am curious if you allow your characters to rotate and translate freely, given your system is not tile-based.

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