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 diagram with a grid on the left and a world on the right, and an arrow showing col becoming x and row becoming y.

   // Grid says [row][col]. The world wants (x, y).
   // x is horizontal, and so is the COLUMN.
   // y is vertical,  and so is the ROW.
   
   addObject(new Wall(), col, row);   // note the SWAP

   Here is the whole lesson in one line, and it is worth staring at.

   The array is `[row][col]`. The world wants `(x, y)`.

   x is the horizontal one, and the horizontal index is COL. So x comes from col. y is the vertical one, and the vertical index is ROW. So y comes from row.

   The two swap places. `map[row][col]` becomes `addObject(a, col, row)`. Getting this backwards is the transposed map from 6.2 arriving by a different route.

2. Step 2

   On your screen A nested loop placing a wall for every 1 in the map, with the swap visible in the addObject call.

   for (int row = 0; row < map.length; row++)
   {
       for (int col = 0; col < map[row].length; col++)
       {
           if (map[row][col] == 1)
           {
               addObject(new Wall(), col, row);
           }
       }
   }

   And there it is, the two orders side by side in the same block.

   `map[row][col]` reads the cell. `addObject(..., col, row)` places the actor.

   This is the whole tile-map renderer, and the next lesson only adds more tile types.

3. Step 3

   On your screen An actor standing on a cell, with its world position being used to index back into the map.

   // The other direction: which cell am I standing on?
   int myRow = getY();
   int myCol = getX();
   int cell  = map[myRow][myCol];

   Going back the other way, which is how a player checks what it is standing on.

   Same swap in reverse: the actor's y is the row, its x is the column.

   This works directly because the world uses one cell per grid square. If the cell size were larger you would divide by it first, which is exactly what cell size meant in 3.5.

4. Step 4

   On your screen A world constructed to exactly match the dimensions of the map array.

   public MazeWorld()
   {
       // columns become width, rows become height
       super(map[0].length, map.length, 32);
       prepare();
   }

   Size the world FROM the map and the two can never disagree.

   The swap appears here too. `super(width, height, ...)` wants width first, and width is the number of COLUMNS. Height is the number of ROWS.

   Hardcode 20 by 15 and then edit the map, and you get walls placed outside the world or an empty band down one side. Deriving it means the world is always exactly right.