Recently,N Cueto wrote: > If given a maze in the form of a > grid > ... > then, what would be the > ideal scripting for limiting > "movement" between only > contiguous squares that are > not separated by a wall
The way I've done something like this in the past is to use physical boundaries, in other words, using the intersect and/or within functions to prevent/constrain movement in certain directions. From your example, it's not clear if you *need* to limit movement based on numerical progression, but this could be handled easily via the loc property, as you guessed. You could use rectangle "wall" graphics combined with the above functions to allow for moveable obstacles, and test for collision with the graphics on the current maze/screen. Alternatively, if you were able to use a single image as your maze, this would allow for testing intersect/within results within a single object -- the image. This is the benefit of using images for collision detection in that you can test for non-transparent pixel collisions, as opposed to using graphics which only allow for rects. I don't know if images would work in your situation but that was the technique I used and it's reliable. Let me know if this makes sense (or if not, maybe I can dig up an old demo). Of course, one must also keep in mind Malte Brill's Arcade Engine... Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design ----- E: [EMAIL PROTECTED] W: http://www.tactilemedia.com _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
