lunes, 25 de septiembre de 2017

Vehículos y aspectos legales.

Ya tocaba sentarnos a hablar de los coches del juego :). La verdad es que no tiene mucho misterio, pero sí que queríamos hacer una entrada comentando algunos aspectos que hemos tenido que tener en cuenta para la incorporación de cualquier tipo de vehículo al juego. Además, os traemos una novedad muy chula, ¡tenemos nuevo coche para el juego!

En concreto, queríamos comentar todo el tema de los aspectos legales. Y es que no se puede modelar cualquier cosa que sea propia de una empresa, no solo vehículos, y ponerlo en tu juego así como así. Una vez más, os instamos a que os leáis (si no lo habéis hecho ya) una entrada de ya hace bastante donde comentábamos cosicas acerca de recursos gratuitos o de pago.

El caso es que quisimos informarnos de como podía funcionar el tema de los vehículos, y como todo apuntaba a que, por lógica, no se podrían usar, decidimos preguntar en foros de Unreal. Y sí amigos, no se pueden poner coches de marcas conocidas en vuestros juegos sin pagar licencias. Mucho menos si pretendéis hacer caja con él, ya sea vendiendo el juego, ganando dinero por publicidad, etc etc.

¡Pero tranquilos! no todo está perdido. Como sabréis, en juegos como GTA aparecen coches sospechosamente parecidos a modelos muy concretos de marcas conocidas. Pues eso, que no podéis copiar tal cual modelos, pero sí se pueden hacer modificaciones o interpretaciones del vehículo original para acabar teniendo un modelo que te puede recordar a un coche determinado pero nunca ser exacto. En nuestro caso, ayuda bastante que el estilo sea lowpoly cartoon, porque hace que ya ni nos paremos a modelar detalles, que suelen ser esas cosas las que acaban haciendo reconocible el modelo exacto que se ha creado.

Nosotros para el primer vehículo que hicimos y que ya estaréis cansados de ver en nuestros gameplays, no pensamos en este punto, y lo hicimos mucho antes de ponernos a indagar sobre el tema. ¡Error! Es algo que tendremos que cambiar si o si en el futuro próximo.


Pickup. Vista frontal.

Pickup. Vista trasera.

Para el próximo coche que hoy mismo podréis ver en acción, ya intentamos modificar partes del vehículo, sobretodo del morro. ¿A qué coche os recuerda? :-)



Clásico. Vista frontal.

Clásico. Vista trasera.

Durante estas semanas también hemos ido toqueteando las físicas de los coches, haciendo más notorias las suspensiones para simular mejor el comportamiento de este tipo de coches de los años 80 o 90. Ahora visualmente se nota más cuando el vehículo toma una curva o un desnivel.

Y lo prometido es deuda. Os dejamos con la novedad que os avanzamos, un gameplay con nuestra nueva adquisición.


Esperamos que os haya gustado y nos vemos la próxima semana.

lunes, 18 de septiembre de 2017

Pantalla de puntuación al completar una misión.

En esta entrada os vamos a mostrar los avances que hemos hecho estos últimos días en cuanto a la funcionalidad básica de una misión. Es decir, iniciar en un punto, transportar el paquete a su destino y mostrar la puntuación final dependiendo del rendimiento del jugador.

Como hemos comentado en otras entradas, la puntuación final de una misión será calculada a partir del tiempo transcurrido en llegar al destino y el estado del paquete. A partir de esta puntuación también se medirá el rendimiento del jugador valorándolo de 1 a 5 estrellas. Una estrella es que lo ha hecho muy mal y cinco es que lo ha hecho muy bien.

Una vez el jugador llega al destino a tiempo y sin haber ocasionado suficientes desperfectos al paquete que está transportando, se le mostrará una ventana de misión completada con la puntuación correspondiente muy parecida a la siguiente imagen (recordad que haciendo clic en la imagen se puede ampliar).

Pantalla de misión completada con la puntuación de la misión.


Por el contrario, si el jugador no llega a tiempo a su destino o bien el paquete sufre muchos daños durante el trayecto, se dará la misión por fallida y no podrá completarla.

En ese caso se mostrará una pantalla parecida a la siguiente.

Pantalla de misión fallida.


La idea es que una vez terminada la misión, no se devuelva el jugador al menú del juego, sino que pueda seguir jugando desde donde ha terminado su último objetivo. Si quiere, podrá repetirla para intentar mejorar su mejor puntuación obtenida. También podrá seguir desde donde se encuentra en ese momento para circular libremente por el mapa o bien para dirigirse al punto de partida del siguiente objetivo en la historia.

De momento tenemos implementado que se pueda iniciar una misión solo desde el menú, pero en próximas entradas mostraremos como iniciarla también mientras se está recorriendo el mapa libremente.

Al inicio y al final de cada misión pondremos diálogos entre los personajes referentes a la misma para introducir al usuario en el siguiente punto de la historia.

Para finalizar, os dejamos con un video gameplay del proceso básico de una misión, desde que se empieza hasta que llega a su destino y se muestra la pantalla de puntuación.



Hay que tener en cuenta que estas pantallas de puntuación son las primeras pruebas, durante el desarrollo del juego se mejorarán para llegar al diseño definitivo.

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

lunes, 11 de septiembre de 2017

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

lunes, 4 de septiembre de 2017

Fase 3 del mini mapa, terminada.

En una entrada anterior os comentamos la finalización de la fase 2 de la ciudad.

En la fase 3, la última de esta zona, hemos terminado de añadir más objetos por las calles de la ciudad para acabar de darle el detalle que le faltaba.

Este detalle ha consistido en añadir zonas de parking en algunas calles, señales de tráfico, paradas de autobús, contenedores, más basura, zonas en obras, etc.

De esta parte hay más que ver que de contar, así que os dejamos con algunas imágenes de como ha quedado. Recordad que haciendo clic en cada imagen la podéis ampliar.

Calle en obras.
Calle en obras.
Vista general de un cruce.
Paso peatonal elevado.
Calle cortada por obras.
Vista general de una avenida.
Vista general de una calle.
Vista general de una obra.
Zona en obras.


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