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.




domingo, 19 de octubre de 2014

Puzzles. El juego más difícil: NOTPRON

Hace unas semanas un compañero de trabajo me habló de notpron el que parece ser uno de los juegos más difíciles de la red. Se trata de una serie de 140 acertijos en los que, básicamente, se muestra una imagen al usuario o se oye una música o un sonido y poco más. El jugador debe leer el código html, analizar la imagen o manipularla. Básicamente debe conocer a fondo como funcional el ordenador, los sistemas de ficheros...además de tener imaginación y pensamiento lateral. Me recuerda un poco al Juego Más Difícil del Verano, que publicaba El País por el año 1992.
Empecé a jugar hace unos días y llegué a la fase 8, donde estoy ahora sin saber muy bien por donde tirar...
Espero que lleguéis más lejos que yo. Este es el link: notpron


Pantalla inicial de notpron

domingo, 12 de octubre de 2014

Boceto de juego en Gamemaker

En una de las primeras entradas, en concreto en la del martes, 22 de enero de 2013 comenté muy de pasada el software Gamemaker. Tenía hecho un boceto de juego en gamemaker (es un ejecutable) que no recordaba hasta que punto estaba avanzado. La verdad es que tiene poca cosa, pero sí que sirve para darle un vistazo a esta plataforma de desarrollo. En el prototipo, como veréis, el tema del contacto con otros personajes no está resuelto pero podéis mover el personaje con las flechas del teclado.


Plantilla para diseñar juegos

A partir de lo que he ido aprendiendo de los autores que he ido leyendo estos meses, he confeccionado una especie de  plantilla para diseñar juegos que resume algunos de los elementos básicos que hay que considerar al diseñar un juego. Aunque sólo es un boceto, creo que puede ser útil para que no se nos olviden muchas cosas y usarlo como guía para compartir ideas entre diseñadores de juegos, encargados del diseño gráfico y los assets y los programadores. La usaré para desarrollar con Juanma el juego en Python que comenté hace unas entradas.

miércoles, 24 de septiembre de 2014

Lean Game Design

Hoy he estado en una formación sobre Lean Start up y he pensado sobre este proceso y las similitudes con la filosofía de Sharon Boller (Play test. Play test). 

De algún modo la idea de Sharon Boller es la misma que la expresada en el Lean Start up: ten algo listo sin demasiado esfuerzo en el acabado o los detalles pero con suficiente calidad (lo que en Lean se llama PMV, el Producto Mínimo Viable; es decir, un prototipo mínimo que si bien no cuenta con los elementos que luego podrían ser importantes para el cliente), pruébalo y modifícalo, así sucesivamente. 

Esquema de the lean start up (Fuente: http://losnuevosguerreros.org/)
Con esta idea he buscado si existe la metodología aplicada al diseño de juegos, y resulta que sí, en concreto a los computer games. La referencia está, como no podría ser de otro modo en Gamasutra.

 El artículo de Tyler York en Gamasutra habla del concepto de MVG (Minimum Viable Game) que es un juego que sirva para probar la mecánica básica del juego, haciendo menos trabajo y gastando menos dinero del que pensamos. Necesitamos construir el primer nivel del juego, lo que proporcionará el marco para las pruebas y nos dará un retorno valioso. Este primer nivel debería ser realizado de la forma más rápida y barata posible, para lo cuál, el autor nos da algunas sugerencias como usar código ya existente, usar sónido y gráficos muy básicos (de hecho sugiere usar recursos de arte gratuitos hasta que tengamos desarrollados los nuestros o echar mano de artistas con pequeños contratos), incluir sólo las características necesarias (no hace falta un menú de inicio, un sistema de salvado de partidas, etc..).

Con el prototipo de juego listo, el siguiente paso es probarlo, a través de foros en los que los usuarios estén abiertos a probar prototipos, como en Gamers Forum y tener herramientas para medir lo que deseamos saber del juego. Una vez medido lo que nos interesa, hay que analizar los resultados. Aunque Tyler York propone un test de hipótesis, seguramente podremos encontrar herramientas más adecuadas, sobre todo si los datos que estamos analizando no son normales o son no paramétricos, pero esa es otra historia y debe ser contada en otra ocasión.
 
La Historia interminable y estadística...se puede ser más freak...esperad a las próximas entradas...(Fuente: http://miscelaneapasarratos.blogspot.com.es/)