Internal Beeper


Aprender a jugar
abril 29, 2005, 12:18 am
Filed under: Quejas

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
abril 28, 2005, 1:08 am
Filed under: Juegos

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.

ringofred1.jpg
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.

ringofred2.jpg
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).

ringofred3.jpg
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.

ringofred4.jpg
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?
abril 27, 2005, 1:55 am
Filed under: Divagaciones

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
abril 26, 2005, 1:03 am
Filed under: Juegos

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.

robotwarlords_screen001.jpg

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.

robotwarlords_screen003.jpg

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…

robotwarlords_screen006.jpg

¡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)
abril 25, 2005, 2:42 am
Filed under: Divagaciones

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
abril 23, 2005, 1:44 am
Filed under: Oldies Computadoras

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.

psycho1.png

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.

psycho2.png

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.

psycho3.png

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)
abril 22, 2005, 12:05 am
Filed under: Informtica variada

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.