Archivo de la etiqueta: Godot Engine

🔨 Creación de recursos TileSet para los mapas 2D en Godot 3.1 🧩

En Godot 3.1 el editor de TileSets mejoró drásticamente, haciendo mucho más fácil la creación de los recursos que usaremos para nuestros mapas de dos dimensiones. Sean AutoTiles o por separado.

Pasaré a explicarles como funciona este, prácticamente, nuevo editor de Godot.

Crear y editar un nuevo recurso

Dirijan la mirada al apartado de “Sistema de Archivos”. Hagan clic derecho sobre el lugar donde quieran crear un nuevo recurso Tileset y presionen clic derecho > Crear Recurso. El navegador de recursos es similar al de Nodos, busquen “TileSet” y listo. Lo guardan donde quieran, y después le dan doble clic sobre el Sistema de Archivos, para que se abra el editor.

Perfecto; ahora podemos crear un AutoTile o varios Tiles separados (Incluso los dos juntos).

Creando AutoTiles

Para esto ustedes deben tener preparada una hoja de Sprites con los tiles que van a necesitar, colocados en función de que sea fácil entender cómo es que deben estar colocados cuando Godot les dé posiciones. Usaré esta hoja:

Presionando el botón de “+” podrán añadir la imagen que quieran, yo seleccioné la hoja de arriba.

Ahora tienen que seleccionar el tipo de recurso que quieren crear. Elegiré primero el AutoTile, y después crearemos “un sólo tile”.

Después de presionar sobre el Autotile, se nos permitirá seleccionar la “región” o la “zona” de nuestra hoja, que tiene los Tiles que necesitamos. Para hacer que el selector sea más exacto, presionemos el botón con el imán:

Sin embargo, los Tiles son más pequeños que los cuadrados de ahí. Para reducir el tamaño, vamos al inspector y cambiamos el «Snap» a valores de 16×16. Cuando la tengamos así, podremos seleccionar exactamente la zona de los tiles (el snap.x es el tamaño horizontal de tus tiles, y el snap.y es el vertical).

Ya tenemos los Tiles que queremos usar, ahora vamos a la sección de «Collision», allí podremos hacer que los tiles sean sólidos para nuestro personaje. Nos encontraremos con que los cuadrados siguen siendo más grandes que la imagen (por lo menos en mi caso). Lo que haré será dirigirme nuevamente al inspector y abrir la sección «Selected Tile» , buscaré la propiedad «Subtile_size» y ajustaré los valores de «X» y «Y» al tamaño de mis tiles.

Ahora sólo debemos hacer un clic sobre la herramienta de rectángulo (la segunda, de izquierda a derecha), y después en los tiles que queramos como cuerpos sólidos.

Cuando tengamos todas las colisiones que necesitamos, pasaremos a la sección «BitMask», para definir cómo reaccionarán los Tiles mientras se estén creando. Deben hacer clic en todo el espacio que ocupa cada tile, menos en los bordes. Como en esta imagen:

Si el cuadrado rojo es muy grande para sus tiles, vayan al inspector y en la sección «Selected Tiles» cambien la propiedad «Autotile Bitmask» de 2X2 a 3X3.

El AutoTile ya debería hacer su trabajo correctamente. Añadan el recurso a algún nodo Tilemap y vean el resultado:

Recuerden que deben cambiar el tamaño de las celdas por el de sus tiles.

Creando tiles únicos

Para esto pueden usar también una hoja de sprites. Yo seguiré con la misma de antes. En lugar de seleccionar «AutoTile», hacen clic en «Single Tile».

Básicamente es lo mismo que usar Autotiles, con la diferencia de que por cada nuevo «Single Tile», debes hacer clic en el botón amarillo para crearlos y seleccionar otra zona de la imagen.


Espero que este tutorial sea suficiente para ustedes. Dentro de poco compartiré un vídeo siguiendo los pasos de este artículo.

Godot Engine: ¿Cómo crear una Máquina de Estados? I

¡Hola compañeros! Hace ya muchas noches de insomnio que empecé con el nuevo proyecto de plataformas. Quiero anunciar que ya se encuentra casi terminado, pero hoy me gustaría mostrarles algo diferente…

He dividido cada funcionalidad del juego en un paquete, como un Asset independiente, para que ustedes puedan tomar la parte que más les interese y puedan adaptarla a sus proyectos con facilidad. El primer Asset de estos que publicaré, será la Máquina de Estados que pueden usar para los personajes jugables, ya que la implementada en los NPC será diferente, incluyendo cosas relacionadas con la IA (Inteligencia Artificial)…

Esta noche les enseñaré a elaborar una máquina de estados en Godot Engine, así estarán preparados para el momento de descargar el Asset o, simplemente, sabrán los pasos para desarrollar su propia máquina. Sin embargo, puede que esto sea algo extenso, dividiré el tutorial en dos partes.

La escena del Jugador y los Nodos necesarios

¿Ya tienen identificado a su jugador? ¿Todas las animaciones de las que dispondrá? De ser así, podemos empezar a añadir los nodos que formarán parte de la Máquina de Estados. Miren este árbol de nodos, es mi jugador:

Ustedes deben decidir que tipo de nodo será la raíz de su jugador, el mio es un KinematicBody2D, por lo tanto también hago uso de un CollisionShape2D. Para controlar las imágenes del personaje uso unas hojas de sprites, divididas de la siguiente forma, que coloco en el nodo Sprite (llamado: Images):

Para animar las hojas de Sprites es necesario que también añadan un nodo AnimationPlayer, como ven en la imagen de arriba. El nodo de “BodyPivot” es un Position2D y después de crearlo, dentro de él añado el Sprite, ya que al momento de elegir la dirección del personaje (izquierda o derecha) parece más ordenado alterar un Position2D que el Sprite (Sin embargo, pueden prescindir del Position2D y usar únicamente el Sprite).

Antes de empezar con la máquina de estados…

Supongamos que todavía no crearemos la máquina de estados. Primero “prepararemos el terreno”: vayan al AnimationPlayer y empiecen a añadir una animación para cada “Estado” de la máquina.

Esta es mi animación de “Idle”. Algo que tienen en común todas las otras animaciones, es que tienen que cambiar la Textura (Asignando la hoja indicada para el estado Idle), los Hframes (El numero de frames horizontales) y la propiedad Frame (Esta cambiara cada microsegundo, y representa la imagen actual). Cuando ya cada Frame de la hoja ocupe un microsegundo, marquen el tiempo final y coloquen que esa será la duración total de la animación. Además activen las flechas que están a la derecha del tiempo total, (como yo, que las tengo en azul) para que la animación se repita. Sólo la tienen que desactivar en animaciones de un disparo, como la de Ataque.

Ahora les dejaré una imagen con todas las animaciones que voy a usar para mi máquina de estados:

Si no sabes usar el AnimationPlayer, puedes ver este tutorial de aquí, donde enseño sobre la animación de personajes usando hojas de sprites (Estoy por actualizar el Tutorial).

Llegamos al último paso antes de crear la máquina de estados. Vamos a añadir un Script para nuestro nodo principal. Aquí el mío:

Como ahora sólo tenemos a un personaje que salta, se mueve y ataca, no necesitamos muchas líneas. Sin embargo explicaré cada sección de mi Script:

  1. Variables: ahí se definen las variables que se encargaran de representar la física y las aceleraciones, tanto para el salto como para el movimiento. Estos últimos se expresan en “float” (números con decimales), o también en números enteros. La velocidad (velocity) es la variable que representa los cálculos del M.R.U (Física: Movimiento Rectilíneo Uniforme), es Vector2 porque necesita un valor para el eje horizontal y otro para el vertical.
  2. _physics_process(delta): como sabrán, esta función se ejecuta en cada frame del juego (hay como 30 frames por segundo). Dentro de ella llamo a una función que he creado para aplicar una gravedad constante todo el tiempo. Es más fácil aplicar desde el jugador la gravedad, que crear la misma función en los estados que necesiten hacer uso de ella.
  3. _input(event): esta función se ejecuta cada vez que el jugador presiona una tecla o, en caso de los teléfonos, toca la pantalla. Recibe un parámetro llamado event, que representa el botón exacto que fue presionado o el gesto que se realizó en la pantalla. Dentro de esta función estoy comprobando que flecha fue presionada, entre la izquierda y la derecha (como esta el código ahora, cuando se presiona la “izquierda” la variable vale -1, y cuando se presiona “derecha” vale 1). Según el resultado, la dirección de la imagen cambiará (Nunca debe valer 0, por eso uso esa condición en el if. De lo contrario, la imagen desaparecería). Nota: cuando cambias por números negativos la escala de un nodo, este se voltea. Osea que en mi código lo que hago es voltear la imagen. Ustedes pueden lograr un resultado similar si usan el método “flip_h = true” de los nodos Sprite2D.
  4. apply_gravity(delta): cada vez que inicia esta función se le suma al valor anterior de la variable que controla la velocidad vertical (velocity.y) el producto de multiplicar la gravedad por el tiempo físico (delta). Esto se sumará hasta que el jugador toque el suelo (if is_on_floor()), donde la velocidad vertical vuelve a ser 0. La función move_and_slide() se usa para mover al jugador según una fórmula física que haga uso de la Velocidad. Pero también hay una alternativa que permite usar unicamente el resultado de la Distancia… Sin embargo esos son otros temas, y creo que ya sabían bien que es el move_and_slide(). Cuando el get_slide_count() no sea 0, significará que el jugador esta colisionando con algo. Entonces comprobaremos que este chocando por debajo del cuerpo para decir que la velocidad vertical vuelva a 0. Si no hacen eso, notaran que cuando chocan debajo de un bloque, el jugador se queda en el aire un tiempo.

Muy bien. Después de esto ya el siguiente paso sería añadir los nodos de la máquina, junto con el código que necesitan para funcionar. Por hoy hemos finalizado la primera etapa. ¿Qué les ha parecido? Me estaban reprochando hacer siempre un enfoque básico, redundando en muchos temas… ahora quiero ver que tal queda este “nivel” de dificultad, donde doy por hecho que ya saben de algunas cosas para seguir el artículo.

Avanzando con el desarrollo de un juego de plataformas

¡Buenas noches compañer@s! Ayer se empezó el desarrollo del nuevo proyecto de plataformas que planeo publicar en Itch.io, GitHub y Godot Assets Library, como Software Libre. El desarrollo del mismo es radicalmente diferente a mi «juego» de plataformas pasado: tratando de suprimir la mayoría de problemas lógicos mientras se trabaja con mejores mecanismos para proyectos generales.

Sin más, dejaré las publicaciones que forman una especie de «camino», durante el desarrollo de los Assets y el proyecto:

¿Por qué hago un artículo para hablar sobre una fase tan temprana?… supongo que en esto se basa el DevLog, y aunque esto sea mi primer paso, la máquina de estados es un tema muy interesante e importante. Además, aprovecho para hablar un poco más sobre esos Assets que puse arriba:

PD: Este artículo se escribió cuatro días atrás, pero perdí la electricidad desde ese momento y vuelvo hoy para publicarlo.

¿Qué es ese paquete de Assets?

Muy bien, desde el principio: seguro algunos ya saben que estoy muy emocionado con practicar Pixel Art y hacer mis propios gráficos. Ese pasatiempo se complementó perfectamente con mi entusiasmo dentro de la programación de juegos, y desde entonces he buscando la forma de dibujar, programar y escribir, para ser feliz y útil dentro de mi trabajo. Ese «pack» es la primera fase del proyecto que he ideado para este mes (y parte del siguiente).

¿Cuáles son esas fases?

La primera fase corresponde al dibujo/Pixel Art: se elaboran todos los recursos importantes que podrán usarse para formar juegos más adelante.

Después, la segunda fase es la programación de una «plantilla» o «demo», que haga uso de los Assets para desarrollar un prototipo jugable que pueda ser difundido por todos como material educativo; permitiendo su lectura, cambio y distribución por parte de cualquier usuario (Software Libre).

Por último, seguro una de las cosas mas interesantes, es tomar ese demo desarrollado y explicar, paso por paso, sobre el desarrollo del mismo… sí, esto toma el nombre de «Curso» y «Tutoriales».

¿Qué generará ingresos?

Estuve dándole vueltas a la publicación de contenido pago, pero no creo que sea necesario. Es probable que pueda alcanzar al público anglosajón y reciba donaciones que me permitan continuar con el desarrollo de nuevos proyectos. Teniendo en cuenta que los Assets y proyectos de código abierto son algo que les beneficia, sin importar que sea hispano.

¿Cuáles son las mecánicas que se introducirán?

Unos días atrás pregunté por algunos temas que puedan resultar de interés para ustedes. Tengo entendido que debería abarcar la inteligencia artificial de enemigos y «jefes», además de introducir mecánicas para el uso de inventario, o recolección de objetos (Para este punto estoy desarrollando un Asset aparte, un inventario que podrán añadir en cualquier proyecto 😉 ). También me hablaron sobre las cuerdas y el balanceo, como de los ataques con espadas o cuerpo a cuerpo… todo eso lo tengo en cuenta. Todo se introducirá poco a poco, y algunas cosas que me parecen importantes, como por ejemplo el inventario, serán desarrolladas con la intención de que, a futuro, puedan ser útiles en cualquier tipo de proyecto, desarrollándolas con un punto de vista general.

SI tienes una idea para introducir, puedes decírmelo en los comentarios. Cuando termine una buena parte y me parezca un buen resultado, abriré el repositorio para que puedan ir descargando el código, sin embargo, las imágenes y el curso pueden salir después… o quizás antes, vamos a ver como me trata el tiempo.

☝ La importancia del GDD (Game Design Document) 📚

Si tienes la idea para un gran videojuego, no basta con decir la historia y hablar un poco de las mecánicas que vas a implementar. Es importarte que toda la información referente al proyecto quede estructurada de una forma donde no se deje nada para la improvisación.

Una buena practica es elaborar un documento de diseño. En vídeojuegos, se conoce mejor como GDD o Game Design Document. Ahí abordarás todas las mecánicas, herramientas, estadísticas e información general que tengas planeada para tu juego, y la organización que alcances te permitirá trabajar con seguridad y, en caso de querer formar un equipo de desarrollo, desenvolverte correctamente.

Si bien la organización o los cronogramas que debes preparar para controlar la eficiencia de tu trabajo son documentos aparte, el GDD englobará todo el grueso de tu proyecto, guardando cada detalle que quieras implementar.

Cada documento de diseño puede alcanzar una estructura diferente, quizás más largo o más corto, dependiendo de cada proyecto. Pasaré a explicar cómo podemos crear uno de estos documentos, además de la estructura básica para que tengan una idea y puedan empezar a escribir algunas cosas.

¿Qué es un documento de diseño?

Como dije arriba: un documento de diseño o GDD (Game Design Document), es el archivo con toda la información referente al proyecto: desde sus estrategias de marketing hasta el gameplay que se implementará. Cabe resaltar que el documento de diseño no es obligatorio para empezar un proyecto, es más como una ayuda que puede ser muy útil para organizar al equipo.

¿Qué debemos escribir ahí?

Los temas que se van a tratar dentro de un documento de diseño son variados. Les dejaré una lista con algunos puntos importantes:

  1. Introducción. En esta sección podemos desarrollar los aspectos generales del proyecto: el nombre, género, plataformas y público al que va dirigido. Además, estaría bien hacer un resumen sobre las mecánicas principales que van a formar parte del proyecto.
  • Cuando nos referimos a la “introducción” de un documento de diseño, es importante señalar que en ella sólo se redactarán los conceptos más importantes de la jugabilidad, la interfaz, los gráficos, y otros elementos del juego. También se le conoce como High Concept, y su objetivo es presentar el juego a cualquier lector sin que este tenga que leer muchas páginas diferentes para hacer su propio resumen.
  1. Mecánicas. Quizás sea una de las partes más extensas del documento. Aquí van a estructurar cada detalle dentro del juego. Desde el movimiento de los jugadores, a las funciones que active, por ejemplo, una palanca. Dentro de esta sección suelen añadir un apartado para los objetos, la interacción del jugador con ellos, los controles, etc, llamado “Jugabilidad”. Ahí se debe desarrollar claramente como el jugador realiza acciones dentro del mundo. También hay una subsección para el “Flujo de Juego”, donde se explica con detalle qué cosas pasan desde que el jugador abre el juego. En esta parte pueden valerse de elementos gráficos para diferenciar cada acción del jugador. Un ejemplo sería: “El jugador entra en el selector de personajes y toma al guerrero, el juego activará los enemigos, después de luchar se abre una puerta”, o cosas así.
  2. Primeros minutos: Este es un apartado menos extenso que el “Flujo de Juego”, escribiremos unicamente de las primeras mecánicas, personajes u elementos que se presentarán durante los primeros minutos de juego. Es importante que el inicio sea emocionante, muchos jugadores no pasan más de cinco minutos hasta que ya eliminan el juego de su teléfono o computador.
  3. Interfaz. Aquí se explicará el funcionamiento de cada “pantalla”. Son los diferentes estados gráficos dentro del juego, como puede ser la pantalla de juego, la pantalla de título, o la pantalla de pausa. Además, también se debería hablar sobre GUI (Game User Interface) y cómo el jugador interactúa con ella.
  4. Arte. Para esta sección van a redactar todo sobre el arte y estilo dentro del juego. Se deciden temas como la perspectiva (2D,3D,2.5D) y los colores. Esta es una información que generalmente puede mostrarse al público general, ya que explica como se verá el juego.
  5. Sonido. Acá se resolverán las dudas que se tengan respecto a los efectos de sonido, doblaje, y música.

¿Cómo crear un GDD? 🚀

Primero que todo, necesitaremos tener instalado algún Software de oficina. En Windows seguramente tendrán el Microsoft Word, pero también hay una alternativa que se puede usar en todos los sistemas operativos: LibreOffice. Para esta labor no tiene nada que envidiarle a Word, es gratuito y su interfaz es bastante parecida (las líneas de este artículo se escriben en LibreOffice).

Cuando tengan instalado el programa que quieran usar, sólo van a tener que empezar a escribir el índice de contenido. Por aquí abajo les mostraré unas plantillas básicas que pueden copiar y pegar.

Cosas que debemos considerar ☝

1️⃣ El documento de diseño será un material que seguramente más de una persona ojeará. El/los encargados de escribir sobre él deben mantener un lenguaje estándar y fácil de entender para todos. La organización es muy importante.

2️⃣ Mientras están escribiendo sobre su proyecto, no eviten un tema que parezca «obvio», seguramente para otra persona no quede claro, y necesitará una explicación.

3️⃣ Mientras más información tengan, más sólido será su documento. Traten de desarrollar bien cada mecánica o hueco de la historia (en caso de que su juego tenga historia). Una opción sería escribir todo dentro del documento de diseño y después sacar las páginas de cada tema para dividirlas en otros documentos, como: «Mecánicas» e «Historia»; dentro de una carpeta llamada: «GDD »Proyecto IX’ «.

Estructura básica para un GDD 📈

Aquí me gustaría destacar esta plantilla que encontré en Internet: https://docs.google.com/document/d/1-I08qX76DgSFyN1ByIGtPuqXh7bVKraHcNIA25tpAzE/edit, me parece un buen ejemplo.

Además, podemos considerar lo siguiente:

  1. Introducción
    • Concepto del juego
    • Características principales
    • Género
    • Publico dirigido
    • Alcance
  2. Mecánicas de juego
    • Jugabilidad
    • Flujo de juego
      • Diagrama de flujo
      • Introducción al juego
      • Jugando
      • Fin de partida
    • Personajes
      • Protagonista
      • Compañero del protagonista
      • Antagonista
    • Control de jugador
      • Interacción con el personaje
      • Interacción con el entorno
      • Interacción con la interfaz
    • Interacción del entorno con el jugador
  3. Interfaz
    • Diagrama de flujo de pantallas
    • Menú principal
    • Menú de pausa
    • Menú de guardado/cargar partida
    • Interfaz de usuario durante partida
    • Interfaz de fin de partida
    • Creditos
  4. Arte
    • Estilo
    • Concepts
    • 2D
    • 3D
  5. Sonido
    • Música
    • FX
    • Diálogos

Si lo necesitas, puedes añadir o quitar alguna sección. Esa estructura la he encontrado aquí.

Beneficios de un GDD 🏆

Como les dije arriba, tener un documento de diseño puede resultar muy útil para mantener organizado un equipo de trabajo. Para finalizar este artículo, colocaré una lista de beneficios por usar un GDD.

  1. Se establecen los límites y las posibilidades del equipo.
  2. Al tener una base documentada, aumenta la seguridad de éxito tras la publicación del juego, se supone que han evaluado y preparado un plan para muchos posibles riegos.
  3. Con toda la información del proyecto, el trabajo en equipo será más fluido: no hay necesidad de que un diseñador o programador tenga que preguntar por cada detalle al administrador del proyecto.

¿Antes de empezar tus proyectos trabajas un documento de diseño? Comparte tu experiencia. Si tienes alguna duda, puedes dejarla en los comentarios.

Repasando la interfaz de Godot 💻 📝

¡Hola Amigos! Vamos a analizar las partes del editor de Godot.

Partiendo desde un proyecto inicial, tenemos lo siguiente:

Podemos dividir el editor de Godot en tres secciones principales: “Izquierda”, “Centro” y “Derecha”.

El la parte de arriba, podemos encontrar un menú con las opciones típicas de cualquier programa a la izquierda. Los botones “2D”, “3D” y “Script” se usan para pasar de una pantalla principal a otra. En la pantalla de “2D” y “3D” podemos editar escenas con dicha perspectiva, mientras que en “Script”, vamos a editar todo lo relacionado con código en el proyecto.

Como dije hace un momento, Godot se divide en tres secciones: en la izquierda encontraremos la pestaña de “Escena”. Allí se administran los componentes de cada nivel u objeto, en el siguiente capítulo la veremos más a fondo. Justo a su lado, encontramos la pestaña “Importar”, la cual es usada para cambiar los parámetros de un archivo dentro de la carpeta de proyecto.

Debajo de “Escena” y como última pestaña en la izquierda, tenemos el “Sistema de Archivos”. Es parecido al navegador de carpetas que hay en nuestro sistema operativo. Desde él, podemos acceder a todos los recursos que tenemos dentro de nuestra carpeta de proyecto, y si hacemos clic derecho en una carpeta dentro del “Sistema de Archivos” podemos seleccionar la opción que dice: “Abrir en navegador” para poder usar rápidamente el navegador de carpetas de nuestro sistema operativo y realizar cualquier cambio.

Pasando ya al centro del editor, tenemos lo siguiente:

En la parte superior encontramos las herramientas correspondientes a nuestra perspectiva, yo tengo en la imagen las herramientas de una vista “2D”. Si nosotros cambiamos a la pantalla de Scripts, veremos como desaparecen esas herramientas por un menú. También podemos apreciar que las pestañas inferiores (“Salida”, “Depurador”, “Audio”, “Animación”) no cambian si pasamos entre pantallas. Cuando activamos una de esas pestañas, por ejemplo: “Salida”, vamos a abrir la consola, una herramienta útil para imprimir valores desde código. Para finalizar el resumen de esta sección, debo mencionar que la pestaña “Depurador” se abrirá automáticamente cada vez que recibamos un error o tengamos una advertencia. De lo contrario, nosotros mismos podemos abrirla para enterarnos de los valores actuales en una variable, los recursos que consume el proyecto, etc.

La última sección del editor, es la derecha:

Aquí tenemos la pestaña de “Inspector” y “Nodos”. La primera se encarga de presentar todas las propiedades que tenga un nodo, permitiendo modificarlas, Los nodos se crean en la pestaña de escena y son los componentes de cada proyecto, en el siguiente capítulo veremos más sobre ellos. Como segunda pestaña tenemos “Nodos”, contiene dos características muy útiles en Godot: la posibilidad de trabajar con señales y, además, administrar grupos para cada nodo seleccionado en la Escena.

Fin del capítulo. Ya conocen cada parte de Godot, durante los siguientes artículos aprenderemos un poco más de cada sección y mediante la practica nos acostumbraremos a esta interfaz, que para un flujo de trabajo, muchos la consideran excelente.

Crear nuevos proyectos en Godot 🤖 📂

¡Hola amigos! Hoy veremos cómo se crean nuevos proyectos en Godot Engine.

Cuando hagamos clic sobre el ejecutable de Godot, vamos a ver la siguiente pantalla:

Al principio no tendremos ningún proyecto creado. Si hacemos clic en la pestaña de “Plantillas” podremos descargar desde los servidores oficiales de Godot, un juego gratuito y libre de modificar.

Ahora veamos estas opciones:

Por ahora podemos ignorar el botón “Escanear” junto con todos los grises oscurecidos. Si queremos crear un nuevo proyecto haremos clic en “Nuevo Proyecto” o, en caso de que tengamos uno descargado, hacemos clic en “Importar”. Cuando importamos un proyecto tenemos que seleccionar la carpeta donde se aloja y hacer clic en el archivo proyect_godot, pero ya lo veremos, más adelante.

Nosotros haremos clic en “Nuevo proyecto”. Por esta ventana podemos elegir un nombre y la ubicación del proyecto. Es necesario que la carpeta donde lo vayamos a guardar se encuentre vacía, para eso podemos, después de colocar un nombre, hacer clic en el botón de “Crear Carpeta” y después “Crear y editar”.

Perfecto. Ya tenemos nuestro proyecto creado, en el siguiente capítulo explicaré las partes del editor.

Dev snapshot: Godot 3.1 beta 2

La semana pasada ingresamos al congelamiento de lanzamiento con Godot 3.1 beta 1, y desde entonces se han corregido muchos informes de errores de alta prioridad. Ahora estamos publicando una nueva instantánea beta 2 para que los evaluadores trabajen. Esta nueva versión corrige varios escenarios de fallo, así como una regresión del rendimiento en el backend de GLES.

Todavía estamos apuntando a un lanzamiento a finales de mes, por lo que estamos bajo un calendario apretado. A partir de ahora, el enfoque de desarrollo se centra en los problemas críticos de la versión que obstaculizarían seriamente la facilidad de uso y las características de Godot 3.1.

Al contrario de nuestras versiones de mantenimiento 3.0.x, que incluyen solo correcciones de errores compatibles con versiones anteriores y revisadas a fondo, la versión 3.1 incluye todas las nuevas características (y errores posteriores) fusionadas en la rama maestra desde enero de 2018, y especialmente todas las que se muestran en nuestros devblogs pasados Ha pasado casi un año desde el lanzamiento de la versión 3.0 y cerca de 6,000 cambios, ¡así que espere muchas cosas buenas en la versión 3.1 final!

Y una pequeña nota para los usuarios de C#: Godot 3.1 beta 2 ahora incluye mono 5.18 en lugar de 5.16. Todavía está incluido, por lo que no necesita actualizar su sistema mono.

Considere

IMPORTANTE: esta es una versión beta, lo que significa que no es adecuada para su uso en producción, ni para revisiones de prensa de lo que Godot 3.1 estaría en su lanzamiento.

Todavía habrá muchas correcciones hechas antes del lanzamiento final, y necesitaremos sus informes detallados de errores para depurar problemas y solucionarlos.

Las mejoras

Las notas de la versión ya están redactadas, pero no queremos arruinar la sorpresa del anuncio de la versión 3.1 ;). Mientras tanto, puede consultar el registro de cambios detallado que mantiene nuestro colaborador Hugo Locurcio, así como los devblogs anteriores.

Los redactores de documentación están trabajando duro para ponerse al día con las nuevas características, y la última rama ya debería incluir detalles sobre muchas de las nuevas características 3.1. Juan agregó varios tutoriales sobre las nuevas características 3.1 la semana pasada (mallas 2D, esqueletos 2D y documentación de AnimationTree).

Descarga

Los enlaces de descarga no se muestran en la página de descargas para evitar confusiones para los nuevos usuarios. En su lugar, navegue por nuestro repositorio de descargas y obtenga las plantillas de exportación y binario del editor que coincidan con su plataforma y el sabor de Godot:

Este artículo es una traducción del anuncio oficial, puedes visitar el original aquí: https://godotengine.org/article/dev-snapshot-godot-3-1-beta-2

La imagen de la ilustración es una captura de pantalla del primer juego de Miskatonic Studio, Intrepid, un juego de ciencia ficción que se lanzó el mes pasado. Steam, Twitter.

Nueva sección DevBlog para el sitio

Si pasan por mi página de inicio notarán que no actualizo las entradas desde hace ya un par de semanas atrás. Esto no significa que me haya olvidado del blog. Estos días he estado estudiando y practicando mucho las áreas débiles que tengo como desarrollador de vídeojuegos: quiero empezar con PixelArt o modelos en Vectores, también estudio inglés y escribo sobre pequeños proyectos de juego, viene siendo hora de publicar mis ideas.

Ya tenemos como diez meses y la mayoría de artículos y vídeos son parte de tutoriales, algunos muy malos de calidad, que me gustaría volver a hacer, incluso usando métodos más sencillos. Tomen en cuenta que el sitio web sobrevive gracias al amigo Nathan, que cada mes me envía el dinero necesario para mantener la renta, aún cuando los tutoriales eran meras repeticiones de otros y no aportaban la mayor cosa.

Estas últimas semanas los tutoriales han resultado más interesantes para ustedes (o eso dicen las estadísticas) y tengo ganas de mantenerlo así. Me voy a comprometer con realizar un tutorial cada semana, y si veo que ese tutorial no es tan importante, lo compensaré con dos vídeos diferentes.

A ese ritmo surge un problema con los otros días de la semana, por aquí acostumbraban a no ver nada, pero ahora creo necesario rellenar con esta sección, explicando como es mi estado en cuanto a la producción de vídeos y mis proyectos personales. Así estarán actualizados con mi tiempo, y hasta se pueden entretener con las noticias de mis jueguitos jaja, esas se acercan.

Por último me gustaría avisar que estoy produciendo un curso sobre Godot 3.1 y renovando los repositorios de Godot Engine, desde ahora publicaré directamente todos los capítulos de un curso cuando lo tenga completado.

Duotone: Nacer y Morir

Son muchas las formas que se han inventado para entretener a los jugadores dentro de un juego de plataformas: armas y explosiones, acertijos, saltos y habilidad… sobre esta última nos detenemos hoy jugando Duotune, un juego de plataformas donde saldremos y moriremos una buena cantidad de veces.

Descripción 🎮

Sin mucho preámbulo, con iniciar el juego se presentarán tres dificultades: Noob, Normal y Difícil, si quieren dejar de ser jugadores cualquiera, elijan el modo Noob 🤓, seguro que ni notan la diferencia. Cuando entramos en los niveles la cosa no parece tan difícil: hay unas monedas que debemos recolectar para pasar el nivel y listo, de resto nuestra misión es llegar con vida a una meta 😈. 

Características 📝

  • Muertes. Tienes que ser preciso. Los bloques son más grandes que tu personaje, cuando estas saltando es difícil caer sobre un lugar libre de obstáculos. 😵
  • Falta de compasión. La diferencia entre el modo difícil y noob radica en una cosa: cuando pierdes en el primero retrocedes hasta el primer nivel, sin importar donde te encuentres. Si pierdes en modo noob sólo retrocedes hasta el inicio del nivel 😙.

Origen y disponibilidad 🧐

Podemos descargarlo para GNU/Linux, Windows y Mac desde la plataforma de Itch.io por 1.50$ (25% de descuento).

También podemos descargarlo desde la tienda de aplicaciones Google Play por sólo 2$.

Este juego fue desarrollado por Damv desde Godot Engine.

12 Preguntas para Matías Muñoz – Desarrollador e instructor en FuryGames y FuryCode

La semana pasada se publicó UltraSpaceShips RPG. Un juego de naves que nos ofrece mecánicas originales y diferentes modalidades. Su principal desarrollador, Matías Muñoz Espinoza, instructor en Youtube y Udemy, se animó a compartir un poco de su experiencia como programador y desarrollador de vídeojuegos.

Entrevista con Matías

Presentación:

Mi nombre completo es Matías Valentín Muñoz Espinoza y estos últimos años me he dedicado en su mayor parte al desarrollo de videojuegos. Tengo un canal de youtube (FuryCode) y formo parte de un equipo (FuryGames), en FuryGames inicialmente era yo solo, pero ahora somos más y vamos avanzando.

1. ¿Cuándo iniciaste FuryCode y FuryGames?

FuryCode empezó primero, fue el 9 de noviembre del 2012 (Fue el primer video del canal), empece con algo de desarrollo web (no tenía mucho conocimiento, pero aprendía mientras hacía los videos) el primer curso fue de Sass y Compass, Sass es un preprocesador de CSS y Compas es un framework. Para no hablar mucho de esto digamos que Sass es un lenguaje encima del CSS que se traduce (transpila) a CSS, creo que actualmente se usa bastante y es recomendable su uso.

Y FuryGames fue después, fue mas o menos en mayo del 2016. Y FuryGames a tenido muchos intentos de ser un grupo estable de desarrollo, en cuanto a personas, pero es algo que cuesta bastante. Sobre todo si no tienes dinero que ofrecer y puedes ofrecer solo un porcentaje de participación en los desarrollos, normalmente ofrecía un porcentaje equitativo. Sin muchas reglas y con muchos ánimos. Pero después con el tiempo uno se va dando cuenta que esto de tener grupos de desarrollo es un tema muy complejo, de mucha motivación, etc.

2. ¿Por qué elegiste Godot Engine?

No me considero extremista del Open Source, pero es algo que me gusta bastante. También soy usuario de Linux, tanto que, no tengo Windows ni lo he tocado desde hace mucho tiempo, de hecho me confundo un poco en Windows. Como Godot es un proyecto Open Source y a la vez Software Libre, es algo que me gusta mucho, funciona muy bien con Linux y es algo que se estaba esperando. Hace tiempo no habían engines (con editor) que funcionaran en Linux, o por lo menos no eran tan maduros como Godot Engine.

Godot al principio fue mera curiosidad, antes use un tiempo LibGDX, que es un framework. Y me di cuenta que Godot Engine agiliza mucho el trabajo, en LibGDX me tomaba siglos un par de cosas que se podían hacer en poco tiempo en Godot Engine. Aunque es verdad que hay gente que quiere hacer todo en código, yo les digo a esas personas que no es necesario hacer todo en código, hay trabajo muy tedioso y repetitivo que sea hace en un framework, la idea de los engine es disminuir ese trabajo tedioso y repetitivo. Y ¿Códear?, al final terminas codeando más del 70% en Godot Engine, osea usando un Engine no te deshaces de codear sino que del trabajo repetitivo.

3. ¿Cómo surgió la idea de Spaceship Shooter?

Al principio fue por experimentar mecánicas distintas, se me ocurrió eso de que las naves enemigas y las balas tengan gravedad en una jam. Era una Jam de pocas personas que creamos con unos amigos de Discord. Un saludo para ellos…

Bueno en esa Jam se creó el primer prototipo, que fue en una semana. El juego esta en itch.io como Ultra Spaceship Shooter.

Después de eso trate de hacer el mismo juego pero ponerle cosas RPG, solo algunos elementos RPG, “No iba a ser la gran cosa decía yo” y al final termine desarrollando un plugin para facilitar la lógica de los juegos RPG.

El segundo juego (Spaceship Shooter RPG Deluxe) no lo hice solo, me ayudaron en muchas cosas, sobre todo con la parte gráfica. También programación, un chico que luego desapareció.

4. ¿Cuesta formar un equipo de desarrollo?

En realidad formar un equipo no es difícil, lo que cuesta en realidad es mantener el equipo y cumplir objetivos. Para eso hay que tratar de ser lo mas organizado posible, y no desistir. Claro que puedes tomarte un tiempo de descanso, pero, también después hay que volver.

No soy para nada una persona exitosa, pero tengo algo experiencia en equipos remotos. Por mera práctica. Y lo que recomendaría para un equipo remoto, sería:

1) Un líder que ponga las tareas y que nunca se canse, y motive al equipo. Resuelva conflictos mas que provocarlos.

2) Cuando hayan conflictos tratar de que el grupo no se disuelva.

3) Usar herramientas de gestión de proyectos, como podría ser HackNPlan.

4) No ser tóxico, las cosas siempre se puede decir de buenas palabras.

5) Avanzar a pesar de que no todos pueden dar el mismo tiempo de trabajo.

6) Usar GIT.

7) Usar Google Drive o/y Dropbox.

8) Hablar las cosas antes de que sucedan

5. ¿Cuánto tiempo costó desarrollar SpaceShip?

La verdad que costó bastante tiempo. Estaba tratando de desarrollar la idea y tuve algunos problemas con el proyecto por usar versiones de Software inestable (La alpha de Godot 3.1).

Aunque el proyecto en equipo empezó el 30/05/2018 y salió la primera versión en el 31/10/2018 evidentemente hubieron muchos tiempos de descanso y de poca participación, también hubo un mes que me tome para hacer el curso de GDScript en Godot Engine.

6. ¿Cuál fue la mecánica más difícil de programar?

Bueno personalmente me enredé un poco en el tema de los ítems, la tienda y esas cosas. No sabía bien como almacenar los items en disco, recuperarlos, etc. Por eso aislé el problema y lo hice un plugin, liberando el código a toda la comunidad.

Pero no hay nada que no se pueda resolver con un papel y lápiz, y esto aunque parezca una práctica no tan importante, es vital. De hecho hay una frase que dice “Resuelve el problema, luego escribe el código”. No digo que siempre haya que cumplirlo, pero cuando uno se ve complicado, es bueno hacerlo.

7. ¿Tienes otros proyectos?

Sí, claro, tengo varios proyectos en Itch.io y en Google Play. Actualmente estoy participando en la jam de GithubGameOFF con un juego de monstruos.

8. ¿Qué tal es la experiencia publicando en Google Play?

La verdad, es difícil, en Google Play hay mucha competencia. Cada día salen más y más aplicaciones. Si uno no tiene los medios para el marketing lo único que queda es tratar de hacer un buen producto y que guste. Y esto no es para nada fácil.

La verdad el tráfico orgánico es lo que mas me ha dado resultado hasta el momento, aunque aún así todavía no hay buenos resultados.

Bueno, no quiero deprimiros con Google Play pero el tema es que hay que seguir y tarde o temprano se cosecha lo que se siembra. Hay gente que le va muy bien con los juegos en Google Play, pero me imagino que solo pocos, muy pocos, les ha ido bien a la primera.

9. ¿Cómo te va publicando en Itch.io?

¡Mal! ¿No es suficiente con preguntar lo de Google Play?. Por ahora Itch.io lo veo como portafolio, pero no es malo. Siempre hay gente que le va bien en esas cosas, pero es algo complicado. También tiene opciones muy interesantes como Jams y devlogs.

10. ¿Continuarás usando Godot Engine para futuros proyectos?

Por su puesto, es un engine que cada vez me gusta más y cada vez me da mejores resultados.

11. ¿Es rentable el desarrollo de tus proyectos?

Por ahora no… Pero en el desarrollo de videojuegos hay que pensar a largo plazo.

12. ¿Recomendarías algo a los nuevos desarrolladores que usen Godot u otro Engine?

Claro, como pudieron ver no soy la persona mas exitosa del mundo, pero si he aprendido varias cosas.

1) Si eres nuevo no hagas proyectos grandes, lo normal es que tengas una mala experiencia con ellos y los dejes abandonados. Es mucho mas motivador terminar cosas pequeñas que muy probablemente no terminar algo muy grande. Puedes ir aumentando de a poco y de paso hacerte portafolio.

2) El desarrollo de videojuegos es golpearse contra la pared varias veces, donde la pared es la realidad. Es un tema en el cuál hay que aprender mucho de varias cosas, para lograr buenos resultados. Mucha práctica.
No le hagas asco a las demás áreas. Si eres bueno programando no le hagas asco a la música o al arte o al marketing. Con esto me refiero a que sepas un poco de todo, esto te servirá mucho. Si haces el peor pixel art del mundo, por lo menos es -tú- pixel art y eso se valora mucho.

3) Usa Git o un sistema de control de versiones: Esto te ayudará a no perder el proyecto y a recuperar cosas que “perdiste”.

4) Usa un administrador de proyectos: HackNPlan o Trello, estan muy bien, pero se organizado. Esto aumenta mucho la productividad. Aumentar la productividad es también un tema de engañar a tu cerebro.
Aprende de los demás: Ve videos, escucha mas que hablar, hay gente que le va bien que tiene mucho que decir y hay gente que no le va tan bien que también tiene mucho que decir.


5) Filtra bien las críticas: Hay críticas que son sólo para hacer daño y hay críticas que son constructivas. Por lo general las críticas que son dañinas son sólo eso, dañinas, no muestran cosas positivas de tu juego. No pierdas el tiempo con ellas. Siempre hay algo positivo. Por muy malo que sea tu juego siempre se puede rescatar algo. Las criticas constructivas tienen el componente “ayuda” y se nota. Normalmente te dicen me gusta esto, pero no me gusta esto. Son objetivas.

6) Termina los proyectos: No soy el indicado para decirlo, pero es algo que se tiene que aprender. Cuando empieces un proyecto, tiene que ser algo que te motive. Motivación vas a necesitar para terminar el proyecto.

7) Planifica tu proyecto, es algo que he aprendido a porrazos. Si lees esto, avisado estas, no comentas estos errores. Has un GDD (Game Doument Design).

Con esto terminamos esta sesión de preguntas. Muchas gracias Matías por estos consejos. Puedes visitar sus redes sociales con los siguientes enlaces:

Canal de Youtube: https://www.youtube.com/user/ElementalCodeNet

Twitter: https://twitter.com/matias_vme

Facebook: https://www.facebook.com/FuryCode/

Udemy: https://www.udemy.com/aprender-a-programar-para-desarrollar-videojuegos-con-godot/

Recuerda descargar juego UltraSpaceShips recientemente publicado: https://play.google.com/store/apps/details?id=spaceship.shooter.rpg.deluxe.furygames