lunes, 28 de marzo de 2011

Profanation y SilverSprite

Me daba un poquito de pena dejar la cosa como estaba. Así que, antes de meterme con otro tema, me puse a juguetear con SilverSprite. Para el que no lo sepa —y le interese, claro— SilverSprite es una capa de adaptación que facilita ejecutar código XNA, en teoría con apenas cambios en el código, en Silverlight [@ Wikipedia] que a su vez es, para quien no lo sepa —y también esté interesado—, un framework pensado originalmente para desarrollar aplicaciones multimedia embebidas en páginas Web, a grosso modo. Viene a ser la respuesta de Microsoft a la plataforma Flash de Adobe y al malogradísio JavaFX de Sun/Oracle. A día de hoy, a la espera de su quinta revisión que incluye aceleración 3D y muchas cosas más, es otra filigrana tecnológica que permite también ejecutar aplicaciones en el escritorio, directamente. Sin entrar si es mejor o peor que las otras alternativas, ni tampoco si se usa más o menos en la actualidad para hacer cosas interesantes, o de que ya está HTML 5 para todo esto, lo cierto es que al ser (casi) multipltaforma [1] el que tengamos la posibilidad de ejecutar las aplicaciones hechas en XNA en la Web a modo de demostración de lo que se puede esperar en otras plataformas es algo que a mí, sinceramente, me parece cojonudo. Si cuajan MonoGame y/o ExEn, significaría que el mismo código sería ejecutable en dispositivos que van desde el iPhone hasta Xbox 360, pasando por Android, el Mac, el PC y el Windows Phone 7. Para empezar, no está nada mal. Por supuesto, en todo momento estamos hablando de juegos 2D, ya que toda la parte de 3D sigue estando en el aire en cualquiera de las alternativas existentes a día de hoy. ExEn es el que parece, dentro de su desarrollo actualmente privado, que dedicará más esfuerzo en breve a implementar parte de las API 3D de XNA 4. Ya veremos.

En mi caso el trabajo lo tuve que realizar en la máquina virtual Windows de que dispongo. Con MonoDevelop tuve muchos problemas para compilar el código Silverlight usando Moonlight SDK. Pero una vez decidido a ponerlo en marcha, y optar por hacerlo con Visual Studio, la cosa fue más o menos sencilla [2]. El esquema general a seguir es el que se encuentra en la página del proyecto SilverSprite. A partir de ahí se exigen algunos cambios menores. En mi caso, del código escrito directamente sobre MonoGame, tuve que cambiar la parte de detección de los toques en la pantalla, que directamente no existen en el API de SilverSprite, y que ahora se controlan con el ratón. También tuve que cambiar la llamada al método Begin que se realiza sobre la instancia SpriteBatch asociada a la clase del juego, ya que se exigen más parámetros. También tuve que convertir todos los sonidos a MP3 y, aprovechando, les bajé la calidad para que la descarga desde Internet no supusiera un trauma. A nivel de invocación del API de sonido también hay algunos cambios menores, pero nada significativo. Quitando el pequeño problemilla con el archivo XAML mencionado en la anotación al pie de artículo, calculo que todo el proceso me llevaría cosa de una hora, aproximadamente. A partir de ahí lo estuve probando en diferentes navegadores. En el que peor resultados obtuve fue
con Safari. El movimiento no terminaba de ser bueno, haciendo cosas raras después de cada salto. En el resto, Chrome, Firefox, Opera e Internet Explorer (en la máquina virtual), la reproducción era exactamente igual a como funciona en el simulador de iPhone.


En fin, una alternativa interesante; o una curiosidad inútil más. Ya veremos.

Al que quiera perder unos minutos con mi prueba de concepto, la podrá encontrar aquí. Si da la casualidad de que alguien tiene la última versión de Moonlight funcionando en su equipo Linux y quiere probar, que me diga qué tal le va.


[1] Ya es de sobra conocido el desprecio que siente Microsoft por la plataforma Linux. Pero también es conocido que ahí donde uno no quiere perder su tiempo, aparece gente dispuesta a ello. Para el mundo Linux existe Moonlight, proyecto auspiciado por el marco del proyecto Mono. Para todo aquel que esté interesado en probar lo de hoy en una máquina con Linux.
[2] La cosa incluso hubiese sido más sencilla si no me hubiese equivocado en una letra a la hora de referir el espacio de nombres en el que se encontraban las clases del juego. En el archivo XAML de la aplicación, ahí donde dice que se ponga «clr-namespace:» yo puse «cls-» y estuve como cosa de una hora intentando averiguar porqué demonios aquello no funcionaba ni a tiros.

sábado, 26 de marzo de 2011

Recocido de Profanation sobre cama afrutada de XNA y con relleno de MonoGame (o XNATouch)

Contaba en la entrada de ayer que tenía ganas de hacer un juego para el iPhone y que había estado buscando durante días algo con lo que desarrollarlo resultara bueno, bonito fácil y barato. También contaba que, finalmente y descartando los entornos integrados, había decidido hacer sendas pruebas de concepto con cuatro de las chopocientas mil alternativas basadas en los lenguajes que a día de hoy exiten para desarrollar para este dispositivo. Y que de las cuatro había decidido empezar con la que, sospechaba, me resultaría más fácil dado que con el lenguaje de programación C# es con el que más años de experiencia tengo y a estas alturas conozco bastantes truquillos de su sintaxis y buena parte de sus interioridades, amén de que me resultaría más comprensible el código que viese en los ejemplos sin tener que andar intentando averiguar para qué servían esos corchetes, a qué venían esos puntos y coma o por qué se metía ese bloque de código indentado en este sitio y no en uno más arriba. «¿¡Pero de dónde narices ha salido esta variable!?»

Las dificultades de hacer un (buen) juego y el objeto de la prueba de concepto.

Si me pidiesen a mí, absoluto lego en la materia, que hiciese una lista ordenada, de mayor a menor dificultad, con los elementos más difíciles para conseguir un buen juego, diría que en primer lugar estaría, sin lugar a dudas, lo que vendría a ser a modo abstracto el diseño, que incluiría cosas como el concepto, los elementos de jugabilidad, etc., etc. Lo pongo el primero porque una cosa es tener una idea como, por ejemplo, «voy a hacer un juego en el que el jugador tenga que mover unos bloques por un nivel para poder salir de él» y otra muy distinta hacerlo. Lo que vulgarmente se conoce en el refranero popular como «del dicho al hecho hay un gran trecho». Vale, lo del laberinto es fácil y la idea pinta bien, no lo voy a discutir. Ahora diseña veinte o treinta niveles, con el adecuado incremento de dificultad de uno a otro, para que el jugador no lo termine en cinco minutos, pero que además no sea tan difícil como para abandonarlo frustrado. Si alguno no me cree que se ponga a diseñar laberintos en donde el jugador tenga que ir pasando por una serie de puntos para activar puertas secretas y tal y tal y que, en resumen, resulte interesante.

Después de las tareas de diseño estaría la parte gráfica. Hay gente que dibuja muy bien y esto lo tienen ganado. Para mí no y es algo con lo que tengo que lidiar si finalmente quiero hacer algo que resulte interesante. En mi caso es un elemento limitante y no descarto que, llegado el caso, acuda a un freelance para encargarle los gráficos. Es asombrosa la cantidad de sitios en Internet que son infraestructuras de proyectos para contratar freelancers y hacer seguimiento del trabajo. Pero hete aquí que el Inglés se vuelve nuevamente imprescindible. En cualquier caso, en este punto quería evitar enfangarme con esto.

Ya en tercer lugar, y sin desmerecer otros muchos aspectos también complicados como por ejemplo el sonido, para mí estaría la programación en sí y, dado que esta es la que en primera instancia me preocupa a la hora de tomar una decisión, es sobre este término que planteé la prueba de concepto. Por ello, para poder concentrame en el código, tenía que salvar de alguna forma los dos apartados anteriores. Y no se me ocurrió mejor forma que hacer un remake de algo ya existente. Esto me quitaría el problema de los gráficos (copiar con un poco de trabajo los originales, si fuera menester) y del diseño del propio juego (copiar el original sí o sí). No se trataba de hacer el juego entero, ni siquiera toda su funcionalidad; simplemente buscaba concentrarme en cómo se podía hacer «aquello de entonces con esto de ahora» y llevar a la práctica dos o tres de las características del original. Además de que se podría incurrir en violación de derechos de propiedad.

Abu Simbel Profanation

Supongo que todos los que crecimos adorando un ordenador y siendo pioneros en esto del ocio electrónico basado en ordenadores personales, tendremos nuestros juegos favoritos. Esos que cuando en alguna conversación de cuarentones nostálgicos se empiezan a enumerar, revivimos con especial entusiasmo. Yo tengo muchos, en particular los de Ultimate Play the Game [@ Wikipedia] y los de Dinamic Software [@ Wikipedia], de mi época de Spectrum (de 12 a 15 años). Pero si hay uno en particular que encabeza la lista es el de Abu Simbel Profanation. Para mí este dificilísimo juego de 1985 (yo tenía 13 años), del que creo que no llegué a pasar de la pantalla dieciséis, supuso una revolución en los juegos de Spectrum en el género de plataformas y se trata de uno de los dos o tres que siempre quise versionar para otras plataformas. Cuando empecé a hacer mis pinitos con el código máquina (lenguaje ensamblador) para el Commodore, intenté implementar la impresión del mapeado de pantallas con superbloques [1]. Creo que durante una semana gané todos los premios al ratio de cuelgues de ordenador por hora causados por saltos condicionales fuera de código y por accesos a memoria fuera de rango. Vamos, que desistí frustrado.

Con esta prueba de concepto parecía que esta iba a ser la oportunidad de, si no todo, por lo menos programar las primeras pantallas de este genial juego. Tocaba «desempolvar» el emulador de Spectrum [Viejos tiempos para el jugador casual] y empezar a capturar las pantallas. Elegí Profanation para hacer la prueba de concepto del código con XNA. Ya tenía diseño y gráficos resueltos. Tan sólo había que recortar cada frame de la animación y ya estaba. En teoría.

Los gráficos, las escalas y primeros tropiezos

Aunque no viene mucho al caso, decir que es asombroso que cuando uno los necesita no funcionan. Justo un par de días antes de ponerme con la modernización actualicé tanto GIMP como Inkscape en mi equipo y dejaron de funcionar. Cada cierto tiempo lanzo el (ahora temido) comando de actualización de MacPorts. Sin saberlo, con la última descarga masiva de actualizaciones había conseguido dejar inservibles tanto uno como otro. Vaya mala suerte. Así que harto de andar para delante y para atrás intentando resolverlo abrí la App Store de MacOS X, busqué y me pillé dos de diseño vectorial y PixeImator. 60 euros más pobre pero me quité del golpe los problemas. De los primeros no estoy muy contento, pero el segundo es una gozada. El software en realidad es muy barato —me apunto que un día tengo que escribir sobre esto— y no me arrepiento del dinero gastado. La integración de GIMP en Mac era inexistente (se requiere X11), algo que le restaba feeling al usarlo. Vamos, me olvidé de él en diez minutos de usar el nuevo. Visto retrospectivamente está claro que no era amor lo que sentía por él.

Tras este inciso me puse a pensar en cómo sería el diseño en el iPhone, que tiene una pantalla de 320 x 480 y en el iPhone 4, en el mismo área, una resolución de 640 x 960, mientras que el juego original tenía 256 x 192. Además que había que meter botones en la pantalla para manejar al machango. Aquí me encontré que los puntos por pulgada de las pantallas de ordenador tienen una densidad bastante menor que la pantalla del terminal y que esto podía conducir a errores en las escalas. Después de hacer un boceto del diseño de la pantalla y exportarlo a la resolución del iPhone, basta con reajustar la densidad de puntos. El cálculo es tan sencillo como aplicar una relación de proporciones o una regla de tres donde comparamos el alto de la pantalla del iPhone con su densidad de puntos (163 ppp) a cómo debería verse en una pantalla normal (96 ppp) o la del portátil (112 ppp) [2]. Vamos, Altura = 320 x 96 / 163, lo que da unos 188 píxeles de alto. Reescalar la imagen y comprobar si el botón ha quedado de un tamaño adecuado para pulsar con el dedo gordo —yo lo tengo muy gordo— poniéndolo directamente sobre nuestra pantalla y si los gráficos originales quedan mínimamente distinguibles. Así es como queda el resultado a la escala de la pantalla del iPhone, dependiendo de la densidad de puntos de tu propio monitor, claro:


Hombre, yo no sé ustedes, pero si bien los botones quedan a un tamaño más o menos prudencial en la pantalla, el protagonista resulta prácticamente indistinguible. Iba a tocar reescalar todo y buscar la forma de que todo encajase en pantalla. En última instancia se trataba de una prueba de concepto y tampoco tenían que ser las mismas pantallas. Bastaba con que el personaje se pudiese mover por algunas plataformas y saltase, controlar las colisiones con algún enemigo tonto y poco más. Vamos, hacer un mix de Abu Simbel Profanation y Mario Bros. Visto lo cual, me puse a rehacer los gráficos. Tuve una especie de deja-vu porque esto mismo hice, de forma algo más cutre, en octavo de EGB pasando los sprites a hojas de cuadraditos para calcular los códigos binarios de cada uno de los bytes que componían el gráfico de 16x16 bits, pero ahora capturando pantalla y reescalando el bicho a 32x32. Vamos, un curro. Y se suponía que la intención era no perder tiempo con esto.

Entonces pensé que tal vez no tendría que hacerlo. Hace años tuve la oportunidad de jugar a un remake que tropecé por casualidad en la zona de ramakes de Computer Emuzone, en la de Remakes Zone o en alguna similar. Estaba hecho en Java y la verdad que era algo simplón en gráficos, pero resultón. Para mí más que suficiente. Busqué y enseguida lo encontré. Y no sólo ese. El autor ha hecho otra versión bastante mejor y que, además, también está para Mac. Aún mejor, se puede descargar el código fuente desde su página Web. Pero aún queda lo mejor de lo mejor: ¡¡¡Viene con los gráficos!!!

Si son nostálgicos de los juegos de 8 bits, en la página de M.A. Software podrán encontrar algunas cosas muy interesantes. Este hombre es un crac.

A base de rapiñar los gráficos de Miguel Ángel, ya tenía resuelto el segundo asunto en orden de complejidad. Aunque bueno, todo todo no lo he rapiñado. También quise aportar mi granito de arena en el apartado gráfico y añadí la secuencia de una muerte bastante truculenta.


Tocaba ponerse a aprender XNA.

¡Ya sé XNA! Al menos los cuatro conceptos básicos

En Internet hay muchísima documentación sobre XNA, suficiente para aprender, pero yo me fui directo a la bibliografía. En mi caso recurrí a un libro que me ha parecido muy entretenido y bien escrito: 'Beginning XNA 3.0 Game Programming' [3]. Tras una lectura rapidísima de los capítulos dedicados a la programación en 2D (de momento no me interesa la parte en 3D), puedo concluir que XNA es muy sencillo de aprender y que tiene cuatro conceptos básicos que comprender: la clase SpriteBatch, heredar de GameComponent —mejor aún de DrawableGameComponent— y los métodos Update ( GameTime gameTime ) y Draw ( GameTime gameTime ). Con estas tres ideas, y cargando las imágenes en clases Texture2D uno ya se puede meter a hacer algo que resulte interesante.

Aunque sea por el placer de escribir tres líneas de código, recomiendo a todo el que tenga curiosidad que intente mover un sprite por la pantalla. De ahí a conseguir un hit en Xbox 360 no hay nada. Y confieso que me ha sorprendido la facilidad con que se aprenden los antes mencionados conceptos básicos y lo fácil que es leer el código C# que hay de ejemplo por todas partes.

Yo tardé un día en leerme los cuatro primeros capítulos, los dedicados al 2D, y sentarme a escribir código con más o menos seguridad sobre lo que estaba haciendo.

Manos a la obra. ¡Qué divertido!

Como usuario de Mac, y sin querer recurrir para este caso a la máquina virtual que siempre tengo con Windows, mi intención era hacerlo todo con software que se ejecutase de forma nativa en mi máquina. Para ello basta con descargar Xcode con el SDK de iPhone [4], instalarse la última versión de Mono para Mac, hacerse con la versión demo de MonoTouch, instalar MonoDevelop y bajarse la última versión de MonoGame, antes conocido como XNATouch. En mi caso me lancé directamente a usar la versión del repositorio, la 1.6, ya que en ésta los espacios de nombre son los mismos que los del XNA original: Microsoft.XNA.Framework.

Repito que tras la experiencia con el apartado gráfico, la idea final era hacer una especie de Mario Bros usando los gráficos del remake Abu Simbel Profanation Deluxe. Pero al resultar tan relativamente sencillo hacer algo con XNA, te acabas enganchando y te dices, «bueno, voy a meterle ahora esto», y así una tras otra. Vamos, que lo que inicialmente había pensado me llevaría tres días, lo acabé convirtiendo en seis o siete días en los que me lo he pasado muy bien haciendo que el machango fuese de un sitio para otro. En dos días ya tenía bastantes cosas hechas, pero lo siguiente era meter sonidos, hacer un scroll de pantalla, meter distintos enemigos con animaciones diferentes, que el muñeco mirase en las diferentes direcciones como hacía el original, etcétera, etcétera.


Pero no era totalmente gratuito este sobre esfuerzo. MonoGame es un producto bastante verde, según lo que se lee en diferentes sitios. Confieso que tenía la creencia de que la cosa haría aguas por todos lados y que la mitad de lo que hiciera no funcionarían. Pero no. Cosa tras cosa que iba metiendo el juego seguía funcionando. Y muy bien, todo sea dicho. Sobre todo porque el código espagueti con el que lo hice dudo que sea el mejor para probar el rendimiento del juego. Si no hice más cosas es porque, precisamente, como no esperaba hacer mucho, la mayoría de las primeras cosas las hice en plan hard coded, como las cuatro pantallas que al final reproduje del juego original. Hay que ver la cantidad de horas que me he metido calculando las coordenadas de cada uno de los bloques que había que pintar en la pantalla.

Por cierto, en la captura aparecen unas áreas rectangulares de colores. Esto se debe a que, ya puestos a meter cosas, también podía superponer las áreas de colisiones para comprobar si todo funcionaba como debía cuando uno se aproxima a un enemigo.

Un pequeño apunte sobre música

Ya como último paso antes de dar por cerrada la prueba de concepto, se me ocurrió meter algo de banda sonora al juego. Los efectos de sonido también se los rapiñé a Abu Simbel Profanation Deluxe, pero me apetecía probar a meter una música de fondo mientras jugaba. Se me ocurrió recurrir a RKO, donde hay cientos de versionados de temas musicales de los juegos del Commodore. Hay algunos muy buenos. Ni corto ni perezoso escuché unos cuantos de los últimos que se habían publicado y me decanté por el tema 'Cauldron II (The Witch Who Stepped in Dub)', de Sound of Hazel (http://www.soundofhazel.com). Le da marchilla a la prueba de concepto. Y, lo mejor, es bastante sencillo dejarla sonando. Tanto como crear una instancia de efecto de sonido e indicarle que se reproduzca en bucle. Pongo algo de código.

public static void PlayMusica ()
{
   musicaInstance = musicaJuego.CreateInstance ();
   musicaInstance.Volume = 0.2f;
   musicaInstance.IsLooped = true;
   musicaInstance.Play ();
}

Reproducir el resto de efectos de sonido es exactamente igual de fácil.

El resultado

Está extendida la creencia de que una imagen vale más que mil palabras. Y que un vídeo más que mil imágenes. Pues por no llevar mucho la contraria, aquí va un pequeño vídeo sobre cómo ha quedado finalmente la prueba de concepto. La chicha tarda un poco en empezar, sean pacientes.



Pero… el simulador no es el dispositivo

Confieso que he quedado gratamente sorprendido por el trabajo de la gente de MonoGame. Me preocupaba el hecho de no conocer nada de XNA y tener que aprender con un producto que, tal vez, fallase más de la cuenta. De hecho, cuando uno descarga el código desde el repositorio del proyecto, la mayoría de las demos que lo acompañan no funcionan. Pese a ello, el proyecto empezándolo desde cero y aplicando las pautas aprendidas en el libro mencionado antes ha funcionado en todo momento.

Sin embargo hay algo que me sigue preocupando. En las pruebas con el simulador, todo funciona perfectamente. Rara vez los frames por segundo bajan de 58, sabiendo que el hardware gráfico del iPhone sólo alcanza los 60 fps. Pero el simulador no es el dispositivo, y algo que funciona perfectamente en el simulador puede ir fatal en el hardware final. Esto supone un riesgo enorme a la hora de adoptar esta tecnología. Pueden significar muchas horas de trabajo tiradas a la basura y/o 400 euros mal invertidos [5] si resulta que desde el principio descubrimos que la cosa no tira. Pero ya se sabe, quien no arriesga no gana. Y tal vez sea mejor perder ese dinero que echar 100 horas en algo que luego no va a funcionar y que seguimos con la incertidumbre hasta que decidamos gastarnos la pasta.

Siguiente paso

Mientras decido si invertir el dinero o no en MonoTouch, ya voy pensando en qué haré a continuación. En la lista el siguiente es Cocos2D. Aunque en teoría lo ideal sería repetir lo mismo que he hecho con MonoGame, la realidad es que no se me apetece —y no voy a repetir de nuevo— lo que he hecho. Supongo que tiraré por algún otro clásico del que haya también gráficos disponibles que poder buitrear. Aunque esta vez espero no dedicar tanto tiempo a pulir pijadas y llenar la prueba con detalles que a la postre son insignificantes en el valor de conjunto. Ya veré. Lo único que sé es que en las últimas dos semanas me lo he pasado genial haciendo esta prueba de concepto.



[1] Si mi memoria no me engaña, y no empiezo a inventarme ya las cosas, leí por primera vez esta idea del «superbloque» en un artículo sobre programación de videojuegos que se publicó en MicroHobby o en MicroManía. Aunque a estas alturas ni estoy seguro de que fuera ese el término ni de que fuera en una de esas revistas. El superbloque vendría a ser lo que hoy se denomina en todas partes como tile (mosaico).
[2] En http://members.ping.de/~sven/dpi.html hay una calculadora que te dice los dpi de tu pantalla en función de la resolución.
[3] Actualmente la versión 4 de XNA deja como obsoletas algunas de las cosas que estaban disponibles en la versión 3. Sin embargo, tanto el proyecto MonoGame como la alternativa ExEn, actualmente en desarrollo privado, no soportan completamente la última versión de XNA.
[4] Para poder probar el código realizado con MonoTouch hay que contar con el simulador que ofrece Apple con el SDK. Para ello es necesario darse de alta en el programa de desarrolladores de Apple (que es gratis) y ya se podrá descargar. Alternativamente, y desde hace poco, también se puede conseguir directamente en la App Store pagando 4€.
[5] En realidad algo menos teniendo en cuenta que sea cual sea la opción que finalmente se elija para hacer un juego (o cualquier otra aplicación de iPhone) será necesario contar con la licencia de programador iOS, que al cambio viene costando unos 80€.

viernes, 25 de marzo de 2011

El blues de los momentos perdidos

Esta es la predecible, y seguramente inevitable, continuación de 'El ABC de los tiempos perdidos'. Entonces no me preocupaba demasiado. Eran unas más que merecidas vacaciones. Pero tras cinco meses en las listas del paro, y con varios rechazos a mi «impecable» curriculum —al menos eso es lo que afirman las personas que llaman para entrevistarme— por cuestiones de idioma, confieso que empiezo a preocuparme ligeramente. Aunque no puedo decir que me angustie aún. Más bien todo lo contrario. En estas últimas tres semanas apenas he pensado en el asunto. El «truco» está en no amargarse demasiado con ello y, lo principal, andar ocupado siempre con algo. A poder ser algo que me llame la atención. Además de seguir siendo optimista. Pesimistas y amargados ya hay muchos en el mundo. Y aún tengo margen de sobre para maniobrar. De hecho hay varios indicadores que apuntan a que acabaré presentándome como freelance. Pero de eso ya hablaré en otro momento.

Dentro del abecedario de intenciones de diciembre, había alguna letra relativa a programación para el iPhone. El desarrollo para terminales móviles es cada vez más demandado. Pero que algo se demande nunca me ha empujado a seguirlo. Tiene que llamarme la atención. Y aquí es dónde debería decir que en los dos últimos años, con la aparición de dispositivos herederos del iPhone, además del propio iPhone, sin dejar de lado el iPad, la programación para terminales móviles se ha convertido en algo que me llama poderosamente la atención. Llevo tiempo queriendo hacer algo para iPhone y presentarlo en la App Store. Tan solo por el placer de hacerlo e intentarlo. Aunque también para ver si doy el pelotazo y me dedico a vivir con Curro en el Caribe. Y tal vez esta última intención ha eclipsado lo anterior y no me he puesto a ello antes. Se me ocurren cientos de ideas a lo largo del día, pero casi todas las voy descartando por parecerme, después de darle unas vueltas, que el esfuerzo no compensa o que ya hay cientos de cosas similares. Así que un día sí y otro también lo voy dejando aparcado en favor de cosas que, para ser franco, tal vez me atraigan menos. Hasta que al final me he dicho que lo interesante en sí no ha de ser el resultado —tal vez los restos incoscientes de la herencia defectuosa de haber trabajado los últimos tres años en una empresa de estricto y cuasidictatorial régimen orientado a resultados, aunque no siempre la calidad con que se consiguen sea la más adecuada—, sino disfrutar en el proceso —la idea original— y, para mí lo más importante siempre, aprender durante el camino. Así que, ni corto ni perezoso, hace unas semanas me levanté a las cuatro y media de la mañana y me senté delante del ordenador a buscar información.

En octubre del año pasado, a poco de haberme comunicado la dirección que tan pronto desmantelase la oficina engrosaría las listas del paro, tuve otro de esos momentos de ponerme a programar un videojuego [1]. Lo de crear un juego es una constante en mi vida. Desde que tengo uso de razón y tuve mi primera videoconsola conectada al televisor. Curiosamente, salvo por alguna cosilla en BASIC para el Spectrum-48-k-teclado-de-goma, de los que me encantaría recuperar las fuentes, y de el Super Kutre Invaders [2], nunca me lo he tomado muy en serio. Hasta ahora. ¿Si lo que me apetece es programar algo para el iPhone, y siempre he querido hacer un juego, porqué no hacer un juego para el iPhone? Totalmente de perogrullo.

A poco que uno se ponga a mirar en Internet los SDK's, API's y entornos de desarrollo para juegos que hay, le puede sobrevenir un colapso mental. De hecho eso es lo que casi me da a mí. Tras cuatro o cinco días intentando elegir qué sería mejor para llevar a cabo alguna de las varias ideas que había estado apuntando en las semanas anteriores, me di cuenta que estaba bloqueado en un claro caso de parálisis por análisis [@ Wikipedia]. Casi desde la mañana hasta la noche encontrando alternativas y revolcándome en el fango de Internet rebuscando información y opiniones sobre cada caso. Y, sobre todo, precios. Agotador.

A continuación un mini-mapa mental de lo que fui encontrando [3]:


Si me hubiese dedicado a investigar y probar cada caso, a estas alturas aún seguiría rompiéndome los cuernos contra la mesa de trabajo. Y estoy seguro que aún hay más por ahí que sería muy interesante. Así que fui tomando decisiones para podar el árbol. Tal vez erróneamente, pero después de mi (¿nula?) experiencia con Unity, opté por dejar en segundo plano los entornos integrados y dedicarme a las API's y SDK's basadas en lenguajes de programación. En última instancia mi intención no es meterme en nada 3D de momento, por lo que buscaba algo que me resultase cómodo para hacer un juego en 2D. Lo que vulgarmente vendría a ser un Indie Game.

Después de muchos quebraderos de cabeza me quedé con cuatro opciones para ir mirando en primera instancia y hacer pruebas de concepto:

  • Cocos2D (Objective-C)
  • Sparrow (Objective-C)
  • MonoGame / ExEn (C# --> MonoTouch)
  • Corona SDK (LUA)

Leyendo la documentación, opiniones, ejemplos y estado de desarrollo, los que me llamaron más la atención fueron Sparrow y Corona SDK, basado en el lenguaje de programación LUA. De hecho, a este último le tengo muchas ganas y encabeza la lista como «muy probable». Sin embargo, dada mi familiaridad con .NET y viendo la bastísima cantidad de documentación existente sobre XNA, he optado por empezar las pruebas de concepto con MonoGame (XNATouch) y, por tanto, con MonoTouch. Después intentaré hacer algo con Cocos2D y Sparrow y, en última instancia, me lanzaré con Corona SDK y el bastante sencillo lenguaje de programación LUA.

Podría resultar curioso que no empiece directamente con los que requieren Objective-C que, además, económicamente son los que menos inversión exigen para poner algo en la App Store. Únicamente se requiere la licencia de desarrollador para iOS; algo que el resto de opciones también requieren y que, además, exigen pago de otras licencias. Llevo un tiempo programando en este lenguaje y —estoy seguro que esto sonará casi blasfemo a los apóstoles del mismo— es que cada vez me gusta menos. Por mucho que me intenten vender su sintaxis revolucionaria, rompedora y todo lo que tú quieras, cada vez me parece más una amalgama de intenciones y modernizaciones a medias. De hecho no descarto saltar a C++. Pero, como todo, es una opinión y habrá quien me corrija en mis palabras. Pero como es mi opinión, y en ella baso mis decisiones, he optado empezar por MonoTouch y usar alguna de las dos alternativas para desarrollar con XNA; sabiendo además que este mismo SDK se usa para desarrollar en PC, XBOX 360 y Windows Phone 7, que con la decisión de Nokia [4] de basar todos sus futuros dispositivos en este sistema operativo, da un buen espaldarazo al parque de móviles que podrían ejecutar el mismo código. Sin olviar que tanto MonoGame como ExEn tiene los ojos puesos en Mono for Android, lo que, en un universo idílico, daría lugar a que lo programas una vez y se podría ejecutar en virtualmente —y vender a— casi todos los dispositivos móviles que hubiera en un futuro no muy lejano.

Hacer un juego es una de las cosas más difíciles que se me ocurre en las que se podría embarcar uno. No tanto por la programación que, además de tener que lidiar con circunstancias particulares (concurrencia, eventos, tiempo real, animaciones, particularidades del hardware, etc., etc), no deja de ser código y, por tanto, aprendible en un tiempo prudencialmente breve para alguien que ya tiene suficiente bagaje. Para mí lo peor de hacer un juego —y uno de los motivos por los que no me haya lanzado antes— está en la componente gráfica. Soy nulísimo en el dibujo y un juego, al menos de forma más o menos generalizada, necesita una muy buena presentación. Por ello, de cara a las pruebas de concepto, me puse a buscar alternativas que no me exigiesen dibujar, al menos no demasiado. Pero eso, mejor, ya lo cuento mañana.

Sin olvidar, entre tanto, que el abecedario de las intenciones tiene más letras y que, visto que es imprescindible el Inglés, he de retomar su estudio lo antes posible. A ver si en unos meses puedo optar a puestos en EEUU (JobCraver). ¿Alguien tiene curiosidad por ver los rangos salariales que se ofrecen al otro lado del Atlántico? Ahora busquen en InfoJobs algún puesto equivalente y, si hay suerte, lo que ofrecen.


[1] La entrada en cuestión es 'Pues sí que está siendo un año de juegos, y algo más (y 2)'. Entonces andaba toqueteando nuevamente Unity 3D (http://unity3d.com/), pero acabé dejándolo (de nuevo) porque el diseño 3D es bastante complicado. Se tarda muchísimo en conseguir una animación interesante. De hecho yo no lo conseguí. Y eso resulta frustrante. Si ya soy rematadamente malo dibujando en 2D, no se pueden ni imaginar en 3D.
[2] En la entrada 'Tesoros perdidos reencontrados (II)' hay un vídeo del Super Kutre Invaders. Por cierto, he vuelto a perder de vista el código fuente. Suerte que se lo pasé a Moisés antes.
[3] A ver si no me equivoco o me dejo alguno fuera.
[4] Uno de tantos artículos que se publicaron en esas fechas, en concreto el 11 de febrero de 2011, en el País: 'Nokia se alía con Microsoft para combatir a Apple y Android'.

jueves, 17 de marzo de 2011

De tajinastes azules

Aprovechando una nueva visita de Sulaco [Distorsiones], nos juntamos Luis, el más-holandés-que-español/canario-a-estas-alturas y el que suscribe, para echarnos unos piscos (o tomarnos algo, como se diría en dialecto normalizado) y tirar para el monte a disparar con nuestras respectivas cámaras. Y no necesariamente en ese orden.

Eso sucedía ayer y, como va siendo norma en la vida de esta bitácora, dejo fiel reflejo en la entrada de hoy —de la víspera al pretérito, por filosofar un poco— por aquello de asegurar que, cuando tanto Luis como Sulaco sean ricos y famosos, poder alegar que yo los conocí y estuve con ellos.

Tajinaste azul

En esta ocasión, y aprovechando la época elegida para la visita, nos dejamos guiar por Luis hasta Valsequillo —en realidad Tenteniguada— y adentrarnos por caminos más aptos para cabras —o gente físicamente mejor preparada— que para proto-obesos de vida sedentaria como yo. Decía conocer el camino para adentrarnos en bosques de tajinastes azules [Echium callithyrsum], planta endémica de la isla, que florecen en esta época. En los calentamientos previos, nos deleitó con paisajes de belleza inimaginable. Luis conoce muchos rincones de la isla que la mayoría desconocemos —ya se sabe el dicho aquel de cuchara de palo…—, aunque el trayecto de ida siempre parece más una odisea de búsqueda. De copiloto acompaña siempre la incertidumbre del camino correcto. Pero aún así llegamos bien y dentro del plazo estipulado.

Lo que no estaba tan bien fue el tiempo climatológico. Al que haya estado atento a las noticias locales, aunque no viva aquí, ya sabrá que esta semana hemos batido récord en cuanto a temperaturas mínimas históricas y, aunque el día se aventuraba de mejor talante, finalmente no acompañó del todo. Tampoco podré decir que la cosa fue trágicamente mala. Supimos, o mejor dicho intuimos —aunque seguramente Punset diría que nuestras neuronas ya lo habían decidido diez segundos antes de que nosotros fuéramos conscientes de ello [1]— que la cosa pintaba cada vez peor y que era el momento de retroceder, transformando el ascenso, penoso en mi caso, por un descenso menos agotador, aunque tanto más peligroso por lo embarrado del camino, antes de que las gotillas molestas que caían acabaran convirtiéndose en una lluvia torrencial parecida a la de los días anteriores.

Tajinaste azul

En definitiva, el clima no acompañó y, como corolario a un cielo casi completamente encapotado, némesis de la fotografía colorista que la Naturaleza exige, que el trayecto fue más bien breve. En mi caso, en estas circunstancias, me cuesta mucho apreciar la belleza de un paisaje que, lo siento por sonar tan negativo y desapegado, ya tengo algo visto. Aunque reconozco que resultó entretenido ver una buena cantidad de estas plantas en el estadio final del florecimiento. Pero más entretenida fue la compañía y la conversación. La fotografía pasó hace tiempo a un estadio secundario. Es la excusa perfecta para quedar y ponernos al día del acontecer de nuestras existencias. Cada una de ellas, como lo es el tajinaste azul, particular a su manera.


[1] La referencia viene perfectamente al caso. De camino a recoger a Sulaco acontecía una entrevista radiada al ilustre Eduardo Punset en la que, por mor de su último libro, Excusas para no pensar, uno de los participantes intentaba ponerlo en un aprieto alegando tal determinismo, casi contradictorio con el dogma punsetiano de la plasticidad mental, en esta circunstancia de actuar a la cola de las decisiones que ya habían tomado nuestras neuronas tanto tiempo antes. Por cierto, que en el momento de escribir esto aparece en la caja tonta siendo entrevistado por el casi tan célebre Buenafuente.

miércoles, 2 de marzo de 2011

'La proporción áurea'

En el primer día de la visita a Sevilla [1], tropecé con uno de esos quioscos de prensa que tienen todas las grandes ciudades repartidos por sus aceras. Como en Las Palmas no abundan —de hecho ahora mismo soy incapaz de recordar ninguno—, tropezármelos siempre atrae mi mirada [2]. En esa ocasión inmediatamente identifiqué la palabra «Matemático» —debo tener algún trauma infantil al respecto que antes de darme cuenta ya he leído palabras como «metemáticas», «científico», etcétera, etcétera, etcétera— y me lancé a mirar de qué se trataba con mayor detalle. Mi visita a Sevilla coincidía con el lanzamiento de la serie 'Mundo Matemático' editada por RBA. Sin meditarlo mucho compré allí mismo el primer volumen y, al llegar al hotel, formalicé mi suscripción por Internet. Al poco me llamaban para decirme que por motivos de calidad en la impresión cancelaban la colección hasta nuevo aviso. Meses después se ponían nuevamente en contacto para decirme que relanzaban la colección, por si estaba interesado en reanudarla. Como en aquella primera ocasión, no lo dudé demasiado.

Ahora mismo hará dos años del viaje a Sevilla y en unos meses concluirá el ciclo por el que recibo dos libros cada mes. Decía lo de casi dos años porque es lo que he tardado en leer el primero. No tengo perdón, pero ya he comentado muchas veces por aquí que soy de compra compulsiva en cuanto a libros y que entran en mis estanterías más de los que leo y, posteriormente, salen. Para sufrimiento en silencio de mi infinitamente paciente mujer [Mis ratos en la cocina]. Pero es que yo soy así y qué le vamos a hacer si tonto me han parido. El caso es que no sé a qué problema de impresión se referían. La nueva edición, que ahora lleva en la portada «El mundo es matemático», además de ser de un tamaño menor, sí llevan el nombre del autor de cada libro en el lomo. Tal vez fuera esto, pero el formato del primero me gusta más que los nuevos. Eso sí, tiene mucho margen en las páginas que no deja de ser papel desperdiciado. Por cierto, el papel también parece de mejor calidad en el primer intento. Sospecho que lo que la editorial quería decir era que tenía menor margen de beneficio. Pero no es mi intención discutir sobre el cálculo del beneficio ni de las matemáticas financieras de la editorial.

Esto no es una novela, así que no tengo que controlarme a la hora de hablar sobre el argumento para no desvelar parte —y no hay mucho peligro si lo hago—. Aunque tampoco hay mucho que contar que no sea un resumido, y para mí apasionante, viaje por la historia de uno de los miles de afluentes que alimentan las Matemáticas y de las curiosas relaciones que hay entre Naturaleza y Arte, por ejemplo, con el número Φ (fi) [3], denominado así en honor al arquitecto griego Fidias (tal como lo cuenta el propio libro), y también conocido como número de oro o proporción áurea. Incluso dentro de las propias Matemáticas se encuentran relaciones con la proporción áurea dentro de la Geometría —de hecho principalmente con ésta— o los Fractales, por poner algunos ejemplos. De hecho, tal como indica el texto, la relación entre los lados de una tarjeta de crédito, de cualquiera porque todas tienen las mismas dimensiones, dan como resultado el número de oro; se trata de un rectángulo áureo. Pero el número de oro tiene también particularidades casi únicas consigo mismo y relaciones estrechas con una de las sucesiones más famosas de los ejercicios de recursividad en Informática: la Sucesión de Fibonacci [4].

[…] Si alejamos nuestra mirada de los trabajos del hombre y la posamos en la naturaleza que nos rodea, también allí nos espera, enigmática y sonriente, la proporción áurea. El crecimiento de muchos seres vivos sigue las pautas marcadas por ella, e incluso los fractales, unos recién llegados al universo de la ciencia, exhiben propiedades que los vinculan con la divina proporción.

Obviamente es un libro que gustará a aquellos que, de por sí, ya tengan cierto gusto por las Matemáticas. Es mi caso. O de aquellos que, sintiendo gusto por la Historia de la Ciencia, aprecien una suave aproximación a la influencia de un número tan particular en diferentes momentos de la Historia. El recorrido, que huye de profundizar en exceso en aspectos complicados y aburridos que se suelen relacionar con la materia, cuenta buena cantidad de anécdotas y se para a detallar algunos aspectos de la biografía de algunos de los personajes que elevaron a grado de divino el número Φ, o de las particularidades puntuales de algunos aspectos de las curiosas relaciones que tiene con otras doctrinas. Es, en resumen, un libro de lectura amena y recomendada, cuyas apenas ciento cuarenta páginas son buena compañía para cualquiera que, como decía al principio de este párrafo, aprecien en su digna medida los distintos cauces que ha tomado el conocimiento humano. O que símplemente tenga curiosidad por saber qué proporciones son las consideradas perfectas en la figura humana, por poner uno de muchos ejemplos.


[1] Hay tres entradas en el blog al respecto. La primera: 'Unos días por Sevilla'. Las otras dos entradas son 'Sevilla. Dormir y comer' y 'Sevilla en números'.
[2] Hay una cosa que me encanta de las ciudades culturalmente avanzadas. Al menos las que yo he visitado, que son muy pocas. En todas hay muchos quioscos de prensa en la calle. Disfruto del hecho de pasear por la zona centro de Madrid, sobretodo por Gran Vía, y ver cada dos por tres un quiosco repleto de revistas y periódicos. Siempre son los mismos periódicos y las mismas revistas, pero siempre me quedo mirando a ver si hay alguna cosa distinta al que acabo de dejar atrás.
[3] En la entrada de la Wikipedia relativa al número áureo, http://es.wikipedia.org/wiki/Número_áureo, hay un buen resumen de todo lo que se pueda relacionar de diferentes ramas de conocimiento con la proporción áurea.
[4] En particular en Algoritmia, cuando se introduce el concepto de función recursiva, al final acaba uno implementando el cálculo del factorial de cualquier número y el cálculo de cualquier término de la Sucesión de Fibonacci (http://es.wikipedia.org/wiki/Sucesión_de_Fibonacci).