## Data Structures & Algorithms in Dart, First Edition!

Dive into stacks, queues, trees, graphs, efficient sorting and searching algorithms, and more—with Dart, a delightful programming language.

# Scene Kit Tutorial with Swift Part 4: Render Loop

In this 5-part Scene Kit tutorial series, you’ll learn how to make your first 3D iOS game: a game like Fruit Ninja called Geometry Fighter!

Note: This is an abbreviated chapter from the 3D iOS Games by Tutorials, to give you a sneak peek of what’s inside the book, released as part of 3D iOS Games by Tutorials Week. We hope you enjoy!

Welcome back to our Scene Kit Tutorial with Swift series!

This tutorial series will show you how to create your first game with Scene Kit, Apple’s built-in 3D game framework.

In the first part of the series, you learned how to make an empty Scene Kit project as a good starting point.

In the second part of the series, you started making your game, learning about Scene Kit nodes along the way.

In the third part of the series, you learned how to make your geometry move through the power of Scene Kit physics.

In this fourth part of the series, you’ll learn how to make your geometry spawn over time through the Scene Kit render loop.

Let’s dive back in!

Note: This tutorial begins where the previous tutorial left off. If you didn’t follow along, no sweat – you can simply use the starter project for this tutorial.

## Getting Started

In the previous tutorial, you enabled basic physics for your spawned object and applied an impulse to kick it up into the air. Eventually, the object fell back down due to the simulated effect of gravity and disappeared into the abyss.

Although the effect is neat, it would be so much cooler to spawn multiple objects that collide with each other. That would certainly push the excitement factor up a notch!

Right now, your game calls `spawnShape()` just once. To spawn multiple objects you’ll need to call `spawnShape()` repeatedly. Introducing…the Render Loop!

As you learned in previous chapters, Scene Kit renders the contents of your scene using an `SCNView` object. `SCNView` has a `delegate` property that you can set to an object that conforms to the `SCNSceneRendererDelegate` protocol, and `SCNView` will then call methods on that delegate when certain events occur within the animation and rendering process of each frame.

In this way, you can tap into the steps Scene Kit takes to render each frame of a scene. These rendering steps are what make up the render loop.

So – what exactly are these steps? Well, here’s a quick breakdown of the render loop:

Is this Wheel of Fortune? :] No, it’s simply a depiction of the nine steps of the render loop. In a game that runs at 60 fps, these steps run… you guessed it… 60 times a second.

The steps always execute in the following order, which lets you inject your game logic exactly where it’s needed:

1. Update: The view calls `renderer(_: updateAtTime:)` on its delegate. This is a good spot to put basic scene update logic.
2. Execute Actions & Animations: Scene Kit executes all actions and performs all attached animations to the nodes in the scene graph.
3. Did Apply Animations: The view calls its delegate’s `renderer(_: didApplyAnimationsAtTime:)`. At this point, all the nodes in the scene have completed one single frame’s worth of animation, based on the applied actions and animations.
4. Simulates Physics: Scene Kit applies a single step of physics simulation to all the physics bodies in the scene.
5. Did Simulate Physics: The view calls `renderer(_: didSimulatePhysicsAtTime:)` on its delegate. At this point, the physics simulation step has completed, and you can add in any logic dependent on the physics applied above.
6. Evaluates Constraints: Scene Kit evaluates and applies constraints, which are rules you can configure to make Scene Kit automatically adjust the transformation of a node.
7. Will Render Scene: The view calls `renderer(_: willRenderScene: atTime:)` on its delegate. At this point, the view is about to render the scene, so any last minute changes should be performed here.
8. Renders Scene In View: Scene Kit renders the scene in the view.
9. Did Render Scene: The final step is for the view to call its delegate’s `renderer(_: didRenderScene: atTime:)`. This marks the end of one cycle of the render loop; you can put any game logic in here that needs to execute before the process starts anew.

Because the render loop is, well, a loop, it’s the perfect place to call to `spawnShape()` – your job is to decide where to inject the spawn logic.

It’s time to put this cool feature to use in your game.

First, make the `GameViewController` class conform to the `SCNSceneRendererDelegate` protocol by adding the following to the bottom of GameViewController.swift:

```// 1
extension GameViewController: SCNSceneRendererDelegate {
// 2
func renderer(renderer: SCNSceneRenderer, updateAtTime time: NSTimeInterval) {
// 3
spawnShape()
}
}
```

Taking a closer look at the code above:

1. This adds an extension to `GameViewController` for protocol conformance and lets you maintain code protocol methods in separate blocks of code.
2. This adds an implemention of the `renderer(_: updateAtTime:)` protocol method.
3. Finally, you call `spawnShape()` to create a new shape inside the delegate method.

This give you your first hook into Scene Kit’s render loop. Before the view can call this delegate method, it first needs to know that `GameViewController` will act as the delegate for the view.

Do this by adding the following line to the bottom of `setupView()`:

```scnView.delegate = self
```

This sets the `delegate` of the Scene Kit view to `self`. Now the view can call the delegate methods you implement in `GameViewController` when the render loop runs.

Finally, clean up your code a little by removing the single call to `spawnShape()` inside `viewDidLoad()`; it’s no longer needed since you’re calling the function inside the render loop now.

Build and run; unleash the spawning fury of your render loop! :]

The game starts and spawns an insane amount of objects, resulting in a moshpit of colliding objects – awesome! :]

So what’s happening here? Since you’re calling `spawnShape()` in every update step of the render loop, you’ll spawn 60 objects per second – if the device you’re running on can support your game at 60 fps. But less-powerful devices, which includes the simulator, can’t support that frame rate.

As the game runs, you’ll notice a rapid decrease in the frame rate. Not only does the graphics processor have to deal with increasing amounts of geometry, the physics engine has to deal with an increasing number of collisions, which also negatively affects your frame rate.

Things are a bit out of control at the moment, as your game won’t perform terribly well on all devices.

To make the gaming experience consistent across devices, you need to make use of time. No, I don’t mean taking more time to write your game! :] Rather, you need to use the passage of time as the one constant across devices; this lets you animate at a consistent rate, regardless of the frame rate the device can support.

Timers are a common technique in many games. Remember the `updateAtTime` parameter passed into the update delegate method? That parameter represents the current system time. If you monitor this parameter, you can calculate things like the elapsed time of your game, or spawn a new object every three seconds instead of as fast as possible.

Geometry Fighter will use a simple timer to spawn objects at randomly timed interval that any processor should be able to handle.

Add the following property to `GameViewController` below `cameraNode`:

```var spawnTime:NSTimeInterval = 0
```

You’ll use this to determine time interval until you spawn another shape.

To fix the continuous spawning, replace the entire body of `renderer(_: updateAtTime:)` with the following:

```// 1
if time > spawnTime {
spawnShape()

// 2
spawnTime = time + NSTimeInterval(Float.random(min: 0.2, max: 1.5))
}
```

Taking each commented line in turn:

1. You check if `time` (the current system time) is greater than `spawnTime`. If so, spawn a new shape; otherwise, do nothing.
2. After you spawn an object, update `spawnTime` with the next time to spawn a new object. The next spawn time is simply the current time incremented by a random amount. Since `NSTimeInterval` is in seconds, you spawn the next object between 0.2 seconds and 1.5 seconds after the current time.

Build and run; check out the difference your timer makes:

Mesmerizing, eh?

Things look a bit more manageable, and the shapes are spawning randomly. But aren’t you curious about what happens to all those objects after they fall out of sight?

`spawnShape()` continuously adds new child nodes into the scene – but they’re never removed, even after they fall out of sight. Scene Kit does an awesome job of keeping things running smoothly for as long as possible, but that doesn’t mean you can forget about your children. What kind of parent are you?! :]

To run at an optimal performance level and frame rate, you’ll have to remove objects that fall out of sight. And what better place to do this than – that’s right, the render loop! Handy thing, isn’t it?

Once an object reaches the limits of its bounds, you should remove it from the scene.

Add the following to the end of your `GameViewController` class, right below `spawnShape()`:

```func cleanScene() {
// 1
for node in scnScene.rootNode.childNodes {
// 2
if node.presentationNode.position.y < -2 {
// 3
node.removeFromParentNode()
}
}
}
```

Here's what's going on in the code above:

1. Here you simply create a little `for` loop that steps through all available child nodes within the root node of the scene.
2. Since the physics simulation is in play at this point, you can't simply look at the object's position as this reflects the position before the animation started. Scene Kit maintains a copy of the object during the animation and plays it out until the animation is done. It's a strange concept to understand at first, but you'll see how this works before long. To get the actual position of an object while it's animating, you leverage the `presentationNode` property. This is purely read-only: don't attempt to modify any values on this property!
3. This line of code makes an object blink out of existence; it seems cruel to do this to your children, but hey, that's just tough love.

To use your method above, add the following line to call `cleanScene()` just after the `if` statement inside `renderer(_: updatedAtTime:)`:

```cleanScene()
```

There's one last thing to add: by default, Scene Kit enters into a "paused" state if there aren't any animations to play out. To prevent this from happening, you have to enable the `playing` property on your `SCNView` instance.

Add the following line of code to the bottom of `setupView()`:

```scnView.playing = true
```

This forces the Scene Kit view into an endless playing mode.

Build and run; as your objects start to fall, pinch to zoom out and see where they disappear into nothingness:

Objects that fall past the lower y-bound (noted by the red line in the screenshot above), are removed from the scene. That's better than having all those objects lying around the dark recesses of your iPhone. :]

## Where To Go From Here?

Here is the example code from this Scene Kit tutorial with Swift.

At this point, you should keep reading to the fifth and final part of this tutorial series, where you'll add some particle systems and wrap up the game.

If you'd like to learn more, you should check out our book 3D iOS Games by Tutorials. The book teaches you everything you need to know to make 3D iOS games, by making a series of mini-games like this one, including a games like Breakout, Marble Madness, and even Crossy Road.