Very strange pathfinding issue (Jumper)

[ac3raven]

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?

[Roland_Yonaba]

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.

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 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:

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

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.

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

Hope this helps.

[ac3raven]

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:

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

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.

[Roland_Yonaba]

Great!