Jeux vidéos sur réseaux ad-hoc - Sidi Mohammed Senouci

CHAPITRE 4. PHASE DE RÉALISATION : ETUDE DE PERFORMANCES
Conclusion sur les expériences menées
Grâce à toutes ces expériences, nous savons donc tout d'abord ce que nécessite le jeu Quake
III Arena, et plus généralement le jeu vidéo. Cette généralisation est permise car Quake III
Arena est un FPS, et il fait donc partie du type de jeu le plus aecté par un réseau de mauvaise
qualité. En conséquence, si ce jeu supporte les conditions du réseau, alors normalement tous
les autres jeux le pourront également.
En parallèle, nous savons dorénavant que les réseaux ad-hoc, au delà d'un certain nombre de
noeuds, ont encore du mal à fournir une qualité susante aux besoins des jeux vidéos.
Les perspectives possibles
Pour améliorer la qualité du jeu vidéo sur les réseaux ad-hoc, plusieurs pistes sont possibles.
Tout d'abord, modier les algorithmes de routage existants. En eet, certains de ces
algorithmes sont paramétrables, et sont le plus souvent congurés pour avoir un minimum de
perte dans le réseau, quitte à faire augmenter le délai. Or, nous avons vu que notre principal
souci était le délai.
Une autre possibilité est tout simplement de créer un nouvel algorithme de routage en
mode ad-hoc, qui serait plus adapté au jeu vidéo ; en pratique, cela ne sera pas réalisable en
un mois.
Il est également possible d'apporter des améliorations en donnant des recommandations
aux joueurs, notamment en terme de placement du serveur. En eet, il est sûrement
préférable que celui-ci soit au centre de la carte plutôt que dans un coin comme ce fût le cas
pour nos expériences.
Enn, augmenter la portée d'émission des noeuds permettrait de limiter le nombre de
sauts, et ainsi réduire de façon considérable les dégradations liées au routage. A l'heure actuelle,
nous sommes en train de trouver des solutions permettant de jouer à quelques joueurs de plus
que ce chire de 7, mais cela fera l'objet du dernier mois de stage et n'est donc pas encore
terminé et exposable dans ce document.
Les dicultés techniques que nous avons rencontrées
Au cours de ce stage, nous avons été heurtés par bon nombre de dicultés techniques que
nous n'avons pas toujours su résoudre. C'est là toute la diérence avec un stage d'ingénieur dit
"classique", en recherche on essaie et ça ne fonctionne malheureusement pas toujours. Voici les
points qui ont posés problème :
Le problème de la reproductibilité des expériences. C'est un problème récurrent
dans la recherche et que nous avons soulevé dans la partie bibliographie, que nous avons
en partie résolu en essayant d'être le plus objectif possible
Le problème de l'émulation. Pour une reproductibilité parfaite, l'émulation (c'est à
dire l'utilisation d'un système réel sur les parties applicatives et une simulation des couches
basses) aurait été optimale. Malheureusement cela est expérimental, et nous avons eu du
mal à trouver la méthode pour réaliser des expériences ayant du sens et étant objectives
Les bots côté client. Cet aspect a été une relative déception pour nous, puisque nous
espérions pouvoir implémenter des joueurs virtuels sur chaque client de façon à pouvoir
relever le score. Or, le jeu Quake III Arena ne le permet pas. Ce point additionné au
56