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.

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

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

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.