Hands-on Rust: can_place logic is "inside out"

Community PragProg Customers
,
2

I’ll do a big round of testing on can_place. Looking at it, I think you may be right - but I’ll have to test to be sure.

You really shouldn’t be able to step into darkness; the can_enter_tile function includes bounds checking to prevent you from leaving the map, and the current tile should always be lit. I’ll test a bit more, but I haven’t run into that one yet.

Inaccessible floor tiles can happen with these algorithms. I wonder if I can squeeze a solution in for that (if not, I’ll post it as an article on my website and include a link to it in the book). The easy solution is to use the same logic from find_most_distant that ensures a reachable tile is picked for the exit - by traversing a Dijkstra map and only allowing reachable tiles to be included. You can easily include a step to transform all unreachable tiles into walls.

I’ll add some test code for monsters on top of one another. It tries to avoid that!

Unit testing is a topic I’d love to have pages for; I hope to write a bit more on that at some point. Rust makes unit tests really easy. You can put tests in your regular code files and call cargo test to run all of your program’s unit tests. For example (from the geometry code in bracket-lib):

#[cfg(test)]
mod tests {
    use super::Point3;

    #[test]
    fn new_point3() {
        let pt = Point3::new(1, 2, 3);
        assert_eq!(pt.x, 1);
        assert_eq!(pt.y, 2);
        assert_eq!(pt.z, 3);
    }
}

Unit testing randomly/procedurally generated content becomes a story of testing for the things you don’t want to happen. So if you don’t want any unreachable walls, you’d write a test to check for them - and then make sure that your generator algorithm culls them. Keeping the test around is helpful, because it’ll catch the times you forgot to do that when you tweaked or added an algorithm. Unfortunately, it would be pretty easy to write a whole second book on unit testing!

1 Like