Windows 8.1 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 improving the user experience and increasing engagement.
Several capabilities new in Windows 8.1 are of particular importance for games:
- Live tiles and notifications—Games can invite and engage players from the Start screen with tile activity that indicates scores, achievements, challenges, and invitations from other players. Notifications during game play or other user activities can encourage players to return to your game faster and more frequently.
- Share contracts—Agreements between apps enable your game to connect with other apps already installed on the system, in the Windows Store, or on the web, making it a more social experience for users.
- Support for a variety of user interactions—Windows 8.1 provides support for touch, pen, keyboard, mouse, and external game controllers.
- Sensors—Windows 8.1 has support for modern sensors including light, gyroscope, accelerometer, and location.
- Support for a variety of form factors and screen sizes—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 window size or screen size for an optimal gaming experience.
- Windows Store—The Windows Store provides new opportunities for app developers to distribute, promote, and sell their games and in-app features. The Windows Store makes it easy to offer a free trial without writing any code.
Throughout this article, you'll learn how these capabilities affect the design and development of games for Windows 8.1. We will demonstrate these principles with the following games: Cut the Rope, Microsoft Solitaire, Tankster, PuzzleTouch and Cannon Ball.
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.
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 complex progress or multiple ongoing games, like a turn-based game played with friends, consider allowing users to pin game saves or specific matches to the Start screen 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.
Consider that users can choose between different tile sizes (small, medium, large, and wide). The more compelling the visuals or information on a tile are, the more likely users are to devote screen space to them. Experiment with different tile sizes, color, and content to find the best fit for your game. Declare the desired tile size in your app manifest and include the appropriate assets for other tile sizes as well. For more info about tile size in the app manifest, see DefaultTile. For more about tile updates, see Tile schema.
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.
Upon opening your game, the splash screen is the first thing your audience will see. It serves as a smooth transition between the launch of 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 background music or 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.
The extended splash screen approach is also helpful at times during gameplay when your app must fetch resources, such as when it's loading a new level or preparing to play a rich cut-scene. If your game ever appears to stop responding for more than 0.5 seconds, it should show a progress control to the user such that they know the app is still processing and has not crashed.
To add audio/visual interest while the app is loading, you may also play background music and include a concurrent animation that supports your game's branding.
When it comes to navigation and commands, games can involve rich, complex strategies that need tiered menus to host myriad options or they 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. The navigation pattern you use should be informed by the type of experience your game provides. You should review and understand the hierarchical and flat navigation patterns. Often, it’s not the game itself but other content within it that helps determine your navigational structure.
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. Don't bury the content behind menus. Every time your game is played, your carefully crafted experiences are right in front of the player. If gameplay 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).
For help choosing the best navigation pattern for your app, see Navigation patterns.
With a hierarchical pattern, you can put all your content in front of users on the main hub page, 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.
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 header. 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 implementing semantic zoom so that users can move easily between sections. A user that is in a particular section of the main hub can pinch to semantically zoom out and quickly navigate to other sections of the app.
Microsoft Solitaire Collection uses semantic zoom to let a user 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 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.
The following figure 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.
Additional Layout Considerations: Apps should maintain single direction scrolling. If you have a horizontally panning hub page all fields within your app should also pan horizontally. There shouldn't be instances of vertical panning. For example, if you have a long leaderboard that traditionally would be shown vertically, wrap the content so it's shown in a column layout. If you're 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.
Touch interactions: Direct manipulation is strongly encouraged as a way to control a game. Windows 8.1 supports powerful multi-touch interactions (up to 5 inputs), which lets users do things like pan or zoom and command at the same time or move a player or game camera and shoot simultaneously. Be sure 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, such as a virtual 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. The W, A, S, D, and arrow keys are natural keyboard equivalents for navigation that you can include parallel to a virtual D-pad. If you’re displaying a D-pad or button controls on the game canvas, consider letting users customize the size and position of the controls, or position them relative to 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 tablet.
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. 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. If your game uses mouse-look controls to drive the game’s virtual camera, consider incorporating some platform best practices referenced in Developing mouse controls.
Multiple input modes: Games should support touch, as well as keyboard, mouse, game controller, 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. Avoid manual settings that force users to turn touch controls on or off or to choose a specific input mode. 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. Games with multiple pages can use navigation commands, which are typically placed in the top app bar, and other secondary commands, which are typically 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 the following figure, no controls are on the canvas. Users play the game via direct manipulation. The user turns the platforms either with touch or mouse to guide the ball along the coin path. However, when they swipe up from the bottom or right-click on the mouse, an app bar appears, pausing the game and letting the user change which weapon is equipped.
When the game is paused, the user can pull up the app bar to restart the level.
You could also consider placing a Play/Pause toggle icon on the screen to resume gameplay.
In Cut the Rope, the Undo button is important enough to take up space on the canvas. It is available in the upper-right corner because it is a frequent action for this game.
You can style app bars, buttons, and progress bars to reflect the brand or personality of your game. These elements can be any shape, color, and size that you want them to be.
To learn more about how to lay out controls in an app bar, see Command patterns.
Sensor integration in Windows 8.1 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 desires. Windows 8.1 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.
Use contracts to enrich the experience of your game and connect it with the rest of the Windows 8.1 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. 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 about when you use the search box. To learn more about search, see Guidelines for search.
Share: The Share contract lets you connect a gamer to other gamers, social media outlets, or friends by letting the user 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. You can share a wide variety of different formats (through URLs, email, social apps, and cloud services) and users can 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.
Devices: Implementing devices is a great way to let users connect gamepads and other peripherals to their computer in preparation for playing a game and to enable users to display game content on a larger screen. Users can also print from the Devices charm.
Windows 8.1 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, provide a path to this information in the Settings charm. Alternatively, you could make tutorials available as a part of your gameplay. An example is shown in the following figure, where the Cut the Rope app makes the tutorial part of its initial game-playing experience.
For more information about providing in-app help and tutorials, see Guidelines for teaching UI.
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's 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 dedicates 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.
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, bottom, 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 window size or layout changes. The user should then be able to un-pause and play within the new window size or layout if it is supported. A game should not only rely on loss of focus to determine that it should pause. Consider including a button in your game to let users pause the action and multi-task. 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.
A user can resize an app from full screen down to a minimum width, can rotate a device or screen to portrait or landscape orientation, and can place multiple apps side by side on the screen. Your game must support variable window sizes and orientations. Be careful to maintain your game's state when resizing windows so that the player's experience is smooth and continuous. Going from landscape to portrait view should not take the user back to a home screen, but rather should show the user a resized version of the page they were already on.
The minimum width that your game must support is 500 pixels; however, you can increase user engagement by supporting a minimum width of 320 pixels. Your game should be playable down to the minimum width you choose and should simply adjust its presentation to the space provided.
You can adapt to smaller widths in your game. The nature of your game can help determine which way you choose to adapt.
- Resize and letterbox: Maintain a fixed-aspect ratio and letterbox the game for smaller widths. This method works best with games that have inflexible content that cannot by dynamically arranged to fit alternate window sizes. Instead of letterboxing the content with black, consider using a matching color or pattern from your game. Cut the Rope uses this method.
- Pan, crop, and zoom: Allow the user to play certain sections of the game at a time in a panned, cropped, or zoomed state. PuzzleTouch uses this method.
- Adapt: Adjust the layout of the game's content so that the user can still play but in a different layout. You can incorporate multiple game screens or pages into the view to use the available window width in the most efficient way. For example, place the game screen at the top of the screen and place leaderboards and achievements below it. Microsoft Solitaire uses this method.
If focus moves from the game to another app that is on the screen, the game should adjust or pause appropriately.
Making your game playable in narrow widths 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, play a move in a turn-based game, or play a board game in a narrow view. If your game has a secondary activity, like chatting with friends or browsing a map, that activity can be the focus at narrow widths as well.
In the following example, Cannon Ball is playable at a narrow width. The game elements are stacked, rearranged, and resized to fit in the narrow window and the page scales to allow the user to see more of the level.
Consider what the touch interactions will be like when the user resizes the window to a narrow width. With a smaller width, 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. It is possible that not all of your commands will fit on an app bar when the app is narrow. If this is the case, consider grouping commands together or providing a more focused experience that requires fewer commands. Remember that standard app bar button labels are hidden by default when the windows becomes too narrow to display them, so be sure to choose icons that are easily identifiable.
If your game is not playable at a smaller size, 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 resized to a larger width. The game should not lose its state or context when paused or resized. If the user resizes the app back to a larger size, the user should be able to continue the game seamlessly. For more information about windows sizes, see Guidelines for window sizes and Guidelines for resizing windows to tall and narrow layouts.
It is crucial to consider how the game will scale to different screen resolutions and DPI settings. Stretching or shrinking your game typically doesn't make it look better because your game assets may become blurry or disproportionate. Rather than directly scaling, consider having a 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. For more information on scaling to screens visit Guidelines for Scaling to Screens.
Your game should follow the state model for Windows Store apps. It should remember its last state and take the user back to that state 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.1. For more info about state management, see Guidelines for app suspend and resume.
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.
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 you consider them 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.
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 played entirely 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.
Games provide a lot of rich content that users can interact with and a great Windows 8.1 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.
Build date: 11/16/2013