Elegante análisis de comandos en un juego de texto basado en OOP

Question

Estoy jugando con la escritura de una aventura de MUD/texto (por favor no te rías) en Ruby. ¿Alguien puede darme algún consejo sobre una solución elegante y basada en oops para analizar el texto de entrada?

Estamos hablando de nada más complejo que "poner la varita en la mesa", aquí. Pero todo debe ser suave; Quiero extender el comando establecido sin dolor, más tarde.

Mis pensamientos actuales, ligeramente simplificada:

1. Cada clase de elemento (caja, de mesa, sala, jugador) sabe cómo reconocer un comando que 'pertenece' a la misma.

2. La clase de juego comprende una especie de un lenguaje de dominio específico que implica acciones como "objeto movimiento X dentro objeto Y", "mostrar descripción de objeto X", etc.

3. La clase de juego de cada pregunta elemento en la sala si reconoce el comando de entrada. Primero, decir que sí gana.

4. Pasa el control a un método en la clase de elemento que maneja el comando. Este método reformula el comando en el DSL, lo pasa de vuelta al objeto del juego para que suceda.

Debe haber formas bien gastadas y elegantes de hacer esto. Sin embargo, parece que no puede googlear nada.

Answer 1

El Interpreter design pattern es el orientado a objetos enfoque más a analizar que yo sepa, pero estoy seguro de expertos compilador señalarán algoritmos que son más potentes.

Answer 2

dividirlo en fichas como el formato será siempre:
[comando] [objeto1] ([refering] [objeto2])

Usted puede llamar al método [comando] en la [objeto1] en su habitación y páselo [object2] si corresponde.

Answer 3

Para los intérpretes de comandos, soy bastante aficionado a este patrón simple, no tan elegante. Los patrones en lenguajes dinámicos tienden a involucrar menos cajas y líneas que los patrones 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 esta manera, agregar un nuevo comando es simplemente agregar un nuevo método. No es necesario ajustar tablas ni declaraciones de casos.

Answer 4

Ok. ¿Entonces necesitas una semántica? (turn es una acción, ilumina un objeto, en un argumento ... (me relaciono con tu comentario a dbemerlin)).

¿Por qué no definir una gramática? Humm ... Supongo que Lex y Yacc no son una opción? (dado que no es OOP en absoluto, pero lo que quiere hacer es "compilar" la entrada del usuario para producir algo - ejecutar algún código que cambie los datos de la sala, y dar salida a un resultado)

Puede tener un POO diseño para su objeto y su acción (como, todos los objetos tienen un método .describeMe() ..), y al lado de eso, un compilador de entrada + compilador.

¿Estoy completamente fuera del tema?

Editar: después de mirar al patrón intérprete señalado por Marc Seeman, que parece ser el camino a seguir en el que desea que en la programación orientada a objetos. (Pero tendrá un poco de reinventar la rueda)

Answer 5

Suena como que necesita un analizador.

Dividir la cadena de entrada en tokens (palabras). Luego alimente los tokens, uno a la vez, a una máquina de estado. Encuentro que el autómata push-down es una forma bastante intuitiva y poderosa de escribir tal stm.