programación de eventos de la historia del juego

28

He desarrollado un motor de juego en c / c ++ y DirectX.

Tengo un motor de mosaico para los mapas, jugadores animados / sprites npc, hablando con el npc, menús y cambio de nivel, pero no hay juego, simplemente se siente vacío.

He mirado alrededor y sigo escuchando respuestas de palabras de moda, pero quiero saber cómo implementar una historia en mi juego.

Algunas personas han dicho que un archivo de guardado contiene banderas que rigen cada acción / estado posible disponible en el juego, pero esto suena ridículo.

Es un poco ambicioso, pero estoy tratando de obtener un juego como los juegos más antiguos de Pokemon / Final Fantasy.

¿Alguien sabe cómo funcionan estos juegos o la teoría utilizada?

He estado buscando por un tiempo y realmente agradecería cualquier aporte que la gente tenga.

Skeith
fuente

Respuestas:

19

La historia de tu juego probablemente debería tener la forma de un autómata de estado finito (o algún tipo de FSA extendida). Cuando ocurren ciertos eventos, debe pasar a un nuevo estado. De esta manera, solo tiene que almacenar el estado actual y cualquier información necesaria para saber dónde avanzar en el FSA (junto con los detalles del jugador, como la posición, la salud, etc.).

Por ejemplo, si simplificamos demasiado los juegos de Pokémon, las insignias del gimnasio forman la rama principal de la FSA. Empiezas en el estado 0 donde no tienes insignias y cuando vences a los líderes del gimnasio te mueves a través de los estados, al estado 1, al estado 2, etc. Para que tus entidades de juego se actualicen al estado actual, solo necesitas obtener ellos para mirar el estado actual. Por ejemplo, un NPC fuera del 3er gimnasio verificará en qué estado se encuentra, verá que se encuentra en el estado correspondiente a tener 3 insignias y respondería en consecuencia (tal vez con un "¡Bien hecho!").

No necesita almacenar el estado de todo en el mundo; solo el estado de la historia. Las entidades mismas saben cómo reaccionar dependiendo del estado actual.

Joseph Mansfield
fuente
enfoque interesante y me gusta tendrá que probarlo, pero ¿cómo rastrearías misiones secundarias que no dependen de la progresión de la historia?
Realmente depende de cuán compleja sea tu historia. Puede ser más fácil tener múltiples FSA (una para cada sub-historia) o puede que necesite algunas ramificaciones complejas. Necesitas sentarte y dibujar tu historia como una hoja de ruta. Cuando comprenda cómo se entrelaza todo, piense en cómo podría almacenar el estado actual (o estados si puede estar en más de uno a la vez). Algunas cosas deberán almacenarse por separado, como las posiciones de los NPC (si necesita que se guarden) y la salud de ciertos personajes, porque estos no dependen de la historia.
de esta FSA de la que habla, ¿dónde encontraría una explicación de esto, preferiblemente simplificada y sin otras teorías entrelazadas?
Skeith 01 de
Puedes aprender todo sobre las máquinas de estado por todas partes, pero el 99,9% de las veces no se hablará de juegos. Un libro introductorio sobre computación le enseñará sobre ellos, pero realmente no necesita tantos detalles. Solo necesita comprender el concepto de estar en estados y moverse entre ellos cuando ocurren ciertos eventos. La respuesta de @ pwny es realmente decir lo mismo de una manera diferente. Sin embargo, leer sobre las FSA será una excelente manera de aprender los conceptos de las máquinas de estado. ¡Solo busque en Google una introducción a las máquinas de estado!
Joseph Mansfield
7

Podrías usar un conjunto de posibles estados en los que se encuentra tu juego. Tus NPC y tu mundo estarían al tanto de esos estados y reaccionarían / ​​mostrarían en consecuencia. También es posible que desee definir un conjunto de desencadenantes que serían activados por algunas acciones / eventos.

Por ejemplo, vencer a cierto oponente activaría el gatillo A, lo que agregaría el estado S a tu mundo y en el estado S tu personaje se electrocutará cuando salga de la guarida de su oponente. O está lloviendo afuera. O encuentras un dulce raro. Tú entiendes.

Con esas dos simples adiciones a tu juego, podrías hacer que esté mucho más "vivo".

Asegúrate de crear también un fondo rico para tu mundo, personajes e historia y asegúrate de que el juego sea consistente con ese fondo. Planifica tu historia primero.

Prueba también Gamedev

pwny
fuente
eso es posible, pero estoy seguro de que los profesionales tienen mejores resultados, ya que lo que usted supone implica cientos de miles de booleanos e ints (lo he probado). Simplemente no lo veo como un enfoque realista para un juego a gran escala. gracias por el enlace
No necesariamente, imagine 5 estados superponibles independientes. Obtienes 32 ramas posibles para 5 booleanos. Creo que eso es razonable. Además, los sistemas de disparo se usan en muchos juegos profesionales, especialmente porque luego puedes guiar el comportamiento usando series de disparadores.
pwny 01 de
2

Como mencionó sftrabbit, esta es una aplicación perfecta para una máquina de estados.

Esencialmente, tienes una especie de estructura de árbol. Cada hoja / nodo contiene información sobre el estado actual y las reglas para avanzar al siguiente estado. Cada nodo puede contener múltiples salidas, dependiendo de cuán complejo necesite que sea su flujo de trama / juego.

Un buen análogo muy suelto de esto es un libro Choose Your Own Adventure . Cada página contiene texto que describe parte de la historia y las decisiones que puede tomar el jugador. Cada decisión lleva a otra página. Algunas páginas pueden vincular a páginas visitadas anteriormente, etc.

Los viejos juegos de aventura basados ​​en texto como Zork y Leather Goddesses of Phobos , y los infames juegos Sierra * Quest ( SpaceQuest protagonizada por Roger Wilco, el conserje espacial es uno de mis favoritos ) usaban una versión muy simple de este tipo de sistema. Cada habitación en un mapa era un estado, con salidas que se vinculaban con otros estados o habitaciones. La adquisición de un elemento establece una bandera en un objeto de estado global. Cada habitación verificaría esas banderas para determinar qué personajes o elementos estaban disponibles en cada habitación.

Por lo tanto, sus estados pueden implementarse como una clase o estructura, cada uno con propiedades para:

Lista de activos: lista de punteros a gráficos de fondo y cualquier otra cosa que necesite para mostrar la sala / estado / nivel.

Condiciones de entrada: logros que ya deben haberse alcanzado para ingresar a un nivel

Salidas: enlaces a cada posible "siguiente" salida. Norte, Sur, Este y Oeste son algunos ejemplos de esto, pero también puede incluir Puerta1, Teletransporte, etc. Al intentar salir de una habitación, o al determinar que una salida / puerta está "abierta", su juego podría verificar el siguiente estado para ver si se han cumplido las condiciones de entrada y modificar la forma en que se muestra la salida en la pantalla, o simplemente no permitir que el jugador se mueva en esa dirección.

Si quieres ponerte elegante, puedes incluir una versión diferente de un estado con diferentes condiciones de entrada, lo que alteraría la forma en que se presenta la sala al jugador, o las acciones que están disponibles en esa sala.

Su pantalla de inicio, muerte / juego sobre pantalla, etc. podrían ser estados dentro del sistema, de forma similar a la forma en que puede navegar entre las pantallas de menú. De hecho, si tiene un sistema de menú de este tipo, puede usarlo para esto. En lugar de las flechas arriba / abajo y "entrar" para navegar por un menú, buscaría eventos específicos dentro del área de juego, como pisar una plataforma de teletransporte, salir del lado derecho de la pantalla, etc.

Desde el punto de vista del administrador, considere si podría o no beneficiarse de la creación de una herramienta de administración que le permita crear la máquina de estado. Agregue habitaciones a un mapa, cree enlaces entre ellas, asigne activos como imágenes de fondo, etc. Esto probablemente sea excesivo para su primer intento; es demasiado fácil absorberse en la construcción de herramientas de administración y nunca terminar el juego. Recuerde: no está escribiendo middleware, sino un juego.

Espero que esto ayude.

3Dave
fuente
Para este ejemplo imagina un pueblo. Tengo un archivo que contiene el diseño de mosaico, así como el gráfico y el tamaño, listas de npc y cosas generales como esa. al agregar un archivo, se agregó una nueva cámara de ciudad al juego, lo que permitió que otros contribuyeran, o así fue el plan, pero el archivo se está volviendo algo completo y complejo. si te entiendo, pondría los eventos que pueden tener lugar en dicha ciudad en este archivo con banderas para seguir el progreso
Skeith 01 de
@Skeith sí, eso suena como un enfoque razonable.
3Dave
0

Solía ​​usar este motor de juego llamado VERGE . Juegue con eso y vea cómo maneja los eventos, realmente me gusta. También es de código abierto, así que puedes ver cómo lo implementan aquí . Aquí hay una breve descripción.

Cada mapa tiene una variedad de capas. Las capas gráficas, de las cuales puede haber varias. La capa de obstrucción. Y luego está la capa de zona. La capa de zona es lo importante aquí. *

Cada mosaico tiene un número para indicar de qué zona es parte. Cada zona se puede activar de dos formas básicas. O bien la zona se activa cuando el jugador ingresa o tiene lo que se llama activación adyacente. La activación adyacente significa que cuando el jugador está parado junto a una de las fichas de la zona y presiona alguna tecla especificada como la tecla de activación, la zona se activa.

Lo que sucede cuando se activa una zona es que llama a una función desde un script. Por lo tanto, debe incrustar algún tipo de lenguaje de secuencias de comandos. VERGE tiene su propio lenguaje llamado VergeC, y también permite lua. Yo mismo prefiero usar Python.

Una vez que haya superado este obstáculo, ahora tiene un tremendo poder en la secuencia de comandos de su evento. Tiene un lenguaje de programación completo en el que puede almacenar y actuar sobre datos como estadísticas de jugadores, banderas de historias, etc.

* También hay una capa de entidad. Las entidades actúan como zonas móviles adyacentes activadas.

Benjamin Lindley
fuente
eso suena como el tipo de sistema que se usa en la serie de creadores de juegos rpg. pero, ¿qué pasa si ese mosaico tiene 5 eventos diferentes en función de lo avanzado que esté la historia?
Skeith 01 de
@Skeith no puede. Cada mosaico solo tiene una zona asociada. Y cada zona solo tiene una función de script que llama. Sin embargo, eso no es un problema. Recuerde, aquí tiene un lenguaje de programación completo. La información sobre qué tan lejos de la historia se encuentra se almacenaría en una variable (o varias) Entonces, decidir qué hacer es una simple cuestión de probar esa variable en el script y tomar la acción adecuada en función de su valor.
Benjamin Lindley
@Skeith: aunque puede agregar la opción de cambiar a qué zona pertenece un mosaico.
Benjamin Lindley