La primera etapa en el desarrollo de mi juego fue el desarrollo del motor RTS. Planeo escribir una serie de publicaciones sobre los problemas que han surgido y sus soluciones en este blog. En este post te contaré cómo organicé el comportamiento de las unidades.
Pensando en dónde comenzar este motor RTS en general, llegué a la conclusión de que vale la pena comenzar con detalles y pasar de él a la abstracción. La primera aplicación que se me ocurrió fue la recolección de recursos, o más bien, la extracción de madera.
Por lo general, este proceso en la mayoría de las estrategias consiste en el hecho de que el empleado, al recibir el decreto para cortar el árbol, va al árbol, durante un tiempo agita un pico cerca de él con un hacha, luego va al almacén y comienza de nuevo.
Es decir, el proceso se ve así:
Para que esta imagen realmente pueda reclamar el nombre del autómata, carece de las condiciones para las transiciones entre estados y el estado inicial y final.
Aquí todo es simple: la máquina se inicializa con el estado "Voy a cortar", y el final del trabajo ocurre durante el cambio. Podemos expresar las transiciones entre estados usando las siguientes condiciones: "llegó al árbol", "cortó un puñado de leña", "llegó al almacén", "recursos entregados". Si la respuesta es sí, la máquina pasa al siguiente estado; si es negativa, permanece en el estado actual.
En cada uno de los estados del autómata, la acción correspondiente se invoca durante la iteración. También se puede realizar un conjunto de acciones durante la transición entre estados.
Por ejemplo, al iterar en el estado "Entregar", los recursos de la mochila de la unidad se transferirán a la tienda de recursos del jugador, y al cambiar del estado "Ir a cortar" al estado "Rublo", se iniciará la animación correspondiente.
También noto que caminar en sí mismo no es una operación "atómica", se encuentra en muchos comportamientos y es en sí mismo un comportamiento, y por lo tanto, el comportamiento de la extracción de árboles en realidad usa el comportamiento de caminar dentro de sí mismo. Es decir, se puede obtener un nuevo autómata utilizando la composición de varios otros autómatas finitos.
Al escribir comportamientos de esta manera, obtenemos un límite arquitectónico entre los detalles de la implementación de los comportamientos y la política de alto nivel para administrar estos comportamientos. Las implementaciones de comportamientos se convierten esencialmente en complementos para el resto del juego, es decir, los cambios en ellos no afectarán la corrección del trabajo de la lógica de alto nivel.
Estos comportamientos funcionan llamando al método de iteración desde el evento Actualizar de objetos de tipo Unidad (este evento dispara cada cuadro). Para comunicarse con el resto del mundo, se llaman los métodos IStateMachineListener.
Este es un ejemplo de la construcción de una máquina de estado en mi juego. Al recibir un equipo de construcción, la unidad va al punto especificado y luego ingresa al estado de construcción directa, transfiriendo las unidades de construcción al edificio. Cuando el edificio ha acumulado suficientes unidades de construcción, la máquina de construcción termina y la unidad recibe un nuevo comportamiento, el comportamiento predeterminado.
Eso es todo Si te gusta o no te gusta este formato, ¡escríbelo en los comentarios!