Actualización de Godot 4.1

 (godotengine.org)
1 puntos por GN⁺ 2023-07-07 | 1 comentarios | Compartir por WhatsApp
  • Godot 4.1 es una versión incremental lanzada 4 meses después de 4.0, que pule la estabilidad, el rendimiento y el acabado, mientras añade funciones como evasión de navegación con IA y un editor de código desacoplable
  • Esta versión corrigió más de 900 issues reportados durante el uso de Godot 4 o detectados en las pre-releases de 4.1, y fue construida con aportes de más de 300 contribuidores
  • Una mejora importante de rendimiento fue cambiar la adición y eliminación de nodos hijos a un sistema basado en hash maps más rápidos, lo que acelera proyectos complejos, aunque con costo en algunas tareas poco comunes y en el uso de memoria de Node
  • Se amplían los flujos de trabajo de scripting y del editor con variables estáticas de GDScript, [GlobalClass] de C#, extensiones GDExtension y editor de scripts desacoplable
  • En general, migrar proyectos de 4.0 a 4.1 es seguro, pero quienes usen C# y GDExtension deben revisar primero posibles incompatibilidades y necesidades de porteo y recompilación

Resumen del lanzamiento de Godot 4.1

  • Godot 4.1 es una actualización que llega tras 4 meses de trabajo desde Godot 4.0 y continúa la idea de mejorar 4.0 con lanzamientos incrementales frecuentes
  • El foco principal de esta release es la estabilidad, el rendimiento y la calidad final, aunque también incluye funciones nuevas
    • evasión de navegación con IA mejorada
    • capacidad de desacoplar el editor de código y colocarlo en otra pantalla
  • Se corrigieron más de 900 issues reportados por usuarios durante el uso de Godot 4 o encontrados en las pruebas de las pre-releases de 4.1
  • La mayoría de los juegos y apps hechos con 4.0 pueden migrarse a 4.1 con relativa seguridad
    • quienes usen C# y GDExtension deben esperar algunas incompatibilidades
    • antes de migrar es necesario hacer respaldo, y se recomienda hacer commit del estado del proyecto con un sistema de control de versiones como Git
    • la guía de migración está en preparación
  • Godot 4.1 puede descargarse desde la página de descargas

Contribuciones de la comunidad y financiamiento del desarrollo

  • Godot es un proyecto impulsado por la comunidad, donde contribuidores individuales participan en la mejora del motor
  • En los últimos años, gracias a donaciones de usuarios y empresas, fue posible contratar a tiempo completo a algunos contribuidores clave, lo que permitió releases más rápidas
  • Actualmente, el gasto mensual supera las donaciones mensuales, por lo que el financiamiento del desarrollo sigue dependiendo de grandes donaciones corporativas puntuales
  • Para mantener el ritmo de actualizaciones de Godot 4 y contratar maintainers que revisen más contribuciones, se necesitan más donaciones mensuales
  • Además del apoyo económico, también se puede contribuir al proyecto de varias formas
    • redactar reportes de bugs detallados
    • contribuir al codebase
    • escribir documentación
    • escribir guías en la documentación oficial o en sitios web personales
    • responder preguntas y compartir consejos en plataformas de la comunidad
  • Esta release fue construida con aportes de más de 300 contribuidores, y la lista completa de correcciones de bugs y mejoras puede consultarse en el interactive changelog

Mejoras de rendimiento

  • Los juegos hechos con Godot se construyen sobre árboles de nodos, el componente base de las entidades del juego, y agregar o eliminar nodos es una operación muy frecuente dentro del motor
  • En 4.1, el algoritmo para agregar y eliminar nodos hijos se cambió a uno basado en hash maps rápidos, haciendo estas operaciones varias veces más rápidas
    • algunas operaciones poco comunes con nodos se vuelven un poco más lentas
    • el uso de memoria de la clase base Node aumenta 10%
    • el beneficio es especialmente grande en proyectos complejos con mucha manipulación de nodos
  • Se agregó multithreading experimental para escenas
    • una nueva propiedad de nodo permite controlar si el procesamiento del nodo será secuencial o en paralelo
    • como sigue siendo una función experimental, se necesitan pruebas amplias para encontrar edge cases
    • no se recomienda su uso en producción
  • También se corrigieron muchos problemas y limitaciones en la carga multihilo
  • Al renderer Vulkan se le agregó un pipeline cache
    • el shader cache existente reducía los tirones por compilación de shaders, pero la compilación de pipelines todavía podía causar tirones y tiempos de carga lentos
    • no soluciona por completo los tirones por compilación de pipelines, pero puede reducir un poco los tiempos de carga en backends de renderizado basados en RenderingDevice
    • este caché puede desactivarse en la configuración del proyecto y en Godot 4.1 viene activado por defecto
    • no resuelve todas las causas de pausas, así que el trabajo continuará en futuras releases

Cambios en el motor central

  • Al importar modelos en Godot, era frecuente que los modelos quedaran orientados hacia atrás
  • En 4.1 se aplicaron varios cambios para reducir este problema
    • en el editor se intercambió la dirección frontal y trasera de la cámara
    • a la función look_at() se le agregó un argumento para usar el espacio del modelo como referencia frontal, en lugar del eje -Z de la cámara
    • este cambio también ayuda a corregir un viejo bug de seguimiento de rutas
  • Se agregó suavizado del delta de frame a Godot 4
    • puede mejorar mucho la fluidez del movimiento y ofrecer un gameplay más suave
    • viene activado por defecto
    • solo funciona cuando VSync está activado

Mejoras de scripting

  • GDScript

    • antes, para compartir datos entre múltiples instancias del mismo script, era necesario usar recursos o autoload
    • desde Godot 4.1 ahora es posible crear y usar variables estáticas
    • las variables estáticas almacenan datos en la clase, no en cada instancia, y todas las instancias de la misma clase comparten ese valor
    • se usan agregando la palabra clave static antes de la definición de variable en la parte superior del script
    • también se mejoró la generación automática de documentación para clases con nombre, añadida en Godot 4
    • los enums ahora se tratan como tipos, haciendo la documentación generada más precisa
    • además del docstring sobre definiciones de variables o funciones, ahora también se pueden usar docstrings inline

  • C#/.NET

    • el foco de C# en esta release es aumentar la paridad funcional con GDScript
    • en GDScript ya era posible agregar un nombre de clase global al script para definir nuevos tipos de nodo utilizables en el editor
    • desde Godot 4.1, en C# también es posible hacer lo mismo agregando el atributo [GlobalClass] al archivo
    • con el atributo [Icon] también se puede asignar un ícono propio a la clase global
    • sin embargo, al momento de 4.1, los proyectos hechos con C# todavía no pueden exportarse a plataformas móviles ni web
    • el trabajo de soporte sigue en progreso
    • la solución de esta limitación probablemente dependa del lanzamiento de .NET 8 a fines de 2023
    • el trabajo serio de soporte para plataformas móviles y web probablemente solo podrá comenzar de lleno en la segunda mitad de 2023

  • GDExtension

    • Godot ofrece una tecnología que permite usar lenguajes de bajo nivel como C++ como lenguaje de scripting para juegos sin recompilar el motor
    • GDExtension sigue en beta en esta release
    • en 4.1, la capacidad de scripting de GDExtension se acerca más a la de GDScript y C#
    • ahora es posible implementar nuevos nodos de visual shader
    • se pueden crear plugins del editor con GDExtension
    • se implementó un sistema de compatibilidad hacia atrás para ayudar a que el código hecho para Godot 4.1 siga funcionando ante futuros cambios de API
    • aun así, para corregir problemas centrales de GDExtension, en 4.1 fue necesario introducir una ruptura importante de compatibilidad
    • las extensiones existentes de Godot 4.0 deben portarse y recompilarse para 4.1
    • también se retomó bastante trabajo arquitectónico para hacer que la API de GDExtension pueda expandirse en el futuro

Flujo de trabajo del editor

  • Godot 4 ya venía soportando múltiples ventanas para configuración del proyecto, configuración del editor y varios pop-ups
  • Desde 4.1 se pueden desacoplar documentos en ventanas flotantes, y también desacoplar el editor de scripts, incluido el editor de shaders, para colocarlo en un monitor aparte
  • El editor puede rastrear el layout de ventanas y, al cerrarse y volver a abrirse, mantener la ubicación de trabajo anterior
  • Godot 4.0 soportaba definir y exportar arrays tipados, así como exportar nodos individuales al inspector, pero no podía combinar ambas cosas
  • Desde Godot 4.1, ahora se pueden exportar arrays de nodos al inspector, facilitando conectar objetos del juego entre sí
  • El project manager recibió funciones para asignar tags a proyectos individuales y filtrarlos por tag
    • esto facilita encontrar proyectos Godot cuando se tienen decenas o cientos

Cambios de renderizado

  • La turbulencia de partículas fue rediseñada con base en feedback de artistas, dando mayor control creativo
  • La turbulencia se usa mucho para crear efectos ricos y amplios como los que se ven en juegos modernos
  • Con la nueva textura de ruido 3D es más fácil controlar la densidad de la niebla volumétrica
    • se puede hacer la niebla más delgada en áreas específicas
  • NoiseTexture3D también puede usarse para crear campos vectoriales de atracción de partículas
    • esto es útil para simular viento que afecta a las partículas
  • El renderer de Godot todavía tiene muchas mejoras planeadas, y la mayoría llegarán en futuras releases
  • El equipo de renderizado y los contribuidores están priorizando corrección de bugs y estabilidad por encima de nuevas funciones
  • El renderer 3D GLES3 todavía no está terminado, y durante los próximos meses se hará un trabajo considerable en él

Mejoras de navegación

  • Godot 4.0 introdujo evasión en tiempo real para navegación con IA, pero estaba limitada a un solo plano
  • Godot 4.1 incluye un algoritmo de evasión completamente reescrito
    • ofrece mejor comportamiento y mayor control
    • la evasión ahora puede funcionar en 2D o 3D
    • permite que agentes voladores se desplacen por encima de agentes terrestres
  • Con capas, se puede controlar qué agentes evitan a cuáles
  • También se pueden asignar prioridades para que algunos agentes empujen a otros
  • El comportamiento de navegación mejorado puede verse en la documentación actualizada

Soporte de plataformas y limitaciones web

  • El alcance del soporte de plataformas en Godot 4.1 es el mismo que en Godot 4.0
  • Tanto en el motor estándar como en la versión .NET se puede exportar a todas las plataformas de escritorio
  • Si el proyecto no usa C#, se puede exportar a móvil y web
  • Al momento de 4.1, la exportación web tiene limitaciones por la falta de soporte de proveedores para algunas funciones modernas
    • pueden aparecer problemas en navegadores con mal soporte de WebGL 2, como Chrome en macOS
    • es difícil resolverlo sin un esfuerzo importante en cambios por parte de Google o soporte de un renderer dedicado para WebGL 1 / GLES2
  • En plataformas de hosting donde no se pueden configurar los headers CORS requeridos para SharedArrayBuffer, configurar juegos web se vuelve complejo
    • este problema depende en gran medida de la implementación del header coep:credentialless en Safari
    • los navegadores basados en Chromium y Firefox ya funcionan bien
    • en particular, funciona muy bien al publicar en itch.io
    • se están investigando posibles alternativas

Problemas conocidos y próxima release

  • Godot 4.1 todavía tiene problemas que no se pudieron resolver antes del lanzamiento
  • El rastreador de bugs puede consultarse en Godot GitHub issues
  • Uno de los principales problemas identificados es que la nueva API para definir propiedades de configuración personalizadas en export presets no puede conservar la configuración del usuario
    • al reiniciar el editor, las opciones de configuración se reinician y desaparecen
    • la corrección llegará en 4.1.1
    • el PR relacionado es GH-79025
  • El trabajo en Godot 4.2 ya comenzó y se espera su lanzamiento en 4 meses
  • Godot mantiene la dirección de sostener un ciclo de releases estable para que las siguientes mejoras y nuevas funciones no tarden demasiado en llegar

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-07-07
Opiniones de Hacker News

  • Hace poco me pasé casi por completo de Unity a Godot 4.0 y, aunque no soy desarrollador de juegos profesional, como alguien que hace juegos pequeños tipo indie/itch.io, estoy realmente satisfecho
    Es ligero, rápido y fácil de aprender, y puede cubrir el 90% de lo que necesita un desarrollador solitario/indie
    Sin embargo, todavía no puedo abandonar Unity por completo debido a un bug por el que, cuando los usuarios de macOS abren un juego en itch.io, la carga tarda tanto que piensan que está roto y cierran la pestaña
    Los juegos que hago suelen ser educativos o estar dirigidos a niños que usan iPad/MacBook, así que es mucho más fácil darles un enlace de itch.io que enseñarles a instalar algo localmente y convencer al dueño del dispositivo
    Desde Godot dicen que lo están resolviendo, pero hasta entonces tendré que seguir usando Unity en algunos proyectos. Si se soluciona este problema, creo que Godot podría despegar mucho en el ámbito de itch.io/game jams

    As of 4.1 web exports still have some limitations due to poor vendor support of certain modern features. Browsers with bad WebGL 2 support, such as Chrome on macOS, unfortunately suffer from issues which we cannot address without a fix from Google or a significant amount of effort put into supporting a dedicated WebGL 1 / GLES2 renderer.
    We are also aware of the complexity setting up web games on hosting platforms which don’t let you set the required CORS headers for SharedArrayBuffer support. This mostly depends on Safari implementing the coep:credentialless header support, while Chromium-based browsers and Firefox already work fine (especially if you publish on itch.io). There is a possible workaround that we are investigating.

    • Estaba en una situación parecida y al final me di cuenta de que Godot 3.5.2 sigue siendo una versión con soporte a largo plazo y que las exportaciones web también funcionan muy bien. El ejemplo que me convenció de hacer el cambio fue este: https://yet-another-lucas.github.io/plumbing-adventure/
      Después de eso pasé de Godot 4.0 C# a Godot 3.5.2 + GDScript, y estoy satisfecho
      También configuré un pipeline de CI/CD que compila y despliega automáticamente en Github Pages cada vez que hago commit a master, y este tipo de pipeline está bastante bueno
      https://www.reddit.com/r/godot/comments/q25riu/hosting_on_gi...
    • Este año hice 5 pequeños juegos estilo game jam basados en navegador con Godot 3.5[1], y en general la experiencia fue buena. Hasta que la exportación web de Godot 4 funcione correctamente, se puede estar perfectamente contento usando Godot 3.5
      Godot 4 trae mejoras de lenguaje que me entusiasman, como mejor soporte de tipos y cambios que reducen el uso de strings mágicos, por ejemplo la capacidad de referenciar señales por nombre
      Pero si eso es un gran obstáculo, quizá convenga esperar
      A veces me frustra que el equipo de Godot 4 vea el problema de macOS como un bug de Chrome y no como una regresión de Godot[2]
      Es más una cuestión de semántica y prioridades, pero si una funcionalidad de la que dependías en Godot 3 se rompe en Godot 4, es difícil no verlo como una regresión
      Aun así, estoy muy agradecido por todo el trabajo hecho en Godot 4 y en las versiones anteriores, y espero con ganas el día en que pueda usar Godot 4
      [1] Si te da curiosidad, están todos en https://eieio.games/
      [2] https://github.com/godotengine/godot/issues/70691
    • Me llamó la atención la parte de “navegadores con mal soporte de WebGL 2 como Chrome en macOS”
      Hasta ahora no he tenido problemas con WebGL2 en Chrome/macOS, así que me da curiosidad saber exactamente de qué problema se trata
      Aunque yo también evito cosas conocidas por causar problemas entre las funciones de WebGL2/GLES3. Principalmente buffers uniformes o patrones de actualización de buffers que funcionan bien en nativo pero no en WebGL, por ejemplo cosas como “buffer orphaning”
    • Me da curiosidad cuál es el estado del soporte de VR en Godot. Usé UE4 durante 9 años y Unity no me gusta demasiado, pero me gustaría probar Godot
    • Desarrollo juegos con Godot en macOS y los publico en itch.io, pero nunca me encontré con este problema. ¿Podrías dar un ejemplo donde ocurra y la información de configuración de exportación del build?

  • Godot es una herramienta realmente impresionante. Si aparece una razón para empezar un nuevo proyecto de juego, quiero aprenderlo más en serio, y al ver lo que lograron con un equipo relativamente pequeño, Unity casi queda en vergüenza
    También es impresionante que hayan “corregido más de 900 problemas reportados durante el uso de Godot 4 y las pruebas de versiones preliminares de 4.1”
    El hecho de haber corregido tantos problemas mientras seguían mejorando el rendimiento y la estabilidad merece elogios

    • La corrección de 900 problemas sin duda es impresionante, pero Godot probablemente sea uno de los repositorios con más issues abiertos en GitHub. Incluso ahora tiene más de 5,000 abiertos
      Por supuesto, la cantidad de issues abiertos no es un buen indicador para juzgar la calidad del software

  • Me gusta Godot, pero hay algunas cosas que me dejan con ganas de más. GDScript no es Python, y le faltan esas pequeñas funciones que hacen que Python sea genial, como las comprensiones de listas/diccionarios, .items(), los conjuntos, etc.
    Aun así, para desarrollo de juegos es suficiente y encaja bien con el entorno, incluidos los tipos nativos, así que es un lenguaje bastante bueno.
    He usado GDNative y todavía tengo que probar más GDExtension, pero hasta ahora escribir C++ para Godot se siente bastante áspero. El programador tiene que usar tipos de Godot y new() por todos lados, así que no es muy fácil de manejar.
    Por eso Godot, más que un motor realmente de C++, se parece más a uno donde la mayor parte del tiempo usas un lenguaje de scripting y solo optimizas en C++ cuando los scripts no son lo bastante rápidos.
    También quisiera comprobar más qué tan rápido es GDScript en la práctica frente a otros lenguajes, y no sé si Mono/.NET es más rápido. Me gusta que sea un lenguaje perfectamente integrado con el diseño del entorno, pero me pregunto si hay planes para mejorarlo.
    Planeo hacer un FPS multijugador y parece que Godot no ofrece predicción de red; me gustaría que la ofreciera.
    También me preocupa el soporte de OpenGL a futuro. Todavía no está completamente terminado, y me preocupa que, al ser tan distinto de APIs nuevas como Vulkan o DX12, sea difícil implementarlo bien.
    En general, Godot es lo mejor que le ha pasado al código abierto y al desarrollo de juegos. El desarrollo de juegos ha sido un campo donde al open source le costaba hacerse un lugar, y el diseño ligero de Godot es un gran alivio frente a herramientas enormes como Unreal o Unity.

    • Ese también es el mayor problema de Godot. Aunque no porque GDScript no sea Python, sino porque no es un lenguaje de propósito general. Es casi lo único que extraño de Unity.
      Claro, probablemente no elegiría Python directamente; aunque es un lenguaje que me gusta, optaría por uno más enfocado en rendimiento. Go también podría ser una buena opción.
      GDScript en sí no es malo; si no lo comparas con otros lenguajes, es bastante excelente. Pero frente a un lenguaje de propósito general se pierde demasiado.
      Sé que existen bindings, pero al tener una experiencia similar con Raylib, el soporte no oficial de lenguajes era prácticamente inexistente. Incluso Mono, que es el binding oficial, es bastante malo.
    • .NET es más rápido.
      Aun así, incluso los juegos AAA suelen usar lenguajes de scripting lentos para la lógica del juego. En muchos juegos, la lógica de juego no es una parte que consuma mucha CPU, así que muchas veces no importa.
    • Me da curiosidad cómo sería la predicción de red en un framework de juegos. ¿Sería algo como indicar qué propiedades de un objeto hay que interpolar y que el motor se encargue del resto?

  • ¿Habrá casos de uso para usar Godot en desarrollo de apps multiplataforma en lugar de algo como Electron?

  • Uno de los principales contribuidores/desarrolladores de Godot también publicó una pequeña herramienta práctica que permite descompilar por completo lo hecho con Godot.
    https://github.com/bruvzg/gdsdecomp

    • Es una herramienta genial, pero el desarrollador principal/líder/original de Godot es reduz, es decir, Juan Linietsky.

  • Godot es realmente excelente. Me impresionan mucho el progreso del equipo y la dirección general del proyecto.
    Siempre me interesó el desarrollo de juegos, y una parte importante de por qué estudié ciencias de la computación y me convertí en ingeniero de software fue porque quería hacer juegos. Quería crear pequeños juegos por mi cuenta, pero en la práctica no lo logré muy bien.
    Después de convertirme en ingeniero de software de tiempo completo, no encontré ni el tiempo ni las herramientas adecuadas para hacer pequeños juegos como hobby.
    Hace poco descubrí Bevy y lo probé; ECS es un buen concepto, pero Bevy se siente más como una biblioteca, y es bastante difícil crear un juego completo con él, como cuando usas algo tipo SDL.
    Cuando descubrí Godot y lo probé, quedé realmente impresionado. Es amigable para principiantes, pero lo bastante rápido, y la comunidad también es excelente. Es exactamente lo que estaba buscando, así que me alegra mucho que exista y tengo expectativas por cómo seguirá evolucionando.
    Algo que me da un poco de pena es la elección del lenguaje nativo y “oficial”. GDScript está bien; es un lenguaje estilo Python bastante bueno para principiantes y prototipado rápido, y C# también puede ser bueno para quienes vienen de Unity.
    Personalmente, creo que habría sido más feliz con mejor soporte para C++, o alguna otra cosa. Sé que existe la interfaz GDNative y que se mejoró en 4.0.
    C# es un buen lenguaje, pero siento que su gran presencia en el desarrollo de juegos se debe a Unity. Es demasiado verboso, y fuera del Visual Studio completo el soporte de herramientas tampoco es tan bueno.
    Dicho eso, quizá la parte de “programación real” no sea tan importante en el desarrollo de juegos, y tal vez simplemente debería aceptarlo y usar GDScript.

  • Puede que a Godot le cueste enfrentarse a Unreal, pero definitivamente apoyo que vaya por el lado de reemplazar a Unity.
    Es un gran motor, y cada vez más desarrolladores están reconociendo bien su potencial.

    • Unity es su propio ecosistema de una manera distinta a Unreal. Como plataforma, Unity soporta la monetización móvil de una forma que otras plataformas no, y a Godot le costará quitarle ese ecosistema de inmediato.
      Pero si hablamos de desarrollo indie, estoy totalmente de acuerdo. Godot es el framework que la gente quería que fuera Unity: ligero, sin estorbar y que te deja empezar a crear de inmediato. Para ese uso, Godot es mucho mejor.
    • Intentar competir con Unreal, un motor centrado en juegos AAA con décadas de historia y un gran equipo de tiempo completo, es temerario. A un proyecto open source le cuesta alcanzar un objetivo en movimiento así.
      Por suerte, Unreal Engine no es una buena opción para muchos tipos de juegos, y Godot está construyendo muy bien su propio espacio en juegos 2D y juegos 3D simples.
      El mercado de juegos 2D sigue siendo grande y, sorprendentemente, no hay muchos motores que den buen soporte a 2D. Godot entra fácilmente entre los mejores.
    • Si puede replicar el marketplace, parece que también podría competir con Unity.

  • Godot es realmente genial, y respeto muchísimo a todas las personas que dedican su tiempo a hacer excelentes este tipo de software y herramientas como Blender.

  • Godot realmente mejora con cada lanzamiento. Hay algunas funciones que me gustaría ver incorporadas a Godot en el futuro:
    FSR2, buen soporte para Wayland e integración con LLM. Los LLM quizá podrían hacer que los NPC se sientan más realistas.

    • No estoy seguro sobre la integración con LLM. Me parece más una función específica de cada juego que algo relacionado con el motor de juegos. Creo que la integración con LLM podría manejarse mediante scripting dentro del juego.
      En cuanto a integración de inteligencia artificial, me resulta más interesante el diseño asistido por IA: describes un terreno, un personaje o un escenario, la IA genera algo, y luego el usuario lo personaliza y ajusta.
      Pero incluso eso probablemente sea mejor hacerlo fuera del núcleo del motor de juegos.
    • ¿Y ray tracing acelerado por hardware?

  • ¿Hay algún tutorial de Godot recomendable?
    Tengo un pequeño prototipo de RPG que funciona en consola, y me gustaría agregarle una GUI real o gráficos con sprites.

    • Hay un tutorial gratuito para Godot 4, y permite crear un juego completo desde cero en unas dos horas: https://quiver.dev/tutorials/create-your-first-godot-4-game/
      Como aviso, soy el fundador de la empresa que creó este curso. Aun así, el tutorial es gratis, y los assets personalizados usados en el tutorial también se ofrecen con una licencia permisiva.
    • GD Quest se considera hoy algo así como el estándar. Ocupa un lugar parecido al de W3Schools para Godot.
      Dicho eso, viniendo de Unity a Godot, creo que el ecosistema de tutoriales de Godot todavía está bastante atrasado.
    • Tomé uno de los cursos de Heartbeast y lo puedo recomendar.
      Hace poco también sacó un curso específico para Godot 4.
      https://www.youtube.com/watch?v=M8-JVjtJlIQ
    • Tengo una lista de tutoriales de programación en YouTube, y también incluye algunos tutoriales de Godot.
      https://www.youtube.com/playlist?list=PLwYfcDZR0fFcROLjkiyBW...
      Muchos de los tutoriales que encuentres probablemente sean para Godot 3, así que conviene buscar filtrando explícitamente por Godot 4.
      Si no, tendrás que adaptar tú mismo el código del tutorial para que funcione con tu versión de Godot, y eso también puede ser una experiencia educativa en sí misma.
    • La documentación oficial[0] es sin duda el camino clásico.
      [0] https://docs.godotengine.org/en/stable/getting_started/intro...