Projet tuteuré – 2 e année 1 Encadré par : Gaëtan Rey Chef de projet : Romain Guillot Développeurs : Benjamin Lissillour, Didier Martini, Gauthier Cibert—Volpé, Guillaume Dalichamp, Jonathan Roux, Laurent Cavallini, Nicolas Gauche
Sommaire Présentation du jeu Présentation des besoins Environnement de développement Moteur IHM Joueur Virtuel Intégration Validation Organisation du projet Bilan et perspectives 2
Présentation du jeu Jeu de cartes créé par Lutz Stepponat Edité en 2007 par Filosofia De 2 à 6 joueurs 3 But du jeu : Remporter plus de points que ses adversaires. Les points s’obtiennent en remportant des cartes objectifs.
Éléments de vocabulaire 4 Carte Objectif Carte InfluenceColonne
Vidéo du déroulement d’une partie 5
Présentation des besoins 6 o Les besoins principaux : B1 : Porter le jeu de carte « De Cape & d’ Épée » sur support PixelSense. B2 : Veiller au bon déroulement d’une partie. B3 : Permettre à des joueurs virtuels de se substituer à des joueurs réels. o Les besoins optionnels : B4 : Geler et restaurer le contexte. B5 : Mettre en œuvre des éléments multimédia. B6 : Permettre l’ajout de fonctionnalités annexes par l’utilisateur.
Les impositions de conception 7 Design pattern Modèle-Vue-Contrôleur Table tactile PixelSense Développement en C# Système SVN pour la gestion des versions du projet
Microsoft PixelSense Caractéristiques Système d’exploitation Windows 7 – 64 bits Définition1920*1080 ProcesseurAthlon X2 Dual-Core à 2.9 GHz Surface d’affichage900 * 500 mm
Logiciels utilisés 9 Visual Paradigm 9 Visual Studio 2010 SDK Surface Input Simulator PhotoShop Resharper Nlog SWI Prolog
Architecture du projet 10 Contrôleur Moteur IHM Joueur Virtuel Contrôleur JV Contrôleur
Présentation du moteur 11 Responsable du lot moteur : Romain Guillot Développeurs : Romain Guillot, Nicolas Gauche Contrôleur Moteur IHM Joueur Virtuel Contrôleur JV Contrôleur
Besoins o Le moteur de jeu répond aux besoins suivants : B1 : Porter le jeu de carte «De Cape & d'Épée» sur support PixelSense. B2 : Veiller au bon déroulement d’une partie. B4 : Geler et restaurer le contexte. 12
Fonctions F1 : Permettre à un utilisateur de démarrer une partie (B1, B2) F2 : Donner la main à un joueur (B1, B2) F6 : Permettre à un joueur de jouer une carte (B1, B2) F7 : Désigner un joueur gagnant (B1, B2) F9 : Permettre aux joueurs de stopper une partie pour la reprendre plus tard (B4) F10 : Permettre aux joueurs de visualiser l’historique des coups joués (B6) 13
14 Conception
Classe Plateau 15
Classe Effet 16
Documents produits Protocole d’échange Moteur-IHM : Dictionnaires Protocole d’échange Moteur-JV : Flux XML 17 ….
Résultat 18 o Difficultés rencontrées : Gestion de la faible puissance de la table PixelSense Gestion multi-cœurs o Quantification de la réalisation o 20 classes 4800 lignes de code dont 30% de commentaires 3 de complexité moyenne par méthode Environ 200 tests unitaires réalisés
Présentation de l’IHM 19 Responsable du lot IHM: Didier Martini Développeurs : Didier Martini, Laurent Cavallini, Gauthier Cibert--Volpe Moteur IHM Joueur Virtuel Contrôleur JV Contrôleur
Besoins et fonctions o Besoins associés à l’IHM: B1 : Porter le jeu de carte «De Cape & d'Épée» sur support PixelSense. B5 : Mettre en œuvre des éléments multimédia lors de l’application des effets des cartes Influence pour les joueurs. o Principales fonctions associées à l’IHM: F1 : Permettre à un utilisateur de démarrer une partie F3 : Permettre à un joueur et à lui seul, de visualiser sa main F4 : Afficher un plateau de jeu pour les joueurs F5 : Afficher une zone personnelle pour les joueurs F6 : Permettre à un joueur de jouer une carte F11 : Afficher des animations lors de l’application des effets 20
Étude de l’existant 21
Problèmes rencontrés 22 Découverte du WPF : du C# couplé au XAML Nécessité d’adapter rapidement le code au fur et à mesure de l’apprentissage du SDK surface 2.0 Dimensions de la table Comment cacher les cartes de la main? Performances Émulation de la table PixelSense Gestion des threads
Plateau de jeu 23 Comment afficher le maximum de cartes dans une colonne? Main :
Main 24 Comment cacher ses cartes des autres joueurs ?
Main 25 Comment jouer une carte dans une colonne ?
Autres fonctionnalités 26 Thèmes : Visuels Audio Chargement / sauvegarde de partie Rangement du plateau
Résultats 27 o Éléments produits: Document d’analyse IHM Code source de l’IHM Classe d’interface entre le moteur et l’IHM Images servant à l’IHM Configuration de la table PixelSense o Quantification: 26 classes 3500 lignes de codes Complexité par méthode : 1,7
Présentation du joueur virtuel 28 Responsable du lot joueur virtuel : Jonathan Roux Développeurs : Jonathan Roux, Benjamin Lissillour, Guillaume Dalichamp Moteur IHM Joueur Virtuel Contrôleur JV Contrôleur
o Besoins associés au joueur virtuel : B3 : Permettre à un (des) joueur(s) virtuel(s) de se substituer à un (des) joueur(s) réel(s) B6 : Permettre l’ajout de fonctionnalités annexes par l’utilisateur o Principales fonctions associés au joueur virtuel: F8 : Permettre à un utilisateur d’ajouter à la partie un ou plusieurs joueurs virtuels (B3) F12 : Permettre à un joueur réel débutant d’être assisté virtuellement (B6) 29 Besoins et fonctions
Type d’algorithme o Explication choix de l’algorithme Etude des différentes approches : Algorithme de types arbres Algorithme par renforcement Système expert o Choix définitif Système expert – SWI-Prolog Initiation au langage (Prolog) Réflexion rapide et flexible Transparence du raisonnement 30
Conception o Objectifs Réaliser le couplage C#/Prolog Pouvoir traiter l’ensemble du plateau comme un joueur réel o Solutions Librairie SwiPlCs Modéliser l’état du plateau 31
Difficultés rencontrées o Difficultés Désistement des joueurs experts Aucun joueur ne s’est considéré « expert » Librairie SwiPlCs défaillante Problème de gestion mémoire Méthode « dépréciée » 32 o Solutions Conception de nos règles « expertes » Réalisation complète d’une nouvelle librairie
Performances 33 Implémentation d’un joueur difficile performant !
Quantification & Résultats o Résultats : 2 joueurs de niveaux différents Une librairie de couplage complète o Codes produits : 600 lignes de code C# 120 tests unitaires des classes C# 4 de complexité moyenne par méthode 30% de commentaires 400 lignes de Prolog 60 tests unitaires de la Base de connaissances o Documents produits : Document d’analyse des algorithmes Questions pour les experts Conception de classe et des règles « expertes » 34
Intégration o Difficultés : Couplage C#/swi-prolog Mauvaise gestion de la mémoire Sur utilisation d’un même cœur du processeur pour les calculs du moteur Ralentissement de l’IHM o Solutions : Refonte du couplage C#/swi-prolog Répartition en multi-cœurs et threads parallèles 35
Validation 36 Type (Action ou Check) Descriptif ActionCharger le contexte Action Le premier joueur choisi une carte et une colonne Action Le deuxième joueur choisi une carte et choisi la même colonne que le premier joueur Check Vérifier que la carte au dessus F6_E6 : Appliquer l'effet de la carte précédente s'il est immédiat
Validation 37 o Difficultés : Moteur très peu « maniable » Impossible de le faire avancer pas à pas Impossible d’exécuter les scripts tel qu’ils étaient prévus o Solutions : Classe Script Concept de point d’arrêt Modifications à faire dans le moteur
Cycle de développement 38 Spécifications Conception détaillée Programmation Intégration Tests Unitaires Conception générale Validation
Diagramme prévisionnel 39 Tests Moteur IHM Joueur virtuel
Diagramme final 40 Tests Moteur IHM Joueur virtuel
41 Bilan des fonctionnalités présentes Installateur du jeu Jeu rapide et fonctionnel Mise en pause Sauvegarde/Chargement du jeu Modification des thèmes visuels Déplacements visuels des cartes Joueur virtuel expert Joueur virtuel aléatoire
42 Perspectives et avenir Création d’une dll avec l’interface C# SWI prolog Amélioration de l’ergonomie avec des tests sur utilisateurs Nouveaux effets visuels/sonores pour les effets des cartes Créer de nouveaux thèmes dont un ou plusieurs Open Source afin de pouvoir diffuser le jeu Ajout de plusieurs niveaux de joueur virtuel Ajout d’un joueur virtuel assistant Permettre au joueur de choisir la façon dont l’on compte ses points en fin de partie Présenter le projet au salon du jeu de Cannes
43 Remerciement Nous remercions Gaëtan Rey pour nous avoir permis de réaliser ce projet et nous avoir encadré pendant toute sa durée. Le laboratoire I3S pour le prêt de la table PixelSense. Merci pour votre attention ! Place à la démonstration du jeu.