Use advanced navigation for a better experience.
You can quickly scroll through posts by pressing the above keyboard keys. Now press the button in right corner to close this window.

Unreal Engine 4: Blueprints vs C++

Aló Aló vecinillos. Quiero escribir un poco sobre este temilla de cuándo usar C++ y/o cuándo Blueprints en Unreal Engine 4.

Hace más de 2 años que vengo usando Unreal Engine 4 para básicamente todo y me gustaría dar mi punto de vista en ese “debate”. Todo lo que comparto en este post viene de mi experiencia, pero también de la experiencia de aquellos con quienes hablo con cierta regularidad que utilizan este motor y lo vienen usando hace muchísimo más tiempo que yo, ya que son gente de la industria AAA y laburaron con versiones anteriores durante mucho tiempo.

 

Mito: Es uno o el otro, los Blueprints son para petes

Veo muchos discutir que blueprints es mejor que C++ o visceversa, e incluso a muchos developers no querer usar Blueprints porque “es de petes” (????

La verdad es que si hay algo que tiene de bueno UE4, es que todo está pensado como un sistema y armado gracias a la experiencia y feedback de developers que están en esto hace años. Así que los blueprints no son una excepción, no fueron hechos para atraer petes, sino para potenciar aún más las bondades del engine en general.

Si sos desarrollador, vas a usar los dos. Es cierto, podés no usar C++ y hacer mucho en Blueprint ( o casi todo); es cierto, podés intentar hacer todo en C++ y no tocar Blueprints porque no querés sentirte un pete (???…. pero ninguno de ambos enfoques termina siendo el ideal.

Blueprints es mucho más que unos nodos de programación visual. Ni mucho menos, ya que es, sin temor a equivocarme, el mejor lenguaje de programación visual que he probado.

Pero más allá de esa parte, los Blueprints también son para UMG (interfaces 2D), para la lógica en las animaciones (en Persona), para crear elementos reutilizables facilmente o herramientas que puedan ser usadas por artistas, level designers, game designer y los mismos programadores en dos patadas.

 

Blueprints para aprender la API de C++?

Yep. A mí de hecho me pasó así y luego pude constatar que no soy el único. Una de las complicaciones cuando arrancás con UE4 a programar, incluso si ya sabés C++, no es el lenguaje en sí, sino la API de UE4 y su forma de hacer las cosas (todo el tema de los macros que se usan y demás).

Todo Blueprints está basado en C++, así que aprendiendo bien lo que podés hacer en Blueprints, vas y lo hacés en C++ de manera muy similar.  Podés aprenderte muchísimo de la API básica sin complicarte con cuestiones del lenguaje y compilador.

 

Cuando C++, Cuando Blueprints

En el fondo, depende de cada uno. He visto muy buenos proyectos hechos de una y otra forma. Lo que importa es que la herramienta cumpla de forma eficiente para hacer un juego; de eso se trata todo esto. Y cada uno maneja las herramientas de forma propia y a su comodidad.

Mi caso, y el que pude ver en otros desarrolladores de experiencia, es que utilizo C++ para toda la lógica del juego, clases, entidades, estructuras de dato, etc, mientras uso Blueprints para instancias específicas de esas clases en el editor, herramientas para Level Design, Animation Blueprints, etc. La linea que divide dónde ponés algo (por ejemplo una variable, o función), si en Blueprint o C++, es muy delgada, aunque depende de cómo venís preparando el código y la arquitectura general.

Como programador, encuentro mucho más ágil dejar todo lo que requiera lógica o arquitectura del lado C++. Me llevó un tiempo llegar a esto pues me peleaba mucho con el C++ del Engine y encontraba más rápido solucionar todo en Blueprints. Pero con el tiempo, descubrí que el mantenimiento de Blueprints es más complicado que el de código.

Los Blueprints pueden hacer de todo, pero cuando los usás para lógicas complejas y completas se vuelven inmensamente engorrosos. Personalmente prefiero mil veces y veo más eficiente tipear código que hacer muchos clicks y arrastrar flechas. Es más rápido para trabajar, más visual y práctico.

Con esto no estoy defenetrando a los Blueprints, todo lo contrario. Así como encontré más ágil C++ en lo mencionado, encuentro infinitamente más ágil Blueprints a la hora de realizar instancias de objetos en el editor, asignarle valores, asignar referencias a assets del Content Browser, armar lógica muy simple de gameplay en elementos específicos de los mapas, manejar todo lo que es UMG y Animation Blueprints, hacer contenedores de objetos, etc.

Un claro ejemplo de un Blueprint que, a mi gusto, se hace gigante y engorroso, incluso si está bien hecho y prolijo, y que llevado a código sería mucho más compacto y fácil de mantener:

 

 

Ejemplos?

Un ejemplo muy bueno de la forma en que me gusta laburar está para descargar entre los proyectos de Learning de Unreal Engine 4, y es el de UnrealMatch3.

Pueden bajarlo gratis de la pestaña Learn del Launcher de UE, e incluso escribieron un PostMortem de como fue hecho.

En resumen, este proyecto pone del lado C++ la definición de clases y sus comportamientos más importantes, como la lógica del juego, la conexión o el guardado de datos.

Mientras utiliza Blueprints para Instancias específicas de estos elementos, ponerlos en el mapa, definir qué assets usa cada instancia (qué sonido, qué texturas, que skin, etc).

Por ejemplo, en la siguiente imagen se puede ver distintas instancias de la clase ATile que está definida en Tile.h, y puede verse como se usa para definir el sprite, materiales, efectos de partículas, etc, que pertenecen a cada instancia.

De esta forma, es muy fácil crear, modificar, tunear, definir, etc los elementos del juego sin andar recurriendo a código, siempre desde el editor.

 


Pero.. y la performance

Sí, Blueprints es más lento que C++.. pero no jodan…. los casos donde el impacto sea realmente notorio son bastante concretos, no es que vas a hacer un engine en Blueprints.


Las curvas de aprendizaje

No hay duda que la curva de aprendizaje de C++ en UE4 es muchísimo más elevada que la de los Blueprints, incluso si ya venís sabiendo C++. El tema de los macros y entender la forma de hacer las cosas “a la Unreal”, te va a hacer putear muchísimo con C++ y tener muchos, muchos crashes hasta que le tomás la mano. He visto muchos desarrolladores decir “este motor está mal hecho” porque crashea mucho y es difícil de adaptarse a la parte del código.

La verdad es que, salvo algunas excepciones de bugs que fueron arreglados pronto, todos los crashes que sufrí (muchos) fueron culpa mía por mi desconocimiento del engine. Sí, la curva de C++ es definitivamente más elevada.

Lo que puedo decir a favor es que el esfuerzo en entender el motor sale bien recompenzado. Cuando le tomás la mano a la API, cuando ya conocés más o menos las clases base y cómo están hechas, la filosofía del engine, todo lo básico de como se usan los macros, etc, lo vale mucho.

Quiero Aprender más

La documentación de UE4 es buenísima. No me falló nunca. Y la comunidad tampoco. En el Answer Hub está casi todo preguntado/respondido. Sí noto cierta resistencia a las preguntas y gente que claramente tienen poca experiencia, pero en esos casos, es muy probable que haya ya respuestas y posts sobre el tema preguntado.

Lo mejor que se puede hacer para aprender más, es hacer ingeniería inversa de los proyectos que están públicos. En la pestaña Learn del launcher hay varios y muy buenos para entender más!

 

 

 

 

Leave a reply

 

small_keyboard