Contact and Colision Masks

The next thing, is that you need to tell SpriteKit how these objects interact with each other. There are three concepts here: contact, collision and category.

Category

This allows each object to adhere to a type of behaviour; for example, the aliens need to pass through each other, but not through bullets; likewise, if we introduced a different type of alien (maybe a different graphic), it might need the same collision behaviour as the existing ones.

Contact

The idea behind contact is that you get notified when two objects intersect each other; in our case, we’ll need to know when aliens intersect bullets, and when aliens intersect the player.

Collision

Collision deals with what happens when the objects intersect. Unlike contact, this isn’t about getting notified, but the physical interaction. Maybe we have a game where blocks are pushed out of the way – in which case, we might only need collision, but not contact; or, in our case, we don’t have any physical interaction, because contact between two opposing entities results in one of them being removed.

Code

So, the result of all that is that we need three new properties setting for each new object:

didBegin

One this is done, you have access to the didBegin function; which, bizarrely named as it is, is the function that handles contact. Before we actually write any code in here, let’s create a helper method to determine if two nodes have come into contact:

Since the accepted standard for iOS is bad naming, I felt it my duty to continue the tradition. This helper method is effectively all the logic that occurs. As you can see, as we don’t know what has touched what, we have reversed checks and then simply remove the stated item (in our case, that is just a game rule). The didBegin function simply calls this:

In this post, we covered how to move an object on the screen; this time, we’re going to control it. However, before we do, let’s change the game orientation to landscape only, as that’s really the only thing that makes sense on an iPhone for this type of game.

Landscape

The first thing to do is to change the code in the GameViewController to force the orienetation to landscape:

When you run the simulator, the game will now appear on its side; to rectify that, select Hardware -> Rotate Left*:

Control

As you may have noticed from the previous post, we do have a modicum of control over the rectangle; let’s now change that so that we can press to the left and have it move left, or on the right and have it move right.

All we’ve actually done here is to create a new rectangle, and sourced it right at the centre of the player. We’ve added it to the self construct, so the automatic rendering will pick it up; next, we need to move it:

In the first post in this series, I described how to set-up an account and create a very basic program. I also laid out a timeline for getting a very basic game up and running on an iPhone. In this post, I follow on from here where I describe how to run an application in the simulator.

This time, we’re going to create a different type of project and start the game. In the first post, I described the target of this post to make an object move across the screen; we’re actually going to go slightly further and allow a small amount of control.

Create a new Game Project

This time, when we create a new project, we’ll select “Game”:

The next screen is vaguely familiar; for this particular example, we want Swift as the language, and SpriteKit as the game framework:

This should create you a new project that looks something like this:

It also gives you some code… which causes the program to do this out of the box:

Clear Default Game Code

There’s quite a lot of code generated by default in order to create this magnificent application. A lot of it needs deleting; let’s start with the text. In GameScene.sks, select the “Hello, World” text and delete it:

Most of the rest of the code is in GameScene.Swift; you can simply clear that; although, unless your target is to create the exact same game as this series of posts describes, you might want to comment out what’s there, so you can revisit later.

Create Object

The first step to making an object move across the screen is to create an object. Our object is going to be a rectangle:

There are two functions in the code above. ‘createScene()’ establishes the game environment: background colour, physics rules, etc. This, in turns, calls ‘CreatePlayer()’ and adds the result to ‘self’.

A Quick not on `Self`

What is ‘self’? As you can see from the class definition, the GameScene class inherits from SKScene:

class GameScene: SKScene {

In C# terms, ‘self’ translates to ‘this’, so we’re referring to the instance of a class that inherits from SKScene.

We now have a couple of functions to set the game up, but haven’t yet called them; that’s where the didMove event comes in. This fires after the scene is loaded and rendered:

override func didMove(to view: SKView) {
createScene()
}

And we have our box:

Move Game Object

But the target wasn’t just to draw something on the screen, but to move it. Let’s make it move when you touch the screen. First, we’ll need to declare a couple of variables to hold the player object and the speed they are travelling (BTW, there’s a reason the variable is called playerSpeed and not speed – speed is a variable that exists in the SpriteKit namespace – although you wouldn’t know it from the error!):

As far as I can establish, anything inside the SKScene object is automatically rendered each frame by virtue of being there. So, if we were relating this to a C# game engine such as MonoGame, the Draw function is automated.

The purpose of this post is to take the code that we created here and run it in the simulator.

Leaving the Playground

To a .Net programmer, this seems like an alien concept but, depending on the mode that you run Xcode in, it results in a different IDE. If, instead of selecting Plaground, we select “Create an Xcode Project”, the whole app experience changes:

There are a lot more options available now; but let’s stick to the most basic:

The created Single View App should look like this in structure:

The target of this post is simply to take the few lines of code that we wrote in part one, and have them run on a simulator.

The first thing it does is launch the ViewController, so let’s take the code that we created in the first part, and add it directly to the ViewController; the new controller will look like this:

I recently upgraded my iPhone 5c to an SE. Everything seems a little smoother on the SE (although I’d swear blind it gave me an electrical shock while scanning my fingerprint!).

When I upgraded, so that I didn’t lose anything, I simply restored the latest backup from the iCloud account linked to the 5C. However, when I got on the train and tried tethering my laptop to the phone, it failed. In fact, it looked like the WiFi connection to the phone was actually broken, as it kept flashing connected and would then disconnect!

The fix for this turned out to be relatively straightforward, you simply rename the phone: