This week we extended our colliders so that we could used them to prevent the player going off the edges of the screen. We used it to show how software design needs to evolve.

Colliders

Our colliders were designed to be connected to an object with three things:

1. A property x  containing the x-coordinate of its location
2. A property y containing the y-coordinate of its location
3. A function hit() which was called if the attached collider touched another collider

Something to Connect To

We had colliders already attached to our:

1. Enemy
2. Bullets

but we didn’t have anything to attach to that could represent the side of the screen.

We created a new class called Static() with nothing more than the x, y  and hit() that we needed so that we could connect a collider to it (stored in one more property – collider).

Screen Edges

We created a pair of these colliders positioned at the right and left-hand side of the screen. We made sure to add them to our list in check_colliders(). Nothing much happened. Why? Well, first, the Player didn’t have a collider, so we added one, liberally copying code from Enemy, which a minor change to the description argument.

Now we could see the contact occurring between the edge and the player, though nothing was stopping it moving yet.

Unintended Consequences

As  often happens with code, this change had unexpected consequences; bullets were not firing properly any more. Why? Because the player now had a collider and the bullets were becoming inactive immediately because they were hitting that. The fix was to modify the Bullet’s hit() function to ignore hitting a collider with the description “player”.

Stopping the Player Moving

We now knew our player was hitting an edge, but another problem became apparent: we didn’t know which edge!

To properly stop the player and stop it moving too far, we really needed to know which side of the player the collider we’d hit was, but that information wasn’t available to us with the current design.

A couple of quick changes were necessary:

1. In Collider.touching(), instead of just passing the descriptors to the objects hit() functions, we changed it to pass the Collider itself.
2. In all the hit() functions, we had to made a small adjustment to account for the fact that we were now getting a Collider and not just a string.

With the extra information from the collider, were were able to determine how far the player should be allowed to move to and prevent it going further by setting the x value appropriately.

Download

The files for this week can be found on our GitHub repository.

This week we mainly dealt with building and using a box collider in our game. The box colliders are written in a way such that:

• They are connected to something in the game and follow it around
  • What they are attached to must have the properties x and y for position
• It is possible to test if they are touching each other
• If two colliders are found to be touching, we tell the things that they’re attached to that they’ve been hit by something
  • What they are attached to must have a function hit() that we can call

Extents of the Collider

Our collider is a box, of a given width and height, centred on the x and y of the thing it’s connected to:

For checking collisions, we need to know the x values of the left and right side of the box and the y values of the top and the bottom of the box.

For convenience, we write a function which returns an object (using curly brackets) with the left, right, top, and bottom values (shortened l, r, t and b respectively) as properties:

extents(){
  return {
    l: this.connected.x - this.width / 2,
    r: this.connected.x + this.width / 2,
    t: this.connected.y - this.height / 2,
    b: this.connected.y + this.height / 2
  };
}

When making an object like this, we set a property value by first writing the property name, followed by a  colon (:)  and then a space and the value we want it to have. Each property is separated with a comma. The don’t need to be on separate lines, but it makes it easier to read.

Touching Colliders

So how do we know that two colliders are touching? Actually there are four ways in which they definitely can’t be touching:

• One is completely to the left of the other
• One is completely to the right of the other
• One is completely above the other
• One is completely below the other

And if none of these are true, then it must be touching. So actually, we’re going to check that they’re not NOT touching (double negative, used correctly!).

How do we know if something is completely to the left of something else? Look at this diagram:

We know that box 2 (in blue) is totally to the left of box 1 (in orange) because we can see it is, but how could get the computer to check it? Remember, left and right are just x values on the screen. Box 2 is left of box 1 because both it’s left and right values are smaller than the left value of box 1.

The checks for the other directions are very similar:

• The second box is right of the first box when both of it’s x values (left and right) are greater than the first’s right side.
• The second box is above of the first box when both of it’s y values (top and bottom) are less than the first’s top side.
• The second box is below of the first box when both of it’s y values (top and bottom) are greater than the first’s bottom side.

Sending Messages

Each collider has a property disc that describes the thing, or type of thing, that it’s connected to.

All colliders know what they’re connected to, so when we determine two have touched, we call a function called hit() on each of the connected objects, passing it the desc of the other collider. This means, in our game, when our enemy is hit, it can know that it’s been hit by a bullet – or maybe something else – and react appropriately.

Checking Every Collider Against Every Other

In our code, we gather all the active colliders at each frame. We then need to check each one against each every other one. How can we do that?

Consider a list of four items:

To check them all against each other we first need to check 0 against the other three. Simple enough.

We we need to check 1. But we don’t need to check 1 against 0, since we already did that. Nor do we need to check it against itself. We only need to check it against 2 and 3.

If we write out the full sequence, we see that for four items we need three passes to check all combinations:

• First pass: Check 0-1, 0-2, 0-3
• Second pass: Check 1-2, 1-3
• Third pass: Check 2-3

We can write a pair of loops to do this:

for (let i = 0; i < c.length - 1; i++){
  for (let j = i + 1; j < c.length; j++){
    c[i].touching(c[j]);
  }
}

Note two things about these loops:

• The first loop goes from zero, but stops one short of the last item in the list (i < c.length – 1). It picks the first item to be checked.
• The second loop doesn’t start from zero. It starts from what ever i currently is, plus one. It picks the second item to be checked.

Other Stuff

We also did a few other things this week:

1. We fixed a small bug that was keeping our spaceship moving when we didn’t want it.
2. We added a little drag to slow the spaceship down to a stop when we lift our fingers off the keys
3. We set bullets inactive when they hit something

Download

The files for this week can be found on our GitHub repository.

This week we continued our Shootah project. We did two main things;

1. Changed the code to control the total number of bullets to those actually on screen
2. Added an enemy that loops backwards and forwards across the screen

Controlling the Number of Bullets

In Part 2, we made a new bullet every time the user pressed the Up key and put it in the bullets list.

This meant that after a while we could have a lot of bullets, most off the top of the screen, which was even slowing some machines down.

To limit the number of bullets we did four things:

1. Added a new property to the Bullet class called active and set it to be true
2. In the move() function for the bullet class, we added a check for the bullet going off the top of the screen (this.y < 0) and, if true, set the active property to false
3. In sketch.js, we moved the lines of code in the draw() function responsible for moving and drawing the bullets into a new function called manageBullets() and called it from draw().
4. In manageBullets() we made a new list called active and put every bullet that was still active into it. We then made this the new bullets list.

We write a little code that printed out the total number of bullets to verify this was working.

Adding an Enemy

We added a new file called enemy.js and included it in the index.html file.

This file looked a lot like player.js. The main different was the move() function. Our enemy moves constantly left-to-right. When it gets too far off the right-hand side of the screen (checked in move()) we set its x position to be off the left-hand side of the screen instead. This makes it loop around.

TODO

We still have loads to do and we made a list on the day:

• No more infinite bullets!
• Check edges so spaceship doesn’t disappear
• Enemies
• Collision detection
• Enemies shoot back (bombs)
• Lives/score
• Levels
• Background music
• Moving background
• Story

We’ve done two and we’ll do some of the others for sure.

Download

The files for this week can be found on our GitHub repository.