Pese a que el desarrollo de videojuegos evoluciona a un ritmo demencial, hay ciertos conceptos, que podemos llamar «de base», que no cambian de ninguna de las maneras. Uno de ellos es el referente a los preparativos para el tan murphyano principio de la tendencia al desastre. ¿Qué podría salir mal? Quizás la pregunta adecuada sea la contraria. Qué no podría.

Me presento. Soy Luis Rodero, programador en Frictional Games, y voy a hablar sobre esas cosillas que pueden ocurrir durante un desarrollo y que no son lo que se dice buenas. Como nota introductoria, el siguiente texto lo escribí la semana anterior al lanzamiento de Amnesia: The Dark Descent, en septiembre de 2010. Han pasado ya más de 3 años, en los que he estado 100% dedicado al siguiente proyecto de Frictional Games (SOMA), y poco puedo añadir a lo que vas a leer a continuación. Una de dos, o ahora lo estoy haciendo tremendamente bien, o realmente tuve muy mala suerte durante el desarrollo de Amnesia. Personalmente, voto por lo último.

Poniendo las cosas en contexto, para los nuevos, Frictional Games es un estudio sin oficina. Es decir, todos y cada uno de los miembros trabajamos desde nuestra propia casa. Mi labor principal en Frictional es desarrollar las herramientas que usamos para crear contenidos para nuestros juegos. Actualmente contamos con un editor de niveles, otro de entidades o actores, otro de sistemas de partículas y por último, otro de materiales. Estas aplicaciones actualmente, y salvo situaciones especiales —como por ejemplo tener que ayudar a terminar la versión alfa que terminamos hace unos cuantos meses— se llevan el 100% de mi tiempo, con lo que cuando hablo de mi proyecto, principalmente me refiero a dichas herramientas. Ahora bien, ¿qué puede frenar el normal desarrollo de un proyecto? Pues puede haber miles de causas diferentes para que algo así ocurra, pero creo que podemos clasificarlas en unas pocas categorías, que voy a listar ahora mismo:

Mal (o no muy buen) diseño

Este punto en concreto es origen de problemas, problemas y más problemas. Piénsalo, si te limitas a parchear las cosas para dar soporte a tus necesidades actuales, vas a necesitar un buen montón de suerte para que eso se sostenga si hay que hacer algún añadido posterior. Además, algo así está destinado a fallar en un futuro. Todo esto suele acabar en tener que reescribir cosas desde cero (o casi cero), y eso se traduce en tiempo en el que el proyecto no avanza.

Por ejemplo, al inicio del desarrollo del editor de niveles hice un sistema de gestión de objetos (aquí con objeto me refiero a toda pieza que forma un nivel) que funcionó perfectamente con los 3 tipos distintos que teníamos en aquel momento. Unos pocos meses más adelante necesitamos incluir 2 tipos más de objetos, y ¡tachán!, el primer diseño ya no valía. A tomar viento el antiguo sistema y a hacer uno nuevo que soportase los nuevos tipos además de los objetos ya creados con las primeras versiones. Entonces de repente se necesita un nuevo tipo y, claro, el diseño no lo soporta… y así sucesivamente. Por suerte, me las apañé para hacer un sistema más o menos genérico que arreglara esto, pero adivina: ¡ya está pidiendo una reescritura! Por no hablar de cómo están manejadas las transformaciones geométricas de los objetos, que por ahora funcionan, pero me gustaría mejorarlas en algún momento.

Así que, ¿qué aprendemos de todo esto? En resumidas cuentas, el lazy design es algo que se debe evitar a toda costa, y encima tienes el control absoluto sobre algo así, ¡así que no permitas que ocurra! Estás avisado. Además, si caes repetidamente en este error, la cosa puede desembocar en…

Falta de motivación

Este apartado es bastante peligroso. Por poner un ejemplo, no es nada gratificante despertarte al lado de tu puesto de trabajo, desayunas, te sientas allí solo, con temperaturas superiores a los 35ºC (el encantador verano español), y tener que ponerte a cazar un bug aleatorio entre más de 1000 líneas de código. Te levantas, comes, te vuelves a sentar, las horas pasan y te vuelves a la cama a dormir. Esto fue mi día a día en aquel mes y medio pre-lanzamiento. Estaba deseando muy mucho cogerme unas vacaciones, por si alguien lo dudaba.

Todo lo que se pueda listar aquí es malo por sí mismo, pero además puede derivar en problemas incluidos en la categoría de arriba. Cuando trabajas en estas condiciones, es mucho más probable que cometas errores, a menudo menores, pero también de los que dan lugar a bugs de esos que entran en la categoría de horribles. Además, al trabajar así, incluso la tarea más simple te puede robar tiempo. Creedme cuando digo que no es para nada bueno.

Force Majeure

Lo que se viene conociendo por aquí como «Fuerza mayor». Recuerda la Ley de Murphy: todo lo que pueda salir mal, saldrá mal. Por norma general se trata de interferencias externas, cosas que ocurren en tu entorno sobre las que se tiene poco o ningún control. Entre ellas se incluyen:

• Cortes de luz de media de dos horas de duración.
• Fallos eléctricos con chisporroteo, arcos voltaicos y su consiguiente riesgo derivado de incendio.
• Agua proveniente del piso de arriba inundándote el tuyo.
• Cortes prolongados de Internet
• Que se te rompa el portátil
• Que se te rompa el portátil (no es un error, pasó una segunda vez)
• Comprar un ordenador de repuesto para el portátil muerto y acabar descubriendo que también está defectuoso.
• Que absurdamente te llamen a juicio por una acusación de estafa, todo sin sentido alguno.

Aunque pueda sonar a guasa o exageración, todas las historias mencionadas son ciertas y demasiado largas para explicarlas aquí (aunque podría explayarme si me lo piden). Bauticé esto con cariño como «la Maldición de Frictional», y parece afectar exclusivamente a miembros del equipo principal de Frictional que vivan fuera de Suecia (servidor, concretamente). Al menos no perdí nada del trabajo hecho. Qué puedo decir…

Por desgracia, todo lo anteriormente descrito no es más que una pequeña muestra de las múltiples formas que puede adoptar el desastre. A estas alturas, no puedo dar mejor consejo que el de aprender a vivir asumiendo que hay una posibilidad de que las cosas se tuerzan, y en el peor momento posible. Una vez lo aceptes, no se van a reducir las posibilidades de que ocurra, ¡pero al menos no te pillará por sorpresa!

The end

Y ahí termina el texto que escribí allá por 2010, con unas mínimas modificaciones. Pero ahora me gustaría hacer alguna puntualización que no pude en su momento, bien por no tener la suficiente experiencia o simplemente por no haberlo visto tan claro como ahora.

En el apartado sobre el diseño, no todo lo que dice el Luis del pasado es inamovible. Al empezar algo desde cero, muchas veces no se tiene ni idea de qué va a hacer falta en un futuro. Este conocimiento es algo que se va adquiriendo sobre la marcha, mientras van surgiendo necesidades que satisfacer. El ejemplo del sistema de gestión de objetos es bastante revelador en este aspecto, me hicieron falta dos «encontronazos» para descubrir el patrón para poder añadir nuevos tipos de forma más cómoda. De no haberlos tenido, jamás hubiera podido llegar al sistema actual. Ahora bien, si todas las necesidades están perfectamente definidas desde el principio, las excusas válidas que quedan para el lazy design son la de la inexperiencia y la de la prisa por alcanzar un plazo.

Por otro lado, ya no creo que sea tan sano hablar de reescrituras tan alegremente. Cuando un proyecto alcanza un tamaño considerable, hay que tener mucho cuidado a la hora de actualizar un componente o una interfaz. De lo contrario podemos encontrarnos hoy, mañana y pasado modificando esa mitad del proyecto que dependía del minúsculo cambio que introdujimos ayer. Con esto quiero decir que hacer actualizaciones y mejoras es bueno, siempre y cuando se hagan con cabeza.

Respecto a la falta de motivación, es un riesgo que siempre va a estar ahí. En un desarrollo siempre va a haber altos y bajos, y siempre tendemos a verlo todo negro cuando las cosas van regular. Cuando esto ocurra, para en seco, piensa en lo que has hecho hasta el momento, échale un ojo a lo que están haciendo tus compañeros, sal un poco, búscate alguna actividad que te ayude a desconectar. Lo que cuento arriba describe un periodo de crunch, en los que por lo general hay menos opciones, pero siempre hay que intentar poner de nuestra parte y venirse arriba como sea. Y si nunca encuentras motivación en desarrollar un videojuego, es posible que debieras dedicarte a otra cosa.

Por último, repasando el apartado de Fuerza Mayor, tengo que decir que «la Maldición de Frictional» ha sido bastante suave desde entonces, ya que no ha vuelto a ocurrir nada parecido a lo comentado más arriba, ni a mí ni a mis nuevos compañeros no-suecos. Quizá algún corte de luz que otro, pero la verdad es que ahora estoy bastante más tranquilo. Puede que haber podido mudarme de piso haya tenido algo que ver, pero cualquiera sabe. Mejor será no bajar la guardia.

Aquí es donde me despido. Espero que esto le sirva de ayuda a alguien o, en el peor de los casos, que se pueda echar unas risas a costa de mis desgracias pasadas. Happy developing!