domingo, 28 de octubre de 2012

Cosas que debería saber un diseñador de videojuegos

¿Debería saber dibujar?

Si y no, es decir, no necesita saber dibujar, incluso no pasaría nada si no tuviera ni idea de hacer un simple garabato, pero si necesita saber expresarse. El miedo al papel (o la pantalla) en blanco es un enemigo muy grande para un diseñador de videojuegos y debe superarlo cuanto antes. Debe saber explicar sus ideas y hacer que los demás las comprendan, por que no sirve de nada idear el gameplay más innovador del mundo si no puedes hacer que el equipo que te va a ayudar a desarrollarlo comprenda en que consiste.

Si eres el peor dibujante del mundo, asegurate de tener siempre cerca a alguien que pueda dibujar tus ideas o, al menos, de aprender a usar el google para encontrar imágenes que te sirvan de apoyo a la hora de mostrar tus ideas al resto de colaboradores.




¿Debería saber programar?

Después de un tiempo observando como funciona esto del desarrollo de juegos he llegado a la conclusión de que, aunque a lo mejor no es imprescindible que un diseñador de juegos sepa programar, si que ayuda mucho a ser mejor diseñador. El hecho de que una persona conozca los límites de su equipo hace que pueda plantear cosas posibles en tiempos razonables. Por otro lado el saber programar o al menos manejar algún tipo de motor que te permita hacer algo sin picar código, ayuda a la hora de realizar un prototipo y comprobar que la jugabilidad que ha pensado el diseñador puede ser divertida y beneficiosa para el usuario.

¿Debería saber 3d?

Bajo mi punto de vista no es necesario, pero si util. Si diseñamos niveles o algún tipo de esquema que ilustré las ideas del gameplay que se nos ha ocurrido para un juego 3D, a veces el poder realizarlo en las mismas dimensiones en que se desarrollará dicho juego nos va a facilitar mucho las cosas. Modelando cajas, cilindros y sabiendo como movernos por un entorno 3D seremos capaces de enseñar a nuestro equipo que en la habitación del fondo hay un secreto al que se accede de tal forma y que en la de encima, si rompemos la pared con el puzzle que se nos ha ocurrido, se continua la aventura.



¿Debería saber escribir?

¡Esto es esencial! Escribir historias, describir situaciones, documentar, anotar ideas, transmitir las de otros compañeros del équipo… Hay que saber crear documentos de diseño y expresarse lo suficientemente bien sobre el papel para que nuestras creaciones no se olviden y sean comprendidas por todos. Además, en este caso también viene bien un poquito de inglés, sobretodo leido y escrito, por si nuestra empresa o grupo es un poco internacional.

¿Debería saber hacer Música?

En este caso mi opinión es que no es necesario. Quizá es bueno tener claro que tipo de música o sonido aproximado se quiere para cada situación y orientar a los profesionales para que hagan aquello que puede irle bien a nuestra idea, pero… vamos a dejar a los que saben que hagan su trabajo, que seguro que tienen mejor oido y más experiencia.

¿Debería saber diseñar niveles?

Siempre se ha dicho que aprender a diseñar niveles era un buen modo de convertirse con el tiempo en diseñador de juegos por lo que es evidente que hay que saber de ello. Aunque haya un rol especifico para esto, cuando se piensa en un gameplay, en una historia, estilo gráfico y demás, se tendrá algunas ideas sobre que tipo de enemigos, en que número y en que lugar pueden aparecer. Luego el diseñador de niveles (si lo hay) se puede encargar de mejorar eso más detalladamente.

¿Debería saber diseñar interfaces?

También hay un rol para esto, pero no en todos los proyectos y, cuando se piensa en la idea para un videojuego, también conviene darle vueltas a como vamos a presentarle la información al usuario y facilitarle las acciones que tenga que realizar.

¿Debería saber escribir un guión?

Un diseñador que sabe pensar buenas historias diseña mucho mejor, ya que en muchas ocasiones, es la propia trama la que te indica que tipo de gameplay le va bien. Quizás no hace falta conocer todas las técnicas o tener la habilidad escribiendo de un novelista de éxito, pero ya que hemos dicho antes que hay que saber escribir, vamos a añadirle que hay que saber QUE escribir.

¿Y qué más?

Curvas de dificultad, añadidos que puedan alargar la vida del juego, equilibrar… pero sobretodo ¡jugar y analizar! Por que un diseñador de juegos es alguien que disfruta jugando y analizando cada detalle para idear cosas que sorprendan al usuario, el mismo debe pensar como un usuario más. Vamos a hacer juegos divertidos, atractivos, interesantes y sorprendentes, por que eso es lo que cualquiera de nosotros/a reclamaría como jugador/a.

martes, 23 de octubre de 2012

Juegos que me influyeron como desarrollador: Day Of The Tentacle

Volvemos de nuevo al pasado, a aquella maravillosa época en que las aventuras gráficas empezaban a manternos horas y horas delante de la pantalla pensando en como resolver los puzzles que nos planteaban. La segunda parte de Maniac Mansion llegó a mis manos y, después de pensar en lo horrible que me resultó la primera, me dispuse a probarla quedando gratamente sorprendido. Tres personajes con los que jugar en distintas épocas gracias a una máquina del tiempo (que a mi me gustan bastante), personajes geniales como el tentáculo púrpura que quería dominar el mundo y de nuevo el sistema SCUMM para controlar nuestras acciones a traves de verbos como “ir a” o “coger”.


Este juego tenía puzzles geniales, y fue entonces cuando empecé a plantearme como se diseñaba un proyecto como aquel y, otra cosa que no me habia planeado antes, como crear una interfaz para un videojuego.

Como no soy la única persona a la que este juego ha influido, también me encontré un pequeño homenaje al mismo en Pangea (la aparición de Bernard, el protagonista de Day of the Tentacle), que tuve oportunidad de testear “trabajando” para su creador Leandro José García. (Por cierto que en el juego también aparece Larry).



Después de Maniac Mansion 2 y también de los dos primeros Monkey Island, mi afición por las aventuras gráficas me llevo a escribir historias y diseñar puzzles para decenas de ellas, todas de temática humoristica. Así fue como en más de una ocasión traté de participar en proyectos de este tipo, los cuales debido a la enorme carga de trabajo artístico y de animación que conllevan, siempre se quedaban a medias.

Algún día, tal vez si reuno un buen équipo de personas en el que pueda confiar. :P

Por cierto, os cuento un poco de que va Day of the Tentacle:

Comienza un tiempo después de los eventos transcurridos en Maniac Mansion. Bernard, el típico tipo con gafas, regresa, pero en esta ocasion acompañado de sus amigos Hoagie y Laverne.

Una de las dos creaciones del Dr. Fred Edison, el Tentáculo Púrpura, toma un residuo radioactivo del exterior de la Mansión, que hace que le crezcan brazos y sea dominado por el deseo de conquistar el mundo. Bernard y sus amigos planean volver atrás en el tiempo, usando el invento de las Cron-O-Letrinas del Dr. Fred, para detener al Tentáculo Púrpura y evitar el incidente del tentaculo con los residuos.

Para el uso de la maquina del tiempo recurren a un diamante de imitación provocando que falle y transporte a Hoagie doscientos años al pasado y a Laverne doscientos años al futuro (un futuro dominado por tentáculos, por cierto). Bernard, sin embargo, se queda en el presente y, con la ayuda del tentáculo verde, debe encontrar un diamante para hacer que la máquina del tiempo funcione de nuevo, y Hoagie y Laverne puedan volver a sus Cron-O-Letrinas, conectarlas a una fuente de energía, y regresar para vencer al tentáculo púrpura.










sábado, 20 de octubre de 2012

Creando entornos


Me temo que no voy a dar un curso de modelado de entornos 3D, ya que sería muy largo y necesitaría años de tutoriales en el Blog (y tiempo para hacerlos), pero para no dejar totalmente de lado el lado “poligonal” de mi página, hoy he decidido repasar algunas ideas a tener en cuenta a la hora de traer a la vida escenarios para videojuegos. Ya sabeis, a la gente le resulta muy atractivo crear el protagonista de la historia, pero si no tiene un mundo por el que moverse no sirve de nada su existencia, por lo que se necesitan modeladores de entornos o creadores de texturas para los mismos y, aunque no lo creamos, es una tarea dificil y larga pero con resultados muy agradecidos. ¡Sentios orgullosos de vuestra creación final!

Medidas:

Es importante tener en cuenta tamaños y medidas a la hora de crear ciudades, paisajes o lo que sea, pero no hay que confiar del todo en la realidad. A veces, las puertas necesitan un tamaño más grande para que puedan pasar decentemente las cámaras o el personaje con su arma de tamaño “vamosadarlesunsustocuandonosveanaparecerconesto”. Los edificios, igualmente podriamos tener que modelarlos en un tamaño reducido (aunque puede exagerarse el tamaño de la escena usando después trucos de cámara) y luego dedicarnos a la parte interior de los mismos con mucho más detalle y extensión, ya que podría cargarse esta como una escena distinta.


Para saber que medidas tomar se recomienda la elaboración de prototipos, sobretodo si vamos a trabajar con “piezas” o tiles, es decir, haciendo nuestro escenario por trozos, para que un diseñador de niveles los junte a su gusto.

Props:

Hablamos de elementos como puede ser una señal de tráfico, un semáforo, una piedra, una planta… Esos objetos pequeños que forman parte de nuestro entorno y le dan vida. Necesitamos muchos para hacer todo más realista, pero es evidente que hay que tener en cuenta los polígonos que consumen y no hacerlos muy repetitivos. Si necesitamos 100 arboles no vale con hacer uno y copiarlo 100 veces, vamos a darles ciertas variaciones y en vez de eso, copiemos 5 distintos veinte veces para que el truco pase más desapercibido.


Iluminación y texturas:

¡Muy importante las dos cosas! Nuestro entorno en muchas ocasiones tendrá que ser sencillo y los edificios van a ser simples cajas para que podamos usar esos recursos en otras cosas necesarias para el proyecto. Vamos a recurrir, por lo tanto, a las texturas y luces para darle un acabado mucho más realista a ese monton de polígonos planos.


Simplificar lo que el usuario no ve:

Si pensamos en un juego en el que nos movemos por una ciudad y, en el que no se pueden usar helicopteros ni subir a la parte alta de los edificios, a la hora de modelar, vamos a centrarnos en dar detalle a la parte inferior de las calles de la ciudad. La parte superior de los edificios tendrá poco trabajo para poner todo lo interesante en lo que el usuario va a ver de cerca. Esto es un truco muy usado en los juegos actuales donde se nos presenta una escena aparentemente enorme y muy realista que en realidad esconde en la distancia el vacío más absoluto tapado por algun plano con textura o formás muy básicas con escasos polígonos. (Esos juegos lineales de pasillo fijo que hay ahora, cuanto truquillo tienen).



Ensuciar y destruir:

Mirad a vuestro alrededor un momento y fijaos en que, por muy limpios, ordenados o cuidadosos que podais ser con vuestras cosas, el uso hace que aparezcan arañazos, manchas, algun fragmento que se ha roto, etc. Eso se hace aun más evidente si se mira en la calle. Esas manchas de aceite en el asfalto, ladrillos o ventanas rotas, etc. Bien, pues deberíamos seguir esta norma a la hora de modelar un entorno. Lo nuevo dura poco por lo que un elemento pulido y limpio, que refleja que acaba de salir de la fabrica donde lo hicieron no nos parece realista, mucho menos si aparece en un mundo en el que, aunque el usuario va a entrar en ese momento, tiene que dar la sensación de que lleva existiendo años y que en él han ocurrido ya muchas cosas.

Y por último se me olvidaba. Hay que eliminar los polígonos que nunca se van a ver. Por ejemplo el suelo de una casa en la que no se va a poder entrar.




martes, 16 de octubre de 2012

HTML5 vs Flash


Justo ahora que me estaba poniendo las pilas con ActionScript, la gente me empieza a decir que hay que renovarse y pasarse a HTML5, que es la leche y que va a mandar la tecnología Flash al olvido más absoluto. (Y la verdad que ya hace tiempo que había oido eso, pero no me lo tomé muy en serio).

El caso es que, para convencerme, tuve que mirarme un poco de HTML5 y comparar observando un poco de código y de todo eso tan mágico que había detrás del proximo HTML, que realmente aun no está en su versión definitiva.

HTML5 se sirve de una nueva etiqueta, el canvas, para usar la tecnología JavaScript y, gracias a ella, hacer cosas bastante parecidas a las que se hacían con Flash, pero con la ventaja de que no necesitamos instalar ningún plug-in (Nuestros navegadores suelen venir con un interprete Javascript). En este sentido, el no necesitar descargar ningún software extra (ni actualizarlo, que Flash Player se pone un poco pesado) es la razón definitiva por la cual anticipan la derrota de Adobe ante la nueva tecnología para la Web que esta por venir.

Asi que ya veis, muy bonito todo, pero mi investigación debería centrarse en si va a darnos ventaja a los creadores de juegos, y para ello me fui a la Web "adictos al trabajo" y miré este artículo.

Os hago un resumen de lo que, por otro lado ya he comprobado:

Flash recopila todo en un solo archivo (a veces pone alguno más para fuentes, sonidos, etc.) mientras que HTML5 necesita además los archivos .js de JavaScript. Además parece que el 3D poligonal, solo existe medio decente hasta ahora en Flash (Aunque no me pregunteis como se hace) y, por último, otra cosa a la que le doy mucha importancia es que si tenemos una Web y le damos al boton derecho del ratón, encontraremos una opción para ver el código fuente, mientras que si creamos nuestro juego con Flash+ActionScript hay que currarselo un poco más para desencriptar el fichero .swf.

¿Quiere todo esto decir que soy pro-Flash?

De todos modos, por estudios, tengo que aprender lo nuevo de HTML, así que al final acabaré sabiendo las dos cosas y, seguramente, haciendo juegos para las dos propuestas (Aunque solo por pensarme si dejar ActionScript he perdido tiempo con proyectos). El caso es que algunas de las cosas por las que la tecnología de Adobe echaba para atrás a muchos desarrolladores (Que era de pago), quedaron solucionadas gracias a Flex y a algunas librerías para el desarrollo de juegos, asi que quedan pocas cosas en las que HTML5 se lleva el gato al agua en cuanto a videojuegos se refiere.

No se, tendré que investigar un poco más y ver que posibilidades tiene toda esta historia. De momento, gracias a la página de desarrolloweb ya voy aprendiendo un poco el funcionamiento del Canvas+JavaScript.

(No, la imagen no da fallo, era un monton de código para hacer que salieran cuadraditos con colores aleatorios en el navegador).


sábado, 13 de octubre de 2012

Descarga de proyectos: Pixfrogger para Android


El proyecto que hicimos hace años en Pixjuegos ha seguido adelante gracias al amigo Pablo Navarro (Pixel), que ha usado los gráficos que realicé para el original, para lanzar una versión Android.

Esta es la primera vez que vivo algo como esto, es decir, que un juego desarrollado hace tiempo siga existiendo y expandiendose sin la necesidad de que yo haga practicamente nada. ¡Es como si se hubiera independizado! ¡Se ha ido de casa y vuela libre!

Bueno, la verdad es que este fue un minijuego muy sencillo (aunque adictivo) con el que no vamos a ganar ni para comer, pero es interesante ver que siguen adelante los antigüos grupos de desarrollo en los que trabajé y les va bien (y sobretodo que siguen trabajando y teniendo ilusión).

Me gustaría dar mi impresión sobre el resultado final de Pixfrogger, pero como no tengo Smartphone por que soy pobre, no he podido probarlo y solo puedo hacerme una ligera idea de en que ha quedado la conversión de la versión para PC por los videos e imágenes que circulan por la red y que, nisiquiera se si son de la versión definitiva.

Quien lo pruebe si quiere contarme… :P

Se puede descargar desde Google Play o en Amazon y en versión gratuita o con donación.





lunes, 8 de octubre de 2012

Diseño de Videojuegos: Azar vs Habilidad del jugador


Las funciones de tipo random se usan mucho en la programación de videojuegos (es decir, el azar) y cuando se usan de manera que tienen poco en cuenta al jugador, a personas como a mi, que nos gusta confiar en nuestra habilidad a los mandos, nos resulta verdaderamente frustrante. Hablo de esos juegos donde inviertes horas en matar a un monstruo que necesitas para obtener un item que necesitas, y después, el conseguirlo o no, depende solo de la suerte de que te salga ese item y no otro. En caso de que la suerte no te acompañe, vuelve a hacer la misma operación de exterminio de bicho gigante una y otra vez hasta que te den el item que estabas buscando.

Este es un ejemplo de un juego que seguro que muchos conoceis, pero el azar esta presente en otros muchos de una manera que no permite al jugador confiar en su manejo, si no que le obliga a intentar las mismas acciones una y otra vez hasta que la combinación sea la que necesita.

Vamos a ver un caso sencillo y conocido, la programación de un juego de tragaperras. Imaginemos la funcion random que hay detrás, en el código, que hará que cada vez que bajemos la palanquita, las figuras empiecen a pasar y salgan tres al azar. Si el jugador se convierte en un experto tal vez pueda desarrollar alguna estrategía que le de alguna posibilidad de ganar, pero en principio ninguna de las habilidades que tenga o que adquiera jugando le garantiza la victoria.

Por otro lado tenemos juegos en los que cuanto más jugamos más experiencia y habilidades podemos conseguir, lo que nos da mayor posibilidad de derrotar a nuestros enemigos. El ejemplo más claro de esto podría ser un RPG en el que obtenemos experiencia, subimos de nivel y obtenemos nuevas armaduras o armas con las que somos más fuertes, rápidos, etc.

Como jugadores esta claro que cualquiera prefiere evitar eso de “coleccionar cromos” y tener que estar probando y probando hasta que te salga ese cromo que deseas, por eso como desarrolladores no es muy recomendable recurrir a un azar de este tipo, aunque sea lo más sencillo en muchos casos. El hecho es que los randoms actuan en muchas ocasiones en combinación con otros eventos para crear el mundo de juego y deberíamos controlar que no interrumpan la experiencia del usuario. Pongo un ejemplo de lo que quiero decir:

Imaginemos un matamarcianos en el que cada vez que acabamos con un tipo de enemigo aparece un power-up de un tipo que el programa elige al azar. Podemos tener un control de las habilidades del jugador (puntuación, daño recibido, vidas perdidas, ect) para inclinar la balanza hacia ponerle las cosas más dificiles o más sencillas dependiendo de lo experto que este usuario sea. Si se trata de un jugador que necesita retos, demosle un simple item que suba un poco su puntuación aunque no le quede demasiada vida. Si es alguien que ha perdido casi todas sus vidas en un momento podemos hacer el random solo entre items de vida extra o aumento de energía para que pueda jugar más tiempo y mejore su manejo del mando.

Cuando desarrollemos nuestros juegos seguramente usemos mucho la aletoriedad para colocar objetos, poner enemigos en pantalla, proporcionar items, lanzar preguntas al jugador… ¡Mil cosas! Pero aconsejo que se condicione esa aletoriedad y no se use para obligar a que las personas tengan que probar y probar siempre lo mismo hasta conseguir sus objetivos. Dejemos que aquel que echa horas en nuestro proyecto y consigue dominarlo pueda demostrar que va a ganar por que ha entrenado para merecerlo. :P


martes, 2 de octubre de 2012

Técnicas de guión aplicadas a videojuegos: El Falso Fracaso del Heroe


No se exactamente cual es el nombre “oficial” de esta técnica, por eso la he llamado de este modo. El caso es que esto lo vais a ver mucho en los comics y series de animación japonesas.

Nos encontramos con un personaje que tiene muy buena fama sobre su fuerza, rapidez o lo que sea. Sin embargo, cuando llega la hora de demostrar sus habilidades es derrotado o se ve en una situación en la que parece que no puede hacer nada. ¿Nuestro heroe ha tenido fracasado? ¡No puede ser! De pronto, con toda la naturalidad del mundo, da a entender que todo era algún tipo de juego y es ahora cuando se va a tomar las cosas en serio. Despues de casi habernos decepcionado, el protagonista es justo lo que se esperaba de él y acaba ganando.

Para que entendamos mejor a lo que me refiero podeis ver muchos ejemplos de esto en la serie Dragon Ball del maestro Akira Toriyama. Muchas veces, Goku se presenta como un guerrero rapidisimo y muy agil, pero pronto su rival le supera y parece perdido. De pronto, nuestro querido heroe tira su muñequeras, tobilleras y la parte superior del traje al suelo y podemos comprobar que la ropa esta diseñada para pesar mucho y que, al llevarla todo el día, permite entrenar a Goku. La batalla vuelve a empezar y se demuestra que el prota era lo que esperabamos, rápido y agil. Se le ha dado la vuelta a la trama y ahora si que parece que pueda ganar al rival.

¿Cómo lo aplicamos a videojuegos?

¿Y si nuestro protagonista dispusiera de unas habilidades increibles y pudieramos contarselo al jugador desde el principio? Dejemos que espere mucho del personaje que está apunto de controlar. Sin embargo, a la hora de tomar los mandos, algo hace que se vea un poco limitado en sus poderes (Hay que tener cuidado de no frustrar mucho al jugador). Cuando parezca que derrotar al enemigo es imposible, demosle todo el poder al usuario que le habiamos prometido desde el principio. Es el momento de que la barra de vida se llene y todo empiece de cero. Ahora si puede ganar. Antes solo estaba bromeando.

La dificultad como siempre es encontrar una historia que nos de buenos motivos para que suceda esto durante el juego. Normalmente todo esto funciona con un personaje un poco chulo o que ve con ingenua naturalidad el ser extraordinario.