In this section we are going to use counted loops to create the "cement truck" toy video we just saw. But what we saw repeated seemed to have a variety of steps. We'll explore using abstraction to help us manage the code we write to create that video. Go ahead and download the world at the bottom of this page: cementTruckLoop.a2w
Why do something so complicated? What if we asked you -- instead of having cementTruck move forward one meter -- we want it to move 3 meters?
[Q10.2.1]: Before you even read about counted loops -- how could you make a cement truck move forward 3 meters? And why do you not need a loop?
But have you wondered how the move method works? The move method is a method someone wrote -- just like the methods you write. Hmm... They need something that will allow the object to move forward 1 meter, 2 meters, 3, meters, etc... Let's come back to that.
But there could be two ways to talk about having something move forward 3 meters. We could do:
or
They look slightly different when we hit play -- in the second one we can see the cementTruck coming to a stop after each meter. Let's suppose we want to do that -- have the cementTruck move forward in 1 meter amounts -- some number of times.
We can use a counted loop to do this. Instead of copying the same instruction 3 times, we can instead create a counted loop with one statement on it and tell the loop to run 3 times.
Let's do that -- as shown below.
After you select other, you should enter the number 3, since we want to loop 3 times. Next, we need to put the statement that tells the cementTruck to move forward inside of the loop. Delete two of the cementTruck move forward statements and drag the other into the loop. Your code should now look like this:
OK, that's nice -- but it's not really clear HOW nice this is until we say the following -- how about having the cementTruck move forward in 1 meter amounts -- 20 times!
[Q10.2.2]: How would you change the counted loop to accomplish this?
If we didn't have counted loops to help us out, we'd be copying the cementTruck move forward 1 meter 20 different times! (And likely, we'd lose count somewhere in the middle and be squinting at the screen trying to count how many we had... Going cross-eyed... And getting frustrated...). Or what about 100 times?!?!?
But really it's much more interesting to consider a more realistic or complex set of actions we want to have repeated. What about the cementTruck video from the previous page -- there's a set of tasks that are repeated 3 times. We could start by making a list of ALL the things we see happening in the entire video, put that whole list on a counted loop tile, and then play that code. We could do that. But we'd have to be very organized and careful not to miss something in our list of actions, and the code would be pretty overwhelming to look at.
Let's consider another option -- let's use abstraction and see if we can see some ways to logically "break down" the work in each iteration of the loop to group sets of actions into methods (an iteration is a single "set" of steps that should be repeated).
What if we look for two parts to each iteration. Watch this video which shows only one iteration or "step".
[Q10.2.3]: If you break this action into 2 parts -- what name would you give each part?
We are going to plan out or overall program using a storyboard.
Loop 3 times
Prepare
Zoom
If you remember storyboarding -- we indicate what goes on a tile by using indenting.
But what happens in the prepare method? and what happens in the zoom method? There's not necessarily just one "right" answer to this. Instead, we will describe our storyboard, and show the abstraction we chose by using a way of showing how method storyboards interact called an implementation strategy diagram. Below is the implementation strategy diagram we designed. Look it over, replaying the video of the single iteration above and trying to match parts to each storyboard.
*Note: In the world setup we have provided, the windupKey and all three lightnings have been made a vehicle to the cementTruck. This means when the cementTruck moves, those 4 objects will move along with it.
The storyboards in the implementation strategy diagram are not always "exact code" for some of the actions -- but they direct us enough about what we should remember to do. As we are doing the coding, we can double check that we are creating exactly what is in the video. (Note: in the real world, you likely have to create exactly what your customer wants from a verbal or written description -- much harder that re-creating a video! If you are a customer, help out by providing as much detail as you can. If you are a programmer, realize that you will likely have to go back and clarify what the customer wants several times.)
Next up... Building our program! (Hint: You might want to print out a copy of the implementation strategy diagram to be able to keep clear what we are trying to do. We only make these things to help out us, the humans, building the program.