¿Hay algún motor / marco enfocado en la narrativa (o al menos no espacio-temporal)? [cerrado]

EDITAR (2): Dado que hay dos respuestas y no he aceptado ninguna de ellas, pensé que motivaría lo que consideraría una respuesta aquí: o algo que sugiera fuertemente que tal enfoque sería imposible / no es útil en absoluto o , alternativamente, una referencia a una investigación (campo) o ejemplos de un sistema al menos algo general más allá de los juegos de aventura de texto / ficción interactiva.

Si bien no voy a fingir que he realizado una investigación más profunda, he notado que todos los motores / marcos de juego que he investigado parecen ser algo así como un motor gráfico glorificado en el sentido de que hablan de formas / entidades en dos o espacio euclidiano tridimensional con, posiblemente, alguna forma de modelo de concurrencia "metido" que permite especificar alguna forma de lógica unida a estas "entidades".

Las "reglas" y la narrativa del juego se escriben de manera algo ad-hoc (con respecto al motor) sobre estas primitivas.

Obviamente, la descripción anterior está bastante simplificada (tome motores más especializados, como el motor de infinito que incluye algún tipo de sistema de búsqueda / narrativa), y me doy cuenta de que este modelo puede funcionar bastante bien (parece que muchas personas lo han usado) .

Sin embargo, me pregunto qué intentos se han hecho para crear motores / marcos que tengan nociones como la descripción (de alto nivel) de las reglas / lógica o narrativa del juego (o al menos un aspecto no espacial del juego) como su principal ¿base?

EDITAR (4): Esto no significa que el juego no incluiría ningún aspecto espacial / gráfico, solo que, en lugar de tener entidades espaciales a las que asocia la lógica, tiene una noción de trama (o juego o "reglas de juego de mesa" ) que luego describe una interfaz gráfica para / realización de.

Especialmente me interesaría cualquier enfoque declarativo que intente capturar algún tipo de semántica (semi) formal de una clase de juegos razonablemente grande, de una manera útil para la implementación real (en oposición a, por ejemplo, un marco exclusivamente para análisis cualitativo de juegos / narrativa).

Lo que he visto son algunas investigaciones sobre modelado / análisis narrativo con un modelo basado en la red de Petri y algunos enfoques interesantes en idiomas para escribir ficción interactiva .

EDITAR (1): pensé que agregaría un ejemplo de juguete para ilustrar.

Digamos que estábamos interesados ​​en crear aventuras de estilo de apuntar y hacer clic (piense en los juegos SCUMM). Uno podría analizar estos como basados ​​en una noción de progresión más o menos lineal y discreta de una situación inicial a una final.

Centrándose en la noción de progresión discreta y permitiendo cierta no linealidad, uno podría elegir la teoría de los DAG (acotados) como teoría básica. Especificar un juego de este tipo, en su forma más abstracta (en relación con esta teoría) corresponde a la adición de axiomas adicionales a esta teoría (ya sea para que la teoría especifique un gráfico específico o simplemente lo suficiente como para capturar lo que uno piense que se requiere para capturar los "trama").

Convertir esto en un juego real ahora se convierte en el problema de diseño de interfaz / HCI de incorporar esta teoría en algo jugable (es decir, construir un modelo de la teoría / encontrar un homo (iso?) Morfismo de gráficos de la colección de estados de interfaz de usuario con transiciones en el DAG "especificando el juego").

En el escenario hipotético anterior, puedo ver al menos tres cosas que deberían ser posibles de capturar en las bibliotecas. En primer lugar, se necesitan herramientas para transformar / razonar sobre DAG o gráficos en general. En segundo lugar, una biblioteca de interfaz de usuario lo suficientemente inteligente como para ayudar a verificar que nuestra representación de nuestro gráfico como un juego jugable en realidad modela el gráfico (por ejemplo, al menos parcial / informalmente, demostrando que el juego no tiene estados atascados, debido a la condición de límite) . Finalmente, se podría proporcionar una colección de bibliotecas de nivel superior para especificar el gráfico; como una biblioteca para expresar caracteres y su interacción y generar (partes de) gráficos en términos de tales.

¿Por qué mantener la teoría "intermedia" de los DAG, en lugar de simplemente tener la implementación de bajo nivel con algunas bibliotecas de ayuda en la parte superior? La respuesta es todas las razones habituales para una semántica formal. Dado que hemos decidido sobre una base formal, podemos verificar ciertas propiedades del juego que permiten razonar sobre cosas como optimizaciones en la biblioteca de interfaz de bajo nivel (siempre que modele el DAG podemos hacer lo que queramos), sin tener que Preocuparse por la incomparabilidad con la descripción de alto nivel (de personajes / diálogo, etc.), ya que esas descripciones deben describir tales estructuras.

No estoy implicando de ninguna manera que el enfoque anterior en específico funcione, y la idea no es que un DAG tenga que ser lo que realmente se guarda en la memoria (sino que forma algo similar a un formalismo computacional como un cálculo lambda), pero espero que esto ilustre el tipo de enfoque que me da curiosidad.

En resumen, supongo que un título alternativo a esta pregunta podría haber sido: ¿Cómo habría escrito Dijkstra juegos de computadora?

Una nota rápida sobre la narrativa y las reglas del juego: en la ficción interactiva se puede argumentar que el juego consiste en atravesar un gráfico de narrativa ramificada, pero en última instancia, la narrativa vive fuera de la mecánica del juego: podría reemplazar todas las palabras con algo ilegible y Sin embargo, los pasos para completar el juego (o perder al jugarlo) serían exactamente los mismos. Esto a su vez implica que la narrativa es irrelevante para el juego, excepto cuando un desarrollador elige cambiar una para adaptarse a la otra. En los juegos, la narrativa es esencialmente una fachada sobre la mecánica que puede hacer que la mecánica sea más atractiva para un jugador que disfruta de esa narrativa, pero eso es todo. Hay algunos juegos (aunque algunos no los llaman juegos) donde la narrativa es la forma principal de entretenimiento y la mecánica del juego es principalmente superficial,Querida Esther , pero los desarrolladores no necesitan un método formal para contar historias más que los escritores de ficción, por lo que no consideraré más la narrativa. En términos generales, cualquier juego que parezca "narrativa jugable" es un árbol o gráfico de eventos del juego que pueden existir y discutirse de manera significativa sin la narrativa en absoluto.

Me di cuenta de que todos los motores / marcos de juego que he examinado parecían ser algo así como un motor gráfico glorificado en el sentido de que hablan de formas / entidades en un espacio euclidiano de dos o tres dimensiones [...]

Sí, la mayoría de los "motores de juegos" son obviamente "motores de videojuegos", y su responsabilidad principal con el tiempo ha sido facilitar el lado de ingeniería de software de un videojuego, no el lado del juego. Podría decirse que esto tiene sentido porque es la ingeniería de software el aspecto más nuevo y más caro y, por lo tanto, más arriesgado. En comparación, el diseño del juego en sentido abstracto se ha realizado a mano durante miles de años sin la ayuda de herramientas, lo que puede explicar hasta cierto punto por qué sigue siendo así.

¿Qué intentos se han hecho para crear motores / marcos que tomen como nociones básicas (descripción de alto nivel) de las reglas / lógica o narrativa del juego (o al menos un aspecto no espacial del juego) como su base principal?

Ha habido pocos intentos serios, ninguno exitoso, que yo sepa.

Storytron es uno. "A diferencia de la ficción interactiva tradicional, Storyworld está más preocupado por modelar las acciones y reacciones de los actores y sus emociones e inclinaciones que por la geografía del mundo del juego o los objetos mundanos que lo pueblan". Sigue un esfuerzo anterior llamado Erasmatron, que realmente no tuvo éxito, y Storytron tampoco parece tener éxito. El siguiente artículo es una buena lectura sobre esto: Persiguiendo al Dragón

En un nivel menos ambicioso, hay muchas personas que han ideado formas simples de representar juegos simples. Uno de los muchos documentos es este: Multijuegos: un lenguaje de muy alto nivel para describir juegos de mesa (el enlace está detrás de un inicio de sesión, pero es posible que pueda buscarlo), pero todo lo que tiene al final es un conjunto legible por computadora de posibles estados, transiciones de estado y condiciones de victoria o funciones de mantenimiento de puntaje: están bien para juegos de mesa discretos como el ajedrez o juegos de cartas como el póker, pero no se generalizan a juegos con grandes cantidades de estado continuo o aquellos con semántica que son más como simulaciones (por ejemplo, juegos de disparos) o deportes (por ejemplo, juegos de carreras). Dichos juegos no pueden representarse adecuadamente a través de un simple árbol de estados de juego.

Una forma de abordar la comprensión de estos sistemas más complejos es tratar de clasificar cada mecánica existente en una de varias formas básicas, y luego averiguar cómo se pueden combinar las formas básicas para formar un juego más complejo, bajo el supuesto de que todo juego puede estar compuesto por estas unidades fundamentales, o combinaciones de las mismas. Dan Cook tiene un artículo llamado " ¿Qué son las mecánicas de juego ?" y un seguimiento " La química del diseño del juego"que intentan documentar este enfoque compositivo para el diseño del juego. En teoría, podría ser posible construir un sistema declarativo además de eso, pero en la práctica la mecánica solo forma una pequeña parte del juego y, por lo tanto, la salida resultante probablemente se verá limitada. dentro de un marco de presentación que no sería lo suficientemente flexible como para captar la atención de la mayoría de los jugadores.

Otros intentos de formalizar los conceptos de diseño de juegos a menudo se denominan "gramática del juego", uno de estos artículos se llama " Átomos de juego multijugador ", pero que se refiere a varios trabajos anteriores.

Digamos que estábamos interesados ​​en crear aventuras de estilo apuntar y hacer clic (piense en los juegos SCUMM). [...] uno podría elegir la teoría de los DAG (acotados) como la teoría básica. [...] En primer lugar, se necesitan herramientas para transformar / razonar sobre DAG o gráficos en general. En segundo lugar, una biblioteca de interfaz de usuario lo suficientemente inteligente como para ayudar a verificar que nuestra representación de nuestro gráfico como un juego jugable en realidad modela el gráfico (por ejemplo, al menos parcial / informalmente, demostrando que el juego no tiene estados atascados, debido a la condición de límite) . Finalmente, se podría proporcionar una colección de bibliotecas de nivel superior para especificar el gráfico; como una biblioteca para expresar caracteres y su interacción y generar (partes de) gráficos en términos de tales.

El problema aquí es que la computadora no agrega mucho al proceso. Los diseñadores de juegos como este a menudo dibujan exactamente esto, un gráfico en forma digital o física, que muestra el flujo a través del juego. Es trivial ver si el juego puede teóricamente completarse o no. Incluso codificar las diversas reglas para avanzar en una aventura de apuntar y hacer clic es trivial. La parte difícil es hacer que siga una narrativa interesante, que lo sitúe en un mundo atractivo, creando el arte y los recursos de sonido para retratar el juego y la interfaz correctamente, y las diversas tareas de ingeniería de software que lo mantienen todo junto. El gráfico dirigido de estados significativos a través del juego suele ser relativamente trivial; todo lo que lo rodea es el problema. Y es por eso que no hay mucho interés en ello,

Personalmente, actualmente estoy trabajando con un equipo en un producto llamado Storybricksque intenta permitir la construcción de un juego interesante a través de la especificación de varias reglas, y estas reglas pueden indicar el estado inicial de una persona, sus necesidades, etc. Es fácil tomar estas reglas y verificar si se pueden satisfacer las necesidades de una persona y, de ser así, cómo hacerlo, y por lo tanto crear declarativamente tareas que deben completarse en el juego. Sin embargo, esto en sí mismo no crea inherentemente una jugabilidad interesante, porque una vez que abstraes las cosas al nivel de "X necesita Y, tráelas para ellos", los jugadores comienzan a detectar el patrón y dejan de disfrutarlo. (Por ejemplo: las personas se cansaron rápidamente de las misiones generadas automáticamente en Skyrim, porque podían ver que no había un significado inherente a una misión generada por procedimientos, en comparación con las creadas por diseñadores. ) Por lo tanto, nuestro trabajo será utilizar métodos de IA para hacer que estas situaciones sean más interesantes, y eso es algo en lo que todavía estamos trabajando. (Storybricks todavía está en una etapa alfa muy temprana). Pero nuestra investigación indica que pocas personas están intentando algo como esto, y que es un problema muy difícil.

Otro problema con el enfoque declarativo es que no es muy utilizable. A los científicos les gusta porque es fácil de procesar, por ejemplo, para demostrar que una situación es solucionable o que un conjunto de reglas lógicas son consistentes. Pero en el mundo real, ni los programadores de juegos de computadora ni los usuarios finales se sienten tan cómodos con una representación declarativa que se centra en los resultados como con una representación imperativa que les dice cómo actuar para que los resultados sucedan. Los 10 principales lenguajes de programación actuales son imprescindibles , y las instrucciones del mundo real también suelen ser imprescindibles, ya sea para hornear un pastel o para construir muebles.. Esta falta de entusiasmo en cualquiera de los extremos del espectro significa que no existe un incentivo comercial para producir especificaciones formales para los juegos modernos, y parece poco probable que esto cambie en el futuro cercano.

He estado considerando cómo responder por un tiempo, y no estoy muy seguro de cómo decir esto.

Es una buena pregunta Desafortunadamente, la respuesta se reduce a que no tiene sentido programar nada menos un motor de juego de esta manera, o que así es como son las cosas.

Parece haber este énfasis en los gráficos, porque debe haber una forma de definir la existencia física de los objetos. Aquí es donde las cosas comienzan a ser existenciales porque de lo que realmente estamos hablando es de una representación de dimensión, pero ignoremos esto por ahora. El punto principal es que esto es algo que realmente está bastante involucrado. Permitir la representación del espacio será algo que inherentemente ocupa gran parte de la programación de un motor de juego. Y si los diseñadores quieren hacer escenas agradables, necesitarán mucho control sobre cómo se colocan las cosas. Entonces verás muchas cosas sobre gráficos.

Entonces, ese es el lado de bajo nivel de las cosas. Alguien necesita pensar mucho en todos estos pequeños problemas técnicos.

¿En cuanto a la narrativa y las reglas del juego? Eso está fuera del alcance de lo que se supone que debe hacer un motor de juego. Esta es la parte donde entra el grupo de desarrollo.

Además, no es que no se haya pensado mucho en cómo representar ideas a través de la programación. Eso es realmente lo que la historia de la informática es . Y, esta es la razón por la cual los motores de juegos frecuentemente tienen interfaces con lenguajes de alto nivel. Es más fácil representar los pensamientos a través de ellos.

Entonces, con eso en mente, ¿se podría hacer un lenguaje específicamente para juegos con énfasis narrativo? Yo diría que probablemente no. De nuevo, todo esto se reduce a la representación. El lenguaje debe poder describir los detalles de tal manera que la computadora sepa qué hacer con él. Si el propósito es crear un lenguaje específico para la creación de juegos, entonces cualquier decisión de diseño debe centrarse en eso.

Y de nuevo, hay muchas opciones de idiomas tal como están. Y más personas que solo aquellos en la industria de los juegos los han estado desarrollando. Generalmente tiene sentido usar uno de esos.

En resumen, hizo una pregunta interesante, pero muy difícil. Y no estoy completamente seguro de qué es, o si realmente lo respondí.

* editar: en retrospectiva, me doy cuenta de que solo estaba considerando los motores de juego 3D, como si fueran los únicos que existen. Algunos juegos no tienen a una persona actuando en un espacio físico en absoluto. Aunque en tales casos no estoy seguro de que un motor de juego contribuya mucho.

Al principio de la historia de la computación hobby (es decir, los años 80) había algunos kits comerciales de desarrollo de juegos disponibles para juegos basados ​​en texto y sprites. Los basados ​​en sprites eran muy parecidos a los "motores gráficos" actuales.

El otro tipo incluía cosas como analizadores de lenguaje natural. Este tipo parece vivir en los modernos "editores de nivel". La mayoría de ellos parecen incluir soporte para algo como Lua o Python scripting. También me gustaría señalar que no veo mucha actividad en la edición de nivel de código abierto, pero eso se debe a que estas cosas generalmente están muy unidas a los detalles específicos del juego en cuestión. Estoy pensando aquí en algo como los juegos de construcción de Elder Scrolls.

El Kinect puede traer de vuelta el analizador. Como fanático del viejo juego de aventuras basado en texto, también estoy entusiasmado con la dirección de Bethesda. Ciertamente es propietario, pero tal vez un genio joven ...