Light And Shadow
      Copyright (C) 2001 - 2002. WOTLAS Team.

      TO DO LIST...

       Voici des propositions de développement pour wotlas. Les descriptifs sont succincts, aussi, n'hésitez pas à demander des détails.

Statut d'un projet : non développé, attribué, en cours, développé.

 

1 - Mentir sur son nom

Statut : développé brillament :)
Référence Draft : partie 2.3.6 - page 11.
Pré-requis wotlas : aucun.

Description : Un joueur a la possibilité de changer son nom, et donc de mentir sur son nom. Pour limiter la taille prise en mémoire, on n’autorise au joueur qu’un nombre limité de faux noms (par exemple 5). Si le joueur veut changer de nom, il faut alors qu’il choisisse parmi ses faux noms possibles celui sous lequel il veut être reconnu. Chaque joueur possède donc un et un seul vrai nom, plus au plus 5 faux noms.

Développement : Le draft donne des idées de départ sur le sujet. On peut maintenant préciser que :

* La gestion des noms se fait côté serveur sur la classe du personnage wotlas.server.PlayerImpl. Pour ne pas surcharger cette classe il faudra créer une classe à part (wotlas.server.LieManager par exemple) que chaque PlayerImpl posséderait pour gérer son nom courant et les noms des personnes connues. Ainsi par exemple lorsque l'on demande PlayerImpl.getPlayerName(), cette méthode appelle par derriere le LieManager pour récupérer le nom demandé.

* Il faudra prévoir que le client puisse modifier son nom et voir la liste de ces faux noms/surnoms... le plus simple est de créer une interface swing (JPanel) que j'ajouterais dans la liste des onglets du wotlas.client.screen.JPlayerPanel. Il faudra aussi ajouter qq messages réseaux pour mettre à jour/récupérer la liste des noms. Cette partie n'est pas aussi difficile qu'elle en a l'air... et je suis prêt à aider la personne qui s'en occupera.


2 - Changer d'apparence

Statut : non développé
Référence Draft : aucune.
Pré-requis wotlas : système de connaissances, caratéristiques jeu de role.

Description : Certains joueurs (Réprouvés,certaines Aes Sedai de haut niveau) auront la possibilité de changer complètement d'apparence... pour revenir plus tard à leur apparence initiale. Avec ce changement d'apparence on peut aussi changer de nom comme pour l'option 'Mentir', cela dit ici les autres joueurs ne peuvent pas reconnaitre le joueur qui a changé d'apparence...

Développement : Il faut mémoriser les attributs visuels du personnage (couleur cheveux, yeux, classe du personnage, statut) plus son nom et surnom. Il faudra ensuite permettre au joueur d'accéder à un JDialog 'Apparence' via la connaissance associée. Ce JDialog lui permettra de sélectionner sa nouvelle apparence. Une fois validée celle-ci est changée côté client et sauvegardée côté serveur. Une fois que l'on a changé d'apparence le JDialog 'Apparence' ne propose que de revenir à l'apparence initiale.

C'est un point de départ... tout est envisageable pour le développement.
Consulter le package wotlas.common.character et la classe wotlas.server.PlayerImpl .

3 - Editeur de Carte

Statut : non développé
Référence Draft : aucune.
Pré-requis wotlas : aucun.

Description : Il s'agit de permettre l'édition et la création de nouvelles cartes pour wotlas. L'image d'une carte ( Monde, Ville, Batiment ) est créé sous Photoshop avec son masque associé puis importée dans l'éditeur. Selon le type de la carte (Monde, ville, batiment) on va alors pouvoir placer des MapExit, RoomLink, etc. Inversement on pourra aussi ouvrir une carte déjà créée et l'éditer.

Plus tard quand le système de gestion des objets sera créé on pourra aussi rajouter des objets sur les cartes.

Développement: C'est un travail de développement assez conséquent qu'il faudra bien analyser/décomposer afin d'éviter qu'il ne devienne chaotique. L'édition des cartes pourra se faire en de nombreuses étapes distinctes ( édition des RoomLinks PUIS création des Rooms... ). L'éditeur utilisera le moteur graphique développé pour wotlas.

4 - Effets graphiques 'One Power'

Statut : en cours
Référence Draft : aucune.
Pré-requis wotlas : aucun.

Description : Il s'agit de créer des effets graphiques pour l'utilisation du 'One Power' dans le jeu. Un premier effet est celle d'une personne qui canalise (sorte d'aura avec rotation rapide aléatoire). L'effet est visible tant que la personne canalise. On pourra reprendre ce qui a été fait avec le wotlas.libs.graphics2D.drawable.AuraEffect . Les autres effets s'établissent entre deux joueurs : les effets du 'One Power' sont décomposés en brins de couleurs différentes qui oscillent et relient l'utilisateur à sa cible.

On pourra envisager d'autres effets graphiques : explosions, oiseaux traversant l'écran, nuages, etc...

Développement : Pour representer l'effet graphique des brins on pourra utiliser les possibités de dessin vectoriel de Java2D (cf. démo de sun dans le jdk1.3) en y ajoutant un flou ou tout autre effet... On pourra ainsi créer un effet 2D générique qui s'initialise en donnant le nombre de brins et leur couleur.

5 - Plug-in Moteur 3D

Statut : attribué
Référence Draft : aucune.
Pré-requis wotlas : sans doutes qq adaptations à faire pour permettre l'ajout du moteur 3D. Actuellement, chaque carte possède un lien vers sa représentation 2D. Il faudra rajouter un lien vers la représentation 3D.

Description : L'utilisateur de wotlas aura la possibilité d'installer un Plug-in 3D lui permettant de voir certains lieux du jeu en 3D. Une fois cette étape réalisée on pourra envisager l'intégration du plug-in directement dans wotlas (avec l'API java3D associée) et l'augmentation du nombre de scènes 3D. Il faudra définir les personnages du jeu en 3D et refaire des décors en correspondance avec ceux qui ont été créé en 2D.

Développement : Fabien. Je m'occuperai de faire un pont côté serveur entre le système de déplacement 3D et celui en 2D. Afin que les mouvements 2D ou 3D des joueurs soient vus de chaque côté.

6 - Révision de la structure du moteur graphique 2D

Statut : développé
Référence Draft : aucune
Pré-requis wotlas : aucun

Description : Notre moteur graphique n'a qu'un seul problème : la structure de l'ImageLibrary est un peu lourde. Le fait de manipuler des entiers pour désigner des images de la bibliothèque chargée en mémoire fait certes gagner du temps, mais pour le développeur c'est un calvaire de manipuler 4 entiers via des macros pour désigner UNE image.

Je propose donc une révision de la structure du moteur graphique afin de conserver en mémoire les noms des répertoires/images.

Développement : On pourrait garder le système d'entiers actuels mais créer en mémoire l'arborescence de la base d'images sous forme de tableau de String. Pour créer un ImageIdentifier on pourait ainsi procéder de la manière suivante:

new ImageIdentifier( "maps", "universe", "tarvalon", "tarvalon-mask" );

Ce qui éviterait d'avoir à créer des macros (final public int MAPS_CAT = 0)Reste à voir comment optimiser la chose pour ne pas perdre en efficacité par rapport aux entiers... si la création se fait avec des Strings, on pourrait par contre ne garder en interne dans l'ImageIdentifier l'ancienne représentation sous forme d'entiers. Tout autre proposition sur la structure de l'ImageLibrary est la bienvenue.

7 - Création d'un tutorial de création de niveaux sous Photoshop (en Anglais)

Statut : non développé
Référence Draft : aucune. cf. le mini tutorial que j'avais écrit sur le sujet.
Pré-requis wotlas : aucun

Description : ce tutorial viendrait s'ajouter à l'éditeur de niveau pour expliquer comment créer un niveau pour wotlas, du début jusqu'à la fin.

Développement : aucun.

8 - Gestion des objets

Statut : en cours
Référence Draft: partie 2.4.2 page 17.
Pré-requis wotlas: aucun, mais le développement pourra aussi être lié à l'éditeur d'objets (cf. développement n°16).

Description : Il s'agit de rajouter les objets divers et variés à l'univers de wotlas : Ajouts de formats d'objets génériques : objets fragiles, indestructibles, différents objets magiques, etc... Il faudra aussi rajouter la possibilité de créer une bibliothèque d'objets au format texte (via le moteur de persistance).

Développement : Avant de se lancer dans ce développement il faudra bien en préparer l'architecture. Le but est de pouvoir rajouter de nouveaux objets à wotlas en les créant au format TEXTE du PersistenceManager (pour des précisions sur le sujet: aldiss, harry, petrus). Il faudra certainement rajouter des méthodes au wotlas.common.PersistenceManager pour pouvoir sauver/charger des objets dans la base. Autre point : certains objets pourront avoir des interfaces graphiques associées (un livre affichera une interface quand on l'utilisera ).

Une idée de départ pour le développement:

Créer un nouveau package pour la gestion des objets, un WotObjectManager qui s'occupe du chargement de la bibliothèque d'objets et une base d'objets standard : clés, livres, différents objets magiques, etc... Les instances de ces objets ( clé c234, livre 'De l'art d'écrire', etc...) sont stockés au format texte via le moteur de persistance et ne sont chargés en mémoire que quand on a besoin d'eux. On pourra considérer que le chargement/déchargement des objets du jeu en mémoire sera géré par le WotObjectManager.

9 - Gestion des Connaissances

Statut : en cours
Référence Draft : partie 2.4.3 p19.
Pré-requis wotlas : aucun.

Description : La gestion des connaissance est CENTRALE dans wotlas. TOUTES les actions du jeu passeront par la manipulation de connaissances et leur apprentissage. C'est un sujet que l'on a bien développé dans le draft qui est à consulter donc pour plus d'informations.

Développement : On retrouve le même modèle que la gestion d'objets : des objets connaissance génériques, un bibliothèque de connaissances stockées sur disque au format texte, et un gestionnaire de connaissances pour les charger en mémoire au besoin. Le but est là encore de pouvoir rajouter de nouvelles connaissances au format texte sans avoir à recompiler la moindre ligne de code.

Une idée d'organisation du développement :

- créer les objets 'connaissance' décrits dans le draft.
- créer le gestionnaire de connaissances
- créer qq connaissances génériques ()

10 - Lecture/Ecriture dans les livres

Statut : en cours
Référence Draft : partie 2.3.8 p12.
Pré-requis wotlas : gestion des objets.

Description : Permettre aux joueurs de lire/écrire dans les objets 'Livre' qu'ils pourraient récupérer. On pourrait aller plus loin en créant des interfaces WritableObject et ReadableObject définissant des types d'objets que l'on peut lire ou sur lesquels on peut écrire... bref, toute idée sera la bienvenue surtout que l'étude du draft n'était pas complètement terminée.

Développement : à étudier... les livres seraient stockés côté serveur (au format texte ou html ? via la librarie de persistance ?) une interface utilisateur sera à prévoir côté client.

11 - Ajout du journal de bord.

Statut : non développé
Référence Draft : partie 2.3.8 p13.
Pré-requis wotlas : aucun.

Description : La possibilité pour le joueur de disposer d'un carnet de notes personel. Possibiliter d'y déclarer les connaissances qu'on a faites dans le jeu ( attributs nom + clé ), ce qui permettra éventuellement de leur envoyer du courrier ( cf. projet 41 ).

Une autre possibilité serait de créer une liste de contacts : pour conserver l'info sur les joueurs, et les retrouver dans le monde.

Développement : Les données de ce journal de bord seraient sauvegardées en LOCAL... ce qui veut dire pas de messages réseaux. Dès lors il s'agit de créer une fenêtre de dialogue simple (JDialog) qui pourraient être accessible via une icone au dessus du chat et qui chargerait/sauvegarderait le texte dans/à partir d'un fichier myPersonalNotes.txt . Pour ceux qui voudraient en faire plus, toute idée d'interface est la bienvenue.

12 - Remise en forme de la création de compte. Ajout des Quizz.

Statut : développé - cf. wotlas.libs.wizard - seul la partie QUIZZ restera à faire.
Référence Draft : partie 2.6 p 29.
Pré-requis wotlas : aucun.

Description : Pour que le jeu puisse s'enrichir facilement de nouveaux types de personnages, il faut qu'on puisse le faire rapidement. Plutot que de développer 1500 écrans différents pour la création des comptes on pourrait utiliser des étapes génériques :
- une étape avec Label, entrée texte, Label, entrée texte, Texte d'information
- une étape avec Label, entrée texte, Texte d'information
- une étape avec Label, JList (pour un choix simple dans une sélection)
- une étape avec Label, JList avec Timer (pour un choix simple dans une sélection dans un temps donné pour les quizz)
- une étape avec Texte d'info (pour afficher une information)

Développement : Une fois ces étapes (JStep) créés, on pourra décrire la création de comptes par un ensemble de fichiers texte. Chaque fichier texte référence un ensemble {type d'étape, textes à afficher, lien précédent, lien suivant}. Le JAccountWizard s'occupe de faire le lien entre les différentes étapes.

Un problème important devra être résolu : comment stocker les données récoltées pour la création du compte... les données devront être envoyées au serveur et servir à la création du compte (messages réseaux génériques?). De plus la possibilité de revenir en arrière devra être étudiée.

13 - Editeur de création de compte.

Statut : non développé - serait-ce réellement utile ?
Référence Draft : aucune.
Pré-requis wotlas : remise en forme de la création de compte.

Description : Permettre une maintenance facile du système de création de compte.

Développement : à étudier.

14 - Ajout des caractéristiques RPG (Role Playing Game)

Statut : non développé
Référence Draft : partie 2.4.1 p14.
Pré-requis wotlas : aucun.

Description : Ajouter toutes les caractéristiques Force, Dextérité, Santé, etc... dans la classe wotlas.common.character.Human .

Développement : Ajout des getForce() & setForce(), etc... (je sais c'est bourrin ici, mettre le minimum d'entête Javadoc). Mais aussi des getMinForce() setMinForce(), getMaxForce(), setMaxForce(), indiquant le min et max de chaque caractéristique pour la classe de personnage.

15 - Ajout des classes de personnages.

Statut : développé - sera à compléter avec plus de catégories de personnages, mais l'essentiel est fait.
Référence Draft : équipe wotlas-orgs.
Pré-requis wotlas : caractéristiques jdr, remise en forme des comptes, système de connaissances.

Description : Rajouter des nouvelles classes de personnages à wotlas.

Développement : normalement si tout a été bien fait il ne devrait pas y avoir de code à développer, juste des fichiers texte et des images à rajouter.

16 - Editeur d'objets. Ajout d'objets génériques.

Statut : non développé
Référence Draft : aucune.
Pré-requis wotlas : système d'objets (l'éditeur d'objets pourra être développé simultanément).

Description : Pour faciliter l'ajout/édition des objets dans le jeu on pourra créer un éditeur très simple permettant de créer/modifier/sauvegarder un objet.

Développement : On pourra aussi réfléchir à une intégration de cet utilitaire à l'éditeur de cartes (pour le placement des objets dans le jeu).

17 - Inventaire des personnages

Statut : en cours
Référence Draft : partie 2.4.2 p17.
Pré-requis wotlas : gestion des objets.

Description : Rajouter la gestion des objets possédés par un joueur : de leur récupération (clic sur l'objet et proximité), jusqu'à leur utilisation et leur transfert au sol d'une carte ou à un autre joueur.

Développement : cf. draft.

18 - Interface du système de connaissances.

Statut : en cours
Référence Draft : partie 2.4.3 p19.
Pré-requis wotlas : systèmes de connaissances.

Description : Suit le projet de développement n°9. Il s'agit de développer l'interface swing de manipulation des connaissances du client tel que décrite dans le draft.

Développement : Les classes seront à rajouter dans wotlas.client.gui

19 - Possibilité de sauvegarder une discussion du chat.

Statut : développé
Référence Draft : aucune.
Pré-requis wotlas : aucun.

Description : Rajouter une icone au dessus du chat pour permettre au joueur de sauvegarder sur disque le contenu du chat courant. Autre possibilité : plutôt que d'un bouton de sauvegarde, on essayera de mettre au point la sauvegarde automatique de la discussion.

Développement : Nous disposons déjà d'un utilitaire de log qui permet d'enregistrer des données sur disque à fréquence réduite... il ne reste plus qu'à l'utiliser ici.

20 - Ajout de connaissances standard

Statut : non développé
Référence Draft : qq idées à la partie 2.4.3 p19.
Pré-requis wotlas : systèmes de connaissances.

Description : En fonction des classes de personnages que l'on envisagera de rajouter, il faudra ajouter toute sorte de connaissances associées ( crochetage, exercices de combat, etc ).

Développement : normalement rien si on s'est bien débrouillé... juste des fichiers texte à ajouter... On pourrait même laisser se travail aux responsables des classes de personnages. A voir.

21 - Gestion des animations des personnages.

Statut : non développé
Référence Draft : aucune.
Pré-requis wotlas : aucun.

Description : Pour l'instant les personnages de wotlas ne font que marcher et notre système actuel ne se base que sur un seul type d'animation. Il faut prévoir de nouveaux animations/états pour le personnage (dans la classe PlayerImpl et interface Player) :

- allongé par terre (blessé, dormir, etc...)
- marcher en étant armé avec une épée
- frapper avec une épée
- frapper avec une dague (la dague ne se voit pas quand le personnage marche)
- marcher avec un arc
- tirer à l'arc
- courir

Développement : rajouter des getter/setter pour changer l'état du personnage (byte playerState avec des macros WotCharacter.WALKING_WITH_SWORD ), répercuter ce changement d'état sur le wotlas.character.WotCharacter afin de pouvoir lui demander la nouvelle base d'image à utiliser pour l'animation. C'est le WotCharacter qui gardera de manière persistante l'état du personnage.

Il faudra aussi prévoir la création des nouvelles images des animations (me le rappeler). Il faudra de plus étudier comment faire côté utilisateur pour que l'on puisse faire courir/allonger son joueur (clavier? ou souris boutton de droite ?).

22 - Combat automatique. Combats dans wotlas.

Statut : non développé
Référence Draft : s'inspirer de partie 2.4.4 p26.
Pré-requis wotlas : gestion des animations des personnages.

Description : Ajouter la possibilité d'attaquer quelqu'un et d'enchainer une suite de mouvement de combat (connaissances) lors du combat. Permettre à tout joueur de spécifier ce que son personnage faire automatiquement quand il est attaqué (se rendre, attaquer, fuir...).

Développement : à étudier. Il y a certainement beaucoup à faire de ce côté là !

23 - Gestion des Bots.

Statut : en cours - cf www.alicebot.org
Référence Draft : partie 2.7 p33.
Pré-requis wotlas : aucun.

Description : Rajouter des joueurs contrôlés par l'ordinateur. Ceux-ci peuvent ne pas bouger, faire un aller retour entre deux points, bouger aléatoirement à l'intérieur d'une zone rectangulaire, attaquer une personne entrant dans une zone rectangulaire, suivre quelqu'un. A noter que ces bots pourraient réagir quand on leur parle avec une certaine suite de mots ( ex: 'ouvrir', 'porte' )

Développement : Il s'agit de capitaliser ce qui a déjà été développé. On pourra ainsi reprendre TOUT le code client de la v1.1.1 ( package wolas.client ) et le copier dans un nouveau package wotlas.bot . A partir de là on pourra virer TOUT ce qui est interface graphique pour ne garder que la structure de chargement et de manipulation de données. Un bot se comportera comme un joueur sans interface graphique et dont la méthode PlayerImpl.tick() implémente un comportement spécifique. On pourra modifier le code pour créer un véritable serveur de bot contrôlant les mouvements d'un grand nombre de bots. Il restera à rajouter une procédure simple pour créer facilement des comptes de bots sur le serveur (type de joueur dont les données sont pré-formatées).

On arrive finalement à une architecture très souple : un ou plusieurs serveurs de bots qui sont connectés au serveur de jeu principal et peuvent ainsi fonctionner sur d'autres ordinateurs.

24 - Les rumeurs.

Statut : non développé
Référence Draft : partie 2.4.5 p27.
Pré-requis wotlas : aucun.

Description : rajouter un système de rumeurs à wotlas. Voir le draft pour plus de détails.

Développement : cf. draft.

25 - Affichage de la santé du personnage.

Statut : non développé
Référence Draft : aucune.
Pré-requis wotlas : caractéristique jdr : santé du personnage.

Description: rajouter un effet graphique affichant la santé du personnage, éventuellement son souffle aussi (plus la personne est essouflée moins elle peut se déplacer et elle doit s'arrêter qq temps pour récupérer).

Développement: Créer un LifeDrawable relié au personnage principal ( DataManager.getMyPlayer() ) et qui est rajouté au GraphicsDirector à la connexion.

26 - Ajout d'une liste d'effets graphiques liés aux cartes du jeu.

Statut : non développé
Référence Draft : aucune.
Pré-requis wotlas : aucun.

Description : Une carte pourrait posséder une liste d'effets graphiques à utiliser : oiseau survolant aléatoirement la carte, nuages, pluie, etc...

Développement : Une InteriorMap pourrait posséder une liste de XXXDrawables à utiliser. Ces XXXDrawable serainent rajoutés au moteur graphique lors du chargement de la carte... le BirdDrawable afficherait une animation d'oiseau survolant la carte par exemple.

27 - Ajout d'une liste d'effets sonores liés aux cartes.

Statut : non développé
Référence Draft : aucune.
Pré-requis wotlas : aucun, associé aux musiques.

Description : de même que pour les effets graphiques on pourrait mettre une liste d'effets sonores à jouer en boucle sur certaines cartes (bruit de fond de la mer sur l'entrée de Tar Valon par exemple).

Développement : Editer la classe wotlas.common.universe.InteriorMap et wotlas.client.InteriorMapData. Il faudra rajouter une option à la librarie de sons pour pouvoir jouer en boucle un son.

28 - Gestion de la luminosité du personnage. Masque de luminosité.

Statut : développé !!
Référence Draft : aucune.
Pré-requis wotlas : aucun.

Description : La luminosité des cartes de wotlas varie... pour éviter que les personnages ne soient toujours aussi bien éclairé quelque soit leur emplacement sur la carte, on pourrait gérer leur luminosité via un masque.

Développement : Le masque de luminosité serait une image gif de taille 10 fois inférieure à la taille de la carte. Il serait composé de plusieurs niveau de gris (255). Comme pour le masque des collisions, il faudrait charger l'image, la convertir en tableau 2D de byte, et disposer d'un filtre wotlas.libs.graphics2D.filter.BrightnessFilter pour faire varier la luminosité des personnages en fonction de ce qu'indique le masque.

29 - Gestion de l'argent dans le jeu.

Statut : en cours
Référence Draft : aucune.
Pré-requis wotlas : gestion des objets.

Description : Rajouter l'argent comme objet dans le jeu (pièces, bourses). Etudier l'utilisation que l'on pourrait en faire dans le jeu : vente de conseils, achats, placements, etc... Salaires, etc...Connaissances liées à l'argent (talent de marchand, etc...)

Développement : à voir en fonction de ce qui aura été étudié.

30 - Gestion des déplacements sur la carte du monde. Moyens de transport.

Statut : non développé
Référence Draft : aucune.
Pré-requis wotlas : gestion des objets, gestion de l'argent.

Description : Etudier et remanier le système de déplacement sur la carte du monde. Etude de faisabilité. On était parti dans l'idée que les voyages seraient très lents sur la carte du monde (comme dans la réalité) et ce afin de renforcer la notion d'espace et de voyage. Lorqu'un joueur se déconnecte le voyage commencé est, depuis la version 1.0 de wotlas, sauvegardé sur le serveur. Ce qui fait que quand le joueur se reconnecte plus tard le voyage a continué pendant son absence. Ce qu'il faut voir c'est la possibilité de choisir son moyen de locomotion : à pied, à cheval, en calèche, caravane... on pourrait ainsi faire que le voyage serait très lent à pied (2 jours pour traverser la carte), mais beaucoup plus rapide à cheval...

Développement : afficher le temps restant avant arrivée à destination sur la carte du monde, trouver un moyen de proposer le choix du moyen de locomotion au joueur (rajout d'une carte spéciale Transports sur la carte de la ville ? choix lors du déplacement ? ). Bref toutes les idées seront les bienvenues...

31 - Tel'aran'riod et autres mondes parallèles.

Statut : non développé
Référence Draft : aucune.
Pré-requis wotlas : Etat "sleeping du joueur" (cf. projet 42). à voir selon le contenu.

Description : Dans les livres de Jordan il existe de nombreux mondes parallèles (Les Voies, les Pierres Portes, le monde des rêves). Il s'agit d'étudier leur application à wotlas : s'agit-il seulement de l'ajout de nouvelles cartes ? ou faut-il mettre en place d'autres aspects que le simple passage d'une carte à une autre ? Dans le Tel'aran'riod ( monde des rêves ) le système de déplacement se fait par la nécessité : en pensant à un endroit on peut s'y retrouver ; parfois des joueurs qui rêvent peuvent se retrouver dans Tel'aran'riod mais en disparaissent quand ils se réveillent ...

Développement : à voir. Il y a sans doute des aspects interessants à développer. Faire des propositions.

En tout cas il faut prendre en compte que le corps du personnage reste dans le monde de départ pendant qu'une autre image du joueur évolue dans Tel'aran'riod. Pour réaliser ça il faudra : (1) modifier le GameAccount pour qu'il puisse posséder un deuxième champs "player" persistant representant le joueur évoluant dans Tel'aran'riod, (2) ce deuxième joueur est créé quand le personnage entre dans Tel'aran'riod et est détruit quand celui-ci le quitte, (3) si le joueur se déconnecte alors qu'il est dans Tel'aran'riod son personnage y reste, de toute manière le serveur sauvegardera les deux champs "player" du compte du client s'ils existent (4) quand le joueur se reconnecte au jeu le serveur lui renvoit le personnage qui se trouve dans Tel'aran'riod (5) si un personnage du jeu effectue l'opération "réveiller" sur un personnage endormi, qui se trouve dans Tel'aran'riod et qui est connecté au jeu, ce dernier est immédiatement retiré de Tel'aran'riod et passe à l'état réveillé.

32 - Communications inter-serveurs

Statut : développé
Référence Draft : partie 3.1 p34.
Pré-requis wotlas : aucun.

Description : On avait prévu que certains batiments puissent être sur des serveurs différents. Pour simplifier la tache (et par nécessité de gain de temps) on pourra faire que ce soient les villes du jeu qui pourront être sur des serveurs différents. Chaque ville dans wotlas possèdera donc un l'identifiant du serveur qui la possède. La carte du monde reste partagée par tous les serveurs. Quand un joueur quitte une ville et passe sur la carte du monde, il reste sur son ancien serveur. Dès qu'il arrive sur une ville, si celle-ci ne se trouve pas sur son serveur, le compte du client est déplacé sur le serveur distant et la connexion est fermée puis réouverte sur le nouveau serveur.

Développement : Chaque serveur wotlas est en fait le regroupement de 3 serveurs :

- un serveur de jeu où évoluent les joueurs ( client-serveur, GameServer, développé )
- un serveur de création de compte ( client-serveur, AccountServer, développé )
- un serveur de transfert de comptes ( serveur-serveur, GatewayServer, non développé )

Le GatewayServer fournira le service de déménagement/réception de comptes entre serveur. Les services qu'il proposera seront ensuite utilisés pour effectuer les déplacements de comptes nécessaires. Il faudra prévenir le client si la transaction se passe mal.

33 - Internationalisation de wotlas. Gestionnaire du texte. Centralisation des resssources.

Statut : non développé
Référence Draft : aucune.
Pré-requis wotlas : aucun.

Description : Disposer d'une version de wotlas intégralement en français, en anglais, en italien, etc... Posséder un gestionnaire de ressources : noms d'images, de musiques, de sons, texte, config, etc... ceci afin de pouvoir controller les appels aux fichiers et transformer wotlas en un ou plusieurs fichiers JAR.

Développement : Comment faire ? vos idées seront les bienvenues... en voici une : Créer un LangManager qui serait un service universel de wotlas ( méthode statique LangManager.getDefaultLangMaager() pour le récupérer ) Par exemple si dans une interface qcq du client il y a le texte "Enter here your password", le LangManager possèderait deux méthodes : getInterface2Password(), setInterface2Password() pour récupérer/sauvegarder le texte à afficher. Le LangManager serait chargé au démarrage de wotlas (via le PersistenceManager) avec tous les textes à afficher dans une langue donnée. Dans le OptionPanel on pourrait alors choisir sa langue, en désignant quel fichier texte de langue ( english.txt, french.txt, etc... ) il faut charger dans le LangManager.

C'est fastidieux certes : chaque ligne de texte devra être chargée via le LangManager.

34 - Suppression des singletons en trop dans le code de wotlas.

Statut : développé - centralisation de la gestion des ressources - prochaine étape sera Java Web Start.
Référence Draft : aucune.
Pré-requis wotlas : auncun.

Description : Comme on me l'a fait remarquer très justement, il y a un léger abus de Singleton dans l'architecture de wotlas (cf. forum 'Open Discussion' pour une discussion/présentation autour du motif de programmation Singleton). Le but est ici de supprimer les Singleton qui sont en trop dans le code. Il faudra surtout voir si le fait de les retirer ne risque pas de compliquer trop le code... à étudier.

Développement : Pour une classe A qui utilise par exemple le DataManager en l'appellant par sa méthode statique DataManager.getDefaultDataManager()... il faudrait éviter ça en passant à A la référence du DataManager par une méthode init().

Cela peut vouloir dire beaucoup de modifications si l'instance de la classe A est possédée par une instance d'une classe B qui ne possède pas de référence au DataManager. Cette classe B devrait alors aussi recevoir la référence au DataManager via une méthode init(). Et ainsi de suite...

Aussi un autre DANGER est celui de la conservation de référence : avec les ajouts de méthodes init() à A et B ces deux instances vont garder en mémoire une référence au DataManager. Il ne faudra pas oublier de les supprimer quand les instances A et B seront supprimés (vraiment nécessaire s'il y a des hashtable qui rentre dans le jeu).

35 - Tests de wotlas sous Java 1.4 et sous Linux.

Statut : développé - merci à Knut pour les tests
Référence Draft : aucune.
Pré-requis wotlas : aucun.

Description : Tester wotlas avec la nouvelle version du jdk et aussi sous Linux.

Développement : espérons qu'il n'y en ait pas. Dans Java 1.4 le moteur de rendu graphique a été complètement rénové. Il faudra voir ce que cela donne. Pour éviter de demander à tous les utilisateurs de désinstaller leur java 1.3 et de télécharger les 9Mo du jre1.4 wotlas DEVRA continuer avec l'API java 1.3 tout en fontionnant avec la 1.4.

36 - Détection de fin de connexion côté serveur (librairie réseau).

Statut : développé !!
Référence Draft : aucune.
Pré-requis wotlas : auncun.

Description : Pour l'instant le serveur ne peut pas détecter la fin de la connexion réseau car la méthode accept() de java 1.3 est bloquante et ne lève pas d'exception quand la connexion est coupée. DONC pour éviter ce problème tout en restant au niveau de l'api java1.3 ( il y aurait des solutions simples à ce problème avec l'api java 1.4)
la solution sera de rajouter un thread de surveillance des interfaces réseaux.

Développement : Rajouter au package wotlas.libs.net.utils une classe utilitaire héritant de Thread. Cette classe vérifiera toutes les trente secondes que l'interface réseau du serveur existe toujours ! Si ce n'est plus le cas l'utilitaire devra le signaler aux serveurs ( rajouter un booléen interfaceNoLongerExist à la classe wotlas.libs.net.Server). Le serveur sort du accept() toutes les deux minutes il pourra alors voir que l'interface ip n'existe plus et balancer une exception SocketException afin que l'erreur soit traitée... (le traitement de l'erreur a déjà été rajouté dans le catch(SocketException), mais il n'a put être traité ).

Utiliser un pattern Observer/EventListener pour la communication entre l'utilitaire et les serveurs. L'utilitaire pourra avoir plusieurs serveurs comme Observer/EventListener.

37 - Console d'administration/gestion des clients.

Statut : à demi développé - il manque un GUI d'administration des comptes
Référence Draft : aucune.
Pré-requis wotlas : aucun.

Description : Rajouter une console de commande qui permet de modifier certains paramètres sur un compte, de le sauvegarder sur disque, de le recharger en mémoire, ou de le supprimer.

Développement : à voir. La console doit-elle être externe au serveur wotlas ou faire partie du serveur ? On pourrait envisager le lancement de la console par le serveur. Par exemple quand on rajoute l'option -admin sur la ligne de commande.

38 - Prévenir les surpopulations

Statut : non développé
Référence Draft : p50.
Pré-requis wotlas : aucun.

Description : Bon on est certes loin d'avoir des problèmes de sur-population dans wotlas, mais on peut considérer que ce développement est de la prévention. Il s'agit d'éviter que trop de joueurs connectés se retrouvent au même endroit ( ah! l'épineux problème des foules dans les mondes virtuels ). Par défaut la limite est de 30 personnes mais on peut l'augmenter ou la diminuer selon le besoin : chaque pièce d'une carte possède sa limite propre ( entier maxPlayers).

Développement : Actuellement, quand un joueur entre dans un MapExit (zone rectangulaire representant un changement de carte) on envoie une demande d'autorisation au serveur pour changer de carte ( CanLeaveXXXMessage ). Dans 99% des cas le serveur réponds OUI ( YouCanLeaveMessage ) et s'il détecte une erreur de synchronisation avec le client il réponds RESET ( ResetPositionMessage ) en demandant au client de se remettre à la bonne position/carte.

Ce que nous voulons rajouter ici c'est la possibilité au serveur de répondre NON si la destination du joueur est surpeuplée. Quand le serveur reçoit une demande "CanLeaveXXXMessage" il peut vérifier le nombre de joueurs sur la destination ( myMap.getPlayers().size() ) et si le nombre myMap.maxPlayers de la destination est dépassé, il renverrait alors un NON ( MaxPlayerReachedMessage ) qui afficherait juste un message d'alerte côté client. C'est tout.

J'ajouterais aussi que seul les passages d'une carte de {ville,monde} vers une carte intérieure ( InteriorMap ) seraient à controller (CanLeaveTownMapMessage et CanLeaveWorldMapMessage).

Une fois que le contrôle fonctionnera il faudra le modifier pour utiliser le nombre de personnes connectées ( cumuler les player.isConnected() ) et non se satisfaire d'un "myMap.getPlayers().size()" qui représente le nombre total de joueurs ( connnectés et non connectés ).

39 - Home Sweet Home.

Statut : non développé
Référence Draft : aucune.
Pré-requis wotlas : aucun.

Description : Permettre à un joueur de revenir automatiquement à un emplacement quand il se déconnecte A CONDITION que cet emplacement se trouve dans la même ville. Revenir à la maison automatiquement en quelque sorte...

Il faudra aussi étudier si cela ne risque pas de constituer un échapatoire aux personnes poursuivies...


Développement : Comment faire ? une idée simple de départ : rajouter des infos dans l'onglet Away ( AwayPanel ) côté client (rajouter un ascenseur s'il n'y a pas la place). Le client aurait alors le choix entre deux options quand il se déconnecte :

- rester là ou il est
- revenir à la position :

Après les ":" de la dernière option il y aurait un bouton "Save Position". En cliquant sur le bouton le joueur désignerait ainsi sa position courante comme celle où il désire revenir ( HomePosition ). Rien de plus simple ainsi de désigner sa maison ! un clic !

Attention à la gestion des erreurs : si le joueur change de ville sa HomePosition devra être réinitialisée. De plus :

- quand le joueur appuie sur "Save Position" il faut envoyer un message au serveur pour signaler le changement de HomePosition ( champs persistants à rajouter à wotlas.server.PlayerImpl).

- quand le joueur se déconnecte il faudra modifier le wotlas.server.PlayerImpl.connectionClosed pour bien envoyer les bons messages (retrait du perso de la carte, ajout du perso à la nouvelle carte...).

40 - Rajouter des sons d'appels.

Statut : développé et même enrichi grâce à xeno
Référence Draft : aucune.
Pré-requis wotlas : aucun.

Description : Permettre à l'utilisateur de siffler pour capter l'attention de qq'un... si vous avez des idées sur des sons que l'on pourrait rajouter dans le jeu et dont chaque joueur pourrait être l'origine.

Développement : à voir. On pourrait rajouter des commandes au chat /whistle etc... qui seraient ainsi répercutée au niveau sonore SHOUT et seraient transformées en son en arrivant chez les clients destinataires. Un timestamp serait sauvegardé pour interdire d'envoyer plus d'un son toutes les 10 secondes. Pas d'abus !

41 - L'envoi / réception de courrier dans le jeu

Statut : non développé
Référence Draft : aucune.
Pré-requis wotlas : aucun.

Description : Permettre à l'utilisateur d'envoyer du courrier à des personnes dont il pourrait garder le nom dans un carnet d'adresse interne au jeu. Lors de l'envoi il faut choisir le moyen de transport : direct (remise en main propre, à condition d'être près de la personne), livreur (peu cher, lent sur de grande distances), livreur express ( coût moyen, un peu plus rapide), pigeon voyageur (coût élevé sauf si on possède des pigeons, très rapide). Selon le mode choisi le message sera gardé plus ou moins longtemps par le serveur avant envoi vers le client.

Développement : Ce développement n'est pas forcément très compliqué. Côté serveur on peut imaginer que le PlayerImpl possède un objet 'Messenger' qui est chargé de stocker ( de manière persistante ! ) les messages envoyés par d'autre joueurs, le délai d'attente avant le transfert de chaque message vers le client dépend du mode (direct, livreur, pigeon ) que l'émetteur a choisi. Par exemple si le mode est le mode livreur, le message attendra 6 heures avant de pouvoir être transféré au client. Si on veut que le message soit délivré instantanément on peut toujours utiliser le mode 'direct'.

Quelques points à résoudre :

- le temps d'attente avant réception devrait dépendre de la distance avec le récepteur. Il faudra sans doute créer un moyen pour évaluer la distance entre deux destinations. On pourra noter que l'on peut calculer la distance entre deux villes à partir de leur position sur la carte. On pourra assimiler la position de l'émetteur et du récepteur à celle de leur ville + un temps de traitement constant ( livreur = +3h le temps, pigeon = + 5 minutes).

- est-ce que le client récupère son courrier directement, ou quand il appuie sur un boutton "vérifier courrier", ou faut-il un endroit spécial nommé "poste" où un bot attendrait qu'on lui prononce le mot "courrier" pour nous transmettre notre courrier... à vous de voir.

- ou rajoute-t'on l'interface cliente de réception du courrier ? un nouvel onglet style Info, Away ? de plus il faudra rajouter quelques méthodes simples au PersistenceManager pour enregistrer/charger le courrier stocké sur le disque du client.

 

42 - Dormir.

Statut : non développé
Référence Draft : aucune.
Pré-requis wotlas : aucun.

Description : Permettre à l'utilisateur de déclarer que son personnage "dort". Quand on clique sur un personnage le texte apparaissant au dessus du personnage serait "Elisane Tishar (sleeping)". L'effet graphique permettant de repérer les personnages qui dorment de ceux qui ne dorment pas sera à étudier ( on envisageait de remplacer l'image par celle du personnage allongé). L'état "sleeping" permettra d'indiquer aux autres joueurs que même si on est connecté on est temporairement absent.

Autre fonctionalité à envisager pour plus tard : pour passer au monde Tel'aran'riod il faudra être endormi. On pourra ajouter la possibilité de réveiller un joueur qui dort, possibilité qui servira à tenter de faire revenir les joueurs qui se promèraient dans le Tel'aran'riod. Réveiller un joueur échoue si celui-ci n'est pas dans le Tel'aran'riod.

Développement : faut-il rajouter un boutton d'état "sleeping / awake" ? ou une commande du chat "/sleep" ? dans les deux cas il faudra rajouter un état booléen sleeping aux PlayerImpl ainsi qu'à l'interface, des messages associés pour propager le changement d'état au serveur. Pour tout ça on pourra s'inspirer de ce qui a été fait avec les messages "AwayMessage" et la propagation de l'état du personnage à la connexion/déconnexion.

 

43 - Détection Améliorée de l'interface réseau.

Statut : développé
Réference Draft: aucune.
Pré-requis Wotlas : aucune.

Description : Je pense que nous pourrions migrer le code server vers Java 1.4 ... avec la nouvelle java.net.NetworkInterface nous pourrions détecter les changements d'IP et automatiquement transférer le nouveau server-X.cfg.adr au serveur web wotlas ...

Développement : Si vous êtes intéressés par le boulot OU si vous connaissez quelqu'un qui pourrait être intéressé, en voici la description : développer un petit utilitaire java 1.4 qui

(1) utiliserait la nouvelle java.net.NetworkInterface
(2) fournirait une méthode pour récupérer l'IP d'une interface à partir de son nom
(3) fournirait une façon de surveiller une interface réseau (timer/thread)

* enregistrer une interface réseau à surveiller (seulement une)
* détecter quand son IP change
* fournir une interface listener pour notifier aux listeners le changement.

Cet utilitaire sera inclus dans le package wotlas.libs.net.utils et utilisé par le serveur wotlas. L'idée serait de donner au serveur le nom de l'interface à laquelle il est associé ... Le serveur réagirait aux changements d'IP en mettant à jour sa config en appelant un script de transfert de configuration. Pour Unix, les interfaces réseaux sont habituellement eth0, eth1, le0, etc ... mais sous Windows ... ???