Archivo de la etiqueta: games

Update #5 UnityCity

IT’S ALL ABOUT ROADS!!

Con este breve update me dispongo a mostrar un par de capturas de una versión primitiva de iluminación y texturas de las carreteras que se podrán construir en UnityCity:


Además Me complace anunciar la inestimable y valiosa colaboración de http://mrbadgergames.com/ en la poco a poco, lenta pero insaciable creación de UnityCity.


Aún queda mucho por hacer y de hecho continúo en la creación del sistema de gestión interno del juego, pero no me gustaría mostrar nada por ahora, hasta tener algo más sólido.

 

Update #4 UnityCity

Una vez depurado el código y alcanzado la meta de que el ‘main thread’ en Unity no supere los 18~20ms, me he puesto a trabajar en la generación aleatoria de terreno mediante un único parámetro a elegir por el jugador: nivel de escarpado (entre 1 y 10), además de incluir un elemento básico y vital para el desarrollo del juego: el agua.

Update #3 UnityCity (18/06/14)

Añadido control de cámara y un último retoque visual: nubes.

El color del atardecer/amanecer es provisional, a la espera de refinarlo un poco.

unitycity_daynnite_clouds

El control de horas y días esta terminado, así como el control de cámara. Puedes moverte por el mapa, rotarlo libremente 360º y modificar el zoom en hasta 7 niveles.

UnityCity – Idea & Vision

Harto de modernas versiones de creadores y gestores de ciudades (como SimCity 2013, Cities XL…), juegos de complejidad extrema (o absolutamente todo lo contrario), mal rendimiento, y acabado tosco o insatisfactorio; me propongo hacer un proyecto que recoja la esencia de auténticos clásicos en lo que a gestión urbanística se refiere (véase Caesar, Pharaoh, o el glorioso SimCity 4).

Para comenzar, estudio una serie de requisitos que detallaré más adelante en la ficha informativa UnityCity, comenzando por lo más básico: la colocación de ‘props’ y edificios.

Para ello, me he decantado por el estilo clásico de los juegos anteriormente mencionados, dividiendo el escenario en un grid de cuadrados, con una cámara isométrica (giratoria 360º); y evitando dejar esos tan incómodos huecos vacíos.

Que dé comienzo el diario de desarrolo de ‘UnityCity’!

[///] – Día II (Player)

Antes de empezar se debe tener muy claro el flujo de trabajo a la hora de hacer el proyecto. En este caso, he decidido primero hacer un nivel jugable, con unos modelos muy básicos (sin detalles, ni texturas, ni sombras). Tan sólo el concepto de jugabilidad y dificultad ante la IA.

Una vez terminado este paso, ya llegará el momento de adornarlo todo con detalles.

Empiezo con el player, y para ello, creo un rectángulo básico que representa al cañon. Este GameObject lleva añadido un Box Collider, que hará de cuerpo detector de los disparos enemigos.

 

Hay que tener en cuenta que la posición de este “collider” no es la inicial (0,0,0); ya que se presupone, representa a una nave espacial, y el cañón en si, una parte de esta nave.

 

Luego, la cámara principal del juego ira enganchada a este cañón, de manera que se posicione en medio de la imagen de la misma, gire hacia donde gire.

 

Dejo por aquí una captura de las propiedades de este gameobject llamado “Cannon”, con las coordenadas del Box Collider.

El Rigidbody añadido al cañon tiene bloqueado tanto rotaciones como posición, en XYZ.
“PlayerCol” es el tag para el collider del player, de manera que cuando programe los disparos de los enemigos, si colisionan con “PlayerCol”, el jugador debe perder 1 barra de vida.

De la animación y el script añadidos hablaré más adelante.

[///] – Día I (Papel y boli)

Los requisitos tomados los plasmo primero en papel, antes de tomar ninguna decisión sobre el modelo de desarrollo o los prefabs a crear.

El player básicamente se compondrá por un rigidBody con posiciones x,y,z fijadas en el espacio y rotación libre, cañón que lanzará “ammo” (disparos), una cámara acoplada y una esfera sin renderizar que servirá como collisionTrigger para activar los disparos de los enemigos. El radio de dicha esfera determinará la distancia desde la que el enemigo comenzará a disparar.

Los enemigos tendrán un límite de velocidad en valores absolutos (no importa la dirección que tomen), de manera que podrán acelerar y desacelerar sin superar un límite establecido, conectados mediante springJoints al rigidBody del player.

El que el enemigo dispare a partir de cierto límite de “cercanía” del player es un hándicap en la jugabilidad. Pero otro mucho más importante es el grado de puntería a la hora de disparar al jugador.

Para esto, como el enemigo siempre avanzará de frente (es decir, aunque tome giros o elipses en torno al player, el modelo de enemigo siempre estará mirando hacia delante), el vector que seguirán sus disparos sera la variable predefinida Vector3.forward con respecto a él mismo. Es a éste vector (eje-Z en el dibujo) al que le aplico un “offset”. Para ello, obteniendo un número random en un rango determinado, se multiplica al valor del vector y el tiro se desviará en función de dicho número random.

Por tanto, para obtener mayor dificultad (el enemigo falla menos disparos), tan sólo hay que disminuir el valor del offset; y para obtener el resultado contrario, aumentarlo.
En la parte inferior del papel plasmo la idea de una posible segunda IA “aliada” con el player, que en caso de entrar en un trigger esférico del enemigo, dispare a éste.
Al no ser una idea crítica para la jugabilidad principal, la pospongo para más adelante y la dejo ahí apuntada.

En esta última página muestro un concepto de GUI. Los enemigos se verán marcados por dos corchetes [ ] que se moverán por la pantalla en una posición relativa a la cámara del player (más adelante explico el código y conversión matemática de los valores de la posición del enemigo respecto a los del GUI por la pantalla, ya que los de éste último deben variar entre 0 y 1.
Encima del modelo del enemigo aparecen los números 3/3. Estos números determinan la cantidad de disparos necesarios para eliminar al enemigo. Más tarde, una vez implementada la GUI en Unity, decidí [spoiler=desechar esta idea][img]http://i.imgur.com/aMbMmbd.jpg[/img][/spoiler] y usar barras de vida [ /// ] (lo que da lugar a este proyectillo), de modo que por cada disparo acertado se elimina una barra.
También estudio la posibilidad de cambiar el color de esta GUI en función de la cercanía al player, de modo que los enemigos más cercanos al player (y potencialmente peligrosos y al mismo tiempo fáciles de derribar) se marquen en rojo.

[///] – Requisitos y brainstorming

[///] será un minijuego con naves espaciales enemigas que tengan IA propia y disparen al jugador, que estas naves nunca se muevan 2 veces iguales, y que el comportamiento de cada una sea distinto al de las demás.
El jugador, desde una posición estática, deberá destruir todas estas naves controladas por la IA.

En principio, parece un planteamiento sencillo para implementar. El principal problema a abordar es el de la IA propia de los enemigos, el que cada uno sea único y diferente a los demás, y que encima no se muevan iguales cada nueva partida.

Aunque el jugador mantenga una posición estática, le voy a poner una vista en 1ª persona de una torreta, que pueda girar 360º en el eje-X, y una limitación de +-75º para el eje-Y. Los controles serán con un ratón y opcionalmente teclado (no descarto uso de joysticks/gamepads).

El “respawn” de enemigos será instantáneo (por ahora). Una única escena donde existan entre 20 y 25 enemigos que ataquen al jugador, y éste deba defenderse y derribarlos.

El juego será totalmente en 3D
Engine: Unity
Plataforma: PC/Webplayer

No habrá límite de tiempo para la demo. El jugador tiene 5 puntos de vida, cada disparo que reciba de la IA enemiga le restará 1 punto, y podrá recuperar 1 punto de vida por cada nave destruida. Cada nave enemiga dispondrá de 3 puntos de vida, por lo que será necesario acertar con 3 disparos.

[b][[WARNING: Posible escalón insalvable en nivel de dificultad]][/b]

Si la probabilidad de recibir disparos es mayor que destruir enemigos, se estudiará la posibilidad de añadir “un tipo de escudo de energia” con el que el jugador pueda protegerse de los disparos enemigos. Los factores generales que determinan la dificultad serán:

– Velocidad movimiento IA enemiga
– Velocidad movimiento disparo jugador
– Cantidad ráfaga disparos IA enemiga
– Cantidad ráfaga disparos jugador
– Distancia (lejanía) disparo IA enemiga
– Alcance disparo jugador
– HP IA enemiga
– HP jugador

[///] – Visión

[///] es una pequeña demo de un shooter espacial hecho en Unity. El objetivo de esta demo es pasar de esto:

a esto

O lo que es lo mismo, intentar explicar paso a paso el proceso de creación e implementación de todos los detalles y efectos que se pueden ver en un juego AAA, sin usar assets ni plugins ni prefabs…. Me gustaría hacer hincapié en que el modo en el que tomo las decisiones para el desarrollo del proyecto no tiene porqué ser, ni la mejor, ni la única, solución para cada problema o requisito.

Así que hablando de requisitos, lo siguiente es la toma de los mismos.

Prólogo

Tras numerosos pequeños proyectos en varias plataformas y campos (programación, android, 3D lowpoly, 3D renders, música… algunos puede que les suena Radio Behind, o tal vez no); miro hacia atrás y me doy cuenta de que no he dejado constancia de mi trabajo relacionado con el mundo del videojuego en ningún sitio, por lo que hoy me dispongo a crear un blog/portfolio donde mostrar todo lo que he hecho hasta ahora,  y lo que me quede por hacer.

Para cada proyecto crearé una sección de “Diario de desarrollo”.

Este diario me servirá para explicar el proceso de abstracción desde el nivel del Game Design hasta el “build & run”; y listaré en todo momento el software que utilizo, los cuales posiblemente no sean los programas más idóneos; o las decisiones de arquitectura del software que tomo para solucionar los objetivos y necesidades del diseño, las cuales posiblemente tampoco sean las más idóneas.
Tras esta titánica parrafada, doy por inaugurado el blog.

Bienvenid@ ;D