Mis primeros pasos con GDScript y Godot

Esto no tiene nada que ver con el trabajo — es la parte del “por disfrute personal” que menciono en mi perfil. Llevaba tiempo con ganas de tocar desarrollo de videojuegos, más por curiosidad que por ningún plan de sacar nada al mercado, y tenía que decidir por dónde empezar.

Por qué Godot y no Unity

Miré Unity primero, como todo el mundo. Pero en cuanto abrí el editor sentí lo mismo que la primera vez que abrí Angular para un proyecto pequeño: demasiadas piezas para lo que quería hacer, que era básicamente mover un cuadrado por la pantalla y que chocara con otro cuadrado. Godot es mucho más ligero de entrada, el editor pesa un puñado de megas y arranca en segundos, y eso para un hobby de ratos sueltos por la noche importa más de lo que pensaba.

GDScript se sintió como llegar a casa

Esperaba tener que aprender un lenguaje nuevo de cero. En cambio, GDScript tiene una sintaxis tan cercana a Python que, viniendo de años con JavaScript y PHP, en un fin de semana ya estaba escribiendo scripts sin tener que consultar la documentación cada dos líneas. La indentación como estructura de bloques (en vez de llaves) me costó un par de días acostumbrarme, sobre todo porque vengo de lenguajes donde los espacios no importan para nada.

El primer bug tonto

Mi primer prototipo fue literalmente un personaje que se movía con las flechas por una habitación en 2D. El primer bug de verdad fue una tontería: el personaje se aceleraba sin límite cada vez que mantenías pulsada una tecla, porque estaba sumando velocidad en cada fotograma sin comprobar un máximo. Cualquiera que lleve tiempo con videojuegos se habría reído, pero a mí me hizo entender de golpe por qué el bucle de físicas (_physics_process) es una bestia completamente distinta al bucle de eventos al que estoy acostumbrado en la web.

No tengo ningún plan concreto con esto, más allá de seguir aprendiendo. Pero si algún día combino esto con lo que estoy aprendiendo de Rust y me animo con Unreal en C++, ya contaré qué tal.