P2014
Université de Technologie de Compiègne
HU KEWEI WANG YUJUE ZHANG YIXUAN ZHU CHUNXIAO
[NF28 -‐ RAPPORT FINAL]
Rapport du projet LeapBand
Contenu
Introduction du projet ... 3
1. Etude préalable et spécifications ... 4
1.1 Etude des utilisateurs ... 4
1.2 Etude des logiciels concurrents: ... 7
1.3 Positionnement ... 12
1.4 Fonctionnalités : ... 13
2. Conception ... 15
2.1 Architecture de l’application ... 15
2.2 Structure de données ... 18
2.3 Gestion de son ... 18
3. Interface ... 20
3.1 Vue de bienvenue ... 20
3.2 vue de menu d'instruments ... 20
3.3 Vue de jouer ... 21
3.4 vue de multi- joueurs ... 24
3.5 Analyse IHM ... 25
4 Contrôle ... 28
4.1 Le Leap Motion ... 28
5. Outil utilisés ... 31
6. Difficultés rencontrées, modifications apportée ... 32
7. Limites du prototype et amélioration possibles ... 33
8. Conclusion ... 34
Remerciement
Dans un premier temps, nous tenons à remercier M. Dominique LENNE, enseignant de l’UV NF28, pour son expérience, son aide et ses conseils donnés tout au long du projet.
Nous tenons également à remercier M. Ala ATRASH, professeur de TD de l’UV NF28, pour nous avoir accompagné tout au long du projet.
Nous tenons aussi à remercier M. Claude MOULIN et Mme Lucile CALLEBERT, pour les aides très précieuses apportées sur la partie de la conception du modèle Multi-Agent.
Enfin, nous remercions toutes les personnes qui, de près ou de loin, ont su nous aider à évoluer dans notre projet, à l’image des personnes ayant répondu aux différents sondages.
Introduction du projet
Contexte :
L’Interaction Homme Machine devient de plus en plus fréquente et variée et évolue activement avec les sorties de nouvelles technologies. Les supports pour lesquels on peut développer un système interactif sont nombreux, par exemple : Ordinateur, SmartPhone, Tablette tactile, Kinect, Leap Motion…
Parmi des outils interactifs, le Leap Motion est un périphérique d’entrée qui permet d’interagir par perception gestuelle. Ce produit s’est bien vendu et a bien évolué depuis son lancement en 2012. Il représente une manière innovant d'interagir avec la machine puisque l’interaction se fait par des gestes dans un espace 3D perçus et analysés par le Leap Motion.
Notre groupe a choisi de développer une application en Java à l’aide d’un capteur Leap Motion. Cette application nous permet de jouer différents instruments musicaux de façon interactive et en collaboration. Grâce au Java, notre application peut être déployé sur les plate-formes Windows et OS X.
Notre application peut aussi attirer de l'attention des amateurs qui voudrait expérimenter la création musicale de façon interactive et en collaboration, elle offre des fonctionnalités distrayantes qui permettent aux joueurs de jouer de la musique sans contrainte et sans utiliser des équipements complexes et parfois onéreux.
1. Etude préalable et spécifications
1.1 Etude des utilisateurs 1. 1.1 Analyse des résultats de l’enquête
Le questionnaire sur “Leap Band” s’est déroulé entre le 10 avril et 17 avril, on a reçu 17 réponses valides, dans notre enquête, on a proposé 11 questions sur Leap Band pour mieux cerner les attentes de potentiels joueur.
Voilà les résultats qui nous ont guidé pour l’orientation du développement de notre projet :
Plus de 50% de sondés connaissent les deux capteurs Kinect et Leap Motion, on suppose qu’ils peuvent comprendre l’avantage et la spécificité de notre jeu en utilisant le capteur Leap Motion, en fait, on pense que tous les propriétaires de Leap Motion sont des clients potentiels.
Selon les réponses, les sondés semble plutôt intéressés par le thème de notre jeu.
Ce résultat nous indique que notre projet est réalisable parce qu’on a quelques clients potentiels qui souhaiteraient acheter notre application et y jouer.
Ce résultat nous propose des idées pour perfectionner notre jeu, on peut ajouter plusieurs instruments musicaux dans le jeux selon la préférence des utilisateurs.
Les sondés sont plutôt satisfaits de la performance du Leap Motion controller, c’est à dire que Leap Motion n’a pas d’effet négatif sur notre jeu. On croit donc que s’ils aiment Leap Motion, notre jeu va attirer leur attention et qu’ils auront envie d’essayer notre jeu dès qu’il sortira.
Sur les deux questions ci-dessus, on analyse que les sondés ont le désir d’acheter notre jeu, et donc d’acheter un Leap Motion pour ceux qui ne l’ont pas encore, notre jeu a déjà des clients prévus, il aura un très bonnes perspectives d’avenir sur le marché.
Le résultat de cette question nous donne une estimation sur le prix de notre jeu, 50%
de sondés acceptent le prix entre 1.00-5.99 euros, selon cela, on peut établir le prix autour de 3.00 euros.
Conclusion:
En résumé, selon le résultat de cette enquête, on peut dire que Leap Band est une bonne idée, plus de la moitié des sondés sont intéressés par notre projet. De plus, notre jeu répond aux besoins des clients, c’est à dire qu’on aura beaucoup plus de clients potentiels. Puis, cette enquête nous donne des idées qui permettront
Band a un bel avenir en perspective, il sera un produit favorable, il est nécessaire de réaliser notre projet.
1.1.2. Utilisateur visé :
Les utilisateurs visés sont les propriétaires du capteur Leap Motion qui utilisent un ordinateur avec un système d’exploitation Windows ou OS X. L’application pourra être mise sur la plate-forme Leap Motion App Store - AirSpace qui permet le téléchargement des applications et leur installation automatique.
Notre application vise principalement des groupes comme :
● Musiciens amateurs
● Artistes numériques
Car ils ont besoin d’un outil qui leur permettra de composer, jouer de la musique en collaboration.
Notre application peut aussi attirer l'attention des amateurs qui veulent expérimenter la création de la musique de façon interactive et en collaboration, elle propose des fonctionnalités permettant de jouer de la musique sans contrainte et sans utiliser des équipements complexes et onéreux.
1.2 Etude des logiciels concurrents:
Nous avons étudié plusieurs applications existantes sur les différentes plateformes (OS X, Windows, iOS) et sur les différents types de support (iPad, Ordinateur, XBOX).
1.2.1 Mac OS X : Garageband
Le premier logiciel s’appelle GarageBand, c’est une application développée par Apple. Cette application est disponible sur la plateforme OS X (Mac) et iOS (iPhone, iPad)
Type d’interaction : tactile Développeur : Apple
Web : http://www.apple.com/fr/mac/garageband/
Prix : Gratuit + 4,49E (complet set of content) Plateforme : OSX, iOS
Nombre d’utilisateur : très grand
Multi joueur : Oui Fonctionnalité:
GarageBand nous propose plusieurs instruments musicaux pour créer des morceaux de musique, dans la version gratuite, il nous donne des instruments comme guitare, piano et drummer. Il nous permet aussi de jouer de la musique en collaboration avec d’autres équipements comme iPad et iPhone via Bluetooth. On peut aussi enregistrer, éditer et partager de la musique avec des amis facilement grâce à iCloud.
Cette application possède toutes les fonctionnalités qu’on envisage, la contrainte de cette application est qu’elle n’est disponible que dans le écosystème de Apple.
1.2.2 Kinect
Kinect est un capteur branché à la XBOX qui permet d’interagir par la commande vocale, la reconnaissance de mouvement et l’image. La sortie européenne a eu lieu le 10 novembre 2010.
Sur la plateforme Xbox, On a beaucoup de jeux vidéo en interaction avec Kinect, la plupart des jeux sont des jeux de danse et d’interprétation. Nous ne trouvons pas de jeu qui permet de composer de la musique et l ‘enregistrer après sa composition.
Un des jeux dans le domaine de la musique est “Dance Central”, Il propose une trentaine de musiques, comme Poker face de Lady Gaga, Satisfaction de Benny Benassi, etc. Le principe du jeu est de se déhancher sur la chorégraphie représentée à l'écran comme dans le reflet d'un miroir.
Du coup, malgré les nombreux utilisateurs de Kinect (24 millions de ventes dans le monde entier), on n’a pas de logiciels concurrents sur cette plateforme.
1.2.3 Leap Motion
Leap Motion est un petit boîtier qui permet de piloter notre ordinateur (PC ou Mac) grâce au contrôle gestuel.
Nous avons étudié trois applications existantes : Geco MIDI, Chordion Conductor et Bongos. Ils sont disponibles sur le marché AirSpace de Leap Motion.
Geco MIDI
Type d’interaction : Leap Motion Développeur : Uwyn
Web : https://airspace.leapmotion.com/apps/geco-midi/osx Prix : 9,99$
Plateforme : OSX, Windows Nombre d’utilisateur : < 1000 Multi joueur : Non
GECO est un outil pour contrôler des instruments MIDI sans contact physique, il ne sort pas directement des sons, mais il supporte beaucoup d’appareils musicaux, surtout des équipements professionnels. C’est une application pour des musiciens professionnels.
Chordion Conductor
Type d’interaction : Leap Motion Développeur : Olympia Noise Co.
Web : https://airspace.leapmotion.com/apps/chordion-conductor/osx Prix : 1,99$
Plateforme : OSX
Nombre d’utilisateur : < 500 Multi joueur : Non
Cette application nous permet de jouer de la musique en pointant des doigts aux boutons sur l’écran, la fonctionnalité est comme taper sur le piano. Le joueur peut aussi changer les mélodies et rythmes afin de générer de la musique intéressante.
Bongos
C’est une application gratuite, du coup, on l’a testé soigneusement, elle est un jeu qui crée des sons de batterie, il y a aussi une musique de fond pour s’accompagner et on peut la changer pendant le jeu. Ce jeu fonctionne bien avec 2 mains, il détecte bien le geste de glisser la main verticalement pour taper les “bongo”, de plus, l’interface est belle, c’est en 3D aussi. C’est un exemple utile pour nous. On remarque que si une troisième main entre, il va supprimer une des trois mains dans le frame. Aussi pour le son de la batterie, il est varié par la position (haut /bas) du point où on tape et la vitesse (fort/faible). Ce jeu a deux grandes fonctionnalités : une est la scène de jeu, l'autre est le menu en haut pour choisir la musique et le kit.
On a beaucoup de logiciels concurrents sur la plateforme Leap Motion, mais ils ne supportent pas la fonctionnalité de multi-joueurs, du coup, ils ne permettent pas de jouer ou composer de la musique en collaboration en interaction avec Leap Motion.
1.3 Positionnement
D’après l’analyse de l’utilisateur, nous trouvons qu’un jeu de musique a un grand potentiel sur le marché. Et notre produit est à la fois innovant et différent des produits concurrents. Nous avons donc placé notre produit à partir de l’analyse des résultats de notre enquête.
1.3.1 Consommation :
Il n’y a pas beaucoup d’applications développées pour le Leap Motion, nous constatons que sur le Leap Store il n’y a que 199 applications, 41 d’entre elles concernant le thème musical, mais peu d’application permettent de composer et faire de la musique, elles sont surtout basés sur la musique existante et manquent de possibilité de création.
En revanche, notre projet a pour but d’aider à créer de la musique et d’ajouter la dimension collaborative qu’on ne retrouve pas dans les autres applications musicale du marché AirSpace.
1.3.2 Prix
Comme il y a peu de produits existants, nous pourrions vendre notre produit sur Leap Store. Là où certains de nos concurrents de produits sont payants, notre produit sera gratuit ou vendu à un prix intéressant (moins de 3 euros selon l’enquête).
1.3.3 Canal de distribution
Notre produit sera disponible sur Leap Motion Airspace Store (https://airspace.leapmotion.com).
Ce marché est le plus grand marché pour les applications en interaction avec Leap Motion.
1.3.4 Communication
La communication sera axée sur l’universalité de notre produit. On peut faire de la publicité indépendamment du type de média, par exemple : par la presse, ou par des vidéos sur Internet (Youtube). De plus avec des réseaux sociaux (créer une page sur Facebook, ouvrir un compte Twitter, etc.), nous pourrions créer une
1.3.5 Produit
1. Notre produit pourrait être plus amusant que Bongos, parce que nous aurons des instruments musicaux variés (ex: piano, cymbale), et nous aurons plus de choix sur la musique de fond.
2. Il sera possible de jouer avec plusieurs personnes grâce au système multi- agents.
3. Notre produit est un prototype qui exploite le nouvel équipement Leap Motion avec une conception NUI (Nature User Interface).
4. Notre produit supportera plusieurs gestes pour faciliter l’interaction humaine-machine et améliorer l’expérience de l’utilisateur.
1.4 Fonctionnalités :
1.4.1 Fonctionnalités de base
Les fonctionnalités de base décrivent les caractéristiques principales de l’application et sont indispensables au bon fonctionnement de celle-ci.
Cette application permet de proposer deux types de jeu: jeu en solo et jeu en collaboration.
a) Jeu en solo :
L’utilisateur peut composer ou jouer de la musique seul.
L’utilisateur peut choisir l’instrument musical de son choix.
L’utilisateur peut faire une pause et continuer à jouer de la musique plus tard.
L’utilisateur peut changer la musique de fond pendant le jeu.
b) Jeu en collaboration :
L’utilisateur peut rejoindre dans une partie déjà existante et jouer de la musique avec les autres joueurs présents dans cette partie.
L’utilisateur peut créer une partie et attendre que les autres utilisateurs viennent afin de faire de la musique ensemble.
Seul le propriétaire de la partie, c’est à dire la personne qui a créé la partie, a le droit de choisir la musique de fond qu’il veut jouer.
Chaque utilisateur dans la même partie peut choisir l’instrument musical de son choix. Les instruments pourront être identiques ou différents.
Processus de jeu :
À l’ouverture de notre application, on propose deux choix. L’utilisateur peut soit décider de jouer ce jeu en solo, ou en collaboration.
Puis s’il est dans le premier cas, il peut ensuite choisir l’instrument musical de son choix et commencer à jouer directement. Pendant le jeu, l’utilisateur peut faire de la musique en faisant des mouvements, des gestes (plutôt avec la main et les doigts) en suivant le rythme de la musique.
Dans le deuxième cas, l’utilisateur choisi son instrument musicale préféré et s’il n’existe aucune salle de jeu, l’utilisateur peut créer une salle lui-même (il est le propriétaire de cette salle) et attendre que les autres utilisateurs rejoignent la partie.
S’il existe déjà une salle de jeu, l’utilisateur peut entrer dans la salle et attendre que le propriétaire de la salle décide de démarrer le jeu pour commencer à faire la musique avec les autres personnes.
Concernant le son, dans le cas du jeu en collaboration, l’utilisateur a le droit de sortir son propre son parmi tous les sons produit par l’équipe.
1.4.2 Fonctionnalités avancées
Nous proposerons quelques choix bonus au niveau des instruments musicaux disponibles.
Nous améliorons l’interface de jeu en ajoutant plus d’animation pour chaque instrument musical et proposerons plus de choix de musiques.
Dans le cas du jeu en collaboration, s’il existe déjà une salle de jeu, l’utilisateur n’est plus obligé d’entrer dans cette salle. Il a le droit de créer sa propre salle de jeu.
C’est à dire que nous permettons la création de plusieurs salles de jeux en parallèle.
De plus, pendant le jeu, nous permettons à un utilisateur (non propriétaire de cette salle de jeu) de quitter le jeu en laissant les autres utilisateurs de cette partie continuer à jouer de la musique. Si le propriétaire veut quitter le jeu, alors l’utilisateur qui est entré dans la salle juste après le propriétaire va prendre la place du propriétaire, dont le rôle est de contrôler la musique de fond, décider de commencer le jeu, etc.
2. Conception
2.1 Architecture de l’application
L’application utilise le modèle MVC pour la réalisation des fonctionnalités. Elle est divisée en trois parties: le modèle, la vue et le contrôleur. Le schéma ci-dessous illustre ce modèle appliqué dans l’architecture de l’application :
Afin d’interagir avec le modèle système MultiAgent(SMA), toutes les vues sont héritées de la classe mère : JAgentFrame, elle hérite de la classe Frame et implémente une interface PropertyChangeListener qui permet d’être capable de recevoir des notifications depuis le SMA.
Pour simplifier le modèle, dans le rapport NF28, nous utilisons l’UserAgent pour présenter le SMA.
Une fois que les objets de la vue ont demandé les informations au modèle UserAgent, le UserAgent reçoit la demande, puis répond aux sollicitations d'informations et utilise le propertyChangeSupport pour notifier les autres objets inscrits sur ce support. Le modèle MVC permet de réaliser la communication entre UserAgent et toutes les interfaces.
Dans la partie contrôleur, nous utilisons plusieurs listeners pour interagir avec l’utilisateur, parmi les listeners, le plus important est le LeapListener, il s’occupe de recevoir des informations essentielles sur le suivi des gestes de l’utilisateur, par exemple, il va appeler le modèle dès qu’il y a des mises à jour sur la position des doigts de l’utilisateur ou des gestes détectés pour le moment. Nous allons détailler cette partie dans le chapitre suivant.
Cette application permet de jouer de la musique toute seule, ainsi pour jouer de façon coopérative.
Single Mode
Lorsque l’utilisateur a choisi le Single Mode, le MenuView va notifier le modèle, et le modèle mémorise ce mode puis change la vue pour choisir l’instrument.
modèle notifie le GameView et lui envoie l’information sur l’instrument et l’utilisateur peut commencer à jouer de la musique via l’interface GameView.
Pendant le jeu, l’utilisateur peut jouer de la musique en faisant des gestes, et le LeapListener détecte les gestes et les envoie à le modèle, et puis, le modèle transmet les gestes au modèle de son qui va traiter les gestes et éventuellement émettre les différents sons selon les gestes reçus.
Multiple Mode
Par contre, si l’utilisateur a choisi le Multiple Mode, nous avons créé un MultiplayAgent pour gérer les comportements. A ce moment-là, la système est coupé en deux parties, serveur et client, le modèle de MVC est constitué par MultiplayAgent côté serveur et UserAgent côté client. Il y a le même mécanisme que Single Mode par rapport à la sélection de l’instrument et au traitement de son.
Une fois l’instrument sélectionné, la vue RoomSelectView est appelée au lieu de la vue GameView, l’utilisateur peut créer un nouveau groupe ou participer directement à un group existant via cette interface. dans le premier cas, l’utilisateur demande de créer un nouveau groupe à le modèle côté client(UserAgent), après, ce modèle envoie message à le modèle côté serveur (MultiplayAgent) pour demande de créer un groupe. Pour distinguer les différents groupes, le serveur distribue l’id pour chaque groupe comme l’identifiant et le renvoie au client, et puis le client crée une liste de joueurs de ce groupe en tant qu’elle a reçu ce message, par la suite, le client va aussi changer la vue ver MultiwaitRoom, dans laquelle, une liste de joueurs de ce groupe est affichée. Par contre, si dans le deuxième cas, l’utilisateur demande de participer à un groupe existant, le modèle côté client envoie cette demande avec l’identifiant de ce groupe à le modèle côté serveur, puis, le serveur ajoute l’id de utilisateur à ce groupe et notifie tous les autres clients de ce groupe de mise à jour la liste de joueurs, et chaque client réalise ce changement et l’affiche dans la liste de MultiwaitRoom. Dans la liste de joueurs, le premier utilisateur est le propriétaire de ce groupe, et il peut décider de commencer le jeu de ce groupe.
Si le jeu commence, interface de tous les utilisateurs est changée ver le GameView avec l’instrument sélectionné.
Il existe un autre cas, sur la vue MultiwaitRoom, si l’utilisateur veut quitter ce groupe, le modèle coté client envoie la demande à le modèle côté serveur avec l’identifiant de cet utilisateur et l’identifiant de ce groupe, après le serveur reçoit cette demande et la réalise, c’est à dire que cet utilisateur va être supprimé dans ce
groupe, puis le serveur notifie tous les autres utilisateurs de mettre à jour leur liste de joueurs. Du coup, notre liste de joueurs pour chaque groupe est ajouté et supprimé de façon dynamique.
2.2 Structure de données
Nous avons utilisé JSON (JavaScript Object Notaion) qui permet de réaliser la communication d’information dans notre application. Car nous utilisons le système MultiAgent comme le modèle, du coup, la communication au sein du modèle sont passé par le message, et pour transmettre des objets, nous utilisons la structure de données JSON pour transmettre des gestes et des notes dans notre modèle.
Pour transmettre des gestes, nous avons réalisé une classe “MoveInformData” qui porte des informations sur une position de gestes : les cordonnées de geste, la vitesse, la direction et l’instrument associé.
Pour envoyer des sons, nous avons créés une classe “NoteInformData” qui a porté le numéro de note, son volume, le type de instrument, etc.
Du coup, avant d’envoyer des classe, on a le sérialisé ver un format JSON et puis quand l’agent dans le modèle a reçu ces messages, il utilise des méthodes de classes pour déserialiser de JSON ver un objet.
L’avantage de ce type de structure de données est indiqué ci-dessous:
● Peu verbeux, ce qui le rend lisible aussi bien par un humain que par une machine.
● Facile à apprendre, car sa syntaxe est réduite et non extensible (bien que ne souffrant que de peu de limitations).
● Ses types de données sont connus et simples à décrire.
2.3 Gestion de son Il y a 2 partie:
● La gestion du son des instruments
● La gestion de la musique du fond
Globalement tout le son dans un groupe se représente sur une seule machine
le même endroit, nous proposons la possibilité que chaque utilisateur reçoit le son de tous les utilisateur dans la groupe.
2.3.1 La gestion du son des instruments
Nous avons utilisé la librairie MIDI pour manipuler et centraliser des sons des instruments. Le son des instruments est représenté par des notes. Le tambour est un instrument particulier il a sa propre voie du son (canal), nous avons utilisé 4 sons de percussion. La guitare a 8 accords, chaque accord concerne une liste des notes.
Tous les type de notes sont encapsulés dans un message qui contient type d’instrument, numéro de notes. Ensuit, la machine de joueur va les traiter et les séparer dans les canaux pour chaque instrument, enfin de les émettre sur une machine.
2.3.2 La gestion de la musique du fond
Actuellement réalisé 2 type de format de la musique, .midi et .mp3, nous avons la possibilité de commencer, arrêter, recommencer la musique du fond, ainsi que la manipulation de la volume de la musique.
3. Interface
3.1 Vue de bienvenue
La vue de bienvenue est constituée de 3 boutons pour renter à différents modes : Mode individuel, Mode multi-joueurs et quitter le jeu. Et au milieu et en haut de la fenêtre, c’est le logo de notre projet.
3.2 vue de menu d'instruments
Un carrousel : la liste d’instrument : Tambour, Guitare, Piano.
Ainsi, au clic sur l’affiche d’un instrument, l’utilisateur peut accéder à la vue de jouer de la musique. Ce carrousel prend alors tout l’espace disponible sur l’écran.
L’utilisateur peut sélectionner un instrument du carrousel et accéder alors à la vue de jouer.
3.3 Vue de jouer
Cette interface est au cœur de l’application. La vue de jouer contient 2 parties principales séparé par :
➔ Un barre d'outils pour la manipulation de la musique du fond et la navigation.
❖ Un bouton de navigation au bureau.
❖ Une image de portrait d'utilisateur.
❖ Un grand bouton pour choisir la musique, qui permet d’afficher une fenêtre qui contient une liste des chansons et un bouton de confirmation.
❖ Trois boutons pour arrêter/commencer le chanson, changer à la prochaine chanson, et changer à la chanson avant.
❖ Un bouton rotatif pour manipuler la volume d’instrument.
➔ Un champ d’interface de jeu pour jouer de la musique.
Cette vue permet à l’utilisateur d’ajouter des instruments. Cette interface liée la présentation de la geste des mains ainsi que la affichage de instrument. le jeu se fait simplement via les boutons en présentant des différents partie des instruments.
Actuellement, nous avons réalisé l'interface de Guitare et Tambour.
Il y a 2 parties communes.
❖ une image au fond
❖ deux ellipses en couleur jaune et bleu qui attache 2 mains séparément.
❖ Tambour:
Deux boutons de tambour. Si la main rentre dans le zoom définitif, avec la geste
“tape” et une certaine vitesse, le bouton pourrai grandir et revient la même forme dans un second. A ce moment-là, un son va directement apparaître qui correspond le zoom.
❖ Guitare:
L’interface guitare a 8 widgets qui présentent accords de guitare. Si la main rentre dans le zoom de accords, avec la geste “swipe down” et avec une certaine vitesse, le accord change sa couleur pour informer l'utilisateur que ce accord est vient être joué. A ce moment-là, un son va directement apparaître qui correspond le zoom.
3.4 vue de multi- joueurs Créer une salle de jeu
L'utilisateur pourrai créer une salle, et attend des joueurs y entrent, la liste des joueurs va apparaître dans la boîte à côté. Cependant, il pourrai définir de commencer une partie de jeu, ou bien quitter la salle.
Choisir une salle
Le champ liste va permettre à l’utilisateur de choisir une salle listée. Lorsque l’utilisateur entrera la mode multi-joueur, L’utilisateur pourra alors sélectionner un élément de la liste qui apparaîtra, si il y déjà existe des salles créées.
❖ deux trigger boutons qui générer la choix de rentrer/sortir de la salle, créer une nouvelle salle/commencer le jeux.
❖ une image du fond
❖ une liste
❖ un bouton de bureau 3.5 Analyse IHM
● Guidage
Il sert de guide lors de la conception d’interface utilisateur en aidant les concepteurs à prendre en compte.
Pour la navigation nous avons mis un bouton de maison pour que l’utilisateur puisse toujours revenir sur l’étape précédente en cas de geste d'erreurs.
Nous avons utilisé des couleurs claires, par exemple, le bleu et le jaune pour 2 mains. Mais aussi nous avons pris en compte la fatigue visuelle de l’utilisateur, donc nous avons choisi les couleurs pastel pour des bouton.
Le déroulement de jeux est la façon générale:
Choisir un mode ->choisir un instrument ->commencer à jouer
Pour la séance multi-joueurs : choisir/créer une salle -> commencer à jouer
● Évaluation d’utilisabilité
Concernant le stabilité de capture les différents gestes et la position des mains, nous avons augmenté la taille des boutons pour utilisateur cibler le choix plus facilement
Au niveau de définition de gestes, nous avons choisi des gestes plus simples, voir ici:
Pour cibler le choix, au lieu de mettre une geste de “Keytap” , qui peut avoir un problème de confirmation de la position à cause du tremblement des mains, nous avons défini la validation de “Click” le bouton, nous allons discuter davantage dans le chapitre suivant.
● Contrôle explicite
Pour utilisateur bien apprendre à la main comment fonctionner l’application, nous avons mis des fonctionnalités important dans le champ plus visible et accessible (écran en haut, écran à droit).
Pour faciliter l'apprentissage, tous les image d’instrument ressemble le vrai, de plus avec le mouvement de bouton ou le changement de couleur, utilisateur pourrait savoir plus comment jour.
● Aide et documentation
Nous avons mis en place un site web, de où utilisateur peut trouver des explications de jeu, y inclut un document sur la configuration d’application, une vidéo de la démonstration de jeu.
4 Contrôle
Dans ce chapitre, nous expliquons le partie contrôle de notre projet, nous illustrons comment ça marche pour le capteur leap motion, comment nous adaptons cet appareil pour intégrer les fonctionnalités dans notre projet, et comment notre code réagit avec la contrôleur, etc.
4.1 Le Leap Motion
Leap motion est un capteur de mouvement des doigts, il est capable de détecter des mouvements au maximum 200 frames par seconde, grâce à cette appareil et le SDK fournie, on a permet de récupérer les positions de doigts de l’utilisateur.
Le Leap Motion fait partie de la contrôleur de le modèle MVC, Nous avons instancié une classe Controller pour gérer la connections avec l'appareil leap motion.
Nous avons aussi créé une classe LeapListener pour interagir avec les données fournie par le capteur. Cette classe hérite la classe Listener, et il “override” la méthode onFrame() afin de récupérer les données dans chaque snapshot.
Cette méthode est appelée quand le capteur a fourni un nouveau frame et dans cette méthode, nous pouvons récupérer toutes les données concernant les informations sur le suivi des doigts. Par exemple, les position 3D de tous les doigts et les mains de l’utilisateur, la vitesse, directions de mouvement de doigt ou main. En outre, le capteur peut aussi détecter les mouvements des “pointables” comme un crayon, un stylo, etc.
Grâce à la dernière version de SDK, nous sommes capable de récupérer des gestes simple dans le frame.
4.1.1 onFrame
Car cette méthode est appelé très fréquent (plus de cent fois par second), du coup, nous faisons des choses légères mais efficace dans cette bloc.
Dans notre projet, on a besoin principalement trois information:
La position d’un doigt, le type de geste (au cas où) et la position des mains.
Du coup, dans le bloc, nous vérifier tout abord s’il y a des gestes détectés dans le frame, si oui, on le traite, sinon, on passe par la détection des mains. Et à la fin, on
mains. L’avantage de cet ordre est que nous ne voulons pas de déclencher plusieurs mise à jour de le modèle dans la même temps, car du point de vue de l'utilisateur, ce n’est pas normale de changer plusieurs comportements dans la même temps, et nous définissons la priorité de comportement dans cette bloc afin que notre application puisse mieux réagir à l’action de l’utilisateur dans chaque frame.
4.1.2 Détection des mains
Pour tracer le mouvement de notre main sur l’écran, on a besoin de faire un mapping des cordonnées de leap motion ver les cordonnées de notre application, car les cordonne de leap motion sont basés sur l’unité de longueur réel (millimètre) et dans notre application, les cordonnées sont basés sur le taille de l’écran avec l’unité de pixel, du coup, il faut bien convertir les cordonnées de leap motion afin que application puisse bien afficher le curseur ou les représentants de main sur l’écran.
Pour améliorer la précision de la détection de mains, car le position fournie par leap motion est très sensible de mouvement, il peut détecter des petit mouvement et après la conversion de cordonne, cette petite mouvement devient un vibration dans l’écran, et ça va causer des problème si l’utilisateur veut rester ses mains dans un position, du coup, nous calculons la position moyenne de tous les doigts d’un main dans le frame, et nous ignorons des petits vibration sur l’écran, cela nous permet de réduire erreur et améliorer la performance de notre suivi de main.
4.1.3 Détection de gestes
Afin de améliorer l’expérience de notre jeu, nous développons quelque type de gestes:
- Glisser : Bouger le paume à gauche, à droite, ver haut et ver bas.
- Cercle : tourner un doigt - Saisir : fermer une paume
- Frapper : bouger la main rapidement
Pour le geste “glisser”, nous utilisons ce geste pour choisir des instruments et sélectionner de la musique de fond.
Pour le geste “cercle”, dans notre jeu, ce geste est réservé pour changer la volume de son d’instrument car le bouton est en rond.
Pour “saisir”, c’est dans l’interface de la confirmation de choix de l'instrument.
Pour “frapper”, c’est le geste le plus utile, nous détectons ce geste pour frapper le tambour ou gratter des cordes de la guitare pour faire un “sweeping”.
Dans un frame, c’est possible qu’il y a plusieurs gestes détectés, et pour la même type de geste, il peut être détecte plusieurs fois, du coup, pour améliorer la performance et la précision de la détection, nous comptons le nombre de geste détecter dans le frame par son type, et dans chaque frame, nous sélectionnons le geste avec le nombre de fois de détection le plus élevé. Cela nous permet de sélectionner le geste le plus possible dans le frame.
Car la fréquence de frame est très élevé, nous réduisons l'intervalle de détection de geste artificiellement, concrètement dit, quand un geste est détecté, la partie de détection de geste est suspendu pendent quelque instance (par exemple 0.75 seconde), pour que le Leap Listener ne déclenche pas plusieurs geste dans la
“même temps”. Par contre, le suivi de main n’est pas suspendu pendant cet intervalle.
4.1.4 Sélection d’un objet
Le SDK de leap motion propose un geste “screen tap” : pointer un doigt ver l’écran et bouger rapidement ver l’écran. Ce geste est similaire un clique sur un tablette. D’abord, on implémente ce geste pour simuler un clique sur des bouton, mais après quelque tests, nous avions pensé que ce n’est pas facile de cliquer sans erreur, mais c’est facile de pointer ver un objet pendant longtemps, du coup, on a développé une méthode pour cliquer l’objet, il faut pointer ver un objet pendant 2 seconde, et après il va déclencher une action de clique ver l’objet. si l’utilisateur bouge le doigt et pointer ver un endroit à extérieur de l’objet, il ne déclenche pas de clique, et si l’utilisateur pointe ver un objet et puis pointe ver un autre objet et puis ré-pointe sur le premier objet, le code recalculé le temps de 2 seconde, du coup, pour cliquer un objet, il faut le pointer successivement pendant deux secondes.
4.1.5 Communication dans le système.
Dans notre projet, LeapListener procède une référence de le modèle mais pas de lien directe avec le vue, du coup, tous les communication sont passés par le modèle, et quand le listener veut mettre à jour le vue, par exemple mettre à jour la position de main dans l'écran, il appelle la méthode de le modèle, et dans la méthode de
la mise à jour de main n’est que nécessaire dans le vue GameView, et si ce vue n’est pas visible pour l’utilisateur, le modèle n’a pas besoin d’informer cette changement à la vue. par contre, si le modèle pense que le changement est nécessaire pour le vue, il va envoyer un événement à la vue. et le vue peut appliquer ce changement.
5. Outil utilisés
Eclipse:
Eclipse est l’environnement de développement intégrale de notre projet.
GitHub:
GitHub est un service web d'hébergement et de gestion de développement de logiciels, utilisant le logiciel de gestion de versions Git.
GitHub propose des comptes professionnels payants, ainsi que des comptes gratuits pour les projets de logiciels libres.
Nous avons choisi d’utiliser le GitHub pour partager, échanger les codes et pour travailler de façon coopératif et efficace.
Leap Motion:
Leap Motion est le centre et contrôle pour le développement de notre projet.
6. Difficultés rencontrées, modifications apportée
Quelques éléments prévus lors de la phase de conception ont été amenés à une modification pendant la phase d’avancement selon les conseils de M. Ala ATRASH pendant le TD.
Difficulté:
La première difficulté que nous avons rencontrée est la précision des gestes.
Modifications apportée:
Donc par conséquence, nous avons premièrement grandi la taille de nos éléments dans toutes les interfaces.
Difficulté:
La geste de type “screentap” que nous avons définie au début de projet dont le rôle est de cliquer les boutons n’est pas pratique (il faut poussons notre doigt vers l’avant et après revenir presque à la position originale). Nous trouvons que cette geste n’est pas facile à prendre en main bien pour les utilisateurs débutants qui n’ont aucune expérience d’utiliser un Leap Motion.
Modifications apportée:
Nous avons donc pensé à changer les gestes qui permettent de choisir un objet ou cliquer une bouton de façon plus pratique et plus précisée.
Premièrement, dans le cas de geste qui permet de cliquer une bouton, nous mettons un Timer de 1.6 secondes, si l’utilisateur peut laisser son main pendant ce 1.6 secondes sans bouger, le programme confirme donc son choix et fait l’action correspondante.
Après, dans le cas d’une geste qui permet de choisir un objet, nous avons changé notre geste de parcourir notre main dans le sens vertical (swipe) par la geste de faire un poing.
De plus, pour l’amélioration de premier cas, nous avons ajouté une photo
l’avancement de timer afin de rendre l’utilisateur savoir clairement combien de temps qu’il reste à rester son main dans la même position
Pour les difficultés technique, par exemple comment fait tourner un bouton pour changer le volume de son, comment fait transparent d’un élément Swing, etc. Nous premièrement chercher sur Google ou les communautés , Si nous n’avons pas trouver des solution intéressant, nous demandons l’aide de professeurs ou notre camarades.
7. Limites du prototype et amélioration possibles
Prochaine étape : ajouter la possibilité de jouer du piano.
➢ Amélioration de mode multi- joueurs
il fait prendre en compte la sécurité d’entrer des salles afin d’éviter quelques utilisateurs faisant des bêtises.
➢ Amélioration d’analyse de capture de geste: plus fluide, adaptée la
geste varié (inviter quelques utilisateurs à tester notre application pour analyser la vitesse de mouvement, la geste générale ).
➢ Amélioration de la gestion de son:
Dans le cas de la musique du fond, ajouter la possibilité de la lecture des chansons en format varié, par exemple .wav. Et l’utilisateur peut télécharger son propre son au serveur. L’utilisateur peut enregistrer le son qu’il vient de interpréter.
➢ Ajouter un mode concurrent
Ce mode permet à deux utilisateurs de faire une concurrence en jouent de la musique. Les deux utilisateurs prennent le même instrument musical. Nous pouvons juger qui jouer mieux entre les deux.
8. Conclusion
Par rapport à notre cahier des charges, nous pouvons dire que nous avons réalisé toutes les fonctionnalités que nous avions défini: les fonctionnalités de base et les fonctionnalités avancées. Nous pouvons jouer de la musique en collaboration.
C’est le point fort de notre projet qui nous permet de nous distinguer au milieu des autres concurrents. Notre produit permet de faciliter la vie des utilisateurs qui voudraient jouer de la musique de temps en temps sans avoir besoin d’acheter un équipement cher et ils peuvent aussi inviter leurs amis à jouer de la musique avec eux dans une même équipe.
Le développement de notre projet nous a amené à travailler au sein d’un groupe de 6 personnes (4 personnes + 2 personnes venant de l’UV IA04). Etant habitués au travail en binôme, c’est un grand challenge pour la gestion de projet. Mais grâce à GitHub, nous avons pu suivre l’avancement de chaque personne dans l’équipe de façon efficace.
Nous avons eu une réunion hebdomadaire après le TD sur l’avancement de projet.
Pendant la réunion, nous avons fait un bilan sur ce que nous avons fait et ce qu’il faut faire dans la semaine prochaine. Ces réunions sont très importantes tout au long de notre projet.
