Luke Micallef Section name

University of Reading 2014 Thursday 16 October 2014 Page 1

Adding arrays and loops

to the game Video transcript [BEEP] [MUSIC PLAYING]

Let's begin and see how the game should look when we finish this video. So I start the game (In emulator: Clicks screen to start game). And we notice that there are three sad faces on the screen.

The sad faces are actually there to block the ball. You don't score when you hit them, the ball just goes and reflects from it like it did in the smiley face. Otherwise, the game is exactly like it was before. We just have these three balls in the way.

When we look at it, actually, this shouldn't be that hard. Yes, there are three of them, so we expect to be using an array like we talked about in the earlier video. They're very good when we have similar things many times. So an array is the way forward and, therefore, probably also a few loops.

But the collision control and detection and response to the collisions will actually be exactly the same as the smiley face, except for we don't score anything when we hit the sad faces. Let's do it. Let's try and code it up (Clicks [reset] to pause game) > (Minimises emulator).

And I've already started here (In Eclipse: Looks at 'SadBall' code). Notice that I'm only using one bitmap (Highlights code), because all the three sad faces are similar. So I can use the same bitmap to print all of the faces.

But the x and the y position of the sad balls, they are arrays, a float array. So I set it up with some initial points for the x of minus 100. And the y, well, I just put in so and declare that it needs to be a float with three in it. I did this basically to show you two different ways of declaring an array.

Now like the smiley ball (Scrolls down to 'SmileyBall' code), we also need to create the sad ball. We need to create the bitmap for the sad ball. I'll just copy and paste this here (Copies and pastes code).

Begin programming: Build your first mobile game

University of Reading 2014 Thursday, 16 October 2014 Page 2

And then we need to change it so the drawable is the sad ball (Selects new drawable from list). It's there on the list. And there we have it. Now we have a bitmap that we can print on the screen with the sad ball.

Next up is the setup, when we set up the beginning of the game. We want to have three different positions where the sad balls are shown. I have created some here that I find are quite good (Copies and pastes code).

Please do go in and move them around and find other positions that you think are better for the game to make a more fun game. But I found that these work quite well for me. And I find that it's a fun game if I play with these.

All I do here is go in to each different variable in each array and give them a value, like we learned in the previous video and text. After that, we need to draw the sad ball and print them out. Now we need a for loop to do the drawing (Copies and pastes code), a for loop that goes through a counter from zero to two, and get the two different values for x and for y (Highlights code). Similar to what we did up here where we just got the x and the y, but now we get it with the reference to the array where we get the appropriate number in the array, get the value that is stored in that position, and then do whatever we needed to do before, when we printed out bitmaps.

This will print out the three different bitmaps in each of their appropriate position. We don't need to do anything when we're touching the screen, because it doesn't interact directly with the user's input, nor does it interact with the film's movements. But in the optic game, we need to do something.

We need to detect that there is a collision. And then we need to respond to it appropriately. It is very similar to the code that we had and used before the smiley face, but we're using a for loop (Highlights code block).

This for loop goes, again, through three times. Well, in this instance, because we are actually checking the length of the array, so we could make more better balls part of the game. Please do that, if you find that it would be fun. A five sad ball game would probably be very hard.

The for loop goes through from zero to the length of the sad ball at x array. We must have the same length of the x and the y, so I'm just checking the x. And we're taking the same code that we used in the paddle and smiley face code to detect the collisions.

Simply just copied and pasted that and changed it in the appropriate places, so that we are using sad ball x, but using the array and getting the appropriate value from the array. I copy and paste. That's all I do. Now we go through each of the different balls in the for loop, detect if there has been a collision, and respond to it if that were so.

University of Reading 2014 Thursday, 16 October 2014 Page 3

Should we have a look at the game again? Because actually, this will work (In icon menu bar: Clicks [Run] button) > (In 'Save Resource' dialog: Clicks [Yes]) > (In 'Android Device Chooser' dialog: Clicks [OK]). Here we are (In emulator: Clicks on screen to start game). And it works. Fantastic.

I want to show you a little bit about how we would do debugging, how we would work out what is happening when something is going wrong. Now we don't have any mistakes in this code, thankfully. But I want to show you how we would go about it if we thought we had a mistake (In Eclipse: Looks at ball velocity).

Let's assume that there's something wrong when we have a collision with one of the sad balls. What I always do is to try and think where could there be a mistake in the code doing that, and then I set a break point (Inserts breakpoint). Once the thing that should happen is happening, I will then expect the code to stop. This will show me that the code is going through the different part of the code as I expected, that nothing has not happened that shouldn't have happened, or that it is going a different route than what I expected.

After that, once I get into the break point-- let's do it (In icon menu bar: Clicks [debugger] button) > (In 'Android Device Chooser' dialog: Clicks [OK]). So we go in, we play the game, and the game should hopefully stop when I hit a sad ball (In emulator: Clicks on screen to start game). Can I hit a sad ball? I'm probably going to score immediately.

No, I didn't. There we are. We had a hit. It stopped as expected. So the code is working as we expected (In 'Confirm Perspective Switch' dialog: Clicks [Yes]).

We go into the debug perspective. And here, we'd normally then go through each different value to see if they are as I expect (In debugger: Checks values). If they are, then I'll start stepping through the code to see that everything else is happening as I expect.

If you start doing that, at some point you will get to a point where the mistake is happening. And you can then rectify it, or understand what you've done wrong. That's called debugging.

It's one of the harder tasks. Finding mistakes is really, really hard, actually. But it is also potentially one of the most satisfying things to do in coding, to find a bug that you created yourself.

Let's think about this game. Try to see what you want to do with it. You can change the positions of the sad balls. Try and do that first. But also try and add more balls, or less balls, have less balls in the game to make it decidedly easier.

If you really want to put your mind to something harder, why not try to add boxes? If you did boxes, or when you do boxes, they are much different when it comes to do collision control, because it's not just the ball. You can't just check how far you are away. You would have to think about when would I hit a box? So you'd have to check both the x and the y of the box with the corners in relationship to where your ball is.

University of Reading 2014 Thursday, 16 October 2014 Page 4

It's actually quite hard. But try and see if you could do it. It would be a good exercise.