I am using Jumper for path-finding in my game. The game features a random-level generator that produces tile-based obstacles. I am having a very strange issue with the discovered paths. see screenshot:
https://imgur.com/jQvdUZZ
I thought it might be an offset issue, but there's nothing out of the ordinary in terms of tile position or character position (that I can see).
I have attached a .love file. After loading it, use the spacebar to generate a new level. the 'thug' is the red character and does not move. This means that he may end up inside of obstacles sometimes. Which, at this point, doesn't matter much. If the thug cannot find a path to the player, the framerate counter turns red.
Also, the level boundary is 1-14 (see the nx,ny global values).
Help?
Very strange pathfinding issue (Jumper)
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
Very strange pathfinding issue (Jumper)
- Attachments
-
- QuickShotPathingIssue.love
- (70.85 KiB) Downloaded 95 times
- Roland_Yonaba
- Inner party member
- Posts: 1563
- Joined: Tue Jun 21, 2011 6:08 pm
- Location: Ouagadougou (Burkina Faso)
- Contact:
Re: Very strange pathfinding issue (Jumper)
Hi ac3raven,
I just took a peek at the code. I might be wrong, but I think it is related with the way you are handling coordinates for display. Yeah, offsets.
In a tile-based environment, when I create a map and I want to display tiles, in case the 2D table I use to represent tile values is a regular Lua array (indices starting at 1), then I shift everything by -1 before drawing.
In that case, the first square is drawn at coordinates ((x-1)*tileWidth, (y-1)*tileHeight) to (tileWidth, tileHeight) for x,y = 1,1, which corresponds to coordinates (0,0) to (tileWidth, tileHeight), which is what I really want to be displayed.
In that respect, I think you should go through the whole code and update everything related to tile/coordinates calculation.
A quick note, I noticed some typos in coordinates calculation...You seem to be confusing the width and height. There is no problem actually, since they are equal (= 32), but for clarity, you should fix that.
Also, when you want to draw a path, it is much more pleasant to the eyes to draw it using tile centers. Just substract the half of a tileWidth and a half of a tileHeight to fix this:
Side note, this method is quite wasteful since it creates a table every single frame, as long as thugpath is not nil. Better,you can index in thugpath as in any regular table. Note to self, i'll provide some methods to the actual API to do that more conveniently for the next relase.
Hope this helps.
I just took a peek at the code. I might be wrong, but I think it is related with the way you are handling coordinates for display. Yeah, offsets.
In a tile-based environment, when I create a map and I want to display tiles, in case the 2D table I use to represent tile values is a regular Lua array (indices starting at 1), then I shift everything by -1 before drawing.
Code: Select all
local map = {
{0,0,0},
{0,0,0},
{0,0,0}
}
local function draw(map, tileWidth, tileHeight)
for y = 1, 3 do
for x = 1,3 do
love.graphics.rectangle('fill', (y-1)*tileHeight, (x-1)*tileWidth, tileWidth, tileHeight)
end
end
end
In that respect, I think you should go through the whole code and update everything related to tile/coordinates calculation.
A quick note, I noticed some typos in coordinates calculation...You seem to be confusing the width and height. There is no problem actually, since they are equal (= 32), but for clarity, you should fix that.
Also, when you want to draw a path, it is much more pleasant to the eyes to draw it using tile centers. Just substract the half of a tileWidth and a half of a tileHeight to fix this:
Code: Select all
function Thug:drawPath(path, tileWidth, tileHeight, enemy)
if thugpath then
local t = {}
for node in thugpath:nodes() do
table.insert(t, (node.x)*32-32/2)
table.insert(t, (node.y)*32-32/2)
end
love.graphics.line(t)
end
end
Code: Select all
function Thug:drawPath(path, tileWidth, tileHeight, enemy)
if thugpath then
for i = 2, #thughpath do
love.graphics.line(
thughpath[i].x*tileWidth-tileWidth/2, thughpath[i].y*tileHeight-tileHeight/2,
thughpath[i-1].x*tileWidth-tileWidth/2, thughpath[i-1].y*tileHeight-tileHeight/2
)
end
end
end
Re: Very strange pathfinding issue (Jumper)
I subtract 1 from y and x in the two functions where it's appropriate (Obstacle:draw() and Obstacle:collision_load()), and I am still getting similar pathing issues. See screenshot.
https://imgur.com/d1YMAim
This is the code that generates a map:
I got rid of the randomness to see if I could change the behavior of the pathing, but it doesn't seem to affect anything. I use HardOn Collider to generate the collision shapes. I wonder if it's draw function is messing things up? I looked at some of the code in HardOn Collider, but I don't understand it well enough to see if it's at the root of the problem.
EDIT: The drawing in HC wouldn't have anything to do with it, but maybe the addRectangle function would?
EDIT 2: I've attached an updated .love featuring your suggested edits, Roland.
EDIT 3: Look at this screenshot: http://imgur.com/R77K9aP The dotted line was added by me. I think the problem might be that it's rotated and flipped somehow, but I'm not sure how to fix it. I tried simply flipping the [y][x] to [x][y] where it related to the map/collision/pathing, but that didn't change anything.
EDIT 4: Fixed it. I didn't need to reverse [y][x]. I was using the y value where x was suppose to be and the x value for y in the draw functions for the obstacles and their collider shapes. It's working now.
https://imgur.com/d1YMAim
This is the code that generates a map:
Code: Select all
nx,ny = 14,14
local scale = 1/love.math.random(4,6)
local threshold = 0.6
local seed = love.math.random(1,9999)
Map = {}
for y=1,ny do
Map[y] = {}
for x=1,nx do
local simplex_value = love.math.noise(y*scale,x*scale,seed)
if simplex_value > threshold then
Map[y][x] = 1
else
Map[y][x] = 0
end
end
end
EDIT: The drawing in HC wouldn't have anything to do with it, but maybe the addRectangle function would?
EDIT 2: I've attached an updated .love featuring your suggested edits, Roland.
EDIT 3: Look at this screenshot: http://imgur.com/R77K9aP The dotted line was added by me. I think the problem might be that it's rotated and flipped somehow, but I'm not sure how to fix it. I tried simply flipping the [y][x] to [x][y] where it related to the map/collision/pathing, but that didn't change anything.
EDIT 4: Fixed it. I didn't need to reverse [y][x]. I was using the y value where x was suppose to be and the x value for y in the draw functions for the obstacles and their collider shapes. It's working now.
- Attachments
-
- QuickShotPathingIssue2.love
- (70.83 KiB) Downloaded 83 times
- Roland_Yonaba
- Inner party member
- Posts: 1563
- Joined: Tue Jun 21, 2011 6:08 pm
- Location: Ouagadougou (Burkina Faso)
- Contact:
Who is online
Users browsing this forum: Google [Bot] and 62 guests