PROJET TOWER DEFENDER UCP ANNEE 2013/2014. Plan de test 26/02/2014. Equipe : Responsable liaison jeu/embarqué : Maxime LEBLANC

Transcription

1 PROJET TOWER DEFENDER UCP ANNEE 2013/2014 Plan de test 26/02/2014 Responsable : Tuyêt Trâm DANG NGOC Equipe : Chef de projet : Amélie ALLIX Responsable embarqué : Brice GAULUPEAU Responsable jeu : Amir ABDELAOUI Responsable liaison jeu/embarqué : Maxime LEBLANC 0

2 Table des matières I. Rappel du projet ) Contexte ) Objet... 2 II. Les différents aspects du projet à tester ) La partie embarquée... 3 a) Les composants... 3 b) Le développement embarqué... 3 c) La rotation de la tour... 4 d) La construction de la tour ) La partie tablette... 5 a) Affichage sur la tablette du flux en provenance d une tour... 5 b) Le gameplay ) La partie communication tablette/tour... 6 a) Protocole de communication... 6 b) Le réseau

3 I. Rappel du projet 1) Contexte Le jeu «Tower Defender» a été initié dans le cadre de la première année de Master ISIM SIC au sein de l Université de Cergy-Pontoise. Ce projet a pour but de nous préparer au monde de l entreprise en nous apprenant à mener à bien les différents aspects d un projet à savoir gestion du temps et des moyens (humains, matériels, budgétaire). 2) Objet Le jeu issu du projet se base sur le principe du Tower Defense où l objectif est de défendre une zone contre des vagues successives d ennemis se déplaçant suivant un itinéraire, en construisant et en améliorant progressivement des tours défensives. Dans cette conception, la zone à défendre sera un terrain réel, les ennemis sont en réalité augmentée et les tours seront physiques. Le joueur pourra décider de superviser la partie à l aide d une tablette ou de prendre le contrôle d une tour. 2

4 II. Les différents aspects du projet à tester 1) La partie embarquée Elle prend en compte les tours ainsi que les éléments qui les composent. Dans la partie embarquée, nous devons tester les parties suivantes : Les composants individuels a) Les composants Nous allons tout d'abord tester les composants de manière individuelle, ainsi en utilisant le composant seul avec un circuit de contrôle basique nous pouvons déterminer si le composant réponds à nos attentes, si ce n'est pas le cas, nous pouvons alors changer le composant par un autre similaire. L intégration des composants Ensuite lorsque tous les composants sont choisis, nous allons passer à l'intégration des composants ensemble dans un même circuit, ainsi nous utilisons une carte de prototypage (breadboard) afin de pouvoir faire des modifications rapides sur le circuit si le besoin en est, si les tests ne sont pas concluants, alors nous pouvons changer de composant ou réétudier les interactions entre les composants sur le prototype. L intégration sur une carte imprimée Enfin, lorsque les composants ont étés validés ensembles, nous pouvons passer à l'intégration sur une carte imprimée définitive, si lors de nos tests sur la carte nous nous apercevons d'un problème, il est encore possible de faire des modifications sur la carte afin de résoudre ces problèmes, mais cependant cela est beaucoup plus difficile b) Le développement embarqué Pour la partie développement embarqué, nous devons tester les points suivants : Acquisition de vidéo Premièrement, nous devons tester l'acquisition de la vidéo par la caméra du Rapsberry Pi, pour ce faire nous allons tester l'affichage de la vidéo du Rapsberry sur l'écran relié à celui-ci, et si ça ne fonctionne pas comme nous le souhaitons, alors nous pouvons choisir une autre caméra (webcam USB) ou essayer de changer la manière de lire la vidéo. 3

5 Connexion du Raspberry Pi au réseau Ensuite nous allons tester la connexion du Raspberry Pi au réseau wifi, en connectant le Dongle Wifi USB à un réseau et en testant avec la commande "Ping" ou encore en téléchargeant un fichier d'internet, si la connexion n'est pas fonctionnelle, nous pouvons alors choisir de passer par une connexion filaire. Interaction Raspberry carte de contrôle des moteurs dédiés Enfin nous allons tester l'interaction du Raspberry avec la carte de contrôle des moteurs dédiés en essayant de contrôler les moteurs à partir d'un code simple sur le Raspberry (utilisation du clavier), si il existe des problèmes alors nous pouvons étudier les solutions électroniques (voir ci-dessus) si c'est d'ordre électronique, sinon nous pouvons nous tourner vers une carte électronique que l'on peut trouver déjà conçue (achat sur internet). c) La rotation de la tour Avant toute architecture définitive de la tour, il est important de s assurer que la tour peut effectuer une rotation complète sur elle-même. En effet, pour effectuer une rotation complète différents moyens sont possibles et de ceux-ci dépend en grande partie l architecture de la tour. Il est donc important de tester la rotation horizontale de la tour avant tout mise en production définitive. N.B : concernant la rotation verticale de la caméra un simple test unitaire suffira car les contraintes sont moins élevées. d) La construction de la tour Lors de la production de la tour, il est important de faire des prototypes de la tour afin de vérifier les plans de celle-ci et d éviter tout problème au moment de l assemblage une fois la tour produite. 4

6 2) La partie tablette a) Affichage sur la tablette du flux en provenance d une tour Récapitulatif du scénario (prise de contrôle d une tour) La tour munie d une caméra transmet via un protocole de communication un flux vidéo à la tablette afin que ce qui est perçu par la caméra d une tour soit affiché sur la tablette du joueur. A l image de départ est ajouté les éléments de réalité augmentée. Travaillant au niveau de la tablette et étant donné qu un de nos critères de qualité est la modularité, le test d affichage se fera indépendamment des autres éléments entrant en jeu dans le scénario de prise de contrôle d une tour. Au lieu de prendre comme source vidéo la caméra d une tour, une simulation sera faite avec comme source vidéo celle provenant de la caméra de la tablette. Dans le cadre d une transmission de flux vidéo provenant de la tour, il y aura probablement une conversion RGB aux images prises par la caméra de la tour à effectuer. De ce fait, le test ne sera pas seulement un accès à la caméra de la tablette, mais une conversion des images acquises par celle-ci. Test d intégration : Superposition d un modèle virtuel 3D Le test sera le suivant : chaque tour sera équipée d un marqueur visuel (glyph). Quand la caméra de la tablette aura dans son champ de vision une tour, une superposition d un modèle virtuelle 3D représentant la tour devra s ajouter à l image. b) Le gameplay Le gameplay sera divisé en plusieurs parties afin d optimiser le développement. Test unitaire de chaque partie. Chaque partie subira des tests unitaires afin de les valider. Test d intégration des parties Lorsque nous serons sûrs du bon fonctionnement de chacune des parties, l intégration pourra être effectuée, puis on vérifiera celle-ci pour les différentes parties. Tester que le scénario de gameplay est respecté Une fois les premiers tests effectués nous devrons vérifier qu aucune incohérence scénaristique n est présente : on vérifiera par exemple que si un ennemi atteint la «sortie» une vie est bien retirée au joueur. 5

7 3) La partie communication tablette/tour Afin de valider le bon fonctionnement de la partie communication entre les tablettes et le Raspberry, nous allons procéder à une série de tests. a) Protocole de communication Dans un premier temps nous vérifierons que protocole de communication soit cohérent et adapté à nos besoins. Pour ce faire, nous vérifierons que toutes les commandes ont été prise en compte lors de la définition du protocole et également que le protocole ne soit pas fermé à de nouvelles fonctionnalités. Dans le cas contraire, nous étudierons le protocole de nouveau. Nous étudierons également que les connexions entre les différents éléments s effectue correctement, indépendamment des paramètres IP. b) Le réseau Nous poursuivrons avec une vérification de la qualité du réseau, avec notamment un test de saturation. Nous mesureront les débits de transmission pour obtenir une bande passante suffisante et des temps de latences faible et stable (temps réel). Dans le cas où le débit est trop important, nous pourrons diminuer la résolution de l image et/ou le nombre d images par seconde. Nous réaliserons également des simulations pour nous mesurer le pourcentage de paquets perdus et vérifier qu ils soient bien retransmis jusqu à être bien réceptionné. Si le taux de perte est trop élevé, nous serons amenés à changer l'environnement du jeu, rapprocher les éléments ou rajouter un relais Wifi. 6