Video hosted by Apple at devstreaming-cdn.apple.com

Configure player

Close

WWDC Index does not host video files

If you have access to video files, you can configure a URL pattern to be used in a video player.

URL pattern

preview

Use any of these variables in your URL pattern, the pattern is stored in your browsers' local storage.

$id
ID of session: tech-talks-2013-28
$eventId
ID of event: tech-talks
$eventContentId
ID of session without event part: 2013-28
$eventShortId
Shortened ID of event: tech-talks
$year
Year of session: 2013
$extension
Extension of original filename: mov
$filenameAlmostEvery
Filename from "(Almost) Every..." gist: [2013] [Tech Talk 28] User Inter...

iOS 7 Tech Talks #28

User Interface Design for iOS 7 Games

2013 • 51:58

Truly outstanding iOS games go beyond addictive gameplay and beautiful graphics by presenting players with interfaces that are thoughtfully designed and carefully implemented. Receive practical advice about UI design and platform conventions that will make your game even more enjoyable.

Speaker: Mike Stern

Unlisted on Apple Developer site

Transcript

This transcript was generated using Whisper, it has known transcription errors. We are working on an improved version.

All right, you guys. We're going to get going. Try to get everyone out of here on time. So my name is Mike Stern. I am a user experience evangelist with Apple. And thanks for sticking through to the end of the day to watch my talk. So today I want to talk to you about UI design for games. And the session of the title is iOS 7 Games. And we'll talk a little bit about iOS 7.

But for a large part of this presentation here in the beginning, I'm just going to talk about general UI advice. Stuff that was relevant at any point in time for iOS. Now, as an evangelist, I spent a lot of time working with developers of both games and apps.

And in particular, when I talk to game developers, I'm always really interested to look out for how they take the theme of the game that they have, the motif, the style of it, and apply it to solving interaction design problems for their game and all the different screens that people are going to see. It's always really surprising and interesting to see what kind of things result from that.

Olo is a really good example of this. When you go to the menu, you simply tap anywhere on the screen and the board splits open to reveal the menu. You can pinch it, close, or tap to close it again. That's a completely non-standard interaction design paradigm. We don't have anything like that anywhere else for our built-in apps, let's say.

But it's totally appropriate for this game. It makes perfect sense for the way the game board is designed. It's very clever, it's really unique, and it works well. And they take the style of that game and they apply it to every screen that you're going to see when you play the game.

Let's look at another example. This is a game called Beat Sneak. It has a very unique and coherent design motif to it. And that style is applied to all sorts of screens, from the pause screen to the level chooser and every other screen that you'll see. And this kind of heavy UI customization for games is something that at Apple we really appreciate. It's great. It brings a lot of diversity to the platform, a lot of variety and creativity to that experience. So we totally encourage that.

Here's another example. This is Badland. Won an ADA, an Apple Design Award, earlier this year. And part of the reason why it did is because, as you can see, the artwork for this game is totally stunning. And they take that artwork, they take that great attention to visual detail, and they apply it to everything in the game. The pause screen and the level chooser.

Here's another example, completely different style, yet again, this is Ridiculous Fishing, also an ADA winner. And again, you can see how thoroughly the UI has been customized. These games, the games that you guys make, they should be completely immersive experiences. They should be worlds that people can escape to, get lost in.

But in order for that to happen, the experience must be consistent. So when we complete a level in Tiny Wings, you expect to see something that looks like this. Not something that looks like that. That just looks like it's not finished, even though those are totally standard UI kit elements that have been placed here.

But even if your game looks totally custom, it should behave in a way that matches other iOS apps and games. It's really important. So for example, even if you have a button that looks like a plank of wood, it should still behave like any other button does on iOS. So when you press it, it should highlight immediately. And when you release your finger or slide your finger off of the button, it should go back to its normal, non-highlighted state.

[ Transcript missing ]

Or when you press the button and you slide your finger off of it, it'll stay in its active state. That's a problem because you feel like you're trapped into pressing this button. How do you bail out? How do you escape? How do you not press this button at this point? So these kind of inconsistent interaction behaviors, like just with this button, this is just one small example of a larger thing, which is that if you don't match iOS behaviors, people are going to get confused and frustrated using your game.

[ Transcript missing ]

: I'm here today to provide some basic guidance to you guys about how to make this happen. Much of this guidance is tailored to you as game developers, but to be honest, I've provided this type of advice to non-game app developers as well. This advice applies to any iOS app, whether it's a game or not.

The purpose of matching standard iOS conventions is that it's going to make your game more intuitive. And the purpose of that is the more intuitive your game is, the more enjoyable it's going to be to play. Which is really what it's all about, right? This simple thing. This is ultimately the goal for all of us, for all of you in this room. To maximize enjoyment.

So let's dive in. Talk about some examples of how to make the UI for your games really great. So the first and most important thing, and Alan actually talked about this quite a bit in the previous discussion. John talked about this earlier this morning. But I'm just going to reiterate this because it's so important. That is you're designing for touch.

iOS is not a desktop where you're using a keyboard or trackpad or a mouse to interact with the game. And it's not a gaming console where you're dependent upon using a game controller. And we see lots of games that try to recreate desktop or gaming console mechanics by superimposing buttons over the game or a D-pad. And typically this doesn't work very well. It's not necessary.

Adding these elements gets in the way of your ability to see the game. And unlike physical buttons, unlike a physical D-pad, you can't feel when your finger is over the button or the D-pad and when it's not. So as much as possible, you want to design for direct manipulation. So for example, if we want to take this paddle here and move it to the right side of the screen, we simply drag it to where we want it to go to. Or we tap a location on the screen. and have it just go there.

We use the movement of the device to control things in the interface. By the way, I just want to take a quick moment. You're going to see a lot of this game. It's not a real game. I designed it for today's presentation. It's called Paddlemania 3000. It's not coming to an app store near you. All right, let's keep going.

So, as you know, we now have the ability to connect to game controllers. And that's great for controlling gameplay, but avoid forcing people to interact with the UI using a game controller. It's often not going to be clear what button does what. Which of these physical buttons relates to which button on screen. Do these buttons quit and resume? Are these buttons? No one knows.

In fact, people may accidentally press those buttons without realizing that they actually will either quit the game or resume gameplay. If you want to quit the game or resume gameplay, if you want to press one of those buttons on the screen, it's much, much easier to just press one of those buttons on the screen.

[ Transcript missing ]

It's much easier to just press the thing that you're interested in pressing. So always go for direct manipulation. Always make sure that the touchscreen experience is really great and at the center. Let's move on to gestures. Gestures are the primary way that we interact with everything on iOS.

And to use an iOS device, all you really need to know are a half dozen really simple gestures like tap, pan, swipe, pinch, rotate, long press. And these gestures work because they're intuitive. And so many of the apps that we interact with on a daily basis support these gestures in a very consistent way. So it's all become very deeply ingrained. It's all very intuitive.

Not that much to remember. So with that in mind, here's a few tips about how to use gestures successfully. First and foremost, match iOS behavior and performance. This is a big one. I can't stress this enough. When basic gestures like pinching and dragging don't work exactly like they do in other iOS apps, we start to feel like something isn't quite right.

So for example-- In a second, I'm going to drag this paddle over to the right-hand side. And as I do so, my expectation is that it's going to stay directly underneath my finger. If it doesn't do that, it undermines that sense of direct manipulation. I don't feel like I'm actually dragging the paddle anywhere.

Similarly, if I do exactly the same thing and it takes a while for the paddle to go to where I want it to go, it also undermines direct manipulation, makes the game or the app feel really sluggish. It's a bad performance. You want to make sure that touch interactions are really responsive.

Next up, we want to avoid remapping. So this is really jarring. When an app or a game has a gesture, uses a standard gesture to do an uncommon thing. So for example, we understand that pinching is used to scale objects. So it would be strange if a simple tap was how we zoomed in and zoomed out.

Next up, prefer gestures to buttons. So don't use buttons for interactions which could be more intuitively performed using a gesture. So for example, scrolling. You don't need up and down buttons to scroll. It's much easier to just swipe on the screen to scroll. Consider plus and minus buttons for zooming. You see this every once in a while. Explicit controls for zooming are typically not necessary. : I'm going to go ahead and start the presentation.

No matter how your game looks, I'm going to kind of repeat myself here, but it's important. UI elements should function in intuitive and predictable ways, meaning they should match, they should be consistent with how iOS controls behave. So if you have things like buttons or scroll views or alerts, you want to make sure that you're doing a good job recreating the expected behaviors that players of your game have.

So let's talk about six different types of controls and views that are really commonplace. And I want to start with the most basic one, the most common UI element, which is a button. Now, this is going to sound really basic and at the risk of insulting everyone's intelligence, I'm just going to put it out there that it's really a lot easier to press a big button than a small button. I know, it's very profound.

Based on our experience and extensive testing, we've determined that you want to make sure that a button is at least 44 points tall and 44 points wide. If it's any smaller than that, there's a high likelihood that your finger is going to be completely covering the button. So you're not going to be able to target it accurately and you're not going to know if you pressed the right button.

Now this play button, this is really big. So it's easy, super easy to target it accurately. And when we press it, we know that we've pressed it because it has a very clear and obvious highlight state. Clear and obvious highlight states are not to be taken lightly. These are really important because, again, it's a touchscreen device. There could be a lot of things around it. And you want to make sure that people know that they pressed the right thing.

Now here we have a much smaller button. And if we were to use the same highlight state for that, you could see there's a bit of a problem. It's too small. The finger could be covering most or all of that button. So that's a problem. The same highlight state that works for a large control doesn't work so well for a small control.

So in these situations, consider having a highlight state that is extraordinarily obvious and is expanded beyond the bounds of the button artwork so that you know even if your finger is completely covering the button as you press it, you're going to get that instantaneous confirmation that you pressed the thing that you had intended to press.

So let's move on to alerts. Now, with alerts, when you give people choices, it's really important that the options that you're presenting to them make it obvious what the outcome of those actions will be. So let's say, for example, in Paddlemania 3000, we've earned this Mega Paddle upgrade, or we're asked for confirmation if we want to buy this Mega Paddle upgrade, and the options that are presented to me are no or yes.

Well, that's okay. That's not terrible. I can read the question, sort of understand what those potential answers are going to be. But it's not a great design. A much better design would be to replace those labels with something more descriptive. So in this case, this is a much better design. The options for action are much more clear.

You want to try to figure out how you can use the labels of the buttons that you're presenting to people in such a way that they're reinforcing the way you've phrased the question that you've asked them. So here we see that we're being asked if we want to buy something and then the button label is buy. So I don't have to second guess or do any kind of interpretation to know which option is going to do which thing.

Also, the order that you show buttons in is incredibly important. On iOS, the button on the right is the affirmative action. We're going to answer the question by saying yes. It's also typically the default action, the most likely one. But there is a big exception to this. If the default action or the affirmative action is also a destructive action, meaning it's going to throw away data or throw away your progress in the game, you want to make sure that it's not on the right-hand side. A lot of people will just press the option on the right because they trust it's the thing that they're going to want to do or the safest thing. So you want to move it and put it over on the left-hand side.

Also, the design of the button is really important. The design of the button can help to suggest which option is the default one, the one that you as the game developer are encouraging people to press. Right now, or previously, those buttons were exactly the same. These are much better button designs because the one on the right is so much stronger. It seems like it's the one that people should select.

The best alerts are really succinct but descriptive. So this is a good alert. Game's over. That's all I need to say to people. And the buttons are also really succinct. Go to the menu. Play again. It's perfectly acceptable to use sentence fragments. You're not trying to write war and peace here.

Mike Stern Long messages like this are tedious to read. People want to play your game. Reading a lot of text and alerts and other parts of the UI will prevent them from doing that. So it's not a very good experience. You want to offer choices that are relevant to people, match the things that they want to do. So here, the game's ended. I can go to the menu or I can play again. Makes perfect sense.

If we presented these options, it wouldn't be what I wanted to do. So this is not a very good experience. And make sure that you use labels that people really understand easily. Menu, play again, totally get it. Those are really easy to understand labels. Now if I had some labels that matched the theme of the game, which is this futuristic theme, it might match that theme, but it makes no sense whatsoever. It would take a lot of interpretation to understand what's being said here.

You also want to make sure not to give people too many choices. You ask a simple question and you give people two very clearly distinct options, two very different options. If you just put a third option in there, all of a sudden you wind up having to think a lot more about what's being asked of you. It's really going to slow you down and be hard for you to proceed.

And just as important, having too few options can be really frustrating. If people feel like they're railroaded into a certain course of action, they're going to feel limited and frustrated. So we've unlocked this new paddle and I only have one option. I have to upgrade. It's not so good.

This is a much better UI because I'm being given a choice. Also, some messages do not require user confirmation. I won. I got it. OK. I'm likely to be concentrating and looking at the screen at this very point in time, right after I finished a level. So I'll see that I won. I know it.

Also, avoid showing multiple alerts or dialogues at one point in time. So here we're on a pause screen, and I'm going to press the restart button, and I'm going to be shown another alert, which asks me, am I sure I want to restart? And as I talked about before, that's actually kind of a good thing. You want to make sure if someone pressed that button accidentally, they're going to lose all the progress that they made in the game. So you want to be sure they want to restart.

But if you do that by just layering on top another alert, I don't know why, but I see this all the time in games, you can wind up having five or more options presented at one point in time. And here we see restart twice, and it can be confusing for people which one they're supposed to press. So I'm going to press restart, and restart and play there in the background, they have the same appearance. They have the same default appearance.

[ Transcript missing ]

Never, ever, ever show a close button on an alert. This is totally unnecessary. For one thing, usually in an alert, one of the buttons is actually just going to close it. In fact, sorry, all of the buttons in the alert are going to close the alert. So you don't need to show a close button. It's ambiguous. No one's going to know what's going to happen if they just close the alert.

Okay, let's talk about scroll views a little more. So earlier I talked about the importance of using gestures and not buttons for scroll views. I've actually used a lot of games that show a scroll bar on the right hand side and sometimes that scroll bar looks big enough and it looks like I can interact with it. But if you go and you press your finger on the scroll thumb and try to drag it down, you realize that it's actually not a control.

Or if it was a control, it wouldn't work very well. It would be too coarse of an adjustment and the list would scroll way too quickly or way too slowly. Now, scroll bars, there's a reason why we don't have them in iOS. For regular UIKit apps, they don't work well.

Now I think the reason why people show scroll bars is because they want to tell players of the game or users of the app that they can scroll, that there's more stuff below. And I think that's understandable, but luckily there's a few solutions for that. So the first one is you can quickly flash a scroll bar when you come to a screen that has a scroll view. Or when you press anywhere on the screen, you show that scroll bar. And that's what we do in a lot of our apps.

Or you can adjust the spacing of the items in the scroll list so that the last thing is partially off screen. And because of that, you imagine that there's more, and you intuitively know how to see the rest of the stuff in that list. Similar to that, you can fade out the scroll view at the very bottom. It's very similar to the previous technique. It lets you know that there's going to be something else beyond the bottom of the screen. Next up, let's talk about popovers. So popovers are these transient views that we use to display additional information or controls.

[ Transcript missing ]

That arrow is very important. It makes it clear what the popover relates to. So with that in mind, it's pretty important that the arrow is pointing at the thing that it relates to, not close to the thing that it relates to. I'm going to show you a little bit about the UI design. I'm going to show you a little bit about the UI design. I'm going to show you a little bit about the UI design.

[ Transcript missing ]

So now we know that if we press about or help or top scores or store, it's not going to give us the about popover or take us to help or show us the top scores or go to the store. It's just going to close the popover.

[ Transcript missing ]

And then press it again and press it again. It shouldn't just make new instantiations of the popover. Try this on your favorite game. You may find that it does exactly this. Obviously, the problem with this is you don't need multiple instances of this popover. And you're going to have to literally tap outside of it multiple times to close the popover or all the popovers that you've created. It's terrible.

And also, one more thing, you do not need a close button in a popover. As I said before, tapping anywhere outside of the popover should dismiss it, or even oftentimes tapping something inside of the popover should also dismiss it. Let's move on to page controls. So page controls are used widely in games. See them all the time for in-app purchase screens, or level choosers, or instruction screens.

But many times, of course, they're not actual UI kit page controls, but rather a reproduction of one. They're not a very good reproduction either. If you're going to reproduce this control, you want to pay attention to the details of how it works and get it right. So here's some important ones to keep in mind. Page control is all about swiping. You do not need the arrows for page control.

It's not necessary to do that. So get rid of them. Awesome flame transition. So one reason I think that people add these arrows is because they want to tell people, you know, you can increment one at a time. But you don't really need that. In fact, you can press on either side of those dots to go to the next or previous thing, item. And make sure that you accurately reproduce the swiping behavior. So there, I just grabbed the next item, I dragged it a little ways, but I didn't drag it far enough to select it, so it moved back. Didn't change my selection.

That's the correct behavior. Now, if I drag it a little bit further, It will snap forward to the next selection. That's the correct behavior. And notice that the thing I was dragging while my finger was touching the screen was always staying directly underneath my finger. Let's do that again and see what the wrong behavior looks like.

So I'm going to press my finger down on the screen. I'm going to slide it a bit to the left. Without lifting my finger, the next item is going to get selected. This prevents me from changing my mind mid-course. It's like the interface is being too eager to change to the next thing, and it undermines the sense of direct manipulation.

Finally, progress indicators. I know this is what you've all been waiting for. So. No one likes waiting, right? But it's just a fact of life. People have to wait sometimes. When your game makes people wait for more than a few seconds, if you're not showing any kind of feedback that something is occurring, they're going to begin to wonder what's going on.

How long are they going to be waiting for? Another few seconds? A couple minutes? A couple of hours? Did the game crash? So here's a couple successful tips for showing good, accurate progress feedback. If people will only be waiting for a short period of time, just show a simple activity indicator like this.

Let them know that something is going on, something is happening. But if it's gonna take, oh, and also, Even if this is kind of a little bit boring, honestly, this is much better for a game, right? Take this as an opportunity to entertain people, to do something kind of adorable and cute.

or you can take this time to educate people. So again, this is the game Badland. This loading screen is providing tips and tricks about how to use the game. So they're making a valuable use of people's time. When people are going to be waiting for longer periods of time, you want to provide specific information about how long something is going to take.

Get creative with your loading screens. Now this is from Plants vs. Zombies. It's totally stylized. Matches the motif of the game. Here's a different example from Cut the Rope. This is the progress bar that you see when you're about to go play a level in the game. They use this box knife to cut open the level.

And then when you leave the level, go back to the main menu, they tape it back up again. All right? It's thematic, it's clever, and it's informative. And for tasks that are really going to take a while to complete, it's really important to let people know how long they're going to be waiting for and to give them the option of bailing out, of canceling, not completing the task. Maybe they don't have enough time to wait, or maybe they don't want to wait for whatever it is that you're going to be doing. Give them the option.

Let's switch gears a little bit. It's also really important to be self-consistent in your game. This goes for every aspect of your design. So for example, I recently saw this in a game where there was a close button. They were showing this ad, and there was a close button to dismiss it.

But every time I saw the ad, they were picking a different place for that close button. It's like they couldn't decide what the best place was, so they just decided to go with all of them, which made it really unpredictable and confusing, because of course, I wanted to press the close button and not buy their other game that they make.

Another form of self-consistency is with iconography. There's many examples of this, but I'm just going to call out a few. So here we have this hand-drawn border for this button, and then we have this really clean geometric shape for the icon that's inside of that border. But they don't match each other. They should either both be clean and geometric, or they should both look hand-drawn.

This is a bit of a stretch, but it's also possible to be too consistent with yourself. So if you have an icon for play that looks too much like your icon for next level, it's going to confuse people, even if the icons have a slightly different treatment. A clearer distinction between the icons is going to be much easier for people to parse.

Now I really want to switch gears. So, done talking about matching standard behavior for iOS apps and games. I want to talk a little bit specifically about UI design challenges that I think are really particular to games. So when I was preparing the talk, I started thinking, one of the most important things for a game is to be a good teacher.

Now, when someone gets a new game, they don't know how to play it, they don't know what their objectives are, they have few, if any, strategies for winning the game and succeeding. So think about that. Be sympathetic. Give people help getting started. If they don't get that kind of help, they're going to get frustrated, they're going to quit, and they're going to delete your game, and you'll never see them again. There's plenty of games out there to play. Now the best tutorials make learning fun. They're easy to follow, they provide instructions about key game mechanics, and they set a mood and establish a plot.

Plants vs. Zombies is a game that I encourage you to look at. I think they really get it right. And when you download the game, the first thing you see is a choice to go through the tutorial. You can either skip over this lesson or go through and play the tutorial. And that's really important to give people that option. It's pretty much impossible to predict whether someone has played your game before. Maybe their buddy had that game on the iPad. So he already knows how to play the game. It's a smart idea to give people an option.

So let's go through the tutorial. Now, this tutorial is basically just a simplified version of this game. And the approach is great because it's going to teach beginners in context, not through an abstraction. You're told how to perform an action, and then you're asked to practice it. And the game confirms each success in learning about how to play. It's a positive and it's a rewarding experience. And it's fun. You don't feel like you're learning. You feel like you're playing the game. And in Plants vs. Zombies, there is a lot to teach.

Just getting to know each of the characters is a pretty time consuming process. There's a lot of characters. There's sunflowers and coins and shovels and plants that explode and plants that shoot things. And of course there's zombies. And each of these characters has a different role to play, has unique capabilities, has unique vulnerabilities, has different motivations.

The tutorial uses a technique that we in the UI world call progressive disclosure. This is a game that's really simple, but it's also a game that keeps people from feeling overwhelmed at any one point in time. So characters like this walnut, they appear one at a time, and when they're introduced to you, the game is giving you a brief description about what that character's capabilities are.

And when you start playing, you don't have a whole horde of zombies coming at you from all different directions. Gameplay is initially simplified by having just one row on the board. So it's a lot easier to see the zombies coming at you and deal with the situation at hand. Cut the Rope is another good case study. They use a technique called coaching tips to explain what the objective is, deliver candy to Om Nom. And they use coaching tips to provide instructions about the game mechanic, to swipe your finger to cut the rope.

Each new game mechanic is introduced one at a time, and each time a coaching tip is displayed. Tips are shown before and during gameplay, and they also introduce interface elements at appropriate moments. You can feel that the onboarding experience was very well thought through. Game mechanics, again, are introduced one at a time. Gameplay is initially very easy, so you feel good about your ability to play the game.

And by completing each level, you're effectively demonstrating that you're ready for more instructions and increasingly difficult challenges. But most importantly, you're always learning by playing. You're always having fun. By contrast, I've seen way too many games that do something like this. This is totally overwhelming. It's way too much information to process at one time, and you're never going to remember everything which is being told to you.

Another common technique is to display a series of images with instructions. And typically these give you way too much information at once. There's no way that people are going to remember all of this information that you're communicating to them. And it's overwhelming. Instead of playing the game, you're being asked to work.

Just as bad as being overloaded with too many instructions is being asked to go through an elaborate configuration process. New players do not understand how your game works, so it's premature to ask them questions about how they want to customize their gaming experience. Again, the goal of all of you should be to maximize enjoyment. If people get excited about playing your game, they're going to be inclined to start customizing it to create a richer and more personalized experience.

Now, above all, make sure people's first experience with your game is amazing. Whether that experience is a tutorial or customization even, or just diving in and playing the game, your game needs to be fun and entertaining from the very beginning. If, on the other hand, your game is boring or confusing or overwhelming, People are going to assume that your game is boring and confusing and overwhelming. And rightfully so.

Next up, wait to ask for feedback. So when you leave here tonight, imagine that you go to a restaurant, you're really hungry because we kept you here way past 6:00, and you're thirsty. So you want some food and drink. You want the waiter to bring you a menu. But instead he comes over and he says, hey, the manager of the restaurant wants us to have you fill out this survey to tell you what you think about the restaurant.

Right? What are you going to say? Nice silverware? Nice ambiance? Nice lighting? you don't know anything about the restaurant. In fact, you're annoyed at being asked that question. Right? Because you're hungry, you're thirsty. Now I know this is a bit of a ridiculous example, but it's totally applicable for apps and games.

When a game asks players to provide feedback before they've really gotten to know the game, they're not going to write a very substantive review. And they're probably going to be annoyed at being asked to provide feedback so early. And it's kind of self-defeating. You actually want to ask people for feedback if they've been playing your game for a while. Because if they've been playing your game for a while, they probably like your game more than the average person who downloaded it. Thank you.

And also advertise thoughtfully. So people who play PaddleMania 3000, they love PaddleMania 3000. Call themselves PaddleManiacs. Great. I love them. So, it's understandable that if I make a new game, I'm going to want to advertise that to them. Do you want to talk to them about Cosmic Paddle? They might be interested in that. But you want to exercise good judgment. People are going to get annoyed if you overwhelm your own game's interface with a bunch of advertisements. It's going to take them out of the experience, and it undermines that engagement that you're trying to work so hard to establish.

And also, don't try to trick people into clicking on ads. Now, I've seen this a number of times, and maybe it's just a sheer coincidence. But I'm looking at a menu screen like this, and I'm about to press the Play button. And right before I do, up pops an ad.

And off to the app store I go. I don't really want to buy this game, and it's just totally annoying. So this is just one example. There's many others. But you don't want to try to trick people. You don't want to be deceptive. Respect the people who play your game.

Now Cut the Rope, I think, does a pretty good job of advertising to people. So we're in the level chooser screen, and over on the left-hand side, we see these little things poking out there. And if we swipe over to see what those are, they're ads in the level chooser. A little unexpected, but OK. They're innocuous, and I kind of understand that they're ads for other games, and I can choose to tap those or not.

And additionally, on the menu screen, there's a little ring there connected to a rope. And if I pull that down, I'll see another promotion. So clearly, they're not shy about advertising to the people that play their game, but they're not trying to deceive people into pressing one of those advertisements and purchasing the other games they make.

And also, it's really important to not cut corners. You want to have high quality in your games, high production value. A big part of what makes games great are the awesome graphics, the beautiful sounds, But games with really great source material, really great artwork and sound design can be hampered by really easy to avoid production mistakes.

Here's some quick tips for making sure that you put your best foot forward. First up, design for retina displays. It's really important to use artwork that's the correct resolution. It's high resolution. It looks great on a retina screen. Low resolution graphics will make your game look fuzzy or jagged. Yes, we know that those graphics take up more space, but they're worth it.

They show off all the great artistry and care and time and attention that went into the design of your game. Next, don't stretch graphics. So let's say we have this button that we designed for our game, but we have another button which has a longer title, so we need it to be wider.

So what do we do? Well, if we just stretched it as one piece, it would look terrible. The rounding on those corners doesn't look right at all. Again, it's also going to look jagged or blurry. So what you want to do is use a three-part image, meaning you take the left cap and the right cap, and you reposition those. And then you take a slice from the center, and you either tile it or you stretch it.

Also, when it comes to video and sound, timing is everything. We know when audio is played too early. or too late. Make sure that your audio clips are trimmed so that they can be timed perfectly to events in the game. And for background music, add some variation. It's okay to loop background music, but looped music can get old really quickly. So it's best to have some variety. Play different loops for different levels or different modes of the game. Okay.

So I've covered a lot of ground here today, I think. But before I go, I, as promised, want to talk a little bit about iOS 7. Now, at first blush, you might believe that the changes to the look and feel of iOS 7 don't really affect you. Maybe you're right. But I'm not so sure.

So what I want to share with you are the principles that influenced and inspired the redesign of iOS 7. Because in my opinion, those principles are just as relevant to all games as they are to all apps. So what are those principles? Well, there's really three core ones. Clarity, deference, and depth.

I'll explain what those are. So clarity is a really straightforward concept. It's just about being clear. So UI design at its essence is really just about communication. So the most successful interface designs are the ones that are the easiest to understand. So a quick example. Here's weather. Weather makes it really easy to understand what the current weather conditions are.

Deference is about getting out of people's way. It's about allowing content to be front and center. As much as possible, the interface should not interfere with that experience of engaging with content. It shouldn't cover up visual content or be too distracting. So let's look at Mail. Mail exemplifies this characteristic of deference. Photos go edge to edge. They're big, so it's easier to see the detail in them. Text is easy to read, and if you have a hard time seeing, you don't have perfect vision, you can increase the size of text so it's even more legible.

And the navigation bar at the top and toolbar at the bottom are visually subdued, so they're not trying to compete with the content for your attention. In fact, they kind of blend in to the message, making the message seem like it's stretching to the full height of the screen. And depth. Depth is about using layering.

and animation to establish and reinforce hierarchy within apps and on the platform as a whole. It's also about creating a more profoundly vibrant and lifelike experience through how things move in response to touch or movement of the device. Now, in my opinion, I think these principles are just as relevant to games as they are to any app. So let's start with clarity.

Clarity is a principle that can be applied to just about everything that we've talked about today. Being internally consistent helps to provide clarity. Giving useful and informative feedback makes your game more clear about what's going on. A tutorial that teaches you while you play your game is far more clear than learning by seeing a series of abstract images, a series of static images.

and low resolution graphics that make it hard to see the details and character and background artwork is quite literally making your game less clear. The principle of clarity can be applied beyond what we've talked about today as well. So consider the copy that you display and how you can be more clear with that.

Ask yourself, are you saying too much? Are you using words that people understand? Let's apply clarity to typography. Is text large enough? Sometimes I think that game developers have exceptionally good eyesight, superhuman eyesight, because text is always so incredibly small and hard to read. Is the font face you're using legible? It's pretty hard to read. It's not very clear at all. It's much easier to read.

And is there sufficient contrast or visual interference with background elements that makes it hard to read the text? This is much easier to read. Deference is about getting out of people's way and allowing their content to be front and center. Forcing people through a series of complicated customization screens before they're even allowed to play the game is not very deferential. If you overlay heads-up displays or health meters or other status information over your game, those elements shouldn't get in the way of your ability to see characters and the game environment.

So consider the heads-up display in Real Racing 3. They do a really good job of getting out of your way. You can see key race information like the track or your speed, but it doesn't limit your field of vision or cover up the amazing graphics they have. Being deferential is all about maximizing the size and prominence of what's most important to people. Secondary elements shouldn't be too distracting.

[ Transcript missing ]

In iOS 7, we use this parallax effect for the home screen. I think this effect is a natural fit for games. Platformer, side-scroller games could use parallax to create a greater sense of depth between foreground and background layers. Even my terrible Paddlemania 3000 game is enhanced by that.

And depth also refers to animation. We use 2 and 1/2D animations for navigating hierarchical views. You zoom in and out when going between the grid view or single image view in the Photos app. This helps to establish and reinforce hierarchy. There's no reason why that type of animation wouldn't work really well for games. Using zoom animations when going in and out of a level chooser is an obvious fit.

So that's all I have for you today. That's all we have for you today. I want to thank you very much for being here and encourage you guys to stick around and share some drinks with us. We have some refreshments outside. Thank you very much. It was a pleasure being here.