Sprite Kit Best Practices

          To get the most out of Sprite Kit, you need to know:

• How to organize your game into scenes and transitions.
• When to subclass Sprite Kit classes.
• How to store your game’s data and art.
• How to use build your own tools to create Sprite Kit content and export that content for your game to use.

      Organize Game Content into Scenes

      Scenes do not have a default behavior, like storyboards do in a traditional iOS app. Instead,  you define and  implement the behaviors for scenes. These behaviors include:

• When new scenes are created.
• The contents of each scene.
• When transitions occur between scenes.
• The visual effect used to perform a transition.
• How data is transferred from one scene to another.

Allow Your Scene Designs to Evolve

• In simple games, the project is simple enough that all of the code can live in a single class.
• The second stage of a project usually happens when the rendering or game logic starts getting longer or more complex. At this stage, you usually start breaking out specific behaviors and implementing them in other classes.
• In the most sophisticated projects, artificial intelligence and other concepts become more important. In these designs, you may end up creating classes that work independently of Sprite Kit.

 Limit the Tree’s Contents to Improve Performance

        When Sprite Kit renders a frame, it culls all of the nodes that are not visible on screen.

• Typically, a node needs to be part of the node tree because:
• It has a reasonably good chance of being rendered in the near future.
• The node runs actions that are required for accurate gameplay.
• The node has a physics body that is required for accurate gameplay.

       When a node does not meet any of these requirements, it is usually better to remove it from the tree,  particularly    if it has many children of its own.

     What Shouldn’t Be in a Scene       

• The content or app logic is shared by multiple scenes.
• The content or app logic is particularly expensive to set up and only needs to be performed once

     Use Subclassing to Create Your Own Node Behaviors

• All of the standard node classes support the NSCopying and NSCoding protocols. If your subclass adds new properties or instance variables, then your subclass should also implement these behaviors. This support is essential if you plan to copy nodes within your game or use archiving to build your own game tools.
• Although nodes are similar to views, you cannot add new drawing behavior to a node class. You must work through the node’s existing methods and properties. This means either controlling a node’s own properties (such as changing a sprite’s texture) or adding additional nodes and controlling their behavior. In either case, you need to consider how your class is going to interact with other parts of your code. You may need to establish your own calling conventions to avoid subtle rendering bugs. For example, one common convention is to avoid adding children to a node object that creates and manages its own child nodes.
• In many cases, expect to add methods that can be called during the scene’s pre-processing and post-processing steps. Your scene coordinates these steps, but focused node subclasses perform the work.
• If you want to implement event handling in a node class, you must implement separate event-handling code for iOS and OS X. The SKNode class inherits from NSResponder on OS X and UIResponder on iOS.
• In some game designs, you can rely on the fact that a particular combination of classes is always going to be used together in a specific scene. In other designs, you may want to create classes that can be used in multiple scenes. The more important reuse is to your design, the more time you should spend designing clean interfaces for objects to interact with each other. When two classes are dependent on each other, use delegation to break that dependency. Most often, you do this by defining a delegate on your node and a protocol for delegates to implement. Your scene (or another node, such as the node’s parent) implements this protocol. Your node class can then be reused in multiple scenes, without needing to know the scene’s class.

      Working with Game Data

•  The best place to store game data depends on where that data is used within your game.
• Store a game level as an archive of a scene node. This archive includes the scene, all of its descendants in the node tree, and all of their connected physics bodies, joints, and actions.
• Store individual archives for specific preconfigured nodes, such a node for each monster. Then, when a new monster needs to be created, you load it from the archive.
• Store saved games as a scene archive.
• Build your own tools to create and edit archived content. Then, your game designers and artists can work within these tools to create game objects and archive them using a format that your game reads. Your game engine and your tools would share common classes.
• You could store Sprite Kit data in a property list. Your game loads the property list and uses it to create game assets.

Gopinath T B,

CEO, Meteora Gaming