Unreal Engine 4. Programando con Blueprints.

Cuando hicimos la migración de Unity 5 a Unreal Engine 4, una de las novedades más importantes de este cambio era la posibilidad de programar el juego con Blueprints.

¿Qué son los Blueprints? básicamente una manera de programar con nodos y enlaces sin picar una linea de código. Esto tiene cosas buenas y cosas malas, aunque si seguimos programando el juego con Blueprints es que de momento nos están gustando :-).

Ejemplo de Blueprint para el movimiento del coche.

En teoría se puede programar todo un juego con Blueprints, y esa es nuestra idea para el juego The Deliver, ya que creemos que no es lo suficientemente complejo como para que no sea así. Otro ejemplo de juego que está en parte, o totalmente (no estamos seguros), programado con Blueprints es el conocido PlayerUnknown's Battlegrounds, donde en un vídeo de desarrollo mostraron como estaban programando la personalización de la ropa de los jugadores y se pudo ver una parte de programación con este sistema.

Seguramente el sistema de programación con Blueprints podría dar para muchas entradas de blog, pero el objetivo de esta entrada es para dar a conocer este método de programación introducido en la versión 4 de Unreal Engine y que muchos quizá no conocen si vienen de Unity 5 u otros motores de juego. Aunque sabemos que para Unity existe un asset para programación visual siempre decimos que si ya viene integrado con el motor, mucho mejor.

Primero vamos a comentar las cosas que nos gustan de este método para programar:

• Es muy visual. Una de las principales ventajas por la que se fomenta la programación con Blueprints es porque es muy gráfico y por lo tanto, más fácil de entender y aprender. Y es más ventaja aún cuando tienes que explicar ese trozo de código a otra persona que no está familiarizada con la programación tradicional en texto.
• Es divertido. Un lenguaje para sentirte motivado para programarlo tiene que ser divertido. Si no es divertido no te lo tomas con tantas ganas. Y la programación visual con Blueprints, de momento, nos parece divertida. A parte, la interfaz de los nodos y los enlaces está muy cuidada, por lo que se hace agradable a la vista trabajar con ellos.
• Evita problemas básicos de compilación. ¿No os ha pasado nunca que una parte del código te daba un error de compilación y no encontrabas el problema y resulta que al final era por no poner un punto y coma al final de linea? pues a nosotros muchas veces, hasta ahora :). Con la programación con Blueprints, como todo va por nodos y enlaces no hay sintaxis, por decirlo de alguna manera, y es todo más estricto con los tipos de datos, y si la entrada de un nodo tiene que ser de un tipo en concreto no te dejará conectar el enlace a menos que sea de ese tipo. O en todo caso te hará automáticamente la conversión para que los tipos coincidan. Por ejemplo, intentar conectar una salida integer con una entrada string, automáticamente te hace el cast a string.

En este caso nos indica que los tipos no son compatibles y debemos hacer un cast.

• Trabajando dentro del contexto. Trabajando de este modo el propio editor te limita al contexto en el que estás trabajando, es decir, cuando en la salida de un nodo quieres crear un nuevo nodo enlazado al primero, el editor solo te muestra las opciones disponibles de enlace, por lo que hay poco margen de error a ligar algo que no toca. Y si en las opciones de enlace no sale la opción que estás buscando, es que el nodo o enlace orígen no está correctamente creado.

Popup que se muestra al querer enlazar la salida del nodo.

• Variables, funciones, bucles, etc. La programación con Blueprints es como cualquier otro lenguaje de programación, ya que durante la compilación el editor transforma los Blueprints a código C++ nativo, por lo que soporta la creación de variables, funciones, bucles, condicionales, etc.
• Proyectos con Blueprints y código C++. Una de las cosas buenas de crear un proyecto en Unreal Engine es que no tienes que escoger un sistema u otro de programación. Sino que puedes tener parte de tu proyecto hecho en Blueprints y otras partes programadas con C++ y todo debería funcionar correctamente, ya que no se obliga a hacerlo de una manera u otra.
• Cambio de versiones menos traumático. Una de las cosas que vimos en los inicios de la migración a Unreal Engine, es que con proyectos hechos solo con C++, el cambio de versiones del editor (por ejemplo de la 4.15 a la 4.16) era más delicado que si tenías todo el proyecto hecho con Blueprints, dónde la conversión entre versiones es directa y no tienes que hacer nada especial. En cambio con código propio de C++ algunas conversiones nos daba algún error de compilación que debía ser tratado para soportar la nueva versión.
• Documentación en Blueprints. A destacar también que la gente se ha acostumbrado a utilizar los Blueprints, así que mucha documentación que encuentras en Internet y muchas dudas de usuarios son con ejemplos gráficos de Blueprints, por lo que no suele ser complicado encontrar un caso parecido al tuyo cuando te da algún error o quieres hacer algo en concreto.

Y ahora vamos con las cosas no tan buenas o mejorables a nuestro criterio:

• No es tan eficaz como programar con C++. Si quieres realizar funciones de cálculos complejos o que requieran un alto nivel de rendimiento, seguramente los Blueprints no son la mejor opción y tengas que hacerlo con C++ directamente.
• Programación horizontal. Acostumbrados a la programación tradicional dónde las líneas de código van una debajo de la otra y la lectura se hace en vertical para una mejor comodidad, nos hemos encontrado que la programación en Blueprints invita a hacerlo en horizontal por propia naturaleza de los nodos, dónde tienen las entradas a la izquierda y las salidas a la derecha. Por lo que al final, para una mejor organización visual, terminas programando en horizontal y a veces no termina de ser del todo cómodo.

La conexión de nodos y enlaces invita a programar en horizontal.

• Organización del código. Aunque el propio editor tiene herramientas para organizar el código como añadir comentarios para encapsular un grupo de nodos, es verdad que cuando empiezas a tener bastantes nodos y enlaces en pantalla, a veces puede llegar a ser un poco caos sino te organizas bien y eso, a veces, no es fácil hacerlo. En la siguiente imagen, por ejemplo, se puede ver nuestra organización actual del código para las funcionalidades principales del juego. Visualmente queda bien. Los problemas vienen cuando tienes que añadir cosas entre medio y tienes que empezar a desplazar partes de código para hacer hueco.

Organización del código en el nivel persistente.

• Desplazamiento automático del código. En la programación tradicional, cuando quieres añadir una línea de código en medio de una función o dentro de un bucle, simplemente te pones al inicio de la línea donde quieres añadir el código, presionas Enter y todo el código se desplaza hacia abajo para poder añadir la línea dónde querías. Con Blueprints la cosa no es tan directa, ya que no hay desplazamiento automático de los nodos si quieres añadir uno en medio de otros, por lo que primero tienes que seleccionar todos los nodos que se desplazarían, moverlos manualmente, y luego añadir el nuevo nodo.

Finalmente vamos a mostraros un pequeño vídeo para ver un poco como es la dinámica de programación con Blueprints. Aunque si queréis ver más, os aconsejamos que hagáis una búsqueda en Youtube dónde está lleno de vídeos de este estilo y os podréis hacer una mejor idea.

En el vídeo simplemente se replica el código de la función Load Mission que hay justo arriba, pero os puede ser útil para ver como se crean nodos, como se enlazan, como se organiza una vez creado, etc.

Esperamos que os haya sido útil y nos vemos el próximo lunes :-).

Unreal Engine 4. Impresiones posteriores.

Ahora que ya llevamos unas semanas con el nuevo (para nosotros) Unreal Engine, aprovecharemos para hacer otra entrada explicando nuestra experiencia con nuevos argumentos, más allá de las primeras impresiones que publicamos hace unos meses.

Cabe decir que durante este tiempo, Unity ha sacado la versión 4.6 de su motor e imaginamos que seguramente tenga mejoras interesantes. Como a nosotros no nos sobra tiempo, no podremos comparar ya que a partir de ahora nos queremos centrar en el Unreal Engine.

Así que es posible que alguna cosa que se comente aquí ya la tenga Unity en alguna última versión, o bien que las tenga a partir de complementos externos, pero como siempre decimos, si ya vienen por defecto con el motor, mucho mejor.

Primero vamos a nombrar algunas de las cosas buenas que hemos ido encontrando en este motor. Y como no todo es perfecto, luego pasaremos a comentar las cosas no tan buenas :-).

• Auto generación del LOD. A groso modo, el LOD (Level of Detail) serian los distintos niveles de geometría que un objeto puede tener dependiendo de la distancia desde la cuál se mire este objeto. A ciertas distancias, la cantidad de polígonos que tiene un objeto se reduce, porque a simple vista no hay diferencia visual entre un objeto cercano con N polígonos y un objeto lejano con la mitad o una tercera parte de los polígonos. Esto ayuda a optimizar el juego y que vaya más fluido. Para crear estos niveles de LOD normalmente el propio diseñador 3D del objeto, cuando lo crea, también tiene que crear réplicas con menos nivel de polígonos, lo que aumenta muchísimo el tiempo dedicado en la creación de cada objeto. En el Unreal Engine nos hemos encontrado la grata sorpresa de que tiene un auto-generador de LOD a partir de un objeto que tengas creado. A partir de unos parámetros como la cantidad de niveles de LOD a generar, la reducción de polígonos por nivel o la distancia de visión entre otros, automáticamente crea las réplicas de los objetos. En nuestro caso, los resultados de las réplicas generadas son muy satisfactorios y es muy útil para generar los niveles de LOD de todos los objetos. El único problema es que tienes que ir objeto por objeto para crear el nivel de LOD, pero bueno, tampoco se le puede pedir tanto :-).

• Miniaturas de los modelos. Esto quizá para algunos puede ser una parida o algo sin importancia, pero ayuda mucho que al importar un objeto te genere automáticamente la miniatura y visualmente puedas ver la lista de objetos en imágenes. En el momento de buscar un objeto para añadirlo al escenario es mucho más fácil buscarlo si visualmente puedes ver el objeto. Esto por ejemplo Unity no lo tenía y una vez probado, seguro que se hecha en falta.

Miniaturas de los objetos importados.

• Creación automática del modelo convexo de colisión. Cuándo a un objeto complejo en cuánto a geometría se le tiene que aplicar simulación de físicas, estas físicas no se aplican sobre la geometría completa del objeto ya que supondría una gran cantidad de recursos para procesar cada petición. Cuando utilizamos Unity, este tenía la opción de convertir la geometría de la colisión a una forma convexa (básicamente es una versión simplificada de la geometría de colisión) para que así al procesar las físicas de este objeto sea más fácil. Esto es bueno, pero a la vez limita un poco la geometría de colisión de este objeto, como por ejemplo, que haya una parte de colisión donde realmente no hay polígonos del objeto. En Unreal Engine, también existe esta herramienta para generar la versión convexa de la geometría de colisión del objeto, pero en este caso va un poco más allá, y permite definir a través de un parámetro la fidelidad de esta geometría convexa. Lo que permite crear una geometría más o menos fiel a la original del objeto si así se desea (a coste de empeorar el rendimiento, claro). En el siguiente ejemplo se puede ver lo que comentamos. A la izquierda se genera el modelo de colisión con el valor 0.1 (poca fidelidad) y a la derecha con el valor por defecto (0.5), lo que permite un modelo de colisión más detallado.

Diferencia de la geometría de colisión al crear el modelo convexo.

• Blueprints. En el artículo anterior ya comentamos un poco por encima las características de los Blueprints. Ahora que los hemos podido probar mejor, podemos reafirmar que son una buena herramienta para la programación de muchas partes del juego que no requieren complejidad. En nuestro caso, por ejemplo, hemos podido programar la funcionalidad del vehículo y otras pequeñas funcionalidades sólo con Blueprints. Aunque cabe decir que Unreal Engine trae una clase específica para crear vehículos, la cuál ayuda mucho. Por el nivel de complejidad del juego, creemos que todo se podrá hacer mediante Blueprints, ya que no necesitamos nada especialmente complejo como para tener que utilizar directamente el C++. Los Blueprints son divertidos de programar y muy visuales, a la vez que permiten igualmente depurar de manera fácil mediante los breakpoints de toda la vida.

• Launcher de Unreal Engine. Este punto sí es una mejora muy grande que hemos encontrado respecto Unity, ya que éste último no tiene un gestor de versiones del motor, lo que dificulta poder gestionar las nuevas versiones que van saliendo y la compatibilidad de los proyectos con estas versiones. En cambio Unreal Engine, el propio launcher tiene una sección para gestionar todas las versiones que tienes instaladas en tu ordenador, sus actualizaciones y todos los proyectos que haces con el motor.

Ejemplo de nuestro launcher con dos versiones de Unreal Engine instaladas.

• El propio Editor. Esto quizá es un poco más difícil de explicar sin probarlo por uno mismo, pero comparándolo con el motor de Unity, el editor de Unreal Engine está creado con más cuidado y más mimo en las pequeñas cosas. Tiene muchos pequeños detalles que individualmente no són algo como para destacar, pero que en conjunto hacen que te sientas más cómodo trabajando. Por ejemplo, la posibilidad de crear distintos niveles de quadrícula para forzar la colocación de los objetos en el escenario, un modo visual de reemplazo de objetos a partir de un filtro de selección, la posibilidad de importar un modelo de colisión desde otro objeto, el icono que se activa cuando editas cualquier valor para poder volver al valor que tenia por defecto, etc. Muchas pequeñas cosas que en conjunto hacen algo mejor.

Y ahora algunas cosas no tan buenas que hemos encontrado. Algunas parecen bugs y otras son más del comportamiento del propio Editor.

• Bug de la señal de ceda el paso. Pues sí, tenemos un bug algo curioso. Cuándo copiamos una parcela de edificios con su atrezzo las señales de ceda el paso de los objetos copiados las sustituye por el objeto de un semáforo que también tenemos en nuestro atrezzo. No sabemos si internamente hay alguna referencia que se nos escapó cuando hacíamos pruebas o es que al editor se le va la pinza y le tiene manía a las señales de ceda el paso... ¡si tan malas no son! [Actualización: este bug ha sido solucionado en la versión 4.16.2 del Unreal Engine].

• La auto expansión de las carpetas del World outliner. Este quizá es el comportamiento del editor que nos trae más de quicio. El World outliner es el panel dónde se muestran todos los objetos que tienes en tu escena. Allí los puedes agrupar por carpetas para tenerlo bien organizado. Hasta aquí bien. El problema es que cuando seleccionas un objeto en tu escenario, este también se selecciona en dicho panel y se expanden todas las carpetas que contiene ese objeto, lo cual a veces molesta bastante porque, aunque selecciones el objeto, no quieres que se expanda todo en el panel. Incluso cuando abres el mapa por defecto se expande todo y no recuerda el estado en que estaban la última vez que cerraste el editor, con lo que tienes que colapsar de nuevo todas las carpetas para tenerlo organizado, y si tienes muchos objetos y carpetas como podemos tener nosotros, molesta bastante. Señores de Unreal, primer aviso, ¡solucionad esto ya! si no nos volvemos a Unity!... que no, que es broma... [Actualización: en la versión 4.16.2 del Unreal Engine parece que ha sido solucionado parcialmente, algunas carpetas no se auto expanden y otras sí].

• Alguna inestabilidad del Editor. En general el editor es muy estable (eso si, sus recursos consume) pero cabe decir que algun crasheo nos ha hecho, aunque los podemos contar con los dedos de una mano. Normalmente són debido a falta de memoria (teniendo 16 GB de RAM) cuando se editan muchos objetos, como por ejemplo cuando se tuvieron que crear todos los niveles de LOD de todos los objetos. Llega un punto que es mejor cerrar el editor y volverlo a abrir para que haga limpieza de memoria.

Y hasta aquí la segunda parte de la migración a Unreal Engine. Si alguien se quedó con dudas en la anterior entrada dónde explicamos la migración a este motor, esperamos que con esta nueva entrada detallando algo más las cosas buenas y malas le sean útiles para tomar una decisión. Aunque lo mejor, como siempre, es probar las dos opciones por uno mismo y quedarse con la que más le guste :-).

ACTUALITZACIÓN: Posteriormente hemos realizado una nueva entrada hablando solo de la programación con blueprints, os aconsejamos la lectura si os interesa el tema :-)

Unity 5 vs Unreal Engine 4. Migramos a Unreal.

Ya está. Sin rodeos. Como cuando te quitas una tirita. No hay dolor!

Y no, no nos hemos vuelto locos... aunque cualquiera lo podría pensar teniendo en cuenta que no disponemos de mucho tiempo para desarrollar el juego, menos aún si nos ponemos a probar cosas por en medio :D.

Pero nos picó la curiosidad, y a diferencia de con Torii, el único motor que nos hacía tilín y era gratuito fue Unity. Así que cuando salió Unreal Engine para todos los públicos, aunque lo probamos por encima, ya habíamos empezado con el otro y decidimos seguir con él por ser simplemente con el que empezamos y aprendimos.

Como prácticamente no hemos tocado Unity todavía para el nuevo proyecto, ya que casi todo ha sido modelado 3D y diseño, nos hemos decidido a darle una oportunidad a Unreal para ver si realmente valía la pena cambiar de motor o, por el contrario, quedarse con el actual.

Finalmente, y después de muchas pruebas y muchos problemas que nos hemos encontrado (por nuestra poca experiencia con el motor), los hemos podido solucionar y creemos que las ventajas que nos ofrece frente a los inconvenientes son suficientemente interesantes como para dar el paso.

La versión que utilizaremos será la 4.15, la última disponible a día de hoy y la que ofrece más posibilidades.

Llevamos pocos días con este motor, pero a continuación vamos a listar las cosas buenas y malas que hemos encontrado durante estas pruebas. Todo esto siempre bajo nuestro criterio y teniendo en cuenta que el único otro motor que hemos probado ha sido Unity y solo para una pequeña demo jugable de un simple escenario, pero trasteamos lo suficiente con él para poder valorar posibilidades.

Para empezar, las cosas buenas:

• Es gratis. Si no fuera gratis, ni nos hubiéramos planteado probarlo, porque como sabréis, nuestra dedicación es mínima (ratos libres) y tampoco nos podemos permitir comprar la licencia de un motor así. Cabe decir que es un poco trampa la palabra "gratis". Porque una vez haces un juego y obtienes beneficios, a partir de los $3000 ganados, los señores de Unreal se llevan una comisión del 5%. Que oye!, tampoco está tan mal :D.

• Es un motor robusto. Durante estos días de pruebas, no ha crasheado ni una vez. Algo que en parte debería ser normal, pero en cambio con Unity nos pasó varias veces y es molesto (algunas veces salia la típica ventanita de critical error sin saber porqué, o cuando entrabas te decía que el layout no se había podido cargar y te ponía el que viene por defecto).
• Sistema de iluminación. Aunque en las últimas versiones Unity ha mejorado el sistema de iluminación y ha introducido la iluminación global (GI o Global Illumination), no nos terminaba de convencer como nos estaba quedando. Y lo peor, esa sensación de no saber qué hacer para mejorar el resultado. En cambio Unreal por defecto lleva una iluminación más realista y más acorde a lo que estamos buscando. Seguramente con Unity al final se puede dejar algo parecido, pero es un trabajo añadido si lo comparamos con Unreal donde te lo da prácticamente hecho.

Escena renderizada con Unreal Engine 4.

• Los Blueprints. Con la versión 4 de Unreal también sacaron la novedad de la programación con blueprints, la cuál es otra manera de programar prácticamente cualquier funcionalidad que pueda tener tu juego pero sin picar código. Todo se hace de manera visual con nodos y conexiones entre ellos. Está claro que para realizar algoritmos complejos o funcionalidades dónde se requiera mucha optimización hacerlo en C++ siempre será mejor. Pero para funcionalidades básicas, los blueprints són muy útiles.

Programación básica de un coche con blueprints.

• El Editor. Hasta donde hemos probado, el editor de Unreal parece más completo que el de Unity. Tiene muchas pequeñas utilidades que muchas veces echas en falta y no sabes porque no vienen por defecto con el motor. Por ejemplo, poder colocar objetos en el escenario y que automáticamente se alineen a un grid predefinido es algo muy útil cuando, por ejemplo en nuestro caso, tienes que crear unas carreteras en formato de cuadrícula. Y así con otros muchos pequeños detalles donde se nota que Unreal está algo más trabajado que Unity. Decimos lo mismo que antes, seguro que con Unity al final puedes hacer lo mismo, ya sea programando un script o consiguiéndolo por Internet, pero cuantos más añadidos útiles tenga un motor por defecto, mejor.

Editor de Unreal Engine 4.

• Los Wheeled Vehicles. Sí, aunque parezca mentira, y luego ya veréis porqué, el sistema de vehículos de Unreal está mucho mejor hecho que en Unity, dónde en éste último, prácticamente lo tienes que programar todo para hacer un vehículo con unas físicas decentes (viene con unos wheel colliders, pero són algo justos para nuestro gusto). En cambio Unreal viene con un componente específico para crear vehículos, el cuál viene con muchos parámetros por defecto, como por ejemplo, la tracción de las ruedas (delante, detrás o en las cuatro), marchas manuales o automáticas, configuración de ruedas y fricción dependiendo de la superficie por dónde rueda, torque del motor, freno de mano, suspensiones, diferencial, etc.

Creación de los colliders para un coche.

Pero eh!, no todo es bueno. Ahora, las cosas más reguleras:

• El lenguaje de programación C++. Esto es algo personal, pero una vez probada la programación en C# de Unity, lo preferimos antes que el C++. Aunque este último es algo más rápido para algoritmos que necesiten mucho procesamiento, pero menos amigable.
• El rendimiento del Editor. En este caso, el editor de Unreal pide mas recursos gráficos que el de Unity. Tanto en el ordenador de sobremesa como en el portátil, hemos notado que los ventiladores soplan más con el Unreal que con Unity, por lo que es algo a tener en cuenta, pero tampoco nada preocupante. Además del espacio ocupado en disco, que aunque no sea algo muy importante en los ordenadores de hoy en día con lo poco que cuesta el almacenamiento, estamos hablando de 3 veces más de espacio; 15GB por los 5GB que pide Unity.
• Hacer funcionalidades fuera de lo común. Aunque no es algo que hayamos experimentado nosotros mismos, o al menos hasta el momento, hemos leído algunas opiniones en foros dónde comentan que Unreal está muy bien si quieres hacer funcionalidades típicas que te puedas encontrar en un juego, pero si te quieres salir de aquí el desarrollo de estas funcionalidades en C++ es muy tedioso.
• Desarrollo en 2D y móviles. En este caso, y por lo leído en varios artículos, Unity es mejor motor para realizar juegos en 2D y juegos móviles que requieran poca carga gráfica. En cambio Unreal es ideal para juegos que tengan que lucir muy bien gráficamente.
• Los Wheeled Vehicles. Sí, otra vez los volvemos a nombrar. Igual que antes hemos comentado las cosas buenas que tienen, ahora vamos a comentar las malas. Y es que durante estos días de pruebas nos hemos encontrado muchos (y cuando decimos muchos, son muchos... pero muchos... pero muchos, muchos... basta!) problemas para encontrar el proceso correcto de creación y funcionamiento de un simple vehículo. Al final hemos podido encontrar un proceso correcto para crearlos, pero aún así, no estamos del todo satisfechos, porque hay una parte, concretamente la del rig del coche, que aún no sabemos qué hacer para que funcione correctamente y tenemos que usar un rig que nos facilitaron muy amablemente para poder tirar adelante con este tema. En una próxima entrada entraremos con mucho más detalle sobre este tema y publicaremos un tutorial de como crear un coche modelado en Blender e importado a Unreal en su versión 4.15.

Y hasta aquí los pros y contras que hemos ido encontrando estos días. Seguro que mientras vayan transcurriendo los días iremos encontrando más cosas buenas y más cosas malas, pero de momento esto es lo que hay, que no es poco :-).

Si alguien lee esto (hola?... eco... eco... eco...) y está con Unity y le pica la curiosidad para probar Unreal, le recomendamos primero que no se quede sólo con la opinión de esta entrada, sinó que lea más críticas que pueda encontrar por Internet. Por ejemplo, recomendamos este artículo donde detalla bien los pros y contras de cada motor gráfico.

También recomendamos este artículo de la propia documentación de Unreal dónde explica las similitudes entre Unreal y Unity. Muy útil.

Esperamos que este artículo os haya resultado interesante, y recordad que en próximas entradas detallaremos mucho más el tema de los Wheeled Vehicles y empezaremos a mostrar el progreso del juego en este nuevo (para nosotros) motor.

ACTUALIZACIÓN 1: Unas semanas más tarde hicimos una nueva entrada dedicada a la migración a Unreal Engine, comentando más impresiones. Podéis seguir con la lectura en el siguiente artículo.

ACTUALITZACIÓN 2: Posteriormente hemos realizado también una nueva entrada de blog hablando solo de la programación con Blueprints. Os aconsejamos la lectura si os interesa el tema :-)