lunes, 19 de junio de 2017

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


lunes, 12 de junio de 2017

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!
  • 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! ... eh... que no, que es broma...
  • 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 :-).

lunes, 5 de junio de 2017

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