PROBLEMAS DURANTE EL DESARROLLO DE VIDEOJUEGOS
Detrás de un videojuego o mejor dicho, detrás de una mecánica rota o de un bug clandestino, escondido en el código de un juego y enterrado por ceros y unos, a veces hay sangre, sudor y lágrimas.
Ese problema de física que hace que esa silla rebote indefinidamente quizá fue el punto y final de una relación lasciva y jodida entre un diseñaodor de niveles y una programadora de generosos senos. Aquella luz no ilumina un trozo de la habitación porque había dos fulanos que se llevaban a matar, o en cierto nivel el juego sufre unos tirones porque una herramienta de desarrollo no se actualizó debidamente porque se quedaron sin dinero.
Detrás de todo desarrollo hay personas humanas y como tales tienen esos problemillas del día a día que a todos nos tocan los cojones y nos amargan la existencia.
A veces sólo vemos lo que tenemos delante y como idiotas tecnócratas que lo dan todo por sentado nos quejamos de que «esa textura» es una chapucería sin pararnos a pensar que detrás de ese horror puede haber una bofetada, una mamada, un llanto, un adiós o incluso un «que os jodan a ti y a tu puto videojuego».
Acompáñenme en este viaje/homenaje a los desarrolladores de videojuegos extraído en su totalidad de los fantásticos «Postmortem» de Gamasutra.
SUPER MEAT BOY
Recursos Económicos Insuficientes
Edmund: Resulta raro decir que nuestros gastos personales fueron algo que realmente salió mal, ya que de hecho nuestra situación económica era más bien una motivación enorme para terminar el juego, pero fue sin duda un problema a medida que avanzábamos y enntrábamos los últimos meses de desarrollo.
Hubo un punto en el que fui operado de urgencia de vesícula biliar y me supuso un agujero de 50.000 dólares porque no podía pagar un seguro médico. No tuvimos dinero real durante todo el proceso incluso todos los cómics que habíamos impreso para la GDC y PAX se llevaron a cabo mediante un sistema de trueque según el cual mi esposa hacía juguetes de peluche para vender en la tienda de Newgrounds a cambio del costo de impresión.
Nuestra situación era muy grave en varios puntos clave del desarrollo, pero he estado en la línea de la pobreza durante los últimos 10 años, así que ir sin un duro encima no suponía un gran problema, y sinceramente, tuvimos problemas mucho más grandes de los que preocuparnos de todos modos .
Tommy: En un momento dado tuve negativo de $ 800 en el banco. Lo malo es cuando vas a un 7-Eleven para comprar una Coke Zero y te rechazan la tarjeta . Con intereses resulta que al final cada Coca-Cola me costó alrededor de $ 40.
RED STEEL
El Wiimote como cámara para el jugador.
En el momento en que Red Steel 1 salió el concepto de movimiento con el Wiimote estaba en pañales y tuvimos poco tiempo para pulir el juego ya que tenía que salir durante el lanzamiento de la consola.
Mientras se mueve la retícula en la pantalla era perfectamente sensible, el problema venía en la confusión que generaba en el jugador cuándo este trataba de girar la cámaraen lugar de estar apuntando a un objetivo en el extremo de la pantalla lo que generaba una sensación de desorientación. Esto es algo con lo que cada programador de Wii ha tenido que lidiar desde entonces.
Elección de motor y cambios de plataforma
El cambio de la plataforma de destino causó serios problemas . A lo largo de sus cuatro años de desarrollo, la plataforma de lanzamiento pasó del PC (donde fue un prototipo) a Xbox (en el que inicialmente tenía que estar), vuelta al PC (en preparación para portarlo a Xbox 360), a Xenon Alpha, entonces Xenon Beta, y por fin a Xenon/360.
Incluso en el hardware final, hubo importantes actualizaciones de software del sistema cada pocos meses. Cuando por fin la plataforma se estabilizó durante el último año de desarrollo (con posterioridad al lanzamiento de hardware), la eficiencia del desarrollo aumentó de forma masiva.
Con un equipo de desarrollo relativamente pequeño para empezar y la dificultad para contratar personal con experiencia, la política era poner en soluciones de middleware con idea de reducir el tiempo de desarrollo. Con mucho, el más importante de ellos fue el motor «RenderWare» de Criterion.
Medidas
En un juego como Tomb Raider: Underworld donde el jugador puede interactuar con elementos muy diferentes del entorno de muchas maneras, los indicadores y las medidas son muy importantes. Constituyen la base para conseguir que Lara Croft resulte ágil y creíble, eliminando controles toscos que impidan la evolución en el personaje de manera fluida.
En su día Tomb Raider: Legend sufrió cambios en las distancias de salto, los parámetros de tamaño de cornisa y otras métricas hasta fases muy avanzadas de desarrollo, dando lugar a incontables horas de correcciones para los diseñadores y artistas (era más dolorosa para los segundos) y estábamos decididos a evitar esto en la secuela.
Nuestros diseñadores de sistemas establecieron indicadores para cada aspecto que definía la relación entre jugador y juego con valores inamovibles hasta crear un sistema completo al comienzo del proyecto. Por supuesto hubo ajustes y se hicieron algunos cambios más tarde, por lo que hubo que tapar agujeros, pero en general fue una gran mejora respecto a títulos anteriores.
RATCHET & CLANK FUTURE: TOOLS OF DESTRUCTION
Desarrollar dos juegos al mismo tiempo
Además de trabajar en un nuevo hardware, resultaba un desafío tener dos juegos en desarrollo simultáneo (Resistance) y como consecuencia sufirmos mucho.
Anteriormente, centrábamos el esfuerzo colectivo de nuestro estudio en sólo un título a la vez de modo que cualquier tema importante podía recibir la atención de toda nuestra empresa si era necesario.
Ahora sin embargo era necesario trabajar compartiendo recursos de modo que ciertas personas no estaban siempre disponibles.
Lo que resultó más difícil todavía que «compartir» personal fue «contratar» nuevo personal. Cuando RCF entró en producción estábamos faltos de personal, sobre todo en nuestro equipo de programación. Sin embargo por no saber ajustar nuestros planes a tiempo mantuvimos erróneamente la esperanza de que íbamos a encontrar la persona adecuada en breve para cada puesto.
Al final no terminamos de contratar gente hasta tres meses antes de sacar el juego a la venta, lo que significa que varios departamentos con personal insuficiente tuvieron que afrontar trabajo extra, con los consiguientes problemas que ello plantea.
El realismo es complicado
A pesar de que dimos una gran cantidad de pasos adecuados en la dirección adecuada para desarrollar una historia realista y con carácter propio, subestimamos el impacto que ello tendría en el realismo de la parte jugable. Un buen ejemplo de ello fue los problemas a la hora de ajustar la salud de los enemigos.
Inicialmente se estableció que los enemigos aguantaran un montón de impactos antes de morir, de modo que cada enemigo resultara un oponente formidable.
Sin embargo, pronto empezamos a recibir comentarios de los testeadores a los que esto les parecía muy poco realista que los enemigos aguantaran más de un par de tiros antes de morir. Esto significaba que tuvimos que volver a rehacer ltodas as batallas generando oleadas de enemigos para compensar dicho cambio.
Fallos en el final de la historia
Cometimos el error de no dedicar suficiente tiempo a la última hora de la historia. Yo estaba convencido (y con razón) de que la primera hora del juego sería decisiva para enganchar al jugador, pero pensé ingenuamente que a una hora del final la opinión del jugador ya estaría formada así que dediqué la mayor parte de mi tiempo al resto del juego con el fin de que fuera lo más perfecto posible.
Esto era obviamente un error. Pasé por alto que lo que deja una impresión duradera en el jugador es a menudo el final, y que un mal final puede cambiar su percepción de todo el juego.
Barreras culturales
No hubiéramos terminado por completo este proyecto a tiempo sin la ayuda de otros estudios de UbiSoft. Sin embargo, la composición diversa del equipo hizo que el trabajo en conjunto fuera más difícil. Muchos de los problemas que nos encontramos derivaba de las diferencias culturales.
La barrera más evidente fue el lenguaje. Tres idiomas diferentes : chino, francés e italiano.
Tuvimos que utilizar el Inglés como lengua de trabajo, pero no todo el mundo hablaba con fluidez el lenguaje y algunas personas ni siquiera lo hablaban en absoluto.
La primera vez que se convirtió en un problema fue durante la fase de formación del personal. Como todos los documentos técnicos estaba en inglés y el director técnico del equipo de diseñadores gráficos sólo hablaba chino e inglés resultaba muy difícil formar a los desarrolladores que no hablaban inglés.
Antes de que comenzara la producción se pensó en mezclar personas de diferentes países en un equipo grande, creyendo que esto ayudaría a la gente a conocerse rápidamente. Entonces nos dimos cuenta de que el problema del idioma hacía que resultara inviable, así que finalmente creamos dos equipos en su lugar: locales y extranjeros.
Cada equipo tenía un líder de equipo que se traduciría en la información del proyecto a su equipo. Sin embargo, esta estructura creó otros problemas:
1. Hizo el proceso de toma de decisiones más difíciles. Los dos líderes de los equipos a veces tenían opiniones diferentes sobre las técnicas, las modalidades de trabajo y las solicitudes de otros equipos. Lo peor era cuando los dos líderes del equipo daban información contradictoria a sus respectivos equipos, lo que naturalmente causó confusión.
2. Se creó sensación de la competencia. La gente inconscientemente – a veces conscientemente – consideraban al otro equipo de desarrolladores sus competidores. Aunqu algo así puede ser bueno en cierto modo, en general, la situación generó condiciones incómodas, impidió el trabajo en equipo y complicó la puesta en común de conocimientos.
Ambición Extrema
La ambición extrema puede ser un potenciador, pero también puede crear muchos problemas. Una gran parte de Gas Powered Games está formado por personal extraordinariamente ambicioso. Cada uno tiene sus propias razones, pero en conjunto todos queremos ser los putos amos. Si esta motivación nos ayudó a perseverar a través de algunos de los retos que nos encontramos durante el desarrollo, también generó otros nuevos.
Nuestra ambición se tradujo en un exceso de características de diseño y un alcance del proyecto que fue en última instancia más grande que nuestra capacidad para poder llevarlos a cabo. El problema se vio agravado por el hecho de que nadie en el equipo había trabajado realmente en un RPG de acción antes. Nos fijamos en la «marca líder» RPG y dijimos: «Hey, este es un género divertido. Vamos a hacer algo como esto, excepto que mucho, mucho más grande, en 3D, sin pantallas de carga, y además vamos a crear y revolucionar la tecnología necesaria para ello»
Está claro que no imaginábamos la enorme cantidad de trabajo necesario para construir el tipo de juego de rol que queríamos, y desde luego queríamos todo tipo de cosas interesantes: sincronización de labios, cooperativo en red, soporte de doble monitor, terreno deformable, y muchas otras joyas.
Algunas de estas características en última instancia no encajaron finalmente en la visión de nuestro juego. A nuestro favor rechazamos la mayoría de estas características incluso antes de empezar el desarrollo, aunque algunas de ellas nos rondaron por la cabeza durante meses.
El FTP y la lejanía.
El estar situados en Australia no parecía ser un problema importante al comienzo del proyecto. Eramos capaces de hablar por teléfono por la mañana y si había una cantidad importante de material para enviar por correo ordinario sólo tardába en llegar un par de noches. No fue sino hasta que fuimos a dar a luz la primera beta que empezamos a darnos cuenta de la gravedad del problema.
Tardábamos aproximadamente cuatro días en enviar por mensajería un disco a los Estados Unidos era . El FTP era la única alternativa y resulta que el FTP de nuestras oficinas sólo alcanzaba una velocidad de unos 5KB/sec. Esto significaba que llevaba alrededor de dos días cargar el juego completo cosa que teníamos que hacer cada vez que producíamos una nueva versión.
GABRIEL KNIGHT 3
La moral del equipo
A todos los directores de proyectos alrededor del mundo: la moral es uno de esos temas personales y políticos que muchos tratáis de evitar, pero hay que entender que tu equipo de desarrollo no es una fábrica de producir contenido y código. Parafraseando a Peter Sellers «El equipo es un jardín de la creatividad que requiere un riego regular y el sol con el fin de construir un fuerte arraigo».
La lealtad no es algo que se gana con facilidad. El mercado laboral es muy competitivo – tus mejores desarrolladores sadrán y encontrarán trabajo si no son bien tratados y mantenidos correctamente. En GK3, hubo una gran falta de amor y aprecio durante todo el proyecto. El reconocimiento por el trabajo realizado era muy raro, carecía de sinceridad, y siempre era poco, y llegaba demasiado tarde.
Por el mero hecho de poner muchas cosas molonas, no significa que el conjunto termine molando.
Cuanto más cosas pongas en un juego, más cosas podrán ir mal. El diseño de niveles, en particular, se ha vuelto demasiado complicado en los juegos modernos como para que lo controle un solo individuo Ser diseñador de niveles ya no es simplemente hacer unos cuantos cuadrados con pasillos de conexión y ya no te limitas a colocar los personajes en un mapa confiando en que sea su propia IA la que gestione sus movimientos.
La demanda de realismo detallado requiere cotas casi inalcanzables de realismo para aegurar el éxito. Todos y cada uno de los personajes deben de ser colocados con rutas y direcciones así como puntos de escape y puntos que les otorgan ventajas durante el ataque y la mayoría de todo su comportamiento debe ser escrito.
La interacción con el entorno también crece exponencialmente a medida que los diseñadores de niveles tienen el control sobre casi todos estos temas en sus niveles.
Un nivel normal ahora puede tardar más de dos meses en completarse y el testeo de todas estas mejoras que has añadido puede ser una pesadilla. El diseño de niveles se convertirá pronto en un departamento multidisciplinar, debido a estas crecientes demandas.
