programación de eventos de la historia del juego

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.

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.

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

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.

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.