Hay muchos programas de secuencias de comandos y muchas ocasiones para escribir su propia secuencia de comandos. Pero, como todas las herramientas de trabajo, el software de escenarios se adapta a los requisitos del área temática. Por esta razón, un programa de guiones de películas no es adecuado para escribir un guión para un juego de computadora y viceversa. Mi área es aún más específica: desarrollé el programa NIMS (un conjunto de herramientas para la historia maestra) para crear guiones para juegos de rol de acción en vivo (en adelante RI).
Blitz preguntas:
¿Se usa? Sí, el proyecto ya tiene dos años. Durante este tiempo, NIMS hizo más de 20 juegos.
¿Está pagado? Gratis - donationware.
En esta publicación, hablaré sobre los tipos de tareas de escenario, los detalles de la escritura de guiones para la República de Ingushetia, que NIMS puede hacer y las características de su implementación.
La imagen muestra una red social basada en las tramas de RI "Port Arthur", MG S&M (clicable).
Descargo de responsabilidad 1: los juegos de rol de tablero son un tipo de juegos independientes y me referiré a ellos como NRI.
Clasificación de tareas de secuencias de comandos
Durante muchos siglos, el guión como fenómeno perteneció exclusivamente a la escena. A fines del siglo XIX, apareció el cine y, a fines del siglo XX, varios juegos (computadora, tablero, acción en vivo, etc.) y en todas partes hay escenarios. Desde un punto de vista artístico, son similares y obedecen las leyes uniformes de la escritura de guiones. Pero desde el punto de vista de la forma de presentación de la información, cada área de aplicación de scripts plantea sus propias tareas. Tratemos de resolverlo.
Las tareas de secuencias de comandos se pueden dividir por la presencia / ausencia de interactividad con el espectador / usuario. El cine, los programas de televisión, los libros y el teatro requieren un escenario no interactivo . En consecuencia, el espectador no puede influir en el curso de la historia y al final solo hay un escenario. En contraste, hay escenarios interactivos que involucran la influencia del espectador. Estos son escenarios de varios juegos.
Los guiones interactivos se pueden dividir en cerrados y abiertos. Los escenarios cerrados requieren una descripción de todas las opciones posibles para el desarrollo de la historia. Por ejemplo, guiones para juegos de computadora y juegos de rol.
Los escenarios interactivos abiertos , a su vez, se pueden dividir condicionalmente de acuerdo con el grado de dependencia principal. En los juegos de rol de tablero, como D&D , todas las acciones de los jugadores se comunican al maestro y él narra. Estos juegos dependen completamente del maestro , y el jugador no puede dar un solo paso sin un maestro.
En la República de Ingushetia, un gran número de jugadores interactúa dentro del marco de las reglas y acuerdos establecidos antes del juego. Los maestros no necesitan seguir cada paso, pero su competencia generalmente sigue siendo la resolución de problemas contenciosos y la corrección de errores de reglas durante el juego. Destaco una vez más que los jugadores interactúan entre sí de forma autónoma , sin la intervención de un mago.
Descargo de responsabilidad 2: lo descrito aquí no es un dogma, sino una opción típica, los NRI son autónomos, los RI son autodependientes y todavía hay una gama completa de opciones intermedias.
Escenarios sobre juegos de rol de acción real
El desarrollo de RI tiene ciertos requisitos. En el proceso de desarrollo, se crea un modelo del mundo, que está habitado por personajes, y se registran conflictos. A menudo, para un juego necesitas crear docenas de personajes activos y docenas de historias abiertas con métodos de resolución.
Antes del juego, el jugador recibe una descripción introductoria de la posición de su personaje: antecedentes, parientes, amigos, enemigos, propiedad, conflictos, posiciones de facción en asuntos clave, etc. Resumiendo, en la introducción puedes poner cualquier información que "pueda jugar".
Y un descargo de responsabilidad más: el descrito aquí tampoco es un dogma. Hay juegos sin ninguna apertura, o algunos de los jugadores tienen apertura, pero otros no. El jugador puede ver su introducción directamente al juego y puede participar en su desarrollo unos meses antes del juego, indicando con qué quiere jugar y con quién.
Una parte importante de los relatos introductorios de la prehistoria, diseñada para responder las preguntas "¿Por qué ...?": "¿Por qué odio al rey?", "¿Por qué nuestras casas están en guerra?", "¿Por qué es importante para nosotros que el ritual vaya bien?"
Cada jugador debe recibir su porción de información y operarla en el juego. El flagelo de escribir una introducción son las inconsistencias. Cualquier evento de la historia se vuelve a contar repetidamente y con diferentes acentos, porque cada participante ve la situación a su manera. No solo debe describirse cada hecho en varias versiones, sino también en caso de que haya algún cambio, todos estos cambios deben duplicarse en cada una de las opciones. Por ejemplo, si en un episodio determinado estuvieron involucrados 5 personajes, entonces, en el caso del más mínimo cambio en este episodio, debe hacer 5 ediciones, y no una. Esta situación lleva a una gran cantidad de inconsistencias.
El proyecto NIMS está diseñado para desarrollar escenarios de RI que involucran múltiples historias con una gran cantidad de participantes. Con su ayuda, la información se distribuye entre los jugadores, y el proceso de escribir textos se acompaña de mecanismos de control para eliminar inconsistencias e identificar líneas "olvidadas".
Proceso de escritura introductoria
Condición del problema: hay una historia en la que participan muchos personajes. Es necesario proporcionar a cada personaje esa parte de la historia que él conoce.
Puedes resolver este problema de frente: Frodo, tu historia de fondo es esta, Gandalf, tu historia de fondo es esto. El problema al que nos enfrentamos es la información no sincronizada. Por ejemplo, escribimos en el Frodo de apertura "Silba fuerte si ves orcos". Pero olvidaremos escribir esto a todos los demás miembros de la Hermandad del Anillo, y no sabrán qué significa el silbato de Frodo. Es incluso "mejor" si escribimos sobre "el silbato de Frodo" solo la mitad del anillo de la Hermandad.
Este problema se puede resolver introduciendo otro texto: el texto de la historia original, sobre la base de la cual escribiremos textos adaptados o textos de adaptación para cada personaje. El texto original leerá "Antes de embarcarse en un viaje, la Comunidad del Anillo acordó que al ver a los orcos, Frodo silbaría". Frodo tendrá: "Acordamos que a la vista de los orcos silbaré". Todos los demás: "Después de escuchar el silbato de Frodo, corro para salvarlo de los orcos".
Pero existe el siguiente problema. Sabemos perfectamente quién entra en la Hermandad del Anillo. Pero en otra situación, es posible que no conozcamos a todos los presentes en el evento. Un ejemplo de tal situación: consejos sobre los que decidieron qué hacer con el anillo. Sabemos con certeza que toda la Hermandad del Anillo, Elrond, se reunió allí, y bien podría haber alguien más (incluso si esto contradice la fuente original). Si se tomó una decisión en este consejo, que debe corregirse en las introductorias, entonces tenemos incertidumbre: ¿cuál de los 140 personajes de nuestro juego estaba en el consejo y sabe algo?
Para resolver este problema, dividimos la historia en eventos, donde el evento es la unidad de tiempo, lugar y personajes. Arreglamos el evento: "Consejo del ring, hora: 3018/10/25 12:00, participantes: ..., descripción del evento: ..." Ahora sabemos exactamente quién fue el participante del evento. Cada participante tiene su propia visión del evento, que describimos en la adaptación del evento. La adaptación de toda la historia para el personaje seleccionado consiste en todas las adaptaciones de eventos con este personaje.
Etapa final: todas las adaptaciones están escritas, las agrupamos en archivos de texto por carácter. En una imagen, se ve así:
Como resultado, obtenemos datos estructurados que también son adecuados para la visualización:
- Podemos crear una cronología de eventos, tanto para cada historia como individualmente para cada personaje.
- Red social en sentido sociológico. Tenemos muchos personajes, y podemos interpretar su hecho de estar en un evento como una conexión social entre cada uno de los participantes en el evento. Como mínimo, podían verse, pero en la mayoría de los casos los personajes interactúan activamente entre sí.
Un ejemplo de la cronología de los eventos de la muestra base del Señor de los Anillos (se puede hacer clic):
Un ejemplo de una red social del juego RI "Mad Mad Max", Mk. Albion (se puede hacer clic):
Relaciones de personaje
La tabla de relaciones de caracteres se usa ampliamente en RI y NRI. La tabla de relaciones es una tabla cuadrada en la que cada fila y cada columna corresponde al carácter, y en las celdas de la tabla registramos la relación del carácter A con el carácter B. Un punto interesante: los caracteres no tienen que estar familiarizados entre sí para relacionarse entre sí. Un personaje de la parte inferior puede tener algún tipo de ábaco con el jefe de la mafia, pero el jefe de la mafia puede ser completamente inconsciente de esto.
Dossier
El dossier es una lista de hechos sobre el personaje. La estructura del dossier está determinada por el maestro del juego, ya que la información importante para un juego no es importante para otro. Por ejemplo, la edad de un personaje puede afectar la admisión a los vuelos en algún juego espacial, pero en El Señor de los Anillos no hay relación con la edad y nada depende de ello.
El expediente es, por supuesto, bueno, pero no es útil en sí mismo, sino en combinación con la capacidad de buscar personajes en él. Por ejemplo, necesitamos agregar a un joven noble soltero a una historia romántica. Configure un filtro: edad "hasta 30", estado "noble", estado civil "soltero", ordenado por edad ascendente.
Grupos de personajes
Desarrollando la idea de un filtro, llegamos a grupos de personajes. Por ejemplo, tenemos un grupo Templario en el juego, y queremos proporcionar el historial del pedido solo a las personas de este grupo. La decisión en la frente: Petya, Vitya, Borya Templarios, los incluimos en el grupo, el texto del grupo se muestra en la introducción. Luego Víctor se convierte en asesinos, Gosha entra en su lugar y editamos manualmente las listas de grupos. En cambio, podemos recoger el filtro a través de un dossier: la facción templaria. Solo aquellos personajes que pasen este filtro recibirán texto para los Templarios, y no habrá problemas con la actualización manual de los datos.
Mapa del terreno
El mapa de la trama es una herramienta para resolver conflictos entre facciones. La herramienta también es bastante conocida tanto en RI como en NRI. Usé este artículo como una especificación. En resumen: hay grupos de fuerza que actúan en el juego que de alguna manera se relacionan entre sí. Por ejemplo, el bien quiere destruir al mal, y viceversa. Hay recursos que son pasivos, pero están dentro del alcance del interés de los grupos. Por ejemplo, si consideras que el anillo de la omnipotencia es un recurso, los buenos quieren destruirlo, los malvados quieren capturarlo, los neutrales quieren usarlo de manera efectiva. Según el mapa de la trama, podemos planificar una lista de conflictos que el juego resolverá y crear una historia para ellos.
Sobre la implementación
El requisito inicial del sistema es la autonomía. Quería que el maestro de los juegos de roles pudiera trabajar desde una computadora portátil donde la comunicación es mala. Por ejemplo, en un patio de comidas o incluso en un campo de entrenamiento. Es por eso que NIMS se hace como una aplicación, y no como un servicio (la mayoría de los sistemas para RI con funcionalidad similar son servicios).
El segundo requisito es la falta de archivos ejecutables e instaladores. Debido a que obstruyen el sistema, porque están colocados en lavados de archivos con la capacidad de reinstalar cualquier basura innecesaria, etc.
Para ponerlo en marcha, necesita una máquina virtual en la computadora del usuario, y es, es un navegador. En realidad, así es como se implementa NIMS: un archivo con una página web independiente que se abre en un navegador.
Esta fue mi primera aplicación escrita completamente en JavaScript, así que intenté minimizar el uso de bibliotecas y marcos.
La implementación de una página web independiente tiene los siguientes efectos secundarios desagradables:
- no hay acceso al sistema de archivos, por lo que es imposible hacer que el botón "Guardar" y todo se guarde discretamente en un archivo. En cambio, la versión actual de la base de datos se descarga desde la página. De manera similar, cuando se abre el sistema, no se muestra la última base de datos, sino una base de datos de ejemplo. Es necesario cargar la última base de trabajo al comienzo del trabajo manualmente. Sí, esto es inconveniente, pero el riesgo de perder datos debido a una falla en el almacenamiento local y los análogos es aún peor.
- incapacidad para usar archivos con "extensiones no estándar" (hola Chrome). Por ejemplo, no puede colocar docx en la carpeta de la página y, si es necesario, cargarlo a través de una solicitud GET. Del mismo modo, la biblioteca l20n con sus archivos ftl no funciona. Del servidor, por favor. Resolví el primer problema codificando docx en base64 y guardando en el archivo js. Resolví el segundo problema creando una bicicleta.
- la imposibilidad de llamar a programas ejecutables, incluso cuando realmente lo desee. Aquí es necesario tener en cuenta el subsistema para la formación de los introductorios; aquí hemos escrito todo, debemos guardarlo en un archivo y enviarlo al reproductor por correo o imprimirlo. El requisito principal era "mantener la introducción en docx" (esto no es lo que se me ocurrió). Implementé esto con un docxtemplater. Le permite generar archivos docx por plantilla. Para este propósito, necesitaba, previa solicitud, cargar la plantilla docx en la página del párrafo anterior.
Y, por cierto, la falta de archivos ejecutables y un posible sin conexión resultan en el hecho de que no puedo usar un DBMS externo. Simplemente algo en el navegador en memoria. Elegí el carril bici e hice el almacenamiento de datos como un objeto JSON con la validación del esquema JSON en el arranque. El objeto JSON se almacena en un archivo de texto plano llamado "base".
En todos los demás aspectos, este es un SPA regular.
Poco después del lanzamiento, me informaron de un problema: juegos en los que estrictamente trabaja un maestro, una minoría. Por lo tanto, la posibilidad de un trabajo conjunto en el juego por parte de varios maestros es una cuestión de vida o muerte del proyecto.
Problema: tenemos un núcleo de trabajo, pero afilado para el trabajo autónomo. ¿Cómo asegurar la colaboración de varios maestros?
Solución: rehacemos el núcleo para que funcione con la base de datos para una operación asincrónica y lo modifiquemos para que pueda ejecutarse en node.js. El modo sin conexión funciona como antes. El modo de servidor distribuye una página web, y todas las llamadas al núcleo se convierten en Llamada de procedimiento remoto para ejecutar solicitudes en el servidor. Lo que solía ser una interfaz de kernel se convierte en una API. En el camino, el modo de servidor extiende la API con funciones de control de acceso y administración de usuarios.
Como resultado, tanto las soluciones fuera de línea como las del servidor usan el mismo núcleo. Esquemáticamente, se ve así:
Materiales
Hemos preparado muchos materiales para los usuarios:
- Presentación en línea : una breve descripción de los conceptos básicos para usuarios que no están familiarizados con NIMS.
- Los screencasts son videos donde hablo sobre cómo usar los NIMS.
- Documentación : una descripción completa de los conceptos utilizados y la funcionalidad implementada.
- Demostración en línea: versión sin conexión publicada en Internet. Se completa con una base de datos de ejemplo que ilustra, si no todas, la mayoría de las características implementadas.
La versión sin conexión se puede descargar aquí . Trabajo comprobado en Chrome y Firefox. Debería funcionar independientemente del sistema operativo, pero esto no se ha probado específicamente.
En cuanto al código fuente, el proyecto se divide en recursos de cliente, servidor y texto:
- El cliente incluye toda la funcionalidad del script.
- Los recursos de texto son una base de ejemplo, presentación, documentación, plantillas de carga.
- El servidor es una extensión del núcleo del cliente para trabajar con derechos y organizar el acceso remoto para varios usuarios. Esta parte del proyecto no está disponible públicamente actualmente.
Conclusión
El proyecto NIMS brinda la oportunidad de ver la escritura de guiones desde una perspectiva diferente. Los escenarios para RI son historias incompletas y no hay necesidad de formar una narración consistente para el espectador / lector. En RI, cada jugador recibe su información y actúa sobre esta base, así como en la realidad. En este caso, la tarea del guionista no es solo contar la historia, sino también distribuir la historia entre los personajes.