Extra Life!

Aprender a jugar

Una de las variaciones más importantes en los juegos actuales, cuando los comparamos con los antiguos, son los tutoriales. Es casi imposible encontrar, actualmente, algún juego que prescinda de esto.

Y hay tutoriales realmente molestos. Sobretodos aquellos que, siendo completamente obligatorios, te enseñan hasta a avanzar. Cuando jugué por primera vez al Halo y, con la excusa de “calibrar el traje” (¿que demonios es eso de calibrar el traje?), me obligaba a mirar a determinadas lucecitas, a moverme hacia adelante y atrás, a recargar mi armadura, dejarme tocar y volverla a recargar... de verdad, que estaba pensando “Dame de una vez la jodida ametralladora y vamos a comprobar si tu traje también está calibrado”.

Generalmente utilizan una excusa de lo más tonta. Para evitar poner las instrucciones o la configuración de las teclas, de forma genérica, en pantalla, la moda está en intentar modificar la trama para añadir las instrucciones. Los Final Fantasy, desde la época de la PS1, empiezan con el personaje entrenando o acompañado de “mayores”, que te van diciendo todo lo que debes hacer. Atrás quedó la época de los antiguos Final Fantasy u otros juegos de rol donde, generalmente, te metían en medio del barullo y apáñatelas como puedas.

A mi nadie me enseñó a jugar al Ikari Warriors. O al Gun Fright. Ni ningún tutorial te decía, en el Eye of Beholder o el Dungeon Master, que tenía que apretar los iconos de las manos de los personajes para atacar. Cuando empezaba, en el Doom 2, con un enemigo delante (y una sierra mecánica detrás), no había ningún tutorial que explicara como moverse y que, para disparar al enemigo, debía apretar CTRL.

Yo entiendo los tutoriales como algo útil en muchos juegos. De estrategia, o incluso de rol, si son suficientemente complicados. Eso sí, con la opción de escoger el tutorial o ir directamente al grano. O, como hace el Star Ocean 3, una sala de tutorial donde puedes entrar o pasar de ella.

Pero si no necesité ningún tutorial para jugar al Zombie (aventura semi-conversacional rara y con un interface más horroroso que los enemigos) no voy a necesitar ir mirando las lucecitas y bailar la lambada para jugar al Halo.

Ring of Red

Hace un par de posts nombraba un juego, de la primera tanda de la PS2, llamado Ring of Red. Un juego de Mechtons, pero que desborda en originalidad.

Para empezar, los Mechtons no son futuristas. El juego transcurre en una alargada segunda guerra mundial, en los años 60. La bomba nuclear nunca estalló. Y Japón está dividida en dos bandos. La República de Japón, gobernada por los rusos y la Democracia de Japón, de la que formamos parte y que, para ser políticamente incorrectos, está apoyada por lo alemanes.

Matarlos a todos o ocupar la base. Una misión standar

Los robots en cuestión son, por lo tanto, máquinas clásicas, más steampunk que futuristas, más tanques con patas que clones de Evangelion. Además de requerir un pelotón completo para su funcionamiento (los proyectiles se cargan a la antigua usanza), cuentan con una autonomía de sólo 90 segundos.

El juego transcurre, como la mayoría de Tactics-RPG nipones, en un mapeado cuadriculado, donde moveremos nuestras unidades (que, a diferencia de los juegos de estricta estrategia, son personajes que van subiendo de nivel) con un objetivo concreto para poder superar la misión.

Pero lo bueno (y lo malo) del juego son los combates. Se reducen a un duelo de 90 segundos entre esas moles metálicas. Cuando finaliza ese tiempo se acaba la lucha, y hasta el siguiente turno a no ser que haya más combates.

Otras formas de acabar el combate puede ser la retirada o el acercamiento. En el primer caso, evitaremos el combate. En el segundo, propinaremos un ataque de cuerpo a cuerpo a nuestro adversario (en caso que nuestra máquina tenga capacidad para ello) o algún ataque especial, y acabará el combate.

Apuntando, el eterno dilema de esperar un poquito más (y arriesgarse a que el contrario dispare antes) o disparar ahora (y arriesgarse a fallar)

Quien ataca a quien tiene, aunque no lo parezca, gran importancia. La distancia inicial del ataque depende de la posición de los robots en el mapa (y, por lo tanto, del que ataca), y los mechs tienen una funcionalidad muy específica. Un mech especializado en la lucha de lejos hará mucho menos daño, y tendrá mucha menos puntería, cuando está cerca de su adversario. Un mech especializado en distancia media perderá efectividad si se está muy cerca o muy lejos, y un mech de distancia corta, a pesar de no tener casi capacidad de ataque a larga distancia, es muy poderoso en la corta, y si llega a acercarse lo suficiente suele ser capaz de hacer ataques cuerpo a cuerpo demoledores.

Además de nuestras máquinas, tendremos tres tropas de soldados, una encima del mech (de la cual dependerán algunas características como la rapidez de recarga) y otras dos de apoyo, que podremos mover delante del tanque (para atacar o utilizar habilidades especiales) o detrás (para evitar ser dañadas o utilizar habilidades de apoyo).

Francotiradores. Aunque utilicen pistola, son ideales para las largas distancias

El combate es, pues, en semi-tiempo real. Podemos pausar en cualquier momento para mover tropas o realizar los ataques, pero tendremos que ir controlando el tiempo (para apurar hasta el último segundo a la hora de atacar, ya que cuanto más tiempo estemos apuntando, más alto será nuestra puntería) y la distancia (para distanciarnos o acercarnos al contrario, dependiendo del tipo de mech que llevemos).

Importantísimo elegir cuidadosamente las tropas de soporte que llevaremos en cada tanque (iremos consiguiendo nuevas en cada pueblo que "conquistemos"), ya que tienen habilidades muy limitadas. Las bengalas serán indispensables por la noche, para iluminar al contrario y evitar penalizaciones por oscuridad, o los cables o minas impedirán que el contrario se acerque demasiado. La artillería pesada, con bazocas o granadas, nos ayudarán si nuestro mech tiene pobre potencia de fuego, la infantería será vital en distancias cortas, y los francotiradores perfectos si pretendemos mantenernos en distancias largas.

La estrategia de este juego es magistral. A pesar de tener cierto componente de "tiempo real", hay mucha más estrategia, no ya en tablero, sino dentro del combate, que en ningún otro juego parecido.

Como podeis comprobar, estos mechtons no son precisamente Mazinger Z, sino una mole de chatarra lenta y que necesita media docena de técnicos para hacerla funcionar

El único problema es que, si estamos acostumbrados a los juegos tácticos donde el combate se soluciona en una animación de 10 segundos, tener que destinar unos cinco minutos (sí, 90 de "tiempo real", pero debemos añadir todas las animaciones, momentos en pausa eligiendo los ataques o moviendo las tropas, preparaciones antes de batalla, etc) hacen que cada misión pueda durar unas 3 o 4 horas (en vez de la media hora a la que estamos acostumbrados por otros juegos del estilo). Algo que requiere de un jugador muy paciente.

Un juego recomendadísimo a los fanáticos de los RPGs tácticos, siempre y cuando sepan tomarse las cosas con mucha calma. Pasarse 4 horas jugando para después darse cuenta que has gastado demasiado tiempo con rencillas estúpidas y no has conseguido acabar la misión en los turnos requeridos puede elevar la tensión por encima de lo saludable.

¿Hasta cuando seremos compatibles?

Una de las ventajas que tienen actualmente los usuarios de las consolas (al menos, de algunas) es la compatibilidad con los juegos de las anteriores consolas.

Eso es algo que nunca había ocurrido anteriormente (al menos no de una forma tan constante), y debemos dar gracias al formato CD-DVD.

Anteriormente, una nueva consola implicaba abandonar por completo el catálogo de la anterior. Lo cual, todo sea dicho, es algo muy doloroso para los que se han gastado bastante dinero en su momento. Sí, uno sigue poseyendo la consola antigua, pero es bastante engorroso tener más de una consola conectada al televisor e ir cambiando.

Uno de los grandes éxitos de la PS2 fue garantizar la compatibilidad de los juegos de la PS1. Y parece bastante evidente que la PS3 va a garantizar la compatibilidad de los juegos de la PS2 y, se supone, también de PS1. Nada debería impedirlo ya que la PS3 tendrá que ser capaz de reproducir DVD's de películas y CD's de música.

Que la PS3 fuera capaz de leer dichos formatos pero no reproduciera los juegos de las PlayStations anteriores sería una auténtico handicap en el terreno comercial.

Pero... ¿que ocurrirá con la PS4? Sí, es cierto que probablemente queden un mínimo de 5 años, si no más, para la aparición de dicha consola. Pero el aparente estancamiento en los formatos audiovisuales, tanto el CD como el DVD (sobretodo este último), inducen a sospechar que la PS4 tendrá también un soporte óptico (que quizás no sea un DVD convencional, pero será capaz de leerlos, así como muy probablemente los CDs).

Eso nos llevaría a un grado de compatibilidad increiblemente largo para una consola, permitiéndonos jugar a juegos realizados 15 años atrás. ¿Hasta cuando durará eso? ¿PS5? ¿PS8?

Nadie es capaz de prever lo que ocurrirá por ese entonces. Quizás para esas consolas ni siquiera se compraran los juegos de forma física, sino que los descargaremos directamente a nuestra máquina, siendo capaces de almacenar miles de juegos sin tener que llenar ninguna estantería. Pero incluso en ese caso, la primera consola que utilizara un sistema parecido debería ser compatible con la consola anterior, por lo que seguiría disponiendo de dispositivos de lectura.

Pero la tónica está aquí. La compatibilidad de sistemas antiguos. Parece impensable que compañías como Sony se atrevan, en algún momento, a hacer una consola que no sea completamente compatible con el sistema anterior. Quizás se han acabado para siempre eso de guardar los juegos antiguos en una caja junto a la consola antigua. Quien sabe. Pero, como la PS3 sea capaz de leer los discos de la PSP (algo bastante pausible), será la indicación que vamos por buen camino.

Realismo y diversión

Hay cierta tendencia a creer que un mayor realismo implica un mejor juego. Pero, claro, el término "mejor" es algo bastante relativo. Lo que sí que puedo dar por sentado es que un mayor realismo no implica necesariamente un juego más adictivo.

Situémonos. PS2. Robot Warlords. Con permiso del fabuloso (aunque injustamente incomprendido) Ring of Red, el juego de estrategia con Mechtons más realista nunca realizado.

Eso sí. Fui capaz, a duras penas, de acabar la primera misión antes de decidir que había tirado el dinero. Y yo aún he sido insistente. Otras dos personas que conozco, que también compraron el juego, fueron incapaces de completar el primer combate. Y no precisamente por difícil, sino por excesivamente realista.

El juego, a diferencia de cualquier otro juego por el estilo (como podría ser la saga Front Mission), es extremadamente realista. Si tu te mueves y estás en el area de visión de los otros Mechtons, evidentemente, vas a sufrir sus ataques, aunque no sea su turno. Si decides acercarte a otro robot para pegarle un puñetazo con un puño de 5 toneladas, no es que por el camino tengas que sufrir los disparos de tu futura víctima, sino también de todos los enemigos que haya cerca.

Eso significa que, en cada movimiento, ves treinta segundos de animaciones de un montón de moles metálicas disparando, sin saber exactamente quien dispara a quien, independientemente del turno de quien sea. Y, aún peor, cuando es tu turno sueles recibir más daño que el que realizas.

Sumémosle otra característica realista. Que estamos hablando de unos armatostes descomunales y algo menos maniobrables que una motocicleta, por lo que si alguien te ataca por el flanco, uno puede necesitar dos turnos para girar lo suficiente como para poder atacarle (suponiendo que el enemigo tenga la gentileza de quedarse quieto). Y ya no hablemos si has avanzado demasiado. Girar 180 grados para realizar una "retirada estratégica" no es una opción. Una vez al descubierto lo mejor es ponerle todos los cojones metálicos al asunto y aguantar lo que se pueda.

Y no es que sea difícil, puesto que lo que vale para tí, vale para el enemigo. Con una buena posición de tus tropas puedes descerranjar una de esas máquinas sin ni siquiera tener que atacar activamente.

Además, como cuando estás quieto tienes mucha mejor puntería que cuando te mueves (aquí, a diferencia de la mayoría de juegos tácticos por turno, no hay movimiento y acción, sino acción en movimiento), todo queda en un no moverse de detrás de las esquinas de los edificios y de los autobuses destrozados, jugando al "venga, ahora me muevo un pasito p'alante, a ver si caes y te acercas".

Todo muy realista. Más o menos como sería una lucha de lentos armatostes de cinco metros de alto combatiendo en la categoría de peso diplodocus. Y aburrido. Muy aburrido. Esa sensación de que no haciendo nada consigues más que haciendo algo. Ese no saber nunca quien está atacando a quien o si estás ganando o perdiendo. Esa sensación de impotencia de tener al enemigo en el cuadrado de al lado pero tener que escaparte, recibiendo tiros en tu trasero metálico, porque él te tiene de cara, pero tu de lado y no puedes girarte en un solo turno...

¡Demonios, que se dejen de tanto realismo y que editen el Front Mission 4 en Europa de una jodida vez!

PD: Sobre lo que comentaba de la manía de poner marcas en los screenshots, me he encontrado algo muy curioso. GameSpot y otra página tienen las mismas imágenes, pero cada una con sus propias marcas. Pero lo más curioso es que estas marcas no son coincidentes, pero los screenshots de una página no tienen la marca de la otra (ni siquiera restos). Así pues, ambas páginas han sacado los pantallazos del mismo sitio... pero las marcan como propias.

Memorias de un programador (2)

Programar para móviles tiene su encanto. Ya lo comenté, hace meses, antes de embarcarme en mi gran aventura por el mundo del j2me, y ahora que lo realizo, "por obligación", debo reiterarlo. Es un encanto.

Pero un encanto con ciertas dosis de masoquismo, todo sea dicho. Programar para un sistema "poco potente", implica tener en la mente, en mayúsculas, Arial 60, negrita, subrallado y lucecitas de neon, la siguiente palabra: LIMITACION.

Vamos a nombrar, de pasada, las limitaciones a las que se ve envuelto un programador de movil:

1.- Limitación de procesador. Lo que significa que, dependiendo de lo que hagas, el juego va a ir a patadas. Si uno no es cauto, y empieza a llenar la parte del código que se va a ejecutar constantemente (por ejemplo, en el repintado, o el trato de eventos) todo va a ir lento. Y la jugabilidad del juego va a bajar hasta el sótano.

2.- Limitación de código. Muchos móviles, o variantes del J2ME imponen un límite del tamaño de los archivos de código. Que no significa que el código fuente sea más corto, sino que el código compilado, debe serlo. Y si el límite es muy pequeño, como en las gamas bajas, uno puede alcanzar ese límite muy fácilmente. Y aquí si que no hay atajos. Si no cabe, no cabe. La única solución es optar siempre por un desarrollo simple. Nada de grandes árboles de inteligencia artificial para los enemigos. Si puedes, no hacer lo mismo, pero "simularlo" con muchos menos código, hazlo.

3.- Limitación de datos. Como si no hubiera suficiente con la limitación de código, a un movil no se le pueden poner los datos que a uno le de la gana. Cinco midis chusqueros, unas cuantas imágenes a pantalla completa y el movil se va a declarar en vaga.

4.- Limitación de memoria. La cantidad de cosas que un movil puede poner en memoria es, para variar, limitada. Muy limitada dependiendo de los modelos. Lo que implica que, aunque tu tengas una gran variedad de gráficos disponibles (o datos, en general), no vas a poder tenerlos todos cargados a la vez. Pero, claro, el movil no va a ponerse a cargar los datos cada vez que el protagonista del juego, por ejemplo, salta. Todas las variaciones gráficas posibles en un nivel deben estar en la memoria a la vez. Y eso implica todas las animaciones posibles de todos los personajes que intervienen en ese nivel, amén de todos los gráficos adicionales. Eso significa saber reaprovechar animaciones y nombrar a los familiares del diseñador del nivel, que ha creído que la variedad de enemigos hará el juego menos monótono.

5.- Limitaciones de soporte. El soporte del juego (es decir, el movil en concreto) puede tener otras limitaciones adicionales que están allá con el único objetivo de hacer la vida imposible a cualquiera que haga aplicaciones para ese movil. Puede ser la imposibilidad de hacer sonar más de un sonido a la vez, o el de apretar dos teclas simultaneamente (eso será la norma para casi qualquier móvil) o a veces cosas tan divertidas como la imposibilidad de tener más de X imágenes cargadas en memoria (independientemente del tamaño de las imágenes) o rutinas que no se pueden aplicar o no existen (por ejemplo, dibujar un círculo de un radio determinado, o calcular un coseno).

Si programar juegos para PC lo comparamos con escribir una novela, programar juegos para un dispositivo concreto, especialmente para uno limitado, es como escribir una novela, pero sin utilizar nombres propios, las letra V, J y U, verbos en subjuntivo y parágrafos que pasen de los 200 caracteres.

Pero, eso sí, mola lo que no tiene nombre.

Psycho Pig UXB

El juego definitivo para dos personas en el CPC.

Seguramente muchos veteranos de esa época discreparan conmigo. Dirán que nada como los partidillos del Kick Off, o la incansable búsqueda del Gauntlet. Pero no conseguirán hacerme cambiar de opinión. Cuando hablamos de diversión por diversión, sin añadidos, el Psycho Pig UXB era insuperable.

Una breve explicación de la trama: Eramos uno o dos cerdos. Literalmente hablando. Y realizábamos un torneo oficial (con árbitro incluido, que iba reponiendo el material) de lanzamiento de bombas. Cuando acabábamos con los demás cerdos, tirando bombas, pasábamos de fase.

Así de simple. Pero el juego era tan increiblemente divertido (sobretodo en dos jugadores) a pesar de su sencillez, que era la opción escogida cuando lo que queríamos era pasar un cuarto de hora de risas y frenesí.

No es que sea un gran juego. Este tipo de juegos pueden ser, o una auténtica bazofia, o el disco más rallado de tanto usarlo, con absoluta facilidad. Dependiendo en gran parte de la conexión de los jugadores. Y a mi, francamente, me encantó. Las musiquillas cómicas y las graciosas presentaciones de los cerdos adversarios a cada nivel resumían todo el juego incluso antes de haberlo jugado. Y los movimientos, así como los "bonus" que aparecían en medio del campo de batalla, como "speed ups", bombas estrella (que hacían explotar todas las bombas de la pantalla) o unos curiosos trajes de pingüino que nos proporcionaban cierta invulnerabilidad, hacían que jugar fuera algo hilarante.

Evidentemente, en el modo dos jugadores, se iba imponiendo una escala de violencia gratuita "Ay, no quería tirarte esa bomba, es que el CPC no me ha pillado bien la diagonal" "Uy, si te he dado. Vaya rebote más tonto que ha pegado esa bomba, ¿no?" que al final uno olvidaba el objetivo del juego y se liaba a bombardear a diestro y siniestro al otro jugador, primero disimuladamente, y después con todo el descaro del mundo, entre codazos.

Y poco más hay que comentar. Un bonus bastante típico cada tres o cuatro niveles y unos contrincantes que, al final, de un color rosa fosforescente, resistian cinco o seis bombazos, se movían al límite de la vista humana y lanzaban unas bombas que, de tanto rebotar en la pantalla, parecían de goma.

Un juego, quizás, del montón, y que seguramente no recibió demasiados elogios por parte de la prensa especializada de entonces pero que, en mi opinión, consiguió dislumbrar, como pocos, lo que es jugar "a dobles" en estado puro.

Memorias de un programador (1)

A mi, como programador, me encanta toquetear el código ajeno. Mucho más que generar código desde cero.

Hay que destacar que utilizar código ajeno, ya sea ampliándolo, o simplemente examinándolo, es algo vital para un programador. Pretender programar sin aprender antes a "leer" el código de los demás es como pretender ser un novelista sin haberse empachado de novelas.

A igual que en el caso de la lectura, estudiar el código ajeno sirve para aprender a programar de una forma mucho más efectiva que empezando de cero e ir recurriendo a la consulta constante del API, y es mucho menos tedioso que ir siguiendo un tutorial que, al fin y al cabo, es como ir a New York en visita guiada. Acabas viendo un poquito de todo, pero no puedes salirte del grupo a riesgo de perderte.

Yo tengo la mala costumbre de imprimir los códigos. Configuración de papel horizontal, Times New Roman a 8, tres columnas, numeración automática de página, y reduciendo los márgenes todo lo que permita la impresora. Un bolígrafo rojo, una taza llena de un café larguísimo con doble o triple carga, e ir picando fragmentos de código como quien va salteando entre canapés en un catering.

He aprendido mucho más MIDP mirando el código de un par de juegos, que siguiendo cinco tutoriales distintos. Ahora que estoy trabajando en el tema, y estoy encadenado durante ocho horas delante de código ajeno, estoy aprendiendo una barbaridad.

Y puedo afirmarlo objetivamente:

Un programador inexperto, cuando lee un código, suele pensar: "¿Que está haciendo aquí?" mientras se mira el código una y otra vez, esperando que las lineas de código cambien a algo que se entienda.

Un programador experto, cuando lee un código, suele decir, en voz alta, e indignado: "¿Pero que demonios está haciendo aquí este pedazo de cenutrio? ¡Haciendo esto, lo único que consigue es darme más trabajo A MI!"

Ultimamente, estoy experimentando más de lo segundo que de lo primero.

UI! Exception!

Siento mucho esta falta de actualización (bueno, dos días, tampoco es el fin del mundo).

Me paso más de 8 horas programando en el curro.
Cuando salgo, suelo ir a la facultad a hacer alguna práctica, ya que he tenido que posponerlas todas a partir de las 6.
Y, cuando llego a casa, me pongo a programar un poco más para ponerme al día, que esto del trabajo ha llegado muy de golpe y tengo que ponerme a buen nivel.

Y, claro, lo que programo en el trabajo lo considero estricto secreto profesional (aunque, curiosamente, no me han comentado nunca que lo fuera).
Lo que programo en las prácticas de la facultad es demasiado aburrido para explicar aquí.
Y lo que programo en casa está muy relacionado con lo del curro, por lo que también lo considero, en su mayoría, secreto profesional.

Así pues, ocupo unas 14 horas al día con cosas de las que no puedo hablar (aunque sea programación de juegos). Y aunque sí tengo tiempo para ponerme a bloguear, no lo tengo para jugar o ponerme a rebuscar "oldies" por internet. Y sin juegos, no hay críticas. En un par de días tendreis un suculento post, no temais.

A no ser que querais una clase sobre las Exception, las IOException o las UIException...

Cafés calientes y videojuegos

Cuando compramos un café en un McDonalds o similar, podemos ver que en la taza pone algo parecido a: "Cuidado, la bebida de esta taza puede estar caliente".

"Eso espero", pienso yo mentalmente. Los cafés se sirven calientes. De hecho, si en el momento de servirme un café, este está frío, exigiré un café caliente. Vaya, es de sentido común que un café se hace mediante agua caliente, no con agua fría.

También es de sentido común que si uno coge una taza y está caliente, es muy probable que su contenido también lo esté. Vamos, de perogrullo.

Pues esta advertencia viene porque, en los USA, una mujer compró un café en un McAuto de esos. Conduciendo, se le cayó el café a las piernas, y se quemó. Denunció al McDonald por no avisarle que el café estaba caliente. Y, como ya sabemos como es la justicia americana, ganó.

Con los videojuegos parece que nadie quiere cometer el mismo error. Me encuentro este mensaje al inicio el Mario Party de GBA, versión americana.

Así pues, voy a ver cuales son estos mensajes tan importantes para mi salud.

El más importante es el de la posibilidad de tener un ataque epiléptico mientras se juega (oh, bueno, la mayoría de manuales de instrucciones también lo comentan). Nos dan una serie de consejos a cumplir aunque nunca hayamos tenido ningún ataque de epilepsia:

1.- Colocarse lejos de la pantalla: Vale. Pero aviso que en el caso de la GameBoy me cuesta bastante jugar cuando me aparto a más de un metro. El palo de escoba no tiene la misma precisión que mis dedos.

2.- Usar el televisor más pequeño que tengamos: Ey, un momento. Me están vendiendo que si unos gráficos revolucionarios, un refresco de 60 Mhz y una resolución mejorada para televisores de última generacion... ¿y quieren que juegue en el televisor blanco y negro (que ni siquiera tiene euroconector) que tengo en el armario?

3.- Juegue en una habitación bien iluminada: Pero a la vez, juegos como el Silent Hill o el Project Zero recomiendan jugarlos a oscuras...

4.- Descanse unos 15 minutos por hora aunque crea que no lo necesite: No, eso sí que no. Cuando uno va por depende de que fase de depende que arcade, apretar el botón de pausa y esperar pacientemente 15 minutos NO es una opción.

Después viene una serie de consejos que, básicamente te dice que, si te duelen los brazos de tanto jugar, mejor que descanses un poco.

Yo estoy convencido que lo próximo será poner mensajes en las películas (sobretodo teniendo en cuenta que cada vez son más largas), al estilo: No pretenda ver esta película entera. Cada hora, pausela y espere 15 minutos. O en la televisión: Mire este canal con la televisión más pequeña que tenga en casa.

Cuando seguimos viendo algunos consejos varios, la situación ya llega a puntos dignos de un show de los Monty Pyton:

- No deje caer la consola Game Boy ni ninguno de sus componentes, ni permita que sufran ningún golpe. Hacerlo podría estropear la consola.

Y, mi favorito:

- Los nudos en los cables son un peligro potencial.

Se han olvidado el: No permita que su gato mordisquee el cable de alimentación...

Modificación de gráficos

Desde que estoy en esto del mundillo de los juegos para móvil, me he dado cuenta de un fenómeno en ascenso.

No me refiero a la piratería de dichos juegos (esto ya hace años que lo conozco) sino a la modificación de gráficos de un juego java.

La mayoría sabreis que un archivo java para móvil tiene extensión jar. Este archivo no es más que una especie de rar, un archivo comprimido en el cual podemos entrar y ver su contenido.

Y, por regla general, la mayoría de dichos juegos java tienen sus archivos gráficos perfectamente visibles y modificables.

Hay gente que dedica su tiempo a coger estos archivos gráficos, con los sprites o fondos de los juegos, y modificarlos. Generalmente utilizando sprites sableados de otros juegos. Es decir, el Rings Fantasy se convierte en Zelda, el Ninja Run se convierte en Mario Kart, etc.

El record lo lleva el Kyushu's Devil, juego de movil de lucha que han reconvertido, cambiando los gráficos, al Final Fight, Kings of Dragon, Megaman... debido a que dicho juego tiene todos los gráficos, sprites, fondos, pantallas de menú, etc, en archivos PNG fácilmente modificables.

No es que yo esté en contra de que la gente se haga sus propios gráficos, pero el problema es que todas estas creaciones, además de generar piratería de estos juegos, hacen que el trabajo original se pierda. Cambian los títulos de crédito, el nombre, y se nombran creadores del juego.

Al fin y al cabo, la piratería es un mal relativamente menor para una compañía de juegos. La reputación de una compañía también es muy importante. Si un juego es bueno, aunque tenga un porcentaje de piratería, la reputación de la compañía sube. Mucha gente optará por comprarse ese juego original, o algún otro juego que lleve el mismo sello. Si, además de piratear un juego, se hace eliminando los nombres de sus creadores originales, la compañía pierde por partida doble.

Pero lo peor del caso no es eso. Lo peor es que si uno se mueve por foros de desarrolladores amateurs de juegos, como GameDev.net, se dará cuenta que hay muchos programadores con ganas de hacer juegos que requieren de grafistas que les hagan los sprites para sus juegos.

Así pues, todos estos grafistas amateurs que se dedican a modificar los juegos ajenos, quizás deberían empezar a colaborar en todos estos proyectos, para realizar un trabajo propio, aunque sea desconocido, antes de sablear el trabajo de los demás, aunque sus juegos sean más descargados.

Elite

Uno de los primeros simuladores espaciales realmente completos fue el Elite. Estamos hablando del 1985, y utilizaba un sistema de 3D completamente poligonal. Con las capacidades de entonces, claro está. Se distribuyó para Spectrum, Commodore, Amiga, PC, NES, etc, etc... practicamente para todos los sistemas existentes por ese entonces.

En el juego, llevábamos al capitán de una nave espacial, en un universo compuesto por varias galaxias, compuesta cada una de ellas por centenares de planetas. Y ni que decir tiene que podíamos ir a cualquiera de esos planetas o incluso cambiar de galaxia.

El juego era completamente libre. Podíamos ir como mercenarios, a ganarnos nuestro sueldo matando piratas esterales (fácilmente reconocibles porque tendían a dispararnos sin más), para ganar unos cuantos créditos. O podíamos asumir el rol de piratas y hacer lo propio, atacar a "relativamente indefensos" mercaderes espaciales con el objetivo de atrapar con nuestros rayos tractores las mercancías que hubieran sobrevivido a la explosión y venderlas.

Aunque, nos dedicáramos a lo uno o a lo otro, no dejaríamos de ejercer el papel de mercaderes, comprando productos baratos en un planeta y vendiéndolo más caros en otro que, por sus características, fuera deficiente en esa materia prima.

Aunque, evidentemente, todos los planetas parecían iguales, el tipo de economía o de gobierno de un planeta variaba considerablemente el precio de sus productos o la seguridad de su navegación. Ni que decir tiene que lo mejor es comprar productos tecnológicos en planetas industriales para venderlos en los paises agricultores, pero tampoco descuidaremos que las dictaduras, pese a no tener tanto crimen (y, por tanto, ser mucho más seguras) no tienen la gran oscilación de precios de los peligrosos regímenes anárquicos, planetas donde uno puede enriquecerse rápidamente si no muere en el intento.

Como es de esperar, deberemos mejorar nuestra naves con células de energía extras, o lasers más potentes, así como accesorios muy útiles como las contramedidas electrónicas o el sistema de autopiloto para poder acceder a las estaciones espaciales de cada planeta sin arriesgarse a estrellarse contra ellas.

En el juego iremos ganandonos una reputación a la par que riquezas, tanto si optamos por no movernos de los planetas cercanos como si nos aventuramos a recorrer la galaxia.

Un gran juego, que tiene un sistema de combate espacial bastante digno, no de grandes batallas, pero sí con escaramuzas contra grupos de tres o cuatro piratas. El efecto del Warp Jump, es decir, el movimiento por encima de la velocidad de la luz, está bastante conseguido, y las naves, a pesar de contar con pocos polígonos, tienen una gran carisma.

El juego fue liberado hace muchos años por su creador, Ian Bell. Que incluso mantiene una página donde encontrareis las instrucciones del juego o muchas de sus versiones.

Aunque su liberalización, además de la gran cantidad de fanáticos de este juego, ha hecho proliferar las versiones del Elite. Existen versiones gratuitas de Elite para GP32, para PocketPC, para GBA, así como gran cantidad de remakes, con gráficos mejorados o incluso misiones para PC.

LucasFan Games

Cuando a mi me pregutan cuales son los tres mejores juegos de la historia, aunque soy consciente que dicha pregunta es imposible de contestar, el Maniac Mansion viene a mi mente.

El Maniac Mansion fue el juego que cambió por completo la forma de ver las aventuras gráficas. Aunque el King's Quest fue pionero en abandonar la rigidez de escenarios de las aventuras conversacionales (aka. Interactive Fiction) para pasar a tener un monigote que se movía por la pantalla, el Maniac Mansion marcó el camino que seguirían las aventuras gráficas. Abandonar definitivamente el teclado.

Pero es que, además, el Maniac Mansion ofrecía algo que nunca antes se había ofrecido y que, para más inri, casi nunca se ofreció después. La posibilidad de utilizar distintos métodos para solucionar los enigmas.

Creo que no exagero si considero que, incluso actualmente, el 90% de los juegos tan solo tienen una forma de solucionar cada cosa. Si la encuentras, bien, si no, se siente.

Sumémosle el hecho que el Maniac Mansion permitía incluso elegir personajes, cada uno con sus habilidades. Como ocurrió con el Prince of Persia, el gran éxito del Maniac Mansion es fruto de tener el valor de enfrentarse a los tópicos de un género y hacer algo completamente revolucionario.

Así pues, entiendo la dedicación y la pasión que ponen los chicos de LucasFan, unos fanáticos de los antiguos juegos de Lucas, que han reprogramado entero el Maniac Mansion, con gráficos ligeramente actualizados. Además, han hecho una miniaventura que continua las andanzas del protagonista de otro juego de LucasArts, Zak McKraken.

Pasaos por su página web, podeis encontrar estos dos juegos en perfectísimo español.

Supervivientes...

Oh, bueno.
He sobrevivido al primer día.

No hacen falta muchas palabras

Ehhh... no espereis ningun review "imparcial" de ningún juego de GameLoft a partir de mañana.

Por cierto, ¿os he comentado que, en su página oficial, se pueden comprar por 3$, es decir, 2'3 euritos de nada?

No, no soy cubano...

Estava yo registrándome en una página para desarrolladores de BREW, que es una herramienta para hacer juegos 3D en java.

Y eso que, tras ir rellenando todo el típico cuestionario para registrarse en una página, me encuentro, al final de todo, un texto. En un principio creía que sería el típico diciendo que sí, que soy mayor de edad, que me envien todo el spam del mundo, etc... (es decir, lo típico). Pero, una vez me puse a leerlo, me encontré con esto:

I am not a citizen or a resident of, or under the control of a government of the following restricted and embargoed destinations: Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria, nor will I export or re-export the software to such countries or other countries which the United States has prohibited exports and re-exports.

Finalizó mi periodo no-sabático

Bueno, ahora mismo acabo de completar y enviar el proyecto que tenía entre manos y que he utilizado como excusa para descuidar mi posteo diario.

Así pues, ya podeis pegarme de collejas virtuales si a partir de ahora falto al posteo de rigor, no sea que me acostumbre a eso de saltármelos.

Prince of Persia, unas cuantas generaciones por delante

Ya hacía demasiado que se echaba en falta comentar este juego, el Prince of Persia 1.

El Prince of Persia 1 tuvo su gran éxito a un hecho concreto. Que estaba, no ya una generación por delante de cualquier otro plataformas de la época, sino tres o cuatro generaciones.

Un juego suele destacar cuando ofrece algo más que sus competidores. Cuando es lo mismo, pero con un par de detalles novedosos, el juego ya es un éxito. Pero el Prince of Persia ofrecía tantas cosas que no tenían los demás juegos que fundó (aunque no nos diéramos cuenta) un nuevo estilo de juegos. El juego de plataformas (o, incluso arcade) realista.

Porque es lo que vendía el Prince of Persia. Realismo. Muchísimo realismo. Y no me estoy refiriendo a los gráficos o el sonido, que destacaban en la época (sobretodo por la descomunal cantidad de animaciones), sino por su "estilo de juego". Podemos afirmar que, de no haber aparecido el Prince of Persia, no simplemente no hubieran aparecido juegos como Another World o FlashBack, sino que sagas como la Tomb Raider hubieran tardado mucho más en idearse.

Lo más curioso es que el Prince of Persia no era un producto demasiado difícil de programar. La gran dificultad era llevar la contraria a una mentalidad demasiado cerril sobre los juegos de plataformas.

Dicha mentalidad se resumía (y, ojo, se sigue resumiendo) en dos premisas: Pies poderosos y un sistema de medida basado en el PIXEL.

Lo del pixel es muy claro. Los antiguos plataformas (Jet Set Willy, Manic Miner) se basaban en el píxel. Uno debía saltar en el píxel correcto (es decir, en el punto concreto de la pantalla), para llegar a la siguiente. Si saltas un pixel antes, aterrizarás un pixel antes (y, en muchos juegos clásicos, con fatales consecuencias).

El Prince of Persia no usaba un sistema de píxeles, sino de baldosas. Si uno apretaba saltar, estubiera donde estubiera de la baldosa, el protagonista se situaba al límite de la baldosa, y saltaba. Si ibas corriendo, el protagonista corría hasta el final de la siguiente baldosa, y saltaba.

Mucha gente no se daba cuenta de ese cambio, pero gran parte de la jugabilidad del Prince of Persia venía de ahí.

La otra regla básica, la de las piernas poderosas, también era rota por el juego. Los anteriores plataformas tenían varias diferencias en la forma de jugar. Algunos tenían grandes saltos, sobretodo cuando corrías. Otros tenían un salto más pequeño, más "realista". Pero algo estaba claro. Si no ponías las patas en la siguiente plataforma, caías.

El uso de las manos, para agarrarse, abría una nueva dimensión. Lo hacía mucho más realista y, sobretodo, más épico.

Sí. He dicho épico. Uno podía dejarse los dedos intentando saltar al límite de la plataforma en el Cauldron, pero cuando veías al príncipe agarrarse con las manos en una plataforma, balanceándose peligrosamente, parecía un esfuerzo mayor (aunque no requiriera saltar en el último píxel).

Pero el Prince of Persia no solo rompió con las férreas reglas de los plataformas de entonces. Si el juego se adelantó, no una, sino varias generaciones, fue porque todo el juego en sí era realista. Jordan Mechner (porque lo menos que se merece es que se nombre en el artículo) cuidó todo tipo de detalles en su juego, en su esfuerzo para diferenciarlo de los plataformas convencionales. Por nombrar solo algunas de sus diferencias.

Rompía el sistema de vidas grabado en fuego por este estilo de juegos. Si morías, comenzabas el nivel (o la zona) de nuevo, sin perder nada más que unos minutos. Hecho que era importante ya que tenías un tiempo muy limitado (una hora en tiempo real) para completarlo.

Aunque el escenario no era realista (el martirio que puede pasar un guardia en el último nivel de la prisión para volver a su casa, una vez finalizado su turno), la interacción con ella sí lo era. Si pasábamos corriendo por las trampas de pincho (o caíamos en ellas) moríamos sin remedio. En cambio, si pasábamos caminando, como es normal, pasábamos entre los pinchos sin sufrir ningún daño. En los plataformas de toda la vida (y actualmente, en casi todos), los pinchos, son pinchos.

Otros detalles. Algunas plataformas en el techo o suelo eran frágiles. Si pasábamos por encima, se caían. Algo normal en los juegos de plataformas. Lo que no era tan normal es que, si saltábamos cerca, las identificábamos porque hacían un ligero movimiento, y si las tocábamos desde abajo con la mano, o levemente con el pie, también caían.

Y un detalle excelente, que también pasó desapercibido a casi todos. Si dejábamos a nuestro príncipe colgado de una repisa, pero apoyado a una pared, podía aguantar el tiempo que hiciera falta (se apoyaría con los pies, se supone). En cambio, si lo hacíamos en una plataforma elevada, sin ningún otro punto de apoyo a parte de las manos, nuestro príncipe oscilaba durante unos segundos, en busca de una apoyo y, si no lo subíamos rápido, le fallaban las manos y se caía.

Si le junta usted un sistema de lucha calcadito al de la esgrima de Defender of the Crown o Pirates!, pero con un movimiento más grácil y un sistema de energía en que se podía ampliar el tope de energía máxima con determinadas pociones, ya nos hemos adelantado, como mínimo, cinco años a los juegos de entonces.

Y, de verdad, no porque el Prince of Persia fuera una gran maravilla técnica, sino porque la cerradez de miras del género habían dejado un enorme vacío que esperaba que alguien desafiara las reglas no escritas de los juegos de plataformas.

Cojan el DOSBox y el Prince of Persia original. Tan sólo van a gastar una hora de su tiempo. Y, realmente, y sobretodo si nunca han jugado al Prince of Persia original, no será una hora malgastada.

PostData especial para los que vienen desde Mondo Pixel. Esto es, guardándome toda la modestia en el frigorífico para utilizarla otro día, un buen review de un juego clásico. Sin tener que recurrir a las puntuaciones o al tecnicismo del Old Game Journalism, ni a la información sesgada, partidista, y que poco aporta del New Game Journalism (el link lleva a un review del Prince of Persia hecha por el responsable del NGJ Manifesto)

¿Donde están los recopilatorios?

Existe un limbo en esto de los remakes de juegos antiguos. Un limbo que va desde mediados de los 80 a la actualidad.

Las consolas como GameCube o PlayStation 2 no tienen prácticamente ningún material clásico que pase de esa época.

Que sí, que algunas compañías, como Midway o Activision, se lían a hacer remakes de juegos de principios de los 80. Pero yo me pregunto... ¿y la SNES? ¿y la MegaDrive? ¿y la PSX?

Estoy convencido que no seríamos pocos los que nos compraríamos un pack con los mejores RPGs de SuperNintendo, si saliera para PS2 o GameCube.

O, algo que siempre me ha extrañado... ¿Porqué Square nunca ha pensado en sacar para PS2 un recopilatorio de los Final Fantasy VII, VIII y IX? O, ya puestos, compuesto por otros grandes juegos suyos de la PSX, como el Vagrant Story, Chrono Cross, Brave Fencer Mushashi o el Front Mission 3?

Y, aún saliéndonos de los RPGs, existen centenares de grandes juegos de MegaDrive, SNES o PSX, que se han quedado en una especie de limbo.

Algunos pocos de SNES han sido "reeditados" para GBA, con algunas mejoras. Pero nada de recopilatorios: un clásico, un juego nuevo. Y el precio equivalente al de un juego "original".

En cambio, las únicas recopilaciones que existen para las consolas son de juegos antiquísimos, en su gran parte, juegos que han envejecido muy mal. Se pueden aprovechar la mitad de los recopilatorios de Midway (jugar al Smash TV es algo intemporal), pero algunos recopilatorios, como los de Activision o Atari, se convierten en un objeto de culto que importa más el hecho de tenerlo que el hecho de jugarlo.

Yo, mientras tanto, espero pacientemente poder jugar al Secret of Mana, al Chrono Trigger, al Streets of Rage, al Golden Axe, al Wild Arms I, al Front Mission 3...

Como van las cosas...

Bueno, no quiero comentar demasiado el tema, porque creo que la prueba de selección que estoy haciendo es "genérica". Es decir, que todos los que aspiran a entrar deben hacerla, y el que la haga mejor, pasa al siguiente nivel.

Tipo: Java Console Aplication con GUI.

Estado del proyecto: Entre un 10% y 90% (soy incapaz de concretar más, el estado real dependerá de lo que me encalle o deje de encallar).

Problemas actuales: Cierto parpadeo a la hora de repintar los gráficos. O cargo demasiado el repaint(), o tengo que utilizar un método alternativo.

Problemas resueltos con especial elegancia: Sistema de detección y creación de grupos de fichas colindantes en array.

Principales mejoras respecto lo exigido: Utilización de offset gráfico para hacer descender fichas de forma suave.

Páginas más consultadas: java.sun.com

Entorno de trabajo: BlueJ

Me iría de perlas: Disponer de un entorno de trabajo avanzado donde pudiera consultar los parámetros de las funciones mediante F1, o las funciones disponibles clicando con el botón derecho sobre la clase.

Un pequeño parón

Ayer fue el primer día que Extra Life! no tuvo ningún post.
Tengo que realizar un pequeño parón a la actividad normal de este blog.

Actualmente tengo que dedicar mi tiempo a algo que tiene que ver bastante con esta página: Realizar un juego.

Digamos que es un compromiso profesional o, más exactamente, pre-profesional (los que sepan un poco como funciona la búsqueda de empleo en el campo informático y la selección de personal, sabreis un poco por donde van los tiros).

Como entendereis, no puedo adelantar nada más, tan solo deciros que os mantengais a la espera. Es cuestión de solo un par de días. Espero que el lunes ya tenga finalizado todo el asunto.

Deseadme suerte.