Review of JavaScript code from

hello, this is my code that i am making for my APCSP class. i have been having some trouble figuring out how to make it so if my sprite collides with the color black that it is then sent back to its starting position. Im using app lab though so it makes it harder for me to figure this out. I have also been trying to make the other sprites disappear that arent chosen once on the maze screen but it isnt seeming to work out very well. im very new to coding so im trying to learn as much as possible. thank you for any help

Well, welcome to Sitepoint, pedersent.

the code in question here seems to be a pre-scripted set of functions. So without knowing what functions are available, what they do, etc, it’s going to be difficult to assist you very practically. Unfortunately, this website doesn’t appear to publish its function set in a manner that can be consumed by people outside of the course.

That said, we can talk about the theory of what you are doing, and how you might go about wall collision.

A Cartesean Example

Let’s ignore sprites, and custom drawn maps for a second, and draw the world as a grid of squares. Because that’s how computers think of space on your screen. A grid of squares called pixels. Let’s draw a verrrry simple ‘maze’.

*    *
*  X *
*    *

(Told you it’d be simple)
Okay, what i’ve drawn isnt exactly a maze. It’s a box. But a maze is a box with a bunch of bits in the middle. So that’s a start. Let’s specify a few things:
1: the TOP LEFT corner of my box is where the number system starts. So that star in the top left, is at 0,0.
2: since the top-left is 0,0, we count distance from that point, meaning all my numbers are positive. Let’s say the star to the right of my origin is at 0,1, and the one below it is at 1,0. Yes, that’s kind of backwards notation for an X and Y coordinate. It’s to do with how the map gets stored in the computer’s memory. So, I’ve made a 6x5 grid (good job Marc. nice and square there.) my grid goes all the way from 0,0 (top left) to 5,4 (bottom right).
3: Our player can move exactly 1 square at a time, and in one of the four cardinal directions.
4: Our player cannot move onto/through a wall. Because that would defeat the purpose of a maze.

My X, which is the ‘player’, has started off at 2,3. (once again, great job on making a square such that you could put it in the middle, Marc.) Let’s think logically for a moment; what are the valid next moves for X?

Well, we could use some maths to figure out if the player is next to a wall because we know the maze is this big and the player’s position is one less than the width or height and … but there’s a problem with that; we’re trying to do this for a maze, not a box. So unless we have some very complex maths that tells us where all of the walls in the maze are, that doesn’t work.

Right so we can’t pre-scribe where the player can go. What we can do however is check after they’ve decided their move that when the player tells us which direction they want to move in, that move is legal. We know that there are *'s at 0,0 and 0,1 and 0,2 etc; we had to know that to draw the maze. So, if the player’s move says “go right”, we first check the square “right” from the player’s current position. Does it contain a *? No, so the player can move there. We move the player in their desired direction.

Now our map looks like this:

*    *
*   X*
*    *

If they say “go right” again (because our player isnt the brightest in the world, clearly), then we check the square they want to move into; this time however, it DOES contain a *. So we stop the player, and tell them they’ve died. Because walls are lethal. Apparently. Just how fast is your player moving that walking into a wall is lethal? Leave that one to the physics guys I guess.

This theory can be represented in pseudocode:

When The Player Moves
If the square the player moves to has a * in it, kill the player.
Otherwise, remove the X from the current square, and put it into the square being moved into.
End If
End When

and eventually, step it towards practical code:

function stepRight(player) { //When the player moves right
  let target = { x: player.x+1, y: player.y} //A rightward move
  if (grid[target.y][target.x] == "*") { //If the move location has a * in it
     console.log("You died."); //They die.
  } else { //Otherwise
    grid[player.y][player.x] = " "; //empty square.
    grid[target.y][target.x] = "X"; //player is here.
    player.x = target.x;
    player.y = target.y; //Update the player's position for next time.
    console.log("Moved Right");
    redrawmaze(); //Clear away the maze picture, draw the new state.
 } //End If
} // End When

//Redraw maze, for the sake of executability:
function redrawmaze() {
   grid.forEach((y) => console.log(y.join("")));

//Setup stuff
//Draw my map...
var grid = [['*','*','*','*','*','*'],['*',' ',' ',' ',' ','*'],['*',' ',' ','X',' ','*'],['*',' ',' ',' ',' ','*'],['*','*','*','*','*','*']];
//Put the player down in the map...
let me = {x:3,y:2};

//Show the map initially:

//Simulate player choices ('play the game')
stepRight(me); //Moved Right
stepRight(me); //You died.

thank you so much, i will go ahead and try to implement this into my code. with a similar concept but with a pre drawn map if that is possible

by the way here is where the code is listed

@m_hutley how would i do this if my maze is my background image on the screen? or would i have to draw rectangles and stuff in order to get a complex maze and not just use an image as the background. so i cant base it off of color?

Well the toolset you linked does have methods for retrieving the color at a given point in image data. So if you think of the image data as your grid, and apply the same logic to it…

I guess that would mean checking the pixels around the border of the sprite each time that it moves, at the intended target location of the sprite, to see if any of those pixels are a wall of the maze.

With a possible enhancement of pre-processing the image as an array, to indicate which locations are safe for passage, that being half the sprite distance in from the walls, and which ones are not?

You could improve the preprocessing algorithm’s storage requirement because it would be a summation check; If the sum of RGB across an X pixel range is less than (for safety) 720X, then there is some pixel within that range that is ‘dark’, and thus not valid.

Course, if your background image is fuzzy on its colors, you run into problems. Also keeping in mind that I’m not entirely sure if the imagedata pixel grid dimensions correspond to the source image or the presented scale.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.