seconde soutenance

Transcription

seconde soutenance

Napolitan Pizzaiolo Mobylette Master
Rapport de la deuxième soutenance.
19 mars 2005
Bit-niK Team :
Abraham Goulagman Alexandre
abraha_a
Caldwell William
caldwe_w
Quillerou Laurent
quille_l
Varannes Rémy
varann_r
TABLE DES MATIÈRES
2
Table des matières
1
2
Présentation du pro jet
1.1
Avancement général et problèmes rencontrés
. . . . . . . . . .
3
1.2
Avancement du site Web . . . . . . . . . . . . . . . . . . . . .
3
Travail individuel
3
2.1
William
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Laurent
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
Rémy
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.4
3
3
2.3.1
Gestion de la distance entre les véhicules . . . . . . . .
9
2.3.2
Site Internet . . . . . . . . . . . . . . . . . . . . . . . .
11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.4.1
Alexandre
Rapport de soutenance . . . . . . . . . . . . . . . . . .
11
2.4.2
Collisions
. . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4.3
Le menu . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.4.4
Les graphismes
15
. . . . . . . . . . . . . . . . . . . . . .
Conclusion
16
Rapport de soutenance 2
1 Présentation du pro jet
1
3
Présentation du projet
1.1
Avancement général et problèmes rencontrés
Si lors de la première soutenance nous avons présenté des ébauches de
programmes, cette soutenance fut l'occasion de vraiment nous plonger dans
la complexité du langage Caml dont nous découvrons jour après jour les facettes cachées.
Et c'est au niveau de la portabilité du langage que s'est posé notre principal
problème, en eet, si les modules Caml fonctionnent pour la plupart facilement sous Unix, beaucoup de modules sont très dicilement compilables
sous Windows (et sans vouloir entrer dans une polémique, on comprend très
bien les créateurs de ces modules...). Toujours est-il que nous avons passé
beaucoup de temps à essayer de compiler des modules qui auraient pu nous
être utiles comme ocamlgl (gestion d'OpenGL), OcamlSDL (gestion multimédia) ou encore camlimages (pour appliquer des textures aux objets OpenGL),
nous avons donc dû nous pencher vers d'autres solutions comme LablGL pour
l'OpenGL mais nous n'avons pas encore renoncé à compiler certains modules !
1.2
Avancement du site Web
Comme convenu, une version de notre site web est online. Il s'agit d'une
version basique dotée de quelques scripts php pour gérer les news et acher
les screenshots, pour plus de précisions sur les travaux réalisés, voir les partie
respectives des webmasters.
2
Travail individuel
2.1
William
Pour la première soutenance, j'avais écrit un moteur physique simple pour
pouvoir m'attaquer à Opengl. Le moteur physique gère les déplacements de
la mobylette et les collisions sur n'importe quelle carte donnée.
Je me suis renseigné sur les diérentes façons d'utiliser opengl avec Caml.
Il y en a deux principales : La première, Ocamlgl, est la plus intéressante, car
non seulement elle permet l'utilisation de GLFW, plus simple d'utilisation,
et plus rapide que Glut, mais Ocamlgl a une syntaxe très proche de celle de
Caml, ce qui permet une écriture plus agréable de notre jeu. La deuxième se
nomme Lablgl, elle permet l'utilisation de Glut, mais avec une syntaxe mal
adaptée à Caml. Alexandre et moi avons plusieurs jours à essayer d'installer
Ocamlgl, mais la quasi inexistence de documentation, et le temps restant
2.1
William
4
avant la soutenance nous ont obligé à cesser nos expérimentations avec ce
dernier, et de me résoudre à utiliser Lablgl.
La première diculté a été de comprendre qu'utiliser Glut voulait dire
perdre tout contrôle sur le déroulement de l'application, et de modier mon
moteur physique pour l'adapter aux exigences de Glut. Mais dès cet obstacle
surmonté, il m'a sut de modier les fonctions d'achage que j'avais écrites
pour le Graphe Caml pour avoir une interface simple en 2D en opengl. Après
quelques rotations la vue était en 3D, et j'ai écrit trois fonctions pour avoir
trois modes de caméra pendant le jeu :
La première reste derrière la mobylette, et s'en approche quand elle
prend de la vitesse pour donner un eet d'accélération amusant.
La deuxième est une vue au dessus de la mobylette, perpendiculaire au
sol, et l'utilisateur peut modier l'altitude de la caméra.
2.1
William
5
La dernière garde la mobylette au centre de l'écran, mais l'utilisateur
peut la faire tourner dans tous les sens, le permettant d'admirer la
beauté du niveau dans son ensemble.
Ensuite j'ai fouillé dans les chiers de Lablgl pour trouver un moyen de
gérer plusieurs touches en même temps et sans répétitions. Cela m'a pris du
2.1
William
6
temps mais le résultat est très agréable, surtout après avoir passé des heures
àjouer sur le Graphe Caml.
J'ai rajouté une partie au moteur physique qui crée une carte aléatoire
de trois cases, et qui, lorsque la mobylette atteint la dernière case, supprime
la première et en rajoute une. Je supprime la dernière case pour ne pas avoir
à vérier qu'une case se rajoute sur une déjà existante, ou que le chemin
s'encercle ce qui obligerait le jeu à s'arrêter, alors que le but de ce mode est
d'être inni. J'écrirai une version qui ne supprimera pas le chemin au fur et
à mesure pour la version nale du moteur physique.
J'ai rajouté des fonctions pour pouvoir :
changer entre les modes opengl "l de fer" et "rempli"
acher (ou non) la dernière case en une autre couleur
changer la hauteur des bâtiments ou des murs sur le côté (tout dépend
de l'interprétation artistique du truc rouge sur le coté de la route).
2.2
Laurent
2.2
7
Laurent
L'objectif de cette seconde soutenance était la réalisation d'une interface
compatible CaML - Delphi. En eet même si le projet a une prédominance
pour le CaML, il comporte une parti Delphi certaines fonctionnalités sont
absentes dans OCaML.
Pour cette seconde soutenance je me suis principalement attaché aux
recherches sur le réseaux an d établir une compatibilité CaML - Delphi. J'ai
tout d abord éplucher le manuel ( disponible sur http ://caml.inria.fr/ocaml/htmlman/index.html ) cependant celui ci ne contient aucunes données à ce
propos. Je me suis donc orienté vers google ( http ://www.google.com ) ainsi
que exaleads (http ://beta.exalead.com/search) un moteur de recherche très
intéressant car celui-ci associe diérents mots clés an d indiquer de nouvelles
pistes de recherches aux utilisateur. Malheureusement celui ci non plus ne m
a donné aucune réponse... Ayant perdu quasiment tout espoir de trouver une
documentation sur les possibilités de CaML au travers de la réalisation d
un protocole je me suis rappelé d une ancienne tentative sous Mac OS 9
infructueuse pour installer un logiciel compatible avec le protocole eD2k :
MLDonkey ! Je me renseigne donc sur les possibilités mais malheureusement
il apparaît que celui-ci est incompatible avec Windows :'( même a l aide
de cygwin ( http ://www.cygwin.com/ ) qui n est autre qu une librairie
permettant de " porter " des application du monde Unix sans eectuer trop
de changement dans le code source de celui-ci.
Puis dans un second temps je me suis intéressé à la conception du site
2.2
Laurent
8
web. En eet an d apporter un aspect intéressant a celui-ci je me suis
renseigné sur les bases de données MySQL ( http ://www.mysql.com/ ) au
travers des diérant numéros de poss-presse ( http ://www.posse-press.com/
) : Login pratique numéro 4, février 2005 ainsi que de code(r) : PHP pratique
Host série #5 et de Pratique de MySQL et PHP aux édition O'Reilly (
http ://www.oreilly.com/ ). Je me suis aussi documenté sur le site ociel de
PHP a l'aide du manuel ociel ( http ://www.php.net ) Ayant eu quelques
soucis avec mes table Rémy s est alors occuper de la mise en forme et des
scripts pour la récupération des news. J ai donc réaliser un scripte PHP
permettant d acher les diérents screenshots : celui-ci liste les " .jpg " d'un
dossier puis en fait des miniatures qui sont achées dans un tableau généré
automatiquement.
Finalement je me suis intéressé à la manière de récupérer les touches
pressées via le code ASCII. En eet celui-ci étant standard il me parait plus
indique lors d un échange de données inter ordinateur. Une fois que ces codes
sont récupérés il sut de les écrire dans un chier et de transmettre ce chier
au serveur pour que celui-ci analyse les informations, les traite et renvoie luimême des informations aux diérents clients connectés.
Pour la soutenance suivante il faudra donc que je nisse l'implémentation
du serveur et commence à obtenir des traitements sur les données envoyées
2.3
Rémy
9
par les clients grâce a un transfère de chier par exemple.
2.3
2.3.1
Rémy
Gestion de la distance entre les véhicules
A la dernière soutenance, la première partie du SIA à été mise en place
avec l'ensemble de fonctions permettant à un véhicule de suivre le chemin
tracé par la route et de choisir son chemin aux intersections de manière à tourner de manière crédible. Maintenant, il faut que l'on puisse gérer plusieurs
véhicules sur la même map pour simuler le trac. Ainsi, pour cette soutenance, c'est la gestion de la distance entre les véhicules qui à été privilégiée
an de pouvoir éviter qu'une voiture se comporte de manière particulièrement
anormale. Par exemple, en fonçant à toute allure sur le véhicule se trouvant
juste devant elle sans se soucier d'entrer en collision avec et de provoquer un
bel accident, tout ça pouvant entraîner de nombreuses réactions en chaîne
qui aboutiront à un immonde chaos sur la carte du niveau, qui était à la base
censée reproduire la circulation normale d'une ville.
Tout d'abord, la fonction gérant la distance entre deux véhicules renverra
un booléen indiquant l'état du trac chaque fois qu'elle sera appelée. On appellera cette fonction en indiquant bien le véhicule concerné. Si ce véhicule se
rapproche trop rapidement d'un véhicule situé juste devant lui, ralentit, qui
est la fonction principale de distance.ml, le chier qui gère l'espacement des
véhicules, renverra une réponse positive qui indiquera au moteur physique que
le véhicule doit commencer à ralentir s'il ne veut pas provoquer une collision.
La fonction ralentit utilise une technique de détection qui n'est sûrement pas
la plus optimisée, mais qui est la seule qu'il m'a été possible d'implémenter
pour obtenir le résultat souhaité. Ne souhaitant pas reproduire parfaitement
le comportement d'un conducteur mais seulement un semblant d'intelligence,
cette fonction devrait donner des résultats assez convenables dans notre jeu.
Premièrement, on va déterminer la direction du véhicule testé pour savoir
où il se dirige et vérier si quelqu'un se trouve sur son chemin. En utilisant
la class vehicule dénie préalablement, on va pouvoir trouver cette direction.
On utilise va (l'angle du vecteur vitesse) comme indiqué sur la gure 1 an
de voir où va le véhicule. On détermine quatre grands espaces sur le cercle
trigonométrique qui vont faire correspondre va avec l'une des quatre directions utilisées sur la map (Nord, Sud, Est, Ouest). On va ainsi renvoyer un
2.3
Rémy
10
entier compris entre 1 et 4 qui sera utilisé par ralentit qui va appliquer un
traitement diérent suivant l'orientation du véhicule.
Ainsi, nous connaissons désormais la direction du véhicule. On peut maintenant vérier si un véhicule se trouve devant lui. Nous allons donc créer un
intervalle de référence qui va être utilisé pour les tests. Donc, maintenant,
pour créer cet intervalle, il faut tenir compte de l'orientation de la voiture.
On peut donc voir que les limites de l'intervalle en x et y sont diérentes
si la voiture va à l'est ou à l'ouest, et encore plus si elle va au nord ou à
l'est. On va donc utiliser pour dénir cet intervalle les valeurs de largeur
et longueur d'un véhicule (récupérées préalablement en appliquant des formules trigonométriques à l'envergure de ce même véhicule), puis une valeur
qui détermine la distance minimale à maintenir entre deux véhicules appelée securite. Il faut ensuite arriver à déterminer l'intervalle en décomposant
toutes ces valeurs et en additionnant tout cela à partir du centre du véhicule.
Cet intervalle obtenu, on peut commencer les comparaisons avec les coordonnées des autres véhicules. On dispose d'une liste récursive qui contient
tous les véhicules circulant sur le circuit, et on peut extraire de ces véhicules
toutes les informations que l'on veut à propos de leurs coordonnées ou leur
2.4
Alexandre
11
orientation.
On va donc utiliser une boucle qui va s'appliquer tant que l'on a pas trouvé
de véhicule se trouvant devant la voiture testée et que la liste n'est pas vide.
On utilise donc les coordonnées de chacun des véhicules de la liste tour à
tour. Si le centre d'un véhicule se trouve dans l'intervalle, c'est que la voiture
testée se trouve trop près de lui et doit ralentir an d'éviter la collision.
Cette fonction ralentit sera donc utilisée régulièrement an de contrôler la
vitesse de chacun des véhicules présents sur la carte.
2.3.2
Site Internet
Le site web de notre projet à évolué depuis la dernière soutenance conformément à nos intentions. J'ai tout d'abord changé le design du site pour qu'il
représente un peu plus l'esprit de notre projet à l'aide d'un menu designé par
Alexandre. Le site est maintenant un peu moins sobre mais est encore utilisable facilement car nous ne voulions pas faire quelque chose de trop farfelu.
Ensuite, comme prévu, j'ai appris à me servir de PHP pour créer quelques
scripts simples permettant de faciliter la mise à jour de notre site par chacun
des membres du groupe. J'ai ainsi créé le système qui permet d'acher les
news de notre site à partir d'une table SQL et qui évite de toucher au html
dès que l'on souhaite faire passer un message sur le site.
Je n'ai par contre pas encore réussi à créer un système d'administration
qui permettrait un ajout encore plus simple de news directement à partir du
site. Toutefois, possédant maintenant des connaissances satisfaisantes de ce
langage qu'est le PHP, je compte réaliser ce système d'administration sous
peu. En eet, il a fallut se xer des priorités et la lecture des news passait en
premier, l'ajout n'étant pas si compliqué que sa, nécessitant juste de passer
par la base de données de notre hébergeur.
2.4
2.4.1
Alexandre
Rapport de soutenance
Le rapport est une partie très importante du projet, c'est pourquoi il
convient de le soigner. Pour ajouter une petite originalité au notre et surtout faciliter la lecture de code caml par un lecteur, j'ai décidé de trouver
un package pour coloriser le langage Caml. Deux options se sont présentées
2.4
Alexandre
12
a moi : Lgrind et listings. Listings étant gratuit et open source, j'ai opté
pour celui-ci. Je ne le regrette pas car il s'est avéré très simple d'usage et
complet, il possède en outre une colorisation par défaut du langage Caml.
J'ai cependant ajouté moi-même une colorisation des lignes d'interprétation
car elles sont parfois nécessaire pour bien comprendre une fonction.
Voici un exemple de code colorisé :
# let
val
Fonction inc
i n c = (+) 1 ; ;
inc
2.4.2
:
int
−>
int
= <f u n >
Collisions
La détection de collision est d'autant plus longue qu'elle est précise. Pour
faire un bon compromis entre ecacité et rapidité, la détection se fera en 3
étapes.
Détection par case :
Il n'est pas nécessaire de tester les collisions avec
tous les véhicules de la map et heureusement ! Dans un premier temps, nous
considérerons tout d'abord les véhicules présents sur les cases autour de notre
véhicule.
Détection par cercle :
La méthode de détection de collision la plus rapide
est la recherche par cercle, en eet nous avons le centre des 2 vehicules et
leur envergure, on peut donc voir si les les cercles circonscrits aux 2 véhicules
se croisent. C'est la deuxième étape de notre détection.
On peut voir sur ce schéma qu'hélas, les véhicules étant rectangulaires,
la détection peut se révéler désastreuse ! C'est un handicap majeur dans la
réalisation d'un jeu où l'action se passe en ville. . .
Détection par bounding box :
L'avantage de cette détection est qu'elle
est exacte mais elle est plus longue que les autres. Voyons comment elle se
décompose :
2.4
Alexandre
13
Récupération des coins de la voiture
Création de fonctions Je crée 4 triplets fonction,départ,arrivée qui correspondent chacun à un côté de la voiture. Je stocke l'abscisse de départ,
celle d'arrivée et la fonction ane qui relie ces 2 points.
Tests de collision J'ai obtenu les fonctions correspondants aux cotés de
chaque véhicule. Il est donc aisé de regarder si elles se croisent. Si oui, il
sut de récupérer les points de collisions en regardant où les fonctions
s'entrecoupent. On obtient ainsi une détection au pixel près.
Voici un schéma résumant la detection. On peut voir a chaque étape les
véhicules en rouge qui sont éliminés.
Une fois les points de collision récupérés, je prend le barycentre des ces
points. en reliant ce point au centre de l objet, j'obtiens la direction de la
force qu'il faut appliquer à l'objet qui le heurte.
Je n'ai pas encore implémenté la réaction des véhicules lors de la collision
car ;en eet, dans l'élaboration de mon type véhicule, je n'avais pas prévu
que le vecteur vitesse puisse être diérent de la direction de l'avant de la
voiture, je dois donc revoir tout mon moteur physique. J'implémenterai donc
cet aspect pour la prochaine soutenance.
2.4
Alexandre
2.4.3
14
Le menu
J'ai décidé, même si le jeu n'est pas encore opérationnel, de coder un menu
type avec quelques options pour voir si c'était facile de le faire sous caml.
A mon grand étonnement, j'ai trouvé la manipulation des fenêtres avec LablGtk plus simple qu'en Delphi ! Certes le codage n'est pas WYSIWYG mais
déclarer un objet est simple et de plus il n'y a pas à s'occuper du placement
des objets, on donne juste une organisation générale et LablGtk se charge de
tout placer.
Les objets sont de plus gérés dynamiquement, c'est-à-dire que la disparition
d'un élément causée par une commande implique une restructuration automatique de la fenetre sans avoir à y toucher.
La construction d'une fenêtre sous LablGtk est intuitive mais elle pousse en
mème temps à s'organiser. En eet les objet qu'on ache sont tous imbriqués
dans un objet plus gros qui est lui même une partie d'un autre et ainsi de
suite jusqu'à l'élément le plus gros qui est la fenêtre. LablGtk est en quelque
AT X est à Word.
sorte à Delphi ce que L
E
Voyons de plus près la façon dont on construit les fenêtres dans LablGtk.
Je n'ai pas exploré toutes les possibilités de cette librairie étant donné le peu
d'utilisation qu'on en fait ici mais on voit qu'elle renferme de très puissante
possibilités.
LablGtk est basé sur le principe d'imbrication. Certains objets comme les
window ou les frame ne peuvent contenir qu'un seul objet et d'autre comme
les vbox et les hbox peuvent en contenir une innité. Les hbox permettent
2.4
Alexandre
15
d'aligner des objets horizontalement et les vbox verticalement. Pour construire
une fenêtre il faut donc jouer des imbrications. Voici l'exemple du menu que
j ai créé.
On voit bien ici que les frame servent à organiser les éléments et le vbox
à aligner verticalement les radio button.
Pour créer un simple bouton, on utilise la syntaxe suivante :
let
true
button = GButton . button ~use_mnemonic :
~ l a b e l : " _Options "
~p a c k i n g : ( vbox#pack ~padding : 5 ) ( )
button#c o n n e c t#c l i c k e d
~callback : create_options ;
Le
in
label indique le texte du bouton, le
est imbriqué le bouton et enn le
packing indique dans quel objet
callback indique la fonction à appeler
lorsque l'utilisateur clique sur le bouton.
Voici le fonctionnement de base de Lablgtk
2.4.4
Les graphismes
Je me suis un peu intéressé aux graphismes et j'ai donc créé le logo
du jeu qui nous faisait cruellement défaut ! J'ai fait un petit menu style
pizza-tomate pour le site et enn j'ai designé une boite à pizza just for fun.
3 Conclusion
3
16
Conclusion
Pour cette soutenance, nous avons tenu la plupart de nos promesses et
nous avons posé des bases solides pour la conception du reste du jeu. Le grand
dé de la prochaine soutenance sera d'adapter le SIA, le moteur physique
et le moteur physique pour qu'ils marchent de concert. Nous devrons aussi
nous pencher sur le problème du son qui pourra être résolu par l'utilisation
d'OcamSDL mais nous devrons alors surmonter le problème de la compilation
sous windows. L'autre grand dé sera la compilation de Pascal et de C pour
la réalisation future du réseau.
RÉFÉRENCES
17
Dédicace
Alexandre dédicace tout son travail eectué dans ce projet à notre bien
aimée Kirika, une gerbille dèle qui nous aura toujours soutenu de ses couinements malicieux et qui est décédée lors d'une coding party. Nos pensées
t'accompagnent !
Références
[1] http ://caml.inria.fr/ocaml/htmlman/index.html
[2] http ://www.google.com
[3] http ://beta.exalead.com/search
[4] http ://www.cygwin.com/
[5] http ://www.php.net
[6] http ://www.mysql.com/
[7] http ://www.posse-press.com/
[8] http ://www.oreilly.com/

seconde soutenance

Transcription

Documents pareils

Fiche d`évaluation du PFE / La soutenance DCESS Finance, Audit

Faculté de Sciences - Thèse de THIERRY LEROY

Thèse de MARIA-JOAO SANTIAGO-RIBEIRO

Ecole Polytechnique - Thèse de CEDRIC LE COQ

Thèse de ERIC LEMAIRE - Doctorat de Musique

CALENDRIER DE DEBUT D`ANNEE 2016/2017

Mini Projet EDBD -Jeu d`Echec - Telechargement TD/TP pour les

Aux frontières de l`Amérique espagnole coloniale

1 Les différents objectifs du stage et du mémoire : pourquoi faire un

un formulaire - BU de Lorraine