Design advanced games for Apple platforms

Hi I'm Linda, from the Design Evangelism Team. If you're new to developing games for Apple platforms, it's never been a better time jump in. Every model of our desktop and mobile devices can handle advanced console-class games. And with a unified gaming platform, your game can now support amazing graphics and performance across Mac, iPad and iPhone. Making it possible to get your game in the hands of even more players.

And with the new "Designing for games" section in the Human Interface Guidelines, as well as the the latest version of the Game Porting Toolkit, which you can learn more about in the video: "Port advanced games to Apple platforms", you'll have the resources to simplify your development process, and save time. Meaning, it's easier than ever to make games for Mac, iPad, and iPhone.

In this talk, Dylan and I will go over how to design your game to deliver a great player experience on Apple platforms. I'll show you how to adapt your game's interface across devices, and then Dylan will take you through how to design your game's input. So let's start with designing for the device. Delivering a great game experience means being considerate of how your game's defaults, layout, text, and controls will feel for your players on Apple devices. The first thing you want to consider, is how you can let people jump into gameplay as soon as possible. And that begins the moment someone first installs your game on their device.

High-end games tend to have larger initial downloads. So imagine for your players, they've been patiently waiting for your game to install. They're super excited to play it. It launches and they get a message that says they need to wait for another download. This is probably not the first-launch experience they were looking forward to. Especially since players on Apple platforms expect their apps to work right out-of-the-box.

Instead, you can minimize waiting by enabling people to play your game as soon as installation finishes.

To do that, make sure the initial stages of your game are downloaded at launch.

Aim to get around the first 15 minutes of gameplay bundled into your App Store download.

From there you can start loading in the next chapters of your game in the background.

What players will experience is a seamless jump from launching your game to playing your game all without waiting while you're handling additional downloads behind-the-scenes.

Try to hide download progress from players. In many cases they'll never have to know that data is still loading in, and it will feel like your whole game was playable at launch.

If a player does manage to progress far enough to hit an unloaded area, that's when it's a good idea to acknowledge through your UI, that the game hasn't fully installed yet.

Look for a place to then show download progress. Ideally put this somewhere relevant where it doesn't distract from gameplay, like a level selection screen.

And also consider allowing players to revisit earlier chapters or levels as they wait, so they're not just stuck looking at a progress bar.

In order to download game data behind-the-scenes, you can take advantage of either On-Demand Resources, or Background Assets. Both of which are Apple frameworks, that let you to pull down additional game data after your app installs. On-Demand Resources are hosted on the App Store, whereas Background Assets are hosted on your own database. You can learn more about both of these on the developer website.

But no matter how you load in your assets, the end result you're aiming for is an installation experience that blends with gameplay, and is invisible to the player.

Another way to design for Apple devices, is to set great default settings.

There's a lot of info you'll get right out of the box about a player's Apple device. Like the hardware model, screen resolution, or any paired accessories. These are all things that you don't need to ask players to optimize for themselves when they start your game.

You can simplify your game's onboarding by setting options automatically for players.

For example, in your onboarding and settings, look for places to remove choices that aren't relevant. Like asking for screen size or aspect ratio, which you just get from the device itself.

Instead of having folks manually set up a physical game controller, you can automatically detect whether a controller is paired and get its profile by using the Game Controller Framework.

This will let you map the player's physical buttons to your UI, right from launch.

When choosing defaults across different platforms, consider adjusting your game's initial performance settings to match the capabilities of that device. For example, you might choose to set quality defaults higher, for a top-of-the-line Mac, than you would for an iPhone.

And especially on mobile platforms, remember that players just want to pick up their device and go. So look for opportunities where you can reduce the granularity of your settings, compared to what you might offer on a desktop.

Here, you can condense a lot of upfront choices into just one player decision. Whether they want to prioritize quality, or performance.

Choosing great defaults removes steps, and lets your players start having fun a lot faster.

So now that you've set great defaults, let's dig into your game's layout, and how to make it flexible for each Apple device. With a unified gaming platform, your game can easily ship across a variety of screen sizes. Plan early on to design an adaptive game interface that scales. This will not only save you time designing across screens, but will also help future-proof your game when new devices launch. The simplest place to start, is to make sure your layout reacts to different aspect ratios.

Even across the same platform, different device models can still have different aspect ratios.

One way to handle this in your UI, is to scale your interface up or down to fit into other devices.

But this method can lead to imprecision of where controls end up. It can make UI less reachable for people's hands, feel too small or too large. And can just end up looking misaligned with the device itself.

Instead, break your UI layout into separate sections. Each of which is anchored to a specific side of the screen.

As you move between device shapes, you can keep each section at a consistent size and distance away from those anchor points.

This keeps controls at physically comfortable sizes for mobile players.

While making the best use of screen space across devices.

Using this method, your UI can go from something that doesn't look or feel quite right, to a layout that feels comfortable and purposeful.

So now that you've got a layout that adapts, let's make sure your hard work is always visible. You can do that by designing for the full screen. On Mac, iPad and iPhone, designing a full screen gaming experience means keeping safe areas in mind.

Safe areas are regions of the display where you can safely put UI so that it doesn't overlap with hardware or software features.

On iPad and iPhone, safe areas help you avoid placing UI where it could get obscured by the devices' rounded corners. They also help you avoid the system Home indicator as well as the Dynamic Island on iPhone, which can both potentially overlap your control's tap targets.

On Mac, the safe area is inset from the top to help you avoid the device's rounded corners and the area around the camera.

Designing within safe areas, will ensure every part of your UI is visible and accessible to your players.

To help you with this, you can find safe area templates in the Apple Design Resources, which are available to download from the developer website.

You can also try building your game to the Simulator App within Xcode. In Simulator, you can preview your game's layout on different device models, bezels, and orientations. And check whether any UI isn't where it should be.

Remember, safe areas are meant as guides for positioning UI, but aren't meant to be the actual margins for your entire game.

Take advantage of every pixel on the screen for your game's environment.

If there's important content in your game that's getting clipped by device proportions, first try adjusting your game's camera, playing with different zoom levels and angles to see if you can fit that content in.

In some cases, such as cinematic cutscenes, you might have pre-rendered content that's already set to a specific aspect ratio.

In those cases you can make use of letterboxing to fit all the important details on the screen.

To make letterboxing still feel like a full screen experience, you can to either fill that area in with custom game artwork, or tint it black to blend in with the device's physical hardware bezels.

But only use letterboxing if you have to, your game will always feel more immersive if it makes use of the entire screen.

Okay, one last point to make your game look great on Apple devices make sure your UI is legible.

This is especially important if you're bringing a console or PC game to Apple devices with a smaller display. What may look great on a large TV, can be barely legible if it's shrunk down to compact sizes without adjustments.

One of the smallest considerations that can make the biggest difference in your gaming experience is to make sure your text is large enough to read. The more compact the device, the larger your text size should be. On each platform, there are recommended default and minimum type sizes. On iPhone and iPad, aim for a type size of 17 points or higher. This size works great for body text and callouts. For less essential information, try not to go lower than an 11 point type size, or you risk your players not being able to read what's on the screen.

On Mac, a comfortable default text size is 13 points or higher. While a minimum of 10 points will still keep your text legible.

Just like you want players to be able to read your game's copy, you also want them to be able to comfortably interact with your controls.

Make sure your controls are large enough to make them easy to select. This is especially important for games on our mobile platforms. Where your players may be using touch as their input and need larger affordance for their fingers. On iPhone and iPad the default tap target size you should aim for is 44 by 44 points. This is a comfortable size for most people's fingers to easily select controls.

For less critical UI, you can push this down to 28 points, but keep in mind that buttons at this size can be harder to select accurately, especially if your players have their attention on your gameplay.

On Mac, you should aim to make the hit area of your controls 28 by 28 points. Which gives enough room for a pointer, like a mouse or a trackpad, to land on.

For less important or infrequent controls, you can reduce that to a minimum of 20 points.

For both text and buttons, aim for the defaults rather than the minimums it'll make your game more comfortable for more players.

Now if you're wondering how you'll fit these larger sizes onto more compact screens. Remember that people are very used to scrolling on mobile, and you can take advantage of scroll views to show more UI.

So for example, instead of needing to cram all your game settings onto the screen at once. You can utilize scrolling to take advantage of more vertical space. Which also gives you breathing room to increase the size of controls. Same thing with text. Use scroll views if you have an overflow of information, instead of reducing type sizes to solve the problem.

If you're ever in doubt, about whether players can read your text or reach your controls. There's nothing I recommend more than testing it out on a real device. Experiencing it yourself, will give you the best sense of whether your game's UI looks and behaves correctly. Better yet, try your layout on as many devices as you can, with as many testers as you can. That way you can be confident players will feel comfortable no matter what hardware they're playing on.

Alrighty. So we've gone over best practices for designing for Apple devices, from quick ways into gameplay, to flexible layouts, to making your game legible. Now, I'll hand it over to Dylan to talk about input.

Thanks Linda! Hi, I'm Dylan, from the Apple design team. And I'm going to talk about how to adapt your game's input scheme to Apple platforms. I'll discuss considerations for each input method, and then I'll dive deep on how to design great touch controls by adapting movement and camera, placing controls intuitively, responding to gameplay, and providing feedback. Let's kick things off by taking a look at the various input methods available on Apple platforms. With comprehensive support for familiar inputs like keyboard, mouse, and game controller, it's easy to bring your game to Apple platforms. The control schemes you use on other platforms should more or less directly transfer to iPhone, iPad, and Mac, with some small considerations. For one, we support a broader range of controllers than most other platforms, each with their own set of glyphs printed on their controls.

You can accommodate this in your design work with the SF Symbols app, which provides an enormous library of glyphs like these and many more. But you shouldn't bake this art into your game. Instead, use the GameController framework to get the appropriate symbols for your controller. This ensures your game will be ready to handle any new controllers or remapped controls.

When implementing keyboard support, consider that the modifier keys on Apple keyboards are arranged in a different order than typical PC keyboards, and so you should validate that your control mappings are comfortable and adjust as necessary.

In addition to mouse, keyboard, and controller support, Apple is especially unique in our support for high-end games on touch-first platforms. And while some players may play your game on their iPhone or iPad with a controller, the vast majority of players won't have a controller available. to maximize the reach of your game, and to provide a great experience for people who want to play on the go, you can go the extra mile by designing custom touch controls.

Designing for touch is a bit different from designing for controller. Traditionally, you have a rich design space within your game to react to the static inputs of your controller.

But on touch screens, your input surface is also the output. Designing your game means designing your input too, because touch controls are dynamic and can be informed by the game itself. I have here a game I've built with a straightforward port of console controls to the iPhone. In its current form, the controls clutter the screen, obscuring content and making it difficult to comfortably and reliably press the right buttons. Let's deconstruct this control scheme and show how we could better adapt it to touch input. I'll start by showing how to adapt movement and camera controls. from physical thumbsticks to touch. For a 1st or 3rd person game like mine, I create a virtual replacement for the physical left thumbstick control. The dynamic nature of a touchscreen means I can hide this control when it's not in use, to avoid obstructing the game.

While thumbsticks traditionally have fixed physical dimension, you're not bound by those constraints on touch. And because players can't physically feel where their hand is relative to a tactile control, it's important to expand the input area to be as broad as possible.

My game makes use of a thumbstick press on the controller to sprint, but my virtual thumbstick can't do that. I could create a button for this functionality, but it's very cumbersome to use and requires me to stop movement to toggle it.

So instead, I'll take advantage of the large dynamic range of the touch surface, to incorporate the Sprint function directly into the virtual thumbstick, instead of using an additional button.

For camera control, which is typically on the right thumbstick I could use another virtual thumbstick to port my controller input to touch, but this isn't making the best use of the touch screen.

Instead, I'll use direct touch input to pan the camera. Notice how as I drag my finger left, right, up, and down, I'm directly manipulating the position of the camera. This provides very fast and precise movement, more akin to the speed and precision of a mouse input rather than a joystick. And just as I said for movement, the input area for this control should be as broad as possible.

In a game with an overhead or isometric perspective there are a couple different considerations. While a virtual thumbstick may be sufficient for movement, you should also consider letting a player tap to move. And while panning to move the camera transfers over well, you can add inertia to help quickly traverse large distances, and use a two finger pinch to zoom in and out. These behaviors will be familiar to people using iOS, as they appear all over the system, like here in Maps. Now that i have my core movement and camera functionality sorted out, I'll talk about how to place controls for all of the other actions in my game.

As Linda described previously, I'll need to be mindful of safe area insets, and avoid the regions at the edge of the screen. But I also want to avoid placing controls in the areas where I expect movement or camera input to happen, and of course I want to avoid covering my character, so I won't place any controls in the center of the display.

This leaves me the regions around the thumbs, which are ideal for placing frequent or important actions, and the region at the top of the screen, which is a great place to put less frequently used controls, like menu buttons. Because players will likely be playing your game with only their two thumbs, you need to consider which controls might need to be used at the same time so that you can place them on the appropriate side of the screen.

A common pattern with controllers is to use a left trigger or L2 button for zooming the camera to aim, while R2 performs an aimed ability. This control scheme doesn't translate well to touch as-is. It prevents me from aiming and moving at the same time, or aiming while using my R2 action.

If I swap these controls, I can zoom and aim at the same time with my right thumb, while using my left thumb to move or fire.

My controls are now well-placed, but I could really elevate them with some new dynamic behaviors that are only possible on a touch screen. There are a few simple guidelines to follow that will make your game feel more at home on a touch-first platform. To start, instead of showing static controller button glyphs, you should use glyphs that better represent your control's action. When a control changes its behavior based on context, you should update its symbol accordingly, and importantly, when an action isn't available or relevant, you should remove it entirely to avoid cluttering the screen.

Applying this to my game I'll replace the standard console button glyphs with descriptive glyphs for each control, and remove controls entirely when they're not available, such as my Fire button that's only available when aiming.

When the player begins aiming, I'll update which controls are visible, revealing the Fire button and hiding everything else.

I can even use my controls to reflect details about the state of the game. Here I'm using the Fire button to visually represent when the ability will be available to use again.

And of course, when I show my menu, I hide all my controller UI completely. It's crucial that your menus respond to touch, virtual controls cover up content and make navigating menus cumbersome. Now I've fully adapted my game's control scheme to touch, but there's one key element missing: feedback. Because touch screens don't have the tactile feedback of physical controls, you need to provide feedback in other ways. It's extremely important that any touch control you create has a press state. Press states give the player confidence that they've pressed a button, and without them, controls feel unresponsive. This could be as simple as darkening or highlighting buttons when pressed, but in the context of a busy game, you might want to draw visual effects like a glow outside of the bounds of the control. This helps provide feedback even when a finger is covering the button itself. You can also theme these effects to better integrate them into the visual style of your game.

Sound and haptics are another great form of feedback, and can even go beyond the feel of a simple button press. You can add subtle haptics on touch down and touch up to provide a sense of responsiveness, in addition to designing sound and haptics for the actions that your controls will perform. Now with feedback built into my controls, I've finished adapting my game's inputs, and have created a control scheme that leans into the benefits of a touch screen.

If you want to go even deeper into our recommendations for input, check out "Game controls" in the "Inputs" section of the Human Interface Guidelines. Linda and I have covered a lot of ground between designing for the device and designing for input. We hope that with this guidance, your players will be able to jump straight into gameplay that looks beautiful across all of their Apple devices, and that they'll be able to play your game with whichever input is most comfortable for them, whether that's keyboard and mouse, controller, or even your newly designed custom touch controls. To learn more about the technical details of bringing your game to Apple platforms check out: "Port advanced games to Apple platforms" Thanks for watching!