Second part of my endeavours to write a computer game with my daughter

A few days ago, I have written about starting to teach my daughter some programming by inventing and implementing a game with Greenfoot and Java. Here’s the second part of that journey.

This time, I had thought a little more in advance about what might be a good thing to tackle next. Putting floors in, so that the Doctor would just walk on those levels (and ladders to go up and down)? Or other moves: jumping, ducking, etc?

I decided the most interesting thing would be to put some opponents in – other actors that you could run away from, and who could catch you. With the Doctor, it’s pretty obvious who that should be: the Daleks! (They are the Doctor’s prime enemy, after all.)

When I came home from work, I suggested this to Sophie. Happily, she agreed.

In the first session, I pretty much let Sophie decide what we do. This time, I thought a little guidance would be appropriate. Firstly, I could see where we’re going: If we put some opponents in, we can very quickly reach a playable stage, where we see a little action and challenge on the screen. That’s important to keep the interest up.

Secondly, having a plan in advance allowed me to do some preparation. The preparation I did was to find and prepare an image of a Dalek. Web search, cutting out the background, scaling. I thought there’s no real value in making Sophie do that again – we’d rather spend the time looking at code.

So I asked Sophie, whether she thought that adding some enemies next would be a good idea. She agreed immediately, and over dinner, we (Sophie, Feena – my second daughter who is 7 – and I) were discussing what could or should happen. (Feena was increasingly getting in on the project. She may be a little young to write Java, but she certainly knows what she’d want from a Dr Who game!)

One important thing that came out is that the girls decided that when a Dalek catches the Doctor, it should shout “EXTERMINATE!”. (If you’ve never seen Dr Who, this might seem strange. But if you are familiar with the series, it all makes sense…)

After dinner, both girls walked around the room, shouting EX-TER-MI-NATE! repeatedly. Clearly, this was the most exciting idea right now, so we decided to deal with the sound first.

Recording the sound

To do sound, you essentially have two choices: find a sound sample on the internet, or make it yourself. Having tried both many times before, I find that making it yourself is both easier and more fun.

So I fired up some sound software. I use Audacity, a very nice and free audio recording and manipulation program, but just about anything that records will do. We plugged in a headset with a microphone, and both Sophie and Feena did their best Dalek impressions. We picked one of the various “Exterminate” variations they produced.

When listening to it, the girls decided that it didn’t sound right. Not mechanical or metallic enough. So we played a little with the effect filters in Audacity. We ended up using the “Phaser” filter with fairly high feedback:

This effect gives the sound a slightly metallic feel. Export to .wav, and we’re done.

That turned out to be a good start, because doing those Dalek impressions was good fun, and Sophie is now keen to get them into her project. So we fire up Greenfoot, and are back in space with the Doctor where we left off.

The first thing we want to do here is to create the Daleks. So we create a new subclass of ‘Mover’ and name it Dalek. We also choose the image I have prepared for it. We can now immediately compile and place a few Daleks into the game:

Of course, at the moment the Daleks don’t do anything. They don’t move, and nothing happens when the Doctor runs over them. The next challenge is to make the Daleks move. As a first step, we just make it move left, as we had done with the Doctor before. We open the Dalek’s editor, and change the act method to:

    public void act()
    {
        moveLeft() ;
    }

When we try this out (compile, place the Doctor in the world, place a Dalek in the world, and hit Run), it looks pretty good already. Except that the Dalek only moves to the left, and stops moving when hitting the edge of the world. But Sophie discovers one very interesting thing here: she can now create two Daleks. Or three. And they all move! She needs to write the class only once, and can have many instances!

Okay, we decide that the Daleks should always move sideways, back and forth over the screen. I thought about this a bit. There are several possibilities here. One of the nice things about Greenfoot (and about object orientation in general) is that you can provide users with an API as simple or as complex as you like it. I write the Mover class, Sophie works in the subclasses. By providing the right methods, I can make life easier for her. Or harder. Depending what level we’re at.

So I considered adapting the Mover to have a move method and a flip method. It would then remember the direction it’s going in, and the Dalek code would just call move() and flip(). I decide against it. I think we are ready to handle more if statements and a new thing: a variable.

So, we end up discussing variables (“we need memory to remember which way we’re going right now”), and write the following:

public class Dalek extends Mover
{
    boolean movingLeft;

    public void act()
    {
        if (movingLeft)
        {
            moveLeft() ;
        }
        else
        {
            moveRight();
        }
    }
}

Of course, this still does not turn around at the edge. There, a new method comes in. I had thought about a few helper methods that I would provide for Sophie. I used similar methods in earlier teaching sessions, so I copied and adapted a method from an earlier project and put it into the Mover class:

    /** * Test if we are at one of the edges of the world. Return true if we are. */
    public boolean atWorldEdge()
    {
        if(getX() == 0 || getX() == getWorld().getWidth()-1)
            return true;
        if(getY() == 0 || getY() == getWorld().getHeight()-1)
            return true;
        else
            return false;
    }

This, again, is preparation work that I do. I tell Sophie that the Dalek can now use atWorldEdge() to check whether he’s at the edge of the world. With a bit of discussion, we work out this code:

    public void act()
    {
        if (movingLeft)
        {
            moveLeft() ;
            if (atWorldEdge())
            {
                movingLeft = false;
            }
        }
        else
        {
            moveRight();
            if (atWorldEdge())
            {
                movingLeft = true;
            }
        }
    }

Now this should work! We try it out, and — it doesn’t! The Dalek just got stuck at the edge of the world again and doesn’t turn.

I was pretty confident that the Dalek code is correct, so I thought that maybe the error is in the Mover class. Now, one useful thing in Greenfoot is that you can invoke any individual method on any object, just by right-clicking on the object:

I called the atWorldEdge method on the Dalek that was stuck at the edge, and it did indeed return false, when we were expecting true. So the error was in the atWorldEdge method. It turned out that I had a typical off-by-one error: I had forgotten the -1 in the test. (In the version shown above, this error is already fixed.)

So I fixed the error, and we tried again. Now the Dalek actually went back and forth. HURRAY!

At the moment, the Daleks move nicely (by themselves), and we can move the Doctor with the keyboard. Good. Here, Sophie discovers something interesting: The Doctor can actually move diagonally as well! Just hold two keys down (say, up and right) and off he goes. Sophie finds that “very cool”. I hadn’t thought of that. But the way the code is written, it makes sense of course. Sometimes it is unexpected things that make a difference.

Currently the Doctor can still run across the Daleks without anything happening. The next thing, therefore, is to make the Daleks catch the Doctor.

Again, I have thought about two helper methods to provide in the Mover class: boolean touches(Class) and void remove(Class). The first method returns true when the Dalek touches an object of the specified class. The second method removes any overlapping object of the specified class.

I had used similar methods before, so I copied them out of an old project and put them into the Mover class. (Again, that is something that you could do in advance, and when I teach groups I certainly have all this prepared before we start.)

The implementation is

    /** 
 * Return true if we touch an object of class 'clss'. 
 * False if there is no such object here. 
 */
    public boolean touches(Class clss)

    {
        Actor actor = getOneIntersectingObject(clss);
        return actor != null;
    }

    /** 
 * Try to remove an object of class 'clss'. This is only successful if we 
 * are currently touching such an object. Otherwise this method does 
 * nothing. 
 */
    public void remove(Class clss)
    {
        Actor actor = getOneIntersectingObject(clss);
        if(actor != null) {
            getWorld().removeObject(actor);
        }
    }

I don’t discuss this implementation with Sophie. In Greenfoot, you can switch the editor to documentation view, so that you just see the Javadoc:

So this is what Sophie and I look at together, and we can see the instructions which we can use to make the Dalek do things. There are now the touches and remove methods. So we work out that we should write something like in the Dalek:

    if touches Doctor
    then
        remove Doctor

I talk Sophie through the typing to get the syntax right, and we end up adding the following code to the Dalek’s act method:

    if ( touches (Doctor.class))
    {
        remove (Doctor.class);
    }

I thought it was rather unfortunate that we have to write the “.class” after the Doctor class name. I thought it looks confusing, but Sophie didn’t seem to be worried. She just accepts it (as kids so often do), and we get on with it.

We try it out – it works! Great. It turns out that you don’t actually have to touch the Dalek’s image with the Doctor’s image to get removed, but just come near it. This is because the getOneIntersectingObject method that I’ve used uses the bounding boxes of the images for testing intersection. But that doesn’t matter too much.It just needs adapting in the story line: “Dalek’s will get you if you come too close to them.”

Now, we’re almost there. The girls both want to play (and they do a bit) but we want to do one more thing today: put the sound in. This is actually easy now. We take our sound file that we produced earlier. We had it saved under the name “exterminate.wav”. In Greenfoot, every scenario has a folder with a few standard sub-folders, on of which is called “sounds”. Sound files are accessible to the actors, if they are stored in the sounds folder. So we just move the “exterminate.wav” file into that folder.

I let Sophie work out where in the code the instruction to play the sound should go (she gets it with a few leading questions), and then I tell her the exact command:

        if( touches (Doctor.class))
        {
            remove (Doctor.class);
            Greenfoot.playSound("exterminate.wav");
        }

That’s it – we’re done! We place the doctor and three Daleks into the world, and the girls are off playing. Using the Greenfoot Export function, it’s easy to turn this into an applet now (which I am doing now as I’m writing this up, so that you can have a go with it yourself). Try it out.

The girls both play for a while. They try to move the Doctor from the bottom of the screen to the top, and back to the bottom without getting caught. A few other interesting things happen. Sophie says “I wonder what happens when I have more than one Doctor. Do they all move at the same time?” So she creates several Doctors and tries it out. It works.

Before you know it, Sophie and Feena have filled the screen with dozens of doctors, and put a few Daleks in to EX-TER-MI-NATE them all. The sound is hilarious.

That’s it for this session. All in all, it took about 45 minutes until we reached the final version, and then they spent another 15 minutes just playing around with it. You can get the full source code (as a Greenfoot project) below.

I’m curious where it will take us next.

The summary for today:

Session #2
Time: 45 min
Result (live on the Greenfoot site): DrWho2
(Source code can be downloaded from the link above.)

Next: Dr Who, Part III: Prepare The TARDIS!