martes, 9 de diciembre de 2014

Corruptópolis. El juego del esperpento español

Hace unos días, Carlos me envió un mail sobre este juego y, poco después, un compañero de trabajo también me hizo llegar misma referencia.Se trata de CORRUPTOPOLIS, un juego desarrollado por la diseñadora Marina Belda y que trata de ser una crítica social al panorama actual. La autora ha financiado la edición del juego en Verkami y ha conseguido (enhorabuena!) el capital necesario para publicarlo.

Imagen del juego CORRUPTÓPOLIS (Fuente: Verkami: Corruptopolis)


No tiene mala pinta, aunque sea para pasar un rato divertido...espero poder conseguir uno y probarlo pronto!

domingo, 23 de noviembre de 2014

Operación Mun (II)

La entrada anterior finalizaba con la "sonda munar" orbitando Kerbin. Hoy vamos a llevarla a su destino final.

Lo primero es programar la maniobra que llevará la sonda al encuentro de Mun. La idea es conectar el motor en sentido pro-grado de forma que el apogeo de la órbita resultante intersecte con la trayectoria de Mun justo cuando ésta pase cerca. De este modo la nave enrará en la esfera de influencia del satélite y será capturado por éste con un poco de ayuda por nuestra parte.

Y allá vamos!!

Una vez finalizada la maniobra, la trayectoria de la sonda entrará en la zona de influencia de Mun.

Cuando estemos en el apogeo de la nueva trayectoria influenciada por la fuerza de gravedad de Mun, entonces encendemos los motores en sentido contra-grado para que el perigeo se acerque al satélite, logrando de este modo un órbita estable a su alrededor. Lo ideal es que el perigeo quede a una altitud menor de 34.000 m sobre Mun para que estemos en órbita cercana y poder realizar todos los experimentos (más un "crew report" y un EVA report) a las dos altitudes.

Una vez realizados iniciamos la maniobra de vuelta a Kerbin de forma similar a la ida. Pero, como la masa de Mun es mucho menor que la de Kerbin, la energía que debemos invertir en el regreso es mucho menor.

Cuando nos captura Kerbin la trayectoria no nos conduce a un aterrizaje, por lo que será necesario realizar correcciones durante el vuelo. Y todo esto sería maravilloso si nos quedase combustible para esa segunda maniobra. Pero si os fijáis en la imagen sólo nos quedan telarañas en los tanques de fuel. Esto es una metáfora, ya que, por supuesto, las arañas no pueden vivir en el espacio.

Pero afortunadamente habíamos añadido unos pequeños depósitos de monopropelente y cuatro motores iguales a los de la fase 1 que devolvimos a Kerbin. Ese pequeño impulso es suficiente para devolvernos a casa.

Con esto completamos la primera fase de la misión de exploración de Mun. Otro día plantaremos la preceptiva bandera en el satélite.

sábado, 22 de noviembre de 2014

Segundo intento de computer game (burning city iii)

Hemos planteado el juego siguiendo la filosofía de Lean Game Design comentada en la entrada del 24 de septiembre de 2014, esto es, empleando código ya existente así como sonidos y gráficos de fuentes gratuitas. Además nos hemos centrado en un sólo nivel que sea jugable, prescindiendo de momento de pantallas de introducción, otros niveles y detalles que sólo hará falta desarrollar en caso que el juego resulte mínimamente entretenido.

El código lo estamos desarrollando en Python 3.2. con el IDE Ninja 2.3 usando las librerías de Pygame y pyganim, la primera para facilitar el desarrollo de los gráficos interactivos y la segunda para gestionar las animaciones.

Sobre Pyhton ya hemos hablado con anterioridad como un lenguaje de programación que, a mi parecer, da bastante juego por ser un lenguaje orientado a objetos. Para utilizar código ya existente, hemos tirado sobre todo en el que desarrollé en el curso de Python de la Universidad de Rice, en concreto, el que emplee para el desarrollo de RiceRocks, una especie de Asteroids.

Para los gráficos, hemos usado los de acceso libre de Vector Open Stock, de Vecteezy, de  Dryicons,  y Free Vector, y para los sonidos, Sound Bible.

A partir del concepto y empleando estas fuentes de gráficos, hicimos una primera aproximación más detallada que nos dará idea del tamaño de sprites que vamos a usar, el tamaño del lienzo, cuántos assets más nos hacen falta, etc.
Y este es el aspecto deseado:
 
Boceto de la primera pantalla
El tiempo de búsqueda de gráficos fue algo más largo, quizá un par de días pero con toda la información, el tiempo de montaje de la escena no fue más de 6 ó 7 horas.

Ahora hemos pasado a la fase de programación en la que se plantea el problema de dividir el programa en tareas y subtareas y la compartición de información. Para compartir información estamos usando Dropbox, compartiendo una carpeta en la que vamos numerando las versiones por fecha y hora. Hay otros métodos más sofisticados, como el Git y BitBucket para gestionar versiones, pero de momento optamos por el mencionado Dropbox porque es bastante sencillo. 

Para controlar las tareas y subtareas que debe hacer cada uno de nosotros, estamos usando Asana, una aplicación para trabajo en equipo sin usar e-mail que he empleado en proyectos de trabajo reales y funciona bastante bien.

Las tareas en Asana

domingo, 16 de noviembre de 2014

Segundo intento de computer game: Burning City (ii)

Miguel Angel y yo hemos empezado con el trabajo previo de definición del juego, la mecánica y la dinámica. Para ello, hemos utilizado la Plantilla para diseñar juegos de la que ya hablamos en la entrada del 12 de octubre.

El tema (muy valenciano...) es el siguiente:

Theme

Eres un bombero en plenas Fallas de Valencia y te han asignado para que controles la cremà. De momento te han dado una falla pequeña, a medida que lo hagas mejor, te asignarán fallas de mayor categoría y quien sabe si más equipo. Tu trabajo es controlar las llamas, evitar que se escapen brasas ardiendo que puedan quemar a la gente de alrededor o a la base de la falla, enfriar las fachadas colindantes para que no se quemen las fincas y remojar a quien te lo pida mientras dejas que la falla se queme completamente sin contratiempos. 

La dinámica del juego es de dos tipos: 
  • Supervivencia
 Básicamente hay que aguantar hasta que la falla se queme completamente, evitando que ocurra ningún desastre que haga llegar a los equipos de emergencias y tenga que apagarse la falla antes de tiempo. Es un juego de habilidad (skill), no incluye estrategia y muy poca suerte (chance). 

  • Destrucción
Hay que eliminar a las llamas que salen de la falla y caen al suelo y apagar las llamas que se prenden en la fachada o que hacen peligrar a la gente de alrededor.

Hemos establecido las condiciones de la victoria: 

La falla termina de arder sin contratiempos. 
  
Contratiempos

  • Si las llamas caen en una finca y no se apagan irán encendiendo más partes de la finca. Si una finca tiene ardiendo 1/3 suenan las sirenas y el juego termina, perdiendo el jugador.
  • Si una llama cae al suelo y no se apaga irá enciendiendo más zonas del suelo. Si llega a la gente se oirán sirenas y el juego termina. 
Progresión del juego
Plantearemos para esta primera versión sólo una pantalla.

Al arrancar el juego iniciará directamente.
  1.  Sonido de música 
  2. Falla empieza a arder 
  3. Progreso del juego 
    1. Las llamas en la falla van subiendo a un ritmo de 1 + llama por cada 3 segundos.
    2. Cada vez que las llamas suben un nivel completo saltan 4 llamas que van a parar aleatoriamente al suelo o a las fincas vecinas. 
    3. El bombero apaga las llamas si puede (ver acciones del jugador) 
    4. La barra de progreso avanza un paso por altura de la falla. 

Acciones del jugador

El jugador puede mover hacia delante y atrás. En esta versión, el personaje no se dará la vuelta. Con el ratón elige el ángulo de la manguera. Al pulsar el botón izquierdo del ratón sale el chorro de agua, que para al soltar la tecla.

Definición de la “vista del juego” (en función del “estado del juego”)
La vista del juego es única. Frontal de la falla.
Posición del bombero respecto a la falla, no la puede superar, siempre está en el lado izquierdo. Puede haber llamas en el suelo o en las paredes las fincas colindantes a la falla que el bombero debe apagar.
Hay una barra de progreso en la zona inferior izquierda de la pantalla donde una llama avanza sobre una barra que indica el tiempo que le queda a la falla para arder completamente.
Puntuación en la parte superior derecha de la pantalla.
 Cada vez que el agua del bombero apaga una llama suma puntuación 10 puntos por llama del suelo y 5 puntos por llama de las fincas.
La llama se transforma en una estrella con la numeración en el interior. Suena un sonido (a determinar), desaparece la estrella y los puntos suben al marcador.

Diseño del contenido
Empezamos con unos bocetos iniciale sdel bombero y del escenario.


Boceto de la pantalla y de la barra de progreso (a la izquierda)
Boceto de bombero

miércoles, 12 de noviembre de 2014

Cohetes reutilizables

El concepto de naves reutilizables en el KSP no fue demasiado interesante hasta la salida de first contract. Todo el mundo podía enviar cohetes a la luna dejando el espacio lleno de desperdicios sobrantes de las fases quemadas de las naves.

A partir de la actualización 0.25 no nos podemos permitir el lujo de dejar caer al mar todas las partes del cohete que nos apetezcan. Esto se debe a que la recompensa que obtengamos de las misiones deben cubrir el coste de volar la nave en cuestión. El combustible gastado siempre va a ser un coste fijo, por lo que no nos conviene incrementarlo destruyendo los motores de las fases sobrantes.

La clave de todo el asunto va a ser que todas aquellas piezas que vayamos descartando a medida que ascendemos vayan equipadas con paracaídas que impidan su destrucción cuando lleguen al suelo. Sin embargo, este método no valdría para naves en órbita, ya que las piezas descartadas no vuelven solas a Kerbin. Es lo que tiene orbitar..., no caes nunca al planenta.

El enfoque contrario consiste en diseñar algo parecido a un avión. Una nave que pueda llegar a órbita y, tras el vuelo, pueda aterrizar (¿o sería kerbinizar?). Son los llamados SSTO (Single Stage To Orbit). Este tipo de naves es muy tractivo, pero para mis diseños no han tenido éxito. Además con las piezas que disponemos al principio es imposible elevar un avión a más de 20.000 m de altura.

Afortunadamente, siempre que tengas dudas sobbre el KSP puedes consultar a Scott Manley, que viene a ser como el oráculo de los dioses de Kerbin. En este video titulado "Kerbal Space Program - 100% Reusable Space Program -" aporta una idea de diseño muy interesante para resolver nuestro problema: un cohete con motor potente auxiliado con motores jet para el ascenso. Estos motores consumen muy poco combustible por lo que en el momento de encender el motor principal todavia queda suficiente para alcanzar la órbita.

Como me gustó tanto la idea la tomé como base para mis futuros diseños. Lo primero era conseguir los motores auxiliares, para ello tomé un depósito "Mk1 Fuselage - Jet Fuel", un motor "Basic Jet Engine" y las tomas de aire "XM-G50 Radial Air Intake" (dos por motor). En la imagen se ve también un motor auxiliar parecido al que utiliza Scott.

Este es el primer cohete que diseñé utilizando los motores auxiliares. Su principal cometido fue llevar a cabo los contratos que implican hacer pruebas a más de 20.000 m ya que a partir de esa altura, los aviones convencionales no llegan. Esta nave no puede escapar de Kerbin y alcanzar una trayectoria orbital.

Nótense las escalerillas y los aparatos científicos para hacer experimentos en el lugar de aterrizaje y, así, acelerar la recolección de puntos de ciencia.

Un punto muy importante consiste en montar los motores auxiliares mediante "subassemblies" en lugar de utilizar la herramienta de simetría. Por cuestiones en la programación del KSP, cuando colocas tomas de aire, éstas se asignan al primer motor que se monta después. Es decir, que si ponemos con la herramienta de simetría 6 depósitos y seis tomas encima, al colocar los 6 motores, todas las tomas se asignan al primer motor dejando sin aire al resto. Para evitar esto debe diseñarse el depósito con toma de aire y motor en un "subassembly" y con la herramienta de simetría colocarse 6 motores completos iguales. Así se asegura el mismo flujo de aire a todos.

Esta es la versión mejorada con motores auxiliares más potentes. Es capaz de alcanzar los 30.000 m de altitud. A partir de ahí las tomas de aire no pueden captar oxígeno y los motores empiezan a quemar el oxidante del depósito de combustible principal, lo que es bastante malo. Antes de ese momento conviene desconectar los auxiliares y continuar el ascenso con el motor principal. Esta nave si que es capaz de llegar a una órbita baja alrededor del planeta.

Esta es la versión definitiva, muy parecida al de Scott Manley. Únicamente he añadido depósitos de monopropelente más grandes y unos propulsores "O-10 MonoPropellant Engine" que son muy útiles para maniobrar en el espacio ya que el motor principal es demasiado potente para esas tareas. Una vez alcanza la órbita, suelta la carga y puede volver a Kerbin. Es importante aterrizar cerca del centro espacial ya que en caso contrario se pierde dinero en la recuperación.

Esta nave es capaz de poner en órbita cargas moderadamente pesadas.

Una vez alcanzas la órbita deseada, sueltas la carga.

También sirve para poner en órbita pequeños satélites.

Y regresamos a casa con la Fase 1 intacta.

Esto nos permite recuperar casi el 100% de las piezas utilizadas. Tan solo hemos gastado combustible.

jueves, 30 de octubre de 2014

Mis primeros contratos en KSP

Como diría Finn el Humano: ganar puntos de ciencia mola; poder diseñar naves con un montón de gadgets tecnológicos mola más; pero diseñar esas maravillas y no poder construirlas por falta de fondos es caca.

Antes de la actualización "First Contract" no teníamos que preocuparnos por el coste de las naves. El límite estaba en el cielo (ja ja ja, que metáfora tan ingeniosa, a la par que pedante, al tratarse de un programa espacial). Ahora el coste es una variable muy importante que limita el diseño de las naves.

Por unificar la terminología, la unidad monetaria del KSP no tiene nombre y su símbolo es una especie de raíz cuadrada. Como keuros, kólares o kréditos no me gustan, llamaré a la moneda "kerbolino".

En las anteriores entradas hemos visto métodos para recolectar puntos de ciencia. Pero llegará un momento que nos quedaremos sin dinero para construir naves. Urge, por tanto, encontrar una fuente de financiación que nos proporcione suficientes kerbolinos para construir lo que se nos ocurra. Esa fuente son los contratos y se consiguen en un nuevo edificio creado en la expansión: el edificio de Control de Misión.

Control de Misión se encuentra junto al edificio grande de construcción de vehículos y en él se accede a los contratos disponibles. Tenemos dos tipos: los contratos que llamo "emblemáticos" y los normales. Los primeros no expiran nunca y ofrecen grandes recompensas al realizarlos. Los que he visto hasta ahora son: volar un cohete; establecer récords de antitud (5.000 y 11.000 m); escapar de la atmósfera; orbitar la tierra; orbitar Mün, aterrizar en Mün, etc... Los segundos consisten en probar piezas y equipamiento variado en determinadas condiciones. Cuando el juego avance supongo que habrá otro tipo de contratos.

Cuando se acepta un contrato, suele entregarse una cantidad de kerbolinos como anticipo. Cuando se cumple con éxito, se entrega el resto de kerbolinos, puntos de ciencia y puntos de reputación. Estos últimos sirven, como dice el link, para mejorar los contratos disponibles. También tendrán utilidad en el edificio de administración, pero de eso hablaremos en otra ocasión. Los contratos tienen un "prestigio" (una dos o tres estrellas). Cuanto mayor sea este, mejores serán las recompensas.

Tal y como he dicho, para cumplir los contratos normales deben darse ciertas condiciones. Por ejemplo, uno podría ser probar el paracaídas Mk16 en vuelo, entre 11.000 y 16.000 m de altitud y velocidad entre 160 y 200 m/s. Estas condiciones no siempre son fáciles de conseguir. Además, para mi sorpresa, gasté más dinero construyendo el cohete que recompensa obtuve por el contrato... ¿Sería esto un bug del juego o pretendrían que éste fuese motivador? En los foros especializdos insisten en que jugar debe suponer un reto. Yo creo que es un error... (modo irónico off)

Para ver cómo funciona la mecánica de los contratos seleccioné tres de ellos que tuvieran las mismas o parecidas condiciones, así aprovechas un viaje para obtener el triple de recompensa. Los contratos eran: probar el motor "Rockomax Poodle Liquid Engine", el tren de aterrizaje "Small Gear Bay" y los estabilizadores "TT18-A Launch Stability Enhancer". Todos ellos deben probarse en Kerbin, en la situación de aterrizado. Otras situaciones (que no me interesaban) podían ser "en vuelo" o "en el mar".

El paso siguiente es el diseño de la nave.

En la imagen puede apreciarse el motor "Poodle", el tren de aterrizaje en un sitio accesible y los estabilizadores rojos. Cada uno de los dispositivos se activan según se indica en la descripción del contrato: dos de ellos mediante fases separadas y el otro mediante un menú contextual. En la esquina inferior derecha se aprecia un recuadro donde nos informa de las condiciones necesarias para el cumplimiento. El coste de la nave según se indica abajo a la derecha es de 15.612 kerbolinos.

El paso siguiente es el "lanzamiento", por llamarlo de algún modo, de la nave.

El cohete no va a volar, por ello es importante cortar la potencia rápido para que no gaste combustible... cada kerbolino cuenta. Se puede ver arriba a la izquierda la ventana que te informa del cumplimiento de las condiciones para activar las fases cuando corresponda. Además, en el centro, está el menú contextual de las ruedas.

Tras terminar la misión vemos el resultado.

¡Uauu! 15.010 kerbolinos recuperados de la nave... Si en la construcción gastamos 15.612, entonces el vuelo nos ha costado 602 kerbolinos en combustible y otros gastos. ¿Será suficiente la recompensa? Veamos los fríos números.

Con el contrato del motor nos dieron 166 kerbolinos como anticipo y 459 al cumplimiento, 27 puntos de ciencia y 4 de prestigio. Con el del tren de aterrizaje, sacamos 50 anticipados y 320 kerbolinos, 27 puntos de ciencia y 4 de prestigio al cumplimiento. Y con el estabilizador, 50 kerbolinos anticipados, 189, 14 puntos de ciencia y 4 de prestigio al cumplimento. En total hacen 267 kerbolinos anticipados y 968 al cumplimiento. Si restamos los 602 kerbolinos gastados en combustible, hemos obtenido 633 kerbolinos limpios además de 68 puntos de ciencia.

Este resultado nos abre la puerta a una nueva forma de ganar ciencia más eficiente.

domingo, 26 de octubre de 2014

Mi primer avión en KSP

Pudiendo hacer hacer cohetes, ¿para qué perder el tiempo con aviones? Pues bien... Existen buenas razones para ello.

Tras recolectar en el Centro Espacial de Kerbal los puntos de ciencia fáciles tenemos que alejarnos un poco de nuestra base para continuar con este proceso. Pero, dado que los cohetes viajan muchísimo más rápido que los aviones, será más fácil aterrizar con precisión en los lugares correctos con un vehículo lento. Por este motivo el diseño de aviones tiene su importancia en estas primeras fases de una partida en KSP.

La mejor referencia que he encontrado para explicar el diseño de aviones en el juego está en el foro del KSP. Aquí se dice que la construcción de aviones es sencilla, pero a mí no me lo parece tanto. El diseño del avión ultra-básico no es complicado, pero soy incapaz de hacer algo más allá (he probado con un bi-motor y no consigo ni despegar de la pista).

Mi primer avión, bautizado en un alarde de imaginación como "Avioncito-1", se compone de un "Mk1 Inline cockpit" al que se añaden los instrumentos científicos (todos los que quepan). Justo delante de la cabina se aprecian el termómetro y el barómetro. Después tenemos tres depósitos de fuel a modo de fuselaje y el motor a reacción. Unas alas y superficies de control: alerones "Elevon 1" y tres "AV-R8-Winglet" en la cola. Completamos el diseño con 4 ruedas "Small Gear Bay".

El diseño se podría mejorar cambiando dos depósitos fuel por fuselajes huecos para ahorrar peso. Además el tren de aterrizaje es manifiestamente mejorable ya que esta disposición hace que el avión no se pueda elevar hasta que no se acaba la pista (lo que no deja de ser peligroso). En cualquier caso, como recolector de puntos cumple su función de forma digna.

En la imagen se ve un despegue apurando la pista hasta el final.

¡¡Jeronimooooo!!
Ponemos rumbo a la isla que se ve a lo lejos nada más despegar....

¿Y cómo aterriza este avión os preguntaréis? Pues mediante los paracaídas azules que se pueden apreciar en la parte superior del fuselaje y las alas. Esta es una parte imprescindible en el diseño, puesto que necesitamos la máxima precisión en el aterrizaje. El método es sencillo... cortamos potencia y abrimos paracaídas cuando estemos en el lugar deseado. Al llegar al suelo ya podemos recolectar toda la ciencia que necesitemos.

Una de las ventajas de este método es, como ya he comentado, la precisión a la hora de elegir el lugar de aterrizaje. En uno de mis viajes descubrí por casualidad que había un bioma tipo tundra muy cerca de la base.

Hasta ahora no había estado jamás en este tipo de bioma en el juego, ya que está muy diseminado y con cohetes nunca pude aterrizar en él. Durante el primer viaje lo marqué con una bandera y así pude aterrizar cerca otra vez.

El balance final del método es que se pueden recolectar puntos de ciencia en los biomas cercanos con un coste razonable. Cada viaje saco alrededor de 29 puntos de ciencia a cambio de 700 créditos de combustible.

Nota: la moneda del KSP es el crédito, pero el nombre no me gusta nada. Y como Keuros o Kólares tampoco molan, los llamaré kerbolinos.

Para terminar, este es un método eficiente para conseguir un par de tecnologías extra necesarias para construir estaciones espaciales. No obstante, gastando a un ritmo de 700 kerbolinos por viaje, al final nos quedaremos sin fondos... En próximas entradas hablaremos del sistema de contratos, nuestra vía de financiación.

jueves, 23 de octubre de 2014

Recolección de puntos de ciencia a partir de "First Contract" en Kerbal

Este artículo analiza el problema de la recogida de puntos de ciencia a partir de la actualización "First Contract". En estos momentos ya ha salido la versión 0.25 del KSP, pero todo lo que contaré es aplicable a esta actualización.

Si recordáis la serie de artículos del KSP sobre la cosecha de puntos de ciencia, para construir esa estación espacial en Mün es necesario el disponer de muchas tecnologías desbloqueadas. Esos primeros puntos de ciencia los recogí enviando cohetes cargados de instrumentos a los distintos biomas de Kerbin.

A partir de "First Contract" esta estrategia de juego ya no es posible porque se ha intruducido la variable "coste de la nave".... Nada es gratis, incluso en los juegos.

En esta actualización te ofrecen contratos en los que debes construir una nave (que cuesta dinero) capaz de realizar una misión concreta y, si la realizas con éxito, te abonan la cantidad acordada. Claro, si para realizarla llevas una nave de 7 fases y vas llenando Kerbin de motores usados lanzados alegremente los gastos serán mayores que los ingresos que recibes. Lógicamente, esta no es una estrategia sostenible.

Para jugar con éxito a esta actualización hará falta desarrollar un método que permita recolectar puntos de ciencia de una forma eficiente y barata. Para ello desarrollé un "cohete" peculiar que bauticé como "Ruedines 1"

Como no disponía de la tecnología necesaria para desarrollar vehículos terrestres, dispuse dos command pods unidos a modo de ruedas que se desplazan girando para avanzar por el terreno. Este ingenio se desplaza con electricidad por lo que hay que montar unas cuantas baterías, además de colocar los instrumentos científicos. Todos ellos se han montado por duplicado para tomar muestras de dos biomas en cada viaje y optimizar el coste (aunque es poco, algo consume).

La misión de "Ruedines 1" es ir desplazándose por el Centro Espacial de Kerbin ya que allí hay muchos biomas de los que puedes tomar lecturas para recoger los valiosos puntos de ciencia. Esto lo descubrí gracias a un "mod" llamdo "[x] Science!" que muestra el progreso en la recogida de puntos de ciencia por los diferentes biomas del juego.

Dicho y hecho. Me pasé un par de días yendo de aquí para allí visitando los rincones más pintorescos del Centro.

En cada uno de ellos realizaba los experimentos y la correspondiente toma de muestras.

Una vez finalizado todo fui capaz de obtener todas las tecnologías básicas de golpe.

El siguiente paso es hacer algo parecido con los biomas del planeta Kerbin, para lo que será necesario construir cohetes o aviones de verdad. Con todas las tecnologías recién descubiertas seguro que lo conseguiré.

Para finalizar, deseo agradecer a la nave "Ruedines 1" su gran contribución al avance del Programa Espacial de Kerbal.

lunes, 20 de octubre de 2014

Diseño de personajes: Digital Character Design & Painting de Don Seegmiller

Estoy leyendo Digital Character Design and Painting: The Photoshop CS Edition de Don Seegmiller, un interesante libro que habla del diseño de personajes usando Photoshop, una herramienta gráfica de todos conocida.



Sin entrar en detalle sobre la parte de manejo de Photoshop, el libro contiene una primera parte titulada CHARACTER DESIGN en la que da algunos consejos muy interesantes sobre diseño de personajes  que ya han sido comentados en este blog por aparecer también en otros libros. Desde la generación de la idea mediante el uso técnicas de ideación, pasando por  técnicas para su desarrollo (caricaturizar, sobreimponer, cambiar la escala, crear un híbrido...) se llega a la definición en detalle del personaje.

Se hace especial énfasis en definir un personaje partiendo de su historia, su entorno, su personalidad, su aspecto general, pasando luego al aspecto físico del personaje. 

En función de dónde va a insertarse el personaje, a qué distancia se representa o el nivel de protagonismo que tiene en el juego hará falta profundizar más o menos en su materialización o incluso definir su movimiento, pero el autor tiene algo claro: 

mantenlo simple

Esto quiere decir, simplifica siempre que sea posible, ve de lo general a lo particular y no uses demasiados componentes.

Este consejo me parece especialmente interesante  y también va ligado a la información que el personaje intenta transmitir. Por ingenioso que sea, no suele ser buena idea confundir al jugador. La idea sobre quién es y cómo es el personaje debe transmitirse visualmente.


Alien...¿el diseño del personaje evoca  bondad?..espera un momento...creo que no...

En este sentido el autor defiende el uso razonable de los estereotipos, que no resulten ofensivos desde luego, porque permiten al jugador reconocer fácilmente ante qué personaje nos encontramos. No obstante, creo que deben manejarse con mucho cuidado, quizá el uso de arquetipos y del simbolismo, aunque más elaborado y complejo, creo que puede reportar resultados más interesantes.