[MUSIC] We would like to give you a project overview in this lecture about what we anticipate you're going to be doing going forward and how you can meet the requirements of this capstone project. From the beginning, so we make sure that this is a successful experience. I want to go over a few of the issues that we're going to be grading you on, and we're going to start just by motivating this thing that you've been studying for a long time in this iOS specialization. You've been learning a lot of different tools in the tool bag of your iOS knowledge. Different technologies, different constructions, different small apps, and now what we want to do is we want to put it all together. We want to do that by recognizing though. That mobile devices, iOS devices, they're very uniquely physical. They're things that exist in the world that we carry with us that are very intimate devices. We use them when we're on the go. We use them when we're at home. We use them when we're studying. We use them when we're playing. We use them when we're working. All kinds of times we use our devices. We also played games everywhere. The games aren't all very elaborate, immersive games, but they're quick games. They're games that we play while we're waiting for a bus, while we're waiting in the line, while we're waiting in the car. Fill up those empty moments, and we can combine those two things. We can make our device physical, and we can make our games physical, and that's kind of the motivation for this assignment. Let's see if we can take all the things that we've learned and make a game that includes some physical element of where the device is or how the device is oriented. That's what we'd like to work with. So we're calling this a trans-reality game. And the reason why we're calling it trans-reality game is because there is both a digital reality of the world that's existing within your device. And then there's a physical reality outside of that device. So a trans-reality game using this kind of an idea is a game that uses something about the physical world to affect the digital world. So that could be the device orientation changes something in the game layout, the environment outside of the device for example the light changes something on the gameplay of the phone. Or maybe, where the device is in the world. Unlocks, opens up, or enables different aspects of the game that you're playing in the digital world. So, we're crossing over between these two worlds by leveraging the devices, and the embodiment of this iOS device out in the world. You'll have a lot of flexibility in this. We don't have very strictly prescribed rules for what this is going to look like. You're not all going to be doing the exact same thing. This is a capstone project that is really something that we hope that you're going to be the ones who are designing it. That you're going to be the ones who are coding it but this is something that you want to do. You get to pick something that you want to do and that ultimately that this is something that's fun to play, both for other people and maybe for yourself. So, there's a lot of flexibility and a lot of creativity and a lot of opportunity for doing something that you like. Now, that said however, creativity always thrives with constraints. And we want to put some boundaries around what you have the opportunity to make, so that we have a fairly common experience with the students in the class, but also that we can really let the skills that you've learned up till now shine. So overall we've got 12 requirements, or 12 constraints, for this capstone project. Let's walk through them. The first one is that the game has to utilize SpriteKit and UIKit. And therefore it has to be a 2D game. You may be familiar with other kinds of games in which you're in an immersive 3D world and walking through the world. We want to limit this game to being in a 2D environment leveraging SpriteKit which are the things that we've taught and that you've learned over the course of this specialization. Secondly this game must be an avatar-based game. So an avatar based game is a game in which the controller, the player who is playing the game, controls some character or some object in the game, which is the focal point of making the game work. So, a game like Super Mario Brothers, a pretty famous, classic game Is an avatar-based game. The avatar is the Super Mario character that's maneuvering through the world. Another game, for example, Settlers of Catan, or Chess. Those are games that can be very fun. They're not avatar-based games, they're a different kind of game, and that's not the type of game we want you to create. Want you create a game in which there is an avatar that's central to the play. And which the player of the game is controlling. Thirdly, the game's gotta have a clear goal for the player who's controlling that avatar. It's gotta be designed into the game that there's something that you're trying to reach, maybe a quest. Maybe accomplishing several different levels, maybe just trying to achieve the highest score possible but there's got to be some kind of clear goal for what the player is trying to achieve. Fourth, the game has to use the iOS physics engine. You've a lot of flexibility of how you want to do that, whether you want to do that with collisions, or vortex fields, or gravity. Maybe with joints in two objects that are being simulated by the physics engine. Whatever you would like to do, that's possible, but you need to make sure that you use the physics engine. And with all these things, ultimately, you're going to need to make sure you communicate how you did those things to all the people who are evaluating you. The fifth thing is you need to use a particle emitter. A particle emitter can be used to create smoke or explosions, magic, water, snow, rain. A lot of different things. Somewhere in your game you need to use a particle emitter as a special effect. Sixth, your game has to play sounds. And we want you to play two different kinds of sounds. We want one of the sounds to be a long form sound, like a background music track maybe, that's playing. Maybe it's a long one that plays on repeat when it's done. And we also want you to use short form sounds or sound effects that are reactionary to things that happen in the game, explosion noises, bounce noises, jumping noises, things like that. Seventh, we want you to use at least one physical sensor in the mechanics of your game, and this is what's going to make the game trans reality. So that sensor can be the compass, the magnetometer, it can be the accelorametor built into your device, it can be the light reading, it can even be the GPS reading. Now some of you who are taking this class may not have a physical iOS device, you may only be working with. The sensor, when you may only be working with the simulator. If that's your case, you're only working with the simulator. It's difficult to design a game for some of the sensors. For example, the accelerometer. Because out-of-the-box, the simulator doesn't support simulating the accelerometer reading. So for you, if you're doing an iOS game only through the simulator, you will need to use location as your sensor because you can put location into the simulator, we've shown you how to do that, and so you'll need to make sure that your game mechanics leverage location and that you can then demonstrate location being used by simulating it as well. Okay, so those are some of your options. All right, eighth requirement is you must have multiple views in your game. And so this is the basic skeleton of what we would assume to be meet the requirements. You can go beyond this, of course, but basically, you're going to have an entry screen where the user has the ability to start the game. You're going to have a preferences screen where a user can set some preferences. You're going to have the primary game scene where the gameplay happens and then you're going to have two different conclusion screens. Two different conclusion view controllers. One which indicates the game has been won. One which indicates the game has been lost. Or some other way of indicating how you ended the game, depending on the nature of your game. Maybe it's not a game that you win or lose, but maybe it's a game that you make progress in, for example. This is the basic skeleton, though. We want to make sure that you have multiple views in your game to leverage the things that you've learned. Ninth, you need to have some achievements. And we're asking you to have five or more achievements over the course of your game. I was going to require you to leverage mechanisms or design in your own, as well as design your game in such a way that there are five achievements that you can think of. And that there are five different achievements that you can keep track of your game. Tenth, your game has to have a preferences screen. Your preference screen has to, at the minimum, enable the user to turn on and off sounds, it has to enable the user to reset achievements across the game, and it has to have one other preference of your choice that somehow affects the game or the environment in which your game is being performed. 11th, the game must not violate any copyright protected intellectual property. And by this we mean, you can't use visual assets, you can't use art, you can't use sounds and you can't use code that belong to other people. You need to either make sure that you have the rights to use those things or you need to create them yourself. That's to make sure that you don't get yourself into any trouble by using someone else's property in your game and then finding yourself at the end of some kind of a conflict resolution process, just because you were trying to complete this course. Finally, the 12th requirement is, this game should be fun. We want it to be something that you enjoy playing, something that you thought of that you think is creative. There's a whole wide range of ways in which games can be fun but ultimately that's what we're looking for, something that you are looking forward to and are going to have a good time playing. All right, so in summary, that's our project. Those are the boundaries around which we want your creativity to thrive. It's an open-ended capstone project in that sense. The whole thing's going to take eight weeks and it's going to involve seven development milestones. Each week is associated with one milestone and then the final week is going to be when you review all of the other people in your cohorts' games that they've created over the previous seven weeks. All right, we're looking forward to seeing what creativity comes out of this course. Thanks. [MUSIC]
