El menú y las pantallas de carga.

Estos días hemos estado probando la manera en que Unreal Engine trata cada mapa y su proceso de carga, ya que tiene varios métodos dependiendo de si tu mapa es único o bien se compone de varios submapas (realmente los llama subniveles).

En nuestro caso, como todo el mapa es muy grande, crearemos subniveles para poder gestionar mejor la carga de estos mientras se juegue. Además, que para el trabajo colaborativo de creación del mapa es mucho mejor tenerlo así, ya que mientras uno trabaja en un subnivel, otro puede trabajar en otro subnivel de otra zona.

Eso no quiere decir que habrá pantallas de carga durante la misión, sinó que el mapa se irá cargando en segundo plano mientras se juegue. Esto tenemos que probarlo más para ver si puede dar algun tipo de tirón mientras se juegue, ya que puede ser bastante molesto.

También hemos estado haciendo una primera versión de prueba del menú principal del juego, tal y como se muestra en la siguiente imagen.

Pantalla del menú principal del juego.

La imagen de fondo de pantalla es provisional. Para la versión final ya veremos si dejamos una imagen o bien una zona en 3D del mapa.

El menú y el estilo del menú si es posible que sea una versión bastante definitiva de lo que podría ser la versión final, aunque siempre habrá pequeñas modificaciones hasta terminar el juego.

De momento el menú es poco funcional. La opción de Start game por ahora nos sirve para tener un proceso de transición entre menú, pantalla de carga y el mapa cargado totalmente. Luego la sección de Options está en pañales, ya que solo hay algunas cosas de pruebas (como se verá en el siguiente vídeo). Y finalmente la opción Quit game, que esta sí funciona perfectamente para salir del juego :-).

La idea ahora es terminar el proceso de carga de una posible misión y luego seguir con la jugabilidad del juego. El menú lo dejaremos así de momento, porque ahora mismo no es una prioridad. Más adelante ya añadiremos todas las opciones gráficas, de audio y de controles en la sección Options.

En el siguiente vídeo se puede ver algo más. La pantalla de "Loading..." que será a pantalla completa para que no se vea mientras carga el mapa, pero de momento está así para ver que realmente lo hace correctamente.

Esperamos que os haya gustado y nos vemos en la siguiente entrada :-).

¿Qué hacer con tu juego?

A raíz de la desaparición de Steam Greenlight por la recién llegada Steam Direct, nos hemos animado a hablar de algunas ideas que nos han ido surgiendo desde que empezamos.

Como ya sabréis, Steam ofrece un servicio desde hace varios años donde los desarrolladores pueden subir su proyecto para que jugadores de todo el mundo lo prueben. Ya sea una pequeña demo para conocer la opinión del público, un early access para conseguir financiación ofreciendo un producto más avanzado o incluso el juego final.

Con el nuevo servicio llamado Direct y a diferencia del desaparecido Greenlight, los desarrolladores que quieran publicar su producto tendrán que pagar 100 dólares obligatoriamente.

Es una pena tener que pagar por usar un servicio que hasta hace muy poco era gratuito, pero lo han hecho por una buena causa. A raíz de la ferviente moda de los juegos indies, mucha gente estaba subiendo sus proyectos a la plataforma para que los potenciales jugadores valoraran si jugarían o no a ese juego. Como no costaba nada, en muy poco tiempo, había crecido de forma exponencial la subida de proyectos y, aunque muchos fueran muy interesantes, la gran mayoría eran desarrollos aún muy verdes.

A causa de esto, algunos proyectos que sí tenían posibilidades de poderse publicar se quedaban en la sombra y se perdían por el camino.

Con esta medida Steam pretende asegurarse que quien quiera publicar lo haga convencido de que su proyecto vale la pena y está en un estado óptimo para, como mínimo, el testeo.

De momento, parece buena idea. La cantidad que piden no es una cantidad inalcanzable y seguramente disuada a algunos desarrolladores que quieran subir su demo antes de tiempo, pero no creemos que sea una cantidad suficientemente grande como para solucionar el problema de raíz. Pero como siempre, veremos en un futuro si realmente ha servido de algo.

Dicho esto, os vamos a comentar un par de alternativas que, aunque no puedan resultar tan atractivas como publicarlas en una plataforma mundialmente conocida, pueden ser interesantes dependiendo de la finalidad con la que hayas desarrollado tu producto.

En nuestro caso, con nuestro primer desarrollo, Torii, decidimos publicarlo en nuestra página web para que cualquiera que llegara vía blog, vía porfolios, etc. pudiera verlo. Sabemos que no es el juego del año. ¡Maldita sea! ¡ni siquiera es un juego más allá de un walking simulator! Pero eso no es motivo suficiente como para no mostrárselo al muuuundooo :D.

Si, como a nosotros, no pretendes hacer dinero, si sólo lo hiciste con motivación para aprender algo nuevo o si lo hiciste por diversión, siguen siendo motivos más que suficientes como para que no se quede tu proyecto en un cajón. Así que te animamos a que lo publiques y muestres tu arte al resto del personal.

Si ves que tienes posibilidades de hacer algo suficientemente decente como para mostrárselo a toda una comunidad de jugadores, te animamos que lo intentes en Steam. Eso si, ten en cuenta esos 100 dólares iniciales. Si tu intención es hacer dinerico, puede que lo recuperes. Si no es así, tampoco es una cantidad tan grande como para quitarte el gusto. Y si llega a suficiente gente, podrás recibir feedback, que siempre debería ser bien recibido para mejorar.

Si nada de esto te convece, quizás te interese saber que en la Asset Store de Unity puedes subir el proyecto entero. Puedes ponerlo gratuitamente o sacarte un dinerillo.

Ah! y puedes ponerlo enteramente y te olvidas o puedes dividir los elementos que conformen tu proyecto en elementos vendibles y aumentar las posibilidades de triunfar, aunque no sea fácil, claro. Esto último también puedes hacerlo en la tienda de Unreal.

Hoy en día existen varias posibilidades de sacar rendimiento a tu proyecto. Desde querer mostrar lo que eres capaz de hacer y enriquecer tu porfolio, a ponerlo a disposición de otros desarrolladores o incluso sacar algún beneficio monetario.

Así que desde nuestro humilde blog, queda inaugurada esta campaña para dar a conocer al mundo nuestras terribles habilidades. Repite con nosotros, ¡no más proyectos en un cajón!

Lo que tenemos y lo que viene.

En esta entrada vamos a intentar resumir el estado actual del proyecto. Lo que hemos podido hacer hasta ahora y nuestras intenciones de los próximos movimientos. Y para que no se haga pesado, mostraremos alguna imagen más de la ciudad :-).

Hasta ahora nos hemos centrado mucho en modelar edificios y atrezzo para ir llenando la primera parte de la ciudad. Como veréis en la imagen de debajo, nos quedan aún algunas parcelas, pero ya estamos cerca.

Vista general de la ciudad.

Internamente planteamos las fases de creación de la zonas del mapa (ciudades, pueblos, bosques, lo que sea) en 3 fases:

• Primera fase: crear la estructura base de la zona. En el caso de la ciudad diseñamos el mapa de calles y luego en Unreal Engine pasamos ese diseño de calles a 3D, colocando cada pieza de calle en su lugar. En el caso de un pueblo sería algo parecido, pero seguramente con menos calles. Y en el caso de un bosque, la primera fase sería diseñar un mapa topográfico de como podría ser más o menos la zona y luego en Unreal Engine utilizar la herramienta para crear los desniveles del terreno.
• Segunda fase: una vez ya tenemos la estructura base, esa zona se tiene que llenar "a lo bruto", por decirlo de alguna manera. Eso no quiere decir llenar la zona de cualquier manera, sino encontrar una forma para que se pueda llenar rápidamente sin perder la calidad. En el caso de la ciudad es donde entra el diseño 3D de edificios y atrezzo, y empezar a crear y duplicar parcelas. En nuestro caso, muchas de las parcelas las duplicamos dos veces para poder llenar más fácilmente la ciudad y a la vez intentar no dar la sensación de copia. A cada parcela le damos prácticamente el detalle de atrezzo final, pero a las calles no, eso ya lo haremos en la fase siguiente. En el caso de un bosque, en esta fase sería "pintar" el terreno de árboles e indicar algunas zonas con casas o atrezzo variado, pero sin entrar mucho en detalle.
• Tercera fase: esta última fase es donde, a partir de las pruebas de juego realizadas, terminamos de llenar la zona con más atrezzo para acabar de dar el detalle que nos gustaría que tuviera la versión final. En el caso de la ciudad, por ejemplo, sería poner los pasos de cebra, más señales de tráfico, más atrezzo en las aceras de la ciudad para darle más vidilla, calles en obras, etc. En el caso del bosque, se terminaría de llenar la zona con rocas, árboles caídos y atrezzo más detallado en las zonas de casas.

Actualmente, nos encontramos acabando la segunda fase de la parte de la ciudad que estamos haciendo. Una vez terminadas las parcelas nos pondremos a detallar un poco más el atrezzo de las calles.

Paralelamente, también estamos intentando optimizar el juego para que vaya lo más fluido posible, creando los niveles de LOD (Level of Detail) para cada objeto y las geometrías de colisión adecuadas para que no afecten en exceso al rendimiento.

En cuanto a programación, lo que tenemos hecho hasta ahora es el control de físicas del atrezzo de la ciudad, para que cada objeto reaccione correctamente cuando el vehículo del jugador colisione con este y balancear los parámetros de peso para que cada objeto reaccione como se espera.

Además, tenemos bastante encarriladas las físicas de la pickup, para que reaccione como se espera.

Ahora que prácticamente tenemos terminada esta zona del mapa, lo que haremos será hacer una pausa en cuanto a creación de más mapa, y centrarnos en la jugabilidad en sí que tendrá el juego. Es decir, por una parte crear un menú simple del juego, que se irá ampliando más adelante. Y por otra parte, centrarnos en el tema de las misiones.

En cuanto a las misiones, la idea es crear un sistema de misión básica y luego ya ir ampliándolo. El sistema de misión básica deberá tener un punto de partida inicial dónde recoger el paquete y un punto final dónde entregar el paquete. Habrá un contador de tiempo para poder puntuar la velocidad de la entrega. Además, el paquete tendrá un indicador de los daños que recibe durante el trayecto. Para poder hacer una buena puntuación, se deberá de llegar en el menor tiempo posible y sin que el paquete sufra daños o los mínimos posibles. Si la entrega no se hace en un tiempo decente o el paquete ha sufrido muchos daños, la misión se dará por fallida.

De momento esto es lo que tenemos en mente. En las próximas semanas os mostraremos los avances de lo comentado en esta entrada.

Para finalizar, os mostraremos alguna imagen más de nuestra ciudad en segunda fase :-).

Vista de unos parques de la ciudad.

Vista de la cafetería del club de tennis.

Vista interior de una parcela de edificios.

Vista de una zona en obras en un callejón.

Esperamos que os haya gustado y nos vemos en la siguiente entrada :-).

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 :-)

Vídeo gameplay: De ruta por la ciudad.

Estas últimas semanas mostrábamos imágenes y más imágenes de zonas nuevas que íbamos creando. Así que ésta semana, y tal y como avanzamos el pasado lunes, variaremos un poco el contenido y mostraremos un vídeo de una versió pre-pre-pre-alpha del juego :D.

La idea es mostrar algo en movimiento, las colisiones con el atrezzo de la ciudad y las físicas de nuestra pickup.

Preparad palomitas que empezamos con los fails. Como es normal, se ven muchos. Desde fallos en la cámara al entrar dentro de almacenes. Pasando por la etiqueta "Preview" en las sombras aún no computadas (Unreal Engine tiene una opción para quitar esta etiqueta, pero se ha puesto burro y no quiere, y cuando no quiere, no las quita...). Siguiendo por el LOD (Level of Detail) de objetos que se ven lejos. Y un largo etcétera.

Para este vídeo hemos utilizado el teclado para controlar el coche, pero también se puede controlar con un mando como el de la XBox, que seguramente utilizaremos en próximos vídeos. Pero en este nos ha dado algun problema de calibración y hemos preferido el teclado.

La cámara tampoco es definitiva. Quizá en la versión final del juego la vista será isométrica y con la cámara más lejos, ya veremos.

Y para que veáis que programar es divertido, os dejamos un funny moment que nos pasó programando las colisiones del atrezzo.

El problema fué que nos equivocamos al conectar unas cosillas sin importancia en los Blueprint de las físicas del coche y del atrezzo, y en lugar de activar las físicas en el atrezzo se la activamos a las ruedas del coche :-).

Esperamos que os haya gustado y nos vemos en la siguiente entrada :-).