Build it step by step

Every step below leaves a scenario that compiles and runs. If you stop halfway you will have something that works, not something broken. Follow along in Greenfoot rather than reading straight through.

1. Step 1

   On your screen A bounds-checking method with all four conditions.

   public boolean inBounds(int row, int col)
   {
       return row >= 0 && row < map.length
           && col >= 0 && col < map[0].length;
   }

   Four tests, and all four are needed.

   Row not negative, row not past the last row, column not negative, column not past the last column.

   It returns a boolean, so it drops straight into an if, which is the 3.4 pattern. Naming it `inBounds` means the calling code says what it means.

2. Step 2

   On your screen A combined check with the bounds test before the lookup, and a broken version with them the other way round.

   // SAFE: the guard runs first
   if (inBounds(r, c) && map[r][c] == 1) { ... }
   
   // THROWS: the lookup happens before the guard can help
   if (map[r][c] == 1 && inBounds(r, c)) { ... }

   This is the payoff for short-circuit evaluation from 2.3, and it is a lovely piece of machinery.

   In the safe version, if `inBounds` is false Java NEVER EVALUATES the right side, so the out-of-range lookup never happens.

   In the broken version the lookup runs first and throws before the check can save you. Same two tests, opposite results, purely because of order.

3. Step 3

   On your screen A grid with a highlighted cell and its four orthogonal neighbors, two of which are outside the grid.

   int walls = 0;
   if (inBounds(row - 1, col) && map[row - 1][col] == 1) { walls++; }  // up
   if (inBounds(row + 1, col) && map[row + 1][col] == 1) { walls++; }  // down
   if (inBounds(row, col - 1) && map[row][col - 1] == 1) { walls++; }  // left
   if (inBounds(row, col + 1) && map[row][col + 1] == 1) { walls++; }  // right
   

   The four orthogonal neighbors. Up is row minus one, because row counts DOWNWARD, which is the same rule as y from 1.4.

   A corner cell has two neighbors that do not exist, and the guard on every line is what stops that throwing. It is repetitive on purpose: at this stage clear beats clever.

4. Step 4

   On your screen A player blocked by a wall, with the destination cell checked before the move.

   public void tryMove(int dRow, int dCol)
   {
       int newRow = getY() + dRow;
       int newCol = getX() + dCol;
   
       if (world.inBounds(newRow, newCol) && world.tileAt(newRow, newCol) != 1)
       {
           setLocation(newCol, newRow);   // swap again
       }
   }

   And this is grid-based wall collision, which is the mechanic Tile Dungeon is built on.

   Work out where you WOULD go, check that cell exists and is not a wall, and only then move. No collision detection needed at all: the array already knows where the walls are.

   Note `setLocation(newCol, newRow)`: the swap from 6.4, one last time.