Début de code

Bonjour à tous,
J'espère que vous passez de bonnes vacances !

Avec Pierre, et plus récemment Jolan, nous avons commencé le projet. On a repris le code du test du réseau, et on y a ajouté quelques règles.

Voici ce qui a été fait : (tout est géré en multijoueur)
- déplacements, en case par case
- équipement et deséquipement de pièce armure (et gestion de l'inventaire)
- messagerie basique (que des messages publiques)
Le tout avec une interface console très basique, juste pour tester. (mais Jolan travaille sur une interface graphique)
Le MJ ne peut rien faire, seule les joueurs peuvent faire les actions (c'est donc automatisé, si on peut dire ^^).

Le déplacement sur la carte prend en compte les collisions avec les éléments (pour le moment, y'a que les murs et les autres joueurs). Les pièces d'armures (chapeau, anneau, armure de corps, etc) peuvent avoir des attributs. Au niveau des caractéristiques des créatures, des choses comme l'AC et le bonus de base à l'attaque sont en parti calculées, mais y'a pas encore tous les éléments pour pouvoir faire les vrais calculs.

Voilà globalement ce qui a été fait la semaine dernière.

Au niveau du code, il est organisé comme suit :
- package jeu :
gère les règles et tous les éléments de D&D.
- package joueur :
tout ce qui concerne l'interface du joueur (pour le moment, juste l'interface console)
- package mj :
pareil pour le mj (pour le moment, juste le démarrage du serveur)
- package reseau :
gère l'envoi de paquet et leur traitement
- package outils :
classes qui permettent de simplifier le code (comme ce qui permet d'implémenter le pattern Observer, dont je parlerai un autre jour)


Sinon, on a utilisé SVN, parce que sinon ça n'aurait pas été possible.
Pour récupérer le code : svn co svn://kidanger.ath.cx/projetdd

Pour le tester :
make mj
dans une deuxième console : make joueur
pour vous déplacer : hjkl
pour parler : s
pour s'équiper : w suivi de l'identifiant de l'objet
pour se deséquiper : t suivi de l'identifiant
pour quitter le joueur : q, pour quitter le mj : ctrl-c


Je pense pas que je vais expliquer tout le code ici. Certaines choses sont assez complexe, comme la gestion des identifiants, dans src/jeu/Entity.java.
Je vous invite par contre à venir sur IRC. Sinon, vous pouvez poser vos questions en réponse.

Bien le bonjour !
Nous travaillons actuellement activement sur le projet, mais nous ne sommes que 3 actifs !
Nous avons besoin de vous !
Alors rejoignez les troupes et venez comba... coder le projet !
Rejoignez aussi le canal IRC pour rester informé et faire part de bugs, ajouts, corrections à effectuer.

Voici les fonctionnalités déjà implémentées :

- Fenêtre principale avec système d'onglets :

- Onglet Carte :
- Carte avec emplacements des murs + joueur(s)
- Possibilité de se déplacer avec des boutons + en cliquant sur la carte directement (! algorithme de calcul de trajectoire du groupe règles nécessaire !)
- Panneau messagerie :
- Zone de messages avec auto-scroll (+ envoi / réception par le réseau, messages privés NON gérés)
- Zone de saisie

- Onglet Inventaire :
- Affichage de l'inventaire du joueur (sous forme de texte)

- Onglet Sorts :
- Vide

- Onglet Fiche Personnage :
- Vide


Note : Le code mérite d'être optimisé (je pense surtout à l'interface graphique qui est sans layout (oui c'est moche) donc faudrait changer tout ça et mettre un beau et compliqué GridBagLayout)
et y'a d'autres trucs à optimiser, et beaucoup d'autres fonctions à implémenter, puisque comme décrit plus haut, seul l'onglet carte est bien avancé (et il manque encore beaucoup d'informations), le reste est vide !

On a besoin de vous !

Voici une capture du jeu à la révision 67, pour vous donner envie de venir :

Je suis assez occupé pour le moment, je pense pouvoir venir aider dans une ou deux semaines.

GridBagLayout : je recommande ce truc.

http://bbclone.developpez.com/fr/java/tutoriels/uiswing/gridbaglayout/?page=page_1

Voilà.

Si on m'explique comment est géré la carte je peux essayer de voir pour l'algorythme de calcul de trajectoire.

J'ai pas mal réfléchit sur l'algorithme de calcul de trajectoire, et plus ça va plus ça me semble complexe à gérer et surtout à implémenter.

Sinon, voici quelques idées que j'ai eu, illustrées de belles images :

Imaginons que notre joueur veuille se rendre au point B en étant actuellement au point A, avec un terrain comme celui-ci :




Ensuite, prenons pour cet exemple, un algorithme qui scanne les positions dans le sens des aiguilles d'une montre, comme ceci :




On peut imaginer le traitement suivant pour ce cas :

PARTIE 1

ETAPE 1
1 : mur = invalide
2 : vide = déplacement




ETAPE 2
1 : vide =déplacement





ETAPE 3
1 : vide =déplacement





ETAPE 4
Traitement en parallèle qui vérifie si la position finale est proche renvoie : vrai
=> fin de la trajectoire n°1
=> nombre de cases parcourues stocké en mémoire (soit 4 dans notre cas)






PARTIE 2

ETAPE 1
1 : mur = invalide
2 : case déjà parcourue = traitement inutile (nécessité de sauvegarder les cases parcourues par l'algorithme)
3 : case bordant une case déjà parcourue = traitement inutile
4 : mur = invalide
5 : mur = invalide
6 : mur = invalide
7 : vide = déplacement





ETAPE 2
1 : vide = déplacement




ETAPE 3
1 : mur
2 : mur
3 : mur
4 : case déjà parcourue
5 : case déjà parcourue
6 : mur
7 : mur
8 : mur

==> Aucune issue : fin de la trajectoire n°2





PARTIE 3

Finalement, l'algorithme compare les résultats :
Trajectoire 1 : destination atteinte, 4 cases
Trajectoire 2 : destination non atteinte

L'algorithme choisit donc la trajectoire n°1.


Cet exemple permet de remarquer qu'il faut faire pas mal de choses :
- Vérifier à tout moment si la position finale n'est pas une case proche.
- Sauvegarder les positions déjà parcourue, pour ne pas revenir en arrière.
- Compter les déplacements (en prenant en compte le fait que 1 fois sur 2 un déplacement en diagonale compte pour 2 cases par exemple)
- Comparer les trajectoires (comparer leur dangerosité, parce que là, il n'est pas encore question de monstre, mais quand il y aura des monstres, il faudra voir si on préfère une trajectoire sûre à une trajectoire courte...) et renvoyer la bonne.

Voilà, en espérant que ça aidera ou éclairera pour l'écriture de l'algo

Evidemment, c'est facile quand y'a plein de murs.
Mais en terrain vierge, y'aura pas 200 fois plus de calculs?

Non, il suffit de rajouter d'autres tests, c'est pour cela qu'à mon avis si l'algorithme de calcul de trajectoire est très bien fait il sera très performant et ça sera juste ENORME.

On peut calculer mathématiquement la distance la plus courte (avec x2 - x1 ...) sans prendre en compte les éléments de la carte. Ensuite, l'algorithme vérifie la trajectoire la plus directe qui va à la destination, et si il n'y a aucun obstacle alors il choisit cette trajectoire.

A mon avis l'algo peut être construit (grossièrement) comme ça :

- Calcul de la distance minimale (calcul mathématique, sans prendre en compte la carte et ses éléments)
- Vérification du tracé le plus court : si non valide, continue :
- Calcule tous les tracés possibles et les compares pour trouver le plus court (ou le plus sûr ?), en prenant en compte ceci :
___- Si il tombe sur un tracé qui fait la distance mini +1 il le choisit et s'arrête
___- Si il tombe sur une case déjà rencontrée il sait combien de déplacement sont nécessaires à partir de cette case pour arriver à destination, et calcule directement la distance totale.
___- Si il dépasse la distance parcourue par une autre trajectoire, il s'arrête aussitôt et passe à la trajectoire suivante, comme ça il ne stocke pas de trajectoires inutiles.
___- Si la trajectoire dépasse le nombre de cases de déplacement de l'entité qui veut bouger, stoppe le calcul de la trajectoire courante.
- Si aucun chemin ne convient, l'algo s'arrête.

En fait, il va falloir stocker énormément de données durant le calcul si on veut quelque chose de très performant.
- Distance la plus courte
- Cheminement de toutes les trajectoires
- Distance parcourue lors de chaque trajet
- Distance jusqu'à arrivée à partir d'une case déjà parcourue / ou case parcourue ne menant nulle part

Si c'est mal codé ça risque d'être long à éxecuter en plus...
Vous avez intérêt de faire ça bien ! ( je dis vous car c'est au groupe règles de faire ça =p )
Haha.

Ce que l'on cherche est un algorithme de recherche du plus court chemin. Evidemment, y'a possibilité de le coder nous même, et de _prouver_ qu'il est bien efficace (que c'est bien le meilleur chemin, qu'il fait pas des calculs en trop, tout ça). Mais vraiment, il en existe déjà, étudiés depuis de nombreuses années : la base c'est Dijkstra (http://fr.wikipedia.org/wiki/Algorithme_de_Dijkstra) , et après y'en a qui l'améliore comme A* (http://fr.wikipedia.org/wiki/Algorithme_A*) qui est plus adapté aux jeux vidéos. Alors ça parle de graphe tout ça, mais vu qu'on a un jeu en case par case c'est simple d'en représenter le graph (un simple tableau à deux dimensions).

Je n'ai pas été dispo souvent en ce début de juillet, et les deux prochaines semaines vont être bien remplies également... Je regarde ce que vous avez fait ce week end et vous donne mon avis ou des idées

Juste une petite explication du fonctionnement de la carte, au niveau des règles.
La carte qui gère les éléments présents est BattleMap. Les éléments doivent implémenter l'interface Placeable pour pouvoir être ajouté à la carte. Actuellement, il n'y a que deux éléments possible : des Creature ou des Wall.

Voici les méthodes principales de BattleMap :
- add : ajoute un élément à la carte.
- move : déplace un élément, le second argument est une liste de positions. Celles ci seront parcouru dans l'ordre, et si il y a collision à une des positions, alors le déplacement s'arrête à cette position. (plus tard, on peut prendre en compte les pièges et tout ça).
- remove : supprime.
À ça, on ajoute des méthodes permettant de récupérer un élément en fonction de son identifiant, ou en fonction de la position.

Il y a aussi un autre mécanisme, qui met à jour la "taille" de la carte lors d'un ajout et d'un déplacement. Cette taille ne servait que pour l'interface console, c'était pour savoir où commençait et où terminait la map. (mais cette bordure n'est pas mise à jour lors de la suppression). Bref, pas très important peut être même à supprimer.

Interactions entre le map et le reste :

Il faut savoir que BattleMap est utilisé au niveau du MJ, mais aussi au niveau du client. Il faut donc une classe qui ne dépendent pas de son utilisation (application MJ ou application Joueur). On a donc mis en place un système d'observateur/observé. Un observateur est un objet qui "s'intéresse" à un autre objet, l'observé.
Concrètement, la map est observé par l'interface graphique (MJ ou Joueur), mais aussi par le réseau. C'est à dire que lorsque qu'un nouvel élément est ajouté, l'interface graphique va automatiquement en être notifié. Et si c'est la carte du MJ qui a changé, alors tous les joueurs vont recevoir un paquet par le réseau pour que leur carte aussi soit changé de la même manière. Et ce dernier changement notifie à l'interface graphique du joueur que la map a changé.
Ça parait compliqué, je sais pas très bien l'expliquer encore, mais une fois qu'on a compris c'est très pratique.

Au niveau de la classe BattleMap, ce système se modélise par le fait qu'elle étend la classe abstraite BetterObservable. De plus, dans la méthode "add" par exemple, on retrouve la notification : "notifyMapAdd", qui provoque la diffusion de l'information.

Je sais pas si ces explications suffisent pour comprendre comment la carte fonctionne actuellement.

Note : cette classe s'appelle BattleMap puisque Map est déjà utilisé par Java.