Hello. Welcome to part two of iOS games. Working on game design. My name's Graeme Devine. Gonna be talking today about game design on iOS. Just quickly, how many of you are iOS game people out there and have apps in the store? That's absolutely awesome. It's most of you. Wow.

Well, in part one, we kind of went over the secret sauce to a whole bunch of iOS technologies. You know, how Game Center works and how the new turn-by-turn gaming API lets you make these turn-by-turn games, which are absolutely, you know, gonna, I think, really change the way that we approach games on iOS.

Nate talked about the cloud and how to sync up to the cloud and how we can share between multiple devices the preferences of our application and storing them there and then bringing them back down and the code to do that with the short notification thing. Talked about GL kits and how easy it is to load textures. And apply effects and do math and to set up a render loop and make those things much easier than they've been before.

And finally, talked about AirPlay and how wonderful AirPlay is that, you know, it's so easy to set up a second display now from our iPad 2 and broadcast that onto our HDTV. I think that's really gonna massively change games and we'll talk about how some of those game design, about some of that game design later on in the talk today.

So, as Nate said, it really is a fantastic time to be making games for iOS. I mean, wow! You know, we are a long way from that first generation iPhone. We have graphic systems which are so much more powerful now than they were on that first phone. The iPad 2 is an incredibly powerful device. It's just, I think it's the best gaming device on the planet by far. The SDK has changed. We have new and powerful technologies like Game Center with 50 million people online, you know, wanting to play games and the ability to build that right into our applications.

Most fantastic though, I say fantastic a lot by the way, I'm like Doctor Who that way, games themselves are also evolving. Games have really changed from the first games we put on the phone to the games we're presenting today. We're kind of still learning our way about how to design the best of breed games for iOS. So, we're gonna take a look at some of those games and what they're doing in terms of game design and what I think, you know, really makes the best of breed game.

So today we're going to talk about 10 ideas for making games great. And we're going to go through each of those 10 ideas, and hopefully by the end of it, you'll know a little bit more about making games for iOS. Let's talk about number one: design to the platform.

What do I mean by that? I mean, we've been making games for a long time. There's a lot of game developers out there who have made console games, and console games are absolutely fantastic. They have controllers, and the controller has buttons, and the buttons do things on the screen.

And I'm looking at the screen, and my hands aren't looking at the controller, and a typical controller now has, you know, 10, 20 buttons on it that do different things. And, you know, we have to design games that reflect that. Game design has to reflect the fact that it has a controller. Whereas on iOS, we've only got one thing. We've got a finger that touches glass.

And there's a huge expectation amongst players there that as soon as they, as soon as their finger goes out and touches glass, that something's going to happen. Hopefully something magical. And so, there's a very different approach to game design, and we need to be thinking about that approach to game design right from the very first thought about our new games. It needs to think about that actual difference.

In reality, because we're also holding these devices, we are holding the entire world of our games in our hands. And that's a very powerful kind of metaphor. If you think about the console games, they've slowly got further and further away from us, you know, across the other side of the living room, now with wireless controllers 30 feet away. The fact I'm holding it in my hands, and it's taking up so much of my view on the iPad 2, and I can tilt it around, I can almost feel the world there, and I can go and touch it.

It adds to the game when I actually touch the glass. I can actually feel the glass. I can actually feel the world. I'm actually going to interact with that world behind me. We'll talk about some of the game design ideas there on how to really make that feel interactive.

And now with Apple TV, we're sharing the world. We are broadcasting the world from my iPad 2 to the TV set. We're going to talk about what that means because our eyeballs might be somewhere else now, and we might be thinking about what to do with a touch device and what that actually means. So, a few years ago, a game called Harbormaster came out from Emoji Studios. Are they out there? Big cheer for them.

Because Harbormaster was kind of that big duh moment in the sky of, here is how you make a great touch game. Here is how you make a game that I'm going to draw around on the screen and move those boats around, draw their lines, and it's a touch game. It's a fantastic touch game. It's one of those games that you went, oh my god, this is how to do touch games. And so I loved it for that.

And if you think about that game too, it is impossible to, you know, it would be really hard to make that game with a controller. That game wouldn't be very good with a joystick. And that's exactly the kind of thought process you need to have in your mind when you think about making a game for iOS. I want this game to suck with a joystick.

Because, you know, you know, Harbourmaster, you know, touching the glass is that different. If you aren't thinking that, something's wrong. You know, one of the things that's, that's, you have, you know, when you have these devices is that, you know, we have multiple iOS devices now, and we hold them very differently.

So when I'm holding the iPhone, I typically hold the iPhone and I cusp it in my hands and I've got my two thumbs doing stuff. And it's, you know, that's the way that I expect to play games. Whereas when I'm on the iPad, I kind of put my arm, you know, behind the iPad and I use one single finger.

And that one single finger is affecting the world in front of me and kind of doing interesting things. And you can see this in Apple's best of breeds applications. And here's Apple's iMovie on both the iPhone and on the iPad. You can see on the, that the interface is very different between the versions. They've thought about building different versions for different iOS devices. On the iPhone, there it is cusp at the side.

I can use my thumbs. You can see the information directly in the center of the screen and the timeline underneath. And you can see on the iPad version, it's designed for holding with one hand back and playing around with a single finger. And you can see on the iPad version, it's designed for holding with one hand back and playing around with a single finger.

That user interface change means that you cannot just up-res your application on an iPad. You can't just say, "Here's my game." Suddenly my graphics are a little bit bigger and my screen interface is going to be the same. You really need to think about how people hold these devices. You need to look at that in your game design if you're making a game which runs both on the iOS, iPhone, and iPad.

So, this is Quest we showed last year. There are two ways of interacting with a game world, as I talked about. There is the indirect method of using a virtual D-pad. We'll talk about those more later. And you can see the virtual D-pad there, and I'm going to move it around, and the character's going to move around or do something indirectly, and that's an indirect approach to game design.

And then I'm going to press the buttons underneath, and it's going to launch magic missiles and do all sorts of things. Or there is the direct approach of touching the world in front of me, which is typically when I have an iPad and I open up a game for the first time, that's what I'm going to try to do.

I'm going to try and touch the screen, because I expect when I touch the screen something to happen, because it happens in every other application. It happens in photos, it happens in mail, it happens in -- I expect things to happen directly. So, directly interacting with the world is kind of the expectation I have from that application.

Now if we look at some absolute best of breed applications that deal well with touch, we see Words with Friends. It's a board game implementation. And when you pick it up, you know right away how to play the game. I'm going to be picking up a tile, moving it around, and dropping it on the board. There's no instruction book that comes with it. It's not indirect. I'm not here guiding with a virtual D-pad and moving up and down and going left and right. It seems obvious, but I've got to point this out.

Crazy's Contraptions, an absolutely excellent game that I see three and four year olds playing. You can give them an iPad and they grok right away. I can move these things around on the screen and something happens. I mean, how fantastic is that that you can give a device to someone and right away they get how things work? And of course, Harbormaster. And as I think about these games, what I kind of notice about these games is they have staying power in the charts. They kind of stay in the top 25. Because people get them, they know how to use them, they keep playing them. Absolutely wonderful games.

Now when I think about indirect interaction and virtual D-pads, what I'm saying to my game player when I have a virtual D-pad on the screen is, "My game is better with a joystick." "My game is more fun on Xbox Live, but I couldn't think of any way to make my touch work directly, so I'm giving you a virtual D-pad." And that, to me, is not such a great way to interact with the world in front of me.

Some games also draw cursors that I'm going to move around, and that's kind of the way that the game is going to work. Some games have jump buttons on the other side as well as the virtual D-pad, so I'm kind of cusping my hand there, side to side, which is great for the position, but it's a bad way to implement a game design where I want to touch the world.

So I really encourage you to think about the way that I interact with the world and the way that I touch the world, and the way that I move away from virtual D-pads as the major input into games, because we have a glass interface. It doesn't come with a joystick. And also when I think about those games, I try to think of how many of those games are in the top 25 that stay there.

I couldn't think of a lot. So, something that's, you know, really strikes home perhaps more than anything is that those games don't have, you know, don't tend to have the same staying power that games have, you know, the direct interaction do. So, when you think about a touch interface, one of the things to think about is discoverability and usability.

Here's a card game, and the card games are easy to pick up. You kind of know what to do. I'm going to want to move my card around on the screen, so how do I do that? I'm going to point at my card and drag it. And that seems kind of obvious, and that's exactly what it does. I drag my card, five of hearts up to the four hearts, and it does the right thing. Snaps into place, and the game continues.

Usability-wise, though, the user might think in the end, "Well, I'm doing that a lot. I just want to touch the four hearts and have the five hearts move up there." So that's a little shortcut that you can add in that lets the more proficient users that want to find things later be able to optimize your application.

You should always think about the obvious thing first. What is the first person who picks up this application going to try and do? They're going to try and move the card. But after a while, they're going to want to think about, "What's the shortcut I can achieve to do the same thing? I want to just click on the four of hearts and have that drag in whatever is the appropriate thing to do on the screen." So it's often good to think about discoverability and usability when it comes to thinking about touch interface and how things will work on screens.

Something to think about when you're touching the world as well is that interaction needs to be quick. When I have a game up and running and it's going at 60 hertz, the game needs to be running fast in front of me. It needs to be running extremely fast.

But in word games, it needs to be running at 60 hertz whenever I touch the screen, because what happens is I'm going to point at the screen, pick up a ball, and move it around. The ball's going to lag behind me because I'm running at 10 hertz, and me as the user, I'm going to go back here to try to pick up that ball.

Meanwhile, it's gone here because that's where the touch thing told it to go, and then I'm going to try to catch up to it again, but it went back there. And then I'm going to let go and not play your app anymore because it apparently can't drag the ball around.

You need to think about going at 60 hertz even when you're picking things up from the screen, even in a simple game like Word for Word. Feel free to ramp down to 10 hertz once the thing's down again. Save on battery. But think about putting 60 hertz whenever you do any touch application. So that's designing to the platform. Number two, audio from the start.

Audio is incredibly important in these games, but it's also incredibly hard. We have speakers, we have headphones, people play at bus stops, they play indoors, they play in school, they play with mute on, they play with mute off, they play in all sorts of environments. So designing audio in from the very beginning is just a smart idea. And thinking about audio from day one is absolutely vital to get into your game.

So, a couple of months ago, I was on Twitter, as I normally am, and this tweet feed started to go out of this constant thing of, we got the Megatome and we are the smartest. And how many of you saw that that night? If you're on Twitter that night, you couldn't help but not see it. And I went and looked at what the hashtag was in Sorcery, and I downloaded this game called Sword and Sorcery.

And I was blown away by how immersive the audio environment was. I was dragged into that game world by the audio environment and how lively it felt. So to talk a little bit more about that, I'd like to invite Nathan and Craig to the stage to talk about how they implemented that audio design in Sword and Sorcery.

Thank you. Hello, WWDC friends. So, I'm Nathan Vella. I'm here to talk a bit about audio design in our game Superbrothers: Sword and Sorcery EP. It's a collaborative project that my studio, Capybara Games, made with Superbrothers and Jim Guthrie. So Super Brothers Sword & Sorcery EP launched on the App Store about two months ago, and in that time it managed to get about 200,000 downloads, which made us super happy. It received a ton of positive press from both the gaming media and the mainstream media, and perhaps most importantly, it got thousands of five-star reviews from our fans. Basically, it was this overwhelming positive love fest, and we couldn't be happier about it.

So, Super Brothers Sword & Sorcery EP is an exploratory adventure game with combat elements, puzzle elements, but the main emphasis is audiovisual style and soul. And while Craig's pixels are pretty awesome and make for a wonderful screenshot, we're pretty sure that the main reason why people really, you know, resonated with the game was because of the audio design and the music of Jim Guthrie. So our goal with the project from the very beginning was to create a record that you could hang out in.

I could talk a lot about how we did that, but it's probably best that we just kind of show you what's shaking. Craig's going to give a little bit of a demo, and I'm going to try to talk over it a little bit to kind of let you know what's going on. So right away when you boot up, what do you see? A record. Hopefully that kind of drives it in that we're making a game that's just as much about audio as anything else.

So once you get into the game, one of the things you'll notice is that there is an actual environmental sound design. The game world itself is making noise. You can tap on bushes, you can tap on characters. There's vocalizations for characters and also voice recording. And all of the sound effects are in the world. They pan and attenuate. Craig is going to go ahead and open up the door there, start walking up the mountain with his pal Logfella and his dog. And as you do, you're going to notice right away that music plays an extremely big component.

So, in this point, the music is set to drive you forward. You know, you're walking along in the woods, so it's walking along in the woods music. As you enter the next room, the environmental audio is going to kind of play with the music, so you're going to start hearing as you approach the bridge some waterfall action and a little bit of wind. And the whole idea is to make sure that you're in the world, and then also that the music is creating a mood and a tone.

At a certain point though, music will change. For example, when you see the three-eyed wolf. And now all of a sudden it's stopped being a kind of moving forward driving tune and it's more into a creepy cautionary. And if you're actually playing with headphones, we use stereo so that some audio is coming out of the right, some coming out of the left.

So that's about it for right now. Hopefully you get the picture of how we, you know, a little bit of an example of how we used audio in the game. So how do we go about crafting the Sword and Sorcery EP? Well, the very first step and a very key step is actually going out and finding an amazing musician.

So we went out, tapped Jim Guthrie, who in Toronto is somewhat of a legend. He's a rock star composer and an amazing performer. He keeps a relatively low profile in the world, but you probably know a lot of his friends and collaborators like Owen Pallet, Feist, and the Arcade Fire.

So we're going to show a quick little clip of Jim here. He works a lot with both analog and digital sounds, creates a whole bunch of different soundscapes with a lot of different tools, and then composes them all together in GarageBand. The idea being to create really rich, really lush audio.

Now I'm going to pass it over to Craig here from Super Brothers, and he's going to talk a bit about the process and so on. Hi, good morning. So I'm Craig from Super Brothers, and on this project I was handling the art, the writing, some of the initial design concepts, and I was also really involved on the audio side. Previously I had worked with Jim Guthrie's music. I had made a couple of amateur pixel music videos, and this project is very much an extension of that approach.

So the way it worked is I actually had some of Jim's music going back for a while, and I was able to listen to the songs over and over and over again, and just sort of figure out what the spirit of the song would be, and then try to paint that with the right color palettes, the right sort of story concepts, and just kind of clarify for myself what I thought the idea was going to be. What you saw there was like a clumsy music video that I was able to use to articulate my vision to the Sword & Sorcery team.

The next step after previsualization was actually getting that going in game. So this is a playable prototype running on iPhone. Basically runs through the same thing you saw with that previous music video, but now we're actually doing it for real. We've got the code, we've got the mechanics, we've got the input, the output, and we've figured out the sound and art assets.

The next step here, well, the basic process for a lot of this game was to start with the music, start with Jim's songs, figure out what those songs would evoke for our project, you know, this sort of sword and sorcery concept. I would paint or make storyboards or make an animatic, and then we would get it in-game, get our headphones on, and go and check to see how it felt and what kind of ideas came from that.

After that, of course, there was a lot of hard work. There's a lot of iterative audio design that happened in this project, and we were using FMOD, which is an audio middleware. And there's actually an application within FMOD called FMOD Designer, and I was actually very involved on that side, even though I'm not necessarily a sound designer.

I was able to go in and swap in and out sounds, change the panning and attenuation, and then I was able to go into my hero Jim's music, cut it to pieces, and put it in, and then kind of string logic. together, which you can see on that slide a little bit. That was the idea of making the song compositions react to the player's progress and the player's decisions.

The other key part of this was that Jim was involved from the start, and as we got going, we would have him stop by the office every week or two, get a new build, we'd talk about it sort of together. He'd go off and play it, put his headphones on, and basically score the experience that he thought would make sense. So he was very much a co-creator on the project, along with myself and Capybara Games.

So in the end, we actually did achieve what we set out to do, amazingly. It really does feel like you're walking through a record. There's as much variety and craft and texture as you might want from a record, and it's all weaved together in this sort of archetypical adventure video game.

And the icing on the cake with all of this is that there's actually a record out there, Jim Guthrie's Sword and Sorcery LP, The Ballad of the Space Babies. It's on iTunes, and we even went ahead and made a vinyl limited edition copy, which is sort of a dream come true. We're all Jim Guthrie fans on the project, so being involved in a record release of his is a really exciting proposition.

So a couple of takeaways from this project. We found there is an audience for songs, style, and soul. If you make something that has audio in the foreground, people will respond to it. And despite what you may have heard, they will take the time to put on headphones and actually get immersed in that handcrafted audio visual experience.

Second takeaway, very straightforward, trust in the collaboration. Make sure that everybody involved is there to add to the project, not just paste something on over top. So for example, Jim would send us a song, we'd listen to it and be like, that is perfect, thanks very much, full stop.

But then there were other times where he would send us music and come to the office when we started talking about it, and we weren't really sure what it was, where it would fit, how it would work. But after we got it in game and started playing and iterating, we realized, wait a second, this actually is the perfect piece of music for that moment.

We just had to trust Jim. And our last takeaway is that anything is possible. These machines are a few years old now, but they're still very much a blank canvas. The audience that's out there doesn't have as many preconceived notions as on other video game platforms, so you can surprise them. You can take genres and mix them together or make something that doesn't even fit in any recognizable genre. You can put audio out front and make that a selling point, and people will respond. There will be some percentage of that broad audience.

There will be some percentage of the audience out there who will take a risk on an unusual artist-driven project like Sword & Sorcery. So that's it. If you'd like to check in with us with any questions, feel free to look us up on the internets. Thank you. Thanks, folks.

That game rocks. I don't think I need to say anything else about audio. Let's talk about leveraging Game Center. Game Center is an incredibly powerful API, but it offers a lot more than I think people think. Leaderboard is something built into, you know, in the Game Center, and it should be built into every one of your applications.

Leaderboards are great. You put the score up there, and, you know, people go look at it. But the real power of leaderboards is kind of that friend-to-friend offline challenge. I'm going to play Nate, and I'm going to, you know, beat his score at, you know, some racing game or whatever.

And then I'm going to log online, and he's going to see, "Oh, Graeme's beating me. I'm going to try and beat him." And I'm going to go play that game. So that offline mode encourages people to go back to your game and play it again and again. You know, you get two friends going together like that, and you get a lot of engagement or re-engagement in your game, which is vital for bringing people back to your game and getting people back in.

Achievements are also really interesting. I mean, a lot of people put achievements in of just, "I've completed level one. I've completed level two. I've completed level three." They're not really achievements, but they're really boring. The best achievements are the creative and fun ones, the ones where I have to go through a level without shooting a gun once and win, the one where I have to go around a racetrack backwards and, you know, not crash into any cars.

Because people look through those achievement lists, and they're thinking, "Well, I can go do that now. That sounds kind of interesting and different." And what that adds to your game is it adds the ability in your game for you to add ways for your players to find different ways to play your game.

Perhaps they're stuck playing just the one level. Perhaps they're just playing the one mode. But they're going to see an interesting-sounding achievement, and they're going to go try that different mode, and perhaps it opens up a whole bunch more re-engagement in your game. Interesting achievements are vital to great game design.

At the conference today, or yesterday, we announced turn-by-turn gaming. And I try to think of, you know, I think there's a fantastic API, and there's going to be a lot of just turn-by-turn games out there. But every game, single-player games especially, should include this API in their application. It's now incredibly easy to add a challenge mode to my game. I'm going to play my game as a challenge to a friend, and I'm going to upload the random number seed as the only piece of data that I'm going to send.

I'm going to go send that seed to someone. They're going to play exactly the same game. Perhaps it's a game of cards, and I'm going to have the same cards that I'm going to play in front of them. And it's a one-turn game, but it makes any game, any single-player game, engaged with a friend, that I can then have a challenge to go and try and beat them. And that's fantastic. Every game should now be including Game Center, at least as that kind of mode.

I think about co-op action games, and, you know, I'm just playing a game where it's one of those roly-marble games, and I'm going to roll past, you know, my friends. of the score and it's going to then send my new position finally out to him so that I can see little flags side by side.

I really encourage you to think outside the box when it comes to API because adding that single player, adding single player game elements into the game is I think a fantastic opportunity for every game. Don't just think of the board games I can go make of this, think of every game as a possibility for using this.

Game Center also adds photos. I love putting photos in apps. It just makes such a difference to the screen that I can go see the person's face, and I can go see what's going on, and I can go see if it's my wife or my mom. And it immediately brings you engagement and love into games because you put your loved ones in there or your friends in there. And that just makes the game more attractive immediately to people. They stick photos all around their house. Let's get it on there. So, Abraham Lincoln tweeted this the other week.

Am I not destroying my enemies when I make friends with them? And that is so true. The true power of Game Center is actually the list of friends I have in Game Center. I have a list of friends that I can, you know, when I start my application up, I can log into Game Center, my application can download that list, and I know all these people want to play games. And that's incredibly powerful.

If I'm not doing something with that, then I'm missing out on the biggest opportunity that iOS has to offer. You know, I am able to get all those GK player IDs and then do something with it, whether it's socially, you know, socially adding something, you know, with my own server, or doing something with Game Center, or thinking of interesting ways to use achievements or leaderboards.

That combination of friends and that list of friends is the most valuable thing in Game Center. It's your friends. It's, that's just, I can't emphasize enough that, you know, include this in every single game design, even if you think that my game is just for one player. Because it's, you know, no game is just for one player. So that's thinking about leveraging Game Center. Wow, I paced a lot there.

Let's talk about going the extra mile. Now, we've all done this, we get very excited about our applications, super excited, and our application's finished, and we're going to upload it onto iTunes Connect, and it's going to be fabulous, and it's going to do well, and we're so excited that maybe we forgot to add a little bit of polish into the game that really will make it go the extra mile.

And polish is really an absolutely critical element of any game now, because if you go look at that top 25 list, each of those games is highly polished. And polish is more than just UI. You should be thinking about your UI from day one, and using the new UI appearance, and skinning your application, and so forth. But you should make sure that you've added gameplay that engages and builds. You should make sure that you don't add all your aliens in level one, and so forth. And you should be adding gameplay which really has levels that properly progress.

When your game is live, you should be reading the reviews on the board. I know that's tough, going into iTunes and taking a look at those, and reading the reviews sometimes is very tough. But often there's a thread there of sanity that says, "This game needs a mute button." And you didn't think about that.

You didn't think, "Hey, my game needs mute because it doesn't need mute because it has awesome audio." But you know, players are out there, and unfortunately, they want to play the game on their terms, and you should add preferences that you yourself will never use, because it will enable more players to enjoy the rest of your game.

Going the extra mile also means a little bit of thinking about the actual devices I'm using. Test your game on every device you sell for. It seems easy, but your beta tester should be able to help you cover this. You should be able to at least test on every single iOS device that you're going to actually sell for. It's amazing how many people just, you know, the only thing they've tested on is the simulator and, oh my god, it doesn't run on the iPad. Go test on real devices and play it. Check every path through your app.

You know, when you add in-app purchase, you know, it's wonderful, but every time you go to test it, you're testing the yes case, because of course that's what you want to test. Does the in-app purchase work? What happens when you tap no and say no? Does the right thing happen or does the app, you know, crash? Make sure that you test every no path through your app. Every possible path needs testing.

And think about when you're making your app, how the release and the debug versions need to be different. On Game Center, you know, you have testing with friends and, you know, you only have the three friends that you have on Game Center when you're testing in the sandbox. When you go live, you've got 50 friends. So those menus need to reflect the ability to show 50 friends and not just, you know, the three friends you have on Game Center in the sandbox mode.

And finally, always keep in the back of your mind that first update. You will be making an update. Think in the back of your mind what you can do beside bug fixes to offer more to your users. Yes, fix the bugs, but think about how I'm going to increment my application to the next level.

So, let's go in the extra mile. Number five, refinement of my application. So, playtesting. Playtesting is something that seems like an easy word to say. It seems like an easy thing to do. The main thing you have to remember about playtesting is, you do not come with every app installed. So, when you playtest your game, when you hand that device over and when you watch them play, you have to remember to shut up and not talk.

You have to watch them struggle with your game and struggle with what might seem obvious to you. The game has a big red button on it that says, "Press here to start." And they're just not finding that big red button. They're trying to get this pixel off the side of the bunny rabbit to try and animate or do something. And you really just want to scream at them, "Hit the big red button." But they're not pressing it, and they're not pressing it.

You have to hold back. You have to listen to their feedback afterwards as to why they didn't press it, what they didn't find obvious about it, why that seemed so unobvious to them. Because it is much better that they complain to you now than they complain on the App Store. So playtesting and withholding from telling people what to do. Just remember, I don't come with the app when people download it.

Something we're all guilty of is scope refinement as we go along when we're making apps. And this really adds to unrefinement of applications. I unrefine an app. I feature creep design. I start making a card game, and I think, oh, my card game's set in the old west. I'm going to add guns thing to it so that I can bring out guns and shoot the cards when I don't like the deck.

Well, what the heck? I'm going to add more than guns thing to it. I'm going to be able to shoot the other player when I don't like him and see him fall over with rendering physics and real life. Oh, what the heck? There's that ability to tip the table over and use that physics thing to make the cards go into the air and the coins will offer. Sounds fantastic. But it's no longer a card game. You made a first-person shooter now.

You've moved beyond the scope of your initial design, but your initial game design and your initial game class and everything you've coded so far reflects a card game. And a card game class can't support a first-person shooter. So, don't allow feature creeps to really enter into your game. Think about the game you're making all the time.

As you are playtesting, think about gathering stats. Add the ability for your application to gather stats on when the player starts playing, when they stop playing, what level they're playing on, when they die, when they pick up power-ups, and store those things on a server and look at them.

If they're all stopping playing on level 3 because they're finding it too hard, you might have to adjust level 3. Perhaps you wanted level 3 to be really hard, and it's not quite hard enough because they're all zooming through it. Capturing those stats during beta testing is incredibly important. It's how some of the big console games get to be so finely tuned, is that they sit and gather stats from beta.

And don't be afraid to cut features. The only person that knows you've cut a feature is you. When you sell your app, they don't know that you've cut a feature. They don't know that the MMO mode of your card game is missing. Just think about keeping your game scoped so you sell what you initially went to make. Cut features. Let's talk about refinement.

Optimization. This is a big subject. That's why it's got two slides. Optimization is incredibly hard. The best way to optimize your app is to step away from your keyboard and take a walk. You know, the first, the most tempting thing to do is always to jump into the profiler and to look at the application and look at where, you know, what Objective-C copy in NSString is taking up all the time, or the texture uploads I'm doing too much. But the absolute best optimizer is your brain.

Your brain thinks better than anything else. It knows the application. It knows how you use those algorithms. It knows what's really going on. It knows you have four million polygons and that fire particle effect back there. It might strike you when it walks, maybe I should reduce that to two million.

Use your brain first. Take a break. Take a walk. Go look at something else. Think about your application. Then, by all means, dive into some of the fantastic instruments and tools that Apple has to offer for profiling. And I'm talking this week about GL Analyzer, GL Detective, and GL Debugger built into Xcode now, and the absolute fabulous statistics that it offers, breaking down your application and the suggestions it offers on how to fix your application.

Those tools are great, but always remember, use your brain first. Amen. One of the biggest things to optimize is startup time. When you start your app, your app should be interactive within three seconds. You must think about this three seconds as the three seconds of hate. For every second that goes by, I hate your application more.

This is what users think. So you might as well approach this right. So if your application is taking 10 seconds to launch, there's a lot of hate there. And that's before you've actually shown the first thing, which is interactiveness, before you've had a chance to entertain them. Do whatever you need to do to have your application be interactive within three seconds.

These people are playing games at bus stops. They're playing games in all sorts of strange places. They want to get your game quick. They want to swap in and out and be able to get there. So think about what I can do to make my game interactive quickly. Defer asset loading. Those 100 PNGs you have loaded for the first level, you don't need to load them. Bring up the menu stuff. Think about threading. It's tough to get threading right, but if you get it right, it rocks. Work out what's going on.

Do I really need those 20 sound files right away? Well, no. You're bringing up a menu. Optimize your startup time. It's the most critical element in your game. It's the first thing users see. Optimize battery life. This is something we really have to think about with iOS. It's kind of an interesting thing to optimize for because it seems to offset some opportunities that we want.

But all these devices run off batteries, and our game players are very sensitive to power-hungry applications. If I start up your game and I play it for 10 minutes and I close down and I'm suddenly at 30% power, I'm kind of going to remember that. I'm going to remember that your application chews through power.

Test and retest between updates. Whenever you make an update for an app, make sure that your application is still as power-misery as possible as it was before. There is an absolutely fantastic app for testing this. The Instruments has the power measurement tool in Xcode. Start up Instruments, you go measure power.

It shows you in your application what's using power. It's the CPU, the GPU, the GPU. The GPS, the GSM radio, the other radio, the other radio. It shows you what's on your device and it gives you an estimation of how much power you're currently using on a scale from 1 to 20. And that is an incredibly powerful way to be able to measure your application and take a look at the amount of power you're using. So always remember to look at the battery life and look at what power you're using inside an application.

Optimization. Three slides, you need to optimize. Connection, and being able to connect to applications. This is something I really started to look at recently, and I've started to add it to all of my applications. It's adding a new section into applications that enables me to talk to my audience.

You know, I started learning how to do server programming, and what it kind of meant to actually run my own server. We should all be thinking about that, because it's incredibly easy. Running your own server with the ability to push news to applications is and may well be your only marketing channel that you own.

I love little news sections in applications, because my application starts up, it can query my server to see if there's any new news. If there is new news, I can make a little thing flash and go, "Boof!" And then my user can opt in, and can opt in to go look at that news. And I never force that news to come up saying, "Whoa, blah, blah, big news, new news," because my users, I want them to love my games. I want them to love me as a developer, and love me and love my company.

And if I've made a fantastic game, if I've made a game that people enjoy playing, if I've made something which is compelling, they will want to have another game from me. You know, they want to play the next game, so that when that news thing goes off, boy, they're going to go to it. I don't have to force things in front of people's faces.

One of the things when you add a news text into your app is you need to update it. I employ my sister now to write my news things for me. She used Hype on the Mac to write great little iOS websites. If I'm going to log into your app, see news come up, and it's going to say September 2010, I'm going to think, "This app is stale." It does add another load to you to do, but it's a way of engaging your audience.

Something that I saw in AppNuts by Limbic Software was right on the first page it's got a feedback button. And absolutely incredible. It's just sitting there on a little post that says feedback. And it comes up and it comes down to some text. Hey, if you love this game or if you don't love this game, send us some feedback. It hit that, it comes up with a little mail thing.

It's not intrusive. It's not doing anything. It doesn't hurt the game. But it allows your game players to directly talk to the developer and to send them some feedback. Because the only other place they have to send you feedback is in the app review section of iTunes. You know, because going anywhere else, going to the support page of your web thing and finding email address, clicking on that, opening up mail, if you've not done it right, so I've got to cut and paste, can provide all sorts of hard ways for users to get your feedback.

But putting it in game I thought was genius. You know, just that little button there, you know, probably lets people provide feedback with ideas for what they want, what they're enjoying, what they're not enjoying. And I just thought that was absolutely perfect touch to add to that game. By the way, I love that game. Always make that opt-in.

Guess there's some devs in the audience. Don't force this. Don't come up and say, hey, rate my app. I've been guilty of this in the past. We have the ability now to make all of this opt in. Like I said, your developers, your game players will love your app. If they do, they'll want to send you feedback telling you so.

And finally, in community, add to the community. That group of friends I told you about in Game Center, extremely valuable. One of the fabulous ways to leverage that is to form a community around your game. So jump flags, when I'm playing a jump game, to show it as I'm jumping up higher and higher and higher, here's my friend, here's my friend, here's my friend. And just seeing that, so those flags go by, kind of makes me feel as if I'm playing a multiplayer game, even though I'm just playing on my own.

When I'm playing a race car game, I love to be able to download other people's race cars and race around a track and see them race around their ghost cars so I can try to race them virtually. I'm not playing head to head with them, but I've downloaded their data so I can see how they race around a track and I can virtually race against them.

Finally, sharing puzzle solutions. I thought this was absolutely fantastic in Casey's Contraptions. It comes up with two things. I can go share my solution with my friends. I can go take a look at their solutions. And the fact that I can go take a look at their solutions and how they ran, what they scored, it's kind of just a little thing that adds to the game that makes me feel connected as I'm playing the game. Whenever I see my friends, I'm going to have a conversation about them. "Oh, I saw you use those crazy cars in that one solution." Adding community in the games is incredibly powerful. I encourage you to do that in every single application now. Talking about connections.

Next, localization. Localization is getting to be much more important. I'm going to talk to you here really about the four things I kind of consider important about localization and how they go along the way. First one is to always design your app for localization. You know, we're all guilty of having a whole bunch of Objective-C files that we just put the strings into, you know, the at OK and the NS alerts and so forth so that it's right there. And it's convenient to do as we're coding. There's no doubt about that.

But if your app then has 100 million downloads, you think, well, I should localize for China. You know, try to get this to 100 million downloads in a different country. You haven't thought about localization from the very beginning. It's a real pain to be able to go back and localize properly.

And Objective-C and NSString obviously allow us to easily localize and set up for localization from the very opening of your application. Just adding, you know, localized strings so that the table that goes looks it up. You know, so design for localization, build that in at the very least because markets outside North America are growing rapidly.

If you can't localize your app completely, at least think about localizing your iTunes description. Now, a lot of game players, they can work out left, right, fire, and score. These are things they recognize. But the iTunes description is the first and foremost point of contact between you and the game player.

It's the most text they will ever see about your game. You know, they're going to base their decision to download, try it, purchase it, based upon that description and that localizing right there. It's a huge difference. It's the easiest thing to do as well. You know, in iTunes Connect, to be able to localize it into the local languages. I don't have to add it into my application.

But it's the major point of contact, you know, between me and my player. It's the first point of contact. And that decision will be based upon that localization. And finally, I really encourage you to localize all your apps. To actually make that app personal, you know, for that localization to be played in. This is a changing world that we're playing in now. We're selling games across the world. Fortunately, there's lots of languages. That's localization.

Getting games up and running. We're making games. Games are fun. So I think games should be running on day two. That's where, if your game isn't running on day two, then you're kind of working on something else, not the game. Now, there's lots of ways to play games.

One of my favorite ways of playing games is to make cards. But whether you're playing your game on paper, chalkboards, whiteboards, or cards, you'll get your game running, whether it's running in-game. Your game might be played with cards, but a turn, which is going to take a tenth of a second on the iPhone, takes 15 minutes to play with cards. And that is a fantastic opportunity. It lets you engineer at the 15-minute level what's going to happen in a tenth of a second. It's like going into the quantum level on my game mechanics and adjusting it.

It's like adjusting it in slow motion. How perfect is that? That tenth of a second becomes perfect because I've worked on a game with cards. I've worked on a game outside of the game engine. I've thought about how those mechanics work very carefully. And that reflects, finally, when you get the game running, that you have that math right.

You have that hit structure right. You have that approach right. Think about playing your game constantly on day two and playing it every single day. From the second day on. No matter what. Think about what you need to do to play it. Never let technology stop you from playing your game.

One of the things that stops us from getting the game running often is our need as game programmers to make the super-duper renderer. Very technical term. The super-duper renderer is this HDR renderer that has all this real-life lighting and these fantastic shadows and fall-off and HDR and sun glints and I look up and HDR changes to the ground and so forth. And has real physics that let things tumble down from the ground and buildings fall over and all this wonderful stuff. And it's fantastic.

Absolutely fantastic stuff. You know, who doesn't want to work on something like that? It's absolutely terrible if you have an eight-week dev cycle and you spend the first seven weeks working on the renderer and the physics engine and the last week working on a game. That's going to mean your game is going to suck. Why the fantastic renderer? Normally views might reflect that, but your game sucks equals no sales. Work on the game. Remember what you're actually selling. Selling a game. Wow. Ooh, get up and running.

Let's talk really about embracing the platform. We're making games for the iPhone, the iPad, the iPod Touch. The iOS SDK offers a stable foundation to build upon. Now, as game programmers, we love to roll our own. We love to roll our own user interface design. We love to roll our own input scheme. We love to roll our own sound engine that mixes the PCM directly onto the hardware pipe. We love that stuff.

We love making our own castles effectively and building a huge moat around it so that our game engine is our game engine. But it's time to move on from that way of thinking when we're thinking about making games for iOS. Building on top of the iOS technologies is better than rolling your own. It has expected behaviors.

When I have a UI button and there is a lot of thought behind how the UI button presses. When the event happens on the tap lift off and there's all sorts of state changes and so forth. And every other application on the phone uses UI button. So game players and users are used to the way that this works.

They're used to the expectations around the way the button works. So why would you roll your own button when there's a button class that works the way users expect in every other application? Of course you should use UI button. You should be using UI kit for anything to do with interface. anything to do with interface. Provides expected behavior.

You can finish your game faster because you're building upon technologies that have wonderful documentation, that don't leak memory, that have great Objective C classes that are thought out, that work together, that are built on top of iOS and provide a great framework for your game to start off with. And they let you be an iOS app.

Building in that way the game feels. Users love games that feel the way that they expect things to feel on their device. They love the iPad applications that have the full screen feel to them. It's kind of like the overall direction that we're seeing some of the user interface go with the buttons and the switches and so forth. Some absolutely great stuff to be done there. You have to remember when you're working on iOS. You can't just start with a simple iOS device. It comes with one button.

Well, some side buttons too, but it comes mainly with one big button called the home button. And the home button really is now your save game button. Way back in the 70s and 80s when we first started making games, computers used to come with floppy disk drives, and we used to store 160 kilobytes on a floppy disk drive. Now I can store more than that in a cloud. It's just amazing. But we used to save a game, come up with a dialogue saying insert the floppy disk now.

We used to go clunk, clunk, clunk, clunk, clunk, and it would save the thing. We would take the disk out, we'd mark it save game one. And we kind of stuck with that metaphor. We kind of stuck with the idea of save game being something that I'm going to go do. I'm going to go make this action.

I'm going to have these slots. I'm going to have these nine slots for save games because that's the first thing we did when hard drives came out. Oh my God, now I can store multiple save games next to each other. But now the device is kind of there constantly, and users expect to exit out by pressing the home button.

You need to be able to save state right there. You need to be able to save your game right at that point. Their expected behavior is I'm going to come back to your application where it was. You need to be able to save right there when things are going. The game machine is also a phone, or some of them are phones, and they're going to ring. People are going to want to talk to that person.

It's going to be their mom. And you have to play nice when they pick up and answer the phone to their mom. They're going to come back and your game better be paused, and if it's asteroids, you might have thought about moving something. You might want to take some of the asteroids out away from the impending death syndrome they're about to have. There's all sorts of things to think about when it comes to us being on a device.

And so now we're offering iCloud. And I think about iCloud and I think it's much more than syncing. It's making universal apps much more attractive. I have this application which is my space war application where on my iPad version I'm moving my spaceships around and they're going to sit and get ready to attack the planet. And they're going to take two weeks to build and then they're going to be here in three weeks and they're going to bombard this planet on the ground.

And then when I play my iPhone version of the same application, it's a ground war and they're being bombarded from space and it offers much more opportunity for making applications which do interesting things between versions, between the iPad version, between the iPhone version, between the version I broadcast over AirPlay. So different gameplay, but the same world. I think that's a huge opportunity to be able to make something fantastic there.

So talking about AirPlay, it's one of those things where I think about AirPlay and it really does offer some, you know, everyone cheered yesterday when it was on screen and being shown as a game thing. It's wonderful. It's absolutely incredible. Also offers some design challenges that we need to meet now as well.

But when I broadcast to it, you know, from my device to AirPlay, where are my eyeballs looking now? What is my expectation for where my gameplay is looking? If I'm expecting my gameplay to look at the TV set, and, you know, what is, how are they going to interact with that? How are they going to interact with the game? You know, with the iPad 2, is it going to become one big button? Am I going to use the gyro, the accelerometer, move things around? We really need to think about where we expect players' eyeballs to be now.

Up until now, we've been lucky. It's always been focused right in front of us. But AirPlay, you know, changes things up a little bit in terms of design. We really need to be careful to design good interface there. So that people can still continue to play our games and enjoy them now on their HDTVs.

I think one of the huge opportunities there is the opportunity of many local devices surrounding a HDTV. We've got to think about how to involve those party games and think about some of the games Nate made and how to actually make that interactive. I think that's going to become some of the really killer games is that many local devices with one iPad connects up to via AirPlay doing some absolutely wonderful games.

That's number 10. Wow. Made it through all 10. Finally, make something fantastic. We're in the games industry. If we aren't getting up every morning and thinking, "Oh, what I'm doing is fantastic," you're in the wrong industry. We're making games. Everything we make is fantastic. This is a fantastic time to be making games. I'm loving it right now. Making fantastic games, getting out of bed doing this is absolutely wonderful. So thank you. Thank you for listening.

We have sessions on Game Center today and tomorrow. I encourage you to go to all of those, although we have a lab this afternoon. Come to our lab first. iCloud sessions today and tomorrow. Open GL ES sessions. That's going to be wonderful to sit through. I'll be here sitting through all of those tomorrow here in this room. The AirPlay session, Presidio, this afternoon. And finally, if you have any questions, Alan Schafer is your man. I'm sure he'll be down visiting our lab as well. Here's his email address. Send him your questions. Thank you. Let's go have some lunch.