Elégant commande-analyse dans un jeu de texte basé sur la POO

Question

Je suis en train de jouer avec une aventure MUD/texte (s'il vous plaît ne riez pas) dans Ruby. Quelqu'un peut-il me donner des indications sur une solution élégante, basée sur l'OOP, pour analyser le texte d'entrée?

Nous ne parlons ici de rien de plus complexe que "mettre la baguette sur la table". Mais tout doit être doux. Je veux étendre l'ensemble de commandes sans douleur, plus tard.

Mes pensées actuelles, légèrement simplifié:

1. Chaque classe d'élément (boîte, table, salle, lecteur) sait reconnaître une commande qui « appartient » à elle.

2. La classe de jeu comprend une sorte d'un domaine spécifique langage impliquant des actions telles que « objet mouvement X à l'intérieur de l'objet Y », « Description de l'exposition de l'objet X », etc.

3. La classe de jeu demande à chaque élément dans la pièce s'il reconnaît la commande d'entrée. Premier à dire oui gagne.

4. Ensuite, il transmet le contrôle à une méthode de la classe d'éléments qui gère la commande. Cette méthode reformule la commande dans le DSL, la renvoie à l'objet du jeu pour que cela se produise.

Il doit y avoir des façons élégantes et usitées de faire ce genre de choses. Je n'arrive pas à google quoi que ce soit, cependant.

Answer 1

Le Interpreter design pattern est l'approche orientée objet la plus orientée à l'analyse que je connais, mais je suis sûr que les experts du compilateur souligneront les algorithmes qui sont plus puissants.

Answer 2

diviser en jetons que le format sera toujours:
[commande] [object1] ([référent] [object2])

Vous pouvez appeler la méthode [commande] sur [object1] dans votre chambre et passez-le [object2] s'il y a lieu.

Answer 3

Pour les interpréteurs de commandes, je suis plutôt friand de ce simple, pas tout ce motif élégant. Les modèles dans les langages dynamiques ont tendance à impliquer moins de boîtes et de lignes que les modèles GOF.

class Thing 

    # Handle a command by calling the method "cmd_" + command. 
    # Raise BadCommand exception if there is no method for that command. 

    def handle_command(command, args) 
    method_name = "cmd_#{command}" 
    raise BadCommand, command unless respond_to?(method_name) 
    send(method_name, args) 
    end 

    def cmd_quit(args) 
    # the code for command "quit" 
    end 

    def cmd_list(args) 
    # the code for command "list" 
    end 

    ... 

end 

De cette manière, l'ajout d'une nouvelle commande consiste simplement à ajouter une nouvelle méthode. Aucune table ou instruction de cas ne doit être ajustée.

Answer 4

Ok. Donc vous avez besoin d'une sémantique? (tour est une action, allume un objet, sur un argument ... (je me rapporte à votre commentaire à dbemerlin)). Pourquoi ne pas définir une grammaire? humm ... Je suppose que lex et yacc ne sont pas une option? (puisque ce n'est pas du tout la POO, mais ce que vous voulez faire est de "compiler" l'entrée de l'utilisateur pour produire quelque chose - exécuter du code qui change les données de la pièce et produire un résultat)

Vous pouvez avoir une POO conception pour votre objet et son action (comme, tous les objets ont une méthode .describeMe() ..), et à côté de cela, un analyseur d'entrée + compilateur.

Est-ce que je suis complètement hors sujet?Edit: après avoir regardé le modèle d'interprète mis en évidence par Marc Seeman, il semble que ce soit la façon d'y aller, vous le voulez dans OOP. (mais vous allez quelque peu réinventer la roue)

Answer 5

On dirait que vous avez besoin d'un analyseur.

Divisez la chaîne d'entrée en jetons (mots). Ensuite, alimentez les jetons, un à la fois, sur une machine d'état. Je trouve que l'automate push-down est plutôt intuitif et puissant pour écrire un tel style.