Objectifs du travail
Avant de nous lancer dans l'édition et la création du MOO à proprement parler, nous avons défini nos objectifs au niveau techniques aussi bien que personnels pour l'accomplissement du travail.
Cette définition s'est faite durant la semaine présentielle et au travers des blogs qui permettaient de faire le point après une discussion ou une lecture, et de le faire savoir à l'autre. Les buts se sont également précisés par la suite, au fil des lectures et des recherches théoriques.
Description des objectifs
- Expérimenter le MOO
- Un MOO est un univers virtuel, en cela déjà il est fascinant. Les possibilités interactives et narratives à l'intérieur d'un tel dispositif sont quasiment infinies et c'est bien ce qui nous a intéressés. Le MOO ne pêche en fait que par son aspect rebutant de mode texte. Nous sommes passés au dessus de ces considérations car il représentait un moyen d'une part, de créer un petit jeu relativement complet en l'espace de quelques semaines. Et d'autre part, de nous introduire à des concepts de programmation et de gestion de projet très intéressants.
- Créer un univers ludique
- Autant expérimenter en créant quelque chose d'amusant, et quelque chose qui a depuis longtemps trouvé sa place dans des MUD et MOO : Un jeu de rôles. Le pari se situe autant au niveau de la création d'un monde qui se tient que d'un scénario peu linéaire, qui laisse une grande liberté d'action au joueur.
- Faire un lien avec l'éducation/formation
- Le travail se situant dans le cadre du diplôme Staf, nous avons voulu nous fixer comme objectif supplémentaire de faire apprendre quelque chose aux gens qui viendraient jouer dans notre monde. De plus, vu le nombre de plate-formes MUD/MOO existantes, en créer une qui a un objectif supplémentaire que : s'amuser, permet certainement de la distinguer un peu.
Formalisation des objectifs
Les objectifs que nous nous sommes fixés sont disponibles sur la page présentant notre projet. Nos intérêts principaux ont été de trouver un MUD/MOO qui convienne, de conceptualiser une fiction à l'intérieur, et enfin de parvenir à programmer et à modeler notre univers comme nous le voulions.
Réalisation
Les workpackages (WP)
WP 1 : Explorer des mud/MOO et en trouver un pour nous
Nous avons commencé par des recherches théoriques sur le web pouvant nous permettre de nous faire une meilleure idée de ce qu'était l'outil sur lequel nous passerions tant d'heures. Les conclusions de ces recherches sont présentées dans la partie introductive. Cependant, la diversité des MUD et de leurs descendants est presque aussi grande que le nombre de développeurs. Il en existe à peu près pour tous les usages et pour tous les goûts. C'est pourquoi, d'abord dans un souci de simplicité, nous avons décidé d'utiliser un moteur semblable à celui de TecfaMOO, à s'avoir LambdaMOO.
WP 2 : Définir notre scénario
Nous avons réfléchi à un scénario qui soit le moins linéaire possible. En partant de nos expériences de MUD/MOO, de jeux vidéos et de jeux de rôles, nous avons pu inventer un petit monde pas très compliqué, médiéval-fantastique, qui nous permettait de ne pas nous limiter dans notre imagination et de placer les concepts à apprendre.
Pour créer les intrigues, c'est à dire les missions que les joueurs doivent remplir, nous avons commencé par définir les commandes MOO que nous voulions apprendre aux joueurs. Il s'agit de commandes de base (déplacement, look, say, examine, @gender, @describe, etc.). La liste complète est disponible en annexe. Ensuite, nous nous sommes demandés quel personnage pourrait détenir quelle information (quelle commande). Nous avons alors inventé un service que les joueurs pourraient rendre à ce personnage, contre lequel celui-ci révèlerait son secret. Ensuite nous avons élaboré un système de test des connaissances : le joueur doit, pour vaincre la sorcière montrer qu'il connaît un tas de commandes. En plus, pour s'assurer que tout le monde jouera un peu, nous avons créé une quête un peu plus principale dans laquelle le joueur doit contacter les chef des trois races présentes pour obtenir l'incantation (phrase) qui viendra à bout de la sorcière.
Afin de ne pas être submergés de travail, nous avons tenté un maximum de réaliser des intrigues pouvant se résoudre simplement en échangeant des paroles ou des objets avec les différents protagonistes. Ainsi peu de verbes sont à programmer.
WP 3 : Réaliser et programmer le scénario
Certainement la partie la plus importante du travail : réaliser le dispositif. Nous avons donc retroussé nos manches et nous avons commencé par nous plonger dans quelques tutoriels, mais peu existent pour les programmeurs. Il a donc fallu se baser sur des manuels. Nous avons commencé par créer les différentes salles que nous avions prévues et puis, de plus en plus profondément, nous avons expérimenté avec des objets et des robots. Notre scénario repose en fait sur des robots qui détiennent les informations et la plupart des objets nécessaires aux diverses quêtes. La compréhension de leurs scripts était donc nécessaire à l'édition de nouveaux. C'est bien entendu dans cette partie que la plupart des problèmes sont survenus. Nous avons également fait jouer deux personnes (1h30 et 20 minutes). Observer des utilisateurs novices dans notre moo nous a permi de mettre à jour un grand nombre de problèmes suplémentaire. Tous n'ont d'ailleurs pas trouvé de réponse à l'heure actuelle. Le compte rendu des observations est disponible en annexe.
WP 4 : Analyser nos difficultés
Pendant la phase de développement, nous avons cherché à identifier nos problèmes et tenté d'y apporter une solution ou au moins un regard différent. Il ressort que la plupart des ennuis étaient dus à notre niveau technique. D'innombrables pertes de temps en incompréhensions face à la machine ! d'autres pertes de temps dues à une mauvaise programmation initiale qui obligeant à modifier une par une certaines propriétés sur tous les robots... Bref, les ennuis étaient multiples. Ils étaient bien entendu pour la grande part d'us à notre manque de connaissances en programmation (de ce moo), liées à des lacunes de compréhension du fonctionnement global du moteur. Tout cela couplé à une préaration du scénario relativement détaillée mais pas jusque dans les moindres interaction nous fit nous engager dans des cul-de-sac et les modifications étaient souvent périlleuses !
Observations et remarques sur notre réalisation
Les utilisateurs ayant testé notre moo nous ont aidé à nous rendre compte d'un grand nombre de faiblesses. Celles-ci sont plus ou moins facilement renforçables. D'autres problèmes nous sont également apparus pendant la phase d'édition / programmation. Un certain nombre de ces problèmes sont décrits ci-dessous avec diverses observations concernant les différents types d'objets peuplant notre moo.
Les salles et les objets
Une soixantaine de salles et une quinzaine d'objets génériques ont été prévus dans notre scénario. Cela représente une certaine quantité de travail car tous doivent être non seulement créés mais aussi décris, testés, placés au bon endroit et enfin (pour les salles) liées aux bonnes salles par des chemins.
Les salles en elles mêmes purent être créées relativement rapidement, il suffisait de suivre le plan et d'utiliser la commande @create, ou @dig. La topologie fut un peu plus problématique, et ce qui par dessus tout pris du temps fut la description de chaque salle.
Au niveau des objets, la nécessité fut de créer des objets génériques, portant une description et éventuellement des propriétés (la grande épée contient le verbe menacer). Ces objets génériques devant servir de parents (de modèles) pour la création des objets qui seraient utilisé dans le jeu. Cette astuce permet, non seulement d'économiser du temps en rédaction de description lorsqu'un objet a plusieurs occurrences dans le monde, mais surtout de permettre aux robots de reconnaître plusieurs objets appartenant à la même catégorie (même parent) lorsqu'ils doivent en recevoir un (voir plus bas).
Problèmes rencontrés
Nous avons rencontrés quelques problèmes de topologie en construisant les salles, en effet plusieurs sorties d'une même salle portaient parfois le même nom, ce qui rendait impossible le passage par l'une ou l'autre, ce problème fut facile à résoudre, nous dûmes simplement changer quelques noms.
Les objets sont malheureusement peu nombreux et si plusieurs joueurs jouent en même temps, il se peut qu'il soit impossible de résoudre toutes les quêtes par manque d'objets. Les robots qui donnent des objets ne disposent en effet que d'un seul objet à chaque fois, une fois donné celui-ci ne peu plus être distribué à d'autres joueurs.
Améliorations possibles
- D'une manière générale les descriptions gagneraient à être étoffées (aussi bien pour les salles, que pour les objets et les personnages).
- Le problème du manque d'objets doit être résolu au plus vite si nous voulons sérieusement pouvoir faire jouer plusieurs personnes en même temps.
- La solution que nous utilisons en attendant de pouvoir créer des objets automatiquement disperse le peu d'objets à disposition des joueurs, il est alors nécessaire de ranger périodiquement le moo (voir plus bas).
- La page de login est austère et manque d'informations pour guider le débutant. De plus la description de la zone d'arrivée devrait comporter plus d'indications, de mots-clés et d'aides.
Les robots
Les personnages peuplant cet univers devaient être au nombre de 27 (ils sont 23 finalement) ont demandé une grande somme de travail. Il a non seulement fallu les créer un à un et éditer leur description (comme pour tous les objets), mais aussi modifier leurs réponses et écrire des scripts pour qu'il soit possible d'agir avec eux.
Les réponses des robots sont des phrases préprogrammées que le robot prononce en fonctions des interactions verbales que le joueur a avec lui. Ainsi si un joueur dit 'bonjour' devant l'arbre du sage, celui-ci pourra par exemple répondre 'c'est un plaisir !', 'bonjour' ou encore 'hello'. Toutes ces réponses des robots correspondent à des réponses génériques pré-programmées. Ce type de robot contient trois type de réponses : Les mots-clés, les patterns, les réponses aux questions et les réponses aléatoires.
- Les mots-clés
- Ce sont simplement des mots, si le robot identifie une série de caractères précise (et définie) quelque part dans le texte prononcé par le joueur, il dira aléatoirement une des phrases prévues (c'est l'exemple précédent avec 'bonjour')
- Les patterns
- Il s'agit de la reconnaissance d'expressions régulières : des suites de mots ou, surtout, des patterns linguistiques. Ainsi, par exemple, on sait que le mot précédent le verbe conjugué est se trouve le plus souvent être le sujet et le mot (ou la suite de mots) suivant, le complément. Il est possible grâce aux patterns de dire au robot que lorsqu'il identifie le mot est dans un phrase il doit prendre le mot d'avant et celui d'après et les mettre dans une réponse pré-programmée, par exemple : 'Vous pensez vraiment que sujet est complément ?' ou alors : 'nous parlons de quelque chose de complément, s'agit-il de sujet ?'. Il est ainsi possible de retourner les phrases du joueur et de produire une conversation plus riche.
- Les réponses aux questions
- Lorsque le robot ne peut identifier de pattern ou de mot-clé mais que la phrase du joueur était une question (qu'elle se termine par un point d'interrogation). Alors le robot prononce une phrase aléatoirement parmi celles définies dans cette catégorie.
- Les réponses aléatoire
- Enfin, lorsque le robot n'identifie rien du tout, il répond une phrase parmi celles écrites dans cette liste-ci.
Tous les robots, n'ont pas des réponses pré-programmés énormément différentes, ils réagissent tous aux mêmes types de mots ('secret', 'mission', 'bonjour', etc.). Et tous n'ont pas un grand nombre de mots-clés (moins d'une dizaine par robot), cependant les réponses données peuvent varier selon le robot, selon le caractère du personnage. Tout cela a dû être écrit bien sûr.
Au delà des aspects de remplissage de texte, les robots ont demandé beaucoup de temps car il fallu programmer des verbes spécifiques à la réalisation de nos scénarios qui n'étaient malheureusement pas prévus dans le package de base du moteur LambdaMOO. Il s'agit des verbes 'donner any to this' et 'demander any from this'. Le premier verbe vise à ce qu'un joueur puisse donner un objet à un personnage, que le personnage reconnaisse l'objet, l'accepte ou non et si oui qu'il le prenne et donne un autre objet spécifique (ou une réponse en texte) au joueur. Le second verbe (demander) permet de demander un objet précis au robot et que celui-ci nous le donne s'il le possède. Ces deux verbes, s'ils ne sont pas des scripts très complexes, nous ont demandé beaucoup de temps car nos notions de programmation n'étaient pas si avancées !
Les verbes ne sont programmés qu'à un seul endroit (sur le parent-robot), mais les propriétés (les variables) sont différentes pour chaque robot et il faut également aller changer chacune d'entre-elles à chaque modification. Tous les robots doivent également être testés.
Problèmes rencontrés
Le plus gros problème de nos robots est qu'ils ne réagissent pas à beaucoup de mots-clés. Nous n'avons pas beaucoup réfléchi à ceux-ci, à vrai dire nous avons, pour la plupart, traduit les exemples présents sur le robot générique et ajouté quelques mot-clés spécifiques au personnage, sans vraiment aller dans les détails. Ceci fait que nos robots ont très peu de conversation et si les joueurs ne sont pas bloqués car ils utilisent le mauvais synonyme du mot-clé, ils comprennent rapidement qu'il est inutile de faire des phrases, essayer quelques mots suffit !
Un gros problème subsistant encore au niveau des robots et le manque d'objets. En effet nous n'avons pas réussi à faire créer de nouveaux objets aux robots. Le script nous a résisté jusqu'au bout. En effet, lorsqu'un robot reçoit un objet et qu'il doit en donner un autre au joueur, la solution la plus simple aurait été que le robot crée un objet à ce moment là et le donne au joueur. Ce ne fut pas possible, du coup la seule solution que nous avons trouvé fut de créer des objets à l'avance et de les mettre dans les robots, le robot dispose d'un objet et le donne au joueur lorsqu'il doit. Cependant, si plus tard un autre joueur revient demander le même objet au robot, celui-ci ne pourra plus rien donner (mais il prendra quand même l'objet du joueur !). C'est un problème qui nous obligera à remettre à zéro notre base de données le plus souvent possible ou à faire de l'ordre souvent.
Lors d'une interaction avec un robot, les patterns sont analysés avant les mots-clés, ce qui a posé pas mal de problèmes car selon la phrase du sujet, le robot identifiait un pattern sans importance au lieu d'utiliser le mot-clé donnait des informations au joueur. Le joueur n'a alors aucune information et n'essaie plus le mot-clé, le croyant inutile. En fait un plus gros travail nécessiterait d'être fait au niveau des réponses des robots, d'un point de vue linguistique mais aussi dramaturgique.
Améliorations possibles
- Les patterns devraient être retravaillés pour être plus diversifiés et réagir plus efficacement aux nécessités du jeu (les mots les plus importants sont analysés en premier. Tirer plus parti du système de patterns pourrait donner des robots plus aptes à la discussion. Au besoin retoucher quelques verbes reste une possibilité
- A terme, les robots doivent être capables de créer des objets, c'est une nécessité !
Les intrigues
La création des intrigues n'a pas pris énormément de temps, et elles ont pu pour la plupart être réalisées et respectées (à très peu de choses près). Deux intrigues n'ont pas été réalisées : celle permettant de découvrir la radio (commande 'x') simplement car cette fonctionnalité n'est pas installée de base sur LambdaMOO et que l'adapter aurait demandé trop de temps. La seconde permettait de découvrir le mail, mais deux robots devaient se trouver dans la même pièce (bonjour l'ambiance !) et les impératifs de temps nous ont découragés à adapter cette intrigue supplémentaire. Enfin, la tour de la sorcière n'a pas été remplie des énigmes et embûches destinées à tester le joueur avant la confrontation avec la maîtresse des lieux (qui n'existe pas encore non plus !). Nous avons en effet privilégié un nombre d'énigmes raisonnable (une quinzaine), sans pousser le développement jusqu'au bout à tout prix. Tout c'est pas encore terminé mais démonstration est néanmoins faite de la possibilité de la chose.
Problèmes rencontrés
Les intrigues en elle-mêmes n'ont pas réellement posé de problèmes. Elles n'étaient jamais trop complexes et la non-linéarité du scénario ne peut que plaire aux joueurs. Le but est bien plus d'explorer à sa guise que de chercher 30 minutes dans la même salle pour trouver une clé.
Améliorations possibles
- Il est bien entendu possible de terminer les intrigues prévues, en particulier la tour de la sorcière, pour finaliser ce qui serait un premier module pour s'initier au MOO
- Il serait également intéressant d'ouvrir un peu plus les intrigues pour qu'en plus de leur non-linéarité, il soit possible de les terminer de plusieurs manières différentes : Avec différents types d'objets (trouvés par des manières diverses), ou en discutant avec les bonnes personnes, en s'introduisant par derrière, en usant de pouvoirs. L'idée étant de plus mélanger fiction interactive et simulation, c'est à dire de s'approcher plus de la simulation d'un univers fini qui 'se tient', dans lequel on pourrait vivre des aventures de la manière dont on le désire.
- Il est également possible d'ajouter des intrigues, des personnages ou des lieux pour enrichir l'univers.
- Pour s'approcher un peu plus des jeux de rôles, un autre défi serait de mettre sur pied un réel système de jeu avec points de vie, d'expérience et des caractéristiques. Des princesses à secourir et des donjons à explorer. Mais trop ont déjà été écrits !
Problèmes et améliorations générales
Nous avons pu remarquer que les joueurs sont vite perdus lorsqu'ils se promènent dans le monde, ils dessinent vite une carte. Nous pourrions proposer cette carte sous forme ascii dans le moo lui-même (par des descriptions dans les salles ou par un objet que les joueurs portent).
Le début de notre scénario (prise en main) est particulièrement compliqueée pour les nouveaux joueurs, ils doivent en effet emmagasiner beaucoup d'informations très rapidement. De plus, il faut le dire, les guides au début du jeu laissent à désirer. Nous les avons quelque peut améliorer mais pousser un peu l'élaboration des premières minutes de jeu serait bénéfique.
Au niveau du rangement des objets, une solution a été trouvée, il s'agit d'un ballai, rangé dans le labo. l'utilisation de cet objet (ranger ballai), permet de remettre automatiquement tous les objets déplacables dans les mains de laurs propriétaires d'origine. Cette solution fonctionne mais un initié doit visiter périodiquement le moo pour faire de l'ordre. Ce qui c'est pas forcément optimal. ne autre solution serait de remettre la base de donnée du moo à zéro de façon périodique. Enfin il devrait être possible de faire en sorte que les personnages remettent eux-mêmes les objets à leur place lorsqu'ils en reçoivent un (il faudrait néanmois tout de même ranger périodiquement le moo). Ces solutions sont possibles mais n'empèchent pas que la création de nouveaux objets au fur et à mesure serait plus efficace (mais poserait le problème de la destruction des objets en trop...)
Un gros problème qui s'est glissé dans un grand nombre de strings et de descriptions, fut que le programme TK-MOO (et son éditeur macMOOse), transcrivaient mal la plupart des accents sur certaines des machines que nous avons utilisées. Il s'ensuit, par exemple, que beaucoup de 'à' sortent 'Ã' dans les descriptions et dans les discussions. La seule solution serait de ré-éditer ces lignes de texte.