création d’une communauté web scénarisée : le projet crealys réalisé par le tp 222...

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

Crealys

Réalisé par le TP 222Enseignant responsable : Mr

Laubin

Introduction Générale

Définition : Qu’est ce qu’un site web scénarisé ?

A quoi servirait un tel projet ?

Pourquoi un projet ?

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

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

Amélioration de l’éditeur de carte

Adaptation du client java en client flash

Développement de l’import/export XML

Nous avons travaillé sur

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

Serveur Java

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

Éditeur de scénario

Pong 3D

Création de Plugins

Le projet Crealys est notre thème principal mais pas notre objectif premier :

On créé des outils Crealys est un jeu d’essai

But du projet

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

Découpage des tâches

Vers la réalisation

Analyse et diégèse finis

Éclatement des équipes

Coordination par Pierrick

Plan général de la soutenance

I – Conception

II – Réalisation

III - Réalisation

I.1 - Analyse des sites web existants

Par M.RAKOTOARISOA

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

Introduction L’analyse des sites existants :

« Une phase obligatoire est prépondérante à l’élaboration du projet »

En quoi consiste-elle?

Ses objectifs

Plan

I. Les moyens mis en œuvre pour effectuer cette recherche?

II. Les résultats

I. Moyens mis en œuvre

1. Outils2. Analyser des sites variés3. Recherche par thèmes4. La fiche méthode

Nom du site Lien Capture d’écran Points positifs et négatifs du site

Fiche méthodologique

Plan

1. Les moyens mis en œuvre pour effectuer cette recherche?

2. Les résultats

II. Les résultats Deux sites intéressants :

1. Au niveau de l’ambiance : Dofus.org

II. Les résultats Deux sites intéressants :

1. Au niveau de l’ambiance Dofus.org

2. Au niveau du scénario (Jeu en lui-même)

Pepsitown.com

La fiche synthétique Voici les principaux points

développés dans cette fiche synthétique :

1. Au niveau du site2. Au niveau du jeu en lui-même3. Au niveau conception

Conclusion Partie analyse très riche :

1. Au niveau personnel2. Au niveau du groupe

I.3 - Définition de la charte graphique

Par Dieter Gorecki


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

Introduction

Étape indispensable pour définir l’ambiance générale du site

Permet de « restreindre » la partie de recherche de la partie technique

I. Moyens

Répartition des taches

Étude de l’existant

II. Résultat

Intégration des différents éléments graphiques du site

Définition et répartition des couleurs selon les quartiers

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 :

II. Résultat

II. Résultat

Définition de la palette des couleurs à utiliser pour la création des personnages

III. Utilité

Respect de la charte graphique

Utilisation des éléments

Conclusion

Document a réaliser rapidement

Capacités graphiques / Imagination

I.4 - Partie UML : Modélisation du projet

Par Pierre Collin


I – Conception I.1 – Analyse des sites web

existant I.2 – Diégèse I.3 – Charte Graphique I.4 – Analyse UML

Introduction : Notre réflexion

Ancien projet

Bible

Réadaptation pour notre site

Utilisation de nos connaissances personnelles

Plan

I. La partie Carte

II. La partie Personnage

III. La partie Scénario

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

I. La partie Carte

II. La partie Personnage

Les joueurs

Les Personnages non joueurs

Choix de modélisation :- classe personnage

III. La partie Scénario

Description générale

Amélioration - Passage en UML- Création de la classe Groupe

Conclusion

Difficultés rencontrées

Vérification de la cohérence de la Bible

Création des tables de la bases de données

II.1 - Partie Éditeur de scénario

Par Julien Vielet


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

Introduction

Le langage Zébra Writer

Étude de l’existant- Le projet PrehistorikQuest

Fonctionnalités ajoutées à l’existant

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

I. Le Langage Zébra Writer Automate

Passage d’un état à un autre

Matrice d’adjacence associée A BA 0 xB 0 0

A B x

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

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

Étude syntaxique

Structure du programme (Diagramme de classe)

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

Conclusion

Difficulté à reprendre du code insuffisamment commenté

Ajout de nouvelles fonctionnalités

II.2 - L’éditeur de cartes

Olivier DICK – TP 222

Position au sein du projet



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

Introduction

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

Introduction

Objectifs :

Reprendre l’éditeur précédentL’améliorer et l’adapter à nos

besoins Le rendre accessible à tous.

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

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

1 - Analyse de l’éditeur 1.4 - Points positifs

Une structure qui marche

Notion d’explorateur de cases assez performant

1 - Analyse de l’éditeur

Éditeur « Rabbit’s Revenge »

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

2 - Adaptation/Apport 2.2 - Structure des fichiers

2 - Adaptation/Apport

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…

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

3 - Bilan 3.1 – Actuellement

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

Conclusion Éditeur = outils indispensable pour

la création d’une communauté…

En accord avec les autres outils, affichage de cartes notamment

II.3 - Serveur Java : Analyse

Par Maxence Barety

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

Plan

I - Etude de PrehistorikQuest

II – Etude de BlablaChat

I. Étude de PrehistorikQuest

1. Description du projet

2. La classe ServeurPrehistorik

3. La classe GestionClient

4. Analyse

II. Etude de BlablaChat

1. Description du projet2. BlablaServ.java3. BlablaThread.java4. Commandes.java5. Analyse

Conclusion

Base pour la création du serveur de notre projet

Cependant, des ajustements sont nécessaires

II.4 - Serveur Java : Programmation

Par Thomas du Boÿs

Introduction

Qu'est-ce qu'un serveur?

Quels tâches lui sont demandées?

Plan I - Ce qui nous était demandé

II - Les choix que l'on a fait

III - Fonctionnement du serveur

IV - Évolutions possibles

I. Ce qui nous était demandé

1. Gestion des clients

2. Fournisseur d'informations

3. Correspondance entre les clients pour le chat pour les déplacements pour le pong

II. Les choix que l'on a fait

1. Utilisation d'un seul port Souci de sécurité

2. Structure en 3 classes “threadées” Gestion aisée et individuelle des clients Gestion de différentes taches de manière

simultanée

3. Optimisation des données transmises Envoi minimum des données de

déplacement

III. Fonctionnement du serveur

1. Une classe gérant la base

2. Un objet par client

3. Un thread pour les commandes

IV. Évolutions possibles1. Facilité d'ajout de commandes

2. Facilité d'ajout de types de messages à gérer

En cas d'ajout d'une fonctionnalité dans le client (exemple du pong)

3. Portabilité du java Sur différentes plateformes Sur différentes bases de données

Conclusion

Serveur facilement utilisable

Serveur facilement adaptable à d'autres projets

Outil simple et pédagogique

Par Gabriel Rosset

II.5 - Flash : Possibilités

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

Introduction

Prise en main de Flash

Étude d’un tutorial existant

I. Interpolation de mouvement

Clip constitué d’une suite d’images

Les éléments graphiques

Les symboles

II. Interpolation de forme

Effets indésirables

Nécessité de décomposer la transformation

Outil de sous sélection

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

III. Un exemple simple

IV. Création de clip en dynamique

Solution abandonné à cause d’erreur d’instanciation

Les clips sont inclus statiquement dans le client

V. Établissement des dictionnaires

Utilisation d’un dictionnaire de terrains

Utilisation d’un dictionnaire d’éléments

Précision sur la forme des balises

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"/>

Conclusion

Prise en main rapide grâce à un très bon tutorial

Flash gère les erreurs de code de manière peu efficace

Par Éric Wajcman

II.6 - Client Flash



Programmation II.5 – Flash : Possibilités II.6 – Client Flash : Import

XML

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

I. Travaux préliminaires

Test des Outils existants

Analyse d’un tutorial de déplacement en 2D sous flash

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 32Lx24HMur 32Lx32H


Le Personnage Objet contrôlé par le clavier Test de collision Vitesse de déplacement multiple de la

taille des cases


Le Personnage 8 directions 3 positions par direction


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

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

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

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

Petit aperçu

III.1 - Présentation du site web

Matthieu VAN ERKELENS


III - Intégration III.1 – Site web III.2 – Pong 3D

Descriptif sur la création du Site Web CREALYS Respect de la norme

http://www.w3.org/1999/xhtml Création de feuille de style Fichier PHP Lien vers une base de donnée

distante pour gérer la communauté

Règlement Intérieur Le site suit 2 principes instaurés

par la Bible :

Règles de gestion à appliquer aux jeux

Règles judiciaires

Formulaire d’inscription

Création du compte dans la base de donnée

Liste des Membres Mise à disposition des informations

des membres inscrit dans la communauté

Connexion à la base de donnée

Identification Connexion à la base de donnée

pour s’authentifier sur le site

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

III.2 – Pong 3D

Par Delafoy Sylvain


III - Intégration III.1 – Site web III.2 – Pong 3D

Introduction

Pong 3D, Pourquoi?

Avec quoi?

Les origines.

Pong 3D : Plan

Exemple de partie

Le fonctionnement sous jacent L'initialisation Les rôles des deux clients. Les cas spéciaux Les échanges

Exemple de partie Début du jeu

Exemple de partie Point marqué

Exemple de partie

Coté gagnant Coté perdant

Fin de partie

Le fonctionnement sous jacent

L’initialisation Les variables Les graphismes


Les rôles des deux clients L 'agresseur La victime


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

Le fonctionnement sous jacent Les échanges

Sockets Format XML Uniquement les données essentielles.

Position de la raquette des joueurs. Balle. Score en cours.

Conclusion

Un excellent moteur graphique.

Une mise en réseau laborieuse.

Par Pierrick Girard

Gestion du Projet


Gestion du Projet Conclusion

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).

Exemple

Gestion du projet

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

Par Pierrick Girard

Conclusion Générale

Conclusion générale

Suivi grâce au diagramme de GANTT Retard du client flash Avance du serveur java

Objectif initial atteint Base solide

Conclusion générale

Expérience enrichissante pour chacun Travail collectif Problèmes de communication Motivation et capacité d’adaptation

aux contraintes

création d’une communauté web scénarisée : le projet crealys réalisé par le tp 222...

Documents