Extra Life!

Emulación a lo bruto

Sí, señores, supongo que deben haber relacionado estos días sin posteo con el descubrimiento de un downgrade para el firmware 2.0 de la PSP.

Sé que suena mal el reconocer que llevo unos días sin postear porque me he dedicado a jugar con la consola, pero tengan en cuenta que lo que he hecho en realidad ha sido ampliar y documentarme en todo lo necesario para seguir posteando en este blog.

La scene para PSP es bastante impresionable. Sobretodo en cuestión de emuladores. Existen prácticamente los mismos emuladores que para PC. NES, SNES, MegaDrive, Master System, Atari, Spectrum, Commodore, GameBoy, etc, etc...

La emulación Consola -> PC suele ser bastante efectiva. Más que nada porque la programación en PC está bastante extendida, y su metodología es bastante genérica. Eso por no hablar que un ordenador actual es centenares (o miles) de veces más potente que la máquina que emula.

La emulación Consola -> Consola ya es otro cantar. Realizar una emulación en una consola de otra consola requiere un gran conocimiento de la arquitectura técnica de cada consola. Y no suele ser así.

Si en un año han aparecido tantos emuladores para PSP (y, de hecho, ya habían bastantes tan solo un par de meses después de la aparición de la consola) es porque lo que se ha hecho se resume a adaptar emuladores para otros sistemas.

Es decir, se coge un emulador hecho para PC, con código abierto, y se modifica el código para que se adapte al API (sistema de instrucciones) de la PSP. De hecho, he visto que algún emulador en realidad es una conversión de un emulador de pocketpc que a la vez era una conversión del mismo emulador, realizado para PC. Muchos otros emuladores se basan en la versión de GP32 que, a la vez, se basan en un emulador existente para PC.

Esta emulación "a lo bruto" es lo que hace que una máquina sea incapaz de emular con suficiente velocidad una máquina muchísimo más lenta. Por ejemplo, aunque existe un emulador de SNES para PC, perfecto, no existe ninguna consola capaz de emular SNES con la misma fiabilidad. Ni la GP32 ni la PSP, consolas muchísimo más potentes que la SuperNintendo, son capaces de ejecutar, sin relentizarse o utilizar frameskip y utilizando sonido, ciertos juegos de la última etapa de la SNES, como el ChronoTrigger. Eso sí, la PSP se acerca mucho.

Aún así, una PSP con el firmware 1.5 parece ser, a día de hoy, la mejor opción para emular máquinas antiguas. Al menos hasta la aparición de las sucesoras de la GP32.

Tengo mucho que contaros en este sentido. El Earthbound, el ChronoTrigger, o las excelentes adaptaciones del Prince of Persia o Flashback para SNES. Así pues, permitidme que me vuelva a perder en las inmensidades de mi PSP para poder otorgaros unos cuantos reviews de juegos de SNES y MegaDrive.

La guerra de las consolas

Reproducido de mi colaboración en PeriodistaDigital con fines archivísticos.

---------------

Aquí en España solemos estar siempre al final de la cola cuando hablamos de las novedades tecnológicas, pero en el resto del mundo ya se está produciendo una auténtica guerra entre la Nintendo DS y la Sony PSP. Aquí está a punto de comenzar.

Se ha producido este último año una gran revolución en el mundo de las consolas portátiles, como no se había visto desde la aparición de la GameBoy, en el 87. El gran avance tecnológico, con la incesable tendencia a la miniaturización, ha permitido que los dispositivos portátiles superaran, con mucho, la función de entretenimiento banal, de relativa baja calidad pero gran portabilidad.

Nintendo con su DS y Sony con su PSP, se enfrentan en una gran batalla por el dominio de dicho mercado. De forma tan feroz que no dejan ningún resquicio para intentonas de las demás compañías. Nokia ha fracasado con la NGage, y ni siquiera parece haber lugar para la GP32 o la Gizmondo.

Nintendo, que siempre ha liderado el mercado de las portátiles, ha optado por la renovación. Nuevos sistemas de juego. Pantalla táctil, detección de voz y un sistema de dos pantallas. Sin duda original, pero con tantas ventajas como inconvenientes. Las atípicas características de la consola son una delicia para los creadores de videojuegos, se supera la rigidez de los botones, permitiendo un interface casi tan completo como en un PC.

Pero, por otra parte, la mayoría de juegos son incapaces de aprovechar las características de la DS: juegos de coches que tan solo utilizan la pantalla táctil para moverse por los menús, juegos en los que la doble pantalla sólo sirve para mostrar el mapa. Se pueden realizar juegos hechos específicamente para jugar con la DS, pero muchos otros juegos, por su diseño, no pueden explotar sus características.

Sony, el aspirante al título, compite mediante una táctica conocida, pero siempre eficaz. La potencia bruta. Su consola es completamente típica, pero con una potencia cercana a las actuales consolas de sobremesa, con una calidad que no nos hubiéramos siquiera imaginado tan sólo hace un par de años. Sencillamente espectacular, acompañado de una descomunal pantalla y gran variedad de funciones multimedia. La potencia de la consola es tal que se puede portabilizar prácticamente cualquier juego de las consolas de sobremesa a la PSP. Y no me refiero a hacer una conversión, es decir, un juego de menor calidad pero con un diseño parecido y el mismo título, sino un juego prácticamente idéntico. La PSP hubiera sido la evolución normal del mundo de las consolas si hubiera aparecido dentro de unos años. Pero esto también implica ciertos inconvenientes. El precio, muy superior a la DS, junto con un tamaño excesivamente grande para una cómoda portabilidad, y una batería con menor autonomía que la de la DS, son grandes bazas que quizás su supremacía técnica no podrá compensar.

De momento no parece haber ningún ganador claro, ni ninguna predicción fiable, sobre dicha guerra. Nintendo argumenta mediante sus ventas totales (que son mayores porque apareció antes) y Sony argumenta que ahora vende más que Nintendo (que también es obvio, al aparecer posteriormente). Y no es algo trivial, la supremacía de esta generación de consolas portátiles puede orientar no sólo la consola que prevalezca, sino la filosofía que se seguirá posteriormente en el mundo de las consolas portátiles. Y quizás, de toda la industria del entretenimiento electrónico.

Colisión: Los cuadrados

Algo muy importante en los juegos, especialmente cuando hablamos de antiguos juegos 2D (y vital en los de plataformas), eran las colisiones.

La máquina debía detectar cuando el personaje (no sólo el protagonista, sino todos los personajes móviles) colisionaba con las paredes, con el suelo de las plataformas, los enemigos o las balas.

Ahora hay métodos mucho más complejos, sobretodo cuando extrapolamos esto en el entorno de las 3D, pero entonces se utilizaba la simple técnica del cuadrado. Al personaje se le adjudicaba un “cuadrado” compuesto por unas coordenadas relativas a su posición. Generalmente coincidía con el cuadrado formado por su imagen, para evitar ocupar más memoria con información extra para cada elemento de la pantalla pero, cuando se disponían de suficientes recursos, se procuraba que el cuadrado fuera tan ajustado a la superficie dibujada como fuera posible, a veces utilizando más de un cuadrado asociado al personaje, si este tenía una forma demasiado poco rectangular.

La solución es simple, si dos de estos cuadrados se superponen, hay colisión, y se dispara el efecto adecuado.

Con el escenario, el suelo, plataformas, etc, pasa algo parecido. En realidad existe un doble mapeado, uno que tiene los gráficos que se muestran y otro, generalmente solo de dos colores, que separa las zonas colisionables de las que no. Cuando la zona de colisión toca la zona inferior del personaje, este deja de caer. De la misma forma, el personaje no atravesará paredes ni techos.

Lo más curioso es que muchos de los bugs que se pueden encontrar con los juegos antiguos son debido al mal uso de las zonas de colisión. Cuando un enemigo nos mataba al acercarse mucho, aún sin habernos tocado realmente, era debido a una área de colisión demasiado grande. Cuando no nos mataban a pesar de tocarnos claramente, era debido a una área de colisión demasiado pequeña.

La colisión también podía provocar esos típicos cuelgues al quedar el personaje “atrapado” en el suelo o en una pared. Eso era debido a que el ordenador no había detectado la colisión a tiempo, y el personaje había entrado en la pared. Entonces, por más que nos moviéramos, como detectaba constantemente colisión, no podíamos despegarnos.

Hay un efecto muy curioso en el juego Cauldron, al menos en CPC. Podíamos ponernos en el límite de las plataformas. Hasta el punto en que nos aguantábamos en el aire sólo contactando con la plataforma con la parte trasera de nuestra túnica. Pero, el cuadrado de colisión no estaba centrado en el personaje (era más largo atrás que adelante) por lo que, si nos girábamos para volver al centro de la plataforma, nos caíamos. En mi época del CPC me mataron unas cuantas veces, por haber aterrizado al límite de la plataforma y no poder volver al centro, sin saber que todo esto era culpa de un cuadrado de colisión descentrado.

Otro día os explicaré más cosas de la colisión, esta vez aplicado a los juegos de lucha.

Un par de anotaciones:

La primera es que la imagen del marcianito colisionando con el cohete la he sacado de un tutorial de programación de videojuegos en java muy bueno. Os lo recomiendo si teneis pensado aprender java.

La segunda es que, si os ha gustado el artículo técnico, y considerais que la página vale la pena, votadme en el concurso. Sólo son un par de clics.

Una NES hoy en día

Unos amigos me han hecho un regalo especial. Supongo que conocedores de mi adicción a los juegos retros, me han regalado un coctel llamado Power Player.

Que es el equivalente de las máquinas de 9999 juegos de los chinos, pero en el mundo de las consolas de sobremesa.

Pongámonos en situación: Un mando clónico de N64, otro mando, este clónico de la megadrive y una pistola que, según me han explicado (yo de esto sé poco) es una réplica exacta de una Beretta. La consola en sí, el procesador, está dentro del mando de N64, a igual que el cable de alimentación y los de video-audio.

Pero lo mejor está dentro, señores... 76 juegos. Pero no juegos cualquiera, sino juegos de NES. Super Mario Brothers, Pacman, Tetris, 1942, Excite Bike, Contra, Dig Dug, Donkey Kong 1 2 & 3, BurgerTime, Asteroids, Galaga...

Y, por extraño que parezca, no son simples "versiones", sino que son directamente los mismos juegos de NES, con su misma músiquilla chillona. He hecho algunas averiguaciones y todo indica que son igualitos, igualitos (los de Nintendo se deben estirar de los pelos al saber que hay "consolas piratas" (ya que no se pueden llamar de ninguna otra forma) que utilizan sus juegos, sobretodo cuando nos los venden, de forma individual, por 20 euros cada uno.

Incluso hay el Yie Ar Kung Fu (aunque en el menu lo llamen King of Fighters). Y, según dicen las malas lenguas, hay posibilidad de insertar unos cartuchos específicos (de venta en los chinos) que permiten jugar aún a más packs de juegos.

Parece tener algunos errores menores de pantalla. En los juegos con scroll vertical, en la parte superior de la pantalla se muestran unos 10 píxeles de la parte inferior, pero nada que no pueda arreglar un ajuste de posición de pantalla. Por todo lo demás, igualito que tener una NES en casa. Y, aunque a mi me haya salido de gratis, no es que sea algo caro.

Es decir, nintenderos que se pasen por aquí, sobretodo si sois antiguos fans de la NES, ya sabeis la forma de conseguir una NES con 76 juegos a un precio de risa. Probablemente lo acabeis encontrando si os dedicais a visitar tiendas de estas chinas o de 20 duros.

Pero aún tengo más. En este link podeis acceder a una lista, con imágenes, de todas estas consolas piratas. Así, si os pasais por el chino y no encontrais el Power Player, podeis encontrar alguna otra de estas que también tienen incorporados juegos de NES, como el Game Player o el Polystation III.

No me digais que esto no se merece un voto, ¿no? Seguro que he arreglado la tarde a más de uno.

Tiles en juegos de Opera

Para acabar de tomar consciencia de los tiles y su importancia en los juegos, no hace falta más que mirar los juegos antiguos.

Miremos el caso del Goody o el Livingstone Supongo. Son juegos que ocupan, cada uno, 30 kb.

El sistema que utiliza es de tiles de 32x32. Algunos detalles como la distancia entre las flores en el Livingstone, o el tamaño de las piedras del suelo en el Goody, parece indicárnoslo. Otro detalle es que la pantalla "util" de ambos juegos es 320x160. Divisibles por 32.

Eso hace que el ordenador tan solo tenga que repintar 50 tiles. Algo que permitía que máquinas tan poco potentes como un 8086 ejecutara el juego a buena velocidad. Si os fijais, al utilizar un modo gráfico CGA (sólo 4 colores, es decir, 2 bits), la cantidad de tamaño que ocupa en memoria cada tile es de 256 bytes. Que era una división de memoria muy usual en la época.

El tileset (es decir, el conjunto de tiles) no era demasiado variado. Calculo que estaría compuesto por unos 100 tiles. Fijaos en la repetición de recursos, como todas las plataformas del Livingstone, o las copas de los árboles, tienen la misma forma, o las piedras y nubes del Goody.

Los sprites, ya puestos a analizar los juegos, parecen en cambio de 24x24. Algo más pequeños. Y, si habeis jugado a estos juegos (cosa que, si no habeis hecho, os recomiendo, funcionan sin siquiera necesidad de DOSBox), vereis que las animaciones de los personajes son bastante limitadas.

Si os dedicais a mirar juegos antiguos, podeis observar claramente el sistema de tiles de la mayoría de ellos. Del Prince of Persia, del Ikari Warriors, del Game Over, del Blood Money...

¿Pero sabeis qué? Que estaban hechos con tanta elegancia y tanta soltura que, a pesar de utilizar unos tiles enormes, reutilizados hasta la saciedad... ni siquiera nos dábamos cuenta de ello. Cuando un juego está bien hecho, está bien hecho.

Los Tiles

¿Que demonios es un tile? Hace tiempo hablamos de los “sprites” como la representación gráfica de cualquier objeto dinámico en un juego (es decir, personajes, objetos, etc). Un tile no es más que un “sprite” del escenario.

Un juego 2D puede ser descomunalmente inmenso. Como podeis suponer, que los fondos sean una gran imagen que el juego deba cargar al completo (o, como mínimo, cada nivel) no es una opción. Si pensais en lo que ocupa un BMP de pantalla completa, o incluso un GIF con gran detalle, imaginaos todo lo que debería cargar un juego para tener en memoria todo el mapeado de un nivel.

Indicación simple de tiles en un Final Fantasy

Así pues, la opción que se utiliza es hacer un sistema de “baldosas” que construye el escenario. Los juegos tienen un número variable de tiles. Un juego cutre de móvil quizás tiene 50 tiles por nivel. Un juego de plataformas 2D de PC, moderno (es decir, de hace unos 5 o 6 años, porque no es que los plataformas 2D abunden actualmente) puede tener miles.

Al final, lo que tenemos en memoria es una especie de mosaico con los identificadores de los tiles que debe ir en cada posición.

El tamaño de los tiles, como de muchas otras cosas en el campo de la programación, viene en múltiples de 8: 8x8 pixels, 16x16, 32x32, etc. El motivo es que la memoria se suele gestionar en múltiples de 8, por lo que es mucho más rápido redireccionar gráficos de esos tamaños que de tamaños intermedios.

Los Tiles están en muchos más juegos de los que podemos imaginar. Los plataformas 2D típicos, los juegos de lucha, los de vista cenital, etc. De hecho, muchos 3D clásicos, como el Doom, utilizan también tiles, aunque previa aplicación del RayTracing para darle una apariencia tridimensional.

Los tiles son la forma perfecta para dibujar un escenario, siempre que sean correctamente dibujados y siempre que el diseñador sepa que tamaño y formato de tiles corresponde a cada proyecto.

Mapa de tiles de un juego de lucha para movil. El tamaño de Tiles es de 24x24, debido a la poca velocidad de procesador de un movil

Un tamaño demasiado pequeño de tiles implicará que el procesador, a cada repintado, tenga que poner miles de dibujos en pantalla. Si estamos hablando, por ejemplo, de una resolución bastante normalita de 640x400 píxeles, si tenemos que llenar esa pantalla con tiles de 8x8, equivalen a 4000 tiles. Si lo hacemos con tiles de 16x16, equivalen “sólo” a 1000. Y esa diferencia de 3000 imágenes que poner por pantalla cada pocos milisegundos puede relentizar notablente un juego dependiendo de la máquina para la que programemos.

Un tamaño demasiado grande de tiles aumentará muchísimo la cantidad de tiles diferentes. Es un efecto parecido a lo de los sprites. Si hacemos los sprites de cuerpo entero, necesitaremos una gran cantidad, si “partimos” al personaje, conseguiremos muchos más movimientos distintos usando menos gráficos. Utilizar tiles de 32x32, por ejemplo, es mortal para la mayoría de juegos, ya que es mucho más fácil encontrar “baldosas” de 8x8 (o incluso 16x16) que se repitan constantemente en un juego, mientras que es mucho más difícil encontrar “baldosas” de 32x32 (o superiores) que se repitan constantemente. Y cuanto menos se repitan los tiles, más carga gráfica tendremos en memoria.

El truco está entonces en conocer la máquina para la que trabajas. Saber de que cosas peca más, y aprovechar la cantidad de memoria o la rapidez de procesador para optar por un tamaño u otro.

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.

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.

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.

Sprites

Voy a hablar un poco de los sprites, ya que tengo intención de ir poniendo de tanto en tanto posts un poco técnicos sobre el interior de los videojuegos, como ya hice el otro día explicando el significado del 255.

Un sprite es, sobretodo en los juegos 2D (también llamados juegos de sprites para diferenciarlos de los que utilizan modelos 3D), un objeto móvil.

A resumidas cuentas, todo lo que no forma parte del escenario y que tiene capacidad para variar.

Los sprites siempre han sido una parte vital en los videojuegos, por motivos obvios.

De hecho, podemos pensar en los sprites como un tampón de matasellos. Un juego de ordenador almacena todos los sprites (o, como mínimo, todos los sprites que vayan a ser utilizados antes de la siguiente carga) en la memoria. Entonces, cuando debe ser mostrado por pantalla, se busca el tampón correspondiente y se copia a la pantalla (concretamente, a la memoria gráfica, y el ordenador la mostrará en pantalla en cuestión de milisegundos, en el siguiente refresco).

¡Hola, soy un sprite en memoria!

Aquí vemos a Link en memoria. El dibujo está apañado para que Link salga identificable, pero en realidad esto deberíamos verlo (en la mayoría de sistemas) como una linea alargada de cuadros, correspondiente a posiciones de memoria. La información de esta memoria es, concretamente, el color que debe dibujar, dejando un color concreto como transparencia. En este caso, el color "transparente" es el negro, y todo lo del dibujo de Link que sea negro no se dibujaría. Observad como Link tiene los ojos de un gris oscuro, pero nunca negro, ya que entonces, podríamos ver lo que Link tiene detrás transparentado en sus ojos.

Las animaciones, como podeis suponer, se basa en ir poniendo distintos sprites muy parecidos en el mismo lugar a intervalos cortos. Más o menos como se hacían los dibujos animados.

Pero lo más importante de los sprites, sobretodo en los sistemas antiguos, era saber optimizarlos para que, en poca memoria, pudiéramos abarcar gran variedad de gráficos. Porque, hagamos lo que hagamos, tiene el mismo "coste" de tiempo imprimir en pantalla 10 veces el mismo sprite que imprimir 10 sprites diferentes.

Consolas

Las consolas lo tienen fácil. La NES o la SNES, o la GBA, tienen una memoria específica para los sprites. La GBA, en concreto, tiene ciertas zonas de mapeado que sirven únicamente para poner sprites o fondos. Es decir, cuanto más sprites tengamos en memoria, menos variedad de fondos podremos poner. Pero ya está. Siempre podemos contar con una variedad de sprites notable.

Los sistemas como el PC (o los más antiguos como CPC o Spectrum) no tienen esta baza. Si ocupas los 128 kb de memoria de un antiguo CPC en una variedad de músicas, o en mapeado de muchos niveles, o en un algoritmo de inteligencia artificial para que los enemigos sean más "listos", vas a tener muchos problemas para presentar una variedad de gráficos en pantalla.

Decolorar

El Spectrum optaba por la decoloración. Imaginemos que tenemos 1000 animaciones posibles (nada raro si contamos el movimiento de un protagonista, unas cinco variedades de enemigos y los objetos), de sprites que cada uno mide 10 pixels de ancho por 10 de alto. Eso son un total de 100 píxels por sprite. A un total de 1000 sprites, nos salen 100.000.

Si contamos que el Spectrum tiene 8 colores, para representar cada color necesitamos 3 bits. En total, 300.000 bits, que corresponden a 37'5 kb.

Pero, claro, con la poca memoria de un Spectrum, no podemos poner 37 kb de Sprites. ¿Dónde pondríamos los fondos, o la música, o el código? Así pues, el Spectrum utilizaba solo 1 bit por pixel. 0 no pintaba nada (trasparente) y 1, lo pintaba. Entonces se le indicaba a cada grupo de sprites de que color era. Si el protagonista iba de azul, pues todo azul. De esta forma, reducíamos por tres el tamaño de los gráficos.

Paleta

Algo muy importante (no imprescindible, pero aumenta significativamente la variedad gráfica de un juego) cuando se utilizan los sprites es no utilizar colores fijos. Es decir, no pintar a Link de verde claro, verde oscuro, marrón, etc... sino pintarlo de color 1, color 2, color 3, etc...

Entonces tenemos una serie de paletas. Las paletas son asignaciones del color de referencia (color 1, color 2, color 3...) a los colores concretos (verde claro, verde oscuro, marrón...).

Así pues, si tenemos, por ejemplo, una paleta "luz" y una paleta "sombra", simplemente con cambiar la paleta activa, podremos hacer que link se vea más oscuro cuando pasa por debajo de un árbol. No es necesario (afortunadamente) tener en memoria dos Links.

Esto se nota mucho en los clásicos Final Fantasy en 2D. Debido a la variedad de enemigos, se utilizaban distintas paletas "facil", "medio", "difícil". De esta forma, podíamos ver tres tipos distintos de monstruos, de distinta dificultad, pero que en realidad eran los mismos sprites pero con otra paleta.

Divide y Vencerás

A veces sale mucho más a cuenta, en cuestiones de memoria, separar los sprites. Si tienes un sprite muy grande, pero el movimientos solo afecta a una parte, en vez de tener un sprite grande para cada movimiento, es mucho mejor tener un sprite grande fijo y después uno pequeño de cada movimiento de la zona en cuestión.

Uno de los primeros juegos que utilizaron esa técnica fue el After the War, de Dinamic. Tenía un problema. Podías caminar, saltar, agacharse, etc. Pero también golpear, empuñar distintos tipos de armas, apuntar hacia arriba...

El prota de After the War, partido pero feliz.

Así pues, si teníamos que repetir todos los sprites de caminar con cada una de las armas posibles, o acciones posibles, salía un número de sprites descomunal.

Así pues, ¿qué hizo Dinamic? Separar al protagonista en dos sprites. Una serie de sprites para la mitad inferior y otra para la mitad superior. Así pues, en vez de contar con un total de 2500 sprites con todos los movimientos posibles, teníamos sólo 100, 50 de los movimientos con la mitad inferior y 50 con la superior.

La calidad gráfica muchas veces sorprendente en sistemas antiguos venía dada por estos trucos. Una mala utilización de los sprites hace que un juego deba limitarse a pocos movimientos y enemigos repetitivos. En cambio, una buena utilización permite una gran variead y, de esta forma, unos gráficos superiores a la media de los demás juegos de ese sistema.

Puñaladas...

Leo en Insert Coin que hay muchos problemas a la hora de convertir el Resident Evil 4 de GameCube para PS2. Que si las texturas tendrán que pasar de 24 bits a 8 o 4 (esto de por si solo es una chorrada, porque una textura de 4 bits es una textura de solo 16 colores).

Por otra parte, que la cantidad de polígonos de los personajes tendrán que reducirse a la mitad, algo también muy extraño porque la PS2, aunque tenga algo menos de procesador, gestiona más de 4 veces más polígonos que la GameCube.

-------------------------------X-Box------------PS2 -------------Gamecube

CPU---------------------------733MHz--------300MHz-----------458MHz

Graphics processor-----------233MHz----------150MHz----------162MHz

Total Memory-----------------64MB-------------32MB-------------40MB

Polygon Performance----------116.5M/sec ----- 66M/sec --------12M/sec

Así pues, extrañado, me dedico a navegar por internet buscando que demonios pasa. Porque es muy extraño que la PS2, que es capaz de convertir la mayoría de juegos de XBOX (que es muy superior en todo en cuestión de hardware) tenga tantos problemas a la hora de convertir un juego tridimensional de una consola que mueve muchos menos polígonos.

Finalmente he llegado a encontrar, buscando noticias, fuentes de dichas noticias, etc, que esto ha sido un rumor lanzado por una revista inglesa sobre GameCube, y que la prensa japonesa se ha hecho eco.

Capcom ha negado ese hecho y ha dicho que esta revista especializada sobre GameCube no tiene acceso al proyecto de conversión de PS2, por lo que sus datos son falsos.

Lo que me lleva a lo mismo. Que en todos sitios cuecen habas y que, al parecer, el mundillo de los videojuegos está tan cargado de puñaladas (o más cargado) que muchos otros géneros...

Amstrad CPC for dummies

Voy a hacer un repaso rápido sobre cargar juegos en el amstrad, por si algunos de vosotros ya habeis olvidado como se hace.

Los juegos pueden estar en formato cinta o en formato disco, ya que el Amstrad poseía ambos formatos. Yo utilizo siempre el formato disco, que es más cómodo. Y podeis encontrar cualquier juego en ese formato.

Una vez con el emulador abierto, teneis que ir a la opción de cargar disco. Esto simplemente simula que nosotros le ponemos en disco del juego en la unidad. Le indicais al emulador el juego que quereis "poner en la unidad" y volvemos al amstrad.

La forma de mirar los archivos del disco es con el comando cat. Es el equivalente al dir del MS-DOS del PC.

Si habeis insertado una ROM de disco de CPC correcta, os tendrá que salir un listado de archivos.

Ahora tenemos que decidir que archivo es el correcto. Generalmente hay un archivo con extensión BAS, que suele ser el archivo de carga (los BIN suelen ser de datos).

Aún así, es posible que en algunos juegos encontreis que solo hay BIN (entonces escoged el que tenga el nombre más simple) o más de un BAS, muchas veces porque permite cargar el juego simple o aplicando "pokes" (lo mismo, escoged el de nombre más simple).

Entonces debeis teclear run"nombredearchivo sin indicar la extensión, sea esta BAS o BIN. Y se cargará el juego.

XBurn

Pues parece ser que la XBOX se quema. Y no es debido al nuevo juego ese de la mansión Playboy, sino a que tiene un problemilla con el cable de alimentación.

En concreto, la compañía asegura que ha recibido información de 30 casos de fallos, siete de ellos de clientes que dicen haber sufrido una "pequeña quemadura en la mano", mientras que los otros 23 casos se refieren a la "existencia de cierto daño derivado del humo o pequeños daños en una alfombra o en un centro de ocio".

La compañía asegura en una nota que "en casi todos los casos, el daño causado por estos fallos afectó al interior de la propia consola o se limitó al extremo del cable de alimentación que se halla por detrás de la consola". Fuentes de la compañía aseguraron que Microsoft está dispuesta a gastar "lo que haga falta" en esta sustitución.

Porque hemos llegado a las palabras mayores. Al riesgo de incendio. Yo aún no se como, si lo que se calienta es el cable de alimentación, o la consola, ha habido gente que se ha quemado las manos.

Pero lo más curioso es el hecho de quemaduras en alfombras. Como voy a suponer que la gente no tiene su XBOX encima de la alfombra, voy a tener que llegar a la conclusión que el aparato ha tenido que empezar a soltar chispas como si fuera una limadora industrial.

Microsoft, mientras se dedica a cambiar los cables de alimentación (de forma gratuita, claro está), ha dado el inteligente consejo de que, si no estás jugando, apaga la consola. Supongo que será por eso de que, si van a caer chispas en la alfombra, al menos ves apagándolas con el pie mientras sigues jugando al Halo 2. Así uno puede incluso montar un minijuego de baile a lo Dance Revolution.

Si su consola tiene esta pinta, quizás necesite un cable nuevo.

Que no es lo primero que les pasa, por cierto.

En marzo de 2002, algunas tiendas japonesas dejaron de vender temporalmente la consola sólo semanas después de su lanzamiento debido a que algunas unidades rallaban los discos. La compañía ofreció reemplazar de inmediato y sin condiciones tanto el 'hardware' como el 'software' dañado.

Es decir, que ya sabeis la nueva bebida energética para este verano. XBurn A ful!

ACTUALIZACION

He encontrado un post sobre alguien a quien le explotó la XBOX. Pero no simplemente le explotó, sino que, al volverla a conectar... le siguió funcionando bien.

Evidentemente, todo podría ser una broma, pero ha colgado fotos mostrando su XBOX, y no creo que nadie le pegue un petardazo a su XBOX para hacer una broma por internet.

¿Que hacer con una GBA?

Bueno, voy a explicar un poco el secretillo este de la GBA, la emulación y todas esas cosas.

La GBA es una consola, en principio, destinada a un público infantil. Tiene juegos y lo peor de todo es que la mayoría de dichos juegos están destinados a un público infantil, a diferencia de, por ejemplo, una PS2.

¿Porqué entonces, un chavalote de 27 años como yo tiene una GBA?

La GBA amplia considerablemente sus capacidades cuando le añades un cartucho regrabable. Hay distintas marcas, aunque la que yo utilizo es la Flash2Advance Ultra. No hace falta decir que comprar o poseer un cartucho regrabable es algo completamente legal, y equivalente a comprar CD’s vírgenes y una grabadora de CD’s.

Estas tarjetas (en realidad son cartuchos, pero se les suele llamar tarjetas porque, al fin y al cabo, no son más que tarjetas como las de un ordenador) cuestan lo suyo, generalmente por encima de los 100 euros si uno quiere tener una memoria decente (unos 256 mbits). Llegan, con facilidad, a costar más que la propia GameBoy. Consisten en un cartucho en apariencia idéntico a los comerciales pero que, si conectas la GBA con el PC y aplicas un software específico, puedes añadir y borrar cosas.

Pero pasemos a lo interesante. Cosas que se puede hacer con un cartucho regrabable.

1.- Grabar ROMS de juegos de GBA. Eso es algo ilegal. No lo hagáis nunca. Que todos los juegos de GBA, en todas sus versiones (un total de 1800 juegos) sean fácilmente adquiribles mediante internet y que no estén protegidos de ninguna forma no os tiene que hacer caer en la tentación y convertiros en unos delincuentes. La piratería es mala, señores. Yo nunca juego a juegos piratas en mi GBA, e incluso compro juegos originales de GBA.

2.- Cargar todo tipo de aplicaciones realizadas para GBA. Programar en GBA es una tarea fácil. Se usa C y ASM, y sus limitadas características y su sistema gráfico lo hacen ideal para pequeños proyectos. Yo utilizo el Keeper 1.1 como agenda, para anotar cosas. Y con el MakeBook copio libros (evidentemente, de libre distribución) para leerlos en la GBA.

3.- Reproducir Multimedia. Ehhh... bueno, en teoría sí. Pero en la práctica, el poco tamaño de los cartuchos hacen bastante inviable destinar la GBA para ver películas o escuchar MP3.

4.- Jugar a juegos realizados para la GBA. Que no son pocos. Hay comunidades como GBADev donde la gente hace juegos para GBA. O grandes directorios de ROMs de domino público, como PD-Roms. Y, evidentemente, completamente gratis. Algo que tiene bastante éxito, más que realizar los propios juegos, es convertir algún remake o juego con código libre, generalmente en C, al C de la GBA. Yo, por ejemplo, tengo algunos clásicos en la GBA, como el Elite, el NetHack o el Rogue (“juegos de rol” realizados con caracteres ASCII) o el Batman 3D.

5.- Emulación. Otra gran función. Aparte de algunos sistemas menores, los más destacables son los emuladores de Game Boy (la clásica, la mono), de Nintendo (la antigua 8 bits), de Sega Master System y Game Gear. También hay uno de Spectrum, pero tiene el problema que es difícil emular un teclado de más de 100 teclas con los 6 botones de la GBA. Evidentemente, solo paso a la GBA los juegos que tengo originales en esos sistemas. Jugar a un juego de algún sistema antiguo aunque sea mediante emulación es ilegal a no ser que poseas el original.

La gran ventaja de todo esto es que con el cartucho regrabable no tienes que limitarte a un juego o programa, sino que tienes disponibles, en un menu con iconos a lo Windows, todos los programas y cosas que hayas metido dentro.

Básicamente utilizo la GBA como si fuera una GP32. Claro está, una GBA es mucho menos potente que una GP32. Pero la GBA SP, que es la que yo tengo, es mucho más pequeña y compacta. Aunque, ciertamente, la cantidad de software, sobretodo en el ámbito de la emulación, que se está realizando ahora para la GP32 hace que cualquiera (incluso yo, teniendo la GBA) deba plantearse comprarse una. Más que nada porque la GP32 es capaz de emular SNES, Megadrive y GBA, con todo lo que eso implica.

¿Chapuzas de Opera?

Es una simple curiosidad informática. Pero yo estaba casi convencido que las chapuzas informáticas era algo más actual. Es decir, que precisamente la distinta orientación de los lenguajes de programación, mucho más a alto nivel que antaño (pero, por otra parte, escondiendo la mayoría de los procesos de los ojos de los programadores), y por otra parte cierto desinterés en el resultado, entendiendo más la programación como un medio antes que un fin, era lo que hacía que actualmente hubieran bastantes “chapuzas”.

Pero estaba revisando yo, con un visor hexadecimal, el código de los archivos ejecutables del Goody y el Livingstone Supongo, y me encuentro algo muy curioso. Algo que podríamos calificar como “chapuza” en toda regla.

Este es un trozo del ejecutable del Goody. Como podeis ver, se trata simplemente del ejecutable de la Abadía del Crimen, pero modificado para que, en vez de cargar los archivos de datos de la Abadía, cargue los del Goody. Pero con la suficiente mala pata como para mantener la llamada a un segundo archivo que poseía la Abadía, pero no el Goody. Así como una opción de escoger monitor color o monocromo que el Goody no tenía.

El del Livingstone es igual, pero en vez de llamar a archivos con nombre “goody”, lo hace con archivos de nombre “livin1”.

Pero no debemos acusar aún a Opera. Hay algunos motivos que me impulsan a creer que los juegos que he llegado a poseer no son “originales”, sino que están modificados.

Los tres juegos (Goody, Livingstone y Abadía) tienen sus archivos ejecutables con la fecha de 1992. Y dichos juegos son anteriores a ese año. Pero a su vez, sus archivos de datos tienen fecha de 1980. Eso implica que los ejecutables se modificaron en el 92, y que los archivos de datos perdieron su fecha original (ya que en el 1980 ni siquiera existía Opera).

Los archivos del Livingstone Supongo son de tipo “livin1”, y dudo que cuando se programó el Livingstone, ya tuvieran en mente su segunda parte.

Lo que me lleva a la siguiente conclusión. Estos tres juegos se vendían en formato 5’1/4 (esos discos planos de antaño). Y eran autoejecutables. De hecho, yo no conseguí entrar en su sistema de archivos. Era para mi imposible ver (a diferencia de la mayoría de juegos) que archivos había en el disco.

Así pues, en el año 92 (y por eso esa fecha), cuando muchos ordenadores ya tenían como unidad base la de 3’1/2 (la actual) alguien decidió traspasar su juegos al nuevo sistema. Pero estos juegos eran ejecutables, y tuvo que hacer algunos cambios. Extrajo los archivos mediante algún programa específico, que los extrajo pero sin aplicar ninguna fecha, quizás porque, debido al sistema de archivos encriptado del disco, no la tenían (y por tanto los archivos adquirieron la fecha “por defecto” que no era la del ordenador, sino la considerada Fecha 0 del PC, 01-01-1980). Pero, claro, aunque tuviera los datos, el archivo ejecutable no se podía utilizar (porque era autoejecutable, y no un exe cualquiera), por lo que tuvo que adaptarlo a archivo exe.

Consiguió generar o modificar un EXE que leyera los datos, probablemente del Abadía del Crimen (ahora no recuerdo si la Abadía era autoejecutable o no, pero juraría que no, ya que permitía grabar la partida, es decir, modificar el disco). Y a partir de aquí, fue modificando el EXE de la Abadía del Crimen para conseguir ejecutar los demás juegos. Y se olvidó (o quizás prefirió modificar el EXE lo menos posible, por si los bugs) modificar lo demás relacionado con la Abadía del Crimen.

Así pues, como diría Grissom, las pistas no mienten y Opera es inocente del posible delito de chapuza informática.

Orígenes reales del 3D

Cualquier persona que sepa más o menos de videojuegos (es decir, que no se limite solamente a jugar al último bombazo) os dirá que el 3D, en los juegos, el auténtico 3D, empezó con el Wolfestein (1992), ese mítico juego de ID Software donde debíamos escaparnos de una prisión nazi en la segunda guerra mundial.

Pero eso es falso. Lo único que podríamos afirmar es que ID utilizó por primera vez un sistema de trazado en 3D llamado “Ray Casting”. Pero no con el Wolfestein 3D, sino ya un año antes con un juego menor llamado Catacomb 3D (1991).

Pero tampoco fue este juego el primer juego 3D. Es cierto que el Ray Casting fue un método realmente revolucionario, ya que, mediante ciertas operaciones matemáticas, permitía por primera vez el uso de texturas complejas, vistas simulando la primera persona, modificando el tamaño y posición de los objetos.

Pero el 3D en el campo de los videojuegos, el auténtico 3D (no esa perspectiva isométrica de la que os hablaba con el Batman) data, como mínimo, del año 1984, cuando apareció el 3D Tank Duel.

Tank Duel. Superando la barrera de los 5 polígonos por pantalla.

El nombre lo dice todo: Duelo de tanques en 3D. Y a este juego le siguieron muchos más, como el StarGlider, el Castle Master o el Mercenary) que utilizaban el 3D. Y me estoy refiriendo a un 3D poligonal, mediante vectores, probablemente más “genuino” que el 3D mediante “Ray Casting” del Wolfestein. Eso sí, como las máquinas de entonces tenían muchísimas limitaciones, los polígonos por pantalla, para representar escenario y vehículos, no pasaban de unas cuantas decenas, y en muchas ocasiones, los polígonos no tenían solidez, limitándose a los vectores, mostrando lo que había detrás.

No puedo asegurar que el 3D Tank Duel fuera el primer juego 3D de la historia, pero estoy bastante convencido de ello. No he encontrado ningunas referencias anteriores, excepto una conferencia, en el mismo año 1984, donde se expuso la posibilidad de crear juegos en 3D para los sistemas existentes.

Eso sí, juegos vendidos como "3d" los hay incluso antes. Por ejemplo, el Akalabeth, el primer juego de rol de la factoría Ultima (y, probablemente, del mundo mundial, como ya comento en este post). Si os interesa el Akalabeth podeis encontrarlo incluso para teléfono móvil directamente, y gratuitamente, en la página de su diseñador.

El Akalabeth, uno de los juegos donde mueres antes por inanición que por combate.

Spectrum VGA

El otro día, buscando imágenes sobre el Phantis y el Game Over, me encontré algo curioso.

Algunos de vosotros recordareis los gráficos del Spectrum. Esos gráficos de, como mucho, 16 colores, distribuidos en forma de bloques, lo que hacía que si un bicho verde pasaba por delante de una nube blanca, la parte de la nube en contacto con el bicho se volvía verde.

Game Over de Spectrum. Mirad como los canguros se dedican a pintar de verde los árboles y nubes

Pues un grupo de personas, los creadores y colaboradores del SPEC256, se dedican a colorear de nuevo estos juegos de Spectrum, pero utilizando una paleta de 256 colores, y utilizando un sistema de carga de gráficos píxel a píxel, eliminando los bloques y, por lo tanto, permitiendo gráficos que les da un empuje a los juegos de, como mínimo, 5 o 6 años, superando con creces las versiones de Amstrad o del PC (por entonces solo con 4 colores o, a lo sumo, 16).

Esto es un Game Over, por Crom. Con planetilla de fondo incluído.

El problema era que el Spectrum, francamente, hacía lo que podía. Su limitación de 48 kb de memoria eran muy grandes. 48 kb es, aproximadamente, lo que ocupa un bmp cuadrado de 128 píxeles. Y aquí te tiene que caber todo el código y la totalidad de los gráficos y mapeados (a no ser que quisieras que el juego cargara de la cinta después de cada fase).

Así pues, ¿como ganaban espacio? Pues en vez de usar gráficos en 256 colores (8 bits por pixel) o ni siquiera en 16 colores (4 bits por píxel), los hacían en monocromo (1 bit por pixel) y le añadían al final 4 bits indicando el color de todo el bloque.

Pero, claro, esta limitación de memoria no existe con los emuladores. Eso sí, la cosa no es fácil. Se tienen que recolorear todos los gráficos de un juego a mano. Por lo tanto, tan solo hay una decena de juegos (entre los que hay el Phantis y el Game Over)

Xbox o cómo competir contra uno mismo

En el mercado de las consolas no queda nada al azar. A igual que en muchas otras formas de ocio, cada compañía tiene su público potencial (por gentileza de los estudios de mercado), y cada uno procura (sobretodo en un mercado donde compiten tres o a lo sumo cuatro compañías) ganarse a un público específico y pisar el terreno de la competencia lo menos posible. Sega se dio cuenta con el fracaso de la Saturn, que había sido incapaz de conseguir un terreno propio, intentando conseguir el escaso margen de mercado que había entre Nintendo y Sony.

Por eso mismo, las consolas de Nintendo y de Sony (GameCube y PS2) coexisten sin demasiado problema.

Nintendo opta por la linea infantil o incluso familiar, continuando la estela de sus antiguas consolas NES y SNES. Es evidente que la GameCube es la mejor opción a escoger para los padres de niños pequeños. Y Nintendo lo sabe. El diseño compacto y con colores llamativos, el sistema de minidiscos, todo está orientado a los más pequeños. Así como sus juegos, que cuando no son directamente infantiles, optan por los juegos “de familia”, como los múltiples Mario Parties, y una inmensidad de títulos parecidos para jugar dos, cuatro o incluso más jugadores a la vez.

Sony fue quien más se arriesgó con la primera PlayStation, y continua su apuesta por el mismo camino. Los videojuegos no son patrimonio de los niños. Y las estadísticas avalan su estrategia. La media de edad de los jugadores es de 25 años. Por eso mismo PS2 está orientado a un público más juvenil o incluso. La misma consola, con un diseño agresivo, negra, y más parecida a un reproductor DVD que a una consola, nos lo dice. Así como sus juegos, mucho más adultos, complicados, generalmente para un único jugador. Y, en muchos casos, con etiquetas explícitas de +18.

Y después está la Xbox. El principal problema de Bill Gates es que es un genio de ordenadores. Y subconscientemente no creó una consola, sino un ordenador sin teclado. Técnicamente, la Xbox debería haber aplastado cualquier otro tipo de competencia, especialmente la PS2, con quien comparte mayor público potencial.

Pero ya he dicho que la Xbox está enfocada como un ordenador. La gran mayoría de juegos “exclusivos” de Xbox, como el Halo o el Morrowind, existen también para PC. Y eso no debería ser un problema, de no ser que son juegos, como los de acción o rol en primera persona, o los de estrategia, que se juegan mucho mejor con ratón o teclado.

Así que Xbox ha hecho lo imposible, pisarse el terreno a si mismo. Mientras que las consolas, por la particularidad de los juegos, se mantienen a un mundo de distancia del PC, ignorándose, Xbox ha conseguido que los ordenadores (y, específicamente el sistema Windows, del mismo Bill Gates) se haya convertido en su peor enemigo. Mucha gente no compra una Xbox porque sus juegos exclusivos ya aparecen para PC, a un precio más barato o, debido a la piratería, mucho más accesibles. Y los juegos de la Xbox que no aparecen para PC, más orientados al estilo de juego de las consolas, son multiplataformas que también aparecen para la PS2.

¿Así pues, que ficha moverá Microsoft? ¿Intentará competir más directamente con la PS2, con títulos como Fable, aún arriesgándose a caer como ya cayó la consola de Sega? ¿O seguirá apostando por los juegos tipo PC, pisándose el terreno a si mismo?

Wolfestein 5119

Aunque es cierto que estas decisiones nunca son fruto de una sola impresión, yo tengo bastante claro de cuando decidí dedicarme a esto de la informática.

Hará casi 20 años, en una revista de videojuegos para Spectrum o Amstrad, apareció el código fuente de un juego, en el código Basic que utilizaban esos sistemas. El juego más corto del mundo.

Eran 10 líneas de código, mucho menos texto del que voy a destinar para este artículo. Tecleabas ese pequeño programa en la pantalla de inicio del Amstrad y, por arte de magia, aparecía un juego en que llevábamos una nave espacial que debía ir por unos túneles, esquivando el techo y suelo.

Eso fue para mi la piedra filosofal de la informática. El punto en el que la ciencia se hacía arte. Ni que decir tiene que, con mi corta edad, y teniendo en cuenta lo complicado del código (ya que estaba optimizado al límite) no entendía ni papa de lo que estaba tecleando. Pero funcionaba. Había escrito un juego.

A veces el arte no está en hacer algo descomunalmente grande, sino conseguir hacer algo suficientemente pequeño, pero con calidad. Es algo que, por simple obligacion de los medios, era vital hace años. Ahora no. Ahora no tiene importancia si algo es exageradamente grande, si necesita más o menos CD’s, si necesita un ordenador más o menos potente. Esta optimización, este ansia por conseguir los mismos resultados, pero con menor tamaño, se ha perdido. Al menos, en el campo de los videojuegos.

Y por eso mismo es esperanzador encontrar iniciativas como el The 5k Contest, una competición anual sobre hacer el mejor programa, pero sin superar las 5k de código. Es decir, 5120 letras de texto. Desgraciadamente, la página del 5k Contest no parece funcionar (¿se activará cuando empiece la competición de este año?), pero he encontrado la página de uno de sus ganadores. El Wolfestein 5k.

Ya comenté ligeramente el Wolfestein, un juego 3D de 1992. Pues Lee Semel ha conseguido hacer un juego al estilo del Wolfestein con solo 5k. Y aún le ha sobrado espacio. El código ocupa 5119 bytes, uno menos del límite.

No simplemente podéis jugar online o descargaros el juego, visitando su web. También, para los aficionados a la programación, incluye un tutorial sobre Ray Casting y un tutorial paso a paso sobre como creó el juego. Todo en http://www.wolf5k.com

Dicen que el saber no ocupa lugar. Esta visto que el talento, tampoco.