¿Por qué no podemos ser amigos?

A veces parecemos políticos. Y no, no me refiero al "talante" de Zapatero, sino más bien a la continua regañina de Rajoy y sus compinches.

Está en los genes del hombre pelearse y organizarse en tribus, pero el conflicto entre diseñadores y programadores, tan antiguo que Ugh el cavernícola ya pensaba que Bork le había dado mal las especificaciones para organizar la caza del mamut, no beneficia a nadie.

Yo soy programador. Es cierto que he estudiado durante varios años para serlo, y me gusta pensar que este tiempo me ha proporcionado ciertas habilidades, más allá de las peculiaridades del C++, y me ha ayudado a desarrollar una forma de pensar estructurada. Me gusta analizar las cosas, me gusta tener algo claro antes de empezarlo. Me gustan la simplicidad y el orden. Si encuentro un problema, mi cerebro se pone a dividirlo en subproblemas y analizarlo antes de que pueda hacer algo para impedirlo.

Ahora bien, cuando me pongo a intentar inventar algo nuevo, a generar ideas revolucionarias, a ejercitar el pensamiento lateral, esa es otra historia. La creatividad se alimenta del desorden, del experimento fallido, de combinar lo que no tiene sentido combinar. Nos gusta trabajar en videojuegos porque es un entorno creativo, innovador. El diseñador es el responsable de ser creativo, y ese es un trabajo importante.

Ya hemos dicho en muchas ocasiones que el desarrollo de juegos no es una ciencia exacta. Incluso hacer una sencilla página web la mayoría de las veces tampoco lo es, y pocas cosas podría haber mejor estudiadas en los últimos años. Salvo que estemos haciendo un clon del Tetris, y aún en ese caso, va a haber aspectos del juego y de su construcción que desconoceremos, y que nos tocará aprender por el camino. A golpes, como suelen aprenderse la mayoría de las cosas. Esto vale para el diseñador que acaba teniendo que cambiar la mecánica de disparo, porque no encajaba con el ritmo de juego esperado, o para el programador que tiene que rehacer la pipeline de procesado de texturas porque había un problema con el canal alfa.

Es posible que durante este proceso de aprendizaje, desarrollo y crecimiento, el programador tenga un enfoque más analítico para solucionar problemas. Es posible que diga "ahora no es realista hacer una herramienta para colorear la sintaxis del script en el editor". También es posible que espere una visión más nítida del proceso de la que es realista esperar. El programador querrá saber cuantas balas por segundo y con qué ángulo de dispersión disparará el AK-47 antes de que se haya decidido si el juego es o no futurista.

El valor del diseñador en todo este proceso no está sólo en introducir unos números y colocar unos enemigos en el editor. Está en saber qué números y qué enemigos. Está en idear nuevas números que introducir, y nuevos tipos de enemigos que colocar. Al diseñador no le gusta cerrarse puertas. Posiblemente diga algo como "vamos a probar poniendo 30 unidades en cada tropa, pero esto puede cambiar". Y le gustaría poder convertir el juego de un Doom a un Fifa o a un Starcraft ajustando unos números en un fichero.

Ambos perfiles están destinados a enfrentarse, pero condenados a entenderse. Un equipo es la suma de toda la gente que hay en él. Toda. Si los programadores no respetan a los diseñadores, probablemente vean los cambios como caprichos, como el resultado de no saber lo que se está haciendo, y no como ideas fallidas, que en su momento parecían dignas de mérito, y que sirven de peldaño para llegar a las buenas ideas. Si los diseñadores no respetan a los programadores, pedirán herramientas imposibles y lo justificarán apuntando a otros paquetes de software y señalando que todo eso está ya funcionando, sin pensar que el esfuerzo de un desarrollo así quizás sea difícilmente recuperable y podría tener un impacto duradero.

A todos nos gustaría trabajar en ese estudio maravilloso, donde los programadores escriben código óptimo y sin bugs a velocidad de vértigo, y los diseñadores presentan documentos precisos y detallados, con todos los aspectos definidos y resueltos. Pero no existe, así que tenemos que salir adelante con lo que tenemos. Si a los diseñadores les falta experiencia, entonces los programadores tendrán que hacer un esfuerzo extra para facilitarles el aprendizaje, y compensar los errores que puedan cometer. Si es el equipo de programación el más débil, entonces los diseñadores tendrán que asumirlo y entender que posiblemente las herramientas sean sencillas y tengan bugs, que quizás tengan que ser más selectivos con los cambios que introducen, y que les tocará también hacer un esfuerzo extra para introducir el contenido.

Pero ante todo, hay que evitar caer en el error de cavar un foso alrededor de un equipo, para "protegerlo" del otro. No hay que dejarse llevar por el ego y menospreciar el trabajo, la dedicación y la ayuda que el otro equipo puede prestar. Ni es práctico que los diseñadores escriban un documento de 500 páginas y lo tiren por encima de la valla para que los programadores lo construyan, ni lo es que programación se cierre en banda y se niegue a escribir código o cambiar nada hasta que exista una definición milimétricamente precisa, o decida escribir algo ignorando los requisitos.

Apoyándonos unos a otros, siempre con honradez y camaradería, será más fácil sacar adelante el juego, habrá mejor convivencia, y los errores de unos y otros pesarán mucho menos. Es hora de terminar con la rivalidad y la sospecha. Hora de ponernos en el lugar del otro sin juzgarlo, y trabajar juntos con un objetivo común.

Mostrar/ocultar resto...