Cool level. I tried a couple of seeds and everything seemed to work for me.
The first things I noticed were the longer loading time, the repeating wall-door patterns in the middle and the lack of example code. I figured there had been a bunch of hand-holding levels lately, so maybe this was intentional.
Flags restricted -> good
Level decorations are good
My experience:
First I tried copying the code from sesame path. I had to change the distance variable to fit the distances in this level, which I calculated using the differences in tooltip coordinates. (Maybe this distance should be stated somewhere.) As expected, the code didn’t pass because the path wasn’t “one route without forks”. But the code did provide a basis for checking which paths were clear.
Now what? Maybe DFS? Then I remembered the maze strategy where you keep following the wall on your left. So I implemented that and it passed.
I think the strategy is viable for this type of maze for any combination of locked/unlocked doors (Figure 1 has a loop in the top left).
The main breaking case is when the start location and the goal location are not connected by walls, but in this maze they are connected.
I believe I have found a bug. When I play as Tharin with Ring of Speed equipped, the isPathClear method returns wrong results sometimes. I’ve added a shield() call after every moveXY() in order to add a small delay and then my solution worked. (Note that the wait() method did not work properly due to the hero momentum pushing them further than they were supposed to go)
Agreed, perhaps a constant/variable declared in the default code would be suitable as well.
This level is very buggy. The initial randomly generated setup for me does not appear to have any solution (here I just hardcoded the directions for the hero to move to prove the point), and the typical approach doesn’t work either because isPathClear is not behaving correctly: it frequently returns true for paths blocked by an ice wall that won’t open.
Yeah, players usually say that about any level that they can’t pass (Just passed it several times with all possible mazes (there are four of them)
I suppose I know the problem with your code, however, could you post it to be sure?
isPathClear work correctly, but doors are less than corridors, that’s why you can see “through” them, but can’t pass (btw it’s a hint why you can’t solve it).
Okay, so I just did more observation and testing, and it seems that the sensitivity of the doors are inconsistent between directions: the initial position given relative to a room can trigger top, left and right door to open, but not the bottom; the hero needs to move closer to trigger it.
…Wait, what? But this is what the hints page is saying:
Use the isPathClear function to find which doors are open as you navigate the maze.
So you’re saying isPathClear can see through closed doors when the hints are implying otherwise? I… don’t know about anything anymore.
And yes, I still stand by my point; it has nothing to do with any code being wrong, but about the level behaviour being unintuitive and not what is being stated. Even if I follow the standard algorithm perfectly I won’t be able to solve the level because of these problems.
Hmm, okay, I can now see the cause of the problem: the initial code given defines the start of the room as {x: 18, y: 19} instead of {x: 18, y: 18}, so that’s why I kept being 1 unit off to trigger the doors on the south. I guess it shouldn’t be hard to fix the initial code?
Well, technically I had wrote some code as my first try, but after getting hit with stuff clearly counter-intuitive I don’t think that’s very relevant anymore. I mean, I can do clunky stuff like try walking toward next room and check if I get no displacement (due to being blocked) midway, which doesn’t rely on isPathClear at all, but the hints told me to utilize isPathClear and it’s not working as it should’ve been, and that is what I have issues on: if the hints are hinting at something not helpful, it’s misleading.