Projet n°3 M1 IngéLog 2010/2011

Transcription

Projet n°3 M1 IngéLog 2010/2011
Projet n°3 M1 IngéLog 2010/2011 – Cahier des charges
a. Existant : .......................................................................................................................... 9
b. Responsabilité du groupe :.......................................................................................... 9
a. Existant : ........................................................................................................................ 10
b. Responsabilité du groupe :........................................................................................ 10
a. Composite Object : .................................................................................................... 12
Structures : ....................................................................................................................................................... 12
Avantages : .................................................................................................................................................... 13
Exemple de mise en œuvre : ...................................................................................................................... 13
b. Entity System & Data Driven : .................................................................................... 15
Entity System : ................................................................................................................................................. 15
Data Driven : ................................................................................................................................................... 18
c. Model View Controller (MVC) : ................................................................................. 18
a. Designs coté client : ................................................................................................... 19
Cas d’utilisation récolter ressource : .......................................................................................................... 19
Diagramme de séquence d’un click sur un bouton : ............................................................................ 20
b. Designs coté serveur : ................................................................................................ 21
Modélisation de la base de données liée aux comptes utilisateurs/joueurs :................................... 21
Cas d’utilisation des comptes utilisateurs : ............................................................................................... 23
Cas d’utilisation des parties : ....................................................................................................................... 24
Algorithme de création de sprites :............................................................................................................ 25
a. Outils et procédures de développement coté client : ......................................... 27
Javascript : ...................................................................................................................................................... 27
JQuery :............................................................................................................................................................ 27
HTML 5 : ............................................................................................................................................................ 28
AJAX : ............................................................................................................................................................... 28
User Interface : ............................................................................................................................................... 29
Model objet Interne de Javel : ................................................................................................................... 30
Model objet de Javel : ................................................................................................................................. 31
b. Outils et procédures de développement coté serveur : ...................................... 33
PHP et Programmation Orientée Objet .................................................................................................... 33
Framework ...................................................................................................................................................... 33
a. Du client vers le serveur.............................................................................................. 38
b. Du serveur vers le client.............................................................................................. 38
A. Projet :
Projet Jeu de Stratégie Web – [DEV]


Développement et conception de l’interface du jeu
Développement et conception de la logique de l’application et d’automates Symfony
de mise à jour du jeu
B. Equipe :



Lemeunier Rémy
Poli Romain
Tavernier Jade
C. Client :



Oger Stanislas
Mazza Benjamin
Gotab Pierre
D. Contraintes :
Les principales contraintes résident dans le sujet, la technologie. Nous nous sommes en effet
engagés à développer l’interface du jeu avec Javascript & Jquery et le moteur du jeu coté
serveur avec le framework Symfony.
A. Positionnement :
Le jeu est un Casual Game (jeux vidéo occasionnel : jeu simple et rapide à jouer conçu pour
prendre du plaisir rapidement lors de parties) qui se place sur le marché des jeux web
classiques.
B. Gratuité :
Il suivra le modèle qui a fait le succès du jeu web : le jeu est gratuit mais pour débloquer toutes
ses fonctionnalités ou pour obtenir des éléments inédits il faut souscrire à un abonnement ou
faire un micro-paiement du type Allopass.
C. Ambiance :
L'ambiance sera fortement déterminée par les graphismes. Le jeu se déroulera dans un univers
futuriste ne se prenant pas trop au sérieux. Il y aura donc quelques touches d'humour, et
quelques éléments irréalistes. Le client désire une communauté forte basé sur le jeu en équipe.
D. Les joueurs ciblés:
Le jeu vise les joueurs occasionnels (casual gamer) qui ont peu de temps à passer devant un
jeu. Il suffira de 15 minutes maximum par jour pour effectuer toutes les actions nécessaires.
E. Les concurrents :
Les principaux concurrents sont :
 Motion twin est une société de développement de jeux gratuit à option payante sur
navigateur. Elle est le leader du marché français. Les jeux phares de la société sont
Labrute, Miniville ou encore Hordes pour les plus connus.

GameForge est également un éditeur de jeux en ligne par navigateur. L’entreprise est
un des leaders mondiaux du marché. Elle s’est notamment illustrée avec des titres
comme Ogame, Ikariam, BattleKnight.
F. Objectifs :
A terme le jeu sera mis en ligne avec du contenu principal gratuit et du contenu évolué
payant. Nous espérons qu’une nouvelle communauté naîtra autour de l’univers du jeu,
nécessaire pour sa survie sur la toile, qui participera donc à l’évolution du jeu.
A. Présentation général du jeu :
Jeu de stratégie en ligne dans un monde semi persistant alliant
(1 tour / jour) et temps réel. Le jeu présente actuellement 3 modes de jeu :



tour
par
tour
Capturer le drapeau : chaque équipe doit capturer le drapeau de l’ennemi.
Protéger un élément fixe (bâtiment) : chaque équipe doit empêcher l’ennemi de
détruire son élément tout en attaquant celui du camp adversaire.
Eliminer les adversaires : chaque équipe doit annihiler toutes les troupes adverses.
Les parties se déroulent sur une quinzaine de jours avec un maximum de 5 joueurs par équipe
qui s’affrontent.
Un système de fidélisation est créé grâce à un profil persistant des joueurs et une acquisition de
points d’expériences, d’objets et de compétences.
On pourra aussi proposer aux utilisateurs de participer à des matchs « officiels », une sorte de
championnat, ou à des matchs amicaux.
B. Description de la carte :
Dans un cadre futuriste, la carte se compose d’hexagones comportant un terrain ainsi que les
divers éléments la composant (joueurs, bâtiments, objets, conduite de gaz ...).
La carte peut être modifiée par les joueurs mais aussi par les conséquences de leurs actions.
Remarque : ce travail ne fait pas partie de notre tache mais une bonne compréhension de
celle-ci est nécessaire pour la conception du moteur de jeu.
C. Les actions du joueur :
Tout d’abord les joueurs peuvent évidemment se déplacer sur la carte. Il est permis aussi de
construire des bâtiments, de poser des objets, d’en échanger et enfin de les utiliser pour
interagir avec l’environnement.
Il y a donc un système de points de déplacement et de points d’action par tour. De plus les
joueurs ont à leur disposition un arsenal de bombes aux effets divers et variés.
Les joueurs ont un champ de vision restreint à leur équipe et en fonction du degré de leur
compétence de vision (brouillard de guerre).
D. Gestion des ressources :
Le joueur possède une quantité limitée et définie de « cluster », des nano-robots à disposer sur
la carte afin de construire ou réparer des bâtiments ainsi que de récolter des ressources.
On retrouve dans ce monde deux types de ressources :
 Matériel provenant de débris
 Gaz provenant des canalisations
Chaque action effectuée sur une conduite influe sur les autres actions réalisées sur la même
conduite.
Dans ce projet, nous travaillons en coopération avec nos tuteurs. C’est pourquoi nous
présenterons les différentes fonctionnalités via celles qui sont à notre charge et celles
effectuées par les autres membres de l’équipe.
A. Fonctionnalités coté client :
a. Existant :




Architecture générale (Obj, Component/Core/Lib/View, Main)
Débogage (Dbg)
Système de communication (Requester)
Carte dynamique et mini-carte (affichage et interactions)
LibMainMinimap)
(LibMap,
b. Responsabilité du groupe :





Interface graphique (UI, widgets, intégration)
Root, Button, StateButton, Toolbar, Window, Progress, Slider, Grid
Protocole de communication (teneur des messages envoyés)
Interactions joueurs (déplacements, échanges, ...)
Interactions environnement (construction, récolte, pose de bombes, ...)
LibMainMan,
B. Fonctionnalités coté serveur :
a. Existant :
 MCD du monde persistant
Modélisation de l’ensembles des entités qui seront gérées dans le jeu.
 Backend partiel de gestion du monde
Traitements coté serveur de plusieurs actions liées à la gestion du jeu.
Par exemple, lorsque le joueur effectue une action sur la carte, le client transmet une requête
au serveur et ce dernier s’occupera de mettre à jour les informations de la carte et de chaque
entité sélectionnée afin de faire la partie.
 RequestController
Contrôleur de requêtes (logique du Design pattern Model – View – Controller).
Vérifie, sécurise et dispache les actions à effectuer sur le serveur.
 RequestBuilder
Classe utilitaire et métier pour construire les requêtes.
 Structure du moteur de jeu et d'évènements
Classe structurelle, squelette des fonctions du moteur du jeu.
 Générateur d'univers
Editeur de carte en "presse bouton", c’est à dire sans aucune utilisation de code source.
b. Responsabilité du groupe :
 MCD des comptes
Modélisation de la logique et des données de connexion/inscription ainsi que de la relation
entre le compte joueur et le compte utilisateur.

Frontend pour gestion des comptes
o Définition de la structure sous Symfony de l’implémentation de l’inscription et de
l’authentification des utilisateurs
o Création des formulaires de gestion du compte
o Réalisation des règles de validation des formulaires (client & serveur)
o Sécurisation des comptes et mots de passes

Backend complet pour la gestion des comptes
o Vision globale et rapide de l’ensemble des comptes
o Définition des actions modératrices
o Gestion des droits
o Sécurisation de l’accès
 Algorithme de création de sprites
Afin d’optimiser le nombre de requêtes au chargement des images, nous allons créer un
algorithme pour générer des sprites. C’est à dire que nous allons rassembler des images en une
seule qui ne sera affichée que partiellement grâce au CSS.
La difficulté réside alors dans l’optimisation de l’espace graphique à utiliser pour réaliser ces
images.
 Mise à jour nocturne "générique"
Phase de traitement des différentes actions effectuées dans la journée. Le serveur se ferme
donc à heure fixe chaque soir et calcule l’impact sur le monde de chaque opération.
Cela correspond donc à la compilation des actions de la journée et de la logique de jeu pour
déduire le monde du jour suivant.

Implémentation de la logique de jeu en utilisant la structure et les outils existants
 Templates des pages annexes
Définition de la structure et de la mise en page des pages autres que le jeu (HTML + CSS).
A. Design patterns :
a. Composite Object :
En programmation objet, un objet composite est constitué d'un ou de plusieurs objets similaires
(ayant des fonctionnalités similaires). L'idée est de manipuler un groupe d'objets de la même
façon que s'il s'agissait d'un seul objet.
Structures :

Component (composant)
o déclare l'interface pour la composition d'objet
o met en œuvre le comportement par défaut
o déclare une interface pour l'accès aux composants enfants

Leaf (feuille)
o représente des objets feuille dans la composition

Composite
o définit un comportement pour les composants ayant des enfants
o stocke les composants enfants
o met en œuvre la gestion des enfants de l'interface Component

Client
o manipule les objets de la composition à travers l'interface Composite
Avantages :
Son principal
avantage
découle
de
la définition même
de
ce
pattern.
Etant donné qu’un agrégat est alors utiliser comme un objet unique, il est donc possible
d’imbriquer ces agrégats .
Exemple de mise en œuvre :
Soit la structure hiérarchique suivante, design d’un objet graphique :
On préférerait pouvoir appliquer directement à un groupe d'objets graphiques les méthodes
d'objet graphique lui même. C’est pourquoi le pattern composite fut créé :
b. Entity System & Data Driven :
Entity System :
L’Entity System est un Design pattern de plus en plus utilisé dans les jeux vidéos.
En effet, les jeux vidéos nécessitent une quantité importante d’objets aussi spécialisés les uns
des autres. On constate ainsi très fréquemment que les objets finaux d’une application en
Programmation Orientée Objet résultent d’une importante succession d’héritages.
La flexibilité et la mise à jour des objets dans ce genre de système est relativement complexe
car la modification d’un élément implique souvent une modification de la structure
hiérarchique, ce qui est une opération relativement lourde.
 Prenons l’exemple suivant :
A la création du jeu, les concepteurs créent une structure orientée objet des différents
éléments du jeu. On retrouve donc plusieurs niveaux d’héritages afin de bien définir toutes les
particularités de chaque objet.
Si durant une mise à jour du jeu, les concepteurs décident que les Tanks ne soient plus mobiles,
il faut alors effectuer une modification de la structure pour un nouveau type de véhicules
statiques :
Cette manipulation étant particulièrement lourde, on retrouve donc souvent dans les jeux
vidéos des « super classes » qui possèdent toutes les fonctionnalités implémentées. Les objets
sont donc identifiables en fonction de leur utilisation, on parle alors de « Blob » :
L’Entity System s’inspire légèrement de cette situation car il n’ya plus d’objet, chaque élément
est une entité, l’élément de base.
Cependant, la structure est beaucoup plus intelligente car une entité n’a aucune
fonctionnalité de base puis est définit en fonction des méthodes qu’elle implémente.
 Prenons un exemple simple POO :
On transforme alors ces objets en entités et ainsi une voiture de sport en est une car elle
implémente les méthodes d’une voiture et celles d’une sportive :
Data Driven :
Le Design pattern Data Driven est étroitement lié à l’Entity System car ce design permet de
structurer une organisation en fonction des données.
C’est à dire que les traitements s’effectuent en fonction des données traitées. Or l’Entity System
spécifie pour chaque entité l’ensemble des fonctionnalités qu’elle implémente et donc
quelque soit le but de l’entité, les données sont gérées de la même manière.
Admettons qu’une première entité « Avion » et qu’une seconde « Voiture » ont toutes deux la
faculté de se déplacer. On effectuera alors le déplacement de chacune de la même façon.
Cette mise en œuvre permet ainsi, à plus grande échelle, d’optimiser le traitement des
opérations en regroupant les actions similaires pour l’ensemble des entités.
c. Model View Controller (MVC) :
Le Model View Controller est une architecture et une méthode de conception qui organise
l'interface homme-machine (IHM) d'une application logicielle.
Elle divise l'IHM en :
 un modèle : traitement des données
 une vue : interface utilisateur
 un contrôleur : synchronise la vue et le model
L’avantage d’utiliser ce modèle est la clarté de l'architecture qu'il impose. Ce qui permet de
simplifier la maintenance ou l’amélioration du projet. Car la modification des traitements ne
change pas la vue.
On peut modifier le modèle tout en conservant les vue actuels.
B. Technologie :
a. Designs coté client :
Cas d’utilisation récolter ressource :
Voici un diagramme pour expliquer le déroulement effectué pour récolter des ressources.
Tout d’abord le joueur fait une demande de création du cluster du Nano robot.
La taille du cluster diffère suivant le niveau du joueur c’est pour cela qu’on fait une demande.
Ensuite on crée le cluster.
Puis le joueur demande de récolter des ressources, la marche à suivre serra différente suivant si
c’est des débris, canalisation ou usine. C’est pour cela qu’on les différencie.
Puis on demande au nano cluster d’effectuer la récolte.
De la même manière, le jeu implémentera diverses actions du même type issues d’interactions
avec les joueurs ou l’environnement :
Interaction Joueur
 se déplacer
 acheter une unité
 modifier son compte
 discuter grâce au chat
Interaction Environnement
 récolter
 poser une bombe
 attaquer
 se déplacer
 attaquer
 construire
Diagramme de séquence d’un click sur un bouton :
Voici le diagramme de séquence d’un clic sur un bouton.
Cela nous permet de voir les relations qu’il y a entre les différents objets.
Lorsqu’on clique sur le bouton la fonction click d’ImgButton est appelé puis celle-ci appel la
fonction clic de notre composant UI.Button.
Ensuite notre UI.Button informe l’UI qu’il y a eu un clic puis le Manager est interpelé par l’UI pour
effectuer les changements demandés.
b. Designs coté serveur :
Modélisation de la base de données liée aux comptes utilisateurs/joueurs :
Dans l’optique d’utiliser le framework symfony qui offre le mapping de la base de données,
c’est à dire que la base est étroitement liée aux objets, nous avons conçu les relations entre
l’utilisateur et le joueur via un MCD.



sfGuardUser : profil utilisateur
player : profil joueur
level : niveaux d’expérience (le niveau d’un joueur est calculé en fonction de son
experience suivant plusieurs seuils)




playerTeam : relation montrant l’appartenance d’un joueur à une équipe
team : équipes présentes dans le jeux
playerEquipment : relation montrant pour un joueur la possession d’un ou plusieurs
objets
equipment : objets présents dans le jeux
Une fois, la conception des utilisateurs sur le serveur effectuée, nous nous intéressons sur la
manière dont nous allons les guider sur le site.
Nous proposons donc une vision de les processus d’inscription/connexion et de connexion à
une partie.
Cas d’utilisation des comptes utilisateurs :
Dans la situation initiale, un internaute se connectant sur le site possède trois actions possibles :



s’il est déjà inscrit et qu’il connaît son mot de passe, il peut se connecter au jeu
s’il est déjà inscrit mais qu’il a oublié son mot de passe, il peut demander à renouveler
un nouveau mot de passe aléatoire via son adresse électronique qui lui sera envoyer sur
sa boîte électronique
s’il n’est pas encore inscrit, il peut alors procéder à son inscription qui une fois terminée le
conduira pendant la création de son profil joueur avant de le connecter au jeu
Cas d’utilisation des parties :
Cette situation met en œuvre le processus de répartition des joueurs dans les différentes
instances de jeu.
Un joueur se connecte premièrement sur son compte et désire commencer une partie, deux
modes de jeu sont possibles :

participer à une partie public officielle : le joueur est alors dirigé par le serveur qui le
connecte à une partie déjà créée du niveau du joueur ou si aucune partie ne
correspond au joueur, il crée une nouvelle instance de jeu et le joueur reste en attente
de connexion du minimum de joueurs recommandés.

participer à une partie privée entre amis : le joueur choisit alors s’il veut prendre part à
une partie existante ou s’il souhaite créer un nouveau monde.
Algorithme de création de sprites :
En autre que la gestion des processus liés aux utilisateurs nous sommes en charge de
développer un programme en PHP qui permette de créer des sprites CSS.
On appelle sprite CSS une méthode d’optimisation des images d’un site internet en regroupant
les différents graphismes de l’interface sur une seule image. Grâce à ce principe une seule
image est donc chargée pour l’ensemble de l’interface.
Cette image est alors utilisée via la propriété background du langage de style CSS. On définit
une vue restreinte de l’image que l’on place sur la sous image souhaitée via la propriété
background-position.
Prenons par exemple un ensemble d’images que nous souhaitons rassembler :
Nous commençons donc par identifier la délimitation en rectangle de la place minimum
utilisée par chaque image :
Enfin on range les images de haut en bas et de gauche à droite les images dans l’ordre
croissant de leur taille.
La difficulté de cette mise en œuvre viendra donc du fait d’optimiser
l’espace utilisé en prenant en compte les espaces et en modulant le
positionnement des blocs afin de combler au maximum ces espaces
vides.
Le but étant de réaliser un résultat digne de le sprite suivant,
surement le plus connu sur la toile :
A. Technologie :
a. Outils et procédures de développement coté client :
Javascript :
Javascript est un langage normé (ECMA-262), créé en 1995 par Monsieur Eich Brendan, il est
libre et gratuit.
C’est un langage de script incorporé dans un document HTML, il permet donc d'améliorer une
page HTML en la rendant dynamique car grâce à lui on exécute des commandes du coté
client.
Cela met en évidence qu’il est relié directement au navigateur qui ouvre la page, mais cela
n’est pas un problème car 99% des utilisateurs utilisent un navigateur qui supporte nativement
Javascript.
Il y a des alternatives à Javascript comme Flash, Silverlight et Java.
Tout d’abord, Flash nécessite l’installation d’un plugin, il est proprietaire et payant.
Ensuite Silverlight lui aussi nécessite l’installation d’un plugin et il n’est également pas très
répandu.
Et enfin Java a également besoin d’un plugin et il n’est pas apprécié dans le domaine du jeu
web.
Nous avons décidé d’utiliser le langage Javascript en fonction de la clientèle que nous visons.
Une bonne partie de notre clientèle sera des salariés qui souhaitent jouer pendant leurs heures
de travail, sur leur ordinateur de travail. Nous avons donc opté pour une page web standard
avec des technologies natives, c’est pour cela que notre choix s'est porté sur Javascript.
JQuery :
Introduction :
jQuery est un framework puissant, simple et léger très utilisé par de nombreux sites internet
(comme Google, Wordpress, mozilla.org, ...). Il est libre (sous licence MIT, GPL), compatible
avec tous les navigateurs et la documentation est agréable et fournie. JQuery a pour but
d’être non-intrusif, facilement modulable grâce à de nombreux plugins et très tolérant en cas
de cohabitation avec d’autres librairies.
Historique du framework :
La première version de JQuery date de juin 2006 en version 1.0 alpha (version sans
toutes les fonctionnalités prévues dans le Framework final). La version actuelle est la v1.4.4.
Points forts du framework :




simplicité d’utilisation
documentation en ligne
quantité de plugins
dynamisme du projet et de sa communauté
Points faible du framework :


hétérogénéité dans la qualité des plugins
facilité à produire un code peu optimisé et consommateur en ressources
Les plugins :
Les plugins permettent d’étendre les capacités de jQuery en ajoutant de nouvelles
fonctions et de nouveaux attributs utilisables par tout objet jQuery. Les plugins permettent de
rendre JQuery moins lourd. Le développeur choisi uniquement les fonctionnalités qu’il souhaite.
JQueryUI :
JQueryUI est né d’un plugin nommé Interface, développé en dehors de l’équipe de
développement officielle. Il fait maintenant parti du projet sous le nom de JQUeryUI. Ce plugin
permet de rendre le site interactif en y ajoutant des éléments dynamiques tel que des
animations sur le texte, des barres de défilement, des barres de progression, le drag and drop
(glisser,déposer) .
Pourquoi JQuery? :
Car c’est l’un des framework le plus utilisé, la documentation est très fournie. C’est un
framework de qualité constamment en évolution, avec des développeurs se souciant des
gains de performances et d’optimisation ainsi que de compatibilité entre ses versions. De plus il
est compatible avec tous les navigateurs actuels.
Les concurrents de JQuery :
Les principaux concurrents sont :
 Mootools
 Dojo
 Prototype
 Yahoo User Interface
HTML 5 :
HTML5 est le devenir du HTML. Il convient tout à fait à la conception d'applications dynamiques
puisqu'il s'oriente clairement dans cette direction (canvas, local database, high level events,
websockets, ...).
AJAX :
AJAX : Asynchronous Javascript and XML.
Ajax réunit un ensemble de technologie comme Javascript, CSS, XML, le DOM et le
XMLHttpRequest pour réaliser des applications Web.
DOM et JavaScript servent à modifier le contenu de la page dans le navigateur par
programmation.
XMLHttpRequest est utilisé pour dialoguer avec le serveur Web (Asynchrone). La notation XML
structure les informations transmises entre le serveur Web et le navigateur.
A la place de XML on peut utiliser JSON.
AJAX permet le dialogue entre un navigateur et un serveur web de manière Asynchrone.
L’’avantage de l’AJAX est qu’il fait tout cela sans recharger la page, il modifie directement le
contenu de la page.
Lorsque le navigateur envoie une requête au serveur, il n’attend pas ca réponse ce qui permet
à l’utilisateur de pouvoir continuer à effectuer des modifications.
Il ne nécessite pas l’installation d’un plug-in comme ses concurrents Adobe Flex ou Microsoft
Silverlight ce qui est un avantage.
User Interface :
Pour la réalisation de l’user interface nous allons utiliser un framework réalisé
par Pierre Gotab : UI.
Notre tuteur Pierre Gotab a décidé de créer son propre Framework car il n’existe à notre
connaissance aucune librairie maintenue qui permet de faire des composants d’interface
graphique suffisamment personnalisables pour s'intégrer parfaitement dans un jeu.
Le framework de Pierre est un système unifié de gestion des composants, il manipule les UI.*.
Ces composants sont soit des interfaces avec une autre librairie, soit un composant réalisé par
nous même lorsque aucune solution existante n’est satisfaisante.
Nous privilégierons en premier lieu les composants issus de la librairie Jquery.UI car nous utilisons
déjà Jquery pour le reste de l’application.
Voici l’interface commune des composants :
 instanciable grâce a la fonction initialise et installe
 représente un Objet HTML concret, plaçable et déplaçable (fonction getElement)
 peut éventuellement contenir de HTML arbitraire ( fonction getContent)
 peut être hautement personnalisable avec du css (fonction getElement().addClass)
 peut être détruit (fonction delete)
Les composants :

Root :
C’est un objet qui prend tout l'écran, il représente le contexte général de l’application. Il
réagit au redimensionnement de la fenêtre. Aucune librairie ne propose de composant
comme cela.

Button :
C’est un objet cliquable, il réagit au clic, peut être toggle (actif ou non actif) et peut
faire partie d’un radio Group (les boutons interagissent entre eux s’ils sont dans le même
groupe).
Jquery propose le bouton Jquery.button qui est satisfaisant mais pas personnalisable.
Donc nous créons une interface d’un fork de jquery.button -> jquery.xButton.

Toolbar :
C’est un conteneur pour d’autre composant UI. Il peut être horizontal ou vertical.
Des composants de ce style existent dans des librairies externes mais il n’accepte que
des composants natifs de leur librairie.

ProgressBar :
Cet objet représente une barre de progression.
Nous avons choisi le composant Jquery.ProgressBar de la librairie Jquery mais peu
personnalisable donc il est utilisé comme Button.

Slider :
C’est un objet composé d’un curseur pouvant être déplacé entre deux bornes. Il
change dynamiquement les valeurs sélectionnées.
Le composant Jquery.Slider nous convient.

Windows :
C’est une fenêtre redimensionnable, déplaçable, avec titre, bordures et bouton de
fermeture.
FancyBox, shadowBox, Fancy Zoom (rapide).

Drag :
C’est un objet qui peut être déplacé grâce à la souris.
Draggable jquery, Dragdealer

Grid :
C’est un composant qui permet de créer des tableaux.
jqGrid

Scrollbar :
Il permet de se déplacer au sein d’un document.
Tiny scrollbar, jScrollPane
Model objet Interne de Javel :
Tout d’abord voici les conventions de nommage pour les modèles objet :
 Quelque soit le modèle :
o UneClasse,
o uneInstance,
o propriete_publique,
o propriete_privee,
o methodePublique(),
o methodePrivee()
 Modèle objet interne : _propriete_builtin_
 Modèle objet de javel : _propriete_builtin_
Le cœur de Javel est composé d’un factory ( obj ) qui prend en entré une Hashmap et
retourne une fonction constructeur contenant le code de création d’une instance de l’objet.
La Hashmap contient des fonctions, qui seront les méthodes de classe, et éventuellement un
bloc de déclaration _static_.
Si autre chose y est présent, une exception SyntaxError sera levée.
La fonction constructeur, que l’on appellera classe par la suite et elle possède comme
propriétés celles présentent dans le bloc _static_.
Utilisé avec le mot clé new, elle va créer une instance possédant une propriété _class_ se
référant à la classe, puis va exécuter la méthode _init_ en lui passant les arguments nécessaires.
Model objet de Javel :
Le model contient quatre entités :
 Components,
 Core,
 Lib,
 View.
Un Core, Lib, View est un Component.
Une View est attachée à une Lib.
Component :
Un component est une factory de classes, il retourne une classe ayant des propriétés et des
méthodes prédéfinies.
Il prend en entrée :
 Le type parmi :
o Component.TYPE_CORE = 0
o Component.TYPE_LIB = 1
o Component.TYPE_VIEW = 2
 Le classname : une chaine de caractères unique
 Les properties du composant : une hashmap ne contenant que des méthodes (et pas
de bloc static)
Il renvoie une classe ayant les méthodes définies dans properties avec en plus :
 Des variables statiques :
o _type : le type de composant
o _classname : le nom de la classe
o _debug_mode : le niveau de débogage du composant (0 par défaut)
 Des méthodes :
o toString() et toSource() renvoient un texte adapté (usage interne au débogueur)
o debug(message [, level]) : affiche message dans la console si le niveau de
débogage du composant est supérieur ou égal à level (défaut 0)
o debugEx([message,] exception [, level]) : affiche les détails de l'exception assortie
de message dans la console
Core :
Un Core produit un Singleton essentiel au fonctionnement du jeu.
Singleton : permet de restreindre l’instanciation d’une classe a un seul objet (ou quelque objet
seulement)
le Core est appelé avec deux arguments :
 classname est une chaine de caractères unique servant à identifier ce Core
 properties est un ensemble de méthodes
Il doit posséder :
Une méthode initialize(params) qui initialise le composant, notamment ses propriétés
d'instance.
Eventuellement une méthode install() qui peut installer le composant sur la page
En réalité il ne fait que créer un Component avec comme type Component.TYPE_CORE, puis il
retourne une instance de ce Component.
Lib :
Une Lib est une librairie de fonctions de manipulation de données.
Tout comme un Core, une Lib prend deux arguments.
En revanche elle retourne une classe. Javelutilise plusieurs librairie de façon interne.
Il faut comme pour le Core il faut implémenter une fonction initialize.
View :
Une View est une vue sur les données manipulées par une Lib. C'est la partie contrôleur d'un
modèle MVC. Elle gère la majeure partie de l'affichage et les interactions avec l'utilisateur
Le deuxième argument est la Lib dont la View dépend. Les deux autres sont les mêmes que
pour Lib ou Core.
La view retourne une classe instanciable. Cette classe à une propriété statique _Lib qui pointe
sur la classe Lib rattachée.
Il faut également implémenter la fonction initialize pour initialiser le composant.
b. Outils et procédures de développement coté serveur :
PHP et Programmation Orientée Objet
Le langage PHP est un langage de programmation web côté serveur, ce qui veut dire que
c'est le serveur qui interprète le code PHP et génère du code qui sera interprété par le
navigateur Internet.
La version actuelle de PHP est la version 5, sortie le 13 juillet 2004.
Elle utilise Zend Engine et introduit un véritable modèle objet, une gestion des erreurs fondée sur
le modèle des exceptions, ainsi que des fonctionnalités de gestion pour les entreprises. PHP 5
apporte beaucoup de nouveautés, telles que :
 le support de SQLite, qui est un système léger de gestion de bases de données
embarqué, au détriment de la bibliothèque cliente de MySQL, plus puissante mais qui
n'est désormais plus activée par défaut

des moyens de manipuler des fichiers et des structures XML basés sur libxml2 :
o une API simple nommée SimpleXML
o une API Document Object Model assez complète
o une interface XPath utilisant les objets DOM et SimpleXML
o intégration de libxslt pour les transformations XSLT via l'extension XSL
o une bien meilleure gestion des objets par rapport à PHP 4, avec des possibilités
qui tendent à se rapprocher de celles de Java
Framework
Definition :
Un framework est un ensemble d'outils et de composants logiciels organisés conformément à
un plan d'architecture et des design patterns. L'ensemble forme un squelette de programme. Il
est souvent fourni sous la forme d'une bibliothèque logicielle, et accompagné du plan de
l'architecture cible du framework.
Avec un framework orienté objets, le programmeur qui utilise le framework pourra personnaliser
les éléments principaux du programme par extension, en utilisant le mécanisme d'héritage :


créer des nouvelles classes qui contiendront l’implémentation des fonctionnalités
spécifiques au programme
Surcharger les fonctionnalités existantes dans les classes du framework
Un framework est conçu en vue d'aider les programmeurs dans leur travail.
L'organisation du framework vise la productivité maximale du programmeur qui va l'utiliser afin
de baisser les coûts de construction du programme.
Frameworks PHP les plus utilisés :





CakePHP (open source)
Zend Framework
CodeIgniter
Copix
Jelix
Symfony :
Historique du framework
La première version publique de Symfony, bien qu'alors encore en béta, est apparue
en Octobre 2005. Symfony a finalement été publié en version 1.0 stable en janvier 2007.
La version actuelle est la version 1.4 en LTS (Long Time Support), elle est supposée perdurer
jusqu’en 2012.
La nouvelle version, Symfony 2.0 devrait bientôt voir le jour et est déjà disponible en béta.
Origine et motivations du framework
Symfony est un framework développé par l'entreprise française Sensio. A ses origines se trouve
le framework Mojavi et, comme la plupart des frameworks de la nouvelle génération, Symfony
s'inspire très largement de certains concepts du Ruby On Rails.
Symfony a été créé à partir d'un constat bien simple : il n'existait pas, auparavant, de solution
PHP suffisamment vaste et bien réalisée pour assurer la pérennité et la réutilisabilité du code.
Même PEAR, effort lancé en 2001, ne parvient pas à fournir une réponse satisfaisante aux
problématiques récurrentes des projets PHP : sécurité, respect d'un modèle (MVC, par
exemple), nommage, portabilité, etc.
Points forts du framework
Même si cela conduit parfois à qualifier Symfony de “mastodonte”, il est forcé de
reconnaître que Symfony est, de tous les frameworks, celui qui propose le plus de
fonctionnalités.
L'extensibilité du framework est assurée par le biais des plugins, qui permettent de profiter très
rapidement de nouvelles fonctionnalités développées par d'autres contributeurs.
Fait remarquable, Symfony dispose sans doute d'une des meilleures documentations :
 l'API est quasiment intégralement documentée
 “The definitive Guide to Symfony”, un livre qui explique, pas à pas, l'emploi de Symfony.
C'est ce livre qui, depuis, sert de documentation officielle à Symfony via sa mise à
disposition gratuite sur le site officiel du framework
 un tutoriel appelé Jobeet est mis régulièrement à jour et permet, en 24 étapes d’environ
une heure, d'apprendre à utiliser le framework de A à Z.
Un des derniers gros avantages de Symfony en tant que framework de développement est qu'il
est sans doute l’un de ceux qui assure le mieux son rôle de framework, cadre de
développement.
En effet le formalisme de développement et les conventions de codage sont bien définis, de
sorte que chaque partie du code d'un projet trouve une place logique dans l'arborescence.
Points faibles du framework
Différentes
études
font
état
d'une
relative
lenteur
de
Symfony.
Tout d'abord, l’utilisation d’un tel outil implique l’ambition de réaliser un programme évolué,
nécessitant un moteur souvent lourd.
Cependant, la version 2.0 de Symfony est actuellement en fin de développement et sera
bientôt présentée au public. Ainsi d’après les premiers tests, cette nouvelle version semblera
nettement améliorer les performances.
Organisation des fichiers
Un projet Symfony propose une structure hiérarchique d'organisation du code, sous forme
d'applications elles-mêmes divisées en différents modules.
Symfony emploie la syntaxe YAML pour ses fichiers de configuration. Cette syntaxe, même si
elle ne répond pas au formalisme de XML, elle a cependant l'avantage de la simplicité :
dev:
.settings:
web_debug:
cache:
no_script_name:
etag:
true
false
false
false
Processus d'internationalisation
Symfony est sans doute le premier framework à proposer une internationalisation (i18n), reprise
du framework Prado, et une localisation (l10n) intégrale, à base de fichiers XLIFF. C’est
un langage de balisage créé pour standardiser les échanges liés à la régionalisation.
Cette partie est assez simple à mettre en œuvre et la gestion des « cultures » de l’utilisateur est
très performantes.
En effet, on distingue comme dit précédemment des fichiers pour chaque culture pour
l’ensemble des formulaires, il suffit alors de créer pour chacune les traductions appropriées pour
que symfony puisse lier le fichier de langue à la culture correspondante.
Cependant, il reste du contenu qui n’est pas géré par Symfony, le texte du site. Effectivement,
Symfony gère la culture des titres et menus mais nous devons néanmoins garantir « à la main »
l’internationalisation de l’ensemble des textes du site. Comme souvent nous devrons gérer une
base de données contenant toutes les traductions sur plusieurs colonnes avec un texte par
ligne et sélectionner le bon élément en fonction du texte demandé et de la culture actuelle.
La culture est stockée en cession. C’est à dire qu’à la connexion le site tente de reconnaître la
culture « préférée » de l’utilisateur (si des cookies ont déjà été créés) sinon il définit une culture
par défaut. L’utilisateur a bien sur l’opportunité de redéfinir la culture souhaitée sur le site
(icônes drapeaux).
Processus de contribution au framework
Le projet Symfony s'appuie sur un atelier de développement composé de Trac (Trac Open
Source Project) et de Subversion ( logiciel permettant le téléchargement et la gestion de
différentes versions de programmes), et dispose d'une communauté vraiment vivante.
Après obtention d'un compte d'accès au Trac, chaque utilisateur du framework est libre de
créer un ticket, de proposer un patch. Le wiki de Symfony est le lieu approprié pour discuter
des évolutions majeures à apporter au framework.
Les plugins, déjà très nombreux, peuvent être contribués par le biais d'une procédure plus
simple : il suffit simplement d'attacher le plugin en pièce jointe à une page du wiki pour que
celui-ci soit disponible à l'installation par le biais de l'outil en ligne de commande, pour tous les
utilisateurs du framework.
Outre le forum officiel, très actif, des listes de diffusion locales développeur et utilisateur, sont
disponibles. La liste de diffusion symfony-fr, par exemple, permet des discussions en français au
sujet du framework.
Gestion des extensions
Un plugin Symfony ajoute des fonctionnalités à la
Ces fonctionnalités peuvent être de différentes sortes :
 modification du comportement par défaut de l'ORM
 gestion des droits utilisateurs, librairies Javascript, etc.
base
fonctionnelle
initiale.
L'installation d'un plugin Symfony est largement simplifiée par l'emploi de l'interface en ligne
de commande :
$ ./symfony plugin-install
Structurellement, un plugin Symfony se présente sous la forme d'un dossier placé dans le dossier
« plugins/ », à la racine du projet.
Actuellement, Symfony propose plus de 975 plugins, qui vont de la simple inclusion de librairies
externes (Swift, jQuery, etc.) à l'utilisation d’application complète (CMS, forum, blog, etc.).
Implémentation de référence
Une implémentation de référence de Symfony a été réalisée peu après le lancement
de Symfony, en Décembre 2005 : il s'agit d'Askeet, un site de question – réponse :
Remise à jour de manière irrégulière, cette implémentation ne reflète plus toute la qualité et la
richesse de Symfony.
Cependant, le tutoriel Jobeet possède des maintenances plus fréquentes et permet de bien
intégrer les grands concepts architecturaux du framework.
De plus, Symfony met à disposition un certain nombre de screencasts ou d'exemples
de fonctionnement d'applications, permettant une prise en main pas à pas du framework
à travers des cas divers et variés.
ORM, Doctrine
Un ORM (Object-Relational Mapping) est une technique permettant de lier un objet à une
base de données relationnelle.
A titre d'exemple, en PHP 5 (Orienté Objet), nous aurons un Objet Utilisateur qui sera
directement lié à une table Utilisateur.
Ainsi l'objet est directement lié et permet de mettre en place des méthodes qui vous
simplifieront la vie pour créer, modifier, récupérer et supprimer des informations.
Ce concept existe dans beaucoup de langages, et en PHP5, il existe notamment 2 frameworks
d'ORM qui sont:
Ce sont ces deux Frameworks qui sont proposés dans Symfony et on ne peut en utiliser qu'un
seul par projet web, il faut donc choisir l'un des deux.
Or il se trouve que des développeurs de Doctrine font désormais partie de celle de Synformy,
l’utilisation de Doctrine est ainsi de plus en plus conseillée.
B. Communication des technologies
Afin d’établir une communication entre les technologies du client vers le serveur et
inversement, nous devrons développer le protocole suivant :
a. Du client vers le serveur
A chaque interaction du joueur avec le monde semi-persistant via l’interface utilisateur, le
client Javascript prend en compte les modifications voulues pour créer une requête HTTP grâce
à un service Ajax pour contacter le serveur.
Le serveur reçoit alors la requête, vérifie et effectue le traitement souhaité sur la base de
données qui définit le monde.
Enfin le client attend la réponse du serveur pour effectuer la modification ou non de l’interface.
b. Du serveur vers le client
A chaque demande du client, le serveur génère dans un flux correspondant aux objets
souhaités sous la forme de données Json ou XML.
Cette réponse est reçue par le service Ajax du client qui effectuera les modifications
appropriées sur l’interface.
C. Sécurité :
La connexion du joueur sera en SSL, et nous nous appuierons sur un cookie de session géré par
Symfony.
La triche sera détectée par un système de validation d'actions côté serveur. Toute action
invalide (qui peut être causée par une latence réseau, une désynchronisation du client ou une
tentative de piratage) sera consignée. Les joueurs qui cumulent de telles erreurs seront suivis à
la trace par des modérateurs (probablement élus parmi la communauté). De manière
générale, des modérateurs seront en charge de contrôler le bon déroulement du jeu.
La sécurité au niveau du serveur lui-même sera assurée par une bonne administration système
et un backup régulier des données.
A. Zoning :
Le zoning permet de découper la page en autant de zones que nécessaire. Cela permet de
positionner les zones de navigation, les contenus, le logo, le pied de page, etc.
Il faut commencer par définir les zones générales puis ajouter les zones de plus en plus précises.
On obtient donc au final un schéma de la structure de la future interface.









Ressources : permet d’afficher l’état des ressources actuelles
Chat : permet de discuter avec les joueurs alliés
Actions contextuelles : permet en fonction des unités sélectionnées de proposer des
actions spécifiques à ce type d’unité
Informations du joueur : affiche le pseudo, l’avatar et le niveau du joueur
Menu : permet de naviguer dans le site
Unités sélectionnées : affiche l’ensemble des unités présentent sur la case cliquée
Informations sur l’élément sélectionné : affiche le descriptif de l’élément cliqué
Aperçu général de la carte : mini carte donnant une vision globale du monde
Calques applicables : permet de définir les options d’affichage de l’aperçu général de
la carte (afficher les unités amies, les ressources, etc)
Nous avons à notre disposition plusieurs outils afin de garantir la communication au sein du
groupe et avec nos tuteurs/clients.
Nous disposons tout d’abord d’une liste de mailing regroupant l’ensemble des personnes
associées au projet. De cette façon nous pouvons transférer une information et/ou des fichiers
rapidement à l’ensemble de nos collègues.
Conformément au souhait des directeurs de projets, nous avons réalisé un site Internet
spécifique au projet : http://projets-gmi.iup.univ-avignon.fr/projets/proj1011/M1/p03/
Ce site est hébergé sous Wordpress, ce qui permet de définir des accès sécurisés aux différents
rédacteurs de l’équipe et de pouvoir modifier le contenu du site de manière rapide et sans
accès au code source des pages.
Bien sur, en vue d’être archivé en fin de projet, nous nous sommes préalablement informer sur
la possibilité d’exporter une version statique HTML du site afin de la rendre accessible sur le
serveur de l’IUT. Nous utilisons alors PageNest, un aspirateur de site très simple qui remplit
parfaitement cette tâche.
Le site du projet permet avant de présenter le projet, son contexte et l’équipe qui y travaille. Il
permet aussi de s’informer de l’avancement du projet via un système de news et la mise en
ligne des comptes rendus de réunions.
Enfin, nos tuteurs ont mis en place un Wiki : ajax.univ-avignon.fr/doku. Celui ci leurs permet de
partager des conseils et principes techniques qui nous seront nécessaire pour le bon
déroulement de notre projet.
Nous nous efforçons d’effectuer au moins une rencontre toutes les deux semaines.
Durant les réunions nous commençons alors par présenter l’avancement, les initiatives et les
difficultés du travail réalisé depuis la rencontre précédente.
Une fois cette présentation faite, nous sommes très attentifs aux différents retours. En effet, nos
interlocuteurs nous font part de leurs appréciations en tant que clients dans le projet mais aussi
en tant que tuteurs de l’équipe.
Enfin suivant le memento expliquant le déroulement du projet, nous terminons ces réunions par
la rédaction de comptes rendus reprenant les points importants, les remarques, les
modifications à apporter, le travail validé et un rappel du travail à venir.
A. Tâches concernant les fonctionnalités coté client :
Tâches à réaliser
Interface graphique (UI, widgets, intégration)
Root, Button, StateButton, Toolbar, Window,
Progress, Slider, Grid
Protocole de communication (teneur des
messages envoyés)
Interactions joueurs (déplacements, échanges,
...)
Interactions environnement (construction, récolte,
pose de bombes, ...)
Répartition du travail
26 %
30 %
5%
24 %
15 %
B. Tâches concernant les fonctionnalités coté serveur :
Tâches à réaliser
Répartition du travail
Frontend pour gestion des comptes
15 %
Backend complet pour la gestion des comptes
16 %
Algorithme de création de sprites
21 %
Protocole de communication (teneur des
messages envoyés)
5 %
Mise à jour nocturne "générique"
13 %
Implémentation de la logique de jeu en utilisant
la structure et les outils existants
20 %
Templates des pages annexes
10 %
Séparant le début de la seconde phase du projet, la semaine du 18 Janvier 2011, et la fin, la
semaine du 20 Mai, nous possédons 14 semaines soit 70 jours et donc environ 140 heures de
travail sur une base de 2h par jour pour une personne.
La répartition des ressources est simple car le projet se décompose en deux parties majeures, le
client Javascript et le serveur PHP. Rémy Leuneunier et Jade Tavernier sont en charge du
Javascript et Romain Poli s’occupera des tâches liées au Php.
De plus nous avons le plaisir d’accueillir un nouveau collègue Erasmus, Martin Repka, qui
travaillera en collaboration avec Romain Poli.
Nous travaillerons donc lors d’une première période comme deux groupes distincts jusqu’à la
définition d’un protocole de communication entre le client et le serveur.
Par la suite, nous effectuerons un travail intimement lié qui nécessitera un respect stricte des
dates.
Cette première partie du projet nous a permis de mettre en pratique les enseignements et
compétences de chacun à travers un exercice demandant :
 Une compréhension de l’existant
 Un travail de modélisation complexe
 L’adaptation à des technologies nouvelles imposées
 La mise en place de solutions techniques avancées :
 Un travail d’équipe nécessitant une grande rigueur de travail, un respect des dates et un
bon dialogue au sein du groupe.
De plus, étant donné que nos clients soient nos tuteurs favorise grandement le dialogue et la
disponibilité de nos entretiens, cela nous permet alors d’exprimer notre opinion plus librement
et encourage nos initiatives.
En somme ce travail de compréhension et de conception est une bonne approche du travail
professionnel pour la réalisation d’une application importante orientée web.

Projet n°3 M1 IngéLog 2010/2011

Transcription

Documents pareils

Communiqué de presse Nouvelles formations

Symfony et Dailymotion : une migration réussie

Document - PI

Dailymotion - SensioLabs

Télécharger la plaquette, les dates

brochure - GPO SARL

O.R.M. Doctrine Requêtes via Repository des entités Requêtes via

Migration du code existant vers .Net 4 et Visual Studio

Programme Staff technique

animaux - Nathan

La Bible du Noob

JEUX VIDEOS Fiche information

Lexique du gamer - Team Bayonnette

Organisation Industrielle - MASS 2

Dossier d`inscription 2016 - Handball Club Aime Tarentaise Vanoise

Installation - Denis PALLEZ

Cours/TP jQuery