[MUSIC] It's time to turn our attention to SpriteKit now. SpriteKit's one of the frameworks that you use for making games. And the approach to using it in the process of making apps is different than the way we use UI kit up till now. Not a complete 180 but it's got some pretty significant differences that we'll try and cover at some level in the rest of this course. So at high-level what SpriteKit is used for is to make two dimensional games. So you should think games that perhaps are aerial, and you see an aerial board, or side scroller games. Things like Super Mario Brothers, classic Super Mario Brothers, classic arcade games, maybe. And then if you want to make other kinds of games, there are other frameworks that you use. But SpriteKit is for two-dimensional games. So iOS actually has four different built in frameworks for graphics. They're all primarily geared towards games. But Sam and I had some discussion about this as we were preparing this lecture. And it was important that as part of that discussion, one of the things we've talked about is the fact that games aren't necessarily graphical. SpriteKit is a very graphics heavy environment. A sprite is a two-dimensional graphic that SpriteKit can manipulate efficiently across the device's user interface. But just because you're doing something that has heavy graphics doesn't necessarily mean that it's a game. There are scientific visualization applications. There may be more mundane kind of office work that are better implemented in a graphical context. Similarly, there are lots of games that aren't necessarily graphical. There are all kinds of things you can play that aren't heavy graphics. Nonetheless, there are four different built-in frameworks for graphics that iOS offers. In addition to these built in frameworks, there are third parties that have graphics frameworks that are compatible with iOS. Unity being one that comes to mind. But that's a third party environment that compiles games into an iOS app for you. So the four that are available as of now are all based on OpenGL, and OpenGL is a technology for doing two-dimensional and three-dimensional graphics. It's very low level, it's the most primitive access to the graphics rendering pipeline that you have available to you. And all the other frameworks are built on top of this core. OpenGL has been around for a long time and it's very fast and it's been efficiently implemented on many platforms. The next level up is a interface in API that Apple's created called Metal. And the goal of Metal was so efficiently unify access to both OpenGL substrate and the Graphic Processing Unit that are on many of the platforms that iOS works with. The idea was to unify them and put them together in such a way that it was easier to work with an OpenGL and GPU accessed separately. But has a more unified interaction. You work with it through an API that's more slightly higher level, but that's still efficient. On top of OpenGL, SpriteKit is implemented. SpriteKit, like I said, is a two-dimensional game engine that has support are for physics engines and effects, lot of support for physics engines in it. And then finally, the fourth framework that's available, SceneKit. And SceneKit is like SpriteKit, but it's geared towards three dimensional games. So things like first-person shooter games, exploration games, things, maybe like Minecraft or environments that you are moving through rather than a side scroller kind of game. So those are the four that are available. We're going to focus in on this specialization and this course on SpriteKit. So SpriteKit Project you start the same way you start a project that we've done previously with UI Kit, but instead you specify a game and then you're given an option to pick which of the frameworks you want to work with. When your template gets built, you'll see a bunch of files, as indicated there on the right, your right. So up, I guess up there. And it has several files that look familiar. For example, AppDelegate. AppDelegate is the code shell that contains all of the functionality for the application, just like a UIKit project. You'll also notice that there's a main storyboard and a launch screen storyboard. There's an assets folder and then there are a couple of other files there that aren't quite as familiar. Like the UIKit the apps user interface is still built on a view controller, only this time rather than using a navigation view controller or one of the other kinds of view controllers that we've seen previously we're going to use one called a GameViewController. And that GameViewController gets built into the template for you, as you can see here in the hierarchy. GameViewController inherits from ViewController in the same way that the other ViewControllers that we've seen inherit from ViewController. So it's kind of unified up until that point. However, within the GameViewController, things start to look pretty different. The GameViewController is basically a container that holds different scenes. And scenes are environments that you partially build in an Xcode GUI and you partially build through programmatic interface to it. So you write code that changes the scene and you can create the scene in a what you see is what you get interface in Xcode. These scenes become basically the playing board or the playing environment in which your game is built. And a game might have one or many different scenes that get shown at different points during life cycle of the game. So the SpriteKit architecture for a game. If we just saw the file hierarchy. This is kind of what it looks like abstractly, in terms of the layout. You have a container which is your application. And so, for example, we're going to demo a Pong game, kind of a digital tennis game. That would be the name of our application. Within that application we have something that inherits from UIViewController, just like we always have. That's going to be our root view and in our case that root view is going to be a class type GameViewController that inherits from UIViewController. A GameViewController has within it an SKView or a SpriteKit View. And that SpriteKit view is something that's specifically part of GameViewController it's not inherited from any Kernels, and so that view is within the GameViewController class. Each SKView takes a various VSKView the view associated with the ViewController at various times will show different scene and so a given scene will inherit from the SKScene class. And so, in the template that we saw previously, GameScene is an example of an SKScene descendant that implements a scene. And then within the scene, you go about all the components of your game. So here is a Pong, you got a blue paddle and a red paddle, and this orange-yellow box bouncing back and forth between them like a tennis match. So that's a basic architecture and layout to try and give you some understanding on how these things are packaged and how they refer to each other. All right, the flow of a SpriteKit game is very robust. It's, and here's another point where Sam and I had a bit of discussion. I wanted to say that SpriteKit was a very event driven architecture. I was contrasting that perhaps to a programming environment like processing, if you're familiar with processing. In processing, when you do graphical user interactions user experiences, it's very frame based. Every time a frame gets shown to the user, you as the developer have to change the environment that's being presented. Graphically change things, frame by frame by frame. So you have to keep track of interpolating, you have to keep track of where things should be shown. At frame 0, at frame 10 and frame 30, at every frame your code gets called. That can happen in SpriteKit. There are ways in which you can run code every time a frame is generated within the animation sequence, or animation you can think of as being a sequence of frames being shown to a user over and over again like a movie. It has a sequence of stills that are shown very quickly to I give the impression of motion. And so while you can do execution and while you can run code on every frame update within SpriteKit, there's a lot of support for giving the control of events over to SpriteKit. And you say what kind of event you're interested in and then you can run code only, or it's possible to run code in response to events. So the discussion that Sam and I are having is whether or not SpriteKit is primarily event-driven or is partially event-driven. So we decided that the best way to describe it would be that it has a robust event-driven architecture. Some of the events that you can respond to when you're not executing things on a frame by frame basis is, for example, collisions. Collisions of objects in your environment. You can set things in motion and then ask for SpriteKit to tell you when a collision happens. And then you can do some action to respond to the collision. You can respond to touches. That's very similar to UIKit a touch becomes an event that you can respond to or do something when it happens, and until it happens you just let the environment run. You might respond to timers. So after a given amount of time, or after you've done something for a period of time, you might want to execute some code. So that's responding to events. On the other side, you can initiate actions. And actions are things that you give to the SpriteKit engine that it is going to manage the execution of. For example, you might put an action into the environment to render an explosion. You might put an action into the environment to create a new object that's interacting with the world. You might create an action that plays a sound. And all those things will get executed and timed by SpriteKit, so you don't have to manage it on a frame by frame basis, although you can also ask for your code to be run on completion of those actions. So you can say, run this two second sound for me, and when it's done let me know, so I can make a good interaction at the end of that sound. So those are kind of two ways that SpriteKit operates. Frame by frame, or in responses to events. A given SpriteKit game probably is going to have multiple scenes. At least a well developed one. You might have different scenes for different game levels. For example, different levels in Super Mario Brothers or different. I don't know. Different, you know? If you play Candy Crush, each one of the Candy Crush levels is a different scene. You might have a high score screen which is implemented as a separate scene. You might have a game over or victory screen which is implemented as its own scene. You might have a settings scene in which you turn up the volume or turn off the volume. Or enter your username and password for some web based interaction. Each scene, as we drill down from application through view controller into the scene, each scene within it has a hierarchy of objects that are being shown on the screen at a given moment. You can think of this like a document object model in HTML. Or the way in which UIKit structured its elements as a hierarchy of elements that are shown, for example containers and sliders and labels all being arranged hierarchically. Each scene manages its node hierarchy and each node in the hierarchy is and inherits from an SKNode type. So, for example, a paddle in Pong, or a ball that's bouncing around, an enemy in some sort of game, an explosion. Each one of those things are probably represented either as an SKNode on its own, somewhere within a tree of SKNodes, or it is itself a sub-tree that's embedded in a tree. But basically, at what SpriteKit is doing is rendering one overall tree and the elements of the tree have their state change that, end up rendering differently on the screen. So, one thing that's different about this tree than the UI kit tree is the SpriteKit tree doesn't correspond so directly to the visual layout of the screen the way it does in UIKit. SpriteKit is responsible for presenting this hierarchy. So you create it partially through the what you see is what you get editor, and partially through code in which you add and remove elements SpriteKit will render it visually. It will go through all the elements of the tree, decide where and how it should be rendered and it will render it for you. Additionally, these different elements in your node hierarchy may also be participating in the physics simulation. And SpriteKit will also execute that physics engine, you could say it's rendering the physics engine as well. I'm paying attention to things and they're moving, their velocity, their rotation, how they are colliding. The results of the collisions. That same hierarchy is used both the visual rendering and the physics engine. So as a result the SKNodes in the hierarchy, each one of the elements in the hierarchy, can be modified either by the developer code or the physics engine will also change the nodes in this hierarchy as they move and primarily they change the state of a node and how they're moving and what their mass and orientation are. It's important to realize that when you change a node in the hierarchy, you're also changing all of the descendents as well. So if you move a node in the hierarchy, a child's position all the children move too. Because everything in a child, everything almost everything associated with a child is related to its parents. So if you move the parent, all the children move. If you rotate a parent, all the children rotate as well. If you visually change the presentation of a parent, the visual presentation of all the children are filtered as well, if you filter the visual presentation. The idea here is, for example, if you are rendering a body and you want to move the body, you might structure the nodes such that they correspond to the limbs. So that hand is a child of the elbow is a child of the shoulder. And that way, as you rotate the shoulder, all of the child elements below it rotate. But if you rotate the hand, none of the elements above it will rotate. And then hat way you can create easily manipulated objects within your note hierarchy. So what I'd like to do is I'd like to build this simple pong game, where we go end-to-end and create an example of a game. There'll be two paddles on either side, and a ball that bounces between them. We'll utilize the physics engine, and we'll respond to user touches. But, a lot like the very first app we wrote in this specialization, way back in course number one, this is kind of like the Hello World of games. And so, I'm going to go through and build it and I'm not going to explain everything that I do along the way. But I want to give you, the students that are taking the course, the opportunity to see all the different pieces that are in play so that as we go through them in more detail individually, you'll understand how they're structured ultimately. All right, so this pong game will be our next step and then we'll slow it down a little bit and talk about each of the pieces in turn. Okay, thanks for your attention. Thanks for your attention but in summary SpriteKit is a 2D game engine that has built-in support for physics engines. Still thank you for your attention. [MUSIC]
