Entradas de la categoría ‘Desarrollo’

Las razones que llevaron a Pixar y a Disney a llegar a un acuerdo comercial para generar y distribuir películas de animación allá por 1991 fueron puramente económicas. Steve Jobs había comprado el departamento de informática gráfica de Industrial Light & Magic (actualmente conocido como Pixar) con el objeto de crear hardware gráfico, ordenadores muy potentes en el manejo de imágenes y polígonos, originalmente pensados para la industria médica y las agencias estatales.

Los inicios de Pixar como estudio de animación fueron promovidos por el propio Jobs que, tras invertir varios millones de dólares en la compra, primero, y en la propia compañía, después, andaba tan escaso de dinero que tuvo que buscar colaboraciones de distribución y financiación para sacar aquel proyecto adelante. La inversión llegó por fin de manos de la todopoderosa Disney que, no del todo convencida, aceptó compartir gastos y beneficios a partes iguales mediante un contrato que vinculaba a las compañías a la producción de dos largometrajes: ‘Toy Story‘ (primer largo totalmente animado por computador) y ‘Monstruos, S.A.‘ (‘Monsters, Inc.’ en su versión anglosajona).

Aquello fue un éxito sin precedentes. Los galardones más prestigiosos y las mejores críticas llegaron en forma de avalancha descomunal. Dinero, dinero y más dinero, y el dinero le gusta mucho (pero mucho) a la compañía de Walt Disney. Pero mucho, tanto que son capaces de llevar a la pantalla grande auténticas bazofias sólo por la pasta que van a sacar en concepto de merchandising, videojuegos derivados, spin-offs, musicales sobre hielo y otras gilipolloces varias. Dicen las malas lenguas que a Disney ya no le importa el producto, en tanto en cuanto el beneficio sea lo suficientemente importante como para justificar su manufactura. Si el señor Walter Elias levantara la cabeza…

En el año 2006, y tras mucho tiempo de relaciones rotas, Disney decide comprar Pixar, haciendo rico (más) a Steve Jobs y a su progenie y manteniendo el equipo técnico original al completo, pero controlando el producto de principio a fin desde ese momento y quedándose con todos los derechos de explotación de todas las producciones. Y ahí empiezan los despropósitos cinematográficos del tipo ‘Cars 2‘, ‘Brave‘ o ‘Monstruos University‘ (‘Monsters University’), películas que, ni de lejos, son las mejores cintas paridas por los animadores de Pixar, sino más bien todo lo contrario (por muy simpáticas que puedan resultar). Punto y aparte de mención son las series ‘Toy Story Toons‘ y ‘Car Toons‘, ejemplos perfectos de cómo seguir ordeñando la teta de la vaca de grandes éxitos con una mínima inversión, una calidad deficiente y un máximo beneficio.

Y en aquesta línea llega a nuestros cines la última superproducción Disney (no firmada por Pixar), la publicitada a tope ‘Aviones‘ (‘Planes’), un spin-off de ‘Cars‘ y su secuela producida por DisneyToon Studios y estrenada, el 9 de agosto de este año 2013, por Walt Disney Studios. Como comentario inicial podemos decir que nunca se ha de confiar en la calidad técnica de, y en el esfuerzo puesto en, una película que llega a la gran pantalla un 9 de agosto y su videojuego aparece en las tiendas para todas las plataformas de Nintendo tres días antes, el 6 de agosto. ¿Ansias de crear, innovar y emocionar o codicia mercantil cutrepastelera?

Cójame usted al señor Rayo McQueen, póngale alas y hélice y ya tiene a Dusty, el flamante protagonista de esta peli, un avión con miedo a las alturas (que ya tiene cojones) que quiere participar en una competición de altos vuelos. Para conseguirlo busca ayuda en un experimentado aviador naval que le ayuda a clasificarse con el fin de retar al vigente campeón del circuito de carreras. Vamos que el guión lo tenían ya hecho, las mallas tridimensionales de los personajes casi también, los renderizados, probablemente los fondos, los chistes y los guiños también. Ley del mínimo esfuerzo y máxima rentabilidad.

El largometraje es penoso y excesivamente infantil. Lo han debido de manufacturar los becarios de los becarios de Disney, porque recuerda a los antiguos dibujos animados o, como mucho, a míseros imitadores mugrientos de Pixar con ínfulas. Resultaría muy interesante para el lector acudir a la reseña que hacen en Blog de Cine sobre la película, donde describen a la perfección la unidimensionalidad de su protagonista, el mero relleno del resto de personajes o lo pobre de su guión y de su calidad visual, entre otros detalles.

‘Aviones’ fue pensada para ser pasto de DVD y Blu-ray, sin pasar por las salas de cine, pero decisiones de última hora han dado con ella en la pantalla grande, esto es, resulta ser un bodrio de videoclub, con todas sus lindezas, proyectado en formato 1,85:1. Cine cutre para el verano de mano de la factoría Disney; nada nuevo bajo el sol. El problema es que esta película corre el peligro de ser relacionada excesivamente con Pixar, y eso no es bueno (para Pixar).

Probablemente el hecho de que Disney comprara Pixar no fue una buena idea. Probablemente, no, seguro. La compañía de Emeryville, California, ha supuesto la mayor revolución en la creación de películas de animación de las últimas dos décadas. Posiblemente no haya habido otro agente implicado en el mundo de los dibujos animados que haya representado un punto de inflexión tal en el mercado como Pixar. Digamos que la historia de la animación, grosso modo, se podría escribir con cuatro películas: ‘Pauvre Pierrot‘ (1892), ‘Steamboat Willie‘ (1927), ‘Blancanieves y los siete enanitos‘ (‘Snow White and the Seven Dwarfs’, 1937) y ‘Toy Story’ (1995).

Pero las prácticas monopolísticas es lo que tienen; ellos compran, compran, compran y manipulan, manipulan, manipulan. A su antojo, sin cortapisas. La calidad aquella con la que nació Pixar, fruto de tremendos profesionales, tremendas ideas y tremenda genialidad ha terminado por convertirse en franquicia del mercado, el dinero y los pingües beneficios. Y es que a Disney le interesa más vender avioncitos de juguete, pijamas de aeroplanos y tazas de desayuno de aviones antropomorfos que crear animaciones de calidad. Hoy en día es una multinacional con todas las de la ley; se acabó el embrujo, se acabó la magia, se acabó la ilusión; bienvenido Señor Dólar.

Y lo que nos queda por ver, Dios nos proteja en un futuro no muy lejano. Y es que ya tienen pensado y programado perpetrar chapuzas de mayor calibre como la secuela de ‘Aviones’, ‘Planes: Fire & Rescue’ (2014); o ‘Buscando a Dory’ (‘Finding Dory’), spin-off para 2015 del divertido personaje secundario de ‘Buscando a Nemo‘ (‘Finding Nemo’), que se habrán vuelto locos para inventarse el título.

La antigua genialidad convertida en mercadotecnia. Una pena.

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.

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.

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.

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.

Alguien, alguna vez, me dijo que yo era un tipo raro por el simple hecho de ser programador informático cuando, desarrollando un software de comunicación sobre redes TCP/IP, me dio por asignar el valor -1 al número ilimitado de licencias de uso. Fue algo espontáneo, instintivo, mecánico: si 0 significaba que no tenías licencia para utilizar el programa, 1 que disponías de una sola y 2 que tenías dos, -1 fue mi elección para el número infinito de permisos de utilización; algo así como una puerta trasera para depurar la aplicación con cientos de instancias al tiempo o, también, una gracia o prebenda para con aquellos clientes que compraban mucho y pagaban bien.

Cualquiera que haya conocido a un programador informático podrá asegurar con total rotundidad que, efectivamente, estos tipos son muy raros. Hablan de códigos ininteligibles, de instrucciones, de sentencias, de bucles, de saltos y de condiciones. Es tal la inmersión léxica en la forma de dirigirse a un ordenador, que sus cerebros no son cúmulos de neuronas en sinapsis, sino millones de líneas de código ofuscado relacionadas entre sí por gigantescos diagramas de clase.

De esta especie de individuos nació aquello que se dio en llamar hexspeak, una suerte de lenguaje informático cachondo para designar identificadores únicos de memoria a la hora de depurar el código de diversas aplicaciones, sistemas operativos o, incluso, procesadores. El hexspeak es muy parecido al leet (1337 en leet), un idioma originado en las antiguas BBS que fue durante muchos años medio de conversación cotidiano de hackers y gurús de la Red, y que hoy, por extremadamente difundido, en considerado más propio de lamers y de newbies o noobs.

La particularidad de hexspeak es que, mientras que leet utiliza números, letras y símbolos para sustituir los caracteres de las distintas palabras, hexspeak se ciñe exclusivamente a la notación hexadecimal, la cual incluye los números del 0 al 9 y las letras mayúsculas de la A a la F, dieciséis dígitos en total (0123456789ABCDEF). Esto restringe bastante las palabras que pueden ser formadas, por lo que el guiño satírico o el giro burlesco se hace necesario para crear términos inteligentes.

Con el 0 representando a la letra O, el 1 a la L, el 5 a la S o el 6 a la G, entre otros, las palabras que se inventan los informáticos vienen a ser valores mágicos de depuración, es decir, igual que los números mágicos que, de manera codificada, identifican a un tipo de archivo en su cabecera (como GIF89a a los ficheros GIF, FF D8 a los JPEG o %PDF a los PDF). En este caso, estos identificadores únicos son valores específicos que se escriben en memoria durante la asignación o la cancelación de asignación, de modo que, posteriormente, se pueda decidir si los datos alojados se han corrompido en el proceso o no.

Numéricamente los programadores prefieren los valores impares, por aquello de que los procesadores que no implementan direccionamiento de byte casquen cuando intenten utilizarlos como punteros. Además, estos valores deben ser elegidos lo más lejos posible de las direcciones de memoria de probable aparición, como las que pueden ocupar el propio código del programa, los datos estáticos, los datos de montículo (heap) o la pila. Por lo tanto, puesto que es muy poco probable (aunque no imposible) que un entero de 32 bits tenga un valor hexspeak bien formado, la aparición de un número así en un depurador o en un volcado de memoria indica, de manera casi segura, un error como un desbordamiento de búfer o una variable no inicializada.

Pero es que además, y como decíamos antes, el hexspeak lleva aparejado un jolgorio y una guasa inherentes propios del cachondeo más ingenioso de los desarrolladores informáticos. Y para muestra varios botones. Reproducimos, a continuación, algunos de los términos más famosos difundidos por los programadores de las más importantes compañías del mundo de la computación. Nótese que el prefijo 0x es utilizado comúnmente en el mundo de la programación para designar que lo que sigue es un número en notación hexadecimal.

● 0x8BADF00D (fonéticamente ate bad food), algo así como «comió mala comida» o «se alimentó mal». Utilizado por Apple en los informes de fallos de su sistema operativo iOS cuando una aplicación tarda demasiado en correr, terminar o responder a los eventos del sistema.

● 0xABADBABE (a bad babe), traducido como «una chica mala». Lo utiliza también Apple como número mágico para el sector cero o área de arranque de un disco (Boot Zero Block).

● 0xBADDCAFE (bad cafe), «mal café» o «café malo». Usado por OpenSolaris para designar la situación de memoria asignada pero no inicializada.

● 0xDEADBEEF (dead beef), «carne muerta». Normalmente utilizado para indicar un fallo de software en sistemas embebidos. Originalmente se le dio el uso de marcar áreas de memoria recientemente asignadas pero todavía sin inicializar. Fue un término típico en sistemas IBM RS/6000, PowerPC 32-bit y Commodore Amiga.

● 0xDEADDEAD (dead dead), literalmente «muerto muerto». Es el código de comprobación de errores que se muestra al ser invocada una Pantalla Azul de la Muerte (Blue Screen of Death) utilizado para obtener un volcado de memoria en sistemas basados en Windows NT.

● 0xDEFEC8ED (defecated), «defecado». Es el número mágico para los volcados de memoria en OpenSolaris.

● 0xB16B00B5 (big boobs, ahí es nada), «tetas grandes». Requerido por el software de virtualización Hyper-V de Microsoft para ser utilizado por los clientes Linux como firma invitada. Menuda guasa tienen algunos.

● 0xFEE1DEAD (feel dead), así como «me siento muerto». Usado como número mágico en las llamadas de reinicio de sistema de Linux.

● face:b00c (facebook), pues eso. Se utiliza en la dirección de protocolo IPv6 para www.v6.facebook.com.

Estos términos, entre otros muchos, representan el habla hexspeak de los programadores, esos locos cuyas mentes forman un conjunto de bases de datos distribuidas, de modelo eventualmente consistente, que ríete tú de Cassandra.

Las entrevistas de trabajo pertenecen a un universo aparte muy alejado del mundo real. Te hacen preguntas incómodas a las que tienes que contestar de manera sicológica, te estimulan o te procuran motivar de una manera peculiarmente curiosa, te examinan atentamente con la mirada y, de vez en cuando, te prueban técnicamente para verificar tus conocimientos reales. El orbe informático no se escapa de estos ensayos y, con cierta frecuencia, recurre a los exámenes expertos para determinar la valía de un candidato o su más absoluta incompetencia.

El problema conocido como «Fizz Buzz» es un buen ejemplo de lo anteriormente comentado. No es más que un método para descartar, de una forma ágil, a un aspirante a programador, ahorrando mucho tiempo al contratador y, por supuesto, al posible contratado. El dilema en sí parece sencillo (y, en el fondo, lo es), pero tiene truco.

El enunciado del problema que se plantea a los candidatos es el siguiente:

Escribe, en el lenguaje de programación que desees, un programa que muestre en pantalla los números del 1 al 100, sustituyendo los múltiplos de 3 por el palabro “Fizz” y, a su vez, los múltiplos de 5 por “Buzz”. Para los guarismos que, al tiempo, son múltiplos de 3 y 5, utiliza el combinado “FizzBuzz”.

Una tontería, ¿no? Pues no. Este programa se puede resolver de cincuenta millones de maneras diferentes, lo que importa (lo que realmente buscan) es que lo hagas de la forma más elegante posible, esto es, utilizando el menor número de líneas de código o, en su defecto, de un modo tal que eyaculen de placer con el procedimiento aplicado. Todo vale, o un sinfín de sentencias condicionales anidadas de Basic o una de línea de 56 caracteres en Ruby.

Los resultados de «Fizz Buzz» son concluyentes y, para mí, bastante preocupantes. Dicen los expertos de las mejores empresas de desarrollo que la mayoría de los graduados, ingenieros o diplomados en informática no pueden hacerlo o, por el contrario, lo saben resolver pero invierten demasiado tiempo en ello. Los entendidos comentan que cualquier candidato deseable no debería tardar más de dos o tres minutos en terminarlo y, pasados 10 minutos, podría ser descartado sin ningún tipo de miramiento.

Parece ser que sólo uno de cada doscientos programadores en una entrevista de trabajo es capaz de pasar la prueba, y eso es muy alarmante.

Lo curioso es que el juego proviene de un divertimento adolescente, últimamente también ligado al hecho de beber alcohol en grupo. Un conjunto de chavales en corro recitan la serie lo más rápido posible, a razón de un número cada uno e introduciendo los «Fizz», los «Buzz» y los «FizzBuzz» correspondientes: 1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz, Buzz, 11, Fizz, 13, 14, FizzBuzz, 16… Y así hasta el 100 (que, por cierto, es «Buzz»). El que se equivoque bebe; y se vuelve a empezar.

A mí mismo me ha tocado lidiar con esta prueba no hace mucho, y pienso que se puede resolver, elegantemente en muy poco tiempo, siempre y cuando tengas la cabeza estructurada y pienses como un programador de verdad. Existen miles de soluciones en cientos de lenguajes de programación diferentes, y en la web Technical Support existe un hilo en el que se pueden encontrar un montonazo de ellas, algunas muy curiosas y otras muy divertidas. Hay una versión para la consola de MS-DOS, otra para Excel, versiones para Python, ensamblador, GW-BASIC, PHP y hasta una en código MSIL y otra en el lenguaje de programación esotérico Ook!

Yo, así a bote pronto, voy a improvisar dos, una en Visual Basic .NET y otra en C# (ambas como aplicación de consola). Y reto a los lectores a que, en cualquiera de estos dos lenguajes (que son de los más típicos) intenten escribir versiones con menos líneas de código y más elegantes. Se puede hacer seguro, y ahora mismo se me está ocurriendo una manera, pero voy a plasmar mis primeras ideas para dar más juego.

Pues, lo dicho, a pensar un poco y a fizzbuzzear un rato.

Si hace una década me hubieran asegurado que una serie televisiva española de ficción me iba a enganchar pegado al televisor, simplemente me habría descojonado con tal virulencia y acometividad que las costillas flotantes que salen de mi columna vertebral se habrían clavado en mi hígado de manera más que probable. Sin embargo, hoy es el día que puedo asegurar que la ficción televisiva patria ha alcanzado un nivel tan aceptable como para lograr competir dignamente con las series estadounidenses, y no sólo en cuota de pantalla, sino también en calidad técnica, aptitud interpretativa y genialidad y originalidad de sus guiones. Algunas, claro.

Dejando a un lado las comedias de situación y las reminiscencias del pasado político (que tanto agradan, ambas, por estos lares), títulos como ‘Periodistas’, ‘Hospital central’, ‘El comisario’, ‘Cuenta atrás’, ‘RIS científica’, ‘Hay alguien ahí’, ‘Águila Roja’ o ‘Piratas’ han hecho evidente que en España se puede hacer buena televisión de entretenimiento, obviando los comentarios que ponen a parir a una o a otra por su mediocridad artística, su falta de trama profunda o su prácticamente nula calidad argumental (en la mayoría de los casos no les falta razón alguna). Mención especial aparte a ‘El internado‘, probablemente la única serie capaz de competir de forma rigurosa y seria con cualquier otra del mundo. Sin duda, la gran obra maestra de la ficción española que, ahora, triunfa en Rusia.

Precisamente, de la productora de ‘El internado’, Globomedia, llegó a principios de este año 2011 un nuevo título que prometía hacer las delicias de los amantes de la ciencia ficción en la pequeña pantalla. La serie (Antena 3), titulada ‘El barco‘, traía consigo emoción, intriga y suspense, algo que se hizo evidente en un más que bueno episodio piloto. Sin embargo, y tras trece capítulos de su primera temporada, ‘El barco’ ha pinchado como serie de ficción y se ha convertido en un melodrama romanticón plagado de amoríos, relaciones y folleteos varios en alta mar (más alta que nunca, por cierto). La trama es técnicamente un despropósito, pero, bien llevada, podría haber conseguido laureles y vítores de la crítica y del público. Empero, los responsables han preferido agradar a los televidentes quinceañeros a golpe de fotogramas de Mario Casas sin camiseta y de Blanca Suárez en paños menores, descuidando la idea original hasta puntos insospechados.

Pero lo que más nos ha llamado la atención en este blog no es la calidad interpretativa del elenco, ni siguiera las incoherencias de un guión cogido con alfileres. Lo que a nosotros nos interesa es la parte tecnológica del asunto, en este caso el área de los efectos especiales digitales de la grabación. Y es que parece mentira que una serie de una de las productoras más potentes de país, en el año 2011 de Nuestro Señor Jesucristo, lleve pegoteados en la cinta unos efectos que cualquiera en su casa, un poco (pero poco) avezado en el manejo de 3D Studio o After Effects, podría haber creado en cinco minutos. Resulta un insulto gravísimo al espectador, al que tratan de tonto e ignorante.

Cromas evidentes, perspectivas imposibles, efectos repetidos, pájaros de conducta errática y humaredas voluptuosas son algunos ejemplos de las decenas de efectos dignos de un parvulario del modelado en 3D. A buen seguro, el único efecto realista que han sido capaces de recrear es el de la neblina de la cortinilla de la serie que, por cierto, reutilizan en el capítulo ‘Niebla’, pero a lo bestia. Como honrosa excepción, sólo se salva el episodio ‘El hombre de Liverpool’, con sus transiciones entre presente y pasado, aunque eso poco tiene que ver con efectos en tres dimensiones, pero era de recibo comentarlo.

El barco creado por ordenador para los planos generales y panorámicos largos es simplemente patético. La suerte les acompaña porque se ve pequeñito (desde muy lejos), ocultando y tapando la mayoría de los defectos. Sin embargo, lo que no han podido esconder es el movimiento de la nave, ya sea a la hora de esquivar un remolino, tipo sumidero, en alta mar o en el momento de mostrar al barco encallado en vete tú a saber dónde en el medio del océano. La fluidez de los movimientos del modelo 3D recuerda muy poco a las películas de Pixar y muy mucho a ‘Los Fruittis‘.

A muchos de los planos que utilizan la técnica del chroma key sólo les falta que se les caiga una sábana verde por detrás. Tienen el tufillo de aquellas películas antiguas en las que un grupo de personas parece viajar en el interior de un coche mientras el fondo se mueve descaradamente a sus espaldas. Algo que, a la altura de siglo que andamos, es inconcebible. Ni que decir tiene que un escenario no puede ser nunca tan estático que parezca una fotografía evidente de una puesta de sol tropical. Pues ‘El barco’ tiene de esos también.

De todos los despropósitos digitales que se pueden encontrar, los que más llaman la atención son dos; sin duda, los más notorios por nocivos para la retina. El primero de ellos se da en el capítulo ‘El graznido’, en el que miles de aves de dudosa procedencia toman el buque en busca de comida. Los planos generales muestran un barco repleto de puntos negros, que representan a los pájaros posados en él, y una jauría en rededor de cuervos y gaviotas (y ¿palomas?) acechando a los tripulantes. En una de las imágenes se puede comprobar la profesionalidad de los diseñadores al programar el movimiento calculado de la bandada. Dos gaviotas (se pueden ver en el centro superior de la imagen siguiente) sufren un comportamiento errático al volar una hacia la otra, chocar y continuar agitando las alas en el sitio, sin desplazarse. Un bug al más puro estilo ‘Pro Evolution Soccer’, cuando un jugador comienza a caminar por el aire o atraviesa el terreno de juego con las piernas saliendo de sus hombros.

El vídeo que corresponde a este fotograma se puede visionar en la propia web de Antena 3. Se corresponde con la quinta parte del capítulo 5, y el gazapo empieza alrededor del minuto 4:02 (produciéndose en el 4:05, aproximadamente). Es el más evidente, pero apuesto a que, examinando a fondo el averío, se pueden encontrar bastantes más.

El segundo momento estelar se refiere al episodio ‘La ley del mar’, donde el navío se queda sin combustible justo encima de un volcán submarino (que ya es puntería y casualidad, mirusté). Hace mucho calor y el agua del mar hierve (literalmente) provocando quemaduras de primer grado en un bañista inconsciente, pero en los peces no. De pronto, y como si por arte de magia se tratara, el volcán entra en erupción, arrojando al exterior inmensas nubes de ceniza y humo, pero ni una gota de agua. ¿O sí es agua? Quién sabe. El fuerte estallido ha sido modelado de una forma tan soez, burda, tosca, basta y ordinaria, que no me explico como no han dejado directamente la malla de polígonos al descubierto; habría quedado más simpático y menos grotesco, irrisorio y ridículo. En el vídeo siguiente se puede comprobar también la pericia del animador 3D para conjugar esos hongos negros rechonchos con el resto de la escena.

Desconozco (y no quiero conocer) qué empresa ha sido la encargada de generar los efectos digitales de esta serie, aunque me juego el cuello a que anda por ahí entremetida en los títulos de crédito. No sé si es una compañía de saldos o es que el presupuesto ha sido tan bajo que han puesto a trabajar a los becarios en prácticas. Desde luego, es amoral e inadmisible que, en esta época, una empresa de animación haga este trabajo para un cliente tan importante y pase todos los filtros y cortapisas hasta llegar a la audiencia. Si es así como queremos competir con las series americanas, casi mejor que nos dediquemos a aídas y cuentamés, que la cosa pinta más fácil para los expertos en FX de este país, antes conocido como España. Para ponerse a mear y no echar ni gota, oiga.