Entradas de la categoría ‘Videojuegos’

Una recopilación más o menos extensa, sin más. Lo que más me ha llamado la atención es la evolución en los mensajes publicitarios: se aprecian las ganas y ansias de vender en los primeros ejemplos y, poco a poco, la publicidad se va convirtiendo en una simple captura de la carátula de la cinta en cuestión.

Los mensajes son la bomba, muy de la época, del estilo «conviértete en la estrella», «la mejor aventura jamás creada», «el mejor juego», «no has visto nada igual», «merecía la pena esperar» o «el mayor éxito».

Pasen y vean; disfruten de las imágenes y rememoren viejos y anhelados tiempos. De fácil digestión para estas épocas estivales que nos toca disfrutar. Para ampliar las imágenes hay que hacer clic sobre ellas.

Daley Thomson’s Decathlon	Videolimpic	Un, dos, tres… responda otra vez
Skool Daze	Rocky	Abu Simbel Profanation
World Series Baseball	Shadow Fire	Frank Bruno’s Boxing
A view to kill	World Series Basketball	Frankie
One-On-One	Exploding Fist	Herbert’s Dummy Run
Nightshade	West Bank	The Rocky Horror Show
Grizam	Commando	Camelot Warriors
MapGame	Olé, toro	Robin de los bosques
Dynamite Dan	Rambo	Yie Ar KUNG-FU
Beach-Head II	Superman	Three weeks in paradise
Battle of the planets	Yabba Dabba Doo!	Gladiator
Legend of Amazon Woman	Ping Pong	Viernes 13
Bomb Jack	Green Beret	Zoids
Costa Capers	Starstrike II	Biggles
Stainless steel	Ghosts’N Goblins	Astérix y el caldero mágico
Dragon’s Lair	Antiriad	Colossus chess 4
TT Racer	Dynamite Dan II	Popeye
Nightmare rally	The great escape	Iridium
Infiltrator	Fernando Martín Basket Master	Dan Dare, pilot of the future
El misterio del Nilo	Nuclear bowls	Paperboy
HardBall	Cobra	Rogue Trooper
Nosferatu	Gauntlet	Mercenario
Aliens, el regreso	1942	Jail Break
Arkanoid	Escape from Singe’s Castle	Nemesis
MagMax	Enduro Racer	Game Over
Barbarian	Hydrofool	Metrocross
Slap Fight	Exolon	Correcaminos
Prohibition	James Bond in The Living Daylights	Whopper Chase
Tank	Freddy Hardest	Renegade
Tai-Pan	Star Dust	Desperado
Phantis	Indiana jones and the Temple of Doom	Hysteria
Mega-Corp	Star Wars	Super Sprint
El oso Yogi	Implosion	Thunder Cats
Out Run	GunBoat	California Games
París Dakar	Winter Olympiad 88	Erik: Phantom of the opera
Match day II	Troought the trapdoor	Gryzor
Platoon	Impossible Mission II	Arkanoid, revenge of Doh
Predator	La guerra de las vajillas	Ikari Warriors
La abadía del crimen	Inside Outing	Starring: Charlie Chaplin
Vixen	Target: Renegade	The vindicator
Salamander	Mickey Mouse	Aspar GP Master
Rambo III	El poder oscuro	Navy Moves
After Burner	Thunder Black	Last Ninja 2
R-TYPE	Batman	Dragon Ninja
Gonzalezz	Renegade III	Ulises
Blasteroids	Perico Delgado	The Real Ghostbusters
Corsarios	Perseguido	Drazen Petrovic Basket
MOT en ópera	Football Manager 2	Crazy Cars II
Knight Force	MOT	Cazafantasmas II
Kick off	Power Drift	Emilio Sánchez Vicario Grand Slam
Clock Chess 89	Wild Streets	Raindow Island
	Predator II

‘Polybius’

Las leyendas urbanas siempre tienen una base real. Cuando oímos hablar del cadáver congelado de Walt Disney, de los cocodrilos que viven en las alcantarillas de Nueva York, de los gatos bonsái o de cómo cocer un huevo con dos teléfonos móviles, podemos comprobar que existe una base verídica del asunto, es decir, Walt Disney existió como persona física real, Nueva York es una ciudad estadounidense y tiene alcantarillas, los gatos son felinos domésticos auténticos y los huevos y los teléfonos móviles son verídicos como objetos visibles y tangibles, aunque no tengan nada que ver entre sí ni estén relacionados por cocción milagrosa alguna.

Supuestas imágenes de ‘Polybius’

El caso de ‘Polybius‘ es muy curioso. ‘Polybius’ fue un supuesto videojuego ochentero, de los de maquinita en sala de recreativos. Y digo «supuesto» porque nunca nadie lo vio, no ha quedado evidencia alguna de que existiera y jamás se han encontrado pruebas gráficas verídicas de su paso por este cosmos. Pero claro, cuando algo jugoso se convierte en fábula, se crea un halo de mito y de falacia a su alrededor, por lo que es muy posible que nos topemos con personas que conocen a personas que, a su vez, conocen a otras personas que jugaron a aquella máquina, que vieron morir de esquizofrenia a alguien que jugó a aquella máquina o que tienen el recuerdo de que una vez les contaron como alguien murió, aunque ya no recuerdan si fue por la máquina o de tanto pensar. Si es que…

Esto es algo así como la historia aquella de Ricky Martin, el programa de televisión ‘Sorpresa, sorpresa’, el perro, la niña y el bote de mermelada; que nunca nadie vio pero todo el mundo recuerda haber visto. La leyenda cuenta que ‘Polybius’ apareció en el año 1981 (desarrollado por Ed Rottberg, a la sazón ingeniero de Atari) en un salón de máquinas recreativas de Portland, Oregón. Junto a esta máquina, unas pocas más se distribuyeron después por la misma ciudad, a modo de prueba (¿de prueba de qué?). Se dice que todo aquel que jugaba a este juego sufría de alucinaciones, amnesia, mareos, vómitos, pesadillas nocturnas e incluso ansias y deseos de suicidio.

Los relatos de las personas que en su día dijeron que tuvieron la oportunidad de jugar a ‘Polybius’ hablaban de combinaciones de luces estroboscópicas y gráficos enmarañados, giros imposibles, vivos colores fluorescentes e incluso mensajes subliminales que animaban a quitarse la vida, entre otras lindezas varias. La supuesta muerte de un adolescente de trece años a causa de ‘Polybius’, dicen que hizo retirar todas las máquinas automáticamente de las calles. Y desde aquello nunca más se supo. Las posteriores paranoias ochenteras, empapadas en LSD, adornaron el bulo con conspiraciones gubernamentales, hombres de negro y pruebas de resistencia militar. En fin.

Supuesta pantalla inicial de ‘Polybius’

Más allá de la discusión de que un videojuego pueda producir un efecto epiléptico en una persona (hoy algo más extendido en este mundillo, pues hasta las grandes marcas de ocio incluyen mensajes de precaución en sus títulos, pero muy poco claro), habría que preguntarse por qué nadie puede aportar ni siquiera una prueba de la existencia de ‘Polybius’. No hay fotos (más que una pequeña imagen −a continuación− aparentemente falsa), no hay placas de circuitería, no existe ninguna ROM del juego, ni la empresa que lo creó existe, ni la persona que lo programó de pronuncia… Sólo gente que dice que le han dicho que a alguien le han dicho…

Lo más gracioso de este tema es que, y como comentaba al inicio, la leyenda urbana de ‘Polybius’ se ha convertido, en sí misma, en una leyenda urbana propiamente dicha. Los internautas hablan y hablan de entradas en los blog, de páginas web, de vídeos y audios que cuentan el mito urbano de ‘Polybius’. Y repiten y enlazan y comentan y analizan escritos de otros que han copiado de otros que, a su vez, copiaron de otros anteriores; y así hasta el origen de los tiempos (¿qué fue antes, el huevo o la gallina?).

Supuesta foto original de un arcade de ‘Polybius’

Esta entrada no pretende retroalimentar la metaleyenda, sino desmontar el hoax por completo. Señores, ‘Polybius’ nunca existió; sin más. Algo de hace treinta años de lo que no se tiene constancia fehaciente es más que probable que no viera nunca la luz, a no ser en la mente de algún perturbado, de algún alborotador o de algún graciosillo trolero cabalgando a lomos del Usenet de los noventa. Y no, las teorías de la conspiración no me valen en absoluto, ya hay demasiadas.

Es increíble que de algo inexistente se puedan encontrar imágenes, vídeos, reconstrucciones, emuladores y todo tipo de material en Internet. ¿Todo falso? Hombre, pues sí. El «si no lo veo no lo creo» debe ser el modus vivendi de nuestra existencia, y más en el hoy digital en el que todo se puede adulterar, simular, deformar, desfigurar y tergiversar sin apenas medios, escrúpulos y miramientos.

Hombre, siempre hay que dejar abierta una rendija de la puerta a una posible explicación de algo inexplicable a primera vista. Pero eso me lo voy a callar, porque si no, este post no habría tenido ningún sentido.

Guiño en ‘Los Simpsons’ a ‘Polybius’ (nótese el «Propiedad del Gobierno de EE.UU.»)

«Game loop» básico

En mi historia como desarrollador informático, así como en mi propia vida, los gustos o las disposiciones siempre se me han presentado por rachas, por períodos de tiempo más o menos largos en los que me da una venada y me zambullo en un asunto de tal manera que, a veces, hasta me doy miedo a mí mismo. He tenido, pues, mi época de desarrollador por cuenta ajena al uso, la de programador de virus informáticos, la de hacker, la de diseñador de aplicaciones para dispositivos móviles, la de programador de microcontroladores PIC, la de desarrollo de robótica e inteligencia artificial y hasta un tiempo que me dio por el diseño de videojuegos.

Normalmente nunca consigo terminar nada serio cuando me dan estos sirocos, pero la temporada en la que me sumerjo en cada asunto (desde varios meses hasta unos pocos años) es tan intensa, que el bagaje intelectual y técnico que acumulo me sirve y me basta, la mayoría de las veces, para calmar mi sed de conocimientos y, por qué no decirlo, mi ego de erudito instruido a medias en muchos contenidos pero docto en casi ninguno de ellos.

En lo que concierne a los videojuegos, hubo varias cuestiones que me produjeron un orgasmo neuronal al descubrirlas y al explorar todas sus posibilidades casi al cien por cien, entre las que puedo destacar dos: la detección de colisiones (algo que me trajo de cabeza durante semanas y de lo que algún día hablaremos) y el bucle de juego o game loop. Todos los videojuegos del mundo mundial (mejor diré casi todos, por no pillarme los dedos) tienen una sección dentro de su código que es un bucle condicional y que se corresponde con la acción principal del programa, es decir, con el momento exacto en el que estamos jugando, sea machacando marcianos a hostias o intentado encajar piezas en su justo lugar para destuir líneas de ladrillos de colores.

Desde el ‘Pong‘ hasta el ‘Metal Gear Rising: Revengeance‘, la actividad principal de un juego se desarrolla dentro de un loop o bucle, infinito en principio, que sólo se rompe bajo determinadas condiciones ocasionadas por el usuario o generadas por el propio desarrollo de la acción en sí. Los procesadores no pueden hacer tantas cosas a la vez como podemos imaginar, es más, realmente, y por norma general, en un sistema informático sólo se puede ejecutar una tarea cada vez, lo que ocurre es que esto se realiza a tal velocidad que la sensación de multiproceso se simula cediendo el control al microprocesador en intervalos de tiempo muy cortos. ¿Cómo es posible, entonces, que en un entorno de juego parezca que, al mismo tiempo, se dispare, se muevan los enemigos, se actualice el marcador y se cambie el fondo de nuestro escenario?

Para los legos en la materia, imaginemos un rizo de instrucciones de código en cualquier lenguaje de programación que se repite muchísimas veces por segundo. Dentro de dicho rizo se realizan multitud de acciones en décimas de segundo que, en función del juego, pueden ser unas u otras, pero que casi siempre son muy parecidas: 1- comprobar eventos del usuario (se ha pulsado una tecla, se ha hecho clic con el ratón, se ha movido el joystick a la izquierda…); 2- mover los elementos del juego (el personaje principal, los enemigos, otros integrantes, ítems para recoger…); 3- detectar colisiones entre elementos (el personaje contra una pared que no puede atravesar, los proyectiles disparados contra los enemigos, un ítem que proporciona más vida contra el personaje principal…); 4- dibujar el contenido completo de la pantalla en función de todo lo anterior (movimientos, saltos, muerte, heridas, fondos…); y 5- añadir un retardo o pausa final para acomodar la velocidad de la acción de igual manera a todas las plataformas y, también, para dar un respiro a la multitarea del sistema operativo cediendo recursos (ya que un bucle sin fin, por definición, colgaría incondicionalmente la aplicación).

El siguiente código, en C#, muestra una función prinicipal Main() que, tras hacer una llamada a la inicialización de las variables necesarias, es un game loop que llama constantemente a diversas funciones que comprueban continuamente las condiciones del juego y actúan en consecuencia mientras una última función booleana partidaTerminada() no devuelva un valor verdadero.

private static void Main()

{

Juego j = new Juego();

j.inicializar();

do {

j.comprobarEventos();

j.moverElementos();

j.detectarColisiones();

j.dibujarContenido();

j.anadirRetardo();

} while (! j.partidaTerminada() );

}

El primero de los puntos dentro de un bucle de juego (comprobar eventos de usuario) realiza constantemente una verificación de los controles que el usuario haya podido utilizar, esto es, detecta pulsaciones de teclas de control o movimientos de mandos de juego. Se debe vigilar todo aquello que sea susceptible de ser empleado por el jugador para, en el siguiente punto, actuar en consecuencia.

En función del desarrollo del juego y de su manejo, el segundo de los asuntos (mover elementos de juego) ejecuta las acciones necesarias, como pueden ser mover el personaje hacia un lado, saltar, disparar, realizar un pausa o abandonar la partida.

El tercero de los puntos (detectar colisiones) actúa sobre las distintas colisiones que se puedan producir en el juego y las controla. Al fin y al cabo, un videojuego no es más que un montón de imágenes generadas por ordenador y moviéndose por la pantalla, y la física del movimiento de estas imágenes debe ser lo más realista posible. Así pues, por ejemplo, un personaje manipulado por el jugador no debe poder atravesar una pared que está a su derecha, por lo que el detector de colisiones ha de localizar si se ha producido un toque entre ambos para anular los movimientos a la derecha, dando la sensación de que se ha chocado con dicha pared. Asimismo, el impacto de un proyectil sobre un enemigo es una colisión que debe ser detectada, como el apoyo de sus pies sobre el suelo o un golpe contra el techo al saltar.

El mundo de la detección de colisiones es una disciplina aparte que bien podría requerir de un libro completo para su explicación, con miles de fórmulas matemáticas y mucha teoría física. Evidentemente, no es lo mismo la colisión de dos sprites en un mundo 2D, que no son más que cuadraditos chocando por alguno de sus cuatro lados, que una colisión en un espacio 3D entre figuras poligonales con formas complicadísimas. El programador deberá decidir cuánto tiempo de proceso dedica a que los microchips detecten este tipo de colisiones, desde un burdo envoltorio tridimensional que casi no permita acercarse al personaje a ningún sitio, hasta una programación exhaustiva (a nivel de píxel) que detecte un disparo dirigido a la rodilla del enemigo y le provoque una simple herida en ella, sin llegar a matarlo.

Algoritmo de colisión entre dos círculos

El cuarto de los estados de nuestro bucle (dibujar contenido) es el referido al renderizado del nuevo contenido atendiendo a todo lo anterior. La pantalla se dibuja varias veces por segundo, por lo que la sensación de movimiento es realista y fluida. En este punto se pueden también poner en orden marcadores, número de vidas, monedas recogidas, tiempo restante de juego, etcétera.

Por último (retardo), ha de añadirse un tiempo de espera que regule el paso (tiempo entre ejecuciones de loop) del bucle para que todo se vea ni muy rápido ni demasiado lento y, además, para ceder durante un instante el control de eventos al sistema operativo y nuestro juego no cuelgue el resto de aplicaciones y procesos.

Los bucles de juego pueden ser de paso fijo o variable. En un tipo fijo de paso, el juego intenta llamar a su método de actualización en un intervalo fijo y constante de tiempo. Por ejemplo, en el entorno de desarrollo XNA de Microsoft (el que se utiliza para el diseño de videojuegos de Xbox 360, entre otros) el tiempo del paso fijo por defecto es de 1/60 de segundo. Los juegos de paso variable llaman a sus métodos de actualización en un bucle continuado.

A la hora de desarrollar un juego, el tiempo de bucle es importantísimo, pues debemos tener en consideración un par de conceptos: FPS (frames per second, o cuadros por segundo) y UPS (updates per second, o actualizaciones por segundo). Lo ideal sería llamar a los métodos o funciones de actualización y de dibujado en pantalla el mismo número de veces por segundo: 20 ó 25 veces por segundo es más que suficiente para ofrecer fantasía de movimiento en un juego que se ejecuta en un teléfono móvil; entre 25 y 30 para los juegos de las consolas actuales.

Por poner un ejemplo claro: si ajustamos un tiempo de bucle a 25 FPS, ello significa que debemos llamar al método de renderizado cada 40 milisegundos (1000 / 25 = 40 ms). Como antes de hacer render se llama a los métodos de actualización de variables, posiciones, detector de colisiones y demás, tenemos que asegurarnos que todas estas actualizaciones se pueden realizar en 40 ms o menos, de lo contrario, tendremos un juego más lento.

Nosotros podemos calcular, grosso modo, el tiempo que puede tardar nuestro programa en actualizar datos y en dibujar la nueva pantalla en condiciones normales. Pero, ¿qué ocurre si nos están atacando 100 enemigos a la vez, con sus posiciones, sus movimientos, sus disparos, etcétera? Efectivamente, el tiempo de bucle no puede ser el mismo para un escenario sin enemigos que para uno repletito de ellos y muy cabreados. Es por eso que, muchos juegos, parecen ir muy bien el principio, pero en condiciones extremas se lentifican.

Lo ideal es calcular el paso del bucle con un «ni pa’ ti, ni pa’ mí». En condiciones de cero enemigos y un día soleado, un método de actualización y un método de dibujado que se quedan cortos y a los que hay que añadirles un tiempo de espera (como decíamos anteriormente) es mucho mejor que un par de métodos que ya sobrepasan el paso de bucle en ese momento y que, cuando caiga la noche y aquello se pete de alienígenas mosqueados, los continuos desfases de actualización van a hacer que el juego vaya muy lento. Lo mejor, por lo tanto, es guardar un equilibrio y, tras muchas pruebas, conseguir un ritmo o una velocidad de juego constante a costa de un FPS variable.

Velocidad constante de juego con FPS variable (vía ‘Against the Grain’)

Y todo eso mogollón de veces en un segundo y más rápido que el mismísimo Rayo McQueen. El game loop es fascinante y merece la pena, para aquel al que le apasione como a mí, estudiarlo muy a fondo y documentarse mucho antes de emprender la excitante tarea que supone programar un videojuego.

‘Curiosity’

Técnicamente es el videojuego más absurdo, estúpido y aburrido de la historia de los juegos digitales, algo que ya se me podría haber ocurrido a mí y que habría tardado en codificar un fin de semana. Sin embargo, tiene ese componente de curiosidad malsana y ponzoñosa que tanto nos atrae a los homo sapiens, ese puntito cotilla que nos puede hacer pasar horas, con un iPad entre las manos, rompiendo cubitos binarios sin sospechar siquiera estar perdiendo el tiempo de una forma escandalosa.

Escenario y cubo de ‘Curiosity’

‘Curiosity’ se compone de una simple pantalla o escenario blanco en el que flota un enorme cubo tridimensional construido con billones (sí, billones, con «b») de pequeños cubitos distribuidos en varias capas, los que los creadores llaman cubelets. Un único cubo para toda la humanidad, para todos los jugadores que lo descarguen y comiencen a jugar con él. Los participantes deben ir tocando a golpe de tap cada cubelet en cada cara del gran cubo con el objeto de hacerlos desaparecer, dejando al descubierto la capa inferior, repletita, de nuevo, de más y más pequeños cubitos (es necesario eliminar completamente una capa antes de que la siguiente esté disponible para destruir). Como digo, el juego es colaborativo, por lo que los cubos que tú destruyas desaparecerán para los demás jugadores.

El objetivo del entretenimiento es llegar al centro del cubo gigante, demoler el último cubelet y descubrir qué es lo que se encuentra en su interior. ¿Y qué se supone que hay en el interior? Según la empresa desarrolladora, bajo un número no revelado de capas, se encuentra un asombroso descubrimiento esperando ser desvelado, algo así como la revelación desconocida más importante para la humanidad. Al final, lo más probable, es que sea una chorrada de marca mayor. La persona que elimine el último de los cubelets recibirá en su dispositivo un enlace a un vídeo explicando qué hay dentro del cubo. Esta decisión, el hecho de quién ha sido el último el tapear el cubito final, la disponen automáticamente los servidores de la empresa, que son los que llevan un registro de los miles de usuarios que en este y en ese momento destruyen cubos y el orden en el que actúan.

Según va transcurriendo el juego, cada capa tiene un diseño diferente que muestra una pista de lo que el gran cubo contiene. Según se procede a reventar cubos, se van consiguiendo monedas que pueden ser canjeadas por herramientas temporales que mejoran las habilidades del jugador, tales como petardos para desencadenar explosiones, cinceles de hierro o diamante, bombas y otras. Por ahora no existe la posibilidad de comprar monedas con dinero real abonado directamente a la cuenta corriente de 22Cans, pero parece que, en un futuro próximo, va a ser un opción más que probable. Probable y rentable, porque se especula con cantidades de alrededor de los 8,00 $ por 300.000 monedas. Teniendo en cuenta que 300.000 monedas es lo que cuesta un único cincel de hierro y que éste tiene una duración de cinco minutos, ahí está el dinero fácil de la financiación de la empresa. Para que os hagáis una idea, el cincel de diamante cuesta tres mil millones de monedas y dura 22 horas, 22 minutos y 22 segundos.

El afortunado que sea el primero en tapear sobre el último cubo (yo seguro que no seré) y en recibir el secreto a través de su conexión de red, tiene la opción de compartir la información con todo el universo conocido o de reservársela para sí eternamente (ya hay que ser cabrón y se le ocurre esto último). Lo que tiene terminantemente prohibido es canjear el misterio por dinero contante y sonante, ya sea a través de venta privada o vía subasta pública.

El caso es que en sus pocos días de vida, ‘Curiosity’ ha conseguido más de un millón de jugadores rompiendo cubitos. Su autor asegura que desea y espera alcanzar los cien millones, pero el asunto no parece tan claro. La enorme conectividad simultánea que soporta el juego ha llevado a recibir miles de quejas por cuelgues, apagones, pérdidas de monedas, fallos en la sincronización y eternos lag de comunicación.

¿Quién será el último rompedor cubitero? ¿Qué oculta el cubo? ¿Será del dominio público tras el final del juego? ¿Cuándo se acaba esto? ¿Se acaba? Incógnitas que el cubo revelará. O no.

Listado BASIC de un Spectrum

La forma de trabajo de aquellos tiempos era bien distinta a lo que puede ocurrir en la actualidad. En un principio los videojuegos se diseñaban directamente sobre la máquina que los iba a ejecutar. Para ello existía una doble vertiente, en función de la calidad requerida y de los conocimientos del programador: desarrollar en ensamblador o desarrollar en algún lenguaje de alto nivel (comúnmente algún intérprete nativo de BASIC).

La diferencia entre ambas técnicas reside en la potencia del producto final. Evidentemente, programar en ensamblador ayuda a aprovechar al máximo las capacidades del aparato, ya que se hace necesario conocer a la perfección el funcionamiento interno del procesador y del resto del hardware, así como las instrucciones propietarias que presentan y permiten manejar. Hacerlo en un lenguaje de alto nivel acompaña en el proceso, debido a su sencillez de codificación con respecto al ensamblador, pero es muy posible que no exprima al cien por cien el funcionamiento de la máquina.

Para desarrollar un título que fuera compatible con las tres plataformas más conocidas al mismo tiempo, los programadores debían, pues, diseñar el juego para cada una de ellas particularmente, aprovechando muchas veces código en el traspaso debido a que las tres compartían el mismo procesador, un Z80. Sin embargo, el proceso resultaba tedioso y, para las empresas, poco rentable.

'Fernando Martín Basket Master' para Spectrum

Hacia el año 1987 apareció una herramienta denominada PDS (Programmers Development System), una suerte de sistema que hacía uso de un compilador cruzado y de un equipo de hardware para la época muy avanzado. Este equipo consistía en dos tarjetas, una ISA con dos puertos COM para un ordenador de 16 bit (que hacía las veces de equipo madre de programación) y otra que se insertaba en el equipo de 8 bit y que, en función de este, podía tener forma de cartucho o de periférico adaptado a él.

Desde el ordenador de 16 bit (bien un PC, un Amiga o un Atari) se diseñaba el juego para, después, enviarlo directamente, ya compilado y a través de un cable conectado a las tarjetas mencionadas, a la memoria de la máquina de 8 bit. De esta forma, el desarrollo era mucho más rápido y dinámico a causa de la potencia de los computadores de trabajo y, también, se disponía de la posibilidad de hacer cambios directamente sobre la memoria para comprobar el funcionamiento de los distintos elementos y de depurar errores prácticamente en tiempo de ejecución.

La pega de este sistema PDS es que él solito era capaz de generar las distintas compilaciones para las diferentes máquinas. Esto, que podría parecer una ventaja, sólo así lo era para los empresarios dueños de las producciones, pero no para el público final. El problema reside en que, a pesar de que los tres ordenadores compartan procesador principal, las capacidades gráficas, de audio, de memoria u otras no son las mismas. Por ejemplo, MSX tiene unas aptitudes gráficas bastante mejores que Spectrum, y Amstrad CPC un sistema de sonido también muy superior al de Spectrum.

Ello significaba que la primera versión que se desarrollaba era la de Spectrum para, posteriormente, convertirla, a través de mínimos cambios, para MSX y Amstrad. La inmensa mayoría de los juegos de la época eran conversiones directas de Spectrum, lo que cabreaba bastante a los usuarios de Amstrad o MSX, porque pagaban por juegos para sus plataformas que llevaban gráficos de Spectrum y el sonido chillón de los pitidos del beeper de Spectrum. En fin, no se aprovechaban las capacidades de las distintas máquinas, porque el objetivo era desarrollar rápido y vender mucho. Ojo, no siempre era así, pues algunas compañías como Opera Soft cuidaban muy mucho las versiones.

'Fernando Martín Basket Master' en Spectrum y Amstrad

Ricardo Cancho, a la sazón grafista de Topo Soft, en una entrevista que le hicieron el pasado año 2010 comenta algo que no tiene desperdicio:

Desde el punto de vista técnico, siempre empezábamos por la versión de Spectrum, pero con los cálculos de memoria realizados para el Amstrad. ¿Por qué? Muy sencillo: el Amstrad era el que más consumía en gráficos, literalmente el doble que en las otras máquinas, así que primero había que asegurarse de que el proyecto cupiese entero en esta plataforma. Una vez realizadas las estimaciones, ya podíamos ponernos a hacer gráficos, mapas, etcétera. Así que, paradójicamente, en las versiones de Spectrum siempre quedaba algo de memoria libre de sus 48 KB.

La versión de MSX se dejaba siempre para el final y solía ser un clon de la de Spectrum. El criterio era puramente económico: no se dedicaba ni un minuto de tiempo extra a esta plataforma, para así cumplir los plazos de entrega y de fecha de salida al mercado.

Una auténtica pena que la avaricia de los mercaderes aplastará ríos de imaginación y destreza informática por los siempre putos plazos de entrega. Pero hoy en día no es muy distinto. La única diferencia es que en aquellos tiempos, si realmente se aprovechaban las capacidades de cada equipo, el mismo juego para Sprectrum y MSX eran completamente polos opuestos. Hoy, si dejamos aparte la Wii de Nintendo por su clara inferioridad técnica, es lo mismo ser un poseedor de una PlayStation 3 o de un Xbox 360, porque los juegos se ven y se perciben de una forma exactamente igual en ambas plataformas. Y esto es algo que no tiene mucho sentido.

Ambas consolas actuales tienen unas capacidades similares, pero no iguales. Cabría pensar, además, que el hecho de que el soporte nativo de PlayStation 3 sea el Blu-ray Disc y el de Xbox 360 sea el DVD podría llevar aparejada una mayor cantidad de contenidos en los juegos de la consola de Sony (más niveles, más cortes de vídeo…), pero no es así. Los títulos para ambas consolas son prácticamente iguales, y las diferencias que se pueden encontrar son tan nimias que no merece la pena siquiera tenerlas en cuenta. Lo único que hoy día debería considerar un comprador a la hora de decidirse por una u otra, es el precio y, sobre todo, el catálogo de juegos.

'Dead Rising 2' en Xbox 360 y PS3

¿Qué es lo que impulsa esta tendencia? ¿Por qué se hacen juegos idénticos? ¿A qué oscuro acuerdo se ha llegado? Porque todo el mundo está de acuerdo en que, si se deseara realmente y se aprovecharan al máximo las capacidades de cada máquina, la guerra entre Sony y Microsoft podría ser brutal. Pero eso no ocurre, ni ocurrirá. La historia se repite, no sabemos si por motivos económicos, de mercado o de lo que fuere.

Para el que quiera profundizar más en este tema, desee disfrutar de un buen rato y tenga hora y cuarto que perder (o que ganar), os dejo con un podcast de RetroActivo, uno de los blog más interesantes, maduros, completos y profesionales del mundo retro de la informática y los videojuegos. En este vídeo ha tenido esta entrada su inspiración, pero os recomiendo el resto también sin ningún género de dudas.