Zombie Game: Implementation of the Backdrop and Flower
Let's implement the behavior of the stage. When the game begins,
it should have the garden backdrop. Let's code this. We could have alternatively specified
this within the code for the broom. As we've already mentioned in this course, often there are more than one possible
ways of implementing our programs. This idea brings me to the concept of the
computational complexity of an algorithm. Even though this sounds
like a complicated idea, it is actually an easy
concept to understand. Suppose that we have several
algorithms to solve the same problem. For example, we want to go
from one city to another, and we have various algorithms. One is to go by car, another one is to go
by plane, and another one is to go by bus. Which one do we choose? We can compare these algorithms. Based on the time it takes, or
the resources needed for each one. And then we can choose
the one that suits us best. Good. Now, let's go back to our game. When designing the program for the stage, we also specify
that when the game is over, it should switch to the corresponding
backdrop, and stop all scripts. This is the stage's reaction to
the receipt of the corresponding message from the zombie clone. How can we implement this? We'll introduce a block "when I receive
game over" from the events palette, and we'll next specify that we
switch backdrop to game over. and that all scripts will be stopped. Even though we haven't implemented
the behavior of the flower so far, we can still test our program for the rest
of the objects that have been implemented. Let's test it. Nice! The instructions are given as expected. The broom is making the zombies go away. The score is updated. Now, let's see what happens when
a zombie reaches the house. Good, the game is over. But, why do we keep seeing
the broom on the stage? In the current program, there is nothing that tells the broom
to hide when the game is over. How can we fix this? At the broom, we'll introduce a
"when I receive" block, setting it to game over,
followed by a hide block. Good. Now, let's test our revised program. It's working! Let's try to play this game once again. Oops! We can't see the broom. By testing again, we found another error. We have to specify that the broom
is shown at the beginning. Let's implement this. Now, let's try it again. Excellent! Problem solved. Note that here, we've moved to
a different stage of the software development process,
that is testing and debugging. Now let's program the behavior of
the flower according to our design. We'll introduce the green flag,
followed by a repeat block, setting it to a random
number from three to ten. Inside this loop, we'll put a block for
creating a clone. Just like in the case of the zombies,
we'll specify at the end of the script, that the flower sprite is hidden, since we'll be working with clones
rather than the sprite itself. Now let's implement the behavior of the
flower clones, following our pseudocode. When it starts as a clone, it will
be located in a random spot, with x and y values between -150 and
150, and it will be shown. Next, we'll specify that the flower clones
keep dancing until they touch a zombie. The dance can be programmed by repeatedly
changing costume and waiting for a short time. Once the flower touches a zombie, the flower clone should be deleted. Let's test out program so far. Brilliant! One detail that we could improve
is that the flowers could be touching each other. To avoid this,
every time we place a flower, we can check that it is not touching
the orange color of the petals. And that it is not touching
the dark green color of the stem. If it touches one of them,
we should reposition it and check again. To implement this,
we'll add a repeat until block, with a condition that it is not touching
green and it is not touching orange, that is, the flower's colors. Remember, that this is
a complex condition. Inside the repeat until block, we'll introduce a go to
block with random positions. Let's test our revised
program a few times. Good! Let's pause for a minute and think about the process
that we've been following. We've been developing our game in
an iterative and incremental fashion. Each new version includes more
elements than the previous one. In this unit, we've talked about the waterfall
approach to software development. Another approach is to
create a software prototype. A prototype is a model of the final
program which allows us to test for certain features without
having the full program. For example, in architecture, a prototype of a house could be
a model of the size of a shoe box. This allows us to visualize the house and imagine how we can move inside it without
having to create the actual house. It also let's us make corrections and adjustments in a design before
actually building the house, which is certainly better than having
to do them after the house is done. Creat