Diario de desarrollo proyectoTanks: 01 - El motor de juegos, sus herramientas, la documentación y tu
Es curioso como la primera recomendación que escuchamos todos los que inician en el desarrollo de videojuegos es justamente hacer cosas pequeñas, ahora mismo veo que un aspecto del proyecto se ha salido totalmente de las limitaciones de tiempo que tenía en mi cabeza, es justamente una de sus funciones principales, el editor de mapas que puede ser hecho de forma sencilla en la teoría, se está saliendo de control.
Previniendo lo que ya suponía, el modulo de edición de mapas está en este repositorio de github, empezando por el control de la malla(TileMap) utilizada para crear el mapa, los cuadrados son 64*64 , lo primero implementado fue este commit con el cual dar click derecho coloca los sprites y click izquierdo los quita, los sprites están definidos por el nodo TileSet que los contiene donde [0,1] es el total de elementos, el primer sprite es selva, no tiene colisionador y su función será dificultar la visibilidad de los jugadores, el segundo sprite es tierra, tiene colisionador y busca ser el límite del mapa en este momento, la idea es que existan 6 o más bloques con distintas propiedades, algunos incluso destructibles.
Tenía muchos problemas ese primer commit por que la cámara no se movía, cuando he conseguido mover la cámara utilizando un algoritmo de movimiento simple y suave que encontré por internet, el problema de la cámara, es que estaba de alguna forma ligada a las coordenadas que devuelve el método event.position(), una vez encontrado ese detalle que todavía no consigo explicar, el metodo get_global_mouse_position() consigue que sin importar los cambios realizados por la cámara, las pulsaciones del mouse sean leídas sobre donde está el mouse y no en una posición modificada por el movimiento de la cámara.
En ese nuevo commit se añade la función _unhandled_input(event) del script del editor, consiguiendo evitar que pulsaciones sobre botones lleguen a la malla y se reflejen cambios, mover la rueda del ratón cambia el sprite a clocar, los botones tanto quitan como colocan los sprites sobre la malla, existe un metodo para guardar, pero no está funcional en este commit.
El ultimo avance hasta la fecha ha conseguido que los botones guardar y cargar, que deberían haber funcionado en otro momento, dejen de funcionar, como soy tontísimo, parece que no está en github uno de los commit que creé en local, pero si se ven reflejados todos los cambios en este commit, actualmente no se guarda el mapa, pero el codigo eliminado que si era funcional, esta ahí, el principal problema de este punto del proyecto es la falta de documentación en el motor, estoy utilizando la clase FileDialog que por algun motivo todavía no termino de entender y es necesaria para guardar los mapas con nombre propio, el guardar que funciona crea un solo mapa con un único nombre, lo que requiere el proyecto es justamente tener muchos mapas guardados en la carpeta personal del jugador, hasta que no consiga poner en funcionamiento el FileDialog en conjunción con el método de guardado, estoy en un bloqueo creativo.
Hasta aquí este informe de progreso, no he creado nada de arte y por twitter tengo algunas divertidas consecuencias de mi proceso creativo de desarrollo que adjuntaré de inmediato como cierre de esta entrada.
Previniendo lo que ya suponía, el modulo de edición de mapas está en este repositorio de github, empezando por el control de la malla(TileMap) utilizada para crear el mapa, los cuadrados son 64*64 , lo primero implementado fue este commit con el cual dar click derecho coloca los sprites y click izquierdo los quita, los sprites están definidos por el nodo TileSet que los contiene donde [0,1] es el total de elementos, el primer sprite es selva, no tiene colisionador y su función será dificultar la visibilidad de los jugadores, el segundo sprite es tierra, tiene colisionador y busca ser el límite del mapa en este momento, la idea es que existan 6 o más bloques con distintas propiedades, algunos incluso destructibles.
Tenía muchos problemas ese primer commit por que la cámara no se movía, cuando he conseguido mover la cámara utilizando un algoritmo de movimiento simple y suave que encontré por internet, el problema de la cámara, es que estaba de alguna forma ligada a las coordenadas que devuelve el método event.position(), una vez encontrado ese detalle que todavía no consigo explicar, el metodo get_global_mouse_position() consigue que sin importar los cambios realizados por la cámara, las pulsaciones del mouse sean leídas sobre donde está el mouse y no en una posición modificada por el movimiento de la cámara.
En ese nuevo commit se añade la función _unhandled_input(event) del script del editor, consiguiendo evitar que pulsaciones sobre botones lleguen a la malla y se reflejen cambios, mover la rueda del ratón cambia el sprite a clocar, los botones tanto quitan como colocan los sprites sobre la malla, existe un metodo para guardar, pero no está funcional en este commit.
El ultimo avance hasta la fecha ha conseguido que los botones guardar y cargar, que deberían haber funcionado en otro momento, dejen de funcionar, como soy tontísimo, parece que no está en github uno de los commit que creé en local, pero si se ven reflejados todos los cambios en este commit, actualmente no se guarda el mapa, pero el codigo eliminado que si era funcional, esta ahí, el principal problema de este punto del proyecto es la falta de documentación en el motor, estoy utilizando la clase FileDialog que por algun motivo todavía no termino de entender y es necesaria para guardar los mapas con nombre propio, el guardar que funciona crea un solo mapa con un único nombre, lo que requiere el proyecto es justamente tener muchos mapas guardados en la carpeta personal del jugador, hasta que no consiga poner en funcionamiento el FileDialog en conjunción con el método de guardado, estoy en un bloqueo creativo.
Hasta aquí este informe de progreso, no he creado nada de arte y por twitter tengo algunas divertidas consecuencias de mi proceso creativo de desarrollo que adjuntaré de inmediato como cierre de esta entrada.
No entiendo porqué event.position no se actualiza junto a la get_global_mouse_position()— Sergio Jimenez (@SergioAnubarak) March 3, 2020
Lo obvio es que la posición del evento sea la misma en la que ocurre el click, pero no pic.twitter.com/XsCopqaccO
Comentarios
Publicar un comentario
Comente usted aquí