Archivo de la categoría: Godot Engine

Animaciones con el nodo Tween – Godot Engine

Si necesitamos una animación muy básica, donde sólo tenemos que cambiar algunas propiedades de un nodo, puede que usar AnimationPlayer sea muy exagerado. Ese nodo dispone de muchas funciones que para una animación sencilla no hacen mucha falta, así que Godot nos ofrece una alternativa con el nodo Tween, para tener animaciones sencillas o hasta con un cierto nivel de complejidad.

Dibujar con la función _draw() – Godot Engine

Hay momentos donde necesitamos hacer una simple línea, rectángulo o círculo y no podemos, o no queremos, recurrir a una herramienta de diseño. Desde Godot también podemos realizar estos «dibujos» simples empleando unos métodos que se incluyen en cada nodo descendiente de Control y Node2D.

Si bien en el vídeo les enseño a usar métodos que unicamente son para dibujar figuras, también podemos tener en cuenta el siguiente:

 draw_texture( Texture texture, Vector2 position, Color modulate=Color( 1, 1, 1, 1 ), Texture normal_map=null )

Se usa para dibujar texturas, es útil si no queremos crear un Sprite o TextureRect desde código o el inspector. En su primer parámetro tenemos que indicar la dirección de la textura, si conocemos su dirección en la carpeta de proyecto, podemos usar algo como: load(«res://nombre.png»)

En su segundo parámetro colocamos un Vector2() con la posición que queremos para la textura. Por último asignamos un color, ahí podemos usar el método que enseño durante el vídeo.

Repositorios Libres – Tappy Plane

Mecánicas del clásico Flappy Bird desarrolladas en Godot Engine. Para expandir las características respecto al juego original, se añadió un selector de jugador, escenario y obstáculos que consiste básicamente en cambiar la apariencia del escenario.

Curso completo

Propuestas

Si tienes la idea de una característica que pueda mejorar el proyecto, puedes proponerla. Realizaré un vídeo desarrollándola y explicando la función.

También puedes desarrollar por tu cuenta y subir los cambios a los repositorios de GitHub y GitLab del proyecto.

Puedes comentar una propuesta en algún vídeo o artículo relacionado con el curso. Cada cierto tiempo se publicará una encuesta en mi página de Patreon donde podrán elegir una de las características.

Repositorios Libres – Plataformas 2D

Recreación de un juego de plataformas como el típico Mario Bros. Entre las cosas que pueden resultar interesantes para ustedes, esta la animación de los bloques al generar una moneda, el punto de control a mitad de nivel y la capacidad de hablar del personaje.

Curso completo

Propuestas

Si tienes la idea de una característica que pueda mejorar el proyecto, puedes proponerla. Realizaré un vídeo desarrollándola y explicando la función.

También puedes desarrollar por tu cuenta y subir los cambios a los repositorios de GitHub y GitLab del proyecto.

Puedes comentar una propuesta en algún vídeo o artículo relacionado con el curso. Cada cierto tiempo se publicará una encuesta en mi página de Patreon donde podrán elegir una de las características.

Repositorios Libres – Mata Patos

Proyecto sencillo donde unos patos son generados cada cierto tiempo y les disparamos para hacer puntos. Útil para aprender más sobre el ParallaxBackground y el nodo CanvasLayer.

Estado del curso para YouTube

CapítulosGrabado/PreparadoProducciónPublicación
1PreparadoNoDiciembre
2PreparadoNoDiciembre
3PreparadoNoDiciembre

Propuestas

Si tienes la idea de una característica que pueda mejorar el proyecto, puedes proponerla. Realizaré un vídeo desarrollándola y explicando la función.

También puedes desarrollar por tu cuenta y subir los cambios a los repositorios de GitHub y GitLab del proyecto.

Puedes comentar una propuesta en algún vídeo o artículo relacionado con el curso. Cada cierto tiempo se publicará una encuesta en mi página de Patreon donde podrán elegir una de las características.

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

Dev snapshot: Godot 3.1 alpha 2

Dos meses después de nuestra versión alfa anterior, nos complace lanzar Godot 3.1 alpha 2, una nueva versión de desarrollo de la rama maestra, que avanza lenta pero constantemente hacia el estado beta.

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 subsiguientes!) Fusionadas en la rama maestra desde enero de 2018, y especialmente todas las que se muestran en nuestros devblogs pasados Han pasado 9 meses desde la versión 3.0 y cerca de 5,000 cambios, ¡así que espere muchas cosas buenas en la versión final 3.1!

La etapa alfa nos corresponde a una congelación de características (ver el anuncio en GitHub), lo que significa que ya no consideraremos solicitudes de extracción con nuevas características para fusionar en la rama maestra, y eso hasta que se libere Godot 3.1. De esta manera, podemos centrarnos en lo que ya tenemos, finalizar y pulir las características principales que aún están en progreso (por ejemplo, soporte de OpenGL ES 2.0) y corregir muchos de los errores antiguos y nuevos informados por la comunidad.

Las instantáneas alfa se publicarán regularmente durante esta fase, para probar continuamente la rama maestra y asegurarse de que siga siendo más estable, confiable y lista para la producción.

Aclaramos que

IMPORTANTE: esta es una compilación alfa, 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 hay un largo camino para corregir errores y mejorar la usabilidad hasta que podamos lanzar la versión estable. Este lanzamiento es exclusivo para probadores que ya están familiarizados con Godot y pueden informar los problemas que experimentan en GitHub.

Tampoco hay garantía de que los proyectos iniciados con la compilación alfa 2 sigan funcionando en las compilaciones alfa 3 o posteriores, ya que nos reservamos el derecho de hacer los ajustes de ruptura necesarios hasta la etapa beta (aunque los cambios de compatibilidad en esta etapa deberían ser mínimos, en caso de presentarse).

Nota: los nuevos usuarios de Godot no deben usar esta versión para comenzar su aprendizaje. Godot 3.0.x es nuestra rama estable actual y aún recibe actualizaciones frecuentes.

Nuevas características

Las notas de la versión aún no están escritas, pero puede consultar el registro de cambios detallado en el que está trabajando nuestro colaborador Hugo Locurcio.

Como se mencionó anteriormente, nuestros devblogs anteriores también deberían darle una idea de los aspectos más destacados del próximo lanzamiento.

Este alfa 2 viene con una cantidad impresionante de correcciones de errores en comparación con el alfa 1. El backend de OpenGL ES 2.0 también ha visto mucho trabajo para empujarlo hacia la finalización de funciones, aún no está hecho, pero se está acercando.

Los redactores de documentación están trabajando duro para ponerse al día con las nuevas características, y la rama más reciente ya debería incluir detalles sobre muchas de las nuevas características 3.1.

Descargas

Los enlaces de descarga no se muestran en la página de descargas por ahora para evitar confusiones para los nuevos usuarios. En su lugar, navegue por uno de nuestro repositorio de descargas y busque el binario del editor que coincida con su plataforma:

IMPORTANTE: haga copias de seguridad de sus proyectos Godot 3.0 antes de abrirlos en cualquier versión de desarrollo 3.1. Una vez que se haya abierto un proyecto en 3.1, su archivo project.godot se actualizará a un nuevo formato para asignaciones de entrada que no es compatible con Godot 3.0; este último se negará a abrir un proyecto 3.1. Además, el uso de las nuevas características 3.1 en su proyecto significa que no puede volver a la versión 3.0, a menos que haga el trabajo necesario para eliminar el uso de esas características. Entonces, pruebe 3.1-alpha2 en una copia de sus proyectos 3.0 o inicie nuevos proyectos con él.

NOTA: esta versión todavía se llama «3.1.alpha» internamente, igual que alfa 1 y compilaciones diarias desde la rama maestra. Esto significa que las plantillas de exportación comparten la misma carpeta de instalación, pero debe asegurarse de reemplazar cualquier plantilla «3.1.alpha» que haya instalado actualmente con las de la distribución alfa 2.

Debido a algunos problemas del sistema de compilación, alpha2 no tiene plantillas de exportación que funcionen para el objetivo ARM de UWP. Además, las características upnp y websockets faltan por completo en las plantillas de exportación de UWP.

Reporte de errores

Todavía hay cientos de informes de errores abiertos para el hito 3.1, lo que significa que ya estamos conscientes de muchos errores. Sin embargo, muchos de esos problemas pueden no ser críticos para la versión 3.1 y pueden volver a dirigirse a una versión posterior para permitir la liberación de Godot 3.1 en un futuro próximo.

Como probador, se recomienda que abra informes de errores si experimenta problemas con 3.1 alpha. Compruebe primero los problemas existentes, utilizando la función de búsqueda con palabras clave relevantes, para asegurarse de que el error que experimenta no se conoce ya.

La imagen de la ilustración es del juego FOSS Mystic Treasure Hunt 3D de Krzysztof Jankowski. Puedes leer más sobre su viaje como artista en su blog

Aclaro que esto es una traducción del blog original.

Nuevo panel de Sistema de Archivos para Godot 3.1

Antes que nada, nos gustaría agradecer a nuestro patrocinador Gamblify por haber donado esta nueva característica a la comunidad. Su participación y su apoyo constante para mejorar Godot son muy apreciados.

Para la próxima versión 3.1, Godot obtiene un nuevo sistema de archivos. Los archivos, no solo las carpetas, ahora se muestran directamente en la vista de árbol y tienen una vista previa:

Esta nueva pantalla, que se puede cambiar con la anterior con un botón en la parte superior de la base, evita dividir la base en dos áreas. Esto permite una interfaz más compacta, que también nos lleva a reconsiderar el diseño predeterminado para el editor. Como puede ver, ahora hay más espacio disponible para el inspector, lo que reduce el desplazamiento necesario allí:

Características

Este nuevo panel presenta varias cosas:

  • Los archivos ahora se pueden marcar como favoritos, no solo como carpetas.
  • Soporte completo al momento de arrastrar y soltar archivos, incluido arrastrar archivos y carpetas a la sección de favoritos:
  • Podemos tener iconos al lado de cada nombre de archivo. Para texturas y materiales, este icono se reemplaza por una miniatura pequeña del recurso.
  • Un campo de búsqueda, para filtrar las entradas en el árbol de recursos:
  • Un menú que desplegamos con el clic derecho para manejar archivos  funciona exactamente en la lista de archivos.
  • El botón «Marcar como favorito» se ha movido a una entrada de menú, que se encuentra al hacer clic con el botón derecho en archivos o carpetas.
  • El botón «Buscar escena actual en archivos» se ha movido a una entrada de menú, al hacer clic con el botón derecho en una pestaña de escena.

Esperamos que disfrute de este nuevo sistema de archivos. ¡Estamos esperando tus comentarios!

Nota: esta nueva característica a estado funcionando desde antes que la congelación de la función entrara en vigencia con Godot 3.1 alpha.

Este artículo es una traducción del oficial, puedes leer desde la web de Godot aquí: https://godotengine.org/article/godot-gets-new-filesystem-dock-3-1

Simplex Noise Lands in Godot 3.1 – Versión español

¡La generación de ruido simple acaba de aterrizar en Godot 3.1! Este algoritmo de generación de ruido, originalmente inventado por Ken Perlin, es rápido y tiene muy buenos resultados.  Todavía tiene algunas patentes privadas, por eso Godot utilizará OpenSimplex noise, de dominio público y una buena alternativa.

Sus aplicaciones

El ruido simple, como cualquier otro tipo de ruido, es especialmente útil en dos áreas del desarrollo de un juego: procedural generation y efectos visuales.

Procedural Generation

Generar contenido de procedural en vídeojuegos puede ser un desafío, las estructuras completamente aleatorias tienden a convertirse en un completo desastre y, por lo tanto, inutilizables. Es por eso que la «aleatoriedad controlada» del ruido simple se vuelve realmente útil. Si desea obtener más información sobre cómo funciona el ruido «fractal» y algunas otras técnicas de generación de terreno, recomiendo encarecidamente este artículo de Red Blob Games.

Un prototipo de Godot: voxel world prototype de Zylann, que utiliza su propio módulo OpenSimplex, puede ser reemplazado por la implementación incorporada.

Efectos visuales

Las texturas de ruido 2D son realmente útiles cuando se crean efectos nublados u ondulados. Por ejemplo, el nuevo recurso NoiseTexture se puede usar como un mapa normal para obtener un material de agua rápido y simple:

Las texturas de ruido también se pueden usar como mapas de rugosidad, texturas de luz 2D, etc. Pero el verdadero poder de las texturas de ruido está disponible cuando se utiliza en combinación con shaders de texto:

Empezando

GDScript

Generar ruido desde GDScript es tan simple como instaurar un nuevo generador de ruido, establecer sus parámetros y tomar muestras en las posiciones deseadas:

# Instantiate
var noise = SimplexNoise.new()

# Configure
noise.seed = randi()
noise.octaves = 4
noise.period = 20.0
noise.persistance = 0.8

# Sample
print(noise.get_noise_2d(1.0, 1.0))
print(noise.get_noise_3d(0.5, 3.0, 15.0))
print(noise.get_noise_3d(0.5, 1.9, 4.7, 0.0))

Otra forma de acceder a los valores de ruido es precomputar una imagen de ruido:

# This creates a 512x512 image filled with simplex noise (using the currently set parameters)
var noise_image = noise.get_image(512, 512)

# You can now access the values at each position like in any other image
print(noise_image.get_pixel(10, 20))

Para obtener más información acerca de SimplexNoise y cuál es el significado de cada parámetro, no olvide consultar la documentación.

Texturas de ruido

Si solo necesita acceso a una textura de ruido para efectos visuales, el nuevo tipo de recurso NoiseTexture es su mejor opción. Le permite especificar un generador de ruido y una textura. Los datos de textura se rellenarán automáticamente con ruido, utilizando los parámetros del generador. También puede habilitar el uso de ruido sin interrupciones (solo funciona con texturas cuadradas) y permitir la salida de datos de ruido como un mapa normal.

NOTA: Este artículo es una traducción de la noticia oficial, la puedes visitar en este enlace: https://godotengine.org/article/simplex-noise-lands-godot-31