jueves, 29 de noviembre de 2012

Postmortem: Nowadays Parte 2


Ahora es cuando toca analizar los fallos y ponerse mal a uno mismo. Voy a reflexionar sobre que cosas hice mal, sin meterme mucho en que podría haber añadido (por que eso es tema de tiempo y de capacidad de implementación más que de no haberlo pensado).

Errores

Falta de documentación

Para empezar no hubo un documento de diseño. Este se suplió con un monton de papeles llenos de bocetos, ideas, trozos de código… y lo iba escribiendo sobre la marcha, por lo que no hubo una planificación y una preproducción y eso se notó en las fases avanzadas del proyecto que cada vez se ponía más cuesta arriba.

Falta de experiencia

Tanto en la parte gráfica, donde los gráficos (que no eran ninguna maravilla, visto ahora) tenían texturas mal hechas con mapeados simples del tipo esfera, cubo o plano, como en la programación, donde acabé teniendo un monton de código duplicado y mal estructurado que, a la hora de corregir errores, lo hacia bastante complicado.


Falta de coherencia

Los enemigos no mantenian algo en común entre si, y lo mismo pasaba con items, menus, y todo el arte en general. Lo ideal hubiera sido usar los colores para diferenciar los disparos enemigos de los del jugador y lo mismo para las naves. Si un item es una caja, todos deberían haber sido cajas (aunque con distintos dibujos), y si el marcador de energía del usuario era una barra, también debería haberlo sido para el enemigo de final de fase.

Perspectiva

Los fondos estan en perspectiva isométrica, pero no ocurre lo mismo con las naves, lo que le da un aspecto extraño al movimiento. Esto fue debido a que no sabía renderizar en pespectiva isometrica en mi software 3D y aprendí en una fase del proyecto en la que tocaba incorporar los fondos pero ya tenía el resto de cosas programadas con sus respectivos gráficos que no volví a renderizar.

Velocidad de juego

El juego es lento y no conseguía lo que yo pretendí desde el principio, que hubiera que esquivar un montón de disparos en cada nivel. Esto se debió sobretodo a un código caotico y poco eficiente que hacía que demasiados elementos en pantalla ralentizaran el juego, por lo que no pude incorporar toda la acción que hubiera deseado.


Copias de seguridad

Importante para no perder el juego, ya que cuando estaba terminado en un 50% aproximadamente, mi disco duro se estropeó y perdí gran parte del trabajo y sobretodo la posibilidad de terminar el juego al 100%.

Música y sonido

Nunca he sido excesivamente bueno haciendo música, pero me propuse hacer esta parte del juego, asi que esta parte, tambien se puede considerar negativa. Hice lo que pude y no lo que convenía a cada situación o escena de juego. Lo ideal es que la música y el sonido transmita lo que se esta viendo en la pantalla, pero se requiere una gran habilidad para crear distintos estilos músicales para conseguir esto.

Menu de opciones

El juego no tiene un menu de opciones que permita configurar la musica, el sonido, tamaño de pantalla o ese tipo de cosas. Habría ganado bastante con ello aunque no fuera lo más importante del mundo.


Selección de naves, pero era la misma

Aunque podíamos elegir entre distintas naves con las que jugar todas se comportaban de forma identica y tenían las mismas armas y forma de moverse, solo varíaba el gráfico que las representaba. Lo ideal habría sido que cada una hubiera tenido velocidad o peso distintos, o disparara sus armas exclusivas, lo que habría hecho el juego más interesante.

Lo positivo

Trabajar duro por mi primer proyecto, ponerle ilusión y ganas, aprender muchisimo y disfrutar jugando mi propio juego incluso años después de crearlo. Las 25000 (o 20000, no recuerdo) pesetas que me pagaron por mi trabajo, el intento de innovar usando perspectiva isométrica para un tipo de juego que normalmente se movia horizontal o verticalmente (aunque ya estaba inventado) y, por último, la incorporación de detalles como items, trucos, selección de naves, etc.

El recuerdo y la sensación de dar un gran primer paso es lo mejor de todo. Iremos mejorando.

Fin de mi primer PostMortem.

- Para descargar y jugar la Beta de Nowadays, recordamos el post: http://creadorvj.blogspot.com.es/2012/08/descarga-de-proyectos-nowadays-beta.html -
 

lunes, 26 de noviembre de 2012

Amigos y rivales

Una iniciativa del Blog de un amigo me ha traido a este tema al que le doy vueltas a menudo. Como mucha gente sabe, soy seguidor de algunos animes como Bakuman, donde se le da gran importancia a la amistad, pero también a la rivalidad. Esto me ha hecho plantearme muchas veces que me gustaría tener un rival con el que competir en esta carrera por llegar a ser creador de videojuegos, pero eso si, un rival con ilusión e iniciativa, que haga cosas constantemente para que yo piense “no puedo perder contra él” y consiga que yo mismo trabaje más. Sin embargo, por otro lado no estoy muy a favor de la cultura de la competencia que se nos enseña hoy en día, donde hay que pisar a los demás para ser el mejor y donde no todo el mundo puede triunfar, si no que para que unos pocos consigan sus metas otros muchos deben fracasar en la consecucion de las suyas. Esto me lleva a pensar en los aliados, por que tener un amigo con el que se compite pero también se colabora aporta mucho más que tener solo un rival que nos esconde sus cartas y evita que podamos aprender de él mientras trata de aprender de nosotros. He pensado muchas veces en asociarme con gente para trabajar juntos, enviarnos modelos en 3D o dibujos para que el otro corrija los fallos y opine devolviendole luego el favor con sus propios modelos. (También se puede hacer con minijuegos, juegos completos, canciones, programas, o lo que sea).

¿Cuál sería la mejor opción?

Supongo que depende de cada uno, pero en el Blog de mi amigo donde se han jugado un bocadillo y una Coca Cola por ver quien hacía el mejor juego me han dado mi respuesta. El tiempo de desarrollo disminuye y la ilusión aumentan cuando hay una competencia sana, con un colega, una competencia de la que podemos aprender, por que nadie esconde sus armas y esta dispuesto a ayudar, a apoyar y a compartir conocimientos (aunque sea despues de ganar el bocadillo y la Coca Cola). Ambos se impulsan mutuamente para llevar a cabo sus tareas. La pena que siempre he tenido sobre esto es no haber encontrado nadie de mi ciudad o muy cercano con el que emprender juntos el camino para ser desarrolladores de juegos (online no es lo mismo), o tal vez a un rival con el que competir y que haga que me rechinen los dientes cada vez que escuche su nombre o sus logros. Hay gente por aquí, pero no tiene puestos todos sus sentidos en lo mismo que yo (aunque actualmente con los estudios yo tpc puedo invertir tanto tiempo como me gustaría en juegos).


Mi consejo es este. Si teneis un rival, ayudaos de la competición que se genera y tratar de superarle, pero sobretodo de superaos a vosotros mismos. Si por el contrario teneis un aliado en vuestro camino, trabajad juntos, generad competición sana y aprended el uno del otro. Llegareis más lejos y en menos tiempo. Eso si, hay que tener en cuenta que la ilusión se desvanece con el tiempo y hay que realimentarla. Iniciativas como la del bocadillo y la Coca Cola del Blog de Todaim, pueden conseguirlo.

domingo, 25 de noviembre de 2012

Postmortem: Nowadays Parte 1

Introducción

El postmortem es el analisis de un proyecto una vez ha finalizado y ha salido a la luz, en el caso de los videojuegos, cuando ya ha podido ser jugado y visto por todos. Hay que mirar cosas positivas y negativas, donde estuvieron los fallos y de que forma podían haberse hecho las cosas mejor, pero sobretodo, el objetivo es aprender, tanto de los errores como de las cosas bien hechas y cargarse de la ilusión que se tenía al inicio del proyecto para mantenerla en el siguiente. Empiezo así mi serie de postmortem de los proyectos que hice a lo largo de mi vida y los que seguiré haciendo, para tomar nota de todo y seguir mejorando.

Nowadays

Año 1998 (Que ya hace), después de hacer unos cuantos ejemplos de código escrito en Div, me planteo llevar a buen puerto mi sueño de crear un videojuego y me pongo a programar. ¿Qué juego puedo hacer? Con lo que se hasta ahora solo puedo meterme en matamarcianos, por que no llevaría físicas, la IA de los enemigos es sencilla, y el tipo de control basado solo en moverse en todas direcciones y disparar es simple. ¿Voy a hacer un matamarcianos de toda la vida? ¡Ni pensarlo! Quiero que se vea bien gráficamente y no sea lo típico, asi que huyendo de lo horizontal o lo vertical en el desplazamiento del scroll, me quedo en un término medio, la isometrica.


Una vez tenía decicido mi primer proyecto, que plantee como juego comercial que trataría de vender a alguna distribuidora, me puse a modelar y pintar gráficos, a crear texturas, hacer la música y el sonido y a programar.

Pasos a seguir

Lo primero, tener una nave que se movía por la pantalla modelada en 3D para que pudiera verse en isométrica y fuera facil de animar. Después los menús, donde ver los créditos, jugar o salir del juego (Decidí no poner opciones).


Historia

Para la parte de la historia no me compliqué demasiado a nivel texto, fue todo improvisado, pues un juego de naves no requieré de una excusa para dar al jugador el poder de acabar con todo lo que aparezca por la pantalla pero, por otro lado, si trabajé la trama en la parte gráfica, con modelado de los personajes que serían pilotos de las naves protagonistas o enemigas, ciudades y una portada para el juego.

Diseño gráfico

Al diseño gráfico le invertí una gran parte del tiempo, creando un logotipo del proyecto y un diseño de interfaz, que elegí por eficacia. Dado que la acción se desarrollaba en perspectiva isométrica, me venía bien que la pantalla de juego fuera cuadrada, por lo que la parte sobrante sería para el HUD donde guardar mostrar al jugador las bombas que le quedaban, los puntos, su energía o la de su enemigo, junto con una foto del piloto de su nave.


Items y selección de protagonista

Quise que el jugador pudiera elegir su nave preferida entre 6 posibles, por lo que tuve que crearlas, hacer un menú para elegirlas y hacer que el juego funcionara con cada una de ellas. Por otro lado, los items, empezaron siendo bastantes, pero el tiempo de desarrollo los fue reduciendo. Aunque tenía muchas ideas que iba apuntando en un papel que tenía en un tablón de corcho, había demasiadas cosas que implementar en el juego y poco tiempo, experiencia y habilidad para llevarlas a cabo.

Enemigos

Algo curioso que ocurrio con este tema fue que los enemigos, en principio, iban a ser protagonistas. La elección que hice de un gráfico para un proposito u otro acabo siendo por cuestiones de gustos personales. Las naves que me parecían más interesantes acabaron siendo controladas por el usuario y las que me gustaban menos se convirtieron en los enemigos.



Armas

Quería lasers brillanes, fuegos que iluminaran, bolas de energía con destellos y misiles que provocaran explosiones gigantescas para limpiar la pantalla, pero sobretodo quería escudos de energía y disparos múltiples para que hubiese muchas “balas” moviendose por toda la zona de juego y hubiera que esquivar bastante.

Escenarios

Los escenarios consistian en gigantescas imágenes que se moverían en el eje x y también en el eje y gracias al scroll. No había varios planos, sino solo uno, y la decisión de que tipo de fondos había en cada fase los decidí escribiendo en un papel las ideas que me surgieron, ya que al principio solo tenía claro que el primer nivel sería una ciudad en ruinas y el último un superordenador que representaba la inteligencia artificial que había desencadenado la historia.

Código fuente

El código fuente iba creciendo cada día y haciendose más complicado de manejar, por lo que desde el principio trate de que no hubiera errores en la parte que tenía antes de avanzar a la siguiente. Así, intentaba no arrastrar fallos de un fragmento del juego a otro. En caso de no saber resolver un problema de código con lo que sabía de programación en Div, trataba de hacerlo de otro modo que si conociera, aunque fuera menos eficiente. Desde el menu, el movimiento de la nave, el comportamiento de los enemigos, los trucos… Todo salió de ejemplos de los que había aprendido antes o de ideas felices, aunque caoticas en muchas ocasiones.

Manuales y trucos

Mi sueño se estaba cumpliendo poco a poco, y empezaba a tener mi gran proyecto como algo jugable, asi que tenía impaciencia por verlo metido en una caja y con su manual, como los juegos que se vendían en las tiendas. Me puse a trabajar en ello, haciendo uso de lo que sabía de programas de retoque o maquetación. Además realicé un manual de instrucciones en formato de página web, pensando después en los trucos, los cuales surgieron como idea tras leer en una revista que, para presentar juegos a distribuidoras, muchos desarrolladores añadian trucos para poder saltar rápido de nivel o enseñar todos los items funcionando y que la persona que les iba a dar la pasta pudiera verlo todo en poco tiempo.

Dado que no hacía nunca copias de seguridad, al final, cuando tenía un 50% del juego aproximadamente, mi disco duro murió y no pude recuperar nada de lo que había en él, lo que me lleva a hablar de los errores del proyecto.

Fin de la primera parte, pronto la segunda.

- Para jugar a la Beta de Nowadays, recordamos el post: http://creadorvj.blogspot.com.es/2012/08/descarga-de-proyectos-nowadays-beta.html -

miércoles, 21 de noviembre de 2012

Diseño de juegos - Generos: Plataformas

El personaje de un juego de plataformas, como su propio nombre indica, suele correr y saltar de plataforma en plataforma de manera que se enfrenta a unos enemigos y avanza hacia su objetivo final.

Este tipo de juegos se fueron complicando cada vez más, de modo que, además de correr y saltar, actualmente también se camina, se escala, se superan obstáculos cada vez más variados…

Generalmente a los plataformas se les suele añadir un gameplay extra que haga más variadas las acciones y que, de paso, les permita diferenciarse de la competencia. Por ejemplo, suele ser clásica la búsqueda de items ocultos o la necesidad de recoger un número concreto de ellos repartidos por todo el nivel para poder seguir avanzando. Y es que además, este género utiliza mucho el concepto de nivel tal y como lo hemos conocido siempre, es decir, superar uno para avanzar hasta el siguiente, en ocasiones con posibilidad de elegir entre varias opciones para que no se haga excesivamente lineal.


Los enemigos de final de fase también son muy comunes en este tipo de juegos. En ellos se nos plantea un reto que superar usando los recursos y acciones obtenidas y aprendidas durante el resto de la partida. Si al principio aprendimos un salto especial para matar a cierto tipo de enemigos, suele ser comun que haya que usarlo de alguna forma u otra para superar al boss de final de fase. Una vez superado este, se suele recomendar premiar al jugador y, si la intensidad ha subido demasiado, calmarla con un nivel sencillo y tranquilo bajo el agua o similar.


¿Cómo podemos premiar al jugador? Una tienda o una fase de bonus donde conseguir vidas extra o items suele ser habitual. Lo que nos lleva a otra cosa típica: El jugador suele fallar habitualmente durante su aventura y matar a su personaje en muchas ocasiones, por lo que es común proporcionarle varias vidas o una cantidad de energía disponible que le ayude a cumplir los objetivos del prota, cuya historia, puede ser muy variable, pero casi siempre sucede en mundos de fantasía alejados de la realidad que conocemos.

Otra cosa a destacar de este género es que a día de hoy se puede diferenciar entre plataformas 2D, cuyo avance es lateral y se nos permite movernos solo arriba o abajo (eje x o eje y); plataformas 3D, donde nos movemos en 3 dimensiones y en los cuales el avance es hacia la profundidad de la pantalla; y los plataformas 2.5D, donde se mezclan los dos anteriores, permitiéndonos movimientos limitados, normalmente a dos dimensiones, pero en una vista tridimensional.



Ejemplos de juegos de plataformas son los clásicos juegos de Super Mario, Sonic, o, por nombrar uno actual y que me encanta, Mutant Mudds.

sábado, 17 de noviembre de 2012

Diseño de juegos: El Prototipo

Si se me ocurre una idea para el gameplay de un juego mega-revolucionaria, o simplemente voy a usar un género de los de toda la vida, pero voy a añadirle alguna cosilla de cosecha propia, o a probar una nueva historia ¿Cómo puedo saber si el juego funcionará y será divertido? ¡Pues desarrollandolo! Pero claro, si vamos a estar meses e incluso años dedicando tiempo a un juego que luego nos parezca aburrido y no nos guste, no parece una buena idea . ¿Cuál es la solución? Hacer un prototipo.

Un prototipo de juego necesita menos tiempo y recursos, pero trata de ser todo lo funcional que podría ser el proyecto final o al menos partes concretas del mismo, de las que queramos probar el gameplay. Para hacer esto no hacen falta grafistas, podemos usar cuadrados de colores que representen a los personajes o si va a ser en 3D, texturas y objetos de sustitución. Tampoco hacen falta sonidos o músicas, podemos prescindir de ellos o usar cualquiera que bajemos de la red. En muchos casos ni siquiera necesitaremos programar si podemos hacer el prototipo de forma visual, con formas animadas y obtener de ello una idea de cómo va a funcionar (aunque es mejor si lo programamos).


Una vez tenemos nuestro prototipo listo para ser jugado y/o visualizado, nos podemos echar unas partiditas para comprobar su buen funcionamiento, ajustar variables de juego para hacerlo más facil, dificil y mejorar cosas, plantear como solucionar futuros problemas en la programación o el diseño, y aprovechar para corregir en la documentación errores de diseño que nos vayamos encontrando. Con todo, seremos capaces de elaborar un buen documento de diseño y de planear todo el proceso de producción. Así, no solo comprobamos que estamos haciendo un juego con el que podemos quedar relativamente contentos (un desarrollador nunca esta contento al 100% con su juego, igual que a un músico nunca le gustan el 100% de las canciones de su disco), sino que también aceleraremos después el desarrollo y afrontaremos problemas con la solución practicamente pensada. Aunque parezca mentira, esto puede acelerar el trabajo y darnos mejores resultados en el proyecto final.

Para ver de lo que hablo dejo un mini-prototipo de lo que podrían ser un proyecto para un juego de preguntas y respuestas sobre juegos. A ver si las acertais todas :P

jueves, 15 de noviembre de 2012

Aumentando el realismo: Envejecer texturas

Ya he comentado en varias entradas del Blog que, para aumentar el realismo de nuestras escenas, objetos o personajes, un buen modo de hacerlo es envejecer las texturas. Esto es así por que todo lo que nos rodea esta manchado, arañado, roto o sucio. Que ahora dira alguien: “no, por que acabo de pasar la aspiradora, ya no hay pelusas debajo de la cama” ¡pues mañana miras otra vez y veras!

Los objetos nuevos, pulidos y brillantes duran muy poco y lo mismo ocurre con lo que acabamos de limpiar con todo nuestro empeño y, puesto queremos reflejar una realidad (que no tiene por que ser la nuestra) en nuestro videojuego, tenemos que tener en cuenta esto cuando hacemos texturas, e incluso a veces es mejor pasarnos que quedarnos cortos.

La historia de las cosas

Una buena forma de envejecer texturas es pensar en la historia de las cosas, por que aunque situemos al jugador en una escena, se supone que ese mundo virtual antes de llegar a ese punto en el tiempo, lleva existiendo años. Han pasado muchas cosas antes de llegar al día donde comenzamos a contar nuestra historia, por esto, nos interesa pensar en ese coche que ya hace 10 años que el protagonista compró y necesita ruedas nuevas y una mano de pintura, en esa televisión a la que hace días que nadie le pasa un plumero, tiene la pantalla arañada y le faltan tres botones, o en los pantalones que lleva nuestro personaje y que estan un poco gastados, rotos y con alguna mancha de café que no hay forma de quitar, por que una vez se le derramó encima estando en la oficina.



Combinar texturas

Una forma rápida de conseguir envejecer texturas consiste en tener en nuestro catálogo texturas de arañazos, grietas, manchas o roturas. Gracias a ellas podremos ajustarles un poco el color y combinarlas con la textura original gracias a la opacidad o los modos de capa que tienen practicamente todos los programas de retoque fotográfico del mercado (incluso muchos gratuitos). A veces, es mejor que estas imágenes estén en escala de grises para poder sacar de ellas mapas de normales o que la combinación sea más realista y facil de conseguir.





Pintar el paso del tiempo

Aunque lo más rápido sea la combinación, si estamos pintando materiales por que nuestro juego es de tipo cartoon o necesitamos añadir más suciedad y defectos por que aun no tenemos suficientes, a veces habrá que pintar a mano las manchas, quemaduras, pegatinas medio borradas o todo aquello que necesitemos. Para esta parte suele ser bueno borrar algunas partes (en caso de las pegatinas o imágenes), desenfocar otras y suavizar la intensidad de las capas que pintemos. Hay que pensar en que zonas tenemos que marcar las imperfecciones. Por ejemplo la pintura suele levantarse en los bordes y esquinas y la ropa se rompe mucho más por donde tiene costuras.

Observad en algunas de las imágenes que adjunto como una textura envejecida aumenta en realismo y si aun teneis dudas, también esta el ejemplo de la nave de carreras. Claramente mejora bastante si añadimos las suficientes quemaduras, manchas y rascaduras para que parezca que lleva ya unas cuantas competiciones a sus “espaldas”.

sábado, 10 de noviembre de 2012

Webs recomendadas: Eresgamer.com

Me gusta mucho la iniciativa de los responsables de este sitio, que se han unido para recopilar información sobre tutoriales para el desarrollo de videojuegos y, han organizado un curso de Unity 3D a base de videotutoriales y cuestionarios. Yo mismo había pesado hacer tutoriales de Unity, pero el manejo del mismo me parecía demasiado sencillo y quería centrarme más en la parte de la programación de scripts. Ahora, el manejo de la interfaz del motor parece que quedará cubierta con los tutoriales de esta Web que recomiendo hoy.

Cosas buenas y malas

Una parte que no me gusta de Eresgamer es que no aconsejan empezar desde abajo ni recomiendan a los que empiezan en esto no meterse en proyectos demasiado grades. Al contrario, parece que se sigue fomentando el ansia de muchos novatos de hacer la competencia a empresas grandes con cientos de trabajadores creando un nuevo World of Warcraft, Crysis 3, etc. En lugar de esto quizás se debería recomendar a la gente empezar con pequeños trabajos para aprender y guardarse sus obras maestras para cuando reunan la capacidad, conocimientos y medios para poder llevarlas a buen puerto.

Por otro lado, aunque los videotutoriales de Unity, que ya han empezado a publicar, son algo improvisados, también son útiles y se puede aprender de ellos. Parecen ser una prometedora forma de introducirse en el motor y aprender a hacer nuestros primeros juegos en el futuro, así que habrá que seguirlos.

También, este sitio Web, puede nacer un punto de encuentro para desarrolladores, donde encontrar colaboradores, socios y consejos. Aunque recordemos que, para eso, en España ya tenemos stratos-ad.com, la cual es dificil de superar en este aspecto.