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

Pathfinding entities never take diagonal path #16

Open
phrohdoh opened this issue Feb 5, 2018 · 2 comments
Open

Pathfinding entities never take diagonal path #16

phrohdoh opened this issue Feb 5, 2018 · 2 comments

Comments

@phrohdoh
Copy link
Member

phrohdoh commented Feb 5, 2018

"Diagonal" in this context means from the perspective of the viewer looking at the 2d window (not in relation to the grid coordinate system).

Determining cell neighbors does include diagonal pieces.

A test that includes only diagonal possibilities passes:

    #[test]
    fn test_find_tile_path_diagonal_only() {
        let width = 3;
        let map = vec![
            1, 0, 0,
            0, 1, 0,
            0, 0, 1,
        ];

        let (terrain, path_finder) = make_terrain_and_path_finder(map, width);
        let occupied_tiles = OccupiedTiles::new();

        let test = &mut |from, to, exp| {
            let path = path_finder.find_tile_path(&terrain,
                                                  &occupied_tiles,
                                                  from,
                                                  to,
                                                  UnitTerrainRestrictionId::Flying);
            assert_eq!(exp, path);
        };

        test((0, 0), (2, 2), vec![(0, 0), (1, 1), (2, 2)]);
    }

@angered-ghandi do you have any insight as to why this may be the case?

@phrohdoh
Copy link
Member Author

phrohdoh commented Feb 5, 2018

Thinking on this in the context of AoE's diamond (rotated) maps the units are only taking diagonal routes.

This test fails:

    #[test]
    fn test_find_tile_path_nondiagonal_only() {
        let width = 3;
        let map = vec![
            0, 1, 0,
            0, 1, 0,
            0, 1, 0,
        ];

        let (terrain, path_finder) = make_terrain_and_path_finder(map, width);
        let occupied_tiles = OccupiedTiles::new();

        let test = &mut |from, to, exp| {
            let path = path_finder.find_tile_path(&terrain,
                                                  &occupied_tiles,
                                                  from,
                                                  to,
                                                  UnitTerrainRestrictionId::Flying);
            assert_eq!(exp, path);
        };

        test((1, 0), (1, 2), vec![(1, 0), (1, 1), (1, 2)]);
    }

/*
  left: `[(1, 0), (1, 1), (1, 2)]`,
 right: `[(1, 0), (1, 1)]`',
*/

@ghallak
Copy link
Contributor

ghallak commented Mar 19, 2018

@phrohdoh, if 1 means passable and 0 means impassible, the second test is failing because you're starting from an impassible tile (1, 0).

The test passed when I changed the last line from:

test((1, 0), (1, 2), vec![(1, 0), (1, 1), (1, 2)]);

to:

test((0, 1), (2, 1), vec![(0, 1), (1, 1), (2, 1)]);

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

No branches or pull requests

2 participants