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 row of walls built from an array of heights.

   int[] heights = {2, 5, 1, 4, 3};
   
   for (int i = 0; i < heights.length; i++)
   {
       addObject(new Wall(), i, heights[i]);
   }

   A skyline, from data.

   The INDEX becomes the x position and the VALUE becomes the y position. Two different jobs from one array, and it is worth pausing on because it is the exact idea Unit 6 extends.

   Change a number and the level changes. The loop never changes.

2. Step 2

   On your screen Actors placed into fixed lanes read from an array.

   int[] laneY = {2, 6, 10};
   
   int lane = Greenfoot.getRandomNumber(laneY.length);
   addObject(new Car(), 0, laneY[lane]);

   Lane positions in an array, and a random lane chosen by index.

   `getRandomNumber(laneY.length)` is exactly right, and this is the payoff for 2.6: the exclusive upper bound produces 0 to length-1, which is precisely the valid index range. The two rules fit together with nothing to adjust.

   Add a fourth lane and this code needs no change at all.

3. Step 3

   On your screen A difficulty schedule array indexed by the current level.

   private int[] enemiesPerLevel = {3, 5, 8, 12, 20};
   private int level = 0;
   
   public void startLevel()
   {
       int howMany = enemiesPerLevel[level];
       for (int i = 0; i < howMany; i++)
       {
           addObject(new Enemy(2), i * 2, 0);
       }
   }

   A difficulty curve as data. Level 0 gets 3 enemies, level 4 gets 20, and tuning the game means editing five numbers.

   One caution: when `level` reaches 5 this throws, because the last valid index is 4. Either stop the game at the last level or clamp the index. That is a real design decision, not an oversight, and boundaries like it are where most real bugs live.