Maze Collision Issues

[Kathleen Falcon]

Hi guys, I've searched through previous topics about mazes but I haven't found a working solution to my issue. I'm trying to build an educational maze app where the user uses four directional buttons move a character sprite through the maze, so an up, down, left, and right button that moves their sprite character by a number of pixels at a time. The maze lines themselves are in a separate, singular image sprite as one big "overlay" on top of the canvas which has it's own background and I've attached a picture of the UI to help visualize this. 

What I want is that: if the character sprite collides with part of (a maze line) the maze image sprite, I want the character sprite to be unable to pass the line, just like how you'd expect a maze to work. I've played around with many different blocks (canvas pixel color, canvas background pixel color, collided with, bounce edge), but I just can't seem to accomplish this. I thought of setting up an event to occur when the character sprite and maze sprite collide that would "reverse" whatever action that occurred when the user pressed up/down/left/right. For example, if the character sprite collided with a maze line after hitting the Right button, then it would move the character sprite left back to where it was as if the Left button was tapped. However, I also could not get this to work.

Any ideas?

[Taifun]

you might find an idea in one of Scott's examples here https://groups.google.com/forum/#!searchin/app-inventor-developers-library/maze

Taifun

---

Trying to push the limits of App Inventor! Snippets, Tutorials and Extensions from Pura Vida Apps by Taifun. 

[Abraham Getzler]

You might find it helpful to separate the design aspects into a View - Model - Controller architecture.

The View part should be the only part that knows about pixels.

The Model design should be the only part that knows about the grid structure and the coordinates,

player start and destination coordinates,

as well as knowing how each  coordinate (measured in rows & columns, not pixels) has 

up to four possible accessible neighbors based on the four possible buttons.

The Controller part should know about the buttons, the choreography and showmanship of 

initiating and ending a game, and how to ask the Model to try to move.

ABG

[Kathleen Falcon]

The fling in Scott's example works great, but it doesn't translate the same way to up/down/left/right buttons unfortunately.

[ScottFerguson]

This is what I came up with.

It allows the hero ImageSprite to move around the maze based on the data stored in a csv table.

The data in the MazeMoves text file looks like this:

00,dr

01,lr

02,ld

03,r

04,lr

05,lrd

06,l

07,dr

08,lr

09,l

:

90,r

91,lu

92,ur

93,lr

94,lr

95,l

96,ur

97,ul

98,ur

99,ul

There are 100 rows in the table for each square in the puzzle.

This csv table is read into a lookup in pairs list. 

When an arrow button is pressed, the direction (l,r,u,d) is passed to a procedure which does a lookup for the row and column of the hero sprite, determines if that direction is allowed, then moves the hero if so.

As an aid to determining which directions are allowed for each square in the maze, I numbered each row and column 0 to 9:

So for row 4, column 3, the allowed moves are up (u) and down (d)

This can be represented in the list and csv table file as: 43,ud or 43,du

---

Happy Inventing!

 

[Abraham Getzler]

Nice and simple!
ABG

[Kathleen Falcon]

Thank you so much Scott! I've been working on implementing it since yesterday for 9 other maze layouts, I really love this idea. I'm a student with less than half a year's experience with AppInventor and programming in general so a lot of those blocks initially went right over my head. However, I understand them all now thanks to your explanations and visuals and I'm gaining even more knowledge of concepts like this to use in app making. 

Thanks again!

[ScottFerguson]

Yay! :)