(For more resources related to this topic, see here.)

A Sprite Kit project consists of things usual to any iOS project. It has the AppDelegate, Storyboard, and ViewController classes. It has the usual structure of any iOS application. However, there are differences in ViewController.view, which has the SKView class in Storyboard.

You will handle everything that is related to Sprite Kit in SKView. This class will render your gameplay elements such as sprites, nodes, backgrounds, and everything else. You can’t draw Sprite Kit elements on other views.

It’s important to understand that Sprite Kit introduces its own coordinate system. In UIkit, the origin (0,0) is located at the top-left corner, whereas Sprite Kit locates the origin at the bottom-left corner. The reason why this is important to understand is because of the fact that all elements will be positioned relative to the new coordinate system. This system originates from OpenGL, which Sprite Kit uses in implementation.

Scenes

An object where you place all of your other objects is the SKScene object. It represents a single collection of objects such as a level in your game. It is like a canvas where you position your Sprite Kit elements. Only one scene at a time is present on SKView. A view knows how to transition between scenes and you can have nice animated transitions. You may have one scene for menus, one for the gameplay scene, and another for the scene that features after the game ends.

If you open your ViewController.m file, you will see how the SKScene object is created in the viewDidLoad method.

Each SKView should have a scene, as all other objects are added to it. The scene and its object form the node tree, which is a hierarchy of all nodes present in the scene.

Open the ERGMyScene.m file. Here, you can find the method where scene initialization and setup take place:

- (id)initWithSize:(CGSize)size

The scene holds the view hierarchy of its nodes and draws all of them. Nodes are very much like UIViews; you can add nodes as children to other nodes, and the parent node will apply its effects to all of its children, effects such as rotation or scaling, which makes working with complex nodes so much easier.

Each node has a position property that is represented by CGPoint in scene coordinates, which is used to set coordinates of the node. Changing this position property also changes the node’s position on the screen.

After you have created a node and set its position, you need to add it to your scene node hierarchy. You can add it either to the scene or to any existing node by calling the addChild: method. You can see this in your test project with the following line:

[self addChild:myLabel];

After the node has been added to a visible node or scene, it will be drawn by the scene in the next iteration of the run loop.

Nodes

The methods that create SKLabelNode are self-explanatory and it is used to represent text in a scene.

The main building block of every scene is SKNode. Most things you can see on the screen of any given Sprite Kit game is probably a result of SKNode.

Node types

There are different node types that serve different purposes:

• SKNode: This is a parent class for different types of nodes
• SKSpriteNode: This is a node that draws textured sprites
• SKLabelNode: This is a node that displays text
• SKShapeNode: This is a node that renders a shape based on a Core Graphics path
• SKEmitterNode: This is a node that creates and renders particles
• SKEffectNode: This is a node that applies a Core Image filter to its children

Each of them has their own initializer methods—you create one, add it to your scene, and it does the job it was assigned to do.

Some node properties and methods that you might find useful are:

• position: This is a CGPoint representing the position of a node in its parent coordinate system.
• zPosition: This is a CGFloat that represents the position of a node on an imaginary Z axis. Nodes with higher zPosition will be over the nodes that have lower zPosition. If nodes have the same zPosition, the ones that were created later will appear on top of those that were created before.
• xScale and yScale: This is a CGFloat that allows you to change the size of any node. The default is 1.0 and setting it to any other value will change the sprite size. It is not recommended, but if you have an image of a certain resolution, scaling it will upscale the image and it will look distorted. Making nodes smaller can lead to other visual artifacts. But if you need quick and easy ways to change the size of your nodes, this property is there.
• name: This is the name of the node that is used to locate it in the node hierarchy. This allows you to be flexible in your scenes as you no longer need to store pointers to your nodes, and also saves you a lot of headache.
• childNodeWithName:(NSString *)name: This finds a child node with the specified name. If there are many nodes with the same name, the first one is returned.
• enumerateChildNodesWithName:usingBlock:: This allows you torun custom code on your nodes. This method is heavily used throughout any Sprite Kit game and can be used for movement, state changing, and other tasks.

Actions

Actions are one of the ways to add life to your game and make things interactive. Actions allow you to perform different things such as moving, rotating, or scaling nodes, playing sounds, and even running your custom code. When the scene processes its nodes, actions that are linked to these nodes are executed.

To create a node, you run a class method on an action that you need, set its properties, and call the runAction: method on your node with action as a parameter.

You may find some actions in the touchesBegan: method in ERGMyScene.m. In this method, you can see that a new node (of the type SKSpriteNode) is created, and then a new action is created and attached to it. This action is embedded into another action that makes it repeat forever, and then a sprite runs the action and you see a rotating sprite on the screen.

To complete the preceding process, it took only five lines, and it is very intuitive. This is one of the Sprite Kit strengths—simplicity and self-documenting code. As you might have noticed, Apple names methods in a simpler way so that you can understand what it does just by reading the method. Try to adhere to the same practice and name your variables and methods so that their function can be understood immediately. Avoid naming objects a or b, use characterSprite or enemyEmitter instead.

There are different action types; here we will list some that you may need in your first project:

• Move actions (moveTo:duration:, moveBy, followPath) are actions that move the node by a specified distance in points
• Rotate actions are actions that rotate your nodes by a certain angle (rotateByAngle:duration:)
• Actions that change node scale over time (scaleBy:duration)
• Actions that combine other actions (sequence: to play actions one after another, and repeatAction: to play an action a certain amount of times or forever)

There are many other actions and you might look up the SKAction class reference if you want to learn more about actions.

Game loop

Unlike UIKit, which is based on events and waits for user input before performing any drawing or interactions, Sprite Kit evaluates all nodes, their interactions, and physics as fast as it can (capped at 60 times per second) and produces results on screen. In the following figure, you can see the way a game loop operates:

First, the scene calls the update:(CFTimeInterval)currentTime method and sends it the time at which this method was invoked. The usual practice is to save the time of the last update and calculate the time that it took from the last update (delta) to the current update to move sprites by a given number of points, by multiplying the velocity of a sprite by delta, so you will get the same movement regardless of FPS. For example, if you want a sprite to move 100 pixels every second, regardless of your game performance, you multiply delta by 100. This way, if it took long to process the scene, your sprite will move slightly further for this frame; if it is processed fast, it will move just a short distance. Either way you get expected results without complex calculations.

After the update is done, the scene evaluates actions, simulates physics, and renders itself on screen. This process repeats itself as soon as it’s finished. This allows for smooth movement and interactions.

You will write the most essential code in the update: method, since it is getting called many times per second and everything on screen happens with the code we write in this method.

You will usually iterate over all objects in your scene and dispatch some job for each to do, such as character moving and bullets disappearing off screen. The update: method is not used in a template project, but it is there if you want to customize it. Let’s see how we can use it to move the Hello, World! label off the screen.

First, find where the label is created in the scene init method, and find this line:

myLabel.text = @"Hello, World!";

Add this code right after it:

myLabel.name = @"theLabel";

Find the update: method; it looks like this:

- (void)update:(CFTimeInterval)currentTime

Insert the following code into it:

    [self enumerateChildNodesWithName:@"theLabel" usingBlock:^(SKNode *node, BOOL *stop) {
       
        node.position = CGPointMake(node.position.x - 2, node.position.y);
        
        if (node.position.x < - node.frame.size.width) {

            node.position = CGPointMake(self.frame.size.width, node.position.y);
        }
    }];

This method first finds the child node with the name “theLabel”, and as we named our label the same, it finds it and gives control to the block inside. The child that it found is a node. If it finds other nodes with the name “theLabel”, it will call the same block on all of them in the order they were found. Inside the block, we change the label position by 2 pixels to the left, keeping the vertical position the same. Then, we do a check, if the position of the label from the left border of the screen is further than the length of the label, we move the label to the right-hand side of the screen. This way, we create a seamless movement that should appear to be coming out of the right-hand side as soon as the label moves off screen.

But if you run the project again, you will notice that the label does not disappear. The label takes a bit longer to disappear and blinks on screen instead of moving gracefully.

There are two problems with our code. The first issue is that the frame is not changing when you rotate the screen, it stays the same even if you rotate the screen. This happens because the scene size is incorrectly calculated at startup. But we will fix that using the following steps:

1. Locate the Endless Runner project root label in the left pane with our files. It says Endless Runner, 2 targets, iOS SDK 7.0 . Select it and select the General pane on the main screen.

   There, find the device orientation and the checkboxes near it. Remove everything but Landscape Left and Landscape Right . We will be making our game in landscape and we don’t need the Portrait mode.

2. Next, locate your ERGViewController.m file. Find the viewDidLoad method. Copy everything after the [super viewDidLoad] call.
3. Make a new method and add the following code:

   - (void) viewWillLayoutSubviews
   {
       // Configure the view.
       [super viewWillLayoutSubviews];
       SKView * skView = (SKView *)self.view;
       skView.showsFPS = YES;
       skView.showsNodeCount = YES;
       
       // Create and configure the scene.
       SKScene * scene = [ERGMyScene sceneWithSize:skView.bounds.size];
       scene.scaleMode = SKSceneScaleModeAspectFill;
       
       // Present the scene.
       [skView presentScene:scene];
   }

4. Let’s see why calculations of frame size are incorrect by default. When the view has finished its load, the viewDidLoad method is getting called, but the view still doesn’t have the correct frame. It is only set to the correct dimensions sometime later and it returns a portrait frame before that time. We fix this issue by setting up the scene after we get the correct frame.

The second problem is the anchoring of the nodes. Unlike UIViews, which are placed on screen using their top-left corner coordinates, SKNodes are getting placed on the screen based on their anchorPoint property. The following figure explains what anchor points are. By default, the anchor point is set at (0.5, 0.5), which means that the sprite position is its center point. This comes in handy when you need to rotate the sprite, as this way it rotates around its center axis.

Imagine that the square in the preceding figure is your sprite. Different anchor points mean that you use these points as the position of the sprite. The anchor point at (0, 0) means that the left-bottom corner of our sprite will be on the position of the sprite itself. If it is at (0.5, 0.5), the center of the sprite will be on the position point. Anchor points go from 0 to 1 and represent the size of the sprite. So, if you make your anchor point (0.5, 0.5), it will be exactly on sprite center.

We might want to use the (0,0) anchor point for our text label.

Summary

In this article, we saw the different parts of the Sprite Kit project, got an idea about various objects such as scenes, nodes, and so on.

Resources for Article :

---

Further resources on this subject:

• Interface Designing for Games in iOS [Article]
• Linking OpenCV to an iOS project [Article]
• Creating a New iOS Social Project [Article]

---