Destripando la certificación

Cuando un juego termina su fase Beta y consideramos que lo tenemos terminado, toca comenzar a hacer release candidates. Estas versiones del juego son, como su nombre indica, versiones candidatas para salir a la calle. ¿Por qué candidatas? Porque aun nos queda un escollo: la fase de certificación. Durante la beta hemos ido solucionando los bugs y hablando con el publisher, pero en muchas plataformas tenemos que pasar por la certificación del fabricante: Microsoft, Sony o Nintendo. Y también en las tiendas móviles: Apple y Google; aunque éstas últimas no son tan exhaustivas.

Normalmente, tenemos unos documentos con todas las pruebas que se hacen. Sony tiene los TRC (Technical Requirements Checklist), Microsoft tiene los TCR (Technical Certification Requirements) y Nintendo tiene el Lot Check. Estos documentos están bajo NDA (non-disclosure agreemen) y cubren desde los avisos a mostrar mientras estás grabando la partida (el mensaje "No apagues la consola" que estáis cansados de ver) o el tiempo que puede estar la pantalla en negro (por ese motivo suele haber algún tipo de animación durante la pantalla de carga).

El proceso es sencillo de explicar: Se envía una versión del juego a certificar y el fabricante devuelve el resultado. Normalmente es un informe con la lista de los errores encontrados y si el juego ha pasado o no la certificación (muchas veces se admiten ciertos bugs "menores" siempre que no sean muchos ni interrumpan al jugador). Cuando le llega al desarrollador, éste tiene que solucionar todos, al menos los que son bloqueantes, y reenviar otra versión.

¿Cómo se soluciona un bug? Pues o lo arreglan, cambiando el código o arte del juego para que no presente problema, o se negocia. Si el problema es que te falta un texto de "No apagues la consola mientras guardas", simplemente es cambiar esa pantalla por otra cosa; pero si tienes que cambiar tu sistema de cargas para poder animar un relojito ya es un cambio más importante y puede requerir bastante trabajo.

Lo crítico de la certificación no es el coste; es el tiempo

Hay que tener en cuenta que, como descubrió por las malas Phil Fish, el objetivo de la certificación no es testear el juego. Te lo pueden tirar para atrás y punto; no hace falta que encuentren todos los bugs. Si trabajas con un editor, tienes la ventaja de que, normalmente, suelen encontrar muchos de los problemas de certificación antes ya que, como tienen experiencia publicando, el departamento de QA (Quality Assurance, o control de calidad) sabe bastante bien lo que te van a pedir durante dicho trámite. Y, posiblemente, sea mucho más barato. En algunos casos cada envío cuesta dinero. Tim Schafer dio una cifra de 40,000$, que para un indie puede ser demasiado. De hecho, Fish no podía parchear Fez porque no podía permitirse enviar más parches a certificar a Microsoft. Afortunadamente, parece que con el auge de lo indie y los nuevos modelos de juegos como servicio, tanto Sony como Microsoft están adaptándose y parece que han eliminado el coste de los parches.

Sin embargo, lo crítico de la certificación no es el coste. Es el tiempo. Normalmente estas revisiones del juego no se hacen inmediatamente. Microsoft o Sony, aunque son muy grandes, tienen unos recursos limitados. Si no hay muchos juegos, el proceso puede ser rápido, pero como estés certificando para Navidad, un fallo puede significar que ya no tengas tiempo de hacer otra "resubmission" y pierdas la campaña navideña. Y ya sabemos los costes extra de los juegos en cosas como marketing y campañas que se preparan a meses vista.

El testeo de certificación no es tan exhaustivo como imaginabais, sino que se limita a revisar una lista de requisitos.

Ahora empezáis a entender porque salen juegos con bugs, como Battlefield 4. Alguno pensará (que quizás algo hay) del poder de EA, que es una empresa influyente y a la que Microsoft no quiere enfadar. Pero, en realidad, ocurre porque el testeo de certificación no es tan exhaustivo como imaginabais, sino que se limita a revisar una lista de requisitos. Y los problemas de servidor no suelen aparecer aquí, porque en ese momento solo juegan los testers, la gente de las editoras y, quizás, la prensa. Si los servidores no soportan la carga de jugadores no lo van a descubrir hasta que lo pongan en la calle.

Tampoco es cosa de Microsoft si el juego es divertido, si es original o si está al nivel de calidad de lo que se espera en la consola. Como mucho, en caso de copia flagrante o cuando se infrinja una propiedad intelectual, si podrían tirar atrás el juego. Pero nada te impide hacer un juego malo con avaricia y sacarlo en su plataforma. Luego ya es cosa tuya ver cómo lo rentabilizas si nadie lo compra.

He hecho el ejercicio de buscar los juegos más malos de la pasada generación, y todos pasaron estos chequeos (me he limitado a juegos físicos, porque en digital había cosas con peor Metacritic). Por ejemplo, en Wii, el peor que he encontrado es Ninjabread Man, mientras que en PS3 y Xbox 360 el honor lo tiene Ride to Hell: Retribution. Los dos juegos obtuvieron el visto bueno de las respectivas compañías, aunque seguro que la gente de certificación (y los de QA de la editora/desarrolladora) veían venir el hostión.

Algunos os planteareis, entonces, ¿cuál es el objetivo de este proceso? Aunque para el usuario el resultado es que el software que compra funciona, sobre todo, lo que se trata es de proteger la imagen del fabricante. Si un juego es aburrido o tiene fallos de animación, el problema es del desarrollador. Pero en cambio, si se te cuelga o se pierde tu partida guardada la gente no se quejará del juego, sino de Xbox o PlayStation (los usuarios hardcore si que quizás estemos más informados de estos temas).

¿Podría hacer más Microsoft, Sony o Nintendo? Seguramente si. Pero, preguntémonos, ¿dónde ponemos el límite? Por supuesto que queremos juegos más optimizados y sin bugs, pero, ¿no es mejor que nosotros, como clientes, compremos lo que consideramos que lo merece y no que tenga que venir la compañía de turno a velar por la integridad de su catálogo?