[Conceptual] Encounter and On-Map alternate Battle Systems

ACTION GAME MAKER General
1

Una discusión conceptual y un examen de las formas de crear Sistemas de Batalla fuera de los sistemas de juego de acción pre-codificados.

Las herramientas actuales que tienen AGM+Godot, y qué herramientas le faltan a AGM para hacer posible un diseño sin herramientas avanzadas de Godot.

Los temas a cubrir incluyen, pero no se limitan a:

  • Pantalla de Batalla: transiciones a otra escena o pantalla visual, y de vuelta cuando la batalla termina.
  • En el Mapa, también conocido como Chrono Trigger: los combatientes permanecen en la escena actual y se mueven a las posiciones de combate.
  • Por turnos: los combatientes toman turnos, ya sea secuencialmente o en otro orden organizativo. Por ejemplo, ordenar basado en un valor de “velocidad”.
  • Tiempo real: los combatientes actúan en sus propios temporizadores o en el “tick” de proceso del motor del juego. Pueden interrumpir a otros combatientes o actuar simultáneamente.
  • Pseudo-turnos: cualquier mezcla de sistemas por turnos y tiempo real, donde los combatientes deben esperar a que otro combatiente termine una acción.
  • Posición fija, o línea de batalla: los combatientes ocupan posiciones fijas y solo se mueven con animaciones preestablecidas.
  • Posición dinámica: los combatientes son libres de moverse. Las posiciones pueden o no ser importantes.

Sistemas de Action Game Maker y Godot

La Base de Datos de AGM es crítica para todo esto. Comprender cómo configurar y modificar Bases de Datos de Usuario, Variables de Proyecto y Interruptores de Proyecto es una habilidad requerida para crear un Sistema de Batalla.

El Árbol de Escenas de Godot y cómo funcionan los Nodos de AGM con él es otro sistema vital para comprender. AGM toma el control de la gestión de escenas a través de la pestaña Transición de Escena. Lo cual es realmente importante en cómo funciona res://AGMaker/core.tscn.

Si no está familiarizado con el Árbol de Escenas y el orden del árbol, necesitará leer parte de la documentación de Godot. El término Árbol como término de estructura de datos aparece con frecuencia en los sistemas de Godot.

  • Corto: La parte superior de las capas del Árbol de Escenas detrás de cualquier cosa más baja en el árbol.
![core.tscn 229x132](upload://8jUG274ZAzDysuPM1Y7Pzar6xkr.png)

Durante el tiempo de ejecución, la GameScene actual se agregará como hija de GameScenes. Cuando ocurre el Acción: FinEscena, SceneTransition eliminará la escena actual y la reemplazará con la siguiente, mediante la lógica de Enlace. Esto limita a AGM a una única GameScene activa a la vez.[1] Los Enlaces también pueden cambiar de escena antes de un FinEscena, así que verifique las Condiciones de su Enlace.

  • 1.0.7: No hay una Acción de Script Visual para cargar múltiples GameScenes. Esto entra en conflicto con los principios de diseño de juego compuesto de Godot.
  • 1.0.7: No hay una Acción de Script Visual para transicionar a una GameScene específica. Esto debe manipularse a través de los Enlaces de SceneTransition Is Change Switch Variable, y un ProjectSwitch o ProjectVariable.

Las GameScenes se construyen a partir de múltiples Capas[2]. Las capas en este contexto son nodos Parallax2D. Se les otorga un privilegio especial en el Script Visual con Acciones de Capa:
![Acciones de Capa 103x148](upload://hlgCHkTwiGQyAI70cVUaWL4zizP.png) ![Selección de Capa Parallax

Bajo las Capas de GameScene o Parallax se encuentran los nodos ObjectRoot requeridos. Estos son responsables del funcionamiento de los GameObjects. Si un GameObject no es descendiente de un ObjectRoot, no funcionará correctamente. El ancestro ObjectRoot inmediato es donde Acción: GenerarObjeto colocará un nuevo GameObject. En la parte inferior de los hijos de ese ObjectRoot.

Las MenuScenes están destinadas a usarse como elementos GUI estáticos. Nodos Control que no se mueven con la Cámara[3] y permanecen posicionados en relación con la Pantalla. Estas escenas especiales pueden ser Acción: AbrirMenú y CerrarMenú.
![MenuScene 218x85](upload://tmlbiYJ5PNTWgORY25qGAEiSku0.png) ![Opciones de CanvasLayer 236x171](upload://aDi5j7MwaTYQsHEbVs20rLkCxU1.png)

El nodo UIObjectRoot es simplemente un ObjectRoot, igual que para las GameScenes. Se supone que debe colocar los GameObjects destinados a Script Visual bajo él. Todo el trabajo gráfico pesado lo realiza el CanvasLayer. Asegúrese de anidar nodos Control bajo el CanvasLayer. También querrá pensar en establecer el número de Capa. Esto anula el orden del Árbol de Escenas, para lo que se dibuja visualmente encima de todo lo demás.

El orden en que AbreMenú puede ser importante. Recuerde el orden del árbol. La MenuScene más reciente se agrega a la parte inferior de /root/CoreScene/GameScenes. Estos SceneMenus no se cierran en una transición de escena. En su lugar, la nueva GameScene se agregará debajo de ellos en el Árbol de Escenas.

Aquí es donde esas CanvasLayers se vuelven realmente importantes. Por defecto, las GameScenes están en la Capa Canvas 0, junto con cualquier otra cosa que no sea descendiente de un nodo CanvasLayer. Las MenuScenes tienen sus CanvasLayers predeterminados en 1, por lo que se renderizarán automáticamente encima de las GameScenes[4].

¿Por qué fue importante este contexto sobre los Nodos?

Porque un Sistema de Batalla puede configurarse de algunas formas muy extrañas.

Algunos ejemplos rápidos.

  • Puede crear una BattleLayer a partir de un Parallax2D extra (mostrado arriba). Eso puede ser Habilitado y Deshabilitado. Con un BattleSystemObject bajo su ObjectRoot.
  • Puede poner nodos no-Control en MenuScenes, y tener GameObjects de Script Visual funcionando aún a través de diferentes cambios de escena.

Entender el Árbol de Escenas y los Nodos es parte de la conversación sobre cómo y dónde colocar los GameObjects que ejecutarán los scripts del Sistema de Batalla. Antes de que esto incluso entre en las APIs de Godot no-AGM y las opciones de GDScript.

  1. GDScript puede forzar múltiples GameScenes en el Árbol de Escenas. No recomendado. ↩︎

  2. Esta terminología en inglés es confusa, pero típica de Godot. Lo que convierte la palabra “escena” en algo confuso por el uso excesivo. Capas Visuales, Capas de Colisión, Capas de Física, Capas de GameScene, Capas CanvasLayer, Capas Z-Index… ↩︎

  3. Las Cámara2D de Godot son un poco extrañas en su función. La Ventana del juego no puede realmente moverse por el mundo de juego 2D. Por lo tanto, el tipo Viewport se desliza (transforma), basado en la posición World2D de la cámara. Tome dos hojas de papel, sostenga una encima de la otra. Sus ojos son la Ventana del juego. Mueva la hoja inferior, esa es la Cámara2D moviendo el Viewport. La hoja superior es un nodo CanvasLayer de Godot que no sigue el Viewport. ↩︎

  4. Hay implicaciones de ejecución de Godot _process, _input y otros del Árbol de Escenas de que una GameScene esté debajo de los SceneMenus, por orden de árbol. Eso podría causar casos extremos inesperados. No he tenido tiempo de probarlos hasta este post. Si ha entendido el Árbol de Escenas, entenderá el orden _process hacia abajo en el árbol, y _input hacia arriba ↩︎

1 Like