Création d’une communauté web scénarisée : le projet Crealys

Présentation au sujet: "Création d’une communauté web scénarisée : le projet Crealys"— Transcription de la présentation:

1 Création d’une communauté web scénarisée : le projet Crealys
Réalisé par le TP 222 Enseignant responsable : Mr Laubin

2 Introduction Générale
Définition : Qu’est ce qu’un site web scénarisé ? A quoi servirait un tel projet ? Pourquoi un projet ?

3 C’est un espace entre… Un forum, comme par exemple celui de Hardware.fr

4 Et entre… Un jeu de rôle en ligne, par exemple Grey

5 Nous avons travaillé sur
Amélioration de l’éditeur de carte Adaptation du client java en client flash Développement de l’import/export XML

6 Serveur Java Serveur java : amélioration de celui d’un ancien projet

7 Éditeur de scénario Amélioration de l’éditeur de scénario existant

8 Création de Plugins Pong 3D

9 But du projet Le projet Crealys est notre thème principal mais pas notre objectif premier : On créé des outils Crealys est un jeu d’essai

10 Découpage des tâches Conception (environ 1 mois)
Réalisation (environ 1 mois) Intégration (environ 15 jours) Selon le modèle présenté par Mr Laubin, chaque étudiant a été répartit dans une partie

11 Vers la réalisation Analyse et diégèse finis Éclatement des équipes
Coordination par Pierrick

12 Plan général de la soutenance
I – Conception II – Réalisation III - Réalisation

13 I.1 - Analyse des sites web existants
Par M.RAKOTOARISOA

14 Situation dans le plan I – Conception
I.1 – Analyse des sites web existants I.2 – Diégèse I.3 – Charte graphique I.4 – Analyse UML

15 Introduction L’analyse des sites existants : En quoi consiste-elle?
« Une phase obligatoire est prépondérante à l’élaboration du projet » En quoi consiste-elle? Ses objectifs

16 Plan I. Les moyens mis en œuvre pour effectuer cette recherche?
II. Les résultats

17 I. Moyens mis en œuvre Outils Analyser des sites variés
Recherche par thèmes La fiche méthode Nom du site Lien Capture d’écran Points positifs et négatifs du site

18 Fiche méthodologique

19 Plan 1. Les moyens mis en œuvre pour effectuer cette recherche?
2. Les résultats

20 II. Les résultats Deux sites intéressants : Au niveau de l’ambiance :
Dofus.org

21

22 II. Les résultats Deux sites intéressants : Au niveau de l’ambiance
Dofus.org Au niveau du scénario (Jeu en lui-même) Pepsitown.com

23

24 La fiche synthétique Voici les principaux points développés dans cette fiche synthétique : Au niveau du site Au niveau du jeu en lui-même Au niveau conception

25 Conclusion Partie analyse très riche : Au niveau personnel
Au niveau du groupe

26 I.3 - Définition de la charte graphique
Par Dieter Gorecki

27 Situation dans le plan I – Conception
I.1 – Analyse des sites web existants I.2 – Diégèse I.3 – Charte Graphique I.4 – Analyse UML

28 Introduction Étape indispensable pour définir l’ambiance générale du site Permet de « restreindre » la partie de recherche de la partie technique

29 I. Moyens Répartition des taches Étude de l’existant

30 II. Résultat Intégration des différents éléments graphiques du site
Définition et répartition des couleurs selon les quartiers

31 II. Résultat

32 II. Résultat Création de bâtiments déclinés selon les différentes couleurs Choix de la police de caractère utilisée pour le jeu :

33 II. Résultat Définition de la palette des couleurs à utiliser pour la création des personnages

34 III. Utilité Respect de la charte graphique Utilisation des éléments

35 Conclusion Document a réaliser rapidement
Capacités graphiques / Imagination

36 I.4 - Partie UML : Modélisation du projet
Par Pierre Collin

37 Situation dans le plan I – Conception
I.1 – Analyse des sites web existant I.2 – Diégèse I.3 – Charte Graphique I.4 – Analyse UML

38 Introduction : Notre réflexion
Ancien projet Bible Réadaptation pour notre site Utilisation de nos connaissances personnelles

39 Plan La partie Carte La partie Personnage La partie Scénario

40 I. La partie Carte Le Monde Le Quartier : - capitale - bâtiment public
- bâtiment privé Les cases : - un terrain - un élément de décor

41 I. La partie Carte

42 II. La partie Personnage
Les joueurs Les Personnages non joueurs Choix de modélisation : - classe personnage

43 III. La partie Scénario Description générale Amélioration
Passage en UML Création de la classe Groupe

44 Conclusion Difficultés rencontrées
Vérification de la cohérence de la Bible Création des tables de la bases de données

45 II.1 - Partie Éditeur de scénario
Par Julien Vielet

46 Situation dans le plan II – Réalisation II.1 – Éditeur de Scénario
II.2 – Éditeur de Carte II.3 – Serveur Java : Analyse II.4 – Serveur Java : Programmation II.5 – Flash : Possibilités II.6 – Client Flash : Import XML

47 Introduction Le langage Zébra Writer Étude de l’existant
- Le projet PrehistorikQuest Fonctionnalités ajoutées à l’existant

48 I. Le Langage Zébra Writer
Syntaxe d’un scénario Fragments Différents éléments BEGIN FR n°scénario – Type – Mode d’activation – Nom de fragment [>>canaux de sortie] [<<canaux d’entrée] - Groupe de fragment 1 - - Groupe de fragment 2 - … - Groupe de fragment n-1 - - Groupe de fragment n - <? condition d’exécution en fonction du vecteur d’état> Bloc d’instruction conditionné </?> Bloc d’instruction non conditionné END

49 I. Le Langage Zébra Writer
Automate Passage d’un état à un autre Matrice d’adjacence associée A B A 0 x B 0 0 x A B

50 II. Étude de l’éditeur préexistant
But de l’éditeur

51 II. Étude de l’éditeur préexistant
Étude syntaxique Structure du programme (Diagramme de classe)

52

53 III. Fonctionnalités ajoutées
Ouvrir un fichier Fermer un ou plusieurs fichiers Enregistrer un fichier Imprimer un document en couleur Lancer un site Internet d’aide en ligne Configurer les fichiers de données

54 Conclusion Difficulté à reprendre du code insuffisamment commenté
Ajout de nouvelles fonctionnalités

55 II.2 - L’éditeur de cartes
Olivier DICK – TP 222

56 Position au sein du projet
II – Réalisation II.1 – Éditeur de Scénario II.2 – Éditeur de Carte II.3 – Serveur Java : Analyse II.4 – Serveur Java : Programmation II.5 – Flash : Possibilités II.6 – Client Flash : Import XML

57 Introduction Qu’est ce qu’un éditeur de carte ?
Permet la génération d’environnement 2D Assemblage de cases Création d’une nouvelle carte Sauvegarde de la création Reprise de la carte Ajout de textures personnelles

58 Introduction Présentation finale de l’éditeur – Carte: Ville.xml créé par Olivier Dick

59 Introduction Objectifs : Reprendre l’éditeur précédent
L’améliorer et l’adapter à nos besoins Le rendre accessible à tous.

60 Sommaire 1 - Analyse d’un éditeur de carte 2 - Adaptation/Apport
3 - Bilan

61 1 - Analyse de l’éditeur 1.1 - Nombreux problèmes
Pas de génération de nouvelles cartes Pas de sauvegarde de cartes fonctionnelle Rafraîchissement pénible 1.2 - Pas convivial. Créé pour les développeurs 1.3 - Notion de fichier carte à redéfinir

62 1 - Analyse de l’éditeur 1.4 - Points positifs
Une structure qui marche Notion d’explorateur de cases assez performant

63 Éditeur « Rabbit’s Revenge »
1 - Analyse de l’éditeur Éditeur « Rabbit’s Revenge »

64 2 - Adaptation/Apport 2.1-Redéfinition du format d’import/export
Format XML choisit, pour remplacer le système primaire initial Mise en place de dictionnaires de cases

65 2 - Adaptation/Apport 2.2 - Structure des fichiers

66 2 - Adaptation/Apport

67 2 - Adaptation/Apport

68 2 - Adaptation/Apport 2.3 – L’ouverture de fichiers
Utilisation du parseur SAX Chargement dynamique des dictionnaires Puis chargement d’une carte (fichier) 2.4 – La génération de nouvelle carte A partir d’un nom et d’une taille 2.5 – La sauvegarde de carte Écriture brute, pas de parseur Formatée en XML, bien sur…

69 2 - Adaptation/Apport 2.6 – Importation de cases
Terrains et éléments à partir d’un nom et d’une texture Ajout aux dictionnaires 2.7 – Amélioration de la convivialité Ajout d’explorateur de fichiers Création/Ouverture de cartes dans l’éditeur Rafraîchissement de l’écran

70 3 - Bilan 3.1 – Actuellement 3.2 – Ce qui peut être fait
Logiciel simple, fonctionnel et stable En accord avec la définition d’un éditeur 3.2 – Ce qui peut être fait Suppression de cases des dictionnaires Adaptation WYSIWYG

71 Conclusion Éditeur = outils indispensable pour la création d’une communauté… En accord avec les autres outils, affichage de cartes notamment

72 II.3 - Serveur Java : Analyse
Par Maxence Barety

73 Situation dans le plan II – Réalisation II.1 – Éditeur de Scénario
II.2 – Éditeur de Carte II.3 – Serveur Java : Analyse II.4 – Serveur Java : Programmation II.5 – Flash : Possibilités II.6 – Client Flash : Import XML

74 Introduction Étape préliminaire pour la création du serveur utilisé pour notre projet Étude de 2 projets existants : - le projet PrehistorikQuest - le projet BlablaChat

75 Plan I - Etude de PrehistorikQuest II – Etude de BlablaChat

76 I. Étude de PrehistorikQuest
Description du projet La classe ServeurPrehistorik La classe GestionClient Analyse

77 II. Etude de BlablaChat Description du projet BlablaServ.java
BlablaThread.java Commandes.java Analyse

78 Conclusion Base pour la création du serveur de notre projet
Cependant, des ajustements sont nécessaires

79 II.4 - Serveur Java : Programmation
Par Thomas du Boÿs

80 Situation dans le plan II – Réalisation II.1 – Éditeur de Scénario
II.2 – Éditeur de Carte II.3 – Serveur Java : Analyse II.4 – Serveur Java : Programmation II.5 – Flash : Possibilités II.6 – Client Flash : Import XML

81 Introduction Qu'est-ce qu'un serveur? Quels tâches lui sont demandées?

82 Plan I - Ce qui nous était demandé II - Les choix que l'on a fait
III - Fonctionnement du serveur IV - Évolutions possibles

83 I. Ce qui nous était demandé
Gestion des clients Fournisseur d'informations Correspondance entre les clients pour le chat pour les déplacements pour le pong

84 II. Les choix que l'on a fait
Utilisation d'un seul port Souci de sécurité Structure en 3 classes “threadées” Gestion aisée et individuelle des clients Gestion de différentes taches de manière simultanée Optimisation des données transmises Envoi minimum des données de déplacement

85 III. Fonctionnement du serveur
Une classe gérant la base Un objet par client Un thread pour les commandes

86 IV. Évolutions possibles
Facilité d'ajout de commandes Facilité d'ajout de types de messages à gérer En cas d'ajout d'une fonctionnalité dans le client (exemple du pong) Portabilité du java Sur différentes plateformes Sur différentes bases de données

87 Conclusion Serveur facilement utilisable
Serveur facilement adaptable à d'autres projets Outil simple et pédagogique

88 II.5 - Flash : Possibilités
Par Gabriel Rosset

89 Situation dans le plan II – Réalisation II.1 – Éditeur de Scénario
II.2 – Éditeur de Carte II.3 – Serveur Java : Analyse II.4 – Serveur Java : Programmation II.5 – Flash : Possibilités II.6 – Client Flash : Import XML

90 Plan I - Analyse de l’existant II - Possibilités de Flash
Interpolations Transparence, profondeur Création dynamique de clip III - Élaboration des dictionnaires Dictionnaire des terrains Dictionnaire des éléments

91 Introduction Prise en main de Flash Étude d’un tutorial existant

92 I. Interpolation de mouvement
Clip constitué d’une suite d’images Les éléments graphiques Les symboles

93 II. Interpolation de forme
Effets indésirables Nécessité de décomposer la transformation Outil de sous sélection

94 III. Profondeur et transparence
Transparence gérée par le format PNG Espacement des profondeurs indispensable à l’affichage Attribution dynamique de la profondeur pour le personnage

95 III. Un exemple simple

96 IV. Création de clip en dynamique
Solution abandonné à cause d’erreur d’instanciation Les clips sont inclus statiquement dans le client

97 V. Établissement des dictionnaires
Utilisation d’un dictionnaire de terrains Utilisation d’un dictionnaire d’éléments Précision sur la forme des balises

98 Exemples de balises <elements nbelements="30">
<element ref="0" bloquant="false" typeelement="vide" img="ELEMENTS\vide.png" /> <typesterrain nbterrain="79"> <typeterrain ref="0" nom="terrain" praticable="false" img="CASES\terrain.png"/>

99 Conclusion Prise en main rapide grâce à un très bon tutorial
Flash gère les erreurs de code de manière peu efficace

100 II.6 - Client Flash Par Éric Wajcman

101 Situation dans le plan II – Réalisation II.1 – Éditeur de Scénario
II.2 – Éditeur de Carte II.3 – Serveur Java : Analyse II.4 – Serveur Java : Programmation II.5 – Flash : Possibilités II.6 – Client Flash : Import XML

102 Objectifs Gérer la cohésion des travaux effectués dans le groupe technique Analyser outils existants des années précédentes Trouver d'autres outils adaptables à nos besoins Modifier les outils sélectionnés et les adapter Étude d’un tutorial existant

103 I. Travaux préliminaires
Test des Outils existants Analyse d’un tutorial de déplacement en 2D sous flash

104 I. Travaux préliminaires : Tutorial
La carte Tableau 2D rempli de 0 et 1(sol et mur) Des images superposées Profondeur pour chaque duplication des cases Une case possède toutes les images possibles des cases Sol 32Lx24H Mur 32Lx32H

105 I. Travaux préliminaires : Tutorial
Le Personnage Objet contrôlé par le clavier Test de collision Vitesse de déplacement multiple de la taille des cases

106 I. Travaux préliminaires : Tutorial
Le Personnage 8 directions 3 positions par direction

107 I. Travaux préliminaires : Tutorial
Une vraie carte La taille des cartes multiple de la taille d’écran (16x16) Transitions d’un écran à l’autre lorsqu’on atteint un bord On calcule la position du personnage avec la potion de carte affichée

108 II. Réalisation pour le projet
Le XML Une norme commune pour le stockage des cartes et des dictionnaires Chargement des dictionnaires Chargement de la carte courante Lors des déplacements des fonctions testent si les cases « visées » sont praticables

109 II. Réalisation pour le projet
Les Images But de départ : importation dynamique des images en fonction des besoins Problème rencontré : impossibilité d’importer les images comme nous le voulions Solution : importation manuelle des images : Utilisation d’un calque avec un cadre Utilisation des outils de flash pour l’alignement des images

110 III. Finalisation et Améliorations
Chargement des fichiers xml, mouvements et animations Possibilité d’afficher d’autres personnages prévus (pas fini) Communication avec le serveur pas encore au point

111 Petit aperçu

112 III.1 - Présentation du site web
Matthieu VAN ERKELENS

113 Situation dans le plan III - Intégration III.1 – Site web
III.2 – Pong 3D

114 Descriptif sur la création du Site Web CREALYS
Respect de la norme Création de feuille de style Fichier PHP Lien vers une base de donnée distante pour gérer la communauté

115 Règlement Intérieur Le site suit 2 principes instaurés par la Bible :
Règles de gestion à appliquer aux jeux Règles judiciaires

116 Formulaire d’inscription
Création du compte dans la base de donnée

117 Liste des Membres Mise à disposition des informations des membres inscrit dans la communauté Connexion à la base de donnée

118 Identification Connexion à la base de donnée pour s’authentifier sur le site

119 Autres fonctions du site
Lien vers l’application Flash Intégration sous peu Mise à disposition de news pour donner des infos au visiteur du site

120 III.2 – Pong 3D Par Delafoy Sylvain

121 Situation dans le plan III - Intégration III.1 – Site web
III.2 – Pong 3D

122 Introduction Pong 3D, Pourquoi? Avec quoi? Les origines.

123 Pong 3D : Plan Exemple de partie Le fonctionnement sous jacent
L'initialisation Les rôles des deux clients. Les cas spéciaux Les échanges

124 Exemple de partie Début du jeu

125 Exemple de partie Point marqué

126 Exemple de partie Fin de partie Coté gagnant Coté perdant

127 Le fonctionnement sous jacent
L’initialisation Les variables Les graphismes

128 Le fonctionnement sous jacent
Les rôles des deux clients L 'agresseur La victime

129 Le fonctionnement sous jacent
Les cas spéciaux L'absence de réseau Le refus de la victime La victime occupée.

130 Le fonctionnement sous jacent
Les échanges Sockets Format XML Uniquement les données essentielles. Position de la raquette des joueurs. Balle. Score en cours.

131 Conclusion Un excellent moteur graphique.
Une mise en réseau laborieuse.

132 Gestion du Projet Par Pierrick Girard

133 Situation dans le plan Gestion du Projet Conclusion

134 Gestion du projet La méthode PERT
Outil de planification et d’optimisation des tâches Tableau des antériorités Représentation sous forme de Graphe La lettre définit l’opération codée Le chiffre correspond à sa durée (minute, heure, jour, mois) La flèche indique le sens de l’exécution (de gauche à droite habituellement).

135 Exemple

136 Gestion du projet Le diagramme de GANTT Application du réseau PERT
Gestion des ressources et coûts

137 Conclusion Générale Par Pierrick Girard

138 Conclusion générale Suivi grâce au diagramme de GANTT
Retard du client flash Avance du serveur java Objectif initial atteint Base solide

139 Conclusion générale Expérience enrichissante pour chacun
Travail collectif Problèmes de communication Motivation et capacité d’adaptation aux contraintes