lunes, 30 de abril de 2012

Libros: Unity 3 Game Development Hotshot

Este es el mejor libro sobre Unity de los que he podido ver hasta ahora, pero también el que requiere un nivel más avanzado, tanto, que yo seguramente tendré que volver a repasarme muchas cosas del mismo cuando tenga algunos conocimientos más. Es largo de leer por que tiene mucho código fuente, pero como todos los otros volumenes de este estilo podemos descargarnos toda la parte gráfica con la que seguir los ejemplos, asi que no tendremos que trabajar nada de esa parte, salvo todo el tema de exportación desde nuestro software 3D favorito o aplicación de texturas (hay un capitulo en el que podrémos programar un Shader, pero se ve muy de pasada).


Los ejemplos: Hay varios ejemplos de juegos que van desde un sencillo juego de plataformas 2D hasta un par de demos en 3ª persona, siendo uno de ellos con cámara al hombro, como por ejemplo, lo fue Resident Evil 4.

Extras: El libro cuenta con unas cuantas páginas finales donde se nos recuerda las funciones de Unity más importantes y útiles que vemos durante el desarrollo de los ejemplos y nos indica como y donde obtener más documentación sobre ellas. Esto es tremendamente útil ya que, además de que hay determinadas instrucciones que practicamente usaremos siempre (como Update()), también hay algunas que nos ayudaran a resolver problemas que se podrían hacer de otro modo muchisimo más dificil y menos óptimo.

Los contras: Se nos pone constantemente los dientes largos sobre lo que podríamos hacer si pagaramos por la versión Pro de Unity. Que si estas luces son mas chulas pero no están en la versión gratuita, que si esta herramienta nos ayuda a optimizar mejor el rendimiento de nuestro juego pero solo está activada en Unity Pro… Claro que no es culpa del autor del libro, es que hay que pagar por usar el motor a un nivel más profesional.

En resumen es un tomo que requiere cierto nivel en programación y en movernos por el entorno de Unity para sacarle el máximo partido, aunque esta muy bien explicado paso por paso y cualquier persona podría, siguiendo las instrucciones, desarrollar los ejemplos que se proponen (eso si, sin comprender demasiado lo que está haciendo). Así que si quereis llegar un paso más allá y aprender sobre colisiones de objetos 3D, IA, menús de juego e su interfaz, eventos, grabar y cargar partidas y un largo etc. que tiene que ver con el mundo del desarrollo de videojuegos, merece totalmente la pena la inversión.

 Por mi parte voy a seguir profundizando más en este entretenido y completo motor de juegos volviendo un poco atrás, a lo más básico, y ya repasaré lo que no recuerde de lo más avanzado cuando me ponga con algún proyecto concreto en el que necesite ayuda.

miércoles, 25 de abril de 2012

Programando VII – ActionScript 3: Texto en pantalla

Esta vez vamos a poner textos en pantalla sin tener que recurrir a la típica salida estándar y, para ello vamos a tener que importarnos un par de librerías que son las que se encargan de los objetos TextField (campo de texto) y TextFormat (formato del texto). Son las siguientes:

flash.text.TextField; 
flash.text.TextFromat;

Vale, ¿y que es eso de las librerías o paquetes? Pues nada, que resulta que los señores que crearon AS se entretuvieron en hacer una serie de clases y funciones con las que tratar cosas de forma óptima, como el texto, para hacernos la vida más sencilla. (Fijate que majetes).

Para importar estas librerías se usa la sentencia import, quedando en este caso:

import flash.text.TextField; 
import flash.text.TextFormat; 

Esto se pone en las primeras lineas de código, antes de nada y nos importa lo que necesitamos (Que si, que ya explicaremos lo que son los objetos y clases) para que podamos usarlos en nuestro código a partir de ahora.

Creando un campo de texto:

Se hace mediante la instanciación de un objeto de tipo TextField (Instanciación es como la copia, más o menos) o para que nos entendamos mejor, con la siguiente sentencia:

var nombreVariable:TextField = new TextField(); 

A nombreVariable podemos darle el nombre que queramos, pero lo demás es fijo, ya que estamos refiriendonos, como ya hemos dicho, la clase TextField y creando un objeto nuevo mediante el operador new. ¿Qué ocurre ahora? Pues que TextField tiene una serie de propiedades o variables internas ya definidas a las que podemos acceder para cambiar, por ejemplo, su posición en pantalla o el texto que va a escribir.

¿Y como lo vemos en pantalla?

Usando addChild(nombreVariable)

Esta orden añade a nuestro ”stage” o pantalla principal el objeto TextField que acabamos de crear. Pero bueno, también es una sentencia que necesitará más explicación. De momento hay que quedarse con que añade a la pantalla lo que le indiquemos entre parentesis.

¿Y que pasa con TextFormat?

Pues que es una clase (si, que si, explicaré que es eso más adelante) que funciona conjuntamente con TextField para dar un formato al texto y poder elegir su alineación, tipo de fuente, altura, anchura, si tiene borde… Es decir, que añade funcionalidades a través de nuevas variables y metodos internos.

Vamos a ver un programilla que saca un texto sin formato y otro con él:

import flash.text.TextField; 
import flash.text.TextFormat; 
var texto:TextField = new TextField(); 
texto.text="Hola de nuevo!"; 
addChild(texto); // Para imprimir el texto en la pantalla. 
texto.x=100; 
texto.y=150; 

// Ahora sacaremos el texto con formato 
var textoFormateado:TextFormat = new new TextFormat("Arial",24,0x0033FF,true);
// El true es para negrita y 0x0033FF es azul en hexadecimal 

var texto2:TextField = new TextField(); 
texto2.defaultTextFormat=textoFormateado;

 // Ahora asociamos el formato a nuestro texto anterior 
texto2.text="Con formato!"; 
texto2.width=400; 
texto2.x=200; 
texto2.y=250; 
addChild(texto2); 

Como vemos texto, saca la frase “Hola de nuevo!” con el tipo por defecto y texto2, tiene un tipo de letra, tamaño y color distinto, ya que le pasamos entre parentesis el formato a su constructor (errr… si, esto también tengo que explicarlo, si, lo se), aunque podriamos acceder a sus variables internas fuera del parentesis, usando el nombre (en este caso textoFormateado) el operador punto y su propiedad a la que añadiremos el valor deseado.

La salida del programa por lo tanto sería:


 
Donde ya vamos viendo cositas más “gráficas” que nuestros futuros juegos van a necesitar para funcionar.

Hasta la próxima!

domingo, 22 de abril de 2012

iDÉAME 2012: Después de

Por fin parece que tenemos disponibles todas las entrevistas, videos e impresiones que han surgido de este iDÉAME y, gracias a ellas, podemos recibir algo de información aquellos que no nos hemos pasado por allí en persona, pero teníamos interes en lo que se hablara.

Para mi ha habido decepciones como siempre en el trato que dan los medios a esta serie de conferencias, quizá por que no hay nadie que vaya con verdadero interés en el desarrollo de videojuegos, ya que todas las Webs o televisiones se interesan casi únicamente en las noticias de lanzamientos o en ensalzar la figura del desarrollador-empresario español y se olvidan un poquito de preguntar sobre motores, presupuestos, dev-kits (Kits para desarrollar en una consola concreta), herramientas de desarrollo o consejos para empezar en esto, etc. Además, en ningún sitio se han podido ver videos de las charlas completas, lo cual es una pena ya que, en los tiempos que vivimos, cualquiera puede ver online y en directo el E3, el Nintendo Direct (Que ha sido este fin de semana) o (esta vez no en directo) conferencias del GameLab.

El caso es que, de todas las entrevistas que he visto, me quedo con una que le han hecho en un medio llamado Juegosdb a Enric álvarez de MercurySteam, pero dejo enlaces a todas las que he visto en Blogocio y resumenes del evento en esta misma Web y otros como el del programa Zoom Net del canal 24h de Televisión Española.



Y Ahora los enlaces. Que aprendais mucho y os divirtais:

Blogocio - Entrevistas:

Jose Arcas:

http://www.youtube.com/watch?feature=player_embedded&v=1tdHQno1VYY

Pedro González

http://www.youtube.com/watch?v=rdilYic1so0&feature=relmfu

Arturo Monedero

http://www.youtube.com/watch?v=eJhhjkQXjSY&feature=channel&list=UL

Tyrone Rodriguez (2 partes)

http://www.youtube.com/watch?v=nsbbZPFPKBQ&feature=channel&list=UL

http://www.youtube.com/watch?v=EWYE9cSWq5I&feature=relmfu

Especiales en Blogocio y RTVE

Blogocio

http://www.youtube.com/watch?feature=player_embedded&v=vXkM53stYQc

Zoom Net

http://www.rtve.es/alacarta/videos/zoom-net/zoom-net-congreso-ideame-surface-20-prototype-2-21-04-12/1382453/?s1=programas&s2=ciencia-y-tecnologia&s3=zoom-net&s4=

Juegosdb entrevista a Jose Arcas

http://www.youtube.com/watch?v=6-nJeuQLkf4&feature=related

Proyectos:


Abylight y Delirium Studios muestran Los delirios de Von Sottendorff

http://www.youtube.com/watch?v=kQOkcX5J3KE&feature=relmfu

Presentación 1001 Spikes

http://www.youtube.com/watch?v=5VWpbIkMuLQ&feature=relmfu

miércoles, 18 de abril de 2012

Programando VI – ActionScript 3: Funciones

Si amigos y amigas, ya sabemos todas las sentencias necesarias para dirigir el flujo de nuestro programa. Ahora queremos que vaya por un lado, luego que se repita 3 veces, si se cumple una condición que no hagas eso… ¿Pero como organizamos más el código? ¿Cómo nos repartimos las tareas con otros programadores? Pues, antes de meternos en cosas más chungas como la Programación Orientada a Objetos (aunque ya vamos a tener que ir pegandonos con ella sin darnos cuenta), vamos a ver como partir nuestro programa en trozos más sencillos usando funciones.

Las funciones encierran el código que necesitemos en su interior y no se ejecutan hasta que son “llamadas”. Gracias a ellas, podemos tener una serie de instrucciones y que se ejecuten cuando, por ejemplo, pulsemos un botón. Así, asociamos ese código dentro de la función a las acciones del botón y la diferenciamos del resto del programa como un simple fragmento del mismo.

Veamos como funcionan:

Declarar una función se hace así:

function nombrefuncion (parametros){
     sentencias;
}


Los parámetros son “variables”que se pasan al llamar a la función para que puedan operarse con ellas o sus valores. Realmente no es necesario pasar parámetros en muchas ocasiones, pero aun así los parentesis siempre deben aparecer.

¿Cómo se llama a la función?

Con su nombre y los parámetros que esta pida.

nombrefuncion(parametros);

Vamos a ver un ejemplo de todo esto a ver si lo entendemos mejor:

var texto1:String="Hola"
var texto2:String=", "

encadena(texto1, texto2);

function encadena(texto1:String, texto2:String){
     var texto3:String="bienvenidos aprendices de AS3";
     trace (texto1+texto2+texto3);
}


La salida de este programa sería la siguiente:


Es decir, tenemos dos variables texto1 y texto2 de tipo String (cadenas de letras) y se las pasamos a la función encadena para que las junte con otra que tiene en su interior. Al ser llamada, el ordenador “empieza a leer” (no es exactamente así, pero es para que nos entendamos) dentro de la función y ejecuta las sentencias que allí va encontrando. Como el operador + “suma” las variables y estas son de tipo “texto” simplemente lo que hace es juntar unas cadenas con otras.

Pero ahora viene la parte dificil de verdad (para mí quiero decir) y es que hay que comprender algo muy importante sobre el paso de parámetros a una función. La diferencia entre pasar por valor y pasar por referencia.

Paso por valor: Es lo que ocurre en el ejemplo y consiste en que se pasa a la función, no las variables en sí, si no su valor, que se asocia luego a variables dentro de la propia función que son solo una copia. Es decir, las variables fuera de la función y las de dentro no son la misma, solo su valor al llamarse a la función. Si el valor de las variables dentro de la función cambiara, no lo haría el de las de fuera.

Lo entenderemos mejor si hacemos el mismo programa pero llamamos de forma distinta a las variables en la función y fuera.

var texto1:String="Hola"
var texto2:String=", "

encadena(texto1, texto2);

function encadena(tex1:String, tex2:String){
     var tex3:String="bienvenidos aprendices de AS3";
     trace (tex1+tex2+tex);
}


Y la salida del programa sería el mismo.

Paso por referencia: Esta vez no se copia, es realmente como si fueran las mismas variables las dos, ya que lo que se hace es apuntar a una dirección de memoria. Veamos, pensemos que tenemos un cajon en un mueble y en el hay un contenido, ponemos una variable que nos indica el contenido de ese cajón y a otra, le pasamos esta variable por referencia. Entonces esta nueva variable también indicará el contenido del cajón, por lo que si variamos ese contenido, varía en ambas variables. Ambas variables cambian su valor por que estan apuntando al contenido de la misma dirección de memoria (o el mismo cajón).

Este suele ser el caso cuando pasamos objetos o matrices. Pero todo esto ya lo veremos mejor más adelante. No preocuparse, que aún no sabemos lo que son ni los objetos ni las matrices… (Bueno yo si :P).

lunes, 16 de abril de 2012

Reportaje sobre el desarrollo de Clippox y Gametopia Games.

Ante la avalancha de videos que espero vengan en los próximos días del iDÉAME, ya estoy atento a todos los archivos multimedia sobre desarrollo de juegos que van apareciendo por Youtube y otras Webs y, de pronto, me he visto gratamente sorprendido por un reportaje (en un programa llamado: Asi me Va) sobre el desarrollo del videojuego Clippox Exodus, creado por Daniel González (mi antiguo profesor de guión y Betatester en Gametopia) y su equipo.

Normalmente las preguntas que se hacen en este tipo de reportajes no son muy técnicas, incluso a veces son muy… “siempre iguales”, pero viendolos se suele aprender algo y sobretodo, se conocen los problemas que tuvieron los creadores en su día a día del proyecto, para saber a que nos podemos enfrentar si algún día decidimos pasar por su mismo proceso creando un juego comercial.

Por mi parte, al equipo de Gametopia Games, le deseo muchas ventas y un próximo juego creado con tanta ilusión como este.

A continuación el video:

domingo, 15 de abril de 2012

Terminado mi primer libro sobre Unity

Y ya voy por la página 100 del segundo, del que ya contaré algo y enseñaré imágenes de los juegos que se hacen en sus tutoriales. Pero como ya he dicho (que si, en el título), acabo de terminar: Unity 3.x Game Development by Example. En el que se van haciendo varios juegos muy sencillos (sin mucho nivel gráfico ni un gran gameplay) donde se nos enseñan las bases de Javascrip para Unity, el entorno, animación, sonido, etc. Todo se comenta de forma muy introductoria, pero sienta las bases para que, por nuestra cuenta, podamos seguir investigando y aprendiendo a usar el Motor.

En este volumen el 3D esta en cierto modo ignorado. Para empezar por que los juegos que se hacen no tienen realmente un movimiento tridimensional, si no que se nos enseña a controlar con el ratón practicamente solo en el eje “xy” y, en segundo lugar, por que no se nos enseña a importar modelos desde software 3D ni tampoco a usar dichos modelos. En el único proyecto que tiene un desplazamiento 3D “real”, se hace todo por animación, de manera que el “personaje” anda en 1ª persona pero en forma de “video”, sin que nosotros lo controlemos.

(Por cierto, que se nos proporcionan todos los gráficos para hacer los ejemplos en el libro)




En fin, el caso es que después de esta introducción al motor Unity (no descarto escribir tutoriales cuando lo domine medianamente), y gracias a la emoción que me produce ver conferencias sobre la industria de los videojuegos (me refiero a IDÉAME), he seguido aprendiendo y haciendo ejemplos como un loco, y ya tengo varios libros más vistos para profundizar todo lo posible antes de plantearme un proyecto de juego en 3D propio.

¡¡Quiero acabar juegos!! A ver si encuentro ratitos libres con los estudios…

sábado, 14 de abril de 2012

iDÉAME 2012


Los viernes o sabados (según como esté de proyectos o estudios) suele ser día de programación y de ActionScript, pero este fin de semana toca ese ciclo de conferencias tan interesante que suelen organizar Nintendo y la Universidad Complutense de Madrid cada año y que esta vez, al parecer, se estará desarrollando en la sede del Ilustre Colegio Oficial de Médicos de Madrid.

No he podido pasarme por allí en directo pero estaré atento a través de diversas Webs como revogamers, blogocio o un canal de iDÉAME preparado por Nintendo en Youtube, para enterarme las charlas y los consejos que estan dando grandes de nuestra industria y la de otros paises.

Para saber quien asiste a las conferencias y que sorpresas se pueden encontrar allí: http://www.ideame.es/ esta es la web del evento, que por cierto, este año va a tratar el tema de: “Los 80 al rescate del videojuego”, tratando el como los juegos retro estan permitiendo a muchos desarrolladores empezar o salir al mercado con pocos recursos y devolviendonos a esa época dorada donde la diversión estaba por encima de todo.

Para ir entrando en matería, un saludo y consejos de parte de Shigeru Miyamoto:



Si estos días alguno de los que se pasa por el Blog está por allí... ¡espero que me cuente todo!

martes, 10 de abril de 2012

Técnicas de guión aplicadas a Videojuegos: Insinuacion

Esta es la que considero la “técnica” más potente de todas a la hora de escribir un guión, y es que es impresionante el efecto que genera en el espectador sin que apenas se de cuenta. ¿De que va?

No se trata de insinuaciones de tipo sexual (malpensados), de hecho en muchos textos sobre guión se puede encontrar esto con otros nombres (pero a mi se me quedó grabado lo de insinuación). Se trata de incluir algun elemento en la trama, que deje un “recuerdo sutil” al espectador, sin que apenas lo perciba (aunque a veces podemos querer que sea muy evidente) y que en un momento más avanzado de la historia, por ejemplo al final, ayude a resolver lo ocurrido.

A ver si me explico mejor: La idea es que el usuario no se extrañe de la resolución de una historia o fragmento de la misma, por que haya habido un objeto, habilidad, personaje o lo que sea, que explique que era posible que eso ocurriera.

¿Aun no se entiende? Ummm, a ver si se me ocurre un ejemplo, aunque sea cutre:

Un tipo odia a su jefe, el cual es un poco tonto y se cree el rey del universo. Este suele firmar como “machoman69” en los correos que envia dentro de la empresa. Así, cuando el prota decide que va a putear a su este tio y se dispone a buscar información en su cuenta de correo, se planta ante el ordenador, se le pide una contraseña, piensa durante un instante y entonces escribe: “machoman69”. Contraseña aceptada.

¿Se entiende? Si durante la historia no se hubiese mostrado al espectador la obsesión del mandamás por la palabra “machoman69”, cuando el prota lo hubiese escrito como contraseña habría sido confuso y quien esta viendo la historia habría pensado: “Claro, y acierta poniendo esa estupidez, y a la primera nada menos”. En cambio le dimos un motivo, y es el ver que esa palabra era constante en la vida del jefe y era probable que la usara también en su contraseña (por que además el tio era un poco tonto).

Como se puede ver es una técnica potente, imprescindible en casi cualquier guión, ya sea interactivo o no. En los libros, en los juegos, en las pelis, incluso en los monologos del club de la comedia, si estais atentos, encontrareis insinuaciones, a veces muy sutiles y otras mucho más evidentes. Siempre dependerá del efecto que busque el escritor.

Vamos a aplicar todo esto al mundo del videojuego:

Hablemos de insinuación y jugabilidad. Presentemos un objeto o una habilidad, por ejemplo, que el personaje tenga en algún momento de la historia y que de motivos a las acciones que puede realizar el jugador para lograr superar el juego. Algo que nos explique el porqué de un item, o que nos insinue de que forma vencer al enemigo final.
No sería la primera vez que durante todas las batallas contra enemigos de fin de fase vamos aprendiendo todas las acciones que necesitaremos para ganar al último.

En resumen necesitamos dar motivos a lo que ocurra en nuestra historia, y la mejor manera de conseguirlo es explicarlo con la propia historia, con imágenes, si tener que detener la inmersión del usuario explicando con palabras. Para esto: insinuación.

sábado, 7 de abril de 2012

Libro 3D Game Environments: Último capítulo

Aun no había podido completar por falta de tiempo el último capítulo de este fantástico libro de Luke Ahearn, donde se propone la creación de un escenario futurista usando técnicas más o menos actuales como Specular o Normal Mapping.

El señor Ahearn (recordad que el libro está en inglés) nos deja bastante solos en este capítulo final, ya que con lo que hemos aprendido a lo largo del libro, y el material que nos proporciona el CD tenemos de sobra. Podemos abrir el archivo terminado y ver como se ha hecho aquello en lo que podamos tener dudas y comprender una forma bastante eficiente de sacar hasta 4 o 5 capas de textura que puede llegar a tener un solo material de este escenario a partir de una imagen 2D debidamente situada en distintas capas de las que sacar cada textura.


Asi que, tras practicar y poner en práctica algunos consejos, estudiar el modelo final, etc. Aquí dejo imágenes del escenario que he hecho yo siguiendo el libro.

Y ahora, a practicar lo aprendido con modelos de mi cosecha. Que aunque el proceso puede llegar a ser muy largo y costoso para una sola persona (Un escenario tiene horas de modelado, montones de capas de textura que componen cada material, más los mapeados de todos los elementos, y la iluminación) el resultado final merece la pena.


viernes, 6 de abril de 2012

Programando V – ActionScript 3: Sentencias de Control (while y do-while)

¿Os han salido muchos bucles infinitos con la sentencia for? Pues hay que tener cuidado, por que ahora vamos con más instrucciones para la creación de bucles. Más concretamente tenemos dos nuevas: while y do-while, que realmente son iguales, pero se diferencian en una cosa muy importante que a veces nos soluciona la vida cuando estamos programando:

while comprueba si se cumple la condición antes de entrar a ejecutar el bucle.

do-while ejecuta el bucle y luego comprueba si se cumple la condición.

¿Se entiende la diferencia? Básicamente el do-while, por su forma, ejecutara las sentencias del bucle al menos una vez, mientras que el while, si no se cumple la condición de entrada, no tiene por que ejecutarse. Veamoslo todo de forma más práctica.

Forma genérica del while:

while (condición) {
     sentencias;
}


Y el do-while:

do{
     sentencias;
}while (condición);


La palabra while significa “mientras” y el do “haz”, por lo que en estas sentencias se hará lo que indiquemos en el bucle mientras se cumpla la condición.

Primero unos programas de ejemplo para comprender la diferencia dicha anteriormente:

var veces:Number=1;

// El bucle while solo se ejecuta si se cumple la condición que hay al principio

while(veces<1){ 

    trace("Se ha pasado por el bucle "+veces+" veces con el bucle while");
       // vamos incrementando la variable en cada ejecución del bucle 
    veces++; 


 // volvemos a poner nuestra variable a 1 
veces=1; 

// El bucle do-while se ejecuta siempre al menos una vez, por que evalua la condición al final 

do{ 
    trace("Se ha pasado por el bucle "+veces+" veces con el bucle do-while"); 
        // vamos incrementando la variable en cada ejecución del bucle 
    veces++; 
}while(veces<1);

El resultado del programa sería:


¿Veis? El bucle while no llega a ejecutarse por que de entrada, la condición no se cumple (la variable veces siempre es mayor que uno, o más concretamente vale 1). Sin embargo, aunque esto también ocurre en el bucle do-while (que la condición no se cumple) se ejecuta una vez, y por eso aparece un mensaje por pantalla.

Vamos a ver un último programa en el que haremos que tanto el while como el do-while tengan el mismo número de pasos:

var veces:Number=1;

// Veamos ahora como el bucle se ejecuta repetidamente hasta cumplir la condición indicada

while(veces<10){ 

    trace("Se ha pasado por el bucle "+veces+" veces con el bucle while"); 
        // vamos incrementando la variable en cada ejecución del bucle 
    veces++; 


 // volvemos a poner nuestra variable a 1 
veces=1; 

trace(""); // imprimimos una linea vacía para separar textos 

// y con do-while 

do{ 
    trace("Se ha pasado por el bucle "+veces+" veces con el bucle do-while"); 
        // vamos incrementando la variable en cada ejecución del bucle 
    veces++; 
}while(veces<10); 

// Tened siempre cuidado con los bucles infinitos!!!

La salida de este último programa sería:


En definitiva tenemos otro par de bucles que se diferencian en el for en que hay que declarar las variables que contaran los pasos fuera, y también incrementarlas de otra forma, y que se suelen usar cuando no tenemos tan claro el numero de veces que queremos que se ejecute la repetición. Pronto iremos viendo casos prácticos del uso de todo esto en videojuegos. Tened paciencia con las bases de la programación, y no os preocupeis si no entendeis todo a la primera, ya lo cogereis bien cuando entremos más en materia.

Próximamente funciones, que en AS3 son importantes para manejarse con los eventos (que ya veremos también lo que son). ¡Hasta otra!

miércoles, 4 de abril de 2012

Juegos que me influyeron como desarrollador XII: StarCraft

He leido en cientos de revistas (bueno, quizá algunas menos), que para llegar a ser un buen diseñador de niveles debes practicar… pues… ¡Diseñando niveles! ¿Pero como? Sobre el papel se puede. Pero debe haber una forma de ir un paso más allá, por que atención: si queremos ser diseñadores de juegos, ¡también es muy recomendable saber diseñar niveles! Así es como entra StarCraft en mi vida, con un editor de niveles potente y sencillo con el que practicar cada día, y convirtiendose en mi referente en lo que se refiere al género de la estrategía del que, por otra parte, nunca fui muy seguidor.



Las razas de los Terrans, Protos y Zergs se peleaban diariamente en mi pantalla por recolectar recursos y ocupar territorio, y paraban de vez en cuando para dejar que yo les colocara el mapa y decidiera sus condiciones de victoria. Y es que con el editor de niveles empezaba a sentirme como un autentico programador de juegos, pudiendo decidir cuantos minerales había que cosechar para pasar de nivel, cuantas tropas iniciales tenía la fase actual, contra quienes debíamos enfrentarnos, cuantas mejoras podían tener mis unidades, etc.



En la parte gráfica, el tema estaba en colocar los elementos que formarían el nivel. El agua por aquí, montañas por allá, aquí unos arbolicos… No se podían introducir tropas nuevas, evidentemente, pero era muy divertido sentir que estabamos alargando la historía del título con nuevas aventuras.

Pero por si no lo he explicado como es debido, StarCraft es un juego de estrategia en tiempo real, en el que controlamos una de las tres razas posibles del juego y tratamos de aumentar su ocupación del territorio, sus recursos, sus unidades, edificios, etc. Un juego genial y muy entretenido, con una jugabilidad sencilla y cómoda, historía que te dejaba con ganas de saber más, y cuya serie, está compuesta en la actualidad por 2 títulos (StarCraft y StarCraft II) junto con una expansión (Brood War).

Inluyó en mi a la hora de pensar en juegos de este género hasta el punto de que no soy capaz de imaginar nada que no tenga esa vista aerea e isométrica típica del juego. La idea de los heroes, de las tropas, de las construcciones, las mejoras…



Claro, que a la hora de innovar mejor cambiar todas esas cosas. Por ejemplo ya lo intenté cuando estuve diseñando un juego de estrategia en tiempo real que se quedó solo en el papel. Y es que no hay que dejar de planear juegos de todos los generos, aunque se queden en el cajón por falta de medios o tiempo para desarrollarlos.

lunes, 2 de abril de 2012

Estilos de dibujo

Cuando estudiaba Diseño Gráfico, en la asignatura de ilustración tenía una profesora que solía regañarme por tener un estilo muy definido.

Tienes un estilo muy reconocible” - solía decirme.

Y entonces yo pensaba que aquello no tenía nada de malo.

Si me ponen delante una ilustración tuya y no me dicen de quien es, seguro que acierto que la hiciste tu” – decía también.

¿Pero eso es bueno, no?

Bien, pues con el tiempo me demostró que es bueno solo en parte, ya que en la mayoría de ocasiones, si trabajas para un cliente, puede pedirte un estilo determinado que no tiene nada que ver con el tuyo o, si trabajas con otros ilustradores en un proyecto común, tal vez tengas que adaptarte al estilo de otro para que el aspecto del conjunto sea uniforme. Asi que, uno debe ser capaz de dibujar manga, realista, muñecos raros, animales, y todo lo que se le pida, con su propio estilo o aprendiendo a imitar lo mejor posible el trazo de otro artista.


Cuando trabajabamos en La Odisea de Valdius ya me ocurrió que tuve que estar practicando durante una o dos semanas hasta conseguir que mis concept art se integraran con el estilo de los que ya estaban hechos. Es por eso por lo que aparecieron varias versiones de la bruja Argentia.

Igualmente a veces, durante un tiempo, a la hora de diseñar nuevos personajes o escenas para un proyecto, dedico bastantes horas e incluso días a probar distintos ojos, pelos, proporciones, diseño de vestuario o formas de dibujo y color. Cuando por fin tengo algo que me gusta, he de trabajar un poco más para mantener ese estilo en el resto de arte del proyecto.

Es dificil ocultar ese toque personal que nos sale automaticamente, pero hay que adaptarse lo máximo posible a lo que se nos pide, así que practicad distintas formas de hacer las cosas e incluso copiad a otros artistas para demostraros a vosotros mismos que seriais capaces de trabajar en un proyecto común con ellos siguiendo su estilo.

Demostración :P

Dibujos mios:



Dibujos fijandome en otros artistas: