The Big Bad World of Exercise

Transcription

Master 2 Interaction Homme-Machine
Mémoire de fin d’études
The Big Bad World of Exercise
2009-2010
Louis NOVAL
Mémoire | BBWoE 2010
2
RESUME
Le présent document décrit l’ensemble du travail réalisé dans le cadre de mon stage qui a eu
lieu du 26 mars 2010 au 27 aout 2010 dans le laboratoire EQUIS à Kingston, Canada. Ce laboratoire,
spécialisé dans la recherche autour des jeux vidéo collaboratifs, travaille sur les exergames depuis une
dizaine d’années. Le but du stage a été de produire une plateforme d’aide au prototypage d’exergame.
Vous trouverez dans ce document : une description de la démarche mise en œuvre, les moyens utilisés
et les résultats obtenus.
Mots-clefs : Exergame, jeu vidéo, jeux vidéo de plateforme, réseau, Farseer physics, moteur physique,
XNA.
ABSTRACT
This document describes all the work done as part of my internship, which took place from
March 26th, 2010 to August 27th, 2010 in EQUIS laboratory in Kingston, Canada. This laboratory
specializes in research around collaborative video games working on Exergame past ten years. The aim
of the course was to produce a platform for prototyping assistance exergame. You will find in this
document: A description of the design process, the means used and the results leading to an exergame
prototyping platform.
Tags: Exergame, video game, platformer, network, physics engine, Farseer physics, XNA, HCI.
3
4
TABLE DES MATIERES
Résumé ......................................................................................................................................................... 3
Abstract ......................................................................................................................................................... 3
Table des figures ........................................................................................................................................... 9
Remerciements ........................................................................................................................................... 11
Introduction ................................................................................................................................................ 13
Guide de lecture.......................................................................................................................................... 15
Contexte ...................................................................................................................................................... 17
1.
Présentation du laboratoire........................................................................................................... 17
2.
Les projets : l’exergame dans le laboratoire .................................................................................. 17
3.
Les utilisateurs ............................................................................................................................... 17
4.
Rappel du sujet .............................................................................................................................. 18
5.
Objectif........................................................................................................................................... 18
Gestion de projet ........................................................................................................................................ 19
1.
Méthode ........................................................................................................................................ 19
2.
Gestion des risques ........................................................................................................................ 21
3.
Livrables ......................................................................................................................................... 21
4.
Les parties prenantes du projet ..................................................................................................... 22
Analyse ........................................................................................................................................................ 23
1.
2.
Analyse de l’existant : Life Is A Village ........................................................................................... 23
a)
Gameplay .............................................................................................................................. 23
b)
La plateforme de développement......................................................................................... 23
Etat de l’art .................................................................................................................................... 24
a)
L’exergame multi-joueurs ..................................................................................................... 24
b)
Les jeux de plateformes ........................................................................................................ 27
5
3.
4.
Technologie .................................................................................................................................... 30
a)
Hardware ............................................................................................................................... 30
b)
Software ................................................................................................................................ 31
Bilan de l’analyse ........................................................................................................................... 32
Conception .................................................................................................................................................. 33
1.
Introduction ................................................................................................................................... 33
2.
Le monde virtuel ............................................................................................................................ 33
3.
L’avatar dans ce monde virtuel...................................................................................................... 35
a)
Durant la phase d’apprentissage .......................................................................................... 35
b)
Les premières versions du monocycle et du tank ................................................................. 36
c)
Interaction de l’avatar sur les entités de ce monde virtuel .................................................. 37
évolution du système de commande............................................................................................. 38
4.
5.
d)
Un troisième avatar et une amélioration des précédents .................................................... 40
e)
Nouveau design graphique ................................................................................................... 41
Plusieurs mondes virtuels ? ........................................................................................................... 41
a)
Première version : découverte de JANUS ............................................................................. 41
b)
Deuxième version : la première version réellement multi-clients........................................ 42
c)
Troisième version : optimisation........................................................................................... 43
d)
Quatrième version : ajout de fonctionnalités et du système de succès ............................... 44
De l’analyse à la conception : évolution des objectifs dans le projet ............................................ 45
Architecture logicielle ................................................................................................................................. 47
1.
Le client .......................................................................................................................................... 47
MotherClass et BBWoE .................................................................................................................. 48
6.
a)
CurrentGame ......................................................................................................................... 49
b)
GameEntity ............................................................................................................................ 50
Serveur ........................................................................................................................................... 50
6
a)
7.
Le serveur .............................................................................................................................. 50
Réseau............................................................................................................................................ 51
Evaluation ................................................................................................................................................... 53
Bilan et Perspectives ................................................................................................................................... 55
1.
Bilan ............................................................................................................................................... 55
2.
Perspectives ................................................................................................................................... 55
Bibliographie ............................................................................................................................................... 57
Glossaire...................................................................................................................................................... 60
Annexes ....................................................................................................................................................... 62
1.
2.
3.
4.
Les textures de BBWoE .................................................................................................................. 62
a)
Avatars .................................................................................................................................. 62
b)
Surfaces ................................................................................................................................. 63
c)
Les objets du monde ............................................................................................................. 64
d)
La maison .............................................................................................................................. 66
Rapport de Brainstorming ............................................................................................................. 67
a)
Première réunion .................................................................................................................. 67
b)
Deuxième réunion ................................................................................................................. 68
c)
Troisième réunion ................................................................................................................. 70
Test utilisateurs.............................................................................................................................. 72
a)
First user test......................................................................................................................... 72
b)
Second user test .................................................................................................................... 73
Architecture client ......................................................................................................................... 75
a)
Overview ............................................................................................................................... 75
b)
Focus on the object hierarchy ............................................................................................... 78
c)
Focus on the loading phase ................................................................................................... 79
d)
Focus on GameEntities properties ........................................................................................ 80
7
e)
5.
How the avatars works? ........................................................................................................ 81
Documentation développeur supplémentaire .............................................................................. 83
a)
How the entities works? ....................................................................................................... 83
b)
Moving BBWOE from computer to computer ...................................................................... 84
c)
Tiny things that can create troubles ..................................................................................... 85
6.
Le wiki ............................................................................................................................................ 86
7.
Présentation du projet ................................................................................................................... 86
8.
Etat de l’art .................................................................................................................................... 86
9.
a)
Life is a village........................................................................................................................ 86
b)
Persistent or Asynchronous gameplay (in multiplayer game) .............................................. 88
Details des Sprints.......................................................................................................................... 91
a)
Avant le premier sprint ......................................................................................................... 91
b)
1er Sprint : du jeudi 1er Avril au jeudi 15 Mai ...................................................................... 91
c)
2eme Sprint : du jeudi 15 Avril au jeudi 29 Mai .................................................................... 92
d)
3eme Sprint : du jeudi 29 Avril au jeudi 13 Mai .................................................................... 92
e)
4eme Sprint : du lundi 17 Mai au jeudi 27 Mai ..................................................................... 92
f)
5eme Sprint : du jeudi 27 Mai au jeudi 10 Juin ..................................................................... 92
g)
6eme Sprint : du jeudi 10 Juin au jeudi 24 Juin ..................................................................... 92
h)
7eme Sprint : du jeudi 24 Juin au jeudi 15 Juillet.................................................................. 93
i)
8eme Sprint : du jeudi 15 Juillet au jeudi 29 Juillet............................................................... 93
j)
9eme Sprint : du jeudi 29 Juillet au jeudi 19 Aout ................................................................ 93
8
TABLE DES FIGURES
Figure 1 : le stage d’un point de vue sprint ................................................................................................ 19
Figure 2 : processus de conception en spirale ............................................................................................ 20
Figure 3 : les parties prenantes ................................................................................................................... 22
Figure 4 : LiaV .............................................................................................................................................. 23
Figure 5 : Nintendo Wii Fit .......................................................................................................................... 24
Figure 6 : Microsoft Kinect .......................................................................................................................... 24
Figure 7 : Sony Playstation Move ................................................................................................................ 24
Figure 8 : Nautilus ....................................................................................................................................... 26
Figure 9 : Breakout for two ......................................................................................................................... 26
Figure 10 : Space Panic (1980) .................................................................................................................... 28
Figure 11 : Super Mario Bros (1985) ........................................................................................................... 28
Figure 12 : Sonic qui court .......................................................................................................................... 28
Figure 13 : Sonic en boule ........................................................................................................................... 28
Figure 14 : X-moto....................................................................................................................................... 29
Figure 15 : Super Paper Mario .................................................................................................................... 29
Figure 16 : manette de Xbox 360 ................................................................................................................ 30
Figure 17 : PCGamerBike ............................................................................................................................ 30
Figure 18 ..................................................................................................................................................... 31
Figure 19 ..................................................................................................................................................... 31
Figure 20 ..................................................................................................................................................... 31
Figure 21 : "FloatingPlatform" .................................................................................................................... 34
Figure 22 : BBWoE à ses débuts .................................................................................................................. 34
Figure 23 : "Ramp" ...................................................................................................................................... 34
Figure 24 : la chenille et la boule ................................................................................................................ 36
9
Figure 25 : le monocycle ............................................................................................................................. 36
Figure 26 : le tank........................................................................................................................................ 36
Figure 27 : l'ascenseur en fonctionnement ................................................................................................ 38
Figure 28 : commande à revoir ................................................................................................................... 39
Figure 29 : New Beetle ................................................................................................................................ 40
Figure 30 : New Beetle 2.0 .......................................................................................................................... 40
Figure 31 : monocycle final ......................................................................................................................... 41
Figure 32 : New Beetle finale ...................................................................................................................... 41
Figure 33 : configuration réseau 1ere version .............................................................................................. 41
Figure 34 : configuration réseau 2e version ............................................................................................... 42
Figure 35 : dialogue client serveur, première version ................................................................................ 43
Figure 36 : dialogue client serveur, version finale ...................................................................................... 43
Figure 37 : vue état/événement du dialogue client/serveur ...................................................................... 44
Figure 38 : apercu global du client .............................................................................................................. 48
Figure 39 : l'architecture des entités .......................................................................................................... 49
Figure 40 : aperçu du serveur ..................................................................................................................... 50
Figure 41 : Janus dans BBWoE .................................................................................................................... 51
10
REMERCIEMENTS
Je tiens à remercier Nicholas Graham pour m’avoir offert la possibilité d’effectuer ce stage de
cinq mois au Canada et d’avoir été d’une aide précieuse tout au long du projet. Je remercie également
Eril Berkok avec qui j’ai travaillé sur ce projet. Tad Stach également, qui a aidé tout au long du projet, en
partageant son expérience des exergames. Cheryl Savery qui a conçu JANUS pendant ce stage et a aidé à
son intégration. Chris Wolfe, pour sa connaissance, quasi-biblique, de la technologie « .Net ». Enfin tous
ceux de l’EQUIS laboratory qui ont collaboré de près ou de loin au travers, notamment, de la conception
participative.
De l’autre cote de l’océan cette fois, je tiens d’abord à remercier mon tuteur pédagogique, Philippe
Palanque, pour son humour et sa disponibilité. Je remercie également tous les gens qui ont fait ce que le
master IHM est aujourd’hui, mais aussi l’ensemble du master sans qui ce stage n’aurait pas été possible.
Enfin je remercie Laëtitia Ferrari pour avoir passé autant de temps à la relecture, parfois fastidieuse, de
ce rapport.
11
12
INTRODUCTION
Les changements de nos modes de vie impliquent une sédentarisation de plus en plus
importante de la population. Cette baisse du temps passé à l’extérieur du foyer familial est en partie due
à la présence de plus en plus forte des écrans dans notre vie de tous les jours, aux travers de médias
comme les jeux vidéo, eux aussi en forte progression. Tous ces changements entrainent des
conséquences plus ou moins importantes sur notre société, comme l’augmentation de l’indice moyen
masse corporelle de la population mais aussi l’augmentation de la population déclarée comme obèse.
L’exergame, l’association de jeux vidéo et d’effort physique, permettrait sous certaines conditions qui
seront décrites dans la partie analyse de ce document, de promouvoir l’activité physique et ainsi
améliorer l’état de santé des plus sédentaires d’entre-nous.
L’EQUIS laboratory travaille sur l’exergame depuis de nombreuses années. Les tests actuels
étant tous effectués dans le laboratoire, il est impossible de statuer sur la motivation d’un joueur à
pratiquer un exergame après plusieurs semaines de jeu. L’arrivée sur le marché de solution de mini vélo
USB comme le PCGamerBike allié à un outil qui permettrait au laboratoire de développer à terme un
exergame 2D multi-joueurs et ainsi de prendre en compte de nouveaux facteurs comme les aspects
sociaux d’un exergame.
13
14
GUIDE DE LECTURE
Contexte ………………………………………………………………………………………………………………………………….………..p.17
Cette partie présente l’environnement qui a entouré ce stage, le laboratoire, les projets dans lesquels il
est impliqué, les utilisateurs de BBWoE ainsi que les objectifs initiaux du stage.
Gestion de projet ………………………………………………………………………………..…………………………………………….p.19
Vous trouverez dans cette partie des détails relatifs à la méthode employée durant ce projet, les risques
inhérents au projet et enfin les livrables attendus.
Analyse de l’existant ……………………….……………………………………………………………………………..……….………..p.23
Vous trouverez une analyse de « Life is a Village » dans cette partie. Un projet d’exergame de l’EQUIS
laboratory en 2002, qui est très proche de ce projet de stage.
Etat de l’art ………………………………………………………………………………………………………………………….….………..p.24
Cet état de l’art présente dans un premier temps des jeux de plateforme au travers d’un historique
pour, dans un second, présenter les spécificités de la conception d’un exergame multi-joueurs.
Conception …………………………………………………………………………………………..…………………………………….……..p.33
Cette partie parcourt le projet sous quatre angles différents : conception de l’avatar, conception du
monde dans lequel il évolue, mise en réseau des mondes virtuels et enfin évolution des objectifs durant
le projet.
Architecture logicielle ……………………………………………………………………..…………………………………….………….p.48
Probablement la partie la plus technique du projet, elle décrit le prototype final aux moyens de
diagramme UML. Elle apporte aussi des informations sur le fonctionnement du JANUS.
Evaluation …………………………………………………………………………………………………………………………….…………..p.54
Cette partie revient sur les retours des utilisateurs durant le projet et explique comment aurait du être
testé BBWoE si nous avions eu les ressources pour le faire.
Bilan et perspectives …………………………………………………………………………………………………………………………p.56
Enfin, vous trouverez un bilan d’avancement du projet, mais aussi des pistes possibles d’évolution de
BBWoE. Cette partie est aussi pour moi l’occasion de donner mon point de vue sur ce que ce projet m’a
apporté.
15
16
CONTEXTE
1. PRESENTATION DU LABORATOIRE
L’EQUIS laboratory (“Engineering Interactive Systems at Queen’s University”) est un laboratoire
qui est spécialisé dans la recherche autour des jeux vidéo collaboratifs. Ces travaux se concentrent
autour de quatre axes : l’exergaming, les architectures collaboratives (groupware), les jeux sur surface
multitouch et l’audio ambiant dans les jeux d’extérieurs. De plus le laboratoire travaille en partenariat
avec des entreprises prestigieuses comme Alcatel-Lucent ou encore AutoDesk.
2. LES PROJETS : L’EXERGAME DANS LE LABORATOIRE
L’axe exergame existe dans l’EQUIS laboratory depuis une dizaine d’années déjà. Les gros
projets effectués dans cet axe ont tous un point commun : Life Is A Village (LIAV). Ce projet a permis de
fournir au laboratoire un exergame 3D avec une structure modulaire qui permet de rapidement
personnaliser l’avatar ou le monde qui l’entoure, afin de recréer son propre mini-jeu.
Cependant manipuler des objets 3D et tout un environnement, demande plus de temps de
développement qu’un simple univers 2D. Son utilisation est donc délicate surtout quand le laboratoire
veut prototyper un mini-jeu afin de conduire des tests utilisateurs en moins de deux mois. L’EQUIS
laboratory utilise également la technologie XNA pour prototyper des mini-jeux à des fins de test. Un
remplacement de LIAV en 2D en utilisant la technologie XNA permettrait de réduire, voir d’annuler le
temps d’apprentissage d’une nouvelle technologie.
Le prototype que je développerais permettrait également de tester un exergame sur une plus grande
période. En effet le laboratoire n’a pas les ressources pour développer un jeu vidéo 3D avec
suffisamment de contenu pour motiver des gens à y jouer pendant plusieurs semaines. Ce but est à plus
long terme et ne sera pas atteint pendant ce stage.
3. LES UTILISATEURS
Dans ce projet, il y a deux types d’utilisateurs bien distincts :


le premier groupe d’utilisateur est composé des chercheurs de l’EQUIS laboratory qui se
serviront de BBWoE pour développer des mini-jeux à tester. Leur profil peut varier
légèrement, mais ils ont tous en commun d’avoir des antécédents de développement
sous XNA et donc des compétences en développement C#. Il se regroupe sous le terme
« développeur » utilisé dans la suite de ce document ;
le deuxième groupe d’utilisateurs, qu’on appellera « utilisateurs finaux », se compose de
joueurs potentiels du prototype de jeu développé durant le stage. Le public visé est très
large puisque il concerne toute personne qui pourrait être intéressée pour jouer à un
exergame. Les collègues du laboratoire forment un groupe d’utilisateurs finaux
potentiels assez divers. Il faudra cependant bien choisir les personnes pour éviter un
17
échantillon trop jeune ou constitué d’une population plus accro aux jeux vidéo que la
moyenne.
4. RAPPEL DU SUJET
« Développer un prototype itératif d’exergame utilisant un PcGamerBike (via une API fournie).
Afin d’améliorer les possibilités et le gameplay du jeu, le stagiaire devra utiliser Farseer Physics pour
XNA afin d’intégrer une gestion réaliste de la physique. Le type de jeu vise à se rapprocher d’un jeu de
plateforme évolué, auquel on ajoutera des composants nécessaires à tout exergame (voir la publication
de Tadeusz B. Stach). »
5. OBJECTIF
Le but initial du stage est donc de produire un prototype d’exergame. Ce prototype devra être
développé incrémentalement, l’analyse permettra d’orienter les choix les plus importants de
conception. Cependant la méthode utilisée pendant ce projet permet une flexibilité qui amènera à
probablement réorienter ou affiner cet objectif.
Remarque : consulter le chapitre 5 de la phase de conception pour plus de détails sur les objectifs du
projet.
18
GESTION DE PROJET
1. METHODE
La méthode AGILE est une méthode itérative et incrémentale de développement. Seuls des
petits incréments du prototype sont modifiés à chaque itération : l’important est de fournir un code
fonctionnel à chaque fin d’itération, appelé sprint. A l’EQUIS laboratory un sprint dure 2 semaines. Cette
méthode d’itération très rapide présente le gros avantage de permettre des tests très réguliers sur des
parties spécifiques du prototype. Les résultats étant rapides à analyser et à intégrer dans le processus de
conception, ce dernier peut changer d’orientation à l’issue d’un seul test. Cependant des objectifs à long
terme (plusieurs sprints) sont également établis quand cela est nécessaire et à moins qu’un résultat ne
les remette en cause, maintenus jusqu'à validation du prototype par l’équipe.
sprint
1
sprint
2
sprint
3
sprint
4
sprint
5
sprint
6
sprint
7
sprint
8
sprint
9
Figure 1 : le stage d’un point de vue sprint
L’utilisation de cette méthode de développement n’a pas été choisie par hasard, elle est le fruit de
l’expérience de T.C. Nicholas Graham. Il a choisi cette méthode car il a observé son efficacité pour
développer des prototypes de jeux vidéo : le chercheur peut ainsi tester petit à petit des incréments de
son prototype afin de reconsidérer, le cas échéant, une partie du prototype qui ne serait pas réalisable.
Comme expliqué précédemment, il est aisé d’intégrer dans le processus de conception, des tests
régulièrement. L’ajout de tests utilisateurs et de réunions avec les utilisateurs ne pose donc pas de
problème.
Remarque : pour la figure 1, il est intéressant de noter que chaque illustration a été choisie afin de
représenter la dominante du sprint en court. Cependant une image ne permettant pas comprendre
réellement de quoi le sprint a été fait, vous trouverez dans l’annexe 9 plus de détails sur chacun des
sprints.
19
On peut d’ailleurs représenter cet enchainement de sprint (Figure 1) sous cette forme (Figure 2).
Figure 2 : processus de conception en spirale
On retrouve dans ce schéma la notion de sprint couplée au processus qui est enseigné dans notre
master IHM.
Rappel des spécificités de notre méthode AGILE :




sprint de deux semaines ;
réunion de suivi toutes les semaines (les jeudis) ;
les orientations décidées durant la réunion sont postées sur un Wiki ;
mise à profit des utilisateurs : lors de phase de générations d’idées (Brainstorming),
durant des tests utilisateurs, mais aussi pendant les réunions de suivi de projet.
20
2. GESTION DES RISQUES
Probabilité
Impact
Difficultés d’accès aux
utilisateurs
Faible
Critique
Blocage du
développement
Moyenne
Important
Blocage lors de
l’intégration
Forte
Critique
Rejet du prototype final
Moyenne
Critique
Prévention
Définir les utilisateurs
potentiels du prototype au plus
vite afin de planifier des tests
au plus tôt
Avancer la phase
d’apprentissage au tout début
du projet pour maximiser
l’expérience de technologies
utilisées
Utiliser un développement
itératif qui permet de
minimiser ce genre de
problème
Inclure des utilisateurs
potentiels dès les premières
réunions de projet. Tester le
prototype régulièrement avec
eux
3. LIVRABLES
A l’issue du stage, il faudra en anglais :




rendre l’intégralité du code source du prototype ;
avoir posté, sur le wiki du laboratoire, des indications afin d’aider au suivi du prototype; (Annexe
6)
mettre à jour le site du laboratoire avec un texte explicatif du projet ; (Annexe 7)
ajouter à ce texte une vidéo du projet d’environ trois minutes. (Annexe 7)
21
4. LES PARTIES PRENANTES DU PROJET
Figure 3 : les parties prenantes
Cette figure (3) présente tous les gens qui ont contribué directement au projet. T.C. Nicholas Graham,
encadrant du stage porte également la casquette de client et d’expert du projet. Il est accompagné par
Tadeusz B. Stach, qui fait une thèse sur l’exergaming, expert pour le projet, mais aussi utilisateur
« développeur ». Cette équipe d’experts sera présente à toutes les réunions de projet, tout comme
l’équipe de projet constituée par Eril Berkok, étudiant en 3eme année à Queen’s University ainsi que
moi-même, étudiant en Interaction Homme Machine. Enfin le dernier acteur du projet, plus à l’écart car
il n’est pas présent dans le laboratoire, est Chris Oliver qui travaillera en tant que graphiste pour le
projet. Il sera en charge de dessiner les textures que l’on retrouvera dans la version finale de BBWoE. Je
travaillerai les deux premiers mois sur le projet, en me concentrant sur le « Front End », Eril arrivera
dans un second temps et améliorera le « Back End ».
22
ANALYSE
1. ANALYSE DE L’EXISTANT : LIFE IS A VILLAGE
Life Is A Village (LiaV) est un exergame développé par l’EQUIS laboratory en 2002. Il se base sur
le moteur open-source OGRE. Même s’il a été développé pour être utilisé en tant que tel, il a servi de
base pour quasiment tous les projets d’exergame qui ont suivi.
A) GAMEPLAY
Au démarrage du jeu, le joueur se retrouve dans la peau d’un avatar robotisé. Le joueur peut utiliser ses
jambes pour faire avancer l’avatar. Afin de compléter le vélo, le joueur tient un pad dans la main qui lui
permet d’effectuer différentes actions (voir annexes 8). En se déplaçant, l’avatar explore un vaste
paysage, ainsi il trouve un emplacement approprié pour fonder un nouveau village. Une fois cette
première étape achevée, le but de l’exploration s’oriente vers la recherche de ressources (comme du
bois près des forêts ou de la pierre près des rochers). Apres avoir développé le village, le joueur a accès
à des bâtiments plus avancés et à des décorations pour embellir le village et ainsi l’encourager à
continuer. Le jeu supporte un système de sauvegarde et de reprise pour éviter de perdre la progression.
B) LA PLATEFORME DE DEVELOPPEMENT
LiaV a tellement été réutilisé depuis, qu’il a
été impossible de retrouver le code source
de la première version. Cependant des
projets encore récents du laboratoire
utilisent des versions améliorées de LiaV.
C’est pourquoi les réunions de projet et les
discussions avec les collègues ont été
l’occasion d’en apprendre plus sur ce que
pensent les utilisateurs de ce jeu.
Même si l’utilisation d’un vélo pour faire
marcher un avatar pourrait paraitre bizarre
au premier abord, le parallèle marcherait
plutôt bien. De plus comme on le voit sur la
figure 4, la 3D procure un effet d’immersion
non négligeable sur l’expérience de jeu.
Figure 4 : LiaV
Afin de récompenser le joueur à la fois pour des actions assez simples, mais également pour des actions
sur le plus long terme, le gameplay comprend un mélange d’objectifs à court et long terme. Le fait
d’aller chercher des ressources pour les stocker dans son village est un objectif à court terme puis avoir
assez de ressources pour construire un nouveau bâtiment est un objectif à long terme.
23
En ce qui concerne les différents périphériques d’entrés, le jeu en supporte un grand nombre. Le joueur
peut utiliser une manette de jeu, un clavier, une souris, un joystick et un Tunturi bike. Cependant le
temps d’apprentissage pour LiaV ne doit pas être négligeable à en juger par le nombre d’actions
possibles ou l’existence de deux modes : le mode de jeu normal et le mode de construction.
Même si l’accès au jeu n’a pas été possible, j’ai pu discuter avec une partie des concepteurs des projets
qui se basent sur LiaV. Ils ont tous salué l’architecture de ce projet, modulaire, qui permet une
compréhension du code rapide. D’ailleurs c’est probablement pour cette raison que l’on retrouve LiaV à
la base d’autant de projet, y compris non exergame.
Les projets exergames qui en découlent : Frozen Treasure Hunter, Hearth Burn, les améliorations de
LIAV …
Remarque : on retrouve dans la partie suivante de nombreux résultats qui sont issus des travaux de
recherches portant sur LiaV.
2. ETAT DE L’ART
Cette partie a été écrite grâce aux travaux de
recherche de Tadeusz B. Stach. Cet étudiant, qui fait une thèse
sur les exergames, a suivi et aidé à l’accomplissement de ce
projet. Tous les travaux de conceptions de ce projet sont basés
de près ou de loin sur ses recherches disponibles sous la
Référence 32.
A) L’EXERGAME MULTI-JOUEURS
L’obésité des 25 – 34 ans est passée de 1979 à 2004 de 8,5% à
20,5% [Ref 1]. Des études ont montré que cette augmentation
est partiellement due à la sédentarisation de nos modes de vie
Figure 5 : Nintendo Wii Fit
[Ref 2]. D’autres études ont également montré un lien entre l’obésité des
adolescents et nos medias actuels comme les jeux vidéo [Ref 3]. Les jeux
vidéo, qui sont de plus en plus présents dans nos sociétés, sont une
forme de divertissement interactif qui propose de plus en plus de
périphériques d’entrées conçues pour se dépenser physiquement.
Nintendo Wii fit (Figure 5), le Playstation Move (Figure 7) ou encore
Microsoft Kinect (Figure 6) sont autant de solutions matérielles
proposées par les constructeurs aux exergames.
Les exergames multi-joueurs sont
des jeux qui permettent de jouer à
deux joueurs ou plus, tout en
pratiquant une activité physique.
Figure 7 : Sony Playstation Move
Figure 6 : Microsoft Kinect
24
Des recherches en psychologie des sports ont montré qu’être en groupe augmente la motivation et
améliore les résultats [Ref 4, 5, 6]. Yim et Graham ont montré [Ref 7], à l’aide de LiaV, que les jeux multijoueurs pouvaient intégrer les bénéfices de l’exergame en groupe. Cet état de l’art s’attachera à
montrer des solutions pour concevoir un exergame multi-joueurs.
DES FACTEURS QUI INFLUENCES LA MOTIVATION
Musique :
Il a été montré [Ref 8] que la musique apporte plus à un exercice physique que la présence d’un
instructeur ou à son identification avec un tiers (présence de son propre avatar à l’écran par exemple).
Des expériences [Ref 9] ont montré trois principaux axes. Premièrement, de l’exercice combiné à de la
musique améliore l’intensité de celui-ci [Ref 10, 11, 12]. Deuxièmement, la perception de la douleur, lors
d’un exercice, baisse avec la présence de musique [Ref 12, 13, 14]. Enfin, la musique influence le joueur
afin de le pousser à de plus hauts niveaux d’intensité dans l’exercice *Ref 11, 13, 14].
Coach :
Des travaux ont montré l’importance d’un coach lors d’exercice physique, notamment comme facteur
bénéfique pour la motivation et l’appréciation de celui-ci [Ref 15]. Westcott [Ref 16] définit certaines
caractéristiques importantes : la connaissance de remise en forme, l'enseignement de compétences,
l'enthousiasme et une attention personnelle. Brehm [Ref 17] suggère que les qualifications de
l'instructeur, le professionnalisme, l'expérience et une attention personnelle sont des facteurs clés dans
l'adhésion de l’effort physique.
Le jeu à plusieurs :
Jouer en groupe peut avoir une influence positive sur la motivation et l’adhérence à l’effort physique
[Ref 4, 18, 19]. L’encouragement de la famille ou même des gens avec qui on joue, sont autant de
facteurs motivants pour le joueur [Ref 18]. Beaucoup d’exergames essayent de tirer parti des bénéfices
apportés par le jeu en groupe en supportant le jeu à deux ou plus.
Interaction de joueur à joueur :
Les interactions entre personnes en sport peuvent se passer de plusieurs façons. Dans les jeux d’équipe,
les co-équipiers coopèrent pour vaincre d’autres joueurs. La compétition implique un concours entre les
participants et il a été montré qu’elle présente un facteur de motivation supplémentaire [Ref 20]. Cette
coopération n’a pas besoin d’impliquer énormément de joueurs pour jouer un rôle bénéfique car il a été
montré que deux personnes peuvent suffirent [Ref 4 et 21].
COMMENT CONCEVOIR UN EXERGAME MULTI-JOUEURS ?
25
Un exergame multi-joueurs a besoin de faciliter le regroupement des joueurs afin de bénéficier de la
motivation positive apportée par la cohésion. Dans leurs exigences de conception, Yim et Graham [Ref
4] utilisent trois approches de soutien au regroupement :



cacher les niveaux de condition physique des joueurs ;
réduire les obstacles au regroupement ;
aider activement la formation de groupe.
Les exergames distribués permettent de cacher l’apparence d’un joueur derrière son avatar virtuel et
évitent donc les problèmes d’estime de soi [Ref 22 et 23]. Permettre aux amis de jouer ensemble peut
avoir un impact positif sur la cohésion de groupe. Toutefois, de nombreux jeux vidéo ont plusieurs
serveurs ce qui divisent donc les joueurs. Cette pratique doit être évitée dans un exergame, quand cela
est possible [Ref 4]. Les mécanismes d’équilibrages automatiques peuvent permettre à des joueurs qui
seraient normalement séparés par leur écart de niveaux, de jouer ensemble. Une approche possible en
faveur de la formation de groupe serait d’inclure des taches collaboratives dans le jeu. Par exemple, on
retrouve des exergames dont la victoire dépend de la coopération entre les joueurs [Ref 24, 25, 26, 27].
La communication et la coordination nécessaires entre les acteurs peuvent avoir une influence positive
sur la cohésion du groupe, il faut donc proposer aux joueurs un système adéquat.
SYNCHRONE VS ASYNCHRONE
Figure 9 : Nautilus
Figure 8 : Breakout for two
On peut parler de jeux multi-joueurs synchrones lorsque les joueurs évoluent dans un univers en
simultané. Cette configuration est la plus utilisée dans les jeux multi-joueurs actuels, mais aussi dans les
exergames. On la retrouve dans de nombreux projets, comme Breakout for Two (Figure 8) [Ref 28] ou
Nautilus (Figure 9) [Ref 29]. Ce dernier est un exergame où les joueurs doivent coopérer devant un
même écran (co-localisé) afin de jouer. Les exergames existants ont démontré qu’ils peuvent s’adapter
aussi bien à des gameplay compétitifs que coopératifs, en réseau ou co-localisés.
26
Au contraire, les jeux asynchrones ne se déroulent pas dans un même univers, ou alors pas en même
temps. Par exemple Triple-Beat [Ref 30] propose un affrontement entre différents coureurs, mais la
course n’a pas besoin de se dérouler en même temps. Le jeu affiche en temps réel si la performance
courante du joueur est en dessous ou au dessus de ces concurrents. Triple-Beat est actuellement le seul
exergame asynchrone, les jeux coopératifs ou co-localisés asynchrones n’ont pas été réellement
expérimentés. Nous ne connaissons donc pas bien les conséquences que pourraient avoir un exergame
asynchrone collaboratif sur la motivation de ces participants.
QUALITE ET EFFICACITE D’UN EXERCICE PHYSIQUE
Le but d’un exergame n’est pas seulement d’amuser, il faut aussi que le jeu implique le joueur dans une
activité physique importante, suffisamment importante pour entretenir voir améliorer sa santé. D’après
l’American College of Sports Medicine (ACSM), qui est le plus gros complexe médical pour le sport au
monde, il faut que l’exercice remplisse un certain nombre de critères [Ref 31] :




fréquence : trois à cinq jours par semaine d’activité sportive ;
intensité : 65% à 90% du rythme cardiaque maximum ou 50% à 80% de la consommation
maximum d’oxygène ;
durée : 20 à 60 minutes d’activité continue ou non (la durée dépend de l’intensité de celle-ci) ;
type : toute activité qui implique un maximum de muscles du corps en les sollicitant
continuellement.
Beaucoup d’exergame commercialisés aujourd’hui sont plus conçus pour proposer une nouvelle forme
d’interaction plutôt qu’un réel exercice physique (ex : Wii, EyeToy …). Les exergames utilisant des
périphériques comparables aux vrais appareils d’entrainement (ex : GameBike) ont globalement de
meilleurs résultats pour la santé. On remarque également un manque de documentation concernant la
conception d’exergame, il n’existe pas de guidelines pour améliorer les futurs exergames par exemple.
BILAN
Malgré les mauvaises performances sur le plan de la santé qu’offrent les exergames actuels, on
remarque que tous les constructeurs de console s’y intéressent, le dernier en date étant Microsoft avec
le Kinect. Ce n’est que très récemment que les recherches ont démarré autour des aspects multi-joueurs
dans l’exergaming et ses conséquences sur la motivation et le temps de jeu du joueur. La création d’un
prototype multi-joueurs permettra donc probablement d’aider à l’exploration de ce nouveau champ.
B) LES JEUX DE PLATEFORMES
27
Ce type de jeu fonctionne souvent avec un écran coulissant qui suit l’avatar. La plupart du temps, le
joueur se déplace dans un environnement hostile plein d’ennemis. Il peut les éviter ou les tuer.
Les premiers :
Figure 10 : Space Panic (1980)
Figure 11 : Super Mario Bros (1985)
Le premier jeu de plateforme est probablement
Space Panic (Figure 10), le joueur pouvait uniquement déplacer son avatar dans les quatre directions,
sans fonction de saut.
Mais durant cette décennie, le jeu de plateforme qui se vend le plus est Super Mario Bros. Son gameplay
novateur allié à une console plus abordable (NES/famicom) et plus vendue y sont pour beaucoup (Figure
11).
Sonic the hedgehog est probablement un des premiers jeux de
plateforme qui propose un gameplay aussi rapide. C’est le
Figure 12 : Sonic qui court
Figure 13 : Sonic en boule
premier succès qui propose des niveaux pensés pour un avatar
qui est capable de courir (Figure 12) et de rouler en même
temps (Figure 13). Le hérisson peut en effet se mettre en boule
pour rouler lors d’une descente par exemple.
« Nouvelle génération » :
Donkey Kong Country (DKC) sur SuperNes est le jeu le plus
vendu sur cette plateforme avec 8 millions de copies [Ref 33]. Il
est aussi un succès technique, car malgré que tout le jeu soit en
2D, à l’aide d’images pré-calculées, le joueur à un effet de 3D
notamment sur son avatar. La plupart des jeux de plateforme
qui sont sortis après DKC sont soit de vrais jeux nouvelle
génération (avec de plus en plus de 3D), soit des jeux de la vieille école, comme X-moto.
28
Deux succès originaux :
X-moto (2005) est le clone open source d’un jeu de
plateforme : Elastomania (2000). Comme ce dernier,
jouer à X-moto consiste à passer des niveaux. Pour
passer au suivant, le joueur doit contrôler un avatar
sur une moto afin de récolter toute les pommes, puis
la fleur qui symbolise la ligne d’arrivée. On retrouve
dans ces deux jeux un moteur physique qui permet un
gameplay assez original. On note cependant une
différence, X-moto est plus réaliste, plus abouti avec des objets
complexes dans des niveaux (comme des ascenseurs).
Comme on peut le voir sur la figure 14, l’interface est assez
sommaire. On retrouve en haut à gauche, le chronomètre, le
meilleur temps et le nombre de pommes collectées. Dans l’angle
opposé, on aperçoit la mini-carte. Tout le jeu ce joue au clavier :
barre d’espace pour changer de direction, flèche haute pour
accélérer, bas pour freiner et enfin les deux directions pour
s’équilibrer (une rotation vers la gauche ou vers la droite).
Figure 14 : X-moto
Super Paper Mario (2007) est original car il est le premier jeu de
plateforme à combiner gameplay 2D et 3D à n’importe quel instant
de la partie. En début de partie le joueur démarre avec deux
dimensions. En avançant il accède à la capacité de se déplacer et
de voir dans la troisième dimension pendant une courte période de
temps. Cette dimension lui permet ainsi de passer des obstacles,
de voir des objets cachés, etc. La figure 15 donne un aperçu de la
différence entre ces 2 vues.
BILAN
Figure 15 : Super Paper Mario
Cette présentation permet d’introduire de ce qui est devenue la
référence des jeux de plateforme. Elle a aussi été l’occasion de
présenter un jeu comme X-moto, qui comme BBWoE est constitué d’un avatar qui évolue dans un
monde avec des entités, régis par les lois de la physique.
Remarque : vous trouverez en annexe un état de l’art portant sur les mondes persistants synchrone et
asynchrone. Ce travail aurait pu servir si nous avions eu plus de temps, notamment pour choisir des
orientations de la partie multi-joueurs. Finalement son contenu n’influence pas suffisamment la
conception pour l’intégrer dans ce présent document. Cependant il pourrait être réutilisé lors d’une
évolution possible de BBWoE.
29
3. TECHNOLOGIE
A) HARDWARE
Le prototype est conçu pour fonctionner sur un
Select
ordinateur
récent disposant
d’un
système
d’exploitation Windows XP minimum. Durant
son développement il a été testé
Stick gauche
régulièrement sur un Intel Core i5 720
disposant de 4 Go de ram et d’un système
d’exploitation Windows 7 32 bits édition
professionnelle.
La partie Input du jeu est confiée à
l’association d’un pad de Xbox 360…
Start
Y
X
B
A
Pad
directionnel
Stick droit
Gâchette
gauche: LT
Gâchette
droite: RT
LB
RB
Figure 16 : manette de Xbox 360
… mais aussi à un pédalier électronique (PCGamerBike) qui permet
d’effectuer un effort physique et de récupérer des valeurs de vitesse de
rotation.
Figure 17 : PCGamerBike
30
B) SOFTWARE
.Net : (prononcer « dot net »)
Ce framework (Figure 18) développé par Microsoft, sous Windows
uniquement, inclut une grande variété de librairies. Comme le java, il
précompile le code écrit en un code intermédiaire (Common Intermediate
Langage) avant de le faire exécuter par une machine virtuelle qui produira le
code d’exécution à proprement parler (Common Langage Runtime).
Figure 18
C# :
Ce langage développé par Microsoft se veut à la fois une amélioration du C++ et une alternative à Java.
On retrouve ce langage dans le framework .Net. A l’inverse de ce framework, le C# est libre. Il existe
d’ailleurs des compilateurs libres multiplateformes comme dotGNU.
XNA pour .Net :
Cet ensemble d’outils (Figure 19) assiste le développement de jeux vidéo. Il
se présente comme une extension des librairies de .NET, il est massivement
utilisé par l’EQUIS laboratory pour prototyper des jeux vidéo.
Figure 19
Farseer Physics Engine :
Ce moteur physique (Figure 20) open source a été développé à destination
de l’environnement .NET. Il permet d’intégrer un moteur physique dans un
projet XNA à moindre coût : il suffit de définir les règles à appliquer (vitesse
du vent, masse de chaque objet, leurs propriétés de surfaces …) et le moteur
gère le reste.
Figure 20
GAIM :
Ce framework développé par l’EQUIS laboratory sert d’interface entre la capture d’actions ou
mouvements du monde réel : mouvement d’un vélo électronique, d’une Wiimote, d’un capteur
cardiaque ... et la restitution de celles-ci pour le développeur.
Janus :
Ce framework développé par l’EQUIS laboratory permet d’aider à l’implémentation d’une couche réseau
dans des applications C#. Il fournit également des fonctions d’interpolation qui optimisent le
positionnement d’objets en cas de mauvaise qualité du réseau.
31
4. BILAN DE L’ANALYSE
Cette analyse permet de donner une idée du travail qui va initier la phase de conception :
l’objectif premier sera de concevoir un jeu de plateforme minimaliste, pour ensuite incrémentalement y
ajouter, en accord avec les utilisateurs, les composants centraux d’un exergame « réussi ». Par exemple
l’ajout d’un coach virtuel prendrait trop de temps par rapport à ce que cela apporterait (déjà testé et
publié). Alors qu’intégrer une partie réseau au projet permettrait d’étudier les conséquences des
interactions collaboratives entre les joueurs et leurs conséquences sur la motivation, mais aussi d’autres
aspects sociaux liés à l’exergame. La partie exergame de cet état de l’art a permis de se rendre compte
qu’il fallait maximiser la motivation du joueur afin de le garder suffisamment sur le jeu, à un niveau
d’exercice suffisant pour sa santé.
La partie portant sur les jeux de plateforme a permis de redécouvrir un panel de jeux de plateforme aux
gameplay parfois éloignés. X-moto, avec son moteur physique et la présence d’entités, est d’ailleurs le
plus proche du sujet de stage.
32
CONCEPTION
1. INTRODUCTION
Conformément à la demande du client, le prototype devra être constitué de deux grandes
parties : d’un côté, le monde virtuel et de l’autre, l’avatar qui interagit avec ce monde. Je présenterai
dans un premier temps le processus qui a conduit à la création de ce monde virtuel, puis dans un second
temps on se concentrera sur l’avatar et ses possibilités d’interactions. Pour chacune des deux parties, je
reviendrai sur le tout début du projet pour expliquer les choix qui ont orienté son évolution vers ce qu’il
est aujourd’hui. Enfin, une dernière partie reviendra sur l’ensemble du projet pour expliquer les
objectifs et les raisons de leurs évolutions.
2. LE MONDE VIRTUEL
Le premier « monde virtuel » utilisé dans BBWoE remonte à la phase d’apprentissage. Il n’était
alors qu’une simple suite de rectangles à l’écran, rapidement implémentables car le rectangle est
l’élément de base de XNA et de pharseer physics. Une des demandes initiales du client a été de pouvoir
ajouter « facilement » de nouveaux objets à ce monde. Poussée par l’architecture de XNA, la décision de
supporter un type d’objet par classe c’est donc fait toute seule car elle permet un support souple :
chaque objet est séparé du reste, tout en gardant une structure commune d’un objet à l’autre. La
complexité de chaque entité est ainsi isolée de la complexité globale du programme. Assez rapidement,
la liste de création, d’initialisation puis d’ajout dans le moteur physique a gagné en longueur et donc en
complexité. On a donc décidé d’ajouter le chargement du monde virtuel depuis un fichier. J’ai décidé
d’utiliser un format XML pour permettre de standardiser suffisamment la définition du monde. Cette
décision a été portée par une demande optionnelle du client : être assez souple pour pouvoir supporter
« facilement » l’ajout d’un éditeur de niveau externe.
33
Figure 22 : BBWoE à ses débuts
Après avoir décidé des valeurs de friction et de rebond des toutes premières entités avec des tests
utilisateurs, il a été nécessaire de créer de nouvelles entités, de plus en plus complexes, afin de pouvoir
construire un monde plus élaboré, plus proche de ce qu’on retrouve
dans les jeux vidéo actuels. Après des entités carrées (« Box » &
« Ground »), une entité « Circle » semblait indispensable : elle
permettrait de créer des grandes roues ou simplement des ballons
(Figure 21). Toutes les entités créées étant particulièrement figées,
Figure 21 : "FloatingPlatform"
en accord avec les utilisateurs développeurs, nous avons décidé
d’ajouter une entité plus complexe : un tapis roulant permettrait
de rendre le déplacement du joueur plus difficile et donc augmenter l’effort physique nécessaire pour
traverser une zone (Figure 21).
A la suite de cet ajout dans le monde virtuel, un cap de complexité a été franchi : les objets que
l’on ajoutera seront difficilement plus complexes du point de vue du moteur physique. Le choix
des objets à ajouter au jeu a continué de se faire lors de réunions avec les utilisateurs. Nous
avons choisi des objets aussi divers qu’une rampe de saut (Figure 23), un ascenseur,
une plateforme volante (Figure 22), un trampoline ou un objet de décor
générique. Certains choix comme le trampoline ou les éléments de décor
Figure 23 : "Ramp"
ont été faits dans un simple but d’amélioration des niveaux de
34
démonstrations que nous voulions développer. Au contraire, l’intégration de la rampe au moteur
physique a nécessité la maitrise d’une nouvelle fonction : l’ajout de formes non-géométriques.
L’ascenseur et la plateforme volante ont comme point commun d’être les premières entités à intégrer
une fonction d’utilisation (voir paragraphe « Interaction de l’avatar sur les entités de ce monde
virtuel »). C’est à la suite de l’ajout de ces dernières entités que nous avons décidé de créer un premier
monde virtuel (sprint 3). Le nombre d’entités était suffisant, seules les entités de décors manquaient à
l’appel et ne permettaient donc pas de créer un monde réellement riche.
Ce monde a été amélioré successivement et a été utilisé finalement jusqu'à la fin du projet. La version
initiale a été créée en moins de 4h et écrite directement en XML à partir d’un schéma. L’évolution du
prototype vu comme un jeu mono-joueur s’arrête ici, la nouvelle version décrite dans la section portant
sur le multi-joueurs supporte néanmoins le fonctionnement hors-ligne.
3. L’AVATAR DANS CE MONDE VIRTUEL
A) DURANT LA PHASE D’APPRENTISSAGE
Dès le début du projet, lors de la phase d’apprentissage, l’avatar était une simple roue que l’on
déplaçait de gauche à droite à l’aide des flèches directionnelles du clavier. Il semblait alors important,
dans un but d’apprentissage, de synchroniser les mouvements de cette roue avec les mouvements d’un
vélo (PCGamerBike). Ceci est réalisé en quelques heures en utilisant une API déjà développée
précédemment par l’EQUIS laboratory : GAIM. Afin de compléter cette nouvelle méthode d’interaction,
l’ajout d’un pad semblait indispensable afin de changer de direction avec l’avatar ou simplement sauter.
L’utilisation de l’association pad et PCGamerBike est de toute façon un pré-requis du projet. Le choix des
touches dans un premier temps a été relativement simple, il s’appuie sur les expériences de l’équipe
dans les jeux de Xbox 360 qui utilisent ce même pad.
Cependant un problème s’est alors posé : XNA n’embarque pas de gestion de la caméra en mode 2D.
J’avais pourtant besoin de pouvoir centrer la vue sur la roue. De plus, l’utilisation massive de texture de
haute résolution ralentissait le jeu, il faudrait donc ajouter à la caméra un système qui traite
uniquement ce qui est dans le champ. J’essayais donc de déplacer uniquement les objets du monde et
garder l’avatar statique, cependant cette idée se heurte à l’utilisation du moteur physique et les
problèmes de collisions ne tardent pas à apparaitre. C’est sur le forum de Farseer physics qu’est trouvé
la solution : une classe caméra 2D, qui remplit toutes les conditions et même plus puisqu’elle incorpore
en plus des fonctions de zoom. L’intégration de cette classe s’est faite sans problème.
35
B) LES PREMIERES VERSIONS DU MONOCYCLE ET
DU TANK
Dans un second temps, l’ajout d’un nouvel avatar
semblait inévitable, comme l’évolution du premier ! Le choix
du nouvel avatar a été fait lors par l’ajout de l’entité
« BeltEntity » au jeu. Comme l’illustration 22 (page 34) le
montre, cette entité à une forme de tapis roulant. On
remarque également la proximité
Figure 24 : la chenille et la boule
forte entre l’avatar chenille et cette
entité (Figure 24). La création d’un avatar chenille ne posait donc pas de problème
technique et avait en plus le gros avantage de fluidifier le parcours sur décor accidenté.
De plus, la chenille étant totalement symétrique, elle ne pose pas de problème en cas de
retournement.
En même temps, le premier avatar a évolué en monocycle
(Figure 25). Cette décision, qui a été prise lors d’une réunion
de sprint, est motivée par la proximité entre le
PCGamerBike et un monocycle. Afin d’éviter tout
problème de retournement, il est décidé de contraindre la
selle à rester en permanence vers le haut. Il a
Figure 26 : le monocycle
également été décidé d’améliorer l’avatar chenille.
Figure 25 : le tank
L’avantage de la symétrie pose aussi un problème, l’avatar est jugé trop
impersonnel pour rester en l’état. L’ajout d’une tourelle (Figure 26), afin de
transformer l’avatar chenille en tank, a été effectué, mais celle-ci a fait remonter un problème de
blocage en cas de retournement. Une solution est alors trouvée lors d’une réunion de projet : utiliser
une touche de stabilisation lorsque le tank est en contact avec aucune entité (lors d’un saut ou d’une
chute libre).
Ces deux avatars sont utilisés pour le premier test utilisateurs. Il a des fins multiples :



la principale est d’avoir des retours sur le contrôle à la manette et sur les feedbacks des
mouvements des avatars à l’écran. Par rapport au feedback de l’avatar, l’accent est mis sur les
différentes surfaces (bois, herbe, glace) sur lesquelles l’avatar peut se mouvoir ;
donner des opinions plus générales sur le jeu;
enfin, une première occasion de présenter mon travail aux collègues du laboratoire qui
m’aideront à faire ce test.
Le premier utilisateur a en fait été testé deux fois. En effet, nous n’avons pas eu assez de temps pour
tester les deux avatars. A la suite du premier test, une simple modification des coefficients de
frottement de la glace a permis d’obtenir un bien meilleur ressenti. A l’issue de ces deux séries de tests
avec ce premier utilisateur, il a été nécessaire d’ajuster quelques paramètres du jeu afin d’éviter une
focalisation des prochains utilisateurs sur ceux-ci (problèmes de freinage et de blocage des roues du
36
tank). Les utilisateurs B et C, à l’inverse du premier, ont pédalé rapidement jusqu’au maximum et n’ont
donc ressenti quasiment aucune différence entre les surfaces. Quelques idées originales proposées
durant ce test :
1. pourquoi ne pas utiliser les pédales dans le sens inverse pour freiner au lieu d’un bouton ;
2. permettre la rotation du monocycle rendrait son utilisation plus intéressante.
Lors des tests, les utilisateurs A et C ont mentionné que l’utilisation du monocycle avait un mauvais
feedback comparé au tank. Nous avons remarqué, lors de ce test, que le tank se retourne et se bloque
assez souvent. La fonction ajoutée afin d’effectuer un saut de remise en place rapidement marche mais
reste contraignante à utiliser. En cas de retournement, l’utilisateur doit sauter puis presser la touche de
stabilisation (bouton X). La plupart du temps les utilisateurs testés ne se souvenaient pas de la séquence
de touche ou alors pressaient le bouton X trop peu de temps pour effectuer un retournement complet.
Afin de stabiliser l’avatar dans les airs, l’ajout de rotation, grâce aux gâchettes de la manette, semblait
naturel. Il a cependant été critiqué par une partie de l’équipe le jugeant trop complexe. C’est la raison
pour laquelle nous l’avons testé avec les utilisateurs et comparé au système de stabilisation
automatique. Ces tests sont détaillés dans la partie « Evolution du système de commande ».
A l’issue de ce premier test, le prototype a évolué pour intégrer toutes les remarques sauf le problème
de retournement qui a été traité ultérieurement. L’utilisation du pédalier pour freiner l’avatar (idée une)
est implémentée. Cependant l’ajout de la rotation au monocycle (idée deux) pose un problème de
contrôle. Il faudra juger de son utilisabilité lors d’une nouvelle session de test, mais cet avatar semble
être réservé à un public expérimenté.
C) INTERACTION DE L’AVATAR SUR LES ENTITES DE CE MONDE VIRTUEL
Après une nouvelle phase de sprint, qui a démarré par une réunion pour choisir les nouvelles
orientations du projet, nous décidons d’améliorer l’interaction entre l’avatar et le monde virtuel.
Chaque entité aura une méthode Use(), Enter() et Exit(). Les méthodes Enter() et Exit() ont pour but de
donner un comportement différent lors du passage de l’avatar près d’elle : par exemple l’ouverture
d’une porte quand l’avatar la touche. La méthode Use() permet d’appliquer une force à une entité si le
joueur est en contact avec elle et qu’il presse la touche utilisation. C’est avec cette méthode que
fonctionnent les entités « Elevator » et « FloatingPlatform ».
Cependant durant la phase d’implémentation de ces méthodes, je me heurte à un problème : comment
savoir si on touche réellement une entité et ensuite comment savoir lesquelles sont utilisées lorsque la
touche « utiliser » est pressée. Sur le moment j’ai décidé simplement de colorer les entités touchées en
rouge et celles utilisées en vert. Ce système a en fait été conservé car il est une solution très
performante à un problème de feedback important pour l’utilisateur, surtout sur des entités dont il est
difficile de percevoir rapidement qu’on effectue une action dessus. La couleur de contact conservée
n’est quasiment pas visible de telle sorte qu’elle ne gène en rien l’utilisateur et en ce qui concerne
l’utilisation, j’ai conservé la couleur verte. Il est cependant important de noter que le choix de ces
37
couleurs est trop important pour ne pas être soumis à l’avis des utilisateurs. Il faudra donc le prendre en
compte quand BBWoE sera réutilisé pour créer un jeu.
Dans un second temps, ces méthodes ont permis de développer un système de ligne de départ et
d’arrivée. Franchir la ligne de départ déclenche le compteur et seul la ligne d’arrivée peut l’arrêter. Cette
illustration du fonctionnement possible d’un chronomètre a ensuite été réutilisée lors de la conception
du système de succès qui est présentée dans cette partie.
Fonctionnement de l’ascenseur (Figure 27) : par défaut il est en bas. S’il n’est pas en bas et qu’il n’est
pas utilisé, il retourne graduellement en position basse. Tant que la méthode Use() est appelée,
l’ascenseur remonte graduellement jusqu'à sa position maximale.
Figure 27 : l'ascenseur en fonctionnement
EVOLUTION DU SYSTEME DE COMMANDE
Depuis le début du projet, le système de commande utilisé marche plutôt bien, cependant il a été créé
en se basant sur des expériences de deux personnes de l’équipe. Une session de brainstorming a donc
été organisée afin d’effectuer des choix et, dans le cas échéant, de proposer des idées pour revoir le
système de commande (Figure 28).
38
Use Brake
Jump
Gauche/Droite
La consigne du stage est d’ « utiliser un
PCGamerBike couplé à un pad afin de contrôler un avatar ».
Tout ce qui a été décidé ensuite peut donc être remis en
question par les participants. Avant de démarrer, cette
consigne
est
rappelée
aux
participants de la réunion.
Zoom
avant/arrière
Les idées proposées dès le début vont
dans ce sens :
1. pourquoi ne pas utiliser le
Rotation
vélo pour stabiliser l’avatar
gauche
dans les airs et pas pour le
déplacer ? Ou pourquoi ne pas
utiliser le vélo pour les deux fonctions ?
2. pourquoi ne pas utiliser les touches RB et LB
pour zoomer plutôt que les touches du pad
directionnelles avant et arrière ?
3. pourquoi ne pas utiliser une simple touche pour le
changement de direction plutôt qu’un stick ?
Rotation
droite
Figure 28 : commande à revoir
Au final, l’ensemble de ces idées tente de trouver des
alternatives à ce qui existe déjà. Cependant tous les participants de la réunion s’accordent à dire qu’une
majorité des attributions déjà faites sont efficaces. Seule une fonction posait réellement problème à leur
sens : l’emploi du bouton utiliser.
Comme dit précédemment, le bouton X permet de déclencher une action au contact d’une entité. Dans
les airs et donc en contact avec aucune entité, une pression sur le bouton utiliser déclenche une
stabilisation automatique de l’avatar jusqu'à un relâchement de celui-ci. Hors un système de
stabilisation manuel existait déjà et les participants à cette réunion (qui ont testé le prototype)
pensaient qu’il était largement suffisant et même plus adapté. Suite à ces avis, ce système de
stabilisation automatique a totalement été supprimé. Cependant une bonne partie des idées citées
précédemment ne pouvait pas être appliqués :

l’idée 1 ne peut être utilisée : au vu du gameplay déjà utilisé dans le prototype, l’utilisateur ne
dépenserait pas assez d’énergie en se servant du vélo pour stabiliser un avatar uniquement dans
les airs. Cette action est en plus moins naturelle, surtout avec l’utilisation du monocycle. Une
alternative aurait été d’utiliser le vélo pour stabiliser l’avatar dans les airs en complément de
son utilisation au sol. Cependant cette idée pose un problème de conflit évident : l’utilisateur
devrait s’arrêter de pédaler dès que l’avatar décolle du sol afin d’éviter tout retournement et
inversement une fois que l’avatar retouche le sol. De plus, le PCGamerBike à une certaine inertie
qui n’aurait pas améliorée pas la situation ;
39


l’idée 2 a été testée, elle a posé deux problèmes : l’utilisation du pad Haut/Bas est plus intuitive
pour effectuer un zoom arrière ou avant que l’utilisation des boutons à droite et à gauche de la
manette. Un autre problème a été soulevé par l’utilisation des gâchettes LT/RT pour la rotation
de l’avatar : elles sont très proches de ces boutons et leur utilisation entrainerait probablement
des inversions fréquentes ;
l’idée 3 a été proposée lors des premières réunions de sprint. Le but alors était de proposer un
système de commande le plus rapide de prise en main possible. Il se trouve que déplacer le pad,
situé à gauche de la manette, à droite ou à gauche est une des premières actions que l’on a
observé et ce, dès les premiers tests utilisateurs.
D) UN TROISIEME AVATAR ET UNE AMELIORATION DES PRECEDENTS
Avant même cette période de test, il a été proposé lors d’une réunion de fin de sprint l’ajout
d’un troisième avatar : une « New Beetle » (Figure 29). Le choix de ce modèle a été encouragé par sa
forme arrondie qui permettrait d’éviter un blocage de la voiture sur le
dos jugé trop
facile par nos observations lors de ce premier test utilisateur. Il
est
également décidé d’ajouter un feedback lors d’un saut. La
solution retenue est un ajout de fumée lorsque l’avatar
décolle du sol.
C’est à partir de cette « line-up » qu’est amorcé le second
test utilisateur. Celui-ci ce concentre sur le recueil de
Figure 29 : New Beetle
remarques encore une fois, mais surtout celles relatives à
la jouabilité des avatars. Le but ici était d’effectuer une dernière modification pour obtenir une version
finale de nos trois avatars. Des utilisateurs nommés A, D et E passèrent ce test (seul l’utilisateur A avait
déjà passé le premier test). Voici une liste des points les plus intéressants relevés par ce test :




un utilisateur apprécie le monocycle, surtout pour le challenge offert par son déséquilibre
permanent ;
« le tank est largement plus abouti que les deux autres avatars, en particulier la « New Beetle »
qui a des comportements étranges » (roues qui sautent en permanence, bug de collisions, etc.) ;
la fumée comme feedback de saut marche. Ceci dit, un utilisateur changerait la couleur pour du
gris (pour « plus de réalisme ») ;
« cette version du prototype est définitivement plus fun que la précédente ! »
Plus de la moitié des points abordés lors du test ont été corrigés rapidement. Seul quelques uns,
notamment ceux de la « New Beetle » ont nécessité des changements
plus radicaux. Malgré de multiples tentatives de réglage des
paramètres physiques de la voiture, il a été impossible d’obtenir un
gameplay convenable.
Suite à ce blocage, la structure même de la voiture a été modifiée.
Lors des tests, cet avatar avait tendance à se bloquer ou à être
Figure 30 : New Beetle 2.0
40
ralenti par des objets du décor qui touchaient sa carrosserie régulièrement. L’avant et
l’arrière de l’avatar ont donc été coupés et les roues doublées de taille (Figure 30). Suite à
ces changements, puis à une phase de réglage des suspensions de la voiture, nous avons
fait valider ces améliorations, au travers d’un test utilisateur, afin de s’assurer que tout
le monde ressente la différence.
E) NOUVEAU DESIGN GRAPHIQUE
Depuis le début du projet, j’ai utilisé des textures trouvées sur internet, qui
n’étaient pas forcement très adaptées. A partir du sixième sprint, Chris Oliver, un
graphiste, a collaboré avec l’équipe de projet afin de designer de nouvelles textures
pour le projet. Il a commencé par proposer de nouveaux modèles d’avatars, qui après un
vote dans le laboratoire, ont permis de donner une nouvelle dimension au projet. Je ne
listerai pas tout ce qu’il a produit pour BBWoE, pour cela se référer à l’annexe 1.
Cependant il est important de présenter les nouvelles versions du
monocycle (Figure 31) et de la « New Beetle » (Figure 32).
Figure 31 : monocycle
Il est intéressant de noter que celle-ci respecte les
final
spécifications de la New Beetle 2.0.
Figure 32 : New Beetle finale
4. PLUSIEURS MONDES VIRTUELS ?
L’intégration d’un mode multi-joueurs dans le prototype a été central. Comme décrit
précédemment dans l’analyse, il est important d’apporter des notions collaboratives afin de motiver
suffisamment le joueur. Ce mode multi-joueurs est aussi l’occasion de créer un serveur qui pourra
héberger un monde aux dimensions quasi-illimitées et ainsi pousser le joueur à l’explorer.
A) PREMIERE VERSION : DECOUVERTE DE JANUS
Cette première version a permis de
découvrir le fonctionnement de JANUS. Elle a servi à
l’apprentissage mais également à la création d’un
serveur écrit en C# qui charge le niveau (en un seul
envoi de message) depuis une Base de Données
(BD), puis l’envoie au client. Cette première version
du serveur ne supporte qu’un seul client en
simultané (Figure 33). On ne peut donc pas encore
vraiment parler de version multi-joueurs.
Figure 33 : configuration réseau 1ere version
JANUS utilise en fait lui aussi des sortes d’entités,
appelées « Stream ». J’ai donc défini « EntityStream » qui permettra de synchroniser les entités du jeu
dans un premier temps. Sur chaque « stream », il est possible d’appeler une méthode send() qui permet
41
d’envoyer les valeurs au serveur, get() pour demander la valeur courante de l’entité au serveur et enfin
sendCommand() qui permet d’envoyer une chaine de caractère directement à un client.
Cependant la réflexion entourant la connexion de plusieurs clients s’est assez vite arrêtée sur un
problème : comment synchroniser plusieurs moteurs physiques ? La première solution proposée a été
de déplacer le moteur physique sur le serveur. Cette solution n’est pas réalisable pour deux raisons,
premièrement nous serions alors limités par le nombre d’objets physiques dans le monde. Enfin, la
bande passante consommée pour le serveur serait énorme, ce qui pose un problème de prix de la
connexion pour le serveur mais aussi pour les clients (au Canada les connexions internet sont souvent
limitée en volume échangé). La seconde solution serait de synchroniser des parties du moteur en
fonction de la position des avatars. C’est finalement cette dernière solution qui a été retenue.
B)
DEUXIEME VERSION : LA PREMIERE VERSION REELLEMENT MULTI-CLIENTS
Cette deuxième version apporte le support du
jeu en multi-joueurs : jusqu'à quatre clients
peuvent se connecter sur le même niveau. Le
niveau est chargé au fur et à mesure du
déplacement de l’avatar dans le monde.
Cependant, comme le serveur envoi chaque
entité à tous les clients, ils chargent des parties
de niveau qu’ils n’ont pas forcement besoin. De
plus, chaque client ne voit pas la position des
autres avatars.
Figure 34 : configuration réseau 2e version
Ce schéma (34) présente le fonctionnement du
réseau d’un point de vue matériel, cette
configuration restera valide jusqu'à la fin du
projet.
L’arrivée de plusieurs clients et le support du chargement en temps réel, en fonction de la position de
chacun des avatars, entrainent forcément une certaine complexité dans le dialogue client/serveur. La
figure 35 présente la structure de « stream » utilisée pour faire dialoguer le client et le serveur dans
cette version. On remarque la présence de cent « EntityStream » chargés d’envoyer les valeurs des
paramètres des entités, ainsi que quatre « GhostStream » chargés de communiquer au serveur la
position des avatars (un « GhostStream » par client).
42
Figure 35 : dialogue client serveur, première version
C)
TROISIEME VERSION : OPTIMISATION
Même si le support de client passe de quatre à dix, cette incrémentation permet d’apporter
surtout une utilisation du réseau plus optimisée. A chaque entité, le serveur attribue un nom unique, ce
nom est communiqué à chaque client qui en a besoin (Figure 36) via un mécanisme expliqué à la page
suivante. Le serveur évite donc d’envoyer une même entité à chaque client un par un. De plus cette
entité est stockée dans une mémoire tampon pour éviter que le serveur la recharge depuis la BD. Le
positionnement de chaque avatar, qui était déjà communiqué au serveur dans la version précédente, est
maintenant renvoyé à chaque client afin qu’il affiche un fantôme des concurrents.
Figure 36 : dialogue client serveur, version finale
43
L’ajout de création de nouvelle entité, à la demande, nécessite d’utiliser le système de message intégré
dans la dernière version de JANUS (sendCommand()). Je filtre chaque message et discrimine l’action en
fonction de l’information d’entête de celui-ci. La conception d’une simple machine à état permet de
représenter ce que nous voulons faire (Figure 37). Le but ici est de s’assurer que le client et le serveur
sont prêts à recevoir les valeurs de la nouvelle entité.
Charger nouvelles entites: “arbre1 et route3”
Serveur
Client
“Reçu”
Reçu
Entité
Reçu
Entité
“Reçu”
Fin
Fin
Figure 37 : vue état/événement du dialogue client/serveur
« » : Message envoyé a travers le réseau avec la fonction sendCommand() de JANUS.
D) QUATRIEME VERSION : AJOUT DE FONCTIONNALITES ET DU SYSTEME DE SUCCES
Le temps passé sur la troisième version a permis de constater une nette amélioration de la
stabilité. Cette quatrième version s’est donc attachée à ajouter des fonctionnalités. Ainsi chaque client
fournit au serveur un nom de joueur à la connexion. Cet identifiant permet d’associer à chaque joueur
un ensemble de succès.
44
Remarque : à l’inverse de l’envoi des positions de l’avatar ou des propriétés d’une entité, les échanges
entre le client et le serveur pour le nom du joueur ou pour déclencher un succès sont ponctuels. Pour
cette raison, ils utilisent le système de message de Janus.
Dans cette itération deux succès ont été implémentés :


« TimeAchievement » qui est en fait une amélioration de l’entité qui servait de départ et
d’arrivée (StartStopEntity). A chaque arrivée, le temps du joueur est envoyé au serveur et s’il
est suffisamment faible, il déclenche un succès qui est ajouté à la BD ;
« RegionAchievement » : une nouvelle entité qui déclenche un succès dès que l’on atteint une
zone. Elle met également à jour la BD pour tenir compte de ce nouveau succès.
Cette version inclut également une nouvelle entité : « HouseEntity ». Cette maison est en fait un
assemblage de briques élémentaires que le joueur collectera dans des implémentations du jeu. Une des
évolutions du projet sera probablement d’implémenter un jeu de construction de sa propre maison dans
BBWoE. Et ainsi proposer un système de collecte de briques dans le jeu (objectifs à court terme) pour
ensuite construire sa maison lors d’un mini-jeu (objectif à long terme).
Synthèse des problèmes soulevés par le multi-joueurs :



problème de latence entre les clients. Solution apportée par JANUS ;
problème de synchronisation des moteurs physiques. Complexe à mettre en place et même
impossible avec la bande passante requise (ligne internet supérieure à une ligne ADSL pour
chaque client) ;
monde quasiment infini, mais qui peut être exploité en utilisant un minimum de bande
passante. Solution partielle avec l’utilisation du modèle client/serveur. (Simple de mise en
place, d’exploitation).
Ce dernier sprint a permis d’intégrer également un système de succès, nous avons donc pour cela créé
une nouvelle entité : « regionAchievement ». Elle permet de déclencher un succès lors du passage du
joueur sur celle-ci. Chaque succès est associé au nom du joueur dans la base de données. De plus, la
base de données étant sous MySQL, nous l’avons interfacé avec un serveur web et écrit une page PHP
qui permet de suivre les scores de chaque joueur. Ce module permettra de reprendre BBWoE et de
travailler sur les aspects sociaux du jeu.
5. DE L’ANALYSE A LA CO NCEPTION : EVOLUTION DES OBJECTIFS DANS LE PROJET
Cette partie permet de décrire l’évolution des objectifs pendant le projet. Son positionnement
dans la partie conception se justifie dans la mesure où le raffinement des objectifs a été fait au fur et à
mesure de la conception du prototype.
Le but initial du stage a été de produire un prototype d’exergame. La phase d’analyse a permis de se
rendre compte de l’importance de la motivation dans la conception d’un exergame. Tous les choix de
45
conception du jeu ont donc directement ou indirectement maximisés cette motivation afin que
l’exergame lui-même soit positif pour la santé de l’utilisateur.
Après la phase d’analyse de l’activité, l’objectif a donc été de produire un premier prototype
d’ « exergame de plateforme ». C’est pour cela que des tests sur l’avatar et le ressenti du joueur par
rapport aux différentes surfaces ont été fait. Mais en parallèle de ces tests, un deuxième objectif plus
global a vu le jour au travers de simples choix d’architecture, la généricité des composants du monde
(entités), leur chargement par un fichier XML. Ces choix sont autant d’objectifs, à courts termes, qui
visent à former une plateforme plutôt qu’un prototype d’exergame. Dans la suite, l’aspect création d’un
exergame est resté au second plan pour se concentrer sur les fonctionnalités de cette plateforme : mise
en réseau, amélioration des entités, amélioration du réseau ...
En fait, les réunions de suivi du projet, très régulières (une par semaines), ont permis de choisir chaque
parties que les utilisateurs « développeur » souhaitaient voir dans BBWoE. Dans chacune des réunions
était présenté l’état courant du prototype. Cette présentation a souvent permis de discuter précisément
d’un feedback ou d’un fonctionnement du programme qui ne convenait pas ou au contraire qui était
intéressant et devait aussi être ajouté ailleurs. Tout ceci nous a permis de produire le prototype tel qu’il
est présenté dans la partie qui suit.
46
ARCHITECTURE LOGICIELLE
Cette partie présente le prototype tel qu’il est à la fin du projet. Elle permet donc d’approfondir
ce qui a déjà été abordé lors de la partie précédente. Dans un premier temps, je présenterais
l’architecture du client. Ensuite, nous verrons l’architecture du serveur. Pour finir, nous parlerons de
l’intégration de Janus utilisé pour les lier. Les deux premières parties se concentreront donc, à l’inverse
de la derniere, sur les aspects non réseau du projet.
1. LE CLIENT
47
Figure 38 : apercu global du client
La figure 38 présente le client dans son ensemble. Pour des raisons évidentes de lecture toutes les
classes correspondantes aux entités ont été factorisées en une classe nommée ici « ObjectNameEntity ».
La description de l’architecture est organisée comme la lecture d’un arbre en profondeur : de haut en
bas puis de gauche à droite.
Remarque : cette architecture a été élaborée après plusieurs itérations (plusieurs sprints). Chaque choix
a été fait après discussion avec les utilisateurs « développeurs » lors de réunions de suivis de projet.
MOTHERCLASS ET BBWOE
48
MotherClass est la classe mère qui a été créée uniquement pour permettre l’ajout ultérieur d’un menu
de sélection de serveur, de personnalisation de son avatar, etc. Pour le moment elle appelle juste la
classe principale du jeu.
BBWoE est la classe principale du jeu. Elle interconnecte les commandes du jeu (classe InputControl), la
gestion de la caméra (classe Camera2D), l’arrière-plan (classe BackgroundTextures) et le moteur
physique (classe CurrentPhysicsProperties) avec le jeu en court (classe currentGame).
A) CURRENTGAME
Probablement la classe la plus complexe du projet, elle gère le chargement et le fonctionnement de
toutes les entités du monde virtuel.
CHARGEMENT LOCAL
Le chargement s’effectue à partir d’un fichier XML, dans un premier temps la classe XMLReader va lire le
fichier XML, pour ensuite initialiser les entités les une après les autres. La classe GameEntity récupère la
liste des entités chargées pour pouvoir les ajouter à la liste des composants XNA. C’est à partir de cette
liste que chaque entité est mise à jour à chaque appel de la méthode CurrentGame.Draw().
CHARGEMENT RESEAU
Dans un souci de performance, j’ai confié cette tâche à un thread supplémentaire. Régulièrement la
classe CurrentGame amorce un thread qui vérifie si de
nouveaux objets ont été envoyés par le serveur. Si c’est le cas
ce nouveau thread crée les nouvelles entités, les initialisent et
les ajoutent à la liste des composants XNA.
PALETTE
La classe palette permet de changer efficacement
un ensemble de texture sans retoucher au
niveau. L’idée serait de proposer au joueur
de personnaliser le
monde virtuel qui
entoure sa maison et
de permettre aux
joueurs qui viendraient
visiter d’avoir les textures
du jeu qui changent en
rentrant dans
la zone.
Cette
Figure 39 : l'architecture des entités
49
fonctionnalité est prévue dans l’architecture et utilisée par une bonne partie des entités. Il manque juste
un système de séparation en zone, qui sera très probablement implémenté lors de la prochaine
itération.
B) GAMEENTITY
Cette classe est une représentation générique des entités qui composent le
monde de BBWoE. Chaque entité hérite donc de ces propriétés, y compris les
avatars. Elle permet de modifier rapidement la réaction de toutes les entités lors
d’un contact avec l’avatar par exemple. La figure 39 (page précédente) permet
de mieux comprendre comment s’articulent chacune de ces classes entres-elles.
Remarque : le nombre d’entités est volontairement faible afin de conserver une
bonne lisibilité du schéma.
6. SERVEUR
Contrairement au client, le serveur n’est pas un projet XNA. Il n’est
donc pas soumis aux mêmes contraintes d’héritage. C’est un projet C# lié à
une base de données MySql et faisant le lien entre ce qu’elle contient et les
différents clients.
A) LE SERVEUR
Comme on le voit sur la figure 40, le serveur a une architecture très simple. Comme
pour le client la partie réseau est mise de côté. La classe « EntityDatabase » n’est
pas réellement une classe dans la mesure où elle représente le tuple entité stocké
dans la base de données. Le reste de l’architecture du serveur
montre une classe principale, « Program », qui contient la méthode
main(). Mais aussi la classe Entity qui permet de stocker les entités
dans une mémoire tampon afin d’éviter trop de requête à la base de
données. L’optimisation consiste à stocker l’entité à chaque requête,
dans un dictionnaire et ainsi éviter de refaire la même requête pour le client suivant. Enfin,
la classe XMLReader permet de charger un fichier XML dans la BD. Cette étape se fait
manuellement, en cas de mise à jour d’un niveau par exemple, et pourra être automatisée
à l’issue de ce stage.
Figure 40 : aperçu du
serveur
50
7. RESEAU
Figure 41 : Janus dans BBWoE
La partie réseau a été réalisée à l’aide de JANUS, une API développée par l’EQUIS laboratory, qui a été
conçue pour simplifier la réalisation et l’intégration de la partie réseau dans un programme. La figure 41
présente la place que prend cette API dans le projet BBWoE. Afin de poursuivre ce qui est expliqué dans
les paragraphes précédents consacrés au client et au serveur, je détaille ici comment s’articulent les
connexions qui existent entre leurs deux classes principales et JANUS. Les classes « EntityStream » et
« GhostStream » permettent de dialoguer en passant par le serveur central de JANUS :
« StreamServer ». Chaque instance de la classe « EntityStream » contient toutes les données nécessaires
à la création d’une entité. Chaque client utilise une instanciation de « GhostStream » afin d’envoyer au
serveur la position de son propre avatar et ainsi permettre à tous les clients d’en afficher une image. Du
fait de l’unicité de cette classe à chaque client, elle me permet également d’envoyer des messages au
serveur ou au client. C’est avec cette méthode qu’est envoyé le nom d’une nouvelle entité à charger par
exemple.
Remarque : même si le schéma 41 ne le met pas en avant, StreamServer est hébergé physiquement sur
le serveur.
Ce chapitre a été l’occasion de décrire l’architecture du côté client/serveur, mais aussi l’architecture qui
leur permet de communiquer. Cependant pour l’approfondir il est recommandé de lire la partie
« Implémentation Design » du wiki disponible dans l’annexe 6.
51
52
EVALUATION
Ce projet, à deux faces, cible deux groupes d’utilisateurs. Depuis le début ils ont été impliqués
durant les différentes phases, au travers des réunions de suivi de projet (utilisateurs développeurs) et au
travers de réunions de brainstorming ou de tests utilisateurs (utilisateurs finaux).
Il semblerait logique, à première vue, de vouloir avoir des retours des deux groupes d’utilisateurs en fin
de projet. Ce serait vrai si nous voulions toujours améliorer la jouabilité du jeu. Hors, au fur et à mesure
du projet, un nouvel objectif est apparu. L’objectif premier a été de créer un exergame. Petit à petit,
celui-ci c’est détourné (autour du 7ème sprint) pour mettre en place une plateforme permettant de
développer rapidement et efficacement un exergame. En fin de projet, après avoir fait valider depuis
plusieurs mois le gameplay des avatars, il n’est plus central de faire intervenir les utilisateurs finaux. Il
aurait cependant été intéressant de tester le prototype avec des utilisateurs développeurs.
En fait, l’intégration d’Eril dans le projet a été aussi l’occasion de voir comment se comporte un
développeur qui prendrait le prototype en main. Ainsi, nous avons constaté qu’il est assez simple pour
un novice de modifier une entité dans le monde ou d’éditer le monde afin de rajouter ou déplacer des
entités déjà existantes. Cependant cette étape a également permis de constater que la création de
nouvelle entité nécessite plus de temps d’apprentissage. Il faut que l’utilisateur crée une nouvelle classe
entité, ajoute dans la parseur XML la création de cette nouvelle entité et ajoute l’initialisation de l’entité
dans la classe « CurrentGame ».
Un test sur plusieurs utilisateurs développeurs potentiels en fin de projet aurait permis de dresser une
liste plus complète, plus précise des défauts de ce prototype et ainsi donner des objectifs clairs à
destination de la prochaine itération. Il aurait cependant nécessité des ressources assez importantes : au
moins cinq développeurs potentiels et plusieurs jours de développement avec chacun d’entre eux. Des
ressources que n’avait pas le laboratoire pendant cette période d’été (campus de Queen’s University
vide).
53
54
BILAN ET PERSPECTIVES
1. BILAN
Comme nous l’avons vu dans la partie évaluation, ce projet s’est déroulé en deux parties. La première
partie a été un succès, les tests utilisateurs qui ont porté sur les avatars et le ressenti des joueurs lors de
leurs utilisations ont permis de constater un réel plaisir de jeu.
Mais l’objectif final va plus loin et ajoute une dimension supplémentaire au projet, le fonctionnement en
réseau d’un prototype générique. Il est difficile en fin de projet et sans test utilisateur de dire si le
prototype remplit ses objectifs de souplesse et réutilisabilité. Cependant sa généricité permet de
prototyper de nouveaux jeux rapidement (en plus des livrables demandés, je fournirai les briques
nécessaires à la création de trois mini-jeux à l’issue de ce stage).
Ces résultats ont été rendus possible par l’utilisation des enseignements du master IHM d’un côté
(brainstorming, test utilisateurs, architecture logicielle, diagramme état/événement …) et d’un autre,
par les enseignements que j’ai eu en master Informatique fondamentale (parseur XML, réseau …). Il a
été aussi l’occasion pour moi de d’approfondir mes connaissances en C#/.Net, mais aussi découvrir XNA
et l’utilisation d’un moteur physique dans une application interactive.
D’ailleurs, l’intégration de toutes ces technologies aurait pu bloquer tout le processus de conception,
mais l’utilisation de sprints très courts a probablement permis d’éviter ce désagrément, cependant en
limitant peut-être le recul qu’on pouvait avoir sur le projet. Finalement, cette cadence aura permis
d’explorer beaucoup de composantes importantes pour l’exergame.
2. PERSPECTIVES
Pendant le déroulement du stage, T.C. Nicholas Graham a été contacté par des médecins qui travaillent
sur la problématique du manque d’activité sportive chez les enfants déficients moteur. L’exergame est
une des solutions envisagée par ces chercheurs afin de résoudre leur manque d’activité physique :
effectivement sous certaines conditions d’utilisabilités, la motivation supplémentaire apportée par le jeu
vidéo pourrait leur permettre de faire plus d’exercice. Ce nouveau champ qui s’ouvrirait à BBWoE,
nécessiterait de poursuivre les travaux, tant au niveau du contrôle de l’avatar qui serait à repenser
complètement, qu’à l’aspect social procuré par le jeu en multi-joueurs.
Le projet est si vaste qu’il pourrait également être scindé en plusieurs parties. Il faudrait en effet
développer un éditeur de niveau qui générerait le code XML que BBWoE utilise pour définir le monde
virtuel (interface WIMP, tactile, autre ?). Dans un second temps, cet éditeur permettrait de réellement
travailler le Game Design du jeu ou de proposer aux joueurs eux-mêmes de designer leur bout
d’environnement.
55
La partie réseau du jeu doit aussi être poursuivie, l’interfaçage de la base de données avec un serveur
http permettra de commencer un travail sur l’impact social du jeu dans la motivation des utilisateurs
finaux. Mais le jeu lui-même devra aussi évoluer, avec l’ajout de textures, de succès et donc d’entités.
Enfin, afin d’intégrer des succès sur le plus long terme, il serait intéressant de développer un jeu de
construction de maison dans le jeu, déjà amorcé avec l’entité «HouseEntity ».
56
BIBLIOGRAPHIE
1. Theppkema, M. Adult obesity in Canada: measured height and weight. Nutrition: Findings from
the Canadian Community Health Survey, no. 1, Statistics Canada, 2008.
2. Manson, J.E., Skerrett, P.J., Greenland, P., and VanItallie, T.B. The escalating pandemics of
obesity and sedentary lifestyles: a call to action for clinicians. Archives of Internal Medicine, 164,
249-258, 2004.
3. Graf, C., Tokarski, W., Predel, H, Koch, B., and Dordel, S. Overweight and obesity in childhood –
how can physical activity help? Physical Education and Sport, 50, 54-59, 2006.
4. Annesi, J.J. Effects of minimal group promotion on cohesion and exercise adherence. Small
Group Research, 30(5), 542-557, 1999.
5. Heinzelmann, F., and Bagley, R. W. Response to physical activity programs and their effects on
health behavior. Public Health Reports, 85 (10), 905-911, 1970.
6. Hohepa, M., Schofield, G., and Kolt, G.S. Physical activity: what do high school students think?
Journal of Adolescent Health, 39, 328-336, 2006.
7. Yim, J. and Graham, T.C.N. Using games to increase exercise motivation. In Proceedings of the
Conference on Future Play, 166-173, 2007.
8. Wininger, S.R., and Pargman, D. Assessment of factors associated with exercise enjoyment.
Journal of Music Therapy, 40(1), 57-73, 2003.
9. Karageorghis, C.I., and Terry, P.C. The psychophysical effects of music in sport and exercise: a
review. Journal of Sport Behavior, 20(1), 54-69, 1997.
10. Copeland, B. L., and Franks, B. D. Effects of types and intensities of background music on
treadmill endurance. The Journal of Sports Medicine and Physical Fitness, 31(1), 100-103, 1991.
11. Elliott, D., Carr, S., and Savage, D. Effects of motivational music on work output and affective
responses during sub-maximal cycling of a standardized perceived intensity. Journal of Sport
Behavior, 27(2), 134-147, 2004.
12. Wales, D. N. The Effects of Tempo and Disposition in Music on Perceived Exertion, Brain Waves,
and Mood During Aerobic Exercise. Master's thesis, Pennsylvania State University, 1985.
13. Boutcher, S.H., and Trenske, M. The effects of sensory deprivation and music on perceived
exertion and affect during exercise. Journal of Sport and Exercise Psychology, 12(2), 167-176,
1990.
14. Steptoe, A., and Cox, S. Acute effects of aerobic exercise on mood. Health Psychology, 7(4), 329340, 1988.
57
15. Patton, N. The influence of musical preference on the affective state, heart rate, and perceived
exertion ratings of participants in aerobic dance/exercise classes. Dissertation Abstracts
International, 52(8), 2858a, 1991.
16. Westcott, W. Role-model instructors. Fitness Management, 48-50, 1991.
17. Brehm, B.A. Successful Fitness Motivation Strategies, Human Kinetics Publishers, 2004.
18. Beauchamp, M.R., Carron, A.V., McCutcheon, S., and Harper, O. Older adults’ preferences for
exercising alone versus in groups: considering contextual congruence. Annals of Behavioral
Medicine, 33, 200-206, 2007.
19. Heinzelmann, F., and Bagley, R. W. Response to physical activity programs and their effects on
health behavior. Public Health Reports, 85 (10), 905-911, 1970.
20. Moran, A.P. Chapter 2: Motivation and goal-setting in sport. Sport and Exercise Psychology (1st
ed.), Routlege, 2004.
21. Hohepa, M., Schofield, G., and Kolt, G.S. Physical activity: what do high school students think?
Journal of Adolescent Health, 39, 328-336, 2006.
22. King, A.C., Kiernan, M., Oman, R.F., Kraemer, H.C., Hull, M., and Ahn, D. Can we identify who will
adhere to long-term physical activity? Signal detection methodology as a potential aid to clinical
decision making. Health Psychology, 16(4), 380-389, 1997.
23. Ransdell, L.B., Taylor, A., Oakland, D., Schmidt, J., Moyer-Mileur, L., and Shultz, B. Daughters and
mothers exercising together: effects of home- and community-based programs. Medicine and
Science in Sports and Exercise, 35(2), 286-296, 2003.
24. Heumer, G., Carlson, D., Kaligiri, S.H., Maheshwari, S., Hasan, W., Jung, B., and Schrader, A.
Paranoia Syndrome – a pervasive multiplayer game. International Symposium on Pervasive
Gaming Applications, 2006.
25. Laakso, S., and Laakso, M. Design of a body-driven multiplayer game system. Computers in
Entertainment, 4(4), 7, 2006.
26. Strömberg, H., Väätänen, A., and Räty, V. A group game played in interactive virtual space:
design and evaluation. Conference on Designing interactive Systems: Processes, Practices,
Methods, and Techniques, 56-63, 2002.
27. Wakkary, R., Hatala, M., Jiang, Y., Droumeva, M., and Hosseini, M. Making sense of group
interaction in an ambient intelligent environment for physical play. Proceedings of the
Conference on Tangible and Embedded interaction, 179-186, 2008.
28. Mueller, F., Gunner, S., Thorogood, A., O'Brien, S., and Wulf, V. Sports over a distance. Personal
and Ubiquitous Computing, 633-645, 2007.
29. Strömberg, H., Väätänen, A., and Räty, V. A group game played in interactive virtual space:
design and evaluation. Conference on Designing interactive Systems: Processes, Practices,
Methods, and Techniques, 56-63, 2002.
58
30. de Oliveira, R., and Oliver, N. TripleBeat: enhancing exercise performance with persuasion.
MobileHCI, 255-264, 2008.
31. Pollock, M., Gaesser, G., Butcher, J., Despres, J, Dishman, R., Franklin, B., and Garber, C. ACSM
position stand: the recommended quantity and quality of exercise for developing and
maintaining cardiorespiratory and muscular fitness, and flexibility in healthy adults. Medicine &
Science in Sports and Exercise, 30(6), 975-991, 1998.
32. Stach, T. (2010) Design aspects of multilayer exergames. /Technical Report 2010-571, School of
Computing Queen's University/.Link: http://research.cs.queensu.ca/TechReports/Reports/2010571.pdf
33. Gamespot DKC, http://www.gamespot.com/gba/action/donkeykongcountry/review.html
59
GLOSSAIRE
ADSL : Asymmetric Digital Subscriber Line, est une technologie réseau qui permet d’augmenter le
spectre électrique utilisé sur les lignes téléphonique conventionnelles afin d’augmenter la bande
passante disponible.
AGILE : méthode de développement privilégiant le développement rapide, les contacts fréquents avec le
client incluant une démonstration concrète.
BD : (Base de Données). Une structure logicielle qui a été pensée pour stocker une grande quantité de
données tout en optimisant son temps d’accès au maximum. L’accès à ces informations est souvent fait
à l’aide d’un langage spécifique (SQL pour ce projet).
C# : langage de programmation orienté objet de Microsoft.
Exergame : jeu vidéo qui nécessite une activité physique du joueur.
Feedback : retour d’un système à un utilisateur des suites d’une action qu’il a accomplie.
HTTP : (Hypertext Transfer Protocol). C’est un protocole réseau qui est la base du World Wide Web. On
utilise ce protocole à chaque fois que l’on se connecte à internet à l’aide d’un navigateur.
IDE : Integrated Development Environment, Interface WIMP qui assiste le développeur lors de son
travail.
LiaV : Life Is A Village est un exergame basé sur le moteur open source OGRE. Ce projet de l’EQUIS
laboratory est réutilisé dans quasiment tous les projets du laboratoire qui font intervenir de la 3D.
Microsoft : multi-nationale, créatrice de Windows ou plus récemment de la Xbox.
MySQL : système de gestion de base de données, un des plus répandus au monde.
MVC : Patron de conception signifiant Modèle Vue Contrôleur.
PCGamerBike : nom donné au modèle du vélo électronique utilisé pour le projet, semblable à un Tunturi
Bike mais quasi-transportable.
Php : langage de script libre très répandu sur internet qui permet de faire générer des pages web html
par un serveur distant. Ce langage s’interface facilement avec d’autres technologies web comme le
JavaScript ou MySQL.
Plug-in : module externe complétant une application hôte en accroissant ses fonctionnalités.
Tunturi Bike : l’EQUIS laboratory possède deux de ces vélos d’appartement modifiés. Ils permettent,
durant un effort physique, d’envoyer des données à un ordinateur et ainsi de récupérer le nombre de
tours par minute, le nombre de Watt produit etc.
60
UML : Unified Modeling Language, il s’agit d’un langage de modélisation graphique de l’architecture
d’un logiciel.
Visual Studio : IDE de Microsoft, il permet via un plug-in de développer des jeux XNA.
Xbox Live : plateforme réseau qui distribue du contenu multimédia et des jeux vidéo pour la console de
Microsoft (Xbox 360).
Xbox 360 : console de jeu nouvelle génération, elle peut exécuter des applications/jeux XNA.
XNA : une API de Microsoft d’aide au développement efficace de jeux vidéo. Souvent utilisé dans le
prototypage de mini-jeux ou le développement de jeux vidéo indépendant pour la plateforme Xbox Live.
WIMP : Window Icon Menu Pointing. Paradigme d’interaction utilisé par des applications depuis environ
une trentaine d’années (exemple : l’Explorer Windows, la suite Microsoft Office ou encore les interfaces
KDE ou Gnome que l’on retrouve sous Linux).
61
ANNEXES
1. LES TEXTURES DE BBWOE
Cette annexe présente les textures qui ont été dessinées par Chris Oliver pour le projet. Elle inclut
également quelques textures qui persistent dans BBWoE depuis ses débuts, comme celles du tank. Elle
n’est pas une liste exhaustive de toutes les textures de BBWoE mais plutôt un aperçu qui permet d’avoir
une idée assez précise de l’identité graphique du jeu.
A) AVATARS
VOITURES
MONOCYLE
62
TANK
LES FANTOMES
LES EFFETS
B) SURFACES
63
C) LES OBJETS DU MONDE
64
65
D) LA MAISON
66
2. RAPPORT DE BRAINSTORMING
A) PREMIERE REUNION
What? (Aim)
The inputs techniques use since the prototype development has been choose arbitrary, so we need a
brainstorming session to give new (different) ideas.
Where?
This brainstorming takes place in the new meeting room of the EQUIS: the garden.
Who?
Actors:
Eril Berkok, undergraduate student working in BBWoE project;
Andrew Heard, undergraduate student;
Claire Joly, Master HCI student;
Louis Noval, Master HCI student.
When?
Date: Thursday 20th May 2010
Why?
See next.
INTRODUCTION
The meetings before this first brainstorming generates sometimes few ideas, but have not been
organize for that. Especially project meetings, where we decide what kind of input we want to use. After
a lot of decision takes because the Xbox 360 pad is use like that in 90 % of the cases. We want to have a
real user center input method. Before this meeting: the bike was use to move the avatar: if you pedaling
clockwise, the avatar go forward (if avatar facing forward). Contrary, if you pedaling counter-clockwise,
the avatar go backward (if you facing forward). The player was able to change avatar’s direction by using
pad's left thrumstick, left or right for facing left or right. The other actions of the avatar are:
Brake using B button;
Use when the avatar touch the object using X button;
Jump when the jump progress bar is full, using A button;
Zooming in/out by pressing the crossbar pad up or down;
The last functionality add to the avatar is the rotation management. First the user can stabilize the
rotation by pressing the Use button when the avatar doesn’t touch something. But I had other buttons
67
for directly rotate the avatar clock wisely and counter-clock wisely. This buttons are: the triggers (left or
right for clocker or counter-clockwise rotation). The buttons upper this triggers for the same using easily
to try on user if the function can be tested on real time).
All of us have already played at BBWoE, but the improvement of the game varies in our mind: Andrew
has been play just few hours before the meetings, Claire play BBWoE 2 weeks later. She doesn’t know all
the changing about the rotation. But actors don't remember all the controls.
GENERATED IDEAS
After an introduction in a brief talk about our point of view on how the brainstorming works, the idea
generation and discuss start.
Why using the pedals for moving the avatar, pedals are not better to use for stabilize the avatar in the
air or using pedaling for moving and for stabilizing when you are in the air.
The actors think that the triggers are a good solution for this rotation problem too.
The changing of avatar direction can be simple by using a simple button (Y should be just perfect for
that).
After discussion about how the use function works for now, Claire asks why we not choose to take right
thumbstick direction + press it to give a specific direction and intensity to the force. This should be use in
addition to the simple way that we find to do that (press just a button).
About the zoom, Andrew talks why we don't take RB and LB for managing the zoom (buttons upper the
triggers).
After this meeting, we start a discussion about the hypothetic future of this project, and I talk about the
nick idea: the climbing. Eril in joking said "like the batman grappling hook?” This idea can be interesting
in following project improvements.
CONCLUSION
This meeting has two points of view about this conclusion: In one hand we don't have generated a lot of
real ideas. But in another, a lot of idea generated is near already implemented function. The strategy to
assign buttons at already using function seems to pay.
B) DEUXIÈME RÉUNION
What? (Aim)
A start of thinking about track editor have to be done before the next sprint, we need some ideas from
different people on this part of the game.
Where?
68
This brainstorming takes place the main room of EQUIS lab.
Who?
Actors:
Andrew Heard undergraduate student;
When?
Date: Wednesday 26th May 2010
Why?
See next.
INTRODUCTION
This track editor is not really important for our user testing, in first time. Because for longer user testing
we have to add a good gameplay for keep the player in the game enough time for his healthy. So this
first version of track editor doesn’t really aim a good design. Some features should probably not
implement, but we want a quick, basic and easy to use editor. The idea is to add a second iterate to
really take the time for developing this editor.
GENERATED IDEAS
After an introduction in a brief talk about our point of view of why we do this meeting, the ideas
generation and discuss start:
Prompt the track editor;
We can start the editor during the game by pressing the big X button (in the middle of the pad);
We can use Back button too for that;
This action does the game in pause for the player;
Directly access by a game menu;
Access to the different shapes, different sprites;
Using Dpad combine with a basic 2D menu presenting different items;
During this action, you can change sprite apply on the object using LB or RB;
Or by pressing LB + a direction with the left thrumbstick;
Another idea is using two menus (one for the textures, and another for the entities);
Another idea about these menus is using pie menu: LB you pop a menu entity, RB you pop a texture
menu.
Editing the size of shape:
You can change the size of the shape after his selection;
69
Or, you can change the size when you have selected one;
For changing this size, using right thrumbstick seems to be the simple way. You increase the width by
moving the stick right, reduce by left. You increase the height by moving the stick up, reduce by down.
Actions based on buttons:
(A) Pick up something;
(X)(When you have nothing already selected) Pick up something (more closely than the original
gameplay);
(X) (When you have something selected) apply the modification and unselect you object;
(B) Undo operation on current object if you have selected one, if you are not, undo last operation;
(A) Start a physics testing;
Dpad for check and edit physics properties of the current object (Y button is free and can be use to
prompt this menu).
CONCLUSION
All this idea is really interesting, and gives new orientations on a more precise design. But because we
probably will develop a basic editor, we have to refine this idea to keep the most simple and remove all
too complex functionality. After this, we should bring some interaction problem, and need to find new
ways. This meeting reaches this simple goal.
C) TROISIÈME RÉUNION
What? (Aim)
Reflect about how to split houses for easily personalizes them. How to re-use as less as pieces of terrain
possible for making a nice world? What kind of terrain you imagine in this game?
Where?
This brainstorming takes place the garden of the EQUIS lab.
Who?
Actors:
When?
Date: Monday 26th July 2010
Why?
70
See next.
INTRODUCTION
The main goal of this meeting is reduce de number of different sprites that we need on the game. This
number can be reduce by factorize quite similar sprites (like with the houses) or by re-using the same
texture lot of time (but in this case we want to hide this to the user).
GENERATED IDEAS
After an introduction in a brief talk about our point of view of why we do this meeting, the ideas
generation and discuss start.
First we start to discuss about the houses:
We can split the houses by isolated each scenery pieces;
Very flexible, higher level of tuning;
Contrary, we can isolate houses stairs by stairs;
Very simple to use, the most Lego like?
A mix: An atom for each stairs (a piece of wall + window) for generating building in height AND in Width;
A real mix before the two other solutions;
After we go on the different surfaces: (already exist surfaces that work: ice/wood/grass)
You can add this kind of surfaces:
Pavement (road);
Stone;
Mud;
Sand/gravel;
Steel -> girder.
For avoid having always the same details that user see by traveling the world:
You can adding scenery object on top of this surfaces (like in sonic the hedgehog);
Changing the size in Width can be a solution for re-using textures.
CONCLUSION
The solution of splitting houses stairs by stairs are really simple to use, and you can add stairs for long
term achievement easily. But after discuss with Nick, it seems not enough flexible for further
developments of the game. It's the reason why we will take the opposite solution; even if we will not
have enough time for implement it completely. Moreover these little pieces can be collect by the player
easily in different parts of the word. For the new ground, I will give to Chris this different surfaces and
ask him which ones should be the best in term of visual effect (depending of what he want) This surface
will have maximum details remove for be able to add it in a second time directly in the XML file of the
"level".
71
3. TEST UTILISATEURS
Remarque : ces tests ont portés sur les utilisateurs dis finaux, donc le public qui est censé jouer avec le
prototype et pas le modifier.
A) FIRST USER TEST
This informal test is the first of a probably long series. The goal of this test is multiple:
Have different feedback on specific functionality;
About the gamepad thumbstick use to change direction;
About the feedback of the avatar when you move;
About what you feel when you use the bike on ice or other different ground?
Give opinion about that functionality, and more generally;
Present what I have done at my colleagues since I'm at EQUIS lab.
This test phase has been sharing between two days, the first only the user A test, cause to not enough
time. Theses feedbacks have been important, and easy to fix for many of them.
USER A
Ice not enough slicing;
Brakes not enough efficient;
Pad to change direction sometime don't take new direction;
A weird bug of direction, sometime the upper part of the tank doesn’t turn, but the tank goes in other
direction;
Not enough difference between wood and grass.
All these problems (expect the bug of direction) have been solving in few minutes. The direction trouble
have been modify next morning. The next day I ask to the same user (A) to test again on the new version
of the game.
I have forgotten to add the brake on the bike...
Object on ice have a better behavior;
But the bike has a feedback not clear cause by the symmetrical of his seat;
The using of pedals clockwise for break is a good think;
The wheel of the tank is sometimes too close. Why do not solve this with stack wheel?
The problem of asymmetrical seat should be solving when I will add an avatar on the seat. The problem
of wheel too close have been solve by modify directly the position of the wheel.
After that, user B and C test the game.
USER B
At high speed, you don't feel the difference between the different surfaces;
When you pedaling fast, the tank have too much speed (all the avatar is deform);
When you press twice left pad, your avatar is completely loose, you can't track them with the camera;
USER C
72
Not enough difference between the surfaces;
The tank feedback is better that the unicycle feedback. Unicycle has to rotate to be more fun.
For the user B, the problem of camera has been solving first, just a value to store before erase it. The
difficulty to feel the difference at high speed can be cause by a too small world to see different distance
to stop the avatar. Future tests will check this hypothesis.
For the user C, the problem of not enough difference between different surfaces has to be re testing at
next test. Because I already change variables, and maybe different user have different feelings. The
opinion about a better feedback for the tank than for the unicycle have already is mention by user A. I
probably add rotation to the unicycle when I solve the problem of how to keep it on the wheel.
All the other problems have been solving at the end of these tests.
B) SECOND USER TEST
You will have to test a simple level, with 3 type of avatar. I want feedback about the game, but I prefer
focus about gameplay around the avatar. So you will perform the test and respond at simples questions
next. I take notes in parallels of our discussion during the test or after.
User A: (Hardcore gamer)
Order of test: Unicycle Tank Beetle
User B: (Gamer)
Order of test: Tank Beetle Unicycle
User C: (None gamer)
Order of test: Beetle Unicycle Tank
USER A
Do you enjoy playing BBWoE, depending on which avatar you have?
Unicycle:
Seams better than last time;
Balancing is good -> "quite perfect".
Beetle:
Not enough rotation;
The car is easily stacked on the back.
Tank:
In floating platform, too much to do at the same time (using function maybe too complex to handle)
About the control of theses avatars, do you have any remarks, advises?
Feels better;
Rotation is great;
Smoke effect is a good idea of feedback, but the picture is not.
Do you think that it’s adapting control for this kind of game (platformer, multiplayer, exergame)?
Yeah, but the jump bar is useless...
If you have to play again at BBWoE, what avatar you probably prefer to use? Why?
73
Unicycle, because the balancing is fun to manage.
If we decide to create a fourth avatar, what kind of think that can be?
Motorcycle (like X-Moto) or a simple wheel.
USER B
Unicycle:
Harder than tank;
But fun.
Beetle:
Too much bounce when you pedaling faster;
Need some improve about wheels behaviors (adding grip?).
Tank:
Control feels simpler than the last time;
Tank seams refine.
Note: Understanding how the triggers (rotation) work in 1 minute.
The rotation using the triggers seams intuitive;
The smoke is cool;
A lot more fun this time.
Tank, it's the easiest to play.
If we decide to create fourth avatar, what kind of think that can be?
Don’t know.
USER C
Unicycle:
Have to keep your avatar straight -> increase interest;
More difficult, but more fun;
Quite natural.
Beetle:
Too light?
Wheels too much slicy;
Why the car jump when I try to go fast? (Bad behavior)
Keep the speed too much time;
Weird position of the car body compare to the wheels.
Tank:
Much easier;
Seams a tank behavior (Weight + chain);
Too high jump?
Pleasant;
Need to increase the Weight?
74
I think it can be better to inverse thrumbstick and triggers...
The smoke is good effect; maybe a darker texture can increase the realism?
I don’t know.
Tank because it's easier to play, better control. But probably the Unicycle when I will be better.
If we decide to create fourth avatar, what kind of think that can be?
3 avatars seem enough …
4. ARCHITECTURE CLIENT
This is a view of different classes in BBWoE:
A) OVERVIEW
75
The next points will introduce contains of this classes.
MOTHERCLASS
For the moment this class is useless, just for editing screen resolution. But the idea is to keep this class
to add easily further functions.
BBWOE
76
The main class of BBWoE project, in this class call loading function in LoadContent() method, update
data in Update() loop and call few object to draw in Draw() loop.
CURRENTGAME
This class has to keep all object and there palette to draw in memory. It’s use to call all the JANUS
communication for loading EntityStream and GhostStream. You can comment or uncomment #online
and #offline if you want to switch the game between these modes.
CURRENTPHYSICSPROPERTIES AND BACKGROUNDTEXTURES
CurrentPhysicsProperties will store all the physics properties of the current place, it’s the same thing for
BackgroundTextures, and the feedback of another texturing should be using to differentiate physics
properties like gravity.
GAMEENTITY
This class is generic class of an object, or an avatar.
OTHER *ENTITY CLASSES
This is all object of the world, with generic definition to be easily reused or adapt to the context. You
have just to call <name>Entity(<param1>,<param2>,...), add this object to the Contains. See object
hierarchy part for more details.
AVATAR
This is a generic class of the already implemented avatar: Monocycle and tank. See object hierarchy part
for more details.
OTHER CLASSES
CAMERA 2D
Manage camera gesture, zoom, and other properties relatives of the view (object is in the camera's
field...).
INPUTCONTROL
Manage all key, pad, and Ipower event, change values of global variables in the avatar file.
INPUTHELPER
77
Manage input for change camera properties, this file will probably be deleting, it depends if we want a
control of the camera by the user, and if the user prefers that too.
XMLREADER
A class to easily create a world using a XML files. In this file the program create new entity after there
loading.
B) FOCUS ON THE OBJECT HIERARCHY
This is a view of the objects classes:
GAMEENTITY
This class is a generic class that contains generic approach for each object: a position, a size, a mass ...
The applyPower() method should move easily an object using the avatar and his use function.
THE AVATAR
The avatar class is a specific class inherits from GameEntity. So the main difference is an orientation of
the avatar. This orientation as type of enumeration Orientation: Up, Down, Left, Right. The camera will
track the object call Shape1 include in our avatar.
MONOCYCLEENTITY & TANKENTITY
Real implementation of each avatar: Loading of bodies, textures, and geometric in LoadContent()
Drawing of this bodies in the Draw() method.
*ENTITY
78
Each <objectName>Entity class is use implement object: Loading of bodies, textures, and geometric in
LoadContent() Drawing of this bodies in the Draw() method.
Like the avatar entities, the difference between two objects can be important. For the moment the most
complex (unique) is the BeltEntity. But BBWoE should be more and more complex
C) FOCUS ON THE LOADING PHASE
Before the game is able to run, the program has to load. More the project progress, more this phase has
to be complex. It's the reason why I try to describe how does it works. Like the first diagram, the first
class to be call when the game start is BBWoE (MotherClass is useless for the moment).
This diagram tries to present the BBWoE classes from a loading point of view. He as to be read from up
to down:
79
The BBWoE diagram call BackgroundTextures class to have a list of possible background. Next, BBWoE
create an instance of CurrentGame. This class will use a class call Palette to have a texture name for
each name of object. It's the call of an Avatar class (TankEntity, UnicycleEntity or BeetleEntity) by
CurrentGame who start the real loading of object. This wills LoadContent of the object. The last step for
CurrentGame is calling of ReaderXML to load the other entire game object. After that, all the
LoadContent() method have been initialize, the game can start to run.
D) FOCUS ON GAMEENTITIES PROPERTIES
80
These properties are sum up in level.xml. For example, this is a GroundEntity:
<ground
id="1" (int, range: [1,oo[)
texture="box" (string)
friction="0.8" (float, range: ]0,+oo[)
restitution="0.1" (float, range: ]0,+oo[)
mass="100" (int, range: ]0,+oo[)
angle="1" (float, range: ]-oo,+oo[, but between ]-Pi,Pi[ is enough)
heightWidth="new Vector2(1000, 100)" (string, with int between ]-oo,+oo[)/> startPos="new Vector2(960, -700)" (string, with int between ]-oo,+oo[)
achievement="false" (bool)
gravityless="true"> (bool)
</ground>
Note: You can write the vector2 with this shorter format: heightWidth="1000,100"
All the gameEntities use this Entry format for the moment (except BeltEntity and StartStopEntity).
The Id property is just use for make easily de difference between two object.
<belt
id="1"
texture="belt"
friction="0.8"
restitution="0.1"
mass="100"
angle="0"
size="150"
startPos="new Vector2(4400, -500)"
achievement="false"
speed="100">
</belt>
For the belt I should add a second texture parameter.
E) HOW THE AVATARS WORKS?
An assembly of different bodies has created each avatar. Some bodies as implemented as Geom in to
add collision detection (see Farseer Physics manual for more information). Even if this picture uses old
avatar sprites, all the physics still true. A picture to illustrate with a body view of each avatar:
81
About the legend:
Motion: Wheels where the torque force is apply when you pedaling.
Rotate: When you press a rotate button, the torque force is applied on this body.
Collision: Theses objects have a listener to check if something is in contact (for detect object to use for
example).
82
StackBack: This body (call UpBody) is use to detect when the avatar is stack on the back after a Big Bad
Jump.
Note: Even if the sprites of the Unicycle and the Beetle have been changed, the objects for the physics
engine didn't change at all. So this picture still completely true at the end of the project, like others
parts.
5. DOCUMENTATION DEVELOPPEUR SUPPLEMENTAIRE
A) HOW THE ENTITIES WORKS?
As you can see on these pages BBWoE use a generic system of entities. Each entity use is own bunch of
methods:
LoadContent() is for initiate all the content:
The spritebatch for drawing objects later
Each textures that you need for this entity
The origin for align the texture on the body
The body (the physics view of your entity) (read [physics] for more details)
The geom in some cases (the object use by farseer for detect collisions)
Adding of the body or the geom in the simulator (the geom include the body, so add the "bigger" that
you can).
Adding the event for Enter and Exit method on the object, don't forget to add this event on the
components list.
Action method will be call when the user press the use button and touch the object at the same time.
You have the time and the strength of this action in parameter. You can modify this parameter for each
entity in the game directly in CurrentGame.cs -> OnWheelCollision([..]) method.
Draw(GameTime gT) method is use for draw the specific entity on the screen. This drawing have to be
between a call of spriteBatch.Begin([..]) and a spriteBatch.End(). The SpriteBatch.Begin([..]) contains
different parameters:
SpriteBlendMode is use for apply different treatment to the transparent part of textures.
SpriteSortMode is for modify the order of drawing textures for this specific entity
SaveStateMode is for avoid to erase the older textures after each new drawings
((MotherClass)_game).Camera.CameraMatrix is for using the Camera2D class
For each entity, you have to add this function for keep descent performance:
Camera.ShouldDraw(Sprite, Position, Origin, Angle).
83
You can override Enter() and Exit() method for add a specific behavior to your entity when an avatar go
in or out.
B)
MOVING BBWOE FROM COMPUTER TO COMPUTER
Assuming you're transferring from Eril's computer, you should have the following:
BBWOE Server:
BBWOE Server itself;
MySQL Server 5.1;
bbwoe_entities database contained in MySQL Server 5.1;
MySQL Connector Net 6.2.3;
Windows XP or newer;
Visual Studio 2008.
BBWOE Client:
BBWOE Client itself;
Windows XP or newer;
Visual Studio 2008;
XNA 3.1.
Procedure to move:
On the computer containing the database, first go to cmd.exe (in Windows 7 on the search bar, type in
command and it should show up).
Here you should have a black command prompt. What you need to do is perform what is referred to as
an SQL dump. This will copy the schema and data of the tables of the database into a convenient and
portable file.
To do this, type in this command:
mysqldump -u(USERNAME) -p(PASSWORD) (DATABASENAME) > (PATH).sql
Anything in and including the brackets is to be replaced with the appropriate data. Typically the
USERNAME will be root, and the PASSWORD will be whatever you set it to when you first installed
MySQL Server. DATABASENAME is the name of the database that you wish to dump (in this case,
bbwoe_entities). PATH is simply the path to where you want to store the dump. Mine was this:
C:\SQLDump\bbwoe_entities.sql
Now that you have this file, you can copy and paste, or move, wherever you want just as you would any
other file. Remember that this only stores the schema and data of the tables, not the actual database
into which it'll be stored;
84
Move the SQL dump to whichever computer you'd like. Make sure MySQL Server 5.1 is also installed and
setup according to how you'd like it;
To import the database, return to cmd.exe (same way as it was done in the first step) and type in the
following command:
mysql -u(USERNAME) -p(PASSWORD) (DATABASENAME) < (PATH).sql
All the same information mentioned in step 3 applies here. Make sure that DATABASE is already created
in the MySQL server, since the dump will not create that. PATH is where you stored the dump. Also keep
in mind the command here is mysql rather than mysqldump. This is a mistake that I made that cost me
quite some time, and I hope that you, my successor, will not also make this mistake.
Install MySQL Connector Net 6.2.3. This will enable us to connect our MySQL database to Microsoft
Visual Studio;
Now you can bring the server and client components of the BBWOE program over to this computer.
Open the server project;
In Microsoft Visual Studio 2008, you need to find your way to "Connect to Database" (may be under a
different name in different versions, "Add Data Source" was also another name I've seen). This can be
found under the Tools tab;
Select MySQL database (this will show up now that the MySQL connector is installed);
Enter information, and test connection. Name of the server will probably be localhost, user id will
probably be root. When this succeeds, simply select bbwoe_entities from the drop box. Now the
program can see the database;
You are done! Simply launch the server, and then the client.
Also make sure that JANUS' StreamServer is begun before you start the server/client. Currently the
server sends a startup command to it, but you needs to make sure it are pointing to the right place. It's a
line in the Program.cs class in the server component. Make sure it's referring to a StreamServer.exe that
actually exists.
C) TINY THINGS THAT CAN CREATE TROUBLES
All the entities that I’ve develop works, but should not support all possible entry values.
For example the BeltEntity don't support different angles value. You have the same problem with the
size of entities that you can modify, if a ground entity is too large, you will have a part of the entity
invisible on the screen.
For the moment BBWoE use colors for appears action on the avatar on object, but we need to change
that by choosing better color than green and red, or by finding another feedback.
85
You can switch between avatars by using the start button; we have to create a menu for choosing the
avatar before the game start (or another thing);
The XML parser use for BBWoE is not perfect and have to be improves: Lot's of entities uses useless
parameters or unperfected names;
The using of a 2nd thread for loading the game improve the performance of the online version of the
game, however the game still have tiny freeze cause by the using of the component list by both of this
threads;
The server support up to 10 clients at the same time, you can improve this number by simply change
numberClient variable in the client AND in the server.
6. LE WIKI
Les annexes 2, 3, 4, 5 peuvent être trouvées
http://dundee.cs.queensu.ca/wiki/index.php/BBWoE
sur
le
wiki
à
cette
adresse :
Les annexes ont le même contenu mais cependant, le wiki peut avoir été mis à jour depuis son
intégration dans le rapport.
7. PRESENTATION DU PROJET
Dans la liste des livrables à fournir, il est demandé une vidéo du projet ainsi qu’un texte général de
présentation du projet. Vous trouverez ces documents sur le site du laboratoire, à cette adresse :
http://equis.cs.queensu.ca/?page_id=448
8. ETAT DE L’ART
A) LIFE IS A VILLAGE
This project aimed to create a full 3D game based on the famous open source engine OGRE. The game
makes use of a combination of an electronic bike and a game pad for player input.
GAMEPLAY
The player take place in a large terrain, compose by mountains, valleys, trees. By pedaling, the avatar
explores the landscape to find a location for this village. After this first step, the player has to seek
resources in this new world. You can harvest wood near forest, stone near to cliffs. Because you start
with just one villager, you can harvest just one resource at the same time, but by adding additional
building, you increase your harvest capacity. You can access to greater resources on harder place to
reach (top of mountains for example). After developing your village a little bit, you have access to
advanced buildings, scenery structures for your village for example. But this game is made to be play on
just a single session, so players can save the game state, and later pick up.
86
The basic controls are: You pedaling for going forward, faster you pedaling faster you go. With your pad
you can brake, steering, and many other actions. For example, in the game when you want harvest a
new resource like wood: First you have to be close enough for pop-up a message that ask you if you
want to harvest this wood. Next you press "1" button on the pad (same position than X on Xbox 360
pad) to validate your action.
But you can play this game with a lot of different inputs:
IN NORMAL MODE
Tunturi bike:
Pedaling forward for going forward (faster you pedaling faster you go);
You have a force-feedback depending the difficulty of the terrain;
Pedaling backward just do nothing.
With the mouse you can moving your avatar:
Left click: walk forwards;
Right click: brake.
With the pad:
Left thumbstick control moving forwards and braking;
Right thumbstick control the camera view (up and down) and turns the avatar (left and right);
Button number 2 and the two right triggers control the brake;
Button number 3 and 4 control gear down and up;
Button number 1 is action button, for cut down trees for example;
Button number 10 (kind of start button) inserts a building (switch to building insert mode).
With the keyboard:
Arrow UP and W move the avatar forwards;
Arrow DOWN and S apply the brake;
LEFT and RIGHT and A and D turn the avatar left and right;
ESCAPE exits the program;
PAGE UP / PAGE DOWN shift the avatar's "gears" up and down;
ENTER is the action button;
HOME and END pitch the camera up and down;
PRINT SCREEN takes a screenshot image and saves it to the current working directory;
B inserts a building (switch to building insert mode).
IN BUILDING MODE
With the pad:
Right thumbstick positions the building;
Button number 3 and 4 rotate the building left and right;
87
Button number 2 is used to cancel building insert;
Button number 10 button confirms the building insert;
With the keyboard:
Arrow keys and WADS move the building;
B inserts the building;
DEL cancels the building insert;
Q and E rotate the building.
Start of Analysis:
First, in this game you running your avatar when you pedaling. The parallel is not perfect but works; the
immersion seams better than just press a button for walking (but need to be tested on people for check
if everybody as same sensibility). Another good point is that: you need to move a lot in this game
because you want to discover new resources, new landscape; so this increases the efficiency of the
exercise. Forgive motivation to the player, the game use a combine of short term and long-term goals.
You have to searching for resources (short term) and after enough resources you can build a new type of
building (long term). For the controls, the good point is that the game supports a lot of different
peripherals (pad, keyboard, mouse, joystick, Tunturi bike). But it's hard to remember all shortcuts for
each state. Another problem is the lack of consistency between normal and building state: the button
for gear Up and Down is use for rotate Left or Right the building for example. The player discover the
control each time he get stack, his try different button until something append on the screen.
Even if the HCI have to be improving, this exergame have been developing to be re-used. So the most
important is a architecture that can be modify for create new tests/games faster as possible. This is
harder to see, but LiaV is use in more than 10 projects in the lab like Frozen Hunter treasure or Heart
Burn (2 exergames). And I don't know one of these users complain about bad code readability or
something like that.
B) PERSISTENT OR ASYNCHRONOUS GAMEPLAY (IN MULTIPLAYER GAME)
Remarque : cet état de l’art n’a pas été terminé car les recherches n’ont pas été suffisamment utiles au
projet pour mériter d’y consacrer plus de temps. Il m’a cependant permis de découvrir ce que sont les
jeux multi-joueurs asynchrone, même si je n’ai pas pris le temps de rédiger cette partie vu que BBWoE
n’est pas encore assez mûr pour pouvoir y intégrer ce genre de gameplay.
INTRODUCTION
With the rising popularity of MMORPG like World of Warcraft (Blizzard Entertainment, 2004), the
MMORPG style is the kind of game that we think when we thinking about multiplayer games. But this
kind of game still Hardcore gamer oriented (even if WoW is one of the most casual MMORPG game).
This paper tries to present, in the first hand, main idea of persistent world oriented, like MMORPG, and
other, in the other, asynchronous game. In conclusion we will present few games base on persistent
world combine with asynchronous communication.
88
PERSISTENT (SYNCHRONOUS) WORLD
A BIT OF "HISTORY"
You can find elements of actual persistence game in older game like Trade Wars (1984) or Wasteland
(1988) but it's the advent of MMORPG that really express what a persistent world can be.
We cannot present MMORPG without explain what is MUD (Multi-User Dungeon). It was the first
adventure game to support multiple users. The player was to connect to a server using the Local
network of the university, and answer to the Dungeon Master questions by basics worlds (yes, no, leap,
go in ...).Screenshot of recent version of MUD:
MUD based on Dungeon & Dragon (D&D), is the precursor of nowadays MMORPG. (Multi-User
Dungeon). You can find a lot a game designers or developers influence by MUD (Interview Brad
McQuaid, Interview Brian Green). But the first graphical MORPG was Neverwinter Nights (First Graphical
Online RPG) This game start with server who can connect 50 players on the same game in 1991. Internet
connection costs dropped, and improvement of server (500 players on a same server in 1995) created
hourly player charge decline. This explains a part of the constant improvement of the players’ number
between 1991 and 1997 July (115000 players) the date where the game was stop. Ultima Online
released in 1997 was set in the already popular Ultima universe. It was also more involved, complex
than many of its predecessors. Ultima online is now credited with popularizing the genre (IGN Ultima
Online review). Everquest launched in 1999 was the most successful MMORPG in the U.S for five years
and was the basis for 16 expansions. Since Everquest, the genre continue to progress with new
gameplay mechanism like Realm vs Realm (RvR) in Dark Age of Camelot or free to play MMO who
generating revenue by selling in-game enhancements.
89
NOWADAYS
Persistent worlds can be simulated in offline games, such as in the Animal Crossing series. Even though
nothing happens while the game is off (due to the obvious technical constraint), the illusion of
persistence is created by advancing events as soon as the game is turned on. The game generates events
that could have happened during the real-world time in which the game was inactive.
Nowadays, World of Warcraft are the most play MMORPG around the world, about 11.5 Millions
(Blizzard Press Release 2008). You find in WoW a mix of gameplay innovation since Ultima Online.
Players have to improve abilities of our avatar. For do that, the avatar have to win some experience
points, stuff, gold. You have many ways to interact with the world: you can move your avatar using your
keyboard and your mouse, you can talk with the avatar around you using a chan include in the game
(you can call avatar near you, but you can talk in a specific chan if you want, your group chan, or guilde
chan for example). When you playing with your guild you have to use VOIP software to directly talk with
your ally (mumble, teamspeak or ventrilo). But there is asynchronous way to discuss in WoW. You can
sell or buy stuff like weapons using a specific auction market in the game. If you win an auction, you
receive your object directly by Mail in few hours. But you can use this Mail system to write letter to
other character, or send objects.
<Talk about the non online persistent world Animal crossing. >
But MMORPG is not the only nowadays game that let player interacting in a persistent virtual world.
Animal crossing is one of these games: You playing an animal that living in a town filled with cartoonish
animal characters. You can interact with them for buying house, work, trade, and personalize their
environment. The game is already synchronized on the real world: If you playing the night the game will
be darker that during the day.
ASYNCHRONOUS GAMEPLAY
Diplomacy and Play-By-Mail
"The most successful game for this format is clearly Diplomacy" (Gamasutra asynchronicity)
Describe Diplomacy and the problems
Describe why Play-my-Mail is a good solution.
Battlemail: Play-By-Email
Describe how battlemail kung-fu work
Conclude about this game
The first version of Animal Crossing ran on a Nintendo GameCube (GC) support asynchronous multi-play
with up to four players. This console support synchronous gameplay, its deliberate designers choice to
let player discover this world alone. These players can interact with their friends or family members who
play the same game, but indirectly: by leaving notes, gifts, completing tasks, or even planting flowers or
trees.
CONCLUSION
90
Persistent asynchronous gameplay. We already talk about Animals Crossing,
BIBLIOGRAPHY
Blizzard Press Release 2008: http://eu.blizzard.com/fr-fr/company/press/pressreleases.html?081223
China, What's coming next? 2010: http://www.readwriteweb.com/archives/
china_social_gaming_landscape_whats_coming_next.php
Trade Wars (1984): http://en.wikipedia.org/wiki/Trade_Wars
Wasteland (1988): http://en.wikipedia.org/wiki/Wasteland_%28video_game%29
Online World Timeline 2002: http://www.raphkoster.com/gaming/mudtimeline.shtml








Multi-User Dungeon (1978): http://www.livinginternet.com/d/di_major.htm
Interview Brad McQuaid: http://www.guru3d.com/gamereviews/brad-mcquaidinterview/index1.shtml
Interview Brian Green: http://grindingtovalhalla.wordpress.com/2009/04/23/psychochild/
First Graphical Online RPG: http://www.mcvuk.com/press-releases/34298/NeverWinter-Nights
Petition about NWN: http://www.wired.com/culture/lifestyle/news/1997/06/4625
IGN Ultima Online review: http://pc.ign.com/articles/759/759391p1.html
Gamasutra asynchronicity:
http://www.gamasutra.com/view/news/24310/Analysis_Asynchronicity_In_Game_Design.php
Animal Crossing 2001: http://en.wikipedia.org/wiki/Animal_Crossing_%28video_game%29
9. DETAILS DES SPRINTS
1
2
3
4
5
6
7
8
9
A) AVANT LE PREMIER SPR INT
Cette première phase c’est déroulée en deux parties. Le premier jour a permis de découvrir le
laboratoire, l’environnement de travail comme le bureau que j’ai partagé avec Chris Wolfe pendant 5
mois. Ensuite la deuxième partie a permis principalement de prendre en main Pharseer physics, le
moteur physique utilisé pour ce projet. Cette prise en main a été l’occasion de développer un monde 2D
minimaliste qui a été repris en début de premier sprint et qui est en fait l’embryon initial de BBWoE.
Enfin c’est pendant cette phase d’apprentissage que Tadeusz B. Stach m’a donné des sources sur
l’exergame dont son papier présenté dans la partie analyse, que vous pouvez retrouver sous la
référence 32.
B) 1ER SPRINT : DU JEUDI 1ER AVRIL AU JEUDI 15 MAI
91
Ce sprint se partage en différents objectifs : d’un côté tout en continuant cette phase d’apprentissage,
améliorer l’architecture de cet embryon initial afin qu’il puisse être utilisé dans la suite du projet. Ce
sprint a aussi été pour moi l’occasion d’intégrer l’API GAIM au projet et donc d’utiliser le vélo pour
contrôler l’avatar. Enfin ce sprint a permis d’introduire le wiki afin de suivre l’évolution du projet de plus
près.
C) 2EME SPRINT : DU JEUDI 15 AVRIL AU JEUDI 29 MAI
La tâche a été divisée en deux : poursuivre le « refactoring » amorcé dans le sprint précédent tout en
commençant un travail avec les utilisateurs finaux. Ici, l’amélioration du ressenti lors du pédalage sur
différente surfaces a été mesuré et amélioré.
D) 3EME SPRINT : DU JEUDI 29 AVRIL AU JEUDI 13 MAI
Ce sprint est la dernière évolution majeure du client. Il améliore des entités, résous des problèmes
soulevés par les utilisateurs (développeurs ou finaux) mais aussi ajoute de nouvelles entités pour
permettre la création d’un niveau qui permet quelques minutes de jeu. C’est lors de ce sprint que les
entités évoluent pour supporter des événements lorsque l’avatar les touches ou se détache d’elles.
E) 4EME SPRINT : DU LUNDI 17 MAI AU JEUDI 27 MAI
(Début du sprint en retard en raison de l'absence de T.C. Nicholas Graham le 13 Mai.)
Poursuite des travaux du sprint précédent, notamment pour finaliser quelques entités comme
l’élévateur. Répondre aux constatations des tests utilisateurs, comme le problème de l’avatar qui se
bloque très souvent et gâche le gameplay. Implémentation d’une destruction automatique de l’avatar
qui entraine un « respawn » de celui-ci. Un autre problème qui se pose est le manque de contrôle de
l’avatar dans les airs. Enfin commencer à réfléchir à un mini éditeur de niveaux intégré au jeu.
F) 5EME SPRINT : DU JEUDI 27 MAI AU JEUDI 10 JUIN
Ce sprint se découpe en deux parties : poursuite des améliorations du client par ajout d’un feedback lors
d’un saut (fumée). Ajout d’un système de saut qui fonctionne uniquement si la voiture touche le sol
(demandé par les utilisateurs testés). Enfin c’est lors de ce sprint que démarrent mes recherches sur les
jeux vidéo persistant afin de préparer la deuxième partie du projet.
G) 6EME SPRINT : DU JEUDI 10 JUIN AU JEUDI 24 JUIN
Dernière semaine de travail sur le client avant que je le connecte au serveur, en partie déjà implémenté
par Eril. Dernière amélioration des avatars, notamment la “New Beetle” qui est découpée. Création de la
première version de la vidéo de présentation du BBWoE pour le site du laboratoire (Annexe 7). Durant la
deuxième semaine commence l’intégration du client et du serveur avec l’API Janus.
92
H) 7EME SPRINT : DU JEUDI 24 JUIN AU JEUDI 15 JUILLET
(Premier sprint de trois semaines en raison de l'annulation d'une réunion)
Trois axes de travail sur ce sprint : ajouter le projet sur le site de l’EQUIS laboratory (effectué par Eril).
Réalisation d’une itération et demie concernant l’amélioration de la connexion client/serveur. Et enfin,
poursuivre les travaux de rédaction de l’état de l’art.
I)
8EME SPRINT : DU JEUDI 15 JUILLET AU JEUDI 29 JUILLET
Poursuite du travail d’amélioration du multi-joueurs, par ajout de fonctions. Amélioration des
performances du serveur en ajoutant une mémoire tampon afin de réduire le nombre de requêtes de la
BD. Amélioration des performances du client également, par modification de la fonction qui charge les
entités du serveur en la séparant du reste du code pour qu’elle soit traitée comme un second thread.
Début de la rédaction d’une section sur le wiki qui complète la documentation à l’attention des
utilisateurs « développeurs ». Deuxième itération de la vidéo de présentation du projet.
J) 9EME SPRINT : DU JEUDI 29 JUILLET AU JEUDI 19 AOUT
(Dernier sprint, qui a duré 3 semaines en raison d'une semaine de pause au milieu)
Poursuite de la rédaction de la documentation à l’attention des utilisateurs « développeur ». Opération
de nettoyage du code, à la recherche de tous les bouts de français qui resterait à l’intérieur, mais aussi
tous les noms de variables non adaptés. Implémentation d’un système de succès :
“RegionAchievement”. Ajout de “HouseEntity” également, qui sera probablement complétée d’une
dernière entité après le rendu de ce rapport : « catchableEntity ».
Cette entité permettrait aux utilisateurs « développeurs » d’éparpiller les briques de la maison dans le
monde virtuel afin que le joueur le parcoure pour reconstruire sa maison.
93

The Big Bad World of Exercise

Transcription

Documents pareils

Métro pour l`Ecosse Rouge Module 6 vocabulary

IB French 3 to IB French 4 summer study

Télécharger les paroles. song lyrics.

Travailler aux UK

BLOOD CLOTS: Do you know the facts?

speach - Djamano

l`infocourtier

Chapitre 1 elementaire corrige

TRANSPORT SCOLAIRE/SCHOOL TRANSPORTATION ÉCOLE

5-HTP Plus Formula - Douglas Laboratories

Sémiotique de la représentation de soi dans les