Creative greenfoot pdf download

Save your Enemy class, and then compile your scenario. Run the scenario, right-click on the Enemy class, and choose new Enemy in the pop-up menu. Add this enemy to the screen and watch it move down.

Now that we have completed our Enemy class, we can use it to create an army. To do this, we are going to add code to the act method in our AvoiderWorld class.

Open the editor for AvoiderWorld by double-clicking on it, or right-clicking on it and selecting Open editor in the pop-up menu. If you look around the code for AvoiderWorld , you'll notice that Greenfoot does not automatically create an act method for you. No problem, we'll just add it.

Put the following code in AvoiderWorld :. The act method starts by checking whether a randomly generated number between 0 and , including 0 but not , was less than In the long run, this code will run 2 percent of the times the act method is called.

Is this enough? Well, the act method is typically called 50 times per second ranges from 1 to , depending on the position of the speed slider bar , so 2 percent of 50 is 1. Therefore, on average one enemy will be created per second. This feels about right for the starting level of our game. Inside the if statement, we create an enemy and place it at a specific location in the world using the method addObject. The addObject method takes three parameters: the object to add, the x coordinate of the object, and the y coordinate of the object.

The y coordinate is constant and chosen so that the newly created enemy starts off at the top of the screen and will appear as it slowly moves down. The x coordinate is trickier. It is dynamically generated so that the enemy could appear on any valid x coordinate on the screen. The following is the code we are talking about:. Figure 11 demonstrates the range of x coordinate values that are generated.

In this figure, the rectangles represent the possible set of values for the x coordinate for the given code. This method of generating ranges of values for screen coordinates is common in Greenfoot. Compile and run the scenario; you should see a continuous stream of enemy hordes moving down the screen. After running the scenario, you'll notice that the enemies end up piling up at the bottom of the screen. In Greenfoot, you can create worlds that are bounded where actors are not allowed to go past the screen borders and unbounded where actors are allow to exit the screen.

By default, Greenfoot creates bounded worlds. However, changing the world to unbounded is extremely easy. Double-click on AvoiderWorld to open the code editor. Take this line of code:. The constructor with four parameters has the same parameters as the one that takes three, plus one additional boolean parameter that indicates whether the world is bounded or not.

Our code change added the fourth Boolean parameter and set it to false no bounds in the world. In Greenfoot applications, you'll create hundreds and thousands of actors. When we are done with an actor, such as when it is killed or goes off screen, we would like to remove that object and not have it consume any more system resources. Java manages memory resources via a method called garbage collection. With this method, Java tries to automatically determine whether you no longer need an actor, and if you don't, it deletes that actor and frees up all resources associated with it.

In Greenfoot, you can let Java know you are done with the actor by removing it from World using the removeObject method. This is what we want to do to an Enemy actor, after we have successfully avoided it and it has moved off the screen. The most convenient place to remove an Enemy , after it has gone off the screen, is within the Enemy class itself.

Add the following code as the last line of code inside the act method in the Enemy class:. Now, we need to add the checkRemove method. Put the definition of this method below the act method. Here is the definition:. The code for your Enemy class should look like that shown in Figure Figure This shows the adding of code to remove the enemy if it goes off the bottom of the screen. Now, compile and run the scenario. The enemies fall of the bottom of the screen, as before, but you can feel good knowing that they are soon removed from the world and the garbage is collected.

Learning is not passive, and you really need to engage in the process. Before moving on to the next section of this chapter, you should:. Make sure your version of our Avoider Game works, click on Scenario in Greenfoot's main application menu, and then choose Save as… to create an experimental copy of Avoider Game. Let's name this experimental copy AvoiderGameIExperimentation.

Play around with your experimental copy. Change the spawn rates of the enemies. Change how fast the enemies descend. Add turn 5 ; to the act method of the Enemy class. Compile and run. What's going on? Try different values instead of 5 as the input parameter to turn. If things get too crazy, delete your experimental copy and make a new copy to play with from our original Avoider Game.

There's no harm done, nor any foul. Throughout this book, take this approach of experimenting with the code. Much learning will happen during the playing. The very act of thinking about how to change the code provides your brain with a new way to process and understand it. Making mistakes in a controlled environment will better prepare you to handle mistakes later on.

You will start to become familiar with Greenfoot's error messages. Great work until now! We have built the basics of our game and will next add some things, such as an introduction screen, game-over screen, and a score, to make it look and feel more like a game.

In this section, we will add a game-over screen, an introduction screen, and some background music. But, before we do all that, we need to know when our hero touches one of the enemies. This will be our cue to end the game. The act of determining when two actors touch is called collision detection.

Collision detection is used to tell whether a bullet hit an enemy, whether the player landed on a platform after jumping, or to tell whether a falling leaf landed on a surface. We will discuss this important topic next and spend considerable time on it in the upcoming chapters. Greenfoot provides several Actor methods you can use to determine whether you are touching another Actor.

They all provide slightly different ways of determining collision. For our game, we are going to use getOneIntersectingObject.

The prototype of this method is as follows:. This method takes one parameter, which is the class of the objects you want to check for collision. This method defines collision in terms of bounding boxes ; a bounding box is the minimal rectangle that can surround all pixels in the graphic.

This method is efficient and fast, but not the most accurate. In Figure 12 , we can see a picture of a skull and a picture of a smiley face. Even though the pixels of the two pictures are not overlapping, we can see that their bounding boxes are overlapping; therefore, getOneIntersectingObject would report that these two actors are touching. In Chapter 3 , Collision Detection , we will explore more advanced methods of collision detection. Armed with this new information, we are going to add collision detection to our Avatar class.

We will remove our hero from the game if it touches one of the enemies. Later in this chapter, we will display a game-over screen after removing our hero. Double-click on the Avatar class to bring up its editing window.

Change its act method to this:. Then, add this checkForCollisions method's definition under the act method:. The Avatar class should look like the code shown in Figure Let's examine exactly what's going on in the checkForCollisions method. The first thing we do is call getOneIntersectionObject and save its return value in the variable enemy. This variable will be null if this object is not touching any enemies, in which case, the expression in the if statement will evaluate to false , and we will not execute the statements inside.

Otherwise, we are touching an object of the type Enemy and do execute the contents of the if statement. There are only two lines of code in the if statement. In the first line, we use the method getWorld , implemented in the Actor class, to get a reference to the instance of the World we are in. Instead of saving the reference in a variable, we immediately invoke the World method removeObject supplying the keyword this as the argument to remove our hero. Lastly, we use the stop method in the Greenfoot utility class to pause our game.

Enemies should stream down from the top of the screen and exit out at the bottom. You should be able to control the hero, an instance of the Avatar class, by moving your mouse. If our hero touches one of the enemies, the game should stop. I used Adobe Illustrator to create the screen shown in Figure Its size should be x the same size as your world. Save this image in the images folder in your AvoiderGame scenario.

Using the same steps that you used to create AvoiderWorld The Avoider Game tutorial section , create another world; call it AvoiderGameOverWorld and associate the image you created earlier with it. In the World classes area of your scenario, you should see what is shown in Figure Now, we want to display the game-over screen if our hero touches an enemy. To do this, we need to perform the following three steps:.

Detect when we collide with an enemy and then tell by calling a method our world, AvoiderWorld , that the game is over. In our AvoiderWorld class, we need to implement the game-over method that the Avatar will use to signal the end of days. Let's start with step 1.

Previously, in the Detecting collisions subsection of this section, you wrote code to remove the hero from the game if it touches one of the enemies.

This code was contained in the method checkForCollisions. To implement step 1, we need to change that method to the following method:. The only difference is the code inside the if statement. I hope it makes sense that we are now asking the world to end the game, as opposed to removing the hero object. The part that could be confusing is the substitution of AvoiderWorld for World and the addition of the AvoiderWorld part.

The problem, is that we are going to implement endGame in AvoiderWorld , not World. So, we need some way of specifying that the return value of getWorld will be treated as AvoiderWorld and not just plain old ordinary World. In Java terms, this is called casting.

Now, let's look at steps 2 and 3. Here's the code you need to add to AvoiderWorld. We have changed, and added, a minimal amount of code, but if you have followed along carefully, you should be able to save, compile, and run the code.

See the game-over screen when our hero touches an enemy? If not, go back and retrace your steps. Something you typed in is wrong. Coding is complicated stuff. When you have a problem to solve, you don't just want to sit down and start hacking away at the computer until you bang out a solution. You want to sit down with a stylus and ePad used to be pen and paper in my day and plan. I gave you a small example when I wrote out the three steps needed to display the game-over screen.

One of the best methods to help you design a solution is a top-down design also know as divide and conquer. In the top-down design, you start thinking of a solution to a problem at a very high level and then repeatedly break down this solution into subsolutions until the subsolutions are small and manageable.

The game-over screen is great and all, but we don't want to just stare at it all day. OK, so let's make it so that you can restart the game by clicking on the game-over screen. AvoiderGameOverWorld needs to keep checking whether the mouse has been clicked and then set the world back to AvoiderWorld , so that we can play the game again. Mini-languages: a way to learn programming principles.

Greenfoot : Combining Object Visualization with Interaction. In the introduction we highlighted that the need for more programmers is now urgent.

Programming is a fundamental part of Computer Science. Educators therefore typically expect that Skip to content. Author : Simon J. Author : Henrik B. Right-click the Leaf class and place the leaf. There is a shortcut to placing several objects a bit quicker: shift-clicking into the world.

Make sure the Leaf class is selected, then hold down the Shift key and click into the world several times. You will place one object of the selected class at every click.

Each object now acts — that is: each object does whatever it wants to do. In our example, leaves are defined to do nothing, while wombats move forward. Both will move. Wombats also like to eat leaves. If they happen to come across a leaf in their path, they will eat it. This is equivalent to clicking the Act button over and over again, very quickly.

Clicking it stops the whole show. The slider next to the Act and Run buttons sets the speed. Instead of just running the whole scenario, you can also invoke single methods. A method is a single action that an object can perform. Make sure you have a wombat in the world, and the scenario is not running. Then right-click on the wombat, and you see that objects in the world also have a pop-up menu Figure 2.

You can select any of the methods shown here to ask the wombat to do something. Try, for example, turnLeft. Selecting this from the menu tells the wombat to turn to its left. Try move. Some methods give you an answer. Try it. This method is called every time you click the Act button. If you have many objects in the world that you do not want anymore, and you want to start all over, there is one easy option: throw away the world and create a new one.

This is usually done by clicking the 'Reset' button at the bottom of the screen. You will get a new, empty world. The old world is discarded and with it all the objects that were in it — you can only have one world at a time.

We have seen that objects in the world have methods which you can invoke via a pop-up menu. The world itself is also an object with methods that you can invoke. We have seen in the previous section how you can create new worlds. Now we want to invoke a method of the world object. Note that this is the title above the world's display, not the class name in the right hand panel.

Try it out. It is a method that creates several leaves and wombats and places them into the world. You can then run the scenario. This method places some leaves in the world at random locations.

Note that this method has some words between the parenthesis after its name: int howMany. It means that you must specify some additional bit of information when you invoke this method.

Invoke this method. A dialogue will pop up that lets you enter a value for this parameter. Enter a number — say: 12 — and click Ok. You may notice, if you count, that it sometimes appears as if fewer than the specified number of leaves were created.

This is because some leaves may be at the same location, and are lying on top of each other. The remainder of this tutorial assumes that readers are familiar with some basics of Java programming. Why dogs don't live longer than people Being a veterinarian, I had been called to examine a ten-year- old Irish Wolfhound named Belker. The dog's owners, Ron, his wife, Lisa, and their little boy, Shane, were all very attached to Belker and they were hoping for a miracle.

I examined Belker and found he was dying of cancer. I told the family there were no miracles left for Belker, and offered to perform the euthanasia procedure for the old dog in their home.

As we made arrangements, Ron and Lisa told me they thought it would be good for the four-year-old Shane to observe the procedure.