Game Development Reference
In-Depth Information
Chapter
9
Sprite Kit Best Practices
In the previous chapter, you learned how to implement scene transitions using Sprite Kit's
SKTransition
class. You got a look at some of the different types of built-in transitions
Sprite Kit makes available to you. You also saw how to control each scene's animation dur-
ing a transition. At the end of the chapter, you took your new knowledge and added a menu
scene to your SuperSpaceMan game.
In this chapter, you will learn some Sprite Kit best practices; specifically, you will see how
you can create your own subclasses of
SKSpriteNode
so that you can better reuse your
nodes. You will then move on to changing your game to load all the sprites into a single
texture atlas that you can reference when creating all future sprites. After that, you will
move on to externalizing some of your game data so that designers and testers can change
the game play. Finally, you will close out the chapter when you prune your node tree of all
nodes that have fallen off the bottom of the screen.
Creating Your Own Nodes Through Sub-
classing
The first best practice I want to talk about is refactoring your sprite nodes into their own
classes. Doing this will both clean up your scene code and encapsulate each node's specific
code to its own class.
The three nodes that can be abstracted to their own classes are the player, orb, and black
hole nodes. Before you can start this process, you will need to first create a new file to
share constants. The purpose of this file is to hold all of the collision categories that will be
used across each of the nodes.
Create this new file and name it
SharedConstants.swift
. Once this file is in place,
move all of the collision categories from the
GameScene.swift
file to this file. When
you are finished, your new file should look like
Listing 9-1
.
