SpriteKit Game From Scratch, Swift 2.0, part 1

Swift 2.0
This tutorial will be dedicated to SpriteKit and it’s wonderful capabilities.




As I foresee this to get a little longer I might have to split this up in two or more parts. There are already some tutorials out there, but I have found that most of all are missing some vital things.
They might be useful as a place to start and by all means – do them – if you are new to SK, then as many tutorials you do – the better.
One thing that I find missing in most tutorials out there is that everything is done in the GameScene.swift file , which might work for a very small game, but is far from Apple’s best practices and not very helpful for the performance later on.


The Plan

What we are planning on creating is a simple game – add a Hero character, an Enemy character, have the ability to shoot, add some score and maybe some extra few things.


This is one of the most important things that you need to learn while playing with SpriteKit – Subclassing, and more specifically subclassing from SKNode. In some cases you might be tempted to subclass from SKSpriteNode, but with time you’ll see that it’s always better to subclass from SKNode and then add the desired SKSpriteNode as a child of the SKNode.

If you are new to Swift – please go back and complete some basics, as there are a lot of things I will not explain here. Also it would be nice if you know a little about SK and classes in general.

So, let’s begin by creating a new project in Xcode – for this I am using Xcode 7.1.1 and Swift 2.0

In Xcode go to File-> New -> Project:

After you have created the new project, hit RUN and you should see the default SpriteKit Scene:



So, we’ll leave the Scene as it is for now.


Adding Game Art to the Project

Let’s add some graphics we’ll use for the project, I got the 2 characters from OpenGameArt.org and I just drew up the bullets in Photoshop. Feel free to just right click and download them from here( or create your own), then just drag them into your project:


Protocols and Classes


So instead of creating the hero and the enemy character in the GameScene, we’ll show you how to create a Hero and Enemy class, so whenever you want to spawn one of them you can just call hero() or enemy() .

We’ll go a step further by creating a class CHARACTER that will be a subclass of SKNODE, then HERO and ENEMY can be subclasses of it. For our little game example this might seem as a bit too much work, but it will lay the ground for some good practices later on. This is done in case, because you might have some things that both HERO and ENEMY class share and instead of writing the same methods twice, you can have them in a higher level class. In addition we’ll show you how to add functionality to your subclasses using protocols. The idea with protocols is that you can create one for each feature you want your characters to have – shooting, walking, flying, exploding…and you can just add these features to any character later on, rather than writing the methods again and again, also allowing you to combine them freely.

We’ll start by creating a new document, Cocoa Touch Class, subclass from SKNode ( you could also just create an empty Swift file ):

Name this character.swift, inside we’ll add this:

What we are doing with this ? We are creating a new class ‘character‘ – a subclass of SKNode.
SKNode is probably the most important and powerful class in SK. It’s basically an universal Object, that can have shape, mass, it can interact with other objects, it can be affected by gravity and so on. SKNode does not have a texture on it’s own, meaning it is invisible.

Inside we are just saying that each character will have scorePoints and a size and we are initializing both as : 1 and 50,50. These are just starting values and we’ll change both of them later on. We are also declaring an empty method: die() that we are planning on using later on.

Now let’s create a new swift file and call it protocols. Inside we’ll add this:

We’ll just use this file to declare any protocols we might need later on, plus an extra class for a gun, called Gun.
For now we’ll have two protocols – pTargetable – basically applying this protocol to any class will give it the ability to have health and to take damage. Protocol pWeapon is just a protocol that will be applied to classes ( or the class will conform to it, this is more correctly said … ) that will be weapons ( we’ll just have one for this example.
The class Gun will conform to protocol pWeapon and will have one method ( function ) shoot that will take a target (that needs to be a class, conforming to pTargetable protocol ) and will use the pTargetable function takeDamage and pass 1 as the value.
Simply said: we have one weapon: Gun that can do 1 damage to a any class that is defined as Targetable.


Global Variables and Parameters


Before we go on creating our Hero and Enemy classes we’ll create one more Swift file, called global.swift and add this here:

I prefer this method of having a global file, where you would put everything you need, that should be accessed from classes within your project.
We’ll create 4 textures in order to draw our 2 characters and the 2 projectiles.
We’ll also create a struct that will hold 2 values, describing the zPosition for objects.
zPosition is basically how objects are drawn on top of each other. The higher the zPosition – the more the object is on top ( closer to the viewer ) or drawn later. If you have 2 objects with the same zPosition the one that will appear on top is the one that is called later in code to be drawn. It’s convenient to predefine these into a struct, as later on we can just say we want an object to have a zPosition of layers.background. For 2 layers it might not seem worth, but in most games you will have 5-6 or more layers. Keeping things well labeled helps a lot later on.


Creating the Hero

Now let’s create another swift file and call it hero. Inside hero.swift we’ll put this:

What is to note here:

class hero: character,pTargetable – this means that we are creating a class, called ‘hero‘, which is a subclass of ‘character’ ( a subclass of SKNode ) and conforming it to the pTargetable protocol, as we want our hero to be able to be shot at.
The line super.init() basically loads everything that is built in within the class. We have to call that first before we can declare more or change any of the values.

We’ll use this line: self.physicsBody = SKPhysicsBody(texture: texture, size: size) to create a physics body, the size and shape of the texture we are using. The physics body is later used for interaction with other objects ( in our case with the enemy bullets )
With this function here:

,we are going to be able to take damage. The function takes one parameter: damage and it will call the superclass function die() if hero’s health goes below or equals 0.

Now let’s go to the GameScene.swift file. Comment the Label stuff ( everything in the didMoveToView method ) and change the rest like this:

What we did is – we left the Scene example as Apple created it, but rather then creating the Spaceship on a tap/touch we’ll create an instance of our custom class hero.

Let’s test it – hit RUN and once the app starts tap on the screen:


We’ll just make one small adjustment, obviously our hero is a little too big for our screen, also I want our game to work only in Landscape.Select your project and deselect the Portrait orientation:

Then go to global.swift and add this line:

Then go to hero.swift and change the:


Now test again:



We’ll just leave it at this, ending Part 1.
Go to Part 2

Feel free to comment or ask questions!

9 thoughts on “SpriteKit Game From Scratch, Swift 2.0, part 1

  1. Hey, first of all great Tutorial, it helped me alot.
    But there is a little error, in the protocol you called the health life, bu in the hero class you called it health.
    Besides of that great work

  2. Benjamin Juarez says:

    Working on this now. Thank you! Just wanted to ask, is there a reason why the program picks up 2 nodes for each sprite you put on screen?

    • Razvigor Andreev says:

      Because I like to create characters as a simple node and then add the sprite as a child of the original node. This gives you more flexibility later on, compared to just using SKSpriteNode. It’s also easy to do effects under the ‘top sprite’ , you can add a particle effect to the main node, but under the sprite , like smoke for example.

      • Benjamin Juarez says:

        That’s a new approach in my world. Do you ever run into memory problems if you plan on using several nodes at once, say for a large battle between several spaceships?

        • Not really, I always use that approach, even when I have 50-60 nodes on the screen. What you have to be careful is particle emitters, as they tend to be heavy. Of course if you see any problems you can always tune things up a bit 🙂
          Let me know. Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *