kassie team mailing list archive

[Kredh <kredh@xxxxxxx>]

Salut tous,

Je vais m'amuser à vous vouvoyez comme si vous étiez plus de 'un' 
actuellement dsl Nitrate ah ah. Bon bref restons sérieux.

Je travaille aujourd'hui sur les interpréteurs de commande. Je doute de 
pouvoir aller très loin, mon emplois du temps a encore subi des 
changements drastiques. Mais la théorie est en place.

Les choses ne sont pas encore très claires dans mon esprit alors je VOUS 
soumet ce sujet de réflexion.

Les contextes tels que je les ai imaginé sont des formes d'interpréteur, 
de chaînon d'un interpréteur pour être très précis.

Quand on demande au joueur d'entrer le nom de son compte, c'est un 
contexte. Le contexte va attendre que le joueur entre un nom de compte 
et agir en fonction de ce qu'il reçoit. Si le nom est invalide, il va 
lui demander de l'entrer à nouveau. Si le nom est OK et qu'il existe 
déjà, on le redirige vers le contexte 'entrer le mot de passe pour un 
compte existant'. Si le compte n'existe pas, on le redirige vers le 
contexte 'entrez le mot de passe du nouveau compte'.

Les contextes doivent donc être fait pour accepter certains schémas, en 
rejeter d'autres, et rediriger dans l'un ou l'autre cas vers d'autres 
contextes (ou vers le même).

Les contextes dans mon esprit sont de plusieurs formes :

-    L'entrée d'information (utile pour la connexion et la création de 
compte)
-    L'interpréteur de commande (j'y reviens un peu plus bas)
-    Les éditeurs
-    Les canaux (je ne le détaillerai pas ici)

Les éditeurs ce sont ces fenêtres textuels permettant d'éditer assez 
intuitivement un objet. Il existe sur Vancia pas mal d'éditeurs destinés 
à la création, un pour éditer la salle, un pour éditer un objet, un pour 
éditer un prototype de bot et j'en passe. Pour les joueurs il existe 
l'éditeur de description personnel et l'éditeur des options.

Le principe des éditeurs est assez simple : on navigue dedans en entrant 
une ou quelques lettres raccourcis. Fenêtre classique :

* Editeur de la salle ...
(T)itre de la salle :
(D)escription
(S)orties
...

En tapant S puis entrée, le bâtisseur est placé dans la sous-fenêtre 
'sortie' sui peut proposer de configurer les sorties (assez logiquement).

Les éditeurs sont déclinables en plusieurs objets et pour l'instant il 
est trop tôt pour en faire la liste, ce travail a d'ailleurs déjà été 
fait en partie sur Vancia donc j'aurai une base.

Le type de contexte 'interpréteur de commande' est peut-être un peu 
moins évident. Jusqu'ici je n'en vois qu'un seul : le contexte 'mode 
connecté' qui recensera TOUTES les commandes que les joueurs pourront 
entrer en étant connecté au jeu.

Voilà l'idée maîtresse. Chaque contexte possède soit une liste d'entrées 
possibles, soit un schéma de validation, et des actions à faire dans tel 
ou tel cas.

Ca, ça semble assez clair dans mon esprit et ça me semble assez viable 
comme idée.

Ce que je VOUS propose ici c'est de réfléchir aux interpréteurs de 
commande. J'aimerai que pour chaque commande on ait une syntaxe 
générique qui se charge du boulot répétitif. En gros, quand vous entrez 
la commande 'examine', vous devez préciser après soit un fragment d'un 
nom d'objet, soit une balise de description. L'idée est d'avoir un 
schéma directeur de la commande pour extraire ces informations et 
retourner au joueur une erreur si sa syntaxe n'est pas correcte.

Même les commandes les plus simples auraient des schémas assez durs à 
mettre en place, j'en ai conscience. Voilà à quoi on devrait arriver (en 
gros hein) :

def examine(...)
    """ma commande examine"""
    schema = parser_schema("<ombjet dans eq>/<objet dans inv>/>objet 
sur sol>/<élément de desc> as objet_a_examiner")
    # Dans schema.objet_a_examiner, on a maintenant l'objet (se 
trouvant soit dans l'équipement du joueur, soit dans son inventaire, 
soit sur le sol), soit un élément de la description
    joueur.envoyer(schema.objet_a_examiner.description)

Je ne sais pas si c'est très clair. Biensûr, le schéma que je vous met 
au-dessus est plutôt simpliste, lourd à écrire et pas très pratique. Sµi 
VOUS en avez envie, je vous encourage à réfléchir à cette idée de schéma 
en prenant les commandes que l'on retrouve sur la plupart des MUDs et 
essayer de dégager :

*    Une syntaxe de la commande
*    La liste des schémas dont on aurai besoin
*    Eventuellement leur syntaxe

Je ne suis pas sûr que ce soit très clair, je posterai des compléments 
si c'est nécessaire.

Kredh