Les tests dans les jeux vidéo

Le domaine des jeux vidéo, bien que priorisant encore avant tout le divertissement, est devenu un sujet intéressant pour les chercheurs. Ce thème central permet de travailler sur différents aspects reliés à d’autres spécialités très variées. Certains travaux se concentrent sur l’utilisation de la réalité virtuelle (Steinicke et al., 2009), sur les possibilités scientifiques qu’offrent les périphériques d’entrée comme la WiiMote (Shirai et al., 2007), sur l’étude des comportements des joueurs (Moura et al., 2011) ou, comme le sujet de ce mémoire, sur les méthodes de vérification (Lewis et Whitehead, 2011). Cet intérêt de la communauté scientifique n’a pas toujours existé et les entreprises issues du domaine des jeux vidéo ont dû développer certaines techniques propres au domaine des jeux vidéo. Notamment, puisqu’elles travaillent sur des logiciels parmi les plus compliqués du domaine de l’informatique, elles ont développé une façon de travailler qui permet de détecter et éliminer une grande partie des bogues.

LES BOGUES DANS LES JEUX VIDEO 

Bien que des bogues soient aussi présents dans les logiciels traditionnels, il est possible d’observer différents comportements lorsqu’ils apparaissent dans les jeux vidéo. Les bogues ne sont pas nécessairement perçus de la même manière et il est donc important de bien définir le terme.

DEFINITION D’UN BOGUE DANS LE DOMAINE DES JEUX VIDEO

Levy et Novak (2010) décrivent un bogue dans les jeux vidéo de la façon suivante : « tout élément qui n’améliore pas le jeu et qui lui nuit est un bogue ». Ils précisent aussi qu’un bogue ne doit pas avoir été ajouté de façon planifiée (dans ce cas là, on parle d’un « Easter Egg » qui n’est pas important pour notre recherche). La taille de ce dernier n’a pas d’importance. Il est aussi important de séparer les problèmes qui sont liés à l’implementation et à la spécification (Lewis et al., 2010). Les bogues d’implementation proviennent d’un élément qui va à rencontre de la spécification donnée dans le document de design du jeu alors que les bogues de spécification proviennent d’une erreur dans les choix des concepteurs, ce qui amène un comportement étrange. Il est possible que ce comportement soit en fait désiré ou, du moins, découle d’un élément désiré du jeu et il est donc difficile, la plupart du temps, de les considérer comme de vrais bogues à surveiller.

TERMINOLOGIE DES BOGUES

Lewis et al. (2010) formalisent le terme bogue en trois couches distinctives (faute, erreur et échec) en reprenant la terminologie d’Avizienis et al. (2004), mais en les adaptant spécifiquement aux jeux vidéo.
— Faute : Une faute est un problème qui a été ajouté lors du design ou de l’implémentation qui mène à une erreur dans le système. La faute est un élément dans le code qui déclenche le bogue.
— Erreur : L’erreur est la manifestation de la faute lors de l’exécution qui crée un état pouvant mener à un échec si les conditions se présentent.
— Échec : L’échec est une déviation du comportement attendu du système qui peut être observée par l’utilisateur. Ce dernier varie beaucoup et peut être très facile à voir ou, au contraire, presque invisible pour l’humain.
Prenons par exemple un bogue de Dragon Age 2, désormais réglé, qui rendait un personnage complètement inutile en combat (Bartel, 2011). À un certain point dans le jeu, le joueur pouvait gagner une habileté passive d’une alliée qui augmentait sa vitesse d’attaque lorsque cette dernière était dans la même équipe que le héros. Par contre, lorsqu’on la retirait de l’équipe, le jeu enlevait le bonus aux capacités initiales du personnage principal, baissant ainsi sa vitesse d’attaque au lieu de tout simplement désactiver l’habileté. Ce problème dans le code représente la faute. Lorsqu’on enlève le personnage, l’erreur se présente. L’échec obtenu est la baisse de puissance nette du personnage qui peut, à un certain moment, attaquer à une vitesse beaucoup trop lente qui ne respecte pas l’intention des concepteurs.

TAXONOMIE DES BOGUES

Avant de séparer les bogues en différents groupes, il est possible de remarquer deux grandes catégories d’échecs : les échecs temporels et les échecs non-temporels (Lewis et al., 2010). Les échecs temporels requièrent d’avoir certains renseignements sur l’état précédent du jeu pour être considérés comme des bogues alors que les échecs non-temporels peuvent être trouvés en regardant un seul état du système. Les auteurs ont remarqué que même si certains échecs se ressemblent, ils ne se détecteront pas nécessairement de la même manière. L’exemple utilisé prend en compte un personnage qui saute dans les airs. Si le personnage saute à une hauteur  qu’il ne devrait normalement pas atteindre, il est possible de remarquer, en un seul point de l’exécution, qu’il a atteint une hauteur trop haute. C’est un échec non-temporel. D’un autre côté, si le personnage saute et reste coincé dans les airs à une hauteur normale, le problème n’est pas le même. Le personnage devrait normalement monter et redescendre, ce qui fait en sorte que malgré qu’il soit encore dans les limites de l’espace, il ne se trouve pas à une position valide. C’est un échec temporel.Voici une brève description de chaque catégorie :

— Position invalide : Un objet est à un endroit où il ne devrait pas être.
— Représentation graphique invalide : Un objet n’apparait pas correctement ou n’apparait pas du tout.
— Changement de valeur invalide : Une valeur comme le pointage a été modifiée de façon incorrecte.
— Stupidité artificielle : L’intelligence artificielle a effectué une action qui ne doit pas être permise.
— Mauvaise information : Le joueur obtient une information qu’il ne devrait pas avoir, comme par exemple, la carte complète du niveau, n’a pas reçu une information qu’il devrait connaître ou reçoit de l’information qui n’est plus valide.
— Mauvaise action : Un personnage entreprend une action qui ne devrait pas être possible.
— Position invalide à travers le temps : Décrit un mouvement invalide qui ne provient pas nécessairement d’un déplacement vers un endroit qui n’est pas permis.
— Contexte d’état invalide à travers le temps : Un objet est dans un mauvais état pour une période de temps incorrecte.
— Occurence d’événement invalide dans le temps : Événement qui arrive trop souvent ou trop peu fréquemment.
— Événement interrompu : Un événement se termine avant d’atteindre la fin.
— Temps d’implémentation : Le jeu ne donne pas de réponse assez rapidement, communément appelé « lag ».

SÉVÉRITÉ DES BOGUES

Plusieurs bogues se retrouvent dans le produit final. En fait, les entreprises du domaine des jeux vidéo sont souvent très sévères au niveau des dates limites pour sortir un jeu et seuls les cas critiques peuvent retarder sa sortie. On sépare alors les bogues en quatre catégories différentes selon la sévérité de chacun d’entre eux pour s’assurer que les plus importants ne se retrouvent pas sur le marché (Levy et Novak, 2010).

— Priorité faible : Les bogues de cette catégorie ne font aucune différence pour l’équipe de développement, qu’ils soient réglés ou non. Ces derniers peuvent varier de petites erreurs graphiques ou sonores à des erreurs grammaticales dans l’interface. Les échecs qui n’ont aucun impact sur le déroulement du jeu ou sur la perception du joueur sont de cette catégorie. Ils ont de bonnes chances de se retrouver dans le produit final puisqu’ils n’ont pas de réel impact négatif.
— Priorité moyenne : La différence entre cette catégorie et la précédente repose davantage sur la fréquence d’apparition. Encore une fois, il est souvent question de problèmes graphiques ou sonores, mais qui arrivent régulièrement. Ce sont des échecs qui ne nuisent pas au déroulement du jeu, mais qui peuvent être énervants aux yeux de l’utilisateur. Ces bogues sont souvent réglés vers la fin de la période de tests lorsque les échecs nuisant à l’expérience de jeu ont disparu.
— Priorité élevée : Cette catégorie représente tous les bogues qui affectent énormément le jeu et qui l’empêchent de s’exécuter de la manière désirée. Par exemple, s’il est impossible de sauter alors que le joueur doit normalement pouvoir le faire, on parle d’une priorité élevée. Ces bogues doivent être réglés rapidement et ne doivent pas se retrouver sur le marché.
— Priorité critique : Ces bogues demandent une attention immédiate de tous les développeurs. Il n’est pas question d’échecs nuisant au déroulement du jeu, mais de ceux qui empêchent tout simplement de jouer comme une corruption des données ou si le jeu cesse de fonctionner soudainement. Le travail sur tous les autres éléments s’arrête afin de trouver une solution.

C’est en prenant en compte de ces informations qu’il est possible, pour les testeurs, de bien effectuer leur travail.

Table des matières

1 Introduction 
2 Les tests dans les jeux vidéo
2.1 Les bogues dans les jeux vidéo
2.2 Déroulement des tests
2.3 Outils de tests
2.4 Problèmes reliés aux tests
3 Le runtime monitoring 
3.1 Définition du monitoring
3.2 Justification
3.3 Langages formels de spécification
3.4 Fonctionnement du runtime monitoring
4 Expérimentations 
4.1 Le moniteur BeepBeep
4.2 Méthode d’instrumentation dans les jeux vidéo
4.3 Jeux vidéo étudiés
4.4 Statistiques liées aux expérimentations
5 Conclusion

Télécharger le rapport complet