Directives du programme Handheld Compatibility

Le programme Handheld Compatibility, conçu par XBOX, permet de donner aux joueurs l’assurance que les jeux fonctionneront bien sur un appareil de jeu portable. Pour qu’un jeu fonctionne parfaitement sur un appareil portable, quelques considérations supplémentaires sont nécessaires par rapport à son comportement dans un environnement de bureau PC. Les jeux sur appareils portables restent des jeux PC. Pour bien fonctionner sur un appareil portable, ils doivent tenir compte d’un petit écran tenu à 30 cm (12 pouces) des yeux, avec des entrées provenant d’une manette plutôt que d’une souris et d’un clavier. Il existe cinq directives principales à prendre en compte. Ce document présente ces cinq directives dans leurs grandes lignes et décrit comment les respecter.

Directive 1 : les paramètres par défaut fonctionnent directement

Les joueurs attendent des expériences similaires à celles d’une console sur les appareils portables. Ils ne devraient pas avoir à chercher un menu et à modifier un paramètre pour faire passer le jeu en mode portable. En utilisant uniquement la manette, ils doivent pouvoir naviguer dans tous les éléments du jeu. Même si les joueurs peuvent souhaiter personnaliser et varier les options de rendu (niveaux de noir, ombres, performances ou qualité), ils s’attendent néanmoins à bénéficier d’une bonne expérience par défaut. La clé pour que les paramètres par défaut « fonctionnent directement » est de savoir que vous êtes sur un appareil de jeu portable. Utilisez le code suivant pour déterminer si le jeu s’exécute sur un appareil de jeu portable.

#ifndef DEVICEFAMILYDEVICEFORM_GAMING_HANDHELD
#define DEVICEFAMILYDEVICEFORM_GAMING_HANDHELD    0x0000002E 
#endif
  
DWORD DeviceForm; 
RtlGetDeviceFamilyInfoEnum(nullptr, nullptr, &DeviceForm); 
  
if (DeviceForm == DEVICEFAMILYDEVICEFORM_GAMING_HANDHELD) 
{ 
   // Do stuff for a handheld 
} 

Au lancement, le jeu peut vérifier si l’appareil est un appareil de jeu portable. Si c’est le cas, le jeu doit choisir les paramètres par défaut qui offrent une bonne expérience :

Choisir une résolution et des paramètres adaptés aux capacités typiques d’un appareil portable.
Modifier l’entrée par défaut pour attendre une manette et afficher un clavier virtuel lorsqu’une saisie de texte est attendue.
Agrandir les polices (voir la section Directive 4 : lisibilité de l’interface utilisateur ci-dessous).

Lors du développement pour des appareils portables, ne vous contentez pas de détecter que le jeu s’exécute sur l’un d’eux. Réfléchissez également à la manière dont le recours à une manette, plutôt qu’à une souris et un clavier, affecte l’expérience du joueur. Cela a un impact sur la façon dont les joueurs naviguent dans l’interface et sur la façon dont vous gérez le focus. Vous devrez peut-être également résoudre des problèmes liés aux entrées, comme la précision réduite d’une manette par rapport à une souris. Des fonctionnalités telles que l’aide à la visée peuvent aider à compenser cela. Pour commencer à vous assurer que « les paramètres par défaut fonctionnent directement » sur un appareil portable, les guides d’accessibilité suivants sont d’excellentes ressources :

Directive 2 : iconographie

Les indications à l’écran, comme l’iconographie, aident le joueur à comprendre comment naviguer et jouer. Assurez-vous qu’aucune indication ne suggère des méthodes d’entrée qui ne sont pas disponibles nativement sur l’appareil portable, ce qui créerait de la confusion.

Directive 3 : saisie de texte

Les jeux conçus pour PC supposent généralement la présence d’une souris et d’un clavier. Sur un appareil de jeu portable, l’entrée par défaut est la manette. Lorsque votre jeu nécessite une saisie de texte, assurez-vous que les joueurs peuvent saisir du texte en utilisant uniquement la manette avec un clavier virtuel. Déclenchez des claviers virtuels chaque fois qu’une saisie de texte peut être nécessaire. Deux approches courantes consistent à lancer le clavier virtuel soit lorsqu’un « toucher » est détecté sur la zone de texte, soit lorsque la zone de texte a le « focus d’entrée » et que le bouton A est enfoncé. Vous êtes libre de créer votre propre clavier virtuel. Vous pouvez également utiliser le clavier virtuel intégré à Windows. Le code suivant montre comment votre jeu peut lancer puis masquer le clavier virtuel Windows en mode manette.

#include <winrt/windows.ui.viewmanagement.core.h>
using namespace winrt::Windows::UI::ViewManagement::Core;
#pragma comment(lib,"windowsapp.lib")


// CoreInputViewKind::Gamepad enum requires headers from 26100.3624 Windows SDK or greater
// Otherwise, use static_cast<CoreInputViewKind>(7) for earlier SDKs

CoreInputView::GetForCurrentView().TryShow(CoreInputViewKind::Gamepad);

CoreInputView::GetForCurrentView().TryHide();

Ce code obtient l’interface ICoreInputView3 appropriée et appelle la méthode TryShow en lui transmettant l’identificateur du nouveau clavier virtuel compatible avec la manette. TryHide masque le clavier s’il est actuellement affiché.

La méthode TryShow n’affiche le clavier que si Windows détermine que son affichage est approprié. Par exemple, l’appel de cette méthode sur un appareil auquel un clavier physique est connecté (entre autres distinctions) peut ne pas afficher le clavier virtuel. Sur un appareil portable doté d’un écran tactile, cet appel fonctionne comme prévu.

L’API ci-dessus n’a aucune dépendance au GDK. Il s’agit d’une API Windows introduite dans Windows 10 version 10.0.17763.0, publiée en octobre 2018. Toutefois, l’énumération CoreInputViewKind::Gamepad nécessite le Windows SDK 10.0.26100.3624 ou une version ultérieure.

Directive 4 : lisibilité de l’interface utilisateur

Les petits écrans de 7 pouces sont courants sur les appareils de jeu portables. Ces petits écrans peuvent rendre difficile la lecture du texte de l’interface utilisateur du jeu. Pour ces petits écrans, les recommandations destinées aux développeurs de jeux sont les suivantes :

Si l’écran est en 1280 x 720, la hauteur du texte en pixels doit être d’au moins 9 pixels. Nous recommandons une hauteur de 12 pixels ou plus.
Si l’écran est en 1920 x 1080, la hauteur du texte en pixels doit être d’au moins 14 pixels. Nous recommandons une hauteur de 18 pixels ou plus.

La lisibilité du texte est une source majeure de problèmes d’accessibilité. De nombreux jeux le reconnaissent et proposent un paramètre de taille de police dans le jeu. Une façon d’assurer la lisibilité du texte consiste à définir automatiquement l’une de ces tailles de texte plus grandes par défaut lorsque vous détectez que le jeu s’exécute sur un appareil portable. La plupart des jeux utilisent des polices bitmap, mais celles-ci ne s’adaptent pas automatiquement à la taille de l’écran, au DPI ou à d’autres paramètres Windows. Si vous utilisez des polices bitmap, proposez des choix de tailles de texte plus grandes. Si vous utilisez une police TrueType dans votre jeu, vous pouvez utiliser DirectWrite pour le texte. DirectWrite peut tirer parti de fonctionnalités clés de Windows telles que la mise à l’échelle des polices, le DPI et d’autres paramètres Windows.

Directive 5 : affichage pris en charge

Les jeux utilisent toute la surface de l’écran pour offrir une excellente expérience. Les jeux ne doivent pas être affichés avec d’importantes bandes noires (letterboxing) ni rendus dans des rapports d’aspect qui déforment le gameplay. Avec les petits écrans typiques des appareils de jeu portables, d’importantes bandes noires peuvent rendre ces écrans encore plus petits, ce qui affecte le gameplay.

Autres considérations

En plus des cinq directives énumérées, consultez Considérations supplémentaires lors du développement de jeux GDK pour les appareils portables Windows.

Introduction

Onboarding & Access

Setup & Install

Build Your First Title

Directive 1 : les paramètres par défaut fonctionnent directement

Directive 2 : iconographie

Directive 3 : saisie de texte

Directive 4 : lisibilité de l’interface utilisateur

Directive 5 : affichage pris en charge

Autres considérations

​Directive 1 : les paramètres par défaut fonctionnent directement

​Directive 2 : iconographie

​Directive 3 : saisie de texte

​Directive 4 : lisibilité de l’interface utilisateur

​Directive 5 : affichage pris en charge

​Autres considérations

Directive 1 : les paramètres par défaut fonctionnent directement

Directive 2 : iconographie

Directive 3 : saisie de texte

Directive 4 : lisibilité de l’interface utilisateur

Directive 5 : affichage pris en charge

Autres considérations