Game Development Reference
In-Depth Information
var moveRightAction = SKAction.moveToX(size.width,
duration: 2.0)
var actionSequence = SKAction.sequence([moveLeftAction,
moveRightAction])
var moveAction
= SKAction.repeatActionForever(actionSequence)
for i in 1...10 {
// new black hole usage code
let blackHoleNode = BlackHole(textureAtlas:
textureAtlas)
blackHoleNode.position = CGPoint(x: size.width
- 80.0, y: 600.0 * CGFloat(i))
blackHoleNode.runAction(moveAction)
foregroundNode!.addChild(blackHoleNode)
}
}
At this point, all of the SKSpriteNode s reuse the same SKTextureAtlas , which
will speed up the retrieval of each of your node's textures.
Externalizing Your Game Data
The next best practice I want to talk about will not necessarily improve the performance
of your game, but it will help during development and testing. So far, all of the positions
of each game node are hard-coded in the SuperSpaceMan Swift code. This is if you are
creating a simple game, with you being both the designer and the developer of the game;
if you have a team with clearly defined roles, you may want to make it possible for a de-
signer or tester to change the play of the game without changing the Swift code. One way
to do this is to externalize the positions of your game nodes.
A simple way to do this in the SuperSpaceMan game is to move the orb and black hole
positions to plist files. You can then load the node positions using an NSBundle . This
will make it possible for a designer or tester to just change a plist to change the layout of
the whole game. An example plist that holds the first three orb node positions is shown
here:
<?xml version="1.0" encoding="UTF-8"?>
Search WWH ::




Custom Search