[ /// ] - Diario de desarrollo

13500 #1 Feb '14

Hola, mi nombre es José Carlos (13500). Aunque no me dedico profesionalmente al desarrollo de videojuegos (trabajo como webmaster), es un mundo que me apasiona y en el que llevo intentando entrar desde hace un par de años.

Prólogo

Tras numerosos proyectillos y coqueteos en varias plataformas y campos (programacion, android, 3D lowpoly, 3D renders, musica... algunos puede que me conozcan por 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 videojuego en ningún sitio, por lo que hoy me dispongo a redactar mi primer diario de desarrollo de una pequeña demo.

Durante el diario de desarrollo 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 comienzo al diario de desarrollo.

¿Qué es [ /// ]?

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

spoiler

a esto

spoiler

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... a mi manera. 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...

Screens

5

13500 #2 Feb '14

Requisitos y tormenta de ideas

Quiero 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.

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

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

E

Ekisu #3 Mar '14

up! como va el desarrollo #1?

1 respuesta

13500 #4 Mar '14

Muchas gracias por el interés #3 . La verdad es que el desarrollo va bastante avanzado, pero sigo poniendo por aquí los pasos uno por uno para documentar todo el recorrido.

dia 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í

desechar esta idea

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.

1 respuesta

_dGr_ #5 Mar '14

#4
Muy buena pinta!. Te sigo de cerca...

13500 #6 Mar '14

dia 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 la posición de este "collider", 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"

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.

13500 #7 Mar '14

[[ INCISO ]]

Publicada primera build v1.3 alpha

https://dl.dropboxusercontent.com/u/11143518/sundark_web/sundark_web.html

En los próximos días, continuo el diario detallado de desarrollo.

[[ /INCISO ]]

URGENTE

Tiempo de carga
- reordenar scripts (flujo de llamada de funciones)
- separar métodos y funciones
- separar acciones por script:
- - 1.cs para movimiento
- - 1.cs para springJoint
- - 1.cs para disparos
- - 1.cs para...
Rebuild explosiones
Mostrar cursor en menu
Opciones en menu
- volumen (musica y fx)
- sensibilidad movimiento ratón (player)
Rebuild enemigos (que cojones pasa, son 14 o 15, se queda 1 vivo)
Rebuild pantalla de puntuaciones (asco)
- 'r' para reiniciar partida
- 'q' para main menu
'Esc' para menu opciones o Quit (mostrar puntero ratón)
Diferentes targets [///]:
- mostrar [///] si y solo si, enemigo esta en visor
- eliminar flechas < ^ V >

DETALLES

Partículas flotantes en rápido movimiento
Animaciones IA de fondo (batallas de cruceros)
Opciones en menu:
- seleccionar otros skyboxes/escenarios
- mostrar ocultar GUI
Spawnear más enemigos sin previa ubicación
Escudo protector de energía

BEYOND

Otros tipos de enemigos (con otros tipos de disparos)
Otros tipos de armas para player

1