Fragile Maze - adventurer feedback


#1

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 didn’t try summoning troops though.

Figure 1: The layout of the level and one of the longer paths


#2

Wow, this level was really satisfying to beat. Such an elegant solution too. :smiley:

Though there seems to be no achievements configured for this level.


#3

Though there seems to be no achievements configured for this level.

Got it, thanks. Replay the level for the experience and gems.


#4

Yeah :slight_smile: I didn’t add “anti-[spoiler]” loops. I added them at the first, but then I decided to make it easier.

BTW, I solved it with simple DFS and “map drawing” technics.


#5

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.


#6

Yep. In the first iteration mazes were trickier


#7

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.


#8

Thank you for the feedbacks.

Yes. I reduced the opening delay, but it’s not enough. I will try to do something, but not sure that I can fix it.

Ok. I will add it.


#9

Realy cool level. Strategy is very easy. To path any labyrint you have to tuch one wall by your hand.


#10

Ok. Ok. I can make the improved version with “left/right hand” rule protection :wink:

And don’t worry I have several ideas about mazes which will try to twist your brains.


#11

If you put charaster in the middle labirint, than this strategy could fail.:slight_smile:


#12

I know, but not just in the middle. To fail “left” rule I need to add “ring” around it.


#13

Great level! It was fun to think about how to implement the right/left hand rule in a simple way. It’s ready to go live! :thumbsup:


#14

Added constants about distances.

And soon you will see the sequel. Almost the same :wink:


#15

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.

See screenshots:



#16

Yeah, players usually say that about any level that they can’t pass :wink: (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).


#17

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.


#18

Try to place your hero in the centre of rooms.

I don’t know, I haven’t seen it to be sure.


#19

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.


#20

It’s weird. Doors have 10 metres open radius. so 1 metre can’t affect on this. Could you send (post) your code, which you are sure is correct?