[Applause]

Hey, everybody. Welcome, and thank you for coming to our session. My name is Megan Gardner, I'm a software engineer on the games and graphics team and later we will have my colleague, Edwin Iskandar up. We're going to be talking to you about going social with ReplayKit and Game Center.

So we have a few things on the agenda today. First, what's new in Game Center. We have two new things basically guest players as well as our new unified server environment. And then Edwin will get up and talk to you about ReplayKit which is a great new way to add a new social experience to your games and for your users to be able to share those experiences with others.

So what's new in Game Center? Well, what is Game Center? Hopefully you know what it is, especially if you are in this session. It's been around for a while, but just in case you don't, Game Center is our API and app that allows you as developers to add a social experience to your games.

This allows our users to be able to make friends with each other, for you as developers to be able to set up leaderboards for those users to be able to post scores to, that they can then compare against their friends as well as others, for you to be able to define achievements that your users can achieve and we also support everything that you would need to be able to write a realtime or turn-based multiplayer game without having to set up your own servers. And we also support challenges which add a multiplayer element to your single player game.

So, what's new? First up, we have guest players. Currently in Game Center we have two main places that you'll run into players. First is your GKLocalPlayer. You only have one of these per device and it has to be an authenticated Game Center user. You'll also run into GKPlayer as friends of that GKLocalPlayer but more commonly as participants in any sort of multiplayer match whether or not that is real time or turn-based. However with these players, you can only have one player per device. Well, not anymore. Now we have guest players.

So what are guest players? They actually are GKPlayer instances. So you can use them just like you would any other GKPlayer. They do not require authentication, they will be created by you vending us an identifier and then we will give you back a GKPlayer. They are first-class participants in any multiplayer game so you can fill up the rest of the slots in your game with those guest players. You do need to have at least one authenticated GKPlayer but everything else can be those guest players.

What can you use guest players for? They are great for pass and play. Say you want to be able to have an iPad game that you have one player logged into and everybody else wants to be able to play. You can fill up the rest of those slots with these guest players and be able to have a completely local game on that iPad that your users will be able to play and you can treat the game logic in that turn-base game exactly as you would any other game. You can pass messages, you can pass the turn, you can send exchanges just as you would in any other turn-based game.

It's also a really great way to be able to plug in AI players, which will allow you to be able to have the same game logic as you would otherwise but also be able to have your users be able to play against different levels of AI so they can learn how to up their game faster.

So with guest players, as I said before, you are going to be defining the identifier, and that identifier needs to be unique across each game session. So whatever method you end up using, make sure that you are not going to be having any collisions on this identifier. If you have one guest player, on one device and another guest player on another device, just make sure that those aren't going to collide, otherwise your game logic is probably going to have problems.

These guest players can't earn scores or achievements, which makes sense, there's nothing on the server to post them to, but you need to know that. Sessions with guest players are only compatible with sessions with players that are also running iOS 9. Now, this does not lock your game to iOS 9. This only locks those individual sessions with guest players to other users that are running iOS 9.

We try to make this a little bit easier for you, we won't be automatching anyone that won't be able to join that game and if one of your users does extend an invitation to multiplayer game to someone who wouldn't be able to join, we will be auto declining that on the server side on their behalf so you shouldn't run into any issues but it is something you need to be aware of.

Again, this is not locking your game. Everything specified in the compatibility matrix will still work, anyone who is running on an older version of iOS with your game will still work. It's just those individual gameplay sessions. That's guest players. We really hope that this is going to allow you to create new and interesting dynamic ways to add to your multiplayer games and we are really excited to see what you're going to do with it.

Next up, we have the Game Center Sandbox environment. So Sandbox, we created to have a separate environment for you to be able to test out Game Center functionality without being on production. But we had a completely duplicate server, you had to have different accounts and all the exact same data in two places. And this was really great. But we feel that Sandbox has really done its purpose, and now we are going to unify Sandbox with production.

So you will still have two sets of data but it will all be running on the same server. And this gives us a lot of really good benefits, one, this really simplifies your accounts. You no longer have to have a separate Sandbox account that you're going to have to be worried about maintaining, making friends with or dealing with in any way like that.

This is really compatible with TestFlight so you can send your game out on TestFlight for your testers to be able to test with and not have to worry about them setting up Sandbox. Multiplayer will now work against any version that you have published on that server and this is automatic, you don't have to do anything to set this up, we will be flipping the switch on our side.

There are a few things that you do need to be aware of. First, any new game that you will be working on will actually show up in your games list in Game Center. So as you can see here, me and demo-liscious are working on GK tester. And if you were demo-liscious' friend, then you clicked on her profile in the Game Center app, if you clicked on her games list, you would be able to scroll through and see that she was working on that game. If there's a game you really don't want to let anyone know about, we do suggest that you set up a separate account, however, that shouldn't be too much of a problem.

Any scores that you post, while running your game will be posting to the same leaderboards. And iOS 8 users will still actually need to flip that Sandbox switch in settings because we will be automatically errorring out if they are not thinking that they are going into that Sandbox environment. Well, Sandbox doesn't exist so they won't actually be in Sandbox but they will see some of that same UI treatment. But fortunately, everyone on iOS 8 can upgrade to iOS 9, so we just suggest that you do that instead.

So let's go over what this is exactly going to mean for each one of these sections. So leaderboards. All of your versions will be posting to the same leaderboards. However, if you have an update to your game, in which you've added new leaderboards, those leaderboards will only be viewable to you or your testers who are running that version, that updated version of your game. No one else will be able to see those leaderboards, but everything else you will be posting to those same production leaderboards.

Fortunately, everything is iTunes Connect and that is going to allow you to clear the leaderboards before you publish them or to call any scores that you or your testers end up posting either erroneously or in a way that you don't really want to mess up the integrity of your leaderboards. Those are easily clearable through iTunes Connect using your current tools.

For multiplayer, this is a really huge benefit. This is going to allow you to be able to test your updates to your multiplayer games against games that are already out there in the wild in production. Because there's no barrier between the preproduction server and the production server. They are the same server. So you will be able to easily test and make sure that any updates that you are making to your multiplayer games are going to work with whatever is already out there.

For iTunes Connect, you will be maintaining two completely separate sets of metadata that we will be maintaining on the server. You will have your currently released version of your data, as well as the unreleased version of your data. So which set of data that you get, you or your users or your testers is going to depend on the CFBundleVersion of the app that you have installed on that device. So if the CFBundleVersion on your device is greater than the release bundle version that you would get from the App Store, you will be vended the unreleased data.

If the CFBundleVersion that you have on your device is less than or equal to the release bundle version that you would download from the App Store, you will be vended the currently released set of data. If there isn't one on the App Store, then you will just be getting the unreleased data. It's the only data that exists.

So let's go over this again. If you or one of your testers is running a beta version of your game, then that game will be viewable by your Game Center friends in the Game Center app. You will be able to play against any other beta version, that's the only versions out there. You'll be posting to the beta leaderboards, again those are the only leaderboards that exist.

If you or one of your users is running a released version of your game, this is kind of your normal case, you will be able to see the game in Game Center, on your Game Center's friends list. You will be able to play, if it's a multiplayer game, against any version specified in the compatibility matrix and iTunes Connect, including versions that your game would not necessarily know about because that compatibility matrix is stored on the server and the server will know that you can match against those unreleased games.

You will be posting to released leaderboards just like you would expect. If you or one of your testers is running an updated version of your game that has not been pubbished yet that game will still be viewable in Game Center in your Game Center friends list and you will be able to play against any specified version, whether or not it is the older version of your game or the new version of your game that you're testing, anything specified on the compatibility matrix, you will be able to play against.

Then you will be posting to release leaderboards if the leaderboard already exists or you will be posting to an unreleased leaderboard if that is a new leaderboard for that game and those games -- those leaderboards will only be viewable by those people who have that version of your game on their system.

So that's what's new. First was guest players which we really hope is going to expand the multiplayer opportunities that you have for your game, as well as our new unified server environment which is really simple, it's automatic, there's nothing that you need to do to set this up.

It's going to work so much better with TestFlight, which we feel will give you guys a better way to be able to get full functionality testing on your game. And I think that this is really going to just make your guys' life a lot easier. Now I will bring up Edwin and he will tell you about the new framework replay kit. [Applause]

All right. Thank you, Megan. Good afternoon, I'm Edwin Iskandar. I'm a software engineer on the graphics and games team here at Apple and I'm here to talk to you about ReplayKit. So some truly memorable moments happen during gaming, right, like when you finally get those three stars in that seemingly impossible level. Or when you finally beat that last boss without losing a single life point. Wouldn't it be awesome if you could capture and share those moments? So that's where ReplayKit comes in.

ReplayKit records the audio and visuals of your running application. It also allows you to use this to add voice commentary and so they can make their recordings more personal or just to provide additional context. It allows your users to play back, scrub and trim their recordings and finally share their recordings to their favorite social networks and video destination sites. ReplayKit produces high-quality HD recordings that will look great on TV's, websites and mobile devices. And it does this extremely efficiently with a low-performance impact while also minimizing power usage.

ReplayKit includes privacy safeguards that help protect our users and we'll talk a little bit more about these in the next slide. And it's available today in the iOS 9 beta. And later in the fall, to customers when iOS 9 ships. It's available in all A7 and A8-based devices.

Like all of Apple's frameworks ReplayKit takes the users privacy very seriously. So before ReplayKit can start recording, it requires that the user give it permission, and it does this via user consent prompt. ReplayKit also supports parental controls so if you have a device that's often used by a child, you can disable ReplayKit systemwide via settings.

All recordings made via ReplayKit will exclude system UI. That means that any personal notifications that come through, while recording, will be excluded as well as any keyboard entry that happens in game. And finally, applications don't have direct access to the movie files. These are only accessible to the user via ReplayKit's preview UI and share sheet.

All right, so let's take a look at how ReplayKit works by taking a look at its architecture. So your application links to the ReplayKit framework and it uses these two classes, RPScreenRecorder which handles the recording tasks and RPPreviewViewController which is responsible for the preview UI and share sheet.

So RPScreenRecorder communicates with the replay demon which is a separate process from your application. The replay demon communicates with lower level video and audio services which in turn communicate with the hardware to capture the visuals and audio of your application, as well as the audio data from the device microphone.

During capture, the replay demon will encode this data in realtime and write it to a movie file. It will write this movie file to a location only accessible to ReplayKits internal services. How does the user actually interact with that movie then? Well, when you tell RPScreenRecorder to stop recording it vends back an RPPreViewViewController.

And you can simply present it, and RPPreviewViewController hosts the preview and share extension which does have access to the movie and your users can interact with that to preview and share the movie. As you can see, it's a pretty complicated system with a lot of moving parts but thankfully for developers it really just boils down to these two classes. RPScreenRecorder and RPPreviewViewController. Pretty simple. All right, so let's take a deeper look into these classes.

So first up, is RPScreenRecorder. Again, it's responsible for starting, stopping and discarding the recording. It can also be used to check for the ability to record and it can also be used to enable the microphone for commentary. RPScreenRecorder has a delegate that you can set that should conform to the RPScreenRecorder delegate protocol. And this delegate can be used to check for changes in availability, and also how a case is if recording stops due to an error, for example.

For the second class, RPPreviewViewController, again it's responsible for previewing the recording, editing and trimming and fially sharing the movie. RPPreviewViewController also has a delegate that you can set that should conform to the RPPreviewViewControllerDelegate protocol. That can be used to simply dismiss the view controller when the user is done previewing and sharing. That's literally it. There are actually only two classes and two protocols. It's a really compact framework and as you will see adoption is incredibly simple.

So let's take a look at this API in action and I think the best way to do that is to use an example. So the example we are going to use is a game that the sample code team created called DemoBots. You have probably seen this in other sessions.

Just in case you haven't, the premise of DemoBots is that you have this circuit board where these task bots live and the task bots are responsible for keeping the circuit board running but unfortunately all the bots are buggy. It's your job to debug them. So each level in DemoBots takes two to three minutes, so it's short gameplay sessions and you can download the source at developer.Apple.com. You should definitely check it out. It showcases a lot of Apple's new gaming technologies. It's a really great sample.

One of the reasons why we chose DemoBots to showcase ReplayKit is it has this great scene flow that's common to iOS games. Once you launch DemoBots you're treated to a main menu. From the main menu, you can start a game and it transitions you to the game level.

The game level, if you succeed at the game level or fail at it, will transition to a level end scene and from the level end scene, you can either replay the level or go to the next level. So now that we know what the scene flow looks like, let's see how ReplayKit fits in.

Since we know that DemoBots has short game play sessions we will opt for an automatic recording strategy. And what I mean by that is that we want to tell ReplayKit to start recording immediately when the game level starts and we want to tell it to stop recording when the game level ends.

We also want to allow the user to preview and share the recording but we don't want to do this immediately after we stop recording, right? We want to do this when all the action has died down. A perfect place to do that is the level end scene. All right.

Pretty straightforward. So let's step through this. So first up is the main menu. Since we are using that automatic recording strategy, we also want to allow the the user to disable this if they don't want to auto record each level and to do this we have implemented an auto record button on the top right there that the user can use to toggle this behavior on and off.

So let's say a user toggles this on and then presses on the new game button. At this point, we transition to the game level where the actual gameplay happens and we want to tell ReplayKit to start recording. Let's take a look at what that looks like in code.

First things first, we need an instance of RPScreenRecorder. So each application has a shared instance of RPScreenRecorder which can be accessed with the class function; shared recorder. Pretty straight forward. To start recording, we call a start recording with microphone enabled on that shared instance, and here you can specify if you want voice commentary on or off.

You also supply a handle block, and that handle block is supplied an optional NSError. If you receive an error here, you should handle it appropriately. In our case we're just going to pause the game and alert the user and that the recording failed. Once you start the recording with microphone enables, the user is presented with this user consent prompt. And the user at this point has three options. It can choose to record the screen and the microphone to enable voice commentary. They can just record the screen only. Or they can don't allow recording at all.

So this user consent prompt will be displayed everytime you call a start recording with microphone enabled, but once the user has accepted it, it will not be shown again for another eight minutes. Let's say the user now wants to enable voice commenary and also record the screen. So they press on the record screen and microphone button. Okay, at this point ReplayKit starts recording, the game starts and the user is playing, providing voice commentary and whatnot.

And they debug all the task bots at that particular level. At that point, they beat the level and we want to transition to that level end scene. Before we do that, we want to tell ReplayKit to stop recording to do that in code, we simply call stop recording with handler on that shared recorder instance and then that handle block its applied an optional NSError and optional preview view controller.

Again, handle that error appropriately. And for the preview view controller, you have a couple of options. You can either present it immediately or you can hang on to it for later use. So we are going to hang on to it because we don't want to display it just yet. ReplayKit has stopped recording and now we transition to that level end scene. And here we want to allow user to preview and share their movie. We have implemented the play recording button that you see in the top right. The user taps on that.

We want to present that preview UI. To do that in code, we simply call UIViewController, as present view controller animated and we patch in that preview view controller that we held the reference to previously. That brings up replay kit's preview UI where the user can scrub through, trim, and finally share their recordings. Using ReplayKit's share UI. So the share UI is implemented with UI share preview controller so you can even write your own custom sharing extensions in your app, which is pretty cool.

So say the user wants to now share this video to Facebook. They tap on the Facebook button and the Facebook modal shows up, the video is already attached, they can write a custom message and then simply press post and it will show up on their feed. It's that simple for the user to use and also really fun. All right.

So now the video is posted to the users Facebook feed, and they are done sharing and previewing, now they want to cancel and dismiss this preview UI. So remember, we presented the preview UI. So we are also responsible for dismissing it. So to handle dismissal, we simply set preview view controllers delegate and that delegate should conform to RPPreviewViewController delegate protocol and should implement preview controller did finish with get supplied, a preview view controller and you simply call dismiss view controller animated on that preview view controller.

And that's basically it. Just a couple lines of code, we have a basic implementation of ReplayKit in DemoBots, it's really that simple. So just to recap, we went over how to get a shared instance of the recorder, how to stop and start the recorder and how to present and dismiss that preview UI. All right. Now that we have the basics down, let's go into some more advanced topics to really fine tune that ReplayKit implementation.

So first up is verifying availability. So ReplayKit may become available or may be unavailable for a number of reasons. ReplayKit uses the same technologies as AirPlay and TV out to capture its video content. So unfortunately, it cannot be used simultaneously with either of those two services. And as I mentioned before, ReplayKit is supported on A7 and A8 based devices. Any older devices, ReplayKit will not be available.

To check for availability, you simply query the available property and RPScreenRecorder. And what do you do if it's not available? Well, you simply discard any recording UI in your game or app. Since availability can change in realtime, you can also implement RPScreenRecorder delegate screen recorder to change the availability to listen for changes in availability.

Quick example, remember the auto record toggle that we had in DemoBots? If ReplayKits not even available on the device, we don't want to show that toggle, right? We query that available property in RPScreenRecorder and use that to drive the visibility of the recording toggle button. Simple. All right, next up is discarding the recording.

So ReplayKit automatically discards the previous recording when a new recording starts. So currently there can only be one recording at a time per application. But there are cases where you know that the user no longer will have access to the preview UI. So you probably want to discard it earlier.

So in our example with DemoBots, if the user transitions from the level end scene, you know they're not going to be able to preview the video anymore so you should probably discard it. To do that in code, in our particular example, and I will transition to the next level scene -- next method, we simply call discard recording with handler and once that returns, we transition to the next level.

Next up is recording indicators. So when ReplayKit is recording, you probably want to notify the user that recording is happening and also if voice commentary is on or off. So to implement this, you can simply query the recording and the microphone enable properties in RPScreenRecorder and use the values of those to toggle the visibility of your recording indicators. Again, pretty straightforward.

So next up is excluding UI. So there's certain elements in a game that are really useful for users, but pretty uninteresting to spectators, right? We just talked about one of those. Recording indicators. They are great for the user to know, but for a spectator, they are pretty useless. They know that the recording is on and voice commentary is on because they are watching the video, right? So you probably want to exclude those.

A couple more examples of virtual controls and pause and menu buttons. These may clutter up the recordings and not be necessary for spectators. How do you exclude UI from the ReplayKit? So ReplayKit only records your applications main UI window. If you want to exclude any UI, you simply create a new instance of UI window and place any elements you want hidden in that new instance. That's excluding UI.

Next up is choosing when to record. So if you remember in DemoBots, we know that DemoBots has short game play sessions lasting only two or three minutes. So we went for an automatic recording strategy where we automatically record each game level. But some games are different, right? For example, in RPG, there's longer gameplay sessions, it might have more spread out interesting events, but it really doesn't make sense to record the entire session. Instead you should give the user the ability to start and stop recording at will. To do this, you simply build your own recording controls that allow users to do that.

Again, all games are different. So you should just choose what is appropriate for your particular game type. All right, so that actually concludes the fine tuning session as well. So we went over how to verify availability, how to discard the recording, how to show the indicator, how to exclude any UI, and also choosing the best recording strategy for your game.

Now, we would like to show you a demo. So a couple of weeks ago, we invited Spacetime Studios over to Cupertino to check out ReplayKit and try to adopt it into the upcoming game, Call of Champions. So I'd like to welcome up on stage Cinco Barnes from Spacetime Studios to share his experiences with us. Please welcome Cinco. [Applause]

CINCO BARNES: Thanks, Edwin. I'm Cinco Barnes. I founded Spacetime Studios with my partners back in 2005. Our purpose was to make hard core PC games but all of that went out of the window in 2009 with iOS and the first iPad and our release of Pocket Legends. Since then we have been dedicated to the iOS platform for gaming and it's been fantastic.

Today I get to talk to you about Call of Champions as a case for ReplayKit. I definitely want to talk to you about how it affects the game itself but the big message is how this builds community, specifically for us as a community of gamers, active gamers into something like this. I want to give you a little bit of history on who we are in some context.

Spacetime Studios has always endeavored to take core games, distill them and adapt them into our mobile gaming lifestyle. It's the way that we found our voice in trying to provide things that are both immediately accessible and things that are strategically rich. And our next product here is Call of Champions.

Call of Champions is a mobile battle arena. It's a three-on-three team game, its got a neat Rugby-inspired lane mechanic, it's got shooter style power ups in the middle. The main thing is it's squeezed into a five-minute segment like a mixed martial arts fight. We worked really hard to load those five minutes with all of the different choices and all the different strategies that we know that our audience loves to play. But we also know that the audience that's attracted to these kinds of games doesn't just enjoy playing them.

They love to watch them. They love to watch live games. One of the things that we did also was include a spectator mode for watching just that, live games anywhere around the world. And on its own this satisfies our side of it. But then we also know how people would love to record and share this as part of the energy of creating that community of gamers and that's where ReplayKit comes in.

Here's an example of a replay that I'm sharing with you. As a designer of a game like this, I've got some top level programmers that are beating the heck out of me and my partners and I really want to show off the features that we have in spectator and replays allows me to do that here in this context.

There's tons of cool stuff going on inside of this but the addition of my commentary and the presentation of this in a shared environment is really what ReplayKit is all about. I mean, we see how this works really well for a game like Call of Champions, but it's our position that it would work for anyone who is actively trying to foster a community in today's media-rich market.

That's an excellent shot right there. A skill shot, by the way and a professional gamer, killing my partner by setting him on fire. And capturing these moments and being able to share them from the tail end of a game that was important to me is exactly the spirit of all of this.

So when I think about ReplayKit, I see it as a crazy powerful means to address this community and to embrace the fact that we are all playing, we are all sharing and being able to bring this stuff to a game like Call of Champions was really easy for us. The implementation took us, well we have one guy, Rick, and he did it in a day. So no excuses. It's spectacular! That's what I have to say about it. Thank you very much for your time. Edwin, I'm taking it back to you. [Applause]

Thank you, Cinco. That was awesome. So unfortunately that concludes our session, what's new in social gaming. Just to recap, Megan talked to us about the changes made at Game Center, like adding guest players which allow for new player configuration and Game Center multiplayer. She also talked about how we streamline development, and testing of Game Center games by unifying the server environments and removing that Game Center Sandbox.

And we introduced ReplayKit, a whole new way to add social into your games and it allows you to record audio and visuals in your running application and it does it efficiently and it has privacy safeguards for the users. As you have seen, it's an incredibly compact framework and has incredibly simple adoption.

For more information, go to developer.Apple.com and refer to the documentation or contact Alan Schaffer our game technologies evangelist. I urge you to download the iOS 9 data, check out ReplayKit, get it into your games, bring them to the labs and show us what you've got. That's it for me. Thank you so much for attending. I hope you enjoy the rest of your WWDC experience. Thank you. [Applause]