data-structures - vehiculos - services flhsmv gov mvcheckweb

RPG diálogo motor/estructura

Question

Siempre me han interesado las estructuras de datos involucradas en un juego de rol (RPG). En particular, tengo curiosidad por el diálogo y las acciones basadas en eventos.

Por ejemplo: si me acerco a un NPC en el punto x del juego, con los elementos y y quests z , ¿cómo averiguaría lo que el NPC tiene que decir? El diálogo de bifurcación y la respuesta a la entrada del jugador parece tan trivial como tener un script definido, y la entrada del usuario hace que el lector del script salte a una línea en particular en el script, que tiene un conjunto correspondiente de líneas de respuesta (como una elección de su propia aventura)

Sin embargo, unir la lógica para determinar si el jugador tiene ciertos elementos y completar ciertas misiones parece arruinar realmente este modelo basado en script.

Estoy buscando ideas (no necesariamente ejemplos de lenguaje de programación) sobre cómo abordar todo este diálogo y lógica, y separarlos para que sea muy fácil agregar nuevo contenido de ramificación, sin profundizar demasiado en el código.

Esta es realmente una pregunta abierta. No creo que haya una sola solución, pero sería bueno hacer rodar la pelota con algunas ideas. Como diseñador más que programador, siempre me interesan las formas de separar el contenido y el código.

Answer 1

Por ejemplo: si me acerco a un NPC en el punto x del juego, con los elementos y y quests z, ¿cómo averiguaría lo que el NPC tiene que decir? El diálogo de bifurcación y la respuesta a la entrada del jugador parece tan trivial como tener un script definido, y la entrada del usuario hace que el lector del script salte a una línea en particular en el script, que tiene un conjunto correspondiente de líneas de respuesta (como una elección de su propia aventura)

Sin embargo, unir la lógica para determinar si el jugador tiene ciertos elementos y completar ciertas misiones parece arruinar realmente este modelo basado en script.

De ningún modo. Simplemente factoriza los condicionales en los datos.

Digamos que tiene su lista de diálogos, numerados del 1 al 400 o cualquier otro ejemplo, como los ejemplos de libros Elija su propia aventura. Asumo que cada diálogo puede consistir en el texto hablado por el NPC, seguido de una lista de respuestas disponibles para el jugador.

Entonces, el siguiente paso es agregar los condicionales allí, simplemente agregando condiciones a cada respuesta. La forma más fácil es hacer esto con un lenguaje de scripting, de modo que tenga un código corto y simple que devuelva Verdadero si esta respuesta está disponible para el jugador y Falso si no lo está.

p.ej. (Formato XML, pero podría ser cualquier cosa)

<dialogue id=''1''>
  <text>
    Couldst thou venture forth and kill me 10 rats, perchance?
  </text>
  <response condition="True" nextDialogue=''2''>
    Verily! Naught could be better than slaying thy verminous foes. Ten ratty
    carcasses shall I bring unto thee.
  </text>
  <response condition="rats_left_in_world() < 10" nextDialogue=''3''>
    Nay, brother! Had thou but ten rats remaining, my sword would be thine,
    but tis not to be.
  </response>
</dialogue>

En su lenguaje de scripting, necesitaría una función ''rats_left_in_world'' que puede llamar para recuperar el valor en cuestión.

¿Qué pasa si no tienes lenguaje de scripting? Bien, podría hacer que el programador codifique una condición individual para cada situación en su diálogo: un poco tedioso, no tan difícil si su diálogo se escribe por adelantado. Luego solo refiérase a una condición por nombre en el script de conversación.

Un esquema más avanzado, que aún no requiere un lenguaje de scripting, podría usar una etiqueta para cada condición, como por ejemplo:

<response>
  <condition type=''min_level'' value=''50''/>
  Sadly squire, my time is too valuable for the likes of thee. Get thyself a
  farm hand or stable boy to do thy bidding!
</response>

Puede agregar tantas condiciones allí como necesite, siempre que se puedan especificar fácilmente con uno o dos valores. Si se cumplen todas las condiciones, la respuesta está disponible.

Answer 2

Ciertamente puedes usar un lenguaje de scripting para manejar el diálogo. Básicamente, una secuencia de comandos podría tener este aspecto:

ShowMessage("Hello " + hero.name + ", how can I help you?")
choices = { "Open the door for me", "Tell me about yourself", "Nevermind" }
chosen = ShowChoices(choices)
if chosen == 0
    if hero.inventory["gold key"] > 0
        ShowMessage("You have the key! I''ll open the door for you!")
        isGateOpen = true
    else
        ShowMessage("I''m sorry, but you need the gold key")
    end if
else if chosen == 1
    if isGateOpen
        ShowMessage("I''m the gate keeper, and the gate is open")
    else
        ShowMessage("I''m the gate keeper and you need gold key to pass")
    end if
else
    ShowMessage("Okay, tell me if you need anything")
end if

Esto está bien para la mayoría de los juegos. El lenguaje de scripting puede ser simple y puede escribir ramas lógicas más complicadas. Su motor tendrá una representación del mundo que está expuesto al lenguaje de scripting. En este ejemplo, esto significa el nombre del héroe y los elementos en el inventario, pero podría exponer lo que quiera. También define funciones a las que los guiones podrían llamar para hacer cosas como mostrar un mensaje o reproducir algún efecto de sonido. Debe realizar un seguimiento de algunos datos globales que se comparten entre los scripts, por ejemplo, si una puerta está abierta o si se realiza una búsqueda (tal vez como parte del mapa y las clases de misiones).

Sin embargo, en algunos juegos, las secuencias de comandos pueden volverse tediosas, especialmente si el diálogo es más dinámico y depende de muchas condiciones (por ejemplo, estado de ánimo del personaje y estadísticas, conocimientos de npc, clima, elementos, etc.) Aquí es posible almacenar su árbol de diálogo en algún formato que permita especificar fácilmente las condiciones previas y los resultados. No sé si esta es la forma de hacerlo, pero una vez hice una pregunta sobre el almacenamiento de la lógica del juego en archivos XML . He encontrado que este enfoque es efectivo para mi juego (en el que el diálogo depende en gran medida de muchos factores). En particular, en el futuro podría hacer fácilmente un editor de diálogo simple que no requiera muchas secuencias de comandos y le permita definir simplemente el diálogo y las ramas con una interfaz gráfica de usuario.

Answer 3

Es interesante, parece que hay una idea central que se está perdiendo aquí. Estamos teniendo una discusión que se relaciona con un programador que realiza la tarea. De hecho, los ejemplos de código anteriores están acoplados al código, no al contenido.

En el desarrollo de juegos, es a los desarrolladores de contenido que nosotros, los programadores, queremos potenciar. Ellos no (esto es muy importante) mirarán el código. Período. De vez en cuando, obtienes un artista técnico o un diseñador técnico, y son maravillosos y no les importa; pero, la mayoría de los autores de contenido no son técnicamente inclinados.

Entiendo que la pregunta es para su propia edificación; pero, debe señalarse que, en la industria, cuando resolvemos este tipo de problemas, nuestros usuarios finales (las personas que utilizan la tecnología que estamos desarrollando) no son ingenieros.

Un sistema como este (diálogo de ramificación) requiere una representación en una herramienta que sea relativamente intuitiva de usar. Por ejemplo, se podría utilizar el sistema de escritura visual Kismet de Unreal.

Esencialmente, las estructuras de datos (lo más probable es que sean un árbol de bifurcación, ya que es fácil de representar / depurar / etc) serían elaboradas por un programador, al igual que los nodos que representan el objeto en el script. El sistema con su capacidad de vincularse con objetos del mundo (lo más probable es que también esté representado por nodos en las secuencias de comandos visuales), etc., se diseñaría y todo el caniche del gatito se uniría en un código glorioso y elegante.

Después de todo eso, un diseñador podría construir una representación visual de la bifurcación de diálogos en el lenguaje de scripting visual. Esto sería mapa-encuentro específico, más que probable. Por supuesto, usted podría generar estos; pero, eso es más un deseo de programador que un diseñador.

Solo pensé que añadiría un poco de conocimiento y visión.

EDITAR: Notado hay un ejemplo XML. No estoy seguro de qué otros diseñadores / artistas / etc. siente al respecto pero, los con los que he trabajado se estremecen ante la idea de tocar un archivo de texto.

Answer 4

Esas son unas preguntas excelentes. Tuve que resolverlo un par de veces para los clientes. Comenzamos con una estructura XML muy similar a la suya, y ahora usamos JSON. Puede ver un ejemplo aquí: http://www.branchtrack.com/projects/on029pq6.json o https://dl.dropboxusercontent.com/u/11433463/branchtrack/on029pq6.json (preténtelo para facilitar la lectura).

Revelación completa: el enlace anterior se genera en BranchTrack, un editor en línea para los diálogos de bifurcación, y yo soy el CEO. Siéntete libre de preguntar cualquier cosa.

Answer 5

Hace poco abordé un problema como este al hacer Chat Mapper . Lo que hago es trazar gráficamente los diálogos como nodos en un árbol y luego cada nodo tiene una condición y un script asociado a ellos. A medida que atraviesa el árbol y golpea un nodo, verifica la condición para ver si ese nodo es válido o no, y si lo es, ejecuta la secuencia de comandos asociada con ese nodo. Es una idea bastante simple pero parece funcionar bien en nuestras pruebas. Estamos utilizando un intérprete de .NET Lua para los scripts.

Answer 6

Hace poco tuve que desarrollar algo para esto y opté por una estructura de archivos de texto muy básica. Puede ver el código resultante y el formato de texto en:

https://github.com/scottbw/dialoguejs

Existe un compromiso entre la sofisticación de los scripts y la facilidad de edición para los no programadores.

He optado por una solución muy simple para el diálogo, y manejar la activación de eventos relacionados con el juego por separado en un lenguaje de scripting secundario.

Eventualmente, podría agregar alguna forma de agregar "instrucciones del escenario" al formato de diálogo de texto que se usa para desencadenar eventos en el motor de secuencias de comandos secundario, pero nuevamente sin necesidad de poner nada que se parezca al código en el archivo de diálogo.

Answer 7

Me atrevería a decir que la mayoría de los juegos modernos (ya sean juegos de rol, juegos de acción, cualquier cosa por encima de los juegos básicos de cartas / tablero) generalmente constan de varios componentes: el motor de visualización, las estructuras de datos principales y, por lo general, un motor de secuencias de comandos secundario. Un ejemplo que fue popular durante un tiempo (y puede que aún lo sea; ni siquiera he hablado con un desarrollador de juegos en años) fue Lua.

La toma de decisiones de la que estás hablando (eventos, ramas de conversación, etc.) suele ser manejada por el motor de secuencias de comandos secundario, ya que los lenguajes de secuencias de comandos son más flexibles y generalmente más fáciles de usar para los diseñadores del juego. Una vez más, la mayor parte de la lógica basada en la historia o en la conducción de un juego sucederá aquí, donde se puede cambiar y cambiar con relativa facilidad. (Al menos, en comparación con la ejecución de una compilación completa de todo el código!)

El motor principal del juego combina las estructuras de datos relacionadas con el mundo (geometría, etc.), las estructuras de datos relacionadas con el (los) jugador (s) y otro (s) actor (es) necesarios (s), y las secuencias de comandos para conducir los encuentros, y utiliza todo eso para Visualizar el entorno final, integrado.

Answer 8

Para mi solución, desarrollé un formato de archivo de texto personalizado que consta de siete líneas de texto por nodo. Cada línea puede ser una lista de pasos o simplemente una línea de texto. Cada nodo tiene un número de posición. El último dígito del número es un tipo, por lo que hay 10 tipos diferentes de nodos, como preguntas nuevas, confirmaciones, acciones repetidas basadas en resultados anteriores, etc.

Cada activación de diálogo comienza con una consulta de selección al almacén de datos cuyos resultados pueden compararse con los miembros de una lista de pasos, para coincidir con el nodo apropiado. Esto es más brutal que un if / then pero hace que el archivo de configuración de texto sea más pequeño, ya que no necesita ninguna sintaxis además del separador de zancada. Utilizo un sistema de comodines para permitir que los resultados seleccionados de la consulta puedan insertarse en el discurso del NPC.

Por último, hay enganches de API para permitir que los scripts personalizados interactúen, en caso de que el archivo de configuración fácil no sea suficiente. Planeo hacer una aplicación web gui en nodejs para permitir que las personas guarden visualmente los archivos de configuración: D