Windows 8 provides unparalleled reach across a range of devices, from touch and pen-centered tablets with modern sensors to high-resolution laptops and desktop PCs. This reach offers a unique opportunity for game publishers to develop experiences for a variety of scenarios. In this article, you’ll see how your game can embrace Windows principles and UX guidelines, while simultaneously improving your users’ experience.
Several capabilities new in Windows 8are of particular importance for games:
- Live Tiles—Games can engage players from the Start screen with tile activity that indicates scores, achievements, challenges, and invitations from other players.
- Share and Devices contracts—Agreements between apps enable your game to connect with other apps already installed on the system, the web, or devices making it a more social experience for users.
- Support for a variety of user interactions—Windows 8 provides support for touch, pen, keyboard, mouse, and external game controllers.
- Sensors—Windows 8 has support for modern sensors including light, gyroscope, accelerometer, and location.
- Support for a variety of form factors and views—Games can be played on a variety of form factors from large screens to tablets. Game controls can be displayed in different layouts dependent on screen size for an optimal gaming experience. Additionally, users can play immersive games using the full screen or while doing other activities in part of the screen.
- Windows Store—The Windows Store provides new opportunities for app developers to distribute, promote, and sell their games and in-game features. The Windows Store makes it easy to offer a free, time-limited trial without writing any code. Developers can also instrument a feature-limited trial if they wish. Trials are the easiest way to increase conversion rates.
Throughout this article, you'll learn how these capabilities affect the design and development of games for Windows 8. We will demonstrate these principles with the following games: Cut the Rope, Tankster, PuzzleTouch and Cannon Ball.
"Best At" Statement
Before designing your game, take the time to write a "best at" statement, which describes the experiences you want to provide your users. What scenario is your game best at and what makes it better than other games that fulfill the same scenario? Use your "best at" statement to guide your design process and make decisions on what scenarios and features you will and won’t include.
The "best at" statement for Cannon Ball is to provide users with a simple and exciting game that allows them to create music by guiding a ball through a series of platforms and collecting coins. During planning of the game, this statement guided decisions on what scenarios to support. To guide a ball to collect the coins, the user needs to be able to change the angle of the platforms. To allow for this scenario, touch, keyboard, and mouse input control was implemented. This statement was also used to decide what scenarios not to support. For example, it was decided that the app would not support the scenario of saving the music created during gameplay. The ability to save music did not add to gameplay and thus was not implemented.
Live Tiles, Secondary Tiles, and Notifications
Games can use live tiles to draw users into their game from the Start screen. Use a live tile to display information about the player’s most recent scores, accomplishments, or their current game state. If your game is updated with new content such as game objects or levels, you could display this information on the live tile to draw users into the game to play with the new content.
If your gameplay involves multiple ongoing games, like a turn-based game played with friends, consider allowing users to pin certain games to Start as secondary tiles. This will allow a user to jump directly into a particular game that they care about. To learn more about Live Tiles, see Guidelines and checklist for tiles and badges.
An additional way to keep users engaged with the game while they are doing other things is to use toast notifications that alert them when it is their turn in a turn-based game or if a friend has beaten their high score. Follow the guidelines in Guidelines and checklist for toast notifications when implementing toast notifications.
Figure 1: The Live Tile for Cannon Ball uses the TileWideImageAndText02 tile template. This tile template allows the developer to display a colorful game image and provide up-to-date information about the user’s high score and amount of treasure collected. See The tile template catalog for details on other tile formats.
Splash Screens and Progress Controls
Upon opening your game, the splash screen is the first thing your audience will see. It serves as a smooth transition between when people launch your game and when it is ready to play. Many games can take longer than the maximum 3 seconds to load due to the large number of assets they have. If that's true of your game, be sure to provide an extended splash screen with a progress ring to indicate to the user that the game is actively loading. For more information on splash screens, see Guidelines and checklist for splash screens.
This approach is also helpful at times during gameplay when resources must be fetched, such as when loading a new level or preparing to play a rich cut-scene. If your app ever appears to stop responding for more than 0.5 seconds, a progress control should be shown to the user such that they know the app is still processing and has not crashed.
To add visual interest while the app is loading, you may also include a concurrent animation that supports branding.
Layout and navigation
When it comes to navigation and commands, games can involve rich, complex strategies that need tiered menus that host myriad options or can be as simple as lightweight puzzle games, which might not have any menus or options. Some games present achievement screens, leader boards, multiplayer lobbies, and more, whereas others give the user only one experience—the game itself. A great Windows 8 game will make sure that navigation between multiple experiences is fast and fluid, and the navigation pattern you use should be informed by the type of experience your game provides. You should review and understand the two patterns – hierarchical and flat - discussed here before continuing. Pick the appropriate pattern to help users find the content they want. Often, it’s not the game itself but other content within it that helps determine which model you pursue.
If you include multiple rich experiences in your game—above and beyond the game itself—use a hierarchical pattern to bring all your content to the top level (as opposed to burying it behind menus). Every time your game is played, your carefully crafted experiences are right in front of the player. But if your game is the only experience, consider a flat pattern, which allows users to swiftly navigate between multiple sessions in the game (for example, multiple one-on-one games against friends). See Navigation design guidelines for Windows Store apps to learn more about the navigation models.
Hierarchical pattern
With a hierarchical pattern, you can put all your content in front of users, delighting them and making their first experience a complete one. On your game's hub, show entry points into the game—such as level selection, a new game, or continue a game—as well as recent achievements, friends lists, and other areas of content, all on the same horizontal panning surface. This offers a way to show players updated and fresh content each time they view the hub, enlivening it with activity even when a user isn't playing the game itself. Each area can present content that players interact with directly. Use section headers as navigation points to reach a deeper view of content for that category. You can also use the hub to convey some of the personality and branding of your game. For example, if a user selects a particular level, the section page background could change to reflect the level that the user is viewing.
The game's hub also offers a way to show players updated and fresh content each time they view it, enlivening the hub with activity even when users aren’t playing the game itself. For instance, consider the achievements experience modeled in Figure 1. It divides achievements into categories and provides information about each individual achievement all at once, telling users what it is and how close they are to unlocking it.
Figure 2: Microsoft Solitaire Collection uses a hierarchical pattern to let a user navigate through many different game experiences.
Within the game, you should always provide a way back to the hub. Often, this is provided via a back button located in the top app bar, which is the appropriate location for any navigation commands. The key is, users should feel as though they are navigating naturally through the game’s content to get to what they want rather than searching through menus. Consider allowing users to utilize Semantic Zoom to hierarchically move between menu sections. If a user is in a particular section of the main hub, they can pinch to semantically zoom out and quickly navigate back to other sections of the menu.
Figure 3: Microsoft Solitaire Collection uses Semantic Zoom to allow a user to quickly move between hub sections.
The hierarchical pattern should let users move from experience to experience and be constantly immersed in the game’s content. This is a great choice for games with a lot of different options for gameplay or games with a lot of secondary experiences.
The flat pattern
The flat pattern keeps your game experience front and center. It’s a great layout for games that don’t have other standalone experiences. With the flat pattern, instead of taking the user to a sparse hub, use the top app bar as your navigational home. Present the user’s different sessions there and let the user move seamlessly between them. If there is a preliminary state before your game starts or if you have a paused game, consider presenting a screen that shows the user your game's branding and provides a place to identify as a “home” within the game. You don’t need to show the top app bar when your game starts. For example, the Internet Explorer app brings users to the Web page they were last on and relies on them to invoke the app bar to navigate tabs.
Figure 4 shows a game that doesn’t offer any experiences beyond the game sessions and the means to navigate between them. Rather than trying to move a small amount of functionality into a hub, it uses the flat pattern to put all of the game’s content in front of its users to let them quickly and confidently navigate it.
Figure 4: In Tankster, users interact directly with the game, not through a hub.
Additional Layout Considerations: Apps should always maintain single direction scrolling. If you have a horizontally panning hub page all fields within your app should also pan horizontally. There should be no instances of vertical panning. For example, if you have a long leaderboard that traditionally would be shown vertically, wrap the content so it is shown in a column layout. If you are concerned about a long list of information, consider letting the user use Semantic Zoom to jump from one end of a long list to another end.
Gameplay Interactions
Touch Interactions: Direct manipulation is strongly encouraged as a way to control a game. Windows 8 supports powerful multi-touch interactions (up to 5 inputs), which lets users do things like pan/zoom and command at the same time or move their player or game camera and shoot simultaneously. Be careful to design your interactions such that any user, even users on a device without sensors or touch-capability, can play your game with mouse and keyboard.
Using virtual controls (e.g. an invisible D-pad to control a character’s movement or sliding a finger left and right to steer a vehicle) allows you to avoid cluttering the canvas with buttons and controls and leave plenty of space for users to interact with the game. If you’re using a virtual joystick or button controls on the canvas, consider letting users customize the size and position of the controls, or make them relative so that they appear wherever a user places his or her fingers or thumbs. No one-size-fits-all placement is ergonomically pleasing to all users. For a default placement of a virtual joystick control, consider where the thumb is when a user is holding a slate.
Consider whether the user's touch interactions could accidentally invoke edge behavior such as pulling in another active app from the left side of the screen or pulling up the charms bar. In-game commands and interactions with them should always be at least 20 pixels from the edges of the screen so that they don’t interfere with UI elements such as charms or app bars. Consider adding some sort of visual "barrier" that discourages the user from swiping near the edges, or modify your controls to avoid accidental edge swipes. You should also not have game commands that require the user to move the mouse to the corners of the screen as the system uses the corners to open charms and pull in other active applications when a user is using a mouse.
Multiple Input Modes: Games should support touch, as well as keyboard, or mouse, or pen. For a great experience on all form-factors, games should support all input modes wherever possible and the control scheme should be as fluent and consistent as possible regardless of input mode. Input switching should be handled dynamically in real time. For example, if a touch event is detected, fade in the controls that apply to touch; if a mouse click is detected, fade out the controls that only apply to touch. Handle input switching as dynamically as possible. Do not add settings that allow users to turn touch controls on or off or choose to use a mouse. Do not prompt a user and ask what input method they would like to use to play the game. Ideally your game should support all control modes seamlessly and equally without any need for mode switching.
App Bar Commands: If possible, design your game so a user can play it by directly manipulating content on the canvas rather than using commands that act on the content. If additional commands or navigation controls are required, users will expect to find them in the app bar. Navigation commands are placed in the top app bar and commands are placed in the bottom app bar. Commands that are always available, such as starting a new game, should go on the right side of the bottom app bar. On the left side, add any contextual commands —those that depend on a user’s location in the hub or depend on what’s selected within the hub. For example, if you have a list of saved games in your hub for a role-playing game, you can expect a user to select one saved game and invoke the bottom app bar, anticipating that a Delete command will appear on the left side of the bottom app bar.
Ask yourself two questions to help determine if a control should be on the canvas or the bottom app bar:
- Will this control be used frequently?
- Is this control crucial to playing the game?
If you answer "yes" to either question, it may be a good choice to put the control on the canvas. This ensures that the users won’t become frustrated by constantly having to reveal the app bar just to make progress in the game.
In Figure 5, no controls are on the canvas. Users play the game via direct manipulation. However, when they swipe up from the bottom or right-click on the mouse, an app bar appears, letting the user pause the game or change which weapon is equipped.
Figure 5: Cannon Ball can be played with direct manipulation. A user turns the platforms either with touch or mouse to guide the ball along the coin path. If a user needs to restart a level they can pull up the app bar to do so.
Figure 6: In Cut the Rope, the Undo button is important enough to take up space on the canvas. It is made available in the upper-right corner because it is a frequent action for this game.
You can easily style App bars to reflect the brand or personality of your game. Buttons and progress bars can be styled as well. Figure 4 shows a stylized App Bar. The app bar can be any shape, color, and size that you want it to be.
When thinking about how to lay out controls in an app bar, consult the app bar guidance. To learn more about controls, see Commanding design for Windows Store apps.
Sensors
Sensor integration in Windows 8 represents a new breed of interaction opportunities for games and interactive entertainment experiences. With access to accelerometer, compass, gyro, light sensors and more, gameplay can be as dynamic and immersive as the designer’s desire. Windows 8 also offers Sensor Fusion to enable precise orientation and location data that games can use to their advantage.
When developing a sensor enabled game, consider the range of possibilities and determine what supports your core scenarios. Make sure you choose the right sensor for the job.
- You can use accelerometers for steering cars or tilting game elements.
- You can sense device movement to rotate a character or a camera viewpoint.
- Shaking the device can be an exciting way to defend against enemies or reset a game board in a puzzle game.
- You can use a light sensor to change the mood or lighting of a game’s rendering to enhance immersive interactivity.
- You can use a microphone or even a camera to integrate realistic environment elements in to the game.
- You can achieve augmented reality by integrating the camera, Sensor Fusion and rendering "secret" elements on a hidden object game.
The possibilities are vast and while not all sensors make sense for all games, with a little creativity a simple gesture or movement can replace a lot of menus or commands. For more information about what sensors can be used, see the Liven Up Your App with Location and Sensors post.
Contracts
Use Windows 8 contracts to enrich the experience of your game and connect it with the rest of the Windows 8 experience. To learn more about contracts, see App contracts and extensions. The following are some examples of useful contracts to implement.
Search: Games can provide a number of interesting search scenarios. Think about what a user would like to be able to Search for from anywhere within the game or from another app. For example, consider enabling Search for looking up a friend's standings or statistics, finding a friend to play a game with, or finding a particular game item that you have acquired. In these cases, follow existing search guidelines rather than using on-canvas search controls. Users will be familiar with using the Search charm for additional discovery within the game. To learn more about search, see Guidelines and checklist for search.
Share: The Share contract lets you connect a gamer to other gamers, social media outlets, or friends by letting them share a particular achievement or status, or even screen shots and short clips of gameplay. You can also use this contract to share data between games. For example, sending a particular item built for a role-playing game to a friend for use in his or her game or sending a custom puzzle for a friend to solve.
When choosing what to share, consider how you want to convey your brand to style the shared information. It is possible to share a wide variety of different formats (through URLs, email, social apps, and cloud services) and users will be able to share to friends who may not have your game or are even on other platforms. Communicating your brand effectively in any shared piece of information could therefore even draw more users to your game.
If your game can consume data from other apps and transform it in an interesting way, you should consider defining your app as a Share target. For example, the game PuzzleTouch receives a photo from the Photos app and transforms it into a puzzle per the user's preferences. To learn more about Share, see Guidelines and Checklist for Sharing.
Figure 7: PuzzleTouch is a Share Target. It allows users to create puzzles from their own pictures.
Devices: Implementing devices is a great way to let users connect gamepads and other peripherals to their computer in preparation for game play and to enable users to display game content on a larger screen. Users can also print from the Devices charm.
Settings and Options
All your game's settings, options, privacy policy, About, Credits, and Help content should be accessible via the Settings charm. The Settings charm is where all Windows 8 apps host their settings and options, so it is the natural place for users to look when they want to adjust the game’s sound effects or change an aspect of gameplay. Modifying settings should not be handled on the game surface or in the app bar unless it is a frequent gameplay activity. Users will know to look to the Settings charm for settings so there should be no menus that duplicate the functionality of the Settings charm or any UI elements that serve only to open the settings panel.
Windows 8 provides a global volume control, but many games may want to have their own, more complex sound settings (such as separate volume sliders for music, sound effects, and voice, which users can tune independently). Include a label that makes it clear that the audio settings are specific to your game. Settings' sliders and buttons should provide real time feedback rather than requiring a secondary action of an Accept or OK button to commit the changes.
If your game includes initial gameplay training or help, such as tutorials, place this information in the Settings Charm. Alternatively, you could make tutorials available as a part of your gameplay. An example is shown in Figure 8, where the app makes the tutorial part of its initial game-playing experience.
Figure 8: In Cut the Rope, the game tutorial is a part of the initial gameplay experience.
Player Accounts
Player accounts are useful for tracking a player's progress through your game, linking the player to social networks, and enabling revenue models. By supporting player accounts, you can create a more engaging experience that keeps users coming back and allows them to play with their friends.
User sign-in: If it is critical to your game's experience that the user sign-in, such as in a social networking game that requires access to a user's data and social connections, dedicate the game's "landing experience" to signing in instead of presenting the player with an unplayable game. When possible, try to derive sign-in information from a user's Microsoft account or from cached sign-in information from previous sessions of the game.
If your game is playable without sign-in, but signing in is strongly encouraged (for example, if the game's revenue model depends on the user signing in for advertising downloadable content that the user does not yet have), the game can either dedicate space on its hub to signing in or dedicate its landing experience to it. If it takes space on the hub, the game should clearly communicate to users that they are not signed in. After the user is signed in, remove the sign-in section entirely or replace it with content unique to the user. If your game dedicated the landing experience to sign-in, it should give the user an option to skip signing in and, if the user chooses not to sign in, should respect that decision and not take the user back to that page at the start of subsequent sessions of the game. In these cases, you can use space on the hub to handle signing in.
For cases where sign-in is optional, the sign-in experience should be located in the Settings pane. The Settings pane could be open when the app starts to help the user find the sign-in experience.
In all cases login should also be available in the Account Management pane within Settings.
Account Management and Signing out: Accomplish account-management scenarios, such as updating a user’s email address or changing passwords, in the Settings pane. Similarly, any sign-out experience should also be hosted in Settings, along with options.
Pausing the Game
Not every game needs to support pausing. Turn-based games, for example, generally have no concept of being paused. In addition, games driven entirely by a user, with no other external factor such as a timer or clock, gain nothing by being paused. In these cases, pausing the game when users navigate away isn’t necessary. When users go back to the game, it should present them with the same experience they were having before they left. If that's not possible (for instance, if a multiplayer gaming session has ended), then the game should clearly communicate to users the state they are in.
For games that do have meaningful pause scenarios, register for loss of focus and pause the game when a user swipes a finger from the left or right edge of the screen, or when a system dialog box appears. If you have a fast paced or timed game, the game should pause when the view or layout changes. The user should then be able to un-pause and play within the new layout if it is supported. A game should not only rely on loss of focus to determine that it should pause. Consider including a pause button in your game. Determine the location of the pause command based on the same command placement considerations discussed in the "Gameplay Interactions" section of this topic.
Communicating Paused State: Communicate to users when the game is in a paused state. You can present a pause overlay or pause screen. For puzzle, strategy, or timed games, obfuscate the game canvas while the game is paused so that users don’t gain an unfair advantage by pausing to study the game board.
Make it as easy for users to un-pause the game as it is to pause it. Both a pause overlay and a pause screen should contain some way for users to un-pause the game. If the user navigates to the hub page be sure to pause the game. When the user returns back to the game or un-pauses the game, the game should resume in the same state.
When users un-pause your game, consider giving them a moment to orient themselves before resuming the action. A countdown is a good way to do this.
Games that present time-flow controls—city-builder games, for example—can "pause" the flow of time, but this is not the same as pausing the game. Pausing is the complete cessation of user interaction with the game, although some background rendering may continue so that animations continue to play.
Changes in Orientation and Window Size
An app can be in one of four visual states: Full screen landscape, full screen portrait, Snapped, or Fill. Your game must support full, fill, and Snapped and optionally portrait view. Be careful to maintain state when switching between views. Going from full view to portrait view should not take the user back to a home screen, but rather should show them a modified version of the page they were already on.
When your game is in the fill state, it should be playable and should simply adjust its presentation to the space provided. This can easily be achieved by letter-boxing the game screen, however consider filling the whole filled view by slightly rearranging the game elements or zooming and cropping to fit. If focus moves from the game to the snapped app, the game should adjust (or pause) appropriately.
Making your game playable in snapped view enables multitasking and lets users continue playing while doing other things on their system, keeping them engaged with your game longer. This approach is particularly great for lightweight, casual games that can occupy the user’s attention without necessarily occupying the entire screen. For example, a user could continue solving a puzzle or playing a board game while in snapped view. If your game has a secondary activity (like chatting with friends or browsing a map), that activity should be functional in snapped view as well.
Figure 9: Cannon Ball is playable in snapped view. The game elements are re-sized to fit on smaller screen size and the page scales to allow the user to see more of the level.
Consider what the touch interactions will be like in snapped view. With a smaller screen size it may be easier for users to unintentionally invoke edge actions. Consider how you can modify your controls to avoid accidental edge swipes. It is also important to consider command placement in snapped view. It is possible that not all of your commands will fit on to an app bar in snapped view. If this is the case, consider grouping commands together or provide a more focused experience that requires fewer commands. Remember that icon labels are hidden by default in snapped view so be careful to choose icons that are easily identifiable.
If your game is not playable in snapped view, or if it reaches a state where further progress requires more screen space, it should pause and explain to the user that further action is impossible until the app is no longer in snapped view. You can include a un-pause button, which unsnaps and resumes the game, but the game should not attempt to programmatically unsnap by itself, without user action. Try not to surprise the user by moving the game out of snapped view when they do not expect it. There should not be a UI element solely for snapping or unsnapping the game. For more information on snapped view, see Guidelines for Snapped and Fill Views.
Figure 10: Cut the Rope is not playable in snapped view. It shows a pause screen and allows the user to select "Continue" if they want to un-snap and resume the game.
It is crucial to consider how the game will scale to different screen resolutions. Stretching or shrinking your game will not make it look better because different displays have different aspect ratios. Rather than directly scaling, consider having an adaptive layout that adjusts what is visible depending on the resolution. For example, on a larger screen, you can display more content, such as showing more of the level, rather than just stretching the view. Or if you choose not to do an adaptive layout, Windows 8 provides theme-able letterboxing regions for apps using XAML or HTML, so you can easily maintain an immersive experience with proper aspect ratio on any screen. For more information on scaling to screens visit Guidelines for Scaling to Screens.
State Management and Saving
Your game should follow the state model for Windows Store applications. It should remember its last state and take the user back to it when the game is activated.
Any game that is suspended should be already paused, unless it's a game that does not have a meaningful pause mode. If an app does not have a pause mode, reentering the game should take the user directly back to the game experience.
In a persistent multiplayer game, if the session the user was in has ended, the user should be presented with a post-game screen or be informed in some way that the game session ended.
These state-management guidelines are independent of the concept of "checkpoints," "saved files" or multiple saved games within a game. They pertain solely to the process life cycle in Windows 8. For more info about state management, see Guidelines for app suspend and resume.
Roaming to the Cloud
Create a continuous experience across devices by roaming game state and settings so that a user can pick up a game right where it was left off, regardless of the device they're using. Make it easy for users to use your game everywhere, from their family’s kitchen PC to their work PC to their personal tablet, by maintaining settings and states with roaming. For more info, see the Guidelines for roaming app data.
Accessibility
Windows users have a wide range of abilities and disabilities. If your game can be re-imagined to allow people with disabilities to play, make sure to accommodate these users. People with disabilities can use the accessible app search functionality to find your game if you mark your game as accessible when submitting to the Windows Store. Incorporating accessibility principles into your app ensures that your game can be used by a wide audience and helps attract more customers to your game. Accessibility features are easy to include in a Windows Store app, particularly if considered early on in the design process. Adding features for accessibility can make games better for all users. For example, allowing game controls to be re-mappable or placed based on where the user places their hands allows both right and left handed users to play in the way most comfortable to them.
There are several important scenarios to consider when designing for accessibility.
Design for Visual Impairments: Blind or visually impaired users use screen readers to develop a mental model of your game UI. For a screen reader to work, all UI elements within your game must be appropriately labeled with a name, role, description, state, position, and any other relevant information. It is important to consider what your UI will look like when system-wide accessibility options (Ease of Access settings) are enabled, such as "Make everything on your screen bigger" or high contrast mode. You may need to create alternate assets for high contrast mode or add additional code to adjust your game visuals when the user enables the system-wide high contrast mode. Be sure to use a color-blind friendly color scheme and if there are places in your game where color is used to convey information, make sure this information is conveyed in another way as well, such as with text, shapes, or icons.
Figure 11: Cannon Ball can be played in high contrast mode. To enable this, the developers created an alternate set of assets that were called when the system was set to high contrast mode.
Design for Keyboard Accessibility and Alternate Inputs: The keyboard is critical for using a screen reader and for users who use alternate input mechanisms such as switch controllers or eye trackers. Make sure that all UI elements can be navigated using the tab and arrow keys. UI elements should be able to be activated using the spacebar and enter keys. Commands and controls should be accessible with keyboard shortcuts. Consider how you can make your game playable with only the keyboard. For example, in Cannon Ball, the platforms can be turned with the arrow keys, allowing the game to be entirely playable with keyboard input.
Design for Auditory Impairments: If your game makes use of audio cues or speech to convey information there should be subtitles available for deaf or hard-of-hearing users. There should be visual substitutes for all audio elements and the mood and meaning of the game should be conveyed even without sound. If you have multiple different sounds going on at one time such as sound effects and dialog, provide separate volume controls for each to help with comprehension.
Design for Cognitive Impairments: Gameplay should allow for a wide range of difficulty levels and game speeds if possible. Consider how users with learning or cognitive impairments would play your game. Could your game be played by someone who is learning to read? If possible offer a sandbox or free play mode with no time constraints for users who may have limited mobility or learning disabilities.
Wrapping Up
Games provide a lot of rich content that users can interact with and a great Windows 8 game puts that content front and center for the user, removing unnecessary pieces of UI that stand in the way. By following the advice and guidelines outlined here, you can tailor each component of your game for the best gaming experience.
Thank You
Thanks to Andy Atkinson, Jessica Noglows, Todd Landstad, Keith Rowe, Nazia Zaman, Dan Keller, Brian LaVee, Bonny Lau, Shai Hinitz, Lora Heiny, Phil Napieralski, Kevin Lambert, Chantal Leonard, Sara Summers, Mark Hopkins, and Clemens Lutsch for their outstanding support and guidance in writing this article.
Related topics
- Commanding design for Windows Store apps
- Making great Windows Store apps
- Navigation design for Windows Store apps
Build date: 3/12/2013
