Rapport du projet de recherche
Usage de la Kinect associé à l’utilisation d’un clavier
Recherche 2011/2012 ELSENSOHN Christophe SCHEIBEL Jean-Baptiste
Etudiants en Master 1 Informatique
Sommaire
INTRODUCTION ... 3
REMERCIEMENTS ... 4
I. PRESENTATION ... 5
A. LA KINECT DE MICROSOFT ... 5
B. UNREAL DEVELOPMENT KIT ... 6
II. MISSION ET METHODE DE TRAVAIL ... 7
A. OBJECTIFS... 7
B. DIFFERENTS TRAVAUX EFFECTUES ENTRE LA KINECT ET UDK ... 7
C. DE L’ETUDE A LA CONCEPTION ... 7
D. METHODE DE TRAVAIL ... 8
III. KUI : KINECT UNREAL INTERFACE ... 9
A. OBJECTIFS... 9
B. CAHIER DES CHARGES ET IMPLEMENTATION ... 9
1. Pilotage de KUI ... 9
2. Calibrage ... 10
3. Détection de postures ... 10
IV. UDK : UNREAL DEVELOPMENT KIT ... 12
A. OBJECTIFS... 12
1. Unity 3D ... 12
2. CryEngine ... 12
3. UDK ... 13
B. CAHIER DES CHARGES ET IMPLEMENTATION ... 13
1. Etape 1 : La modélisation ... 13
a) Choix du logiciel de modélisation 3D ... 13
b) Modélisation des objets ... 13
c) Importation des objets modélisés ... 14
2. Etape 2 : Création de la scène dans UDK ... 14
3. Etape 3 : Développement ... 14
4. Jeu final ... 15
V. INTEGRATION DE KUI DANS UDK ... 16
A. OBJECTIFS... 16
B. CAHIER DES CHARGES ET IMPLEMENTATION ... 16
VI. LE LOGGER ... 18
A. OBJECTIFS... 18
B. CAHIER DES CHARGES ET IMPLEMENTATION ... 18
VII. INTERPRETEUR DE LOG ... 20
A. OBJECTIFS... 20
B. CAHIER DES CHARGES ET IMPLEMENTATION ... 20
VIII. TESTS UTILISATEURS ... 22
A. OBJECTIFS... 22
B. PREPARATION ... 22
1. Les postures et actions implémentées ... 22
2. Questionnaire ... 23
C. ANALYSE DES RESULTATS ... 24
1. Analyse de la scène de jeu ... 24
2. Analyse qualitative ... 24
a) Résultat du questionnaire ... 24
b) Mode de pilotage favori ... 25
c) Commentaires des utilisateurs ... 26
3. Analyse quantitative ... 27
a) Précision de la saisie ... 27
b) Analyse du pilotage ... 28
4. Synthèse ... 30
CONCLUSION... 31
REFERENCES ... 32
I. BIBLIOGRAPHIE ... 32
II. WEBOGRAPHIE ... 32
Introduction
De nos jours, le domaine de la reconnaissance de gestes est de plus en plus prisé dans le monde de la recherche. L’interaction gestuelle bouleverse complètement les moyens de communiquer et d’interagir avec une application. Ces dernières années, de nombreux progrès ont été réalisés. Il est désormais possible de détecter des silhouettes et de les suivre sans aucun accessoire (gant, télécommande, manette, …). Cette technologie pourrait s’utiliser dans de nombreux domaines, tels que la robotique, la domotique, la médecine, la communication et les jeux.
La sortie de la Kinect de Microsoft en novembre 2010, vient mettre en application ces recherches, qui étaient initialement destinées à la console de jeu Xbox.
D’autre part, la saisie de texte au clavier est un problème selon plusieurs ergonomes. Plusieurs recherches ont été réalisées afin de trouver une solution pour faciliter la frappe et éviter les erreurs.
L’objectif de ce projet de recherche était de combiner la saisie à l’usage de la Kinect. Ainsi, il sera possible de saisir facilement les lettres d’un clavier avec son corps.
Intéressés par les nouvelles technologies, ce projet de recherche nous a tout particulièrement attirés et motivés. Nous avons été d’emblée séduis, la Kinect étant une technologie jeune et en pleine expansion.
De la recherche à l’élaboration, nous présenterons le déroulement du projet qui s’est opéré en 5 étapes. La recherche était un point très important. Il était nécessaire de comprendre le fonctionnement de la Kinect. De plus, afin d’élaborer le cadre de l’application, nous avons utilisé un moteur physique 3D. Ne connaissant pas un tel environnement, une phase d’apprentissage des différents moteurs était nécessaire. C’est pourquoi nous présenterons tout d’abord ces divers outils.
La réalisation d’un projet de cette envergure doit être exécutée de manière professionnelle afin d’aboutir à des objectifs satisfaisants. Nous relaterons donc notre mission et notre méthode de travail dans une seconde partie.
Ensuite, nous détaillerons le développement de KUI1 permettant de contrôler la Kinect et de détecter différentes postures.
De plus, pour réaliser l’ensemble de l’application, la conception s’est axée autour du moteur physique UDK2 que nous exposerons en détail.
Puis, nous expliquerons le fonctionnement de la communication que nous avons mis en place entre KUI et UDK.
Enfin, nous décrirons l’éditeur et l’interpréteur de logs, permettant d’analyser le comportement gestuel des différents utilisateurs et nous en ferons l’analyse.
Nous insisterons sur les phases de recherches, les prises de décisions, les problèmes rencontrés et résolus.
1 Kinect Unreal Interface
2 Unreal Development Kit
Remerciements
Nous tenons tout d’abord à remercier tous les intervenants extérieurs qui nous ont permis de nous guider dans la réalisation de notre projet : Monsieur MINICH, « Le site du zéro », Epic Game.
Nous remercions également toutes les personnes qui ont consacré de leur temps pour réaliser des tests utilisateurs.
Enfin, nous remercions Monsieur MARTIN Benoît, notre tuteur à l’université Paul Verlaine.
I. Présentation
A. La Kinect de Microsoft
Provenant du projet « Project Natal » de la société israélienne PrimeSense, la Kinect est un périphérique de Microsoft destinée initialement pour la console de jeux vidéo Xbox 360. Elle est constituée de plusieurs capteurs :
Une caméra VGA couleur.
Deux capteurs de profondeur : Ils détectent jusqu’à six silhouettes dont ils peuvent analyser une représentation 3D de deux personnes.
Un microphone multidirectionnel : Il capte la voix et la situe dans la pièce.
Figure 1 : Description des capteurs de la Kinect
Le SDK1 de la Kinect appelé « NUI Library » développé en C++ et en C# permet d’utiliser les informations retournées par les 3 capteurs et d’interpréter les résultats. La fonctionnalité la plus utilisée correspond à la représentation 3D d’une personne détectée. Elle suit vingt points du corps humain qui seront ensuite exploités dans l’application.
1 Software Development Kit
Figure 2 : Utilisation de la Kinect dans l'application à travers NUI Figure 3 : Utilisation de la Kinect dans l'application à travers NUI
Figure 4 : Les 20 points clés du corps traqués
B. Unreal Development Kit
UDK est un moteur de jeux vidéo développé par Epic Game. Connu sous le nom d’Unreal Engine 3, c’est un environnement de développement complet dont l’objectif est d’élaborer des jeux vidéo de qualité professionnelle. On y retrouve par exemple Unreal Tournament 3, Bulltestorm, Mirror’s Edge et bien d’autres encore.
Les principales caractéristiques d’UDK sont :
Editeur de matériaux très performant en temps réel
Eclairage en temps réel perfectionné et dynamique
Système de particules puissant, associé à un éditeur graphique
Editeur de terrains et de végétation (SpeedTree)
Moteur physique avec un environnement destructible
Bink, un moteur vidéo performant
Interfaces graphiques avancées avec Scaleform en flash : Menu en 3D, vidéos, effets visuels Tout le contenu du jeu vidéo est directement exploitable dans un seul outil, « UDK Editor » et peut être associé à Microsoft Visual Studio pour le développement dans le langage UnrealScript.
UnrealScript est un langage de programmation orienté objet, de haut niveau, similaire à la syntaxe de C#. Il prend nativement en charge les fonctionnalités modernes de programmation couramment utilisées (Héritage, Délégué, Interface). Une des fonctionnalités les plus puissantes est la possibilité de définir des états multiples (State) et d’offrir une programmation sans danger (sans plantage) ainsi qu’un ensemble de fonctionnalités pour les jeux (sérialisation, gestion du réseau, gestion du son, …). De plus, il offre la possibilité d’utiliser des DLL1 programmées en C++.
Plusieurs plateformes sont nativement supportées : PC (Uniquement Windows), Mac OSx, iPhone, Xbox 360 et PlayStation 3. La distribution sur les deux dernières plateformes est par contre excessivement coûteuse.
1 Dynamic Link Library
II. Mission et méthode de travail A. Objectifs
Dans ce projet de recherche, notre mission consistait en l’élaboration d’une application. Par l’utilisation de la Kinect, nous devions intégrer les postures des utilisateurs comme système de commande. Ceux-ci doivent piloter un artefact ; dans notre cas, un avion.
Pendant le vol, une succession de claviers s’enchaîneront. L’utilisateur doit faire passer l’avion à travers une touche pour la saisir. L’ensemble des touches saisies formera un mot ou un texte.
Dans le but de piloter l’avion, nous devons rechercher les postures les plus intuitives et les plus ergonomiques.
B. Différents travaux effectués entre la Kinect et UDK
A notre connaissance et après de nombreuses recherches, il n’existe aucun moyen
actuellement de contrôler un avion par l’intermédiaire de la Kinect. Aucune réalisation publiée n’a été réalisée en ce sens. Dans la majorité des cas, l’utilisateur contrôle un humanoïde1. En revanche, notre objectif est de contrôler un avatar2 de façon indirecte : C’est-à-dire que l’individu ne voit pas sa posture affichée à l’écran, mais observe la réaction de l’avatar qu’il contrôle.
Par ailleurs, une API3 a été développée par un étudiant afin de contrôler la Kinect depuis UDK : « Niui ». Elle permet de récupérer et de suivre les 20 points clés du corps. Elle utilise
cependant le driver OpenNI, pilote de la Xbox 360 qui a été piratée par les hackers pour une utilisation sur PC.
C. De l’étude à la conception
Après de nombreuses réflexions, nous nous sommes tournés vers l’étude d’un jeu vidéo. En effet, l’application doit permettre un apprentissage ludique d’un clavier et de l’orthographe (concept de serious game4).
Le mot à saisir s’affiche en bas de l’écran. Le joueur contrôle un avion afin d’écrire le mot attendu. L’objectif pour lui est de commettre le moins de fautes d’orthographe et de traverser le moins de claviers possibles tout en étant le plus rapide. Une fois le mot tapé, un nouvel objectif apparaît.
Ensuite, plusieurs versions alternatives pourraient être élaborées. Au fil des niveaux, la difficulté changerait en fonction du niveau d’apprentissage.
En effet, pour le premier niveau, on pourrait imaginer que seules les lettres du clavier nécessaires à la saisie du mot, s’affichent. Une image représentant le mot à taper apparaîtrait à côté de sa signification. Le joueur pourrait ainsi associer le mot à saisir à sa signification réelle et retenir son orthographe. Le fait de n’afficher que les lettres à traverser permet au joueur de ne pas être perdu parmi toutes les touches du clavier. De plus, cela lui facilite l’identification de leurs positions en un coup d’œil. Un 2ème niveau pourrait être élaboré afin d’afficher uniquement l’image du mot à saisir.
1 Un humanoïde signifie une forme humaine. Il évoque principalement un bipède (présence de deux bras, deux jambes et une tête).
2 Un avatar est un personnage représentant un utilisateur dans un jeu vidéo.
3 Application Programming Interface.
4 En français, jeu sérieux. Logiciel qui combine une intention sérieuse de type pédagogique, informative, communicationnelle, avec des ressorts ludiques.
Ainsi, le joueur devrait se rappeler de sa signification et de son orthographe. Ensuite, nous pourrions ajouter des lettres pièges jusqu’à afficher tout le clavier.
Cet enchaînement de niveaux permettrait au joueur d’apprendre au fil du jeu, l’orthographe et la signification des mots présentés, tout en apprenant inconsciemment la position des touches du clavier.
Enfin, pour rompre la monotonie du jeu et pour amuser le joueur, nous pensions qu’il était préférable d’intégrer un mode multi-joueurs où il pourra jouer avec ses amis. Le style du jeu serait donc orienté vers des courses afin d’écrire l’objectif le plus rapidement possible. Les joueurs auraient la capacité d’envoyer des missiles sur leurs concurrents, à l’instar du jeu « Mario Kart ».
Afin de réaliser ce type de jeu, nous nous sommes donnés plusieurs objectifs. Il était absolument nécessaire que le pilotage de l’avion s’opère de manière intuitive pour le joueur.
Notre premier axe de recherche était donc fixé. En premier lieu, nous devions établir une bibliothèque de postures dans le but de contrôler l’avion et développer un programme assurant la communication avec la Kinect.
Ensuite, avant de réaliser des tests utilisateurs, nous devions élaborer l’environnement du jeu.
En effet, nous devions concevoir une carte simple pour de ne pas perdre les joueurs et de ne pas fausser les futurs tests. De plus, il était nécessaire d’élaborer le gameplay1. Celui-ci s’est orienté sur trois principes. Premièrement, seules les touches utiles à la saisie sont affichées. De plus, la touche à traverser doit être entourée d’une cible visible permettant au joueur de la reconnaître. Enfin, seul le prochain clavier à franchir est affiché.
Il était ensuite nécessaire de tester la bibliothèque de gestes sous plusieurs modes de conduite et de faire une analyse quantitative et qualitative des résultats. Afin de réaliser nos tests quantitatifs, il était essentiel de concevoir un programme permettant de créer des logs utilisateurs pendant le test et un autre pour les analyser. De plus, un questionnaire a été établi pour chaque testeur pour effectuer un test qualitatif.
D. Méthode de travail
Etant donné que nous ne connaissions aucun moteur physique 3D, nous avons dû nous faire une opinion sur les moteurs existants du marché. Suite à plusieurs investigations sur internet, nous avons découvert et testé Unity3D, CryEngine et UDK. Les raisons de notre choix seront présentées dans la partie 4 : « UDK : Unreal Development Kit ».
Afin de mener à bien notre projet, il était important de nous auto-former. En effet, l’utilisation de la Kinect ainsi que l’environnement d’UDK nous étaient complètement inconnus. En ce qui concerne la Kinect, nous avons principalement étudié sa documentation (en anglais uniquement).
Inversement pour UDK, nos études se sont orientées vers plusieurs autres sources : des tutoriels, des livres, des cours (en anglais principalement).
Ce n’est qu’au bout de 2 mois de recherches et de travail que nous avons pu commencer le développement de la solution. De plus, pour éviter de possibles pertes de données, et pour
« versionner » notre travail, tous nos projets étaient sous contrôle de code source sur un serveur privé.
1 Le Gameplay correspond aux règles du jeu, à la manière dont le joueur est censé et peut jouer, à la fluidité des règles appliquées à l’environnement du jeu ainsi qu’aux possibilités offertes par l’environnement.
III. KUI : Kinect Unreal Interface A. Objectifs
Le développement de KUI était nécessaire afin de pouvoir exploiter les fonctionnalités de la Kinect depuis un autre programme. En effet, la Kinect ne peut pas s’utiliser directement dans UDK car aucune intégration n’a encore été réalisée. Néanmoins, UDK permet de charger des DLL, ce qui a permis d’utiliser KUI au sein d’UDK.
B. Cahier des charges et implémentation
L’objectif du projet KUI est de réaliser une API en C++, exploitable par UDK. Elle assure une communication avec la Kinect et garantit les fonctionnalités natives de celle-ci: démarrage, arrêt et récupération des informations des capteurs.
De plus, elle effectue des prétraitements sur les squelettes suivis. Une fois qu’un squelette est détecté, KUI effectue automatiquement un calibrage sur la morphologie de la personne. En effet, la structure des squelettes est différente selon les âges des individus. Il est donc nécessaire de conserver le squelette initial afin de le comparer aux autres pour détecter de possibles mouvements.
KUI est aussi capable de récupérer un squelette précédemment choisi, de l’analyser et de vérifier l’existence de postures.
1. Pilotage de KUI
Figure 5 : Fonctionnement général de KUI
Au démarrage, KUI démarre le capteur de profondeur de la Kinect. Il est responsable de la détection des silhouettes et permet au SDK de produire une frame de squelettes. Une frame contient jusqu’à six silhouettes comportant pour chacune une position de référence dans le but de les localiser.
Parmi ces profils, deux squelettes peuvent être récupérés. Identifié par un index de 0 à 5, un squelette correspond aux 20 points clés du corps suivis par la Kinect.
A présent, KUI peut récupérer les frames afin de les exploiter. Elle effectue en premier lieu un calibrage qui permettra de détecter les différentes postures existantes dans la bibliothèque. Tant que cette opération n’est pas terminée, il est impossible pour l’application de demander des mises à jour sur la posture actuelle de l’individu.
Figure 6 : Position de calibrage 2. Calibrage
Le calibrage consiste en une capture du squelette. Pour que cette opération soit correctement effectuée, l’individu doit être debout, en face de la Kinect, les bras le long du corps. De plus, cette position doit être maintenue pendant 5 ticks. Un tick correspond à une mise à jour de KUI.
3. Détection de postures
Notre implémentation de la détection de postures s’appuie sur le Design Pattern « Decorator ». Il consiste en une liste chaînée pour laquelle
chaque élément modifie l’objet à décorer. Dans notre cas, cet objet est en charge de mettre ses valeurs à zéro, tandis que les décorateurs s’occupent de les modifier.
Dans notre solution, les décorateurs représentent les actions : monter, descendre, tourner à droite, tourner à gauche, pivoter à droite, pivoter à gauche, accélérer et ralentir.
Figure 7 : Détection de postures
La figure 7 montre le principe de fonctionnement de notre implémentation. Tout d’abord, chaque décorateur demande à son suivant de « décorer ». Si le suivant est l’objet à décorer, il s’initialise. Sur le chemin de retour, chaque décorateur modifie les valeurs dont il a la responsabilité.
Puisque le design pattern Decorator consiste en une liste chaînée, il est facile et rapide de rajouter ou de supprimer un décorateur. Afin d’obtenir une solution plus souple à modifier, nous avons dissocié l’opération de décoration (celle qui modifie les valeurs), de l’opération de détection. C’est pourquoi chaque décorateur possède un détecteur qui est responsable de la détection de mouvements.
De cette façon, il nous est possible de réaliser n’importe quelle combinaison décorateur/détecteur. Par exemple, nous aurions pu associer un détecteur « bras droit levé » à un décorateur « tourner à droite ». Si cette combinaison n’était pas satisfaisante, il suffirait de remplacer le détecteur par un autre plus pertinent.
Lorsqu’un détecteur reconnaît une posture, ce dernier renvoie une valeur au décorateur auquel il est associé. Cette valeur représente l’amplitude du mouvement détecté. Le décorateur l’applique ensuite à l’objet
à décorer. Figure 8 : Détection du
mouvement « pivoter à droite »
Nota :
Les angles utilisés dans UDK ne sont pas dans une unité standard telle que les radians ou les degrés.
Dans UDK, 2π = 65535 ce qui correspond à la valeur maximale d’un mot codé sur 16 bits. Il ne faut pas oublier ce détail car la rotation de π en radian dans le monde UDK ne sera pas perceptible.
Sur la figure 7, on observe deux « personnages ». Ce sont les squelettes fournis à la chaîne de détection. Le premier correspond au squelette obtenu après la phase de calibrage, et le second résulte de la posture actuelle de l’utilisateur. Il est nécessaire de fournir les deux squelettes afin de réaliser des comparaisons sur la position des vingt points clés.
En effet, la posture actuelle à elle seule ne suffit pas à réaliser une détection correcte. La chaîne détecterait uniquement les postures d’une personne de morphologie normale. C’est pourquoi, il est important de prendre en compte certains paramètres relatifs à la structure du corps de l’individu.
Par exemple, la longueur d’un bras d’un enfant est différente de celui d’un adulte. Cependant, quelles que soient leurs morphologies, l’amplitude du geste doit être identique d’une personne à l’autre. De plus, une personne corpulente provoquerait des faux positifs. En effet, la position de référence étant positionnée au milieu des hanches et sur la surface du corps, la détection « Buste en arrière » serait positive alors que la personne est debout et droite.
La seule solution à notre connaissance permettant de palier à ce problème est donc de fournir les deux squelettes (le calibré et l’actuel) afin de prendre en compte la morphologie de la personne.
Lorsque la chaîne de détection atteint la fin de la chaîne, elle se trouve sur l’instance de
« Component » qui s’initialise.
Nous avons exposé le fonctionnement de notre chaîne de détection. En revanche, nous n’avons pas mentionné la structure de l’objet à décorer. En effet, cet objet est une instance de la classe
« Component » qui possède un réel de type float et un RotatorF.
Le réel correspond à la vélocité qui sera utilisée pour déterminer la vitesse de déplacement de notre avion. Quant au RotatorF, c’est une structure identique à un vecteur 3D.
Cependant, au lieu de contenir des coordonnées, elle possède des angles autour des 3 axes.
Voici la composition d’un RotatorF :
Pitch : Rotation autour de l’axe de ⃗
Yaw : Rotation autour de l’axe de ⃗
Roll : Rotation autour de l’axe de ⃗
Ce type de structure devait être implémenté dans KUI puisque UDK utilise le même type de structure, appelée Rotator, pour définir l’orientation des acteurs1.
1 Dans UDK, un acteur représente tous les objets du jeu (objet 3D, lumière, sons, …)
Figure 9 : Un Rotator
IV. UDK : Unreal Development Kit A. Objectifs
La réalisation d’un jeu vidéo met en commun tous les savoirs : la programmation, « l’art » graphique et le gameplay. C’est là qu’intervient le concept de moteur de jeu. Le moteur est un environnement de développement qui embarque généralement toutes ces fonctionnalités. Il fournit une interface simple au matériel. En effet, toutes les fonctionnalités de bas niveaux (rafraîchissement, gestion de la mémoire, …) sont directement intégrées au moteur et ne feront plus l’objet de réflexion.
De plus, la gestion du contenu est simplifiée. Il est capable d’importer des images, du son et des objets 3D depuis plusieurs formats. Enfin, tout le développement est centralisé dans un seul logiciel.
Plusieurs moteurs de jeux vidéo existent sur le marché : Unity3D, CryEngine, UDK, etc.
Chaque moteur a été étudié et testé afin de trouver celui qui est le plus en adéquation avec nos recherches.
1. Unity 3D
Unity3D est un moteur 3D et Physique1 utilisé pour la création de jeux en réseaux, d’animations en temps réel et de contenus interactifs (audio, vidéo et objets 3D). Il peut être utilisé avec les langages de développement C#, JavaScript et Boo2. Il n’est pas destiné à la modélisation3 ; cependant il permet la conception de scènes comportant des éclairages, des terrains, des caméras et des textures. Il est compatible avec de nombreux formats (Maya, Photoshop, TIFF, etc.) et peut être déployé sur plusieurs plateformes (Windows, Web Player, Flash, iOS, Android, Wii, PS3 et Xbox360).
De plus, Unity 3D intègre un plugin permettant d’intégrer et de piloter la Kinect. Il correspondait donc totalement à nos besoins. Néanmoins, le plugin utilisait la version de recherche du SDK de la Kinect. Il présentait plusieurs anomalies produisant certains disfonctionnements (arrêt prématuré, perte de la connexion, …). C’est pourquoi nous avons voulu développer un plugin basé sur la dernière version stable du SDK (release 1.0 de décembre). Cependant, la version du framework .Net utilisé par Unity 3D (3.5) était inférieure à celle utilisée par le SDK (4.0). Cela le rendait inutilisable dans Unity. Nous nous sommes donc orientés vers un autre moteur de jeu.
2. CryEngine
CryEngine est un moteur de jeu développé par Crytek, qui était initialement destiné à une démonstration technologique pour NVidia.
Plusieurs grands jeux ont ensuite été développés : Farcry, Crysis, etc.
Il réalise des graphismes époustouflants et la version 3 offre un déploiement sur PS3 et Xbox 360.
1 Un moteur physique représente une bibliothèque logiciel indépendante appliquée à la résolution de problèmes mécaniques classiques (collisions, chute des corps, forces, cinétiques, etc.).
2 Langage de programmation objet, dont le développement a commencé en 2003 afin de faire usage de la gestion de l’Unicode, de l’internationalisation et des applications web, basé sur une syntaxe inspirée du Python.
3 La modélisation consiste à créer un objet à trois dimensions dans un logiciel de modélisation 3D.
Après diverses recherches, aucune intégration de la Kinect n’a encore été réalisée mais cela reste un projet prioritaire pour Crytek. De plus, CryEngine nous paraissait difficile à appréhender à cause de la complexité du moteur.
3. UDK
Précédemment présenté à la page 6, UDK est un moteur de jeu complexe et performant.
Cependant, tout comme CryEngine, aucune intégration de la Kinect n’a été effectuée. Néanmoins, il comporte une communauté américaine et française importante et de nombreux tutoriels et livres existent. De plus, le projet Niui exposé à la page 7 nous confortait dans l’idée d’utiliser ce moteur.
B. Cahier des charges et implémentation
Le développement d’un projet UDK se sépare en plusieurs parties. Premièrement, tous les objets 3D doivent être modélisés dans un logiciel de modélisation 3D, tels que 3DSmax ou Blender.
Ensuite, la scène de jeu doit être conçue, puis vient le rôle de la programmation afin d’élaborer le gameplay.
1. Etape 1 : La modélisation
a) Choix du logiciel de modélisation 3D Dans le but de les tester, nous avons téléchargé les 2 logiciels Blender et 3DSmax puisque nous n’en connaissions aucun. Finalement, nous nous sommes orientés vers 3DSMax qui nous a semblé être le plus intuitif. De plus, la conversion des objets modélisés par Blender, afin de les intégrer dans UDK, n’était pas native. Un script tiers, nommé « Goofos », développé en python, devait être utilisé. Celui-ci provoquait des anomalies de triangulation.
b) Modélisation des objets
Les objets qui ont été modélisés sont : le clavier, les lettres de l’alphabet, la cible et l’avion.
Voici quelques exemples de pièces qui ont été modélisées :
Les lettres ont été réalisées en 2D grâce à l’outil « Texte ». Elles ont ensuite été extrudées sur l’axe ⃗ pour former la lettre en 3D. En ce qui concerne la cible, elle a été produite avec l’outil
« Tore ». Quant au clavier, il est représenté par une simple boite de 10UA1 de long, de 3UA de hauteur, et 1UA de large. En revanche l’avion a été téléchargé depuis internet.
1 Unité arbitraire
Figure 12 : La lettre S Figure 10 : La cible Figure 11 : L'avion
c) Importation des objets modélisés
Afin d’importer les objets modélisés dans UDK, il est nécessaire de les convertir dans un format approprié. FBX correspondait à la meilleure solution, d’autant plus que c’est un format propriétaire d’Autodesk, éditeur de 3DSmax et qu’il est totalement reconnu par UDK.
De plus, avant d’exporter l’objet modélisé, il est important de vérifier la position du repère local de l’objet. En effet, c’est le même qui sera utilisé en tant que repère de l’objet dans UDK. Pour modifier sa position, il faut utiliser l’outil « Affecter seulement le pivot ».
2. Etape 2 : Création de la scène dans UDK
La scène permet de définir l’environnement de jeu. Elle contient le terrain, le décor, les lumières, les sons, etc. La conception de la scène ne sera pas détaillée dans ce rapport puisqu’elle n’est pas en corrélation directe avec le sujet.
Le terrain a été élaboré en forme d’ovale pour guider un minimum le joueur. De plus, plusieurs obstacles ont été ajoutés dans le but de les forcer à faire des mouvements différents. Sur la figure 13 nous pouvons par exemple apercevoir une arche qui les oblige à passer soit au-dessus, soit en dessous.
Le clavier (en forme de boite) affiché dans la figure 14 n’est pas visible dans le jeu. C’est une représentation du clavier afin de pouvoir le positionner visuellement dans la scène. C’est lui qui nous informe que le joueur l’a traversé et s’il l’a franchi dans le bon sens. En effet, une lettre saisie en sens inverse ne correspond pas à une entrée correcte.
3. Etape 3 : Développement
Par l’intermédiaire du plugin « nFringe », nous pouvons développer en UnrealScript avec l’IDE1 « Microsoft Visual Studio ».
Le développement se déroule en plusieurs parties. Voici les acteurs principaux du jeu qui ont été programmés : le « PawnControleur », le « Pawn », la « Camera », le « HUD » le « GameInfo » et le « Clavier ».
Le « Pawn » correspond à l’avion lui-même. C’est l’acteur qui représente le personnage du joueur.
1 Integrated Development Environment (Interface de développement)
Figure 14 : Scène avec claviers Figure 13 : Scène sans clavier
Le « PawnControleur » est responsable des interactions du « Pawn ». Nous verrons plus tard qu’il implémente « KuiPlayerController » dans le but de recevoir les mises à jour de KUI (réception du Rotator et de la vélocité).
La « Camera » est une caméra à la 3ème personne, pour visualiser l’avion. Une caméra à la 1ère personne représenterait le cockpit (non implémentée).
Le « HUD » est l’interface du jeu. Elle a été conçue en flash par l’intermédiaire d’Adobe Flash Professionnel, logiciel qui nous était aussi inconnu au départ.
Le « GameInfo » permet d’implémenter le gameplay du jeu. C’est ici qu’est programmé le mot à saisir, les lettres du clavier à afficher, les enchaînements de claviers, les touches franchies, la prochaine lettre à saisir, la fin de jeu et les logs.
Le « Clavier » est un acteur représentant le clavier virtuel. Entièrement configurable, il affiche ou cache l’ensemble ou une partie de ses touches. Celles-ci, ainsi que leurs positions logiques, sont chargées depuis un fichier XML. Grâce à cette implémentation, nous pouvons changer de type de clavier facilement sans toucher au code source et à la scène (par exemple : de Azerty vers Qwerty).
4. Jeu final
V. Intégration de KUI dans UDK A. Objectifs
La Kinect pourrait être représentée comme un contrôleur d’entrée1 et KUI comme un interpréteur de la Kinect vers UDK.
Dans le but de contrôler un ou des acteurs spécifiques d’UDK, il est nécessaire que la communication s’établisse de manière souple et évolutive. C’est pourquoi il est intéressant que chaque acteur puisse être abonné au contrôleur KUI afin de recevoir les mises à jour de la Kinect. Dans notre cas, seul le « PawnControleur » devra implémenter cette communication, car c’est lui qui est responsable des mouvements du « Pawn ».
B. Cahier des charges et implémentation
KUI est une DLL qui a été développée de manière précise afin d’être utilisée dans UDK. Un certain nombre de méthodes a été exporté :
Démarrage et arrêt de KUI
Récupération du geste du squelette actuel d’index spécifique
Récupération du squelette calibré d’index spécifique
Récupération des squelettes détectés
Application d’un mode de configuration
Méthodes de logs
Toutes ces méthodes ne peuvent utiliser que quelques types C++ (int, float, char, wchart_t* et struct). De plus, nous pouvons utiliser des pointeurs avec UDK.
Pour connaître l’état d’exécution de chaque fonction, nous avons pris la convention de retourner obligatoirement une structure concernant son statut. Ainsi, l’application d’UDK est prévenue en cas d’erreurs.
Le geste est une structure issue de la chaîne de décoration de KUI. Il contient un Rotator et une vélocité.
Dans l’objectif de tester plusieurs configurations de postures, nous avons décidé d’appliquer les différentes modifications relatives à ces tests directement dans KUI. Chaque configuration aura sa DLL. Cela permet de changer facilement et rapidement de mode de pilotage sans avoir à recompiler UDK. A titre d’information, 3 fichiers « .bat » ont été générés afin d’inter-changer automatiquement les DLL et de lancer le jeu dans la configuration adéquate.
Maintenant que les DLL de KUI sont opérationnelles, nous pouvons expliquer le fonctionnement de l’interaction de KUI dans UDK.
Toutes les méthodes exportées, ainsi que les structures nécessaires, ont été importées dans UDK. Au démarrage, le jeu initialise KUI. Ensuite, un abonnement de chaque acteur implémentant l’interface « KuiPlayerControleur » est effectué sur le contrôleur de KUI. Ceci permet de référencer les acteurs afin de les avertir des mises à jour de KUI.
1 Un contrôleur d’entrée représente un périphérique qui envoie des données
A chaque tick1 de jeu, nous vérifions que la Kinect est dans un état fonctionnel et que des joueurs sont suivis. Pour chacun de ces squelettes, nous récupérons le Rotator qui correspond au geste actuel ainsi qu’à sa vélocité. Si les squelettes ne sont pas calibrés, une erreur est retournée empêchant la mise à jour des acteurs.
A la réception d’un nouveau geste, le « PawnControleur » met à jour le « Pawn », opération qui nous a posée de nombreuses difficultés.
Auparavant, nous ajoutions simplement le Rotator de transformation (celui du geste) à celui du
« Pawn ». Cela provoquait un résultat inattendu.
Pour expliquer le problème, prenons deux exemples du monde réel. Sur la figure 16, nous avons un avion qui vole à plat. Lorsque l’utilisateur « tire sur le manche », l’avion s’oriente vers le ciel. Sur la figure 15, lorsque l’on effectue la même opération, l’avion s’élève suivant l’axe ⃗ (en rouge) de son repère.
Dans notre application, la situation de la figure 16 aboutissait au même résultat que le monde réel. En revanche, la situation de la figure 15 produisait un résultat différent. En effet, l’avion s’élevait suivant l’axe ⃗ (en rouge) du repère monde.
Nous en avons conclu que l’addition des deux Rotators s’effectuait suivant le repère Monde alors que nous pensions que l’ajout d’un Rotator sur le Rotator d’un « Pawn » s’appliquerait suivant le repère du « Pawn ».
Pour résoudre ce problème, nous avons dû effectuer une rotation sur chacun des axes du repère du « Pawn » permettant de réorienter les deux autres vecteurs. L’ordre d’application des rotations autour des axes est très important. En effet, la rotation doit se faire en premier sur Yaw (autour de ⃗), puis sur Pitch (autour de ⃗) et enfin sur Roll (autour de ⃗). Une application dans un autre ordre produirait une orientation complètement différente.
Quant à la vélocité, nous effectuons une translation2 en fonction du vecteur direction du
« Pawn ». Celui-ci correspond à la norme3 du vecteur ⃗ de son repère local.
1 Ici, un tick de jeu correspond à chaque rafraichissement effectuée par UDK
2 Une translation est une transformation géométrique qui correspond à un glissement d’un objet sans rotation, ni déformation.
3 Un vecteur est normé quand sa norme vaut 1
Figure 15 : Avion incliné Figure 16 : Avion à plat
Figure 17 : Section XSD en charge de l'héritage
VI. Le logger A. Objectifs
Afin de déterminer le « meilleur » mode de pilotage, il faut mettre en corrélation les impressions des utilisateurs, récoltées par le questionnaire rempli pendant les tests, avec les postures qu’ils ont réellement effectuées. C’est pourquoi une classe de log est nécessaire. Grâce à elle, nous conservons une trace des différentes postures. Ainsi nous pouvons vérifier si le mode de pilotage préféré du joueur correspond à celui qui relève les meilleures performances (temps de jeu, nombre de touches ratées, etc.).
B. Cahier des charges et implémentation
L’objectif de la classe de log est de conserver un maximum d’informations. En effet, elle sauvegarde les postures détectées, les claviers franchis ainsi que les touches saisies et attendues.
Chaque enregistrement est associé à la date et l’heure de l’évènement.
De plus, connaître le nombre de claviers franchis nous aide à identifier le nombre de touches manquées par le joueur.
Dans le but de faciliter la lecture, nous avons décidé d’écrire toutes les informations dans un fichier XML1. En plus d’être lisible et compréhensible par un être humain, il permet d’être structuré grâce à l’utilisation d’un schéma XSD2, facilitant ainsi l’analyse par programme.
L’élaboration du schéma XSD correspondant à la structure XML était une problématique. Afin de détailler cette difficulté, nous vous référons au fichier de log présent en annexe 3 et ci-dessous:
« Objectif », « LettreTouchee », « ClavierFranchi » et « Geste » sont des balises filles de
« TestUtilisateur » qui est la racine de l’arborescence XML.
Dans la balise « Geste », une ou plusieurs balises sont présentes. Elles symbolisent un décorateur de type particulier. C’est pourquoi il est nécessaire d’utiliser le principe d’héritage en XSD.
1 Extensible Markup Language
2 XML Schema Definition
L’élément abstrait « Decorators » représente l’élément de base de tous les décorateurs et contient le type complexe « DecoratorType ». Tous les éléments qui utilisent ce dernier ne peuvent contenir qu’une seule balise « DetecteurGeste » qui doit être non vide. De plus, « DecoratorType » doit être associée à un attribut nommé « valeur » de type float.
La base de l’héritage XSD est définit par ces 3 structures. Les seuls éléments qui restent à spécifier sont les différents héritiers de « Decorators ». Désormais les balises « Geste » peuvent s’enchaîner. Chacune d’elles contient une séquence de balises « Decorators » qui peut être représentée par « DecoratorMonter », « DecoratorDescendre », etc.
Maintenant que notre schéma de validation de fichier XML est opérationnel, il est intéressant de développer une application qui exploitera les fichiers générés lors des tests utilisateurs.
VII. Interpréteur de log A. Objectifs
Après les tests utilisateurs, nous avons remarqué que les fichiers de log représentaient plus de 30 000 lignes par test. Il paraît évident qu’ils ne sont pas exploitables en l’état. C’est pourquoi, nous avons développé le projet « ParseurLogKinectUDK » afin d’effectuer une analyse quantitative.
B. Cahier des charges et implémentation
Le projet « ParseurLogKinectUDK » permet d’analyser les fichiers de log qui ont été générés pendant les tests de notre jeu. Son principal objectif est d’extraire les données significatives des fichiers afin de fournir des informations analysables telles que le nombre de claviers franchis, le nombre de mouvements, etc.
Grâce à la conception de notre schéma XSD, nous avons pu utiliser le plugin XSD2Code. Ce plugin nous génère une hiérarchie de classe en C#, en se basant sur le schéma XSD qui lui est fourni.
Il possède une option qui génère les méthodes utiles à la sérialisation et à la dé-sérialisation. Nous avons donc généré les classes nécessaires avec ce plugin. De plus, tous les fichiers qui ne respectent pas le schéma XSD original, génèreront des exceptions lors de la lecture du fichier. Ceci nous assure la robustesse de l’application.
Ensuite, nous avons utilisé LINQ1 dans le but d’extraire les données des fichiers XML. En effet, LINQ permet de réaliser des requêtes sur les collections de nos objets. De cette façon, il est possible de restreindre les recherches sur certains types.
Par exemple, depuis la collection des balises filles de « TestUtilisateur », nous avons extrait les balises de type « Geste » uniquement. Ensuite, nous avons recherché le premier geste contenant un certain type de decorator, puis le premier geste ne contenant pas ce decorator. De cette manière, nous avons identifié une succession de gestes ayant un type de decorator. En répétant cette opération jusqu’à la fin de la collection, nous pouvons déterminer le nombre de ce type de mouvements.
Les valeurs que nous avons recherchées sont :
Le nombre de mouvements (à droite, à gauche, monter, descendre, pivoter à droite, pivoter à gauche)
Le nombre d’hésitations sur ces mouvements
La durée du test
Le coefficient d’accélération moyen
Le nombre de claviers franchis
Le nombre de claviers franchis sans saisie
Le nombre de mauvaises saisies
Le texte saisi
De plus, il nous paraît intéressant de connaître le nombre de fois ou l’utilisateur a rapidement corrigé un mouvement. C’est ce que nous appelons des hésitations. Par exemple, le joueur démarre un mouvement de monter, puis quelques instants plus tard, il effectue le mouvement contraire, descendre.
Ceci nous permet d’estimer la précision des postures que nous avons implémentées. En effet, un fort taux d’hésitation met en évidence le manque de finesse de détection de postures.
1 Language Integrated Query
Pour ce qui est du nombre de claviers franchis, cette valeur est nettement plus révélatrice que le nombre de mauvaises saisies. En effet, celle-ci est comptabilisée si l’utilisateur traverse une lettre autre que celle attendue. Par contre, si l’utilisateur cible la lettre attendue, mais qu’il la manque de peu, il n’a franchi aucune touche. Cependant, il a tout de même essayé d’en atteindre une. C’est la raison pour laquelle nous enregistrons les claviers franchis. Ainsi, nous pouvons évaluer la difficulté des utilisateurs à piloter l’avion.
Une autre fonctionnalité de « ParseurLogKinectUDK » consiste en la génération d’un fichier html contenant tous les résultats extraits et analysés du fichier de log : ceci dans l’unique but d’avoir une trace persistante et imprimable de l’analyse.
VIII. Tests utilisateurs A. Objectifs
Afin de faire comparer nos différents modes de pilotage, nous avons procédé à des tests utilisateurs. La population testée s’élève à 12 individus bien qu’il aurait été intéressant de réaliser des tests sur un plus grand nombre de personnes, nombre qui serait bien plus représentatif. En effet, chaque utilisateur doit nous consacrer approximativement 20 minutes de son temps (durée du test). La durée totale du test sur 24 personnes nous aurait pris environ 8 heures. A cela s’ajoute le temps de saisie des données et de l’analyse des résultats.
B. Préparation
1. Les postures et actions implémentées
Nous avons défini une bibliothèque de postures auxquelles nous avons associé une réaction de l’avion. Voici les différentes actions/postures misent en place :
Monter : mettre le buste en arrière,
Descendre : mettre le buste en avant,
Tourner à droite : tourner les épaules vers la droite,
Tourner à gauche : tourner les épaules vers la gauche,
Pivoter à droite : pencher le buste sur la droite,
Pivoter à gauche : pencher le buste sur la gauche,
Accélérer : Tendre les bras vers l’avant.
Afin d’implémenter ces postures, nous avons effectué au préalable divers essais. En effet, nous avons observé le comportement de différents cobayes face au pilotage de l’avion sans qu’ils aient connaissance des gestes implémentés. De ce fait, nous avons donc élaboré une bibliothèque de
postures en fonction des gestes les plus fréquents. De plus, nous avons remarqué que les utilisateurs se servaient de leurs épaules pour tourner, d’où notre implémentation.
A partir des différentes actions possibles, nous avons élaboré 3 modes de pilotage, du plus facile au plus difficile :
Mode automatique : Il correspond au mode le plus assisté. 3 mouvements sont uniquement disponibles : accélérer, monter/descendre, tourner à droite/gauche.
Mode semi-automatique : Toutes les actions sont disponibles. A titre d’information, le pivotement de l’avion suit l’axe des épaules de l’utilisateur (voir figure 18). Lorsque l’utilisateur se remet droit, l’avion revient automatiquement à l’horizontal.
Mode manuel : Ce mode correspond à une simulation. Contrairement au mode semi- automatique, lorsque l’utilisateur remet ses épaules à l’horizontal, l’avion conserve son inclinaison (voir figure 19). Pour le remettre à l’horizontal, il devra effectuer le mouvement contraire.
Figure 19 : Mode manuel
2. Questionnaire
Nous avons réalisé un questionnaire (cf. annexe 1). Les questions s’orientent suivant 3 axes :
les modes de pilotage : apprentissage des gestes, la difficulté à contrôler l’avion, etc.,
le monde : position des claviers, visibilité des touches, etc.,
l’utilisateur lui-même, afin d’identifier ses habitudes vis-à-vis des jeux vidéo.
Nous avons utilisé une échelle de réponse pour comparer les résultats afin de ne pas obtenir des valeurs brutes du type « oui » ou « non ». Cette échelle se gradue de 1 à 5. 1 correspondant à une réponse en total accord avec la question, et 5 en total désaccord.
Nous avons aussi alterné le sens des questions : Une question positive, où la réponse serait plutôt 1 ou 2, avec une question négative, à laquelle la réponse serait 4 ou 5. L’utilisateur doit donc bien lire et comprendre la question, ceci dans le but d’éviter les réponses par habitude.
Avant d’effectuer le test, nous questionnons le « cobaye » au sujet des postures qu’il aurait utilisé pour les 3 actions de pilotage de l’avion : monter ou descendre, tourner à droite ou à gauche et pivoter à droite ou à gauche. Cela nous permet de comparer les postures proposées avec celles que nous avons implémentées.
Ensuite, nous avons établi un ordre de succession des modes de pilotage de façon différente pour chaque testeur, dans le but de ne pas « défavoriser » un mode de pilotage. En effet, appliquer la même séquence aurait probablement généré une plus mauvaise notation sur le premier mode. Puisqu’il y a 3 modes, nous avons produit les 6 enchaînements suivants :
Automatique, semi-automatique, manuel
Automatique, manuel, semi-automatique
Manuel, semi-automatique, automatique
Etc.
Pour avoir une bonne répartition des modes de pilotage, il est nécessaire d’avoir un nombre de testeurs qui soit un multiple de 6. De cette façon, le nombre d’exécution de chaque séquence sera identique.
C. Analyse des résultats
Les 3 modes de conduite seront représentés par les lettres A, B et C dont voici la désignation :
A : Mode automatique (2 gestes plus 1 automatique)
B : Mode semi-automatique (3 gestes dont un semi-automatique)
C : Mode manuel (3 gestes)
1. Analyse de la scène de jeu
A la vue du graphique 1, nous constatons que le monde est adapté pour tous les utilisateurs. En effet, tous les critères obtiennent majoritairement la note maximale. Les utilisateurs étaient donc dans de bonnes conditions. La variable « Monde » n’a donc aucune influence sur les résultats concernant les modes de pilotage.
0 1 2 3 4 5
La taille des lettres n'est pas trop petite
Les claviers sont correctement
positionnés
La vitesse minimale n'est pas trop
rapide
La lettre à saisir est facilement identifiable
La scène
Graphique 1 2. Analyse qualitative
a) Résultat du questionnaire
D’après le graphique 2, nous pouvons remarquer qu’il n’y a pas de distinctions significatives entre les modes de pilotage.
En revanche, nous pouvons noter que « A » est un mode de pilotage très facile à prendre en main, absolument pas fatiguant, et dont les gestes sont totalement logiques avec les mouvements de l’avion. De plus, il obtient de très bons résultats dans les autres catégories. Nous pouvons donc en conclure que le mode de pilotage « A » est très intuitif et qu’il serait idéalement adapté pour les enfants.
Cependant, les tests des modes « B » et « C » fournissent de moins bons résultats quant à la facilité du contrôle de l’avion. Ils obtiennent une note approximative de 4, ce qui reste tout de même correct.
0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5
Le jeu est facile à prendre en
main
Le mouvement
de l'avion correspond au geste effectué
L'avion est facile à contrôler
Les mouvements
de l'avion sont-ils réactif
Les gestes sont logiques
par rapport aux mouvements
de l'avion
Les positions utilisées de votre corps
sont ergonomiques
Vous n'étiez pas fatigué à la fin du test
Vous ne vous êtes pas senti perdu dans le
jeu
Analyse qualitative
A B C
Graphique 2
b) Mode de pilotage favori
A la fin des 3 tests, chaque utilisateur nous a indiqué son mode de pilotage préféré. D’après le graphique 3, nous pouvons constater que le mode de pilotage « B » l’emporte largement. La majorité de la population préfère donc un pilotage semi-assisté.
0 2 4 6 8
A
B C
Mode favori
Graphique 3
De plus, nous pouvons remarquer d’après le graphique ci-après que les utilisateurs familiers avec les jeux vidéo et les jeux vidéo pilotés par gestes préfèrent en général utiliser le mode « B ». En comparaison, les utilisateurs non familiers n’ont pas de mode particulier préféré.
0 1 2 3 4 5 6 7
Utilisateurs familiers avec
jeux vidéo
Utilisateurs non familiers avec les jeux
vidéos
Utilisateurs familiers avec les jeux piloter par les gestes
Utilisateurs non familiers avec les jeux piloter par les
gestes 2
0 0
2 7
0
5
2 2
1
2
1
Choix par type d'utilisateur
A B C
Graphique 4
c) Commentaires des utilisateurs
Plusieurs commentaires découlent du ressenti des utilisateurs pour chaque modes de pilotages.
(1) Le mode A
Pour le mode A, plusieurs personnes ont répondu positivement :
« Bien, puisque les gestes sont assistés »
« Mode adapté aux plus jeunes »
« Simple à prendre en main »
Néanmoins, nous remarquons les critiques suivantes :
« C’est le moins adapté et le moins logique. La vrille automatique ne permet pas de contrôler complètement l’avion »
« Pas ergonomique, car la rotation des épaules pour orienter l’avion n’est pas naturelle »
Bien que ce mode de pilotage soit très facile à prendre en main, nous constatons que la population se divise en 2 catégories. Une qui l’apprécie fortement et une autre qui le trouve inadapté.
(2) Le mode B
Voici les commentaires principaux fournis par les testeurs.
« C’est le meilleur moyen de contrôler l’avion. Les gestes du corps sont adaptés à la conduite »
« C’est le plus facile à contrôler puisque l’inclinaison de l’avion suit les épaules du corps »
« Plus de liberté de mouvements et plus réactif par rapport au mode A. »
« Ni trop difficile, ni trop facile »
Au vu de ces commentaires et des notations fournis par la population, le mode B est un mode très apprécié.
(3) Le mode C
Les commentaires que nous avons récoltés pour ce mode de pilotage sont d’une part négatifs :
« Difficile au départ pour contrôler la vrille »
« Difficile de dissocier les gestes « tourner » et « vriller » ; ce sont 2 gestes très proches. »
« Plus de difficultés à contrôler » Et d’une autre part, positifs :
« Correspond bien à une simulation de vol »
Nous pouvons constater que ce mode de pilotage n’est pas très apprécié, ceci dû à sa difficulté de contrôle. De plus, sur le graphique 2, le mode « C » n’obtient jamais la meilleure note à lui seul. Il reste néanmoins un pilotage réaliste.
(4) Synthèse
Suivant la perception des utilisateurs, le mode B est le meilleur. Voyons si l’analyse quantitative suit cette tendance.
3. Analyse quantitative
a) Précision de la saisie
D’après le graphique 5, nous constatons que les utilisateurs obtiennent une meilleure précision en termes de lettre correctement saisie avec le mode de pilotage « A ». De plus, les deux autres modes fournissent sensiblement la même précision. Nous pouvons aussi remarquer que le mode « A » dépasse largement le taux global des touches correctement saisies. Une touche incorrectement saisie correspond à traverser un clavier sans la saisir, ou ne pas saisir la touche attendue.
76%
63% 63%
0%
10%
20%
30%
40%
50%
60%
70%
80%
A B C
Taux de touches correctement saisies
Taux global
Graphique 5
Que l’utilisateur soit familiarisé ou non avec les jeux vidéo, le mode de pilotage « A » semble être le mode le plus intuitif. En effet, à la vue du graphique 6, nous remarquons qu’il offre une précision à la saisie largement supérieure aux autres.
Bien que « B » soit le plus apprécié des modes de pilotages, il n’excelle jamais quel que soit le rapport qu’entretien l’utilisateur avec les jeux vidéo et les jeux vidéo pilotés par gestes (Wii, Kinect, etc.).
En revanche, « C » est un mode bien plus facile à contrôler par les utilisateurs habitués aux jeux vidéo pilotés par gestes. En effet, nous notons une différence significative de 15% entres les deux catégories d’utilisateurs.
0%
10%
20%
30%
40%
50%
60%
70%
80%
Utilisateurs familiers avec
jeux vidéo
Utilisateurs non familiers avec les jeux vidéos
Utilisateurs familiers avec les jeux piloter
par les gestes
Utilisateurs non familiers avec les jeux piloter par les gestes Utilisateurs familiers
avec jeux vidéo
Utilisateurs non familiers avec les jeux
vidéos
Utilisateurs familiers avec les jeux piloter par
les gestes
Utilisateurs non familiers avec les jeux
piloter par les gestes
A 78% 60% 76% 75%
B 58% 67% 55% 63%
C 62% 67% 70% 55%
Taux de claviers correctement franchis
Graphique 6
Nous pouvons donc conclure, à la vue de ces graphiques, que le mode de pilotage « A » offre une meilleure précision de saisie. Voyons maintenant si cette affirmation se confirme en termes de pilotage.
b) Analyse du pilotage
Dans le but de comparer les données indépendamment du temps de jeu, nous les avons rapportées à la minute.
A la vue du graphique 7, nous pouvons remarquer que les différents tests fournissent un nombre de mouvements approximativement égal pour « Pivoter à gauche », « Tourner à gauche » et
« Tourner à droite ».
Sachant que la scène est formée en ovale et que le sens de parcourt est dans le sens trigonométrique, l’avion doit tourner majoritairement vers la gauche. Nous pouvons noter que le nombre de « Pivoter à droite » est plus important pour le mode « C ». Ceci illustre le fait que le joueur doit contrebalancer l’avion afin de le rétablir à l’horizontal.
Bien plus encore, des mouvements « Pivoter à droite » et « Pivoter à gauche » sont détectés pour le mode « A ». Cela nous indique que le joueur les exécute instinctivement bien qu’ils ne sont pas utilisés dans ce mode.
0,00 2,00 4,00 6,00 8,00 10,00 12,00 14,00
Tourner à droite
Tourner à gauche
Monter
Descendre Pivoter à droite
Pivoter à gauche
Accélérer
Mouvements moyens à la minute
A B C
Graphique 7
Le taux d’hésitations est calculé en fonction du temps de réaction complexe1. En fonction des individus, la réponse motrice a lieu après 225 et 325 millisecondes. Nous avons donc pris le parti d’utiliser une base de 250 millisecondes pour repérer les diverses hésitations. Une hésitation correspond à l’exécution ravisée d’un geste dans ce laps de temps.
Nous pouvons donc remarquer depuis le graphique 8, que le taux d’hésitations sur les 3 modes de pilotage est très faible. En effet, les tests ne dépassent jamais 20% d’hésitations sur l’ensemble des gestes effectués.
D’après le graphique 9, « C » obtient un nombre d’hésitations à la minute important pour les gestes « Tourner à droite », « Tourner à gauche », « Pivoter à droite » et « Pivoter à gauche ». Ceci nous révèle que les utilisateurs ont du mal à dissocier ces deux mouvements.
1 Temps entre l’application de deux stimuli et la mise en place d’une réponse inféodée au stimulus. Dans ce cas, la préparation de la réponse motrice se met en place qu’après apparition du double stimulus.
0%
5%
10%
15%
20%
25%
Tourner à droite
Tourner à gauche
Monter
Descendre Pivoter à droite
Pivoter à gauche
Taux d'hésitations moyens à la minute
A B C
Graphique 8
0,00 0,50 1,00 1,50 2,00 2,50
Tourner à droite
Tourner à gauche
Monter
Descendre Pivoter à droite
Pivoter à gauche
Hésitations moyennes à la minute
A B C
Graphique 9
Nous pouvons donc conclure que les pilotages « A » et « B » sont sensiblement identiques. Par contre, le mode « C » génère des hésitations plus importantes.
4. Synthèse
D’après l’analyse qualitative, le mode « B » est le plus apprécié des utilisateurs. Cependant, ce n’est pas le plus précis. En effet, l’analyse quantitative nous révèle que la saisie du mot « UNREAL » est plus facilement exécutée dans le mode « A ». Par contre, il nous est impossible de déterminer quel est le pilotage le plus instinctif puisque les modes génèrent approximativement le même nombre de mouvements et d’hésitations à la minute.
