POR FAVOR, NO DEN DE COMER A LOS PROGRAMADORES
Hay una leyenda urbana ampliamente extendida de que, muchas veces, el problema para hacer un juego es que “es muy difícil encontrar buenos programadores”. Quizás haya una parte de verdad en eso, pero como todo argumento que parece demasiado arbitrario para ser real, es una cuestión de expectativas erróneas.
Normalmente, una persona que se pone a hacer un juego amateur suele pensar, lo primero, esto: “Vale, no podré ofrecer los medios técnicos de los grandes estudios. ¡Pero mi juego tendrá chorrocientas armas, e ítems, y relaciones interpersonales con el SCP (Sistema de Corazones Paralelepípedos) y su puta madre!”
Cuando dice eso, la traducción la podríamos hacer por “OK, se qué no puedo esperar que mis tres grafistas sin casi experiencia me ofrezcan las animaciones, acabados, extensiones kilométricas y brillisbrillis en general, que ofrece un equipo profesional de ciento veinte personas. No obstante, espero qué un único programador, con menos experiencia aún, me ofrezca ampliamente más que un equipo de primer nivel de sesenta personas”.
Hay varios elementos que permiten que se de pie a este equívoco. El primero suele ser el propio programador, muchas veces sin experiencia alguna (programar en basic cuando Enrique y Ana lo daban todo, no nos vale), al menos en lo que es programar un videojuego y plenamente convencido de que puede. En muchos caso, ha hecho ya los subprogramas en simuladores de aplicación de consola, y cree que “implementarlos en el juego no costará mucho”…
…iluso…
El segundo factor es el “factor 2D”. El avance tecnológico tiene sus cosas buenas y malas. Una de las malas es el desprecio instantáneo a lo que valía hace cuatro días, y la idolatría a lo nuevo. Sólo así se explica que las aventuras gráficas se emperren en salir en 3D. El caso es que la gente, por lo que sea, tiene la idea de que si un juego se hace en 2D, se haga lo que se haga con él (como si haces el puto Skyrim con los tiroteos del Mass Effect) será muy fácil, un paseo, vamos, y cualquier cosa que se haga en 3D, será muy difícil, sólo al alcance de un profesional venido del futuro… cuando para cualquier cosa que implique algo más que mover y colisionar un muñecos será siempre más sencillo en 3D, aunque sólo sea por la ayuda que te dan los tropecientos motores y funciones que hay a paletadas por la internné.
Y claro, con estas dos cosas, empiezan los problemas. El programador jura y perjura, en su mente todo era fácil, pero realmente, la realidad que él se había planteado era la de una persona (concretamente yo) que tuviese pensado poner el lápiz en el papel y no levantarlo hasta haber terminado todos los dibujos. NI UNA RAYA IBA A BORRAR. Y claro, el faraónico proyecto de 8700 líneas de código tiene 23000 warning y 1340 errores, y el chaval dice que lo corregirá, pero porque es incapaz de aceptar que el volumen de trabajo que ha aceptado es inasumible para un único ser humano. Si no, le pueden preguntar que opina al creador de supermeatboy.
Y el resto del equipo se quema y le echa la culpa al programador, que a su vez está al borde de un colapso nervioso tomando coka colas cada media hora, lo cual, que sea malo para él es lo de menos. Lo realmente preocupante es que así trabaja peor.
Y es que nunca, repito, nunca, señor programador, debe usted ser complaciente. Es el elemento que me quedaba por mirar. Usted piense que cuando alguien le pregunta algo, esa persona no tiene ni puta idea de lo que pregunta porque programar es de genios autistas. A veces, algo fácil de implementar quedará sin ser preguntado porque al diseñador “le sonaba difícil”. Otras veces, pedirán cosas complicadísimas porque “parece fácil”. Así que es simple, si alguien te viene con una cosa que es un marrón, tú dile que no se puede. No digas “bueeeno, quizás si….” o “se podría, peeerooo…”. Amigo programador, simplemente di no. Recuerda los anuncios de los 90. Recuerda a Pedobear. No dejes que toque tu código fuente si no quieres.
Porque luego la frustración es para todos. A veces será un poco culpa tuya. Era fácil, pero en principio no se iba a meter y ahora es como pedirte que lo rehagas casi todo. Otras, sencillamente, no compensa. Cuando te preguntan algo, piénsatelo, y si no le ves claro, di “lo miraré” o di “no se puede”, directamente. Si te miran raro, échale la culpa al Hardware (“que vamos cogidos de RAM”) al software (“el proceso de renderizado ofrece problemas con el AA y se borraría”) o a cualquier otra cosa.
Hay montones de proyectos que se quedan en nada por este motivo. Por tener una ambición desmedida desde el punto de vista técnico. Lo que a mi me dicta la experiencia según las peleas con JJ, es que te demuestres primero que eres capaz de hacer un Space Invaders, y luego te demuestres que puedes hacer un Space Invaders con subida de nivel, caminos alternativos y demás zarandajas. Muchas veces, ofrecer mejores gráficos solo significa cambiar los dibujos por dibujos mejores. A nivel de programación no supone nada.
Con estos pequeños consejos del que mira como programa otro, su juego no será mejor, y quizás eso les joda. Pero al menos los terminarán algún día, si no sufren algún robo de sus proyectos. Aunque eso sí, hagan lo que hagan, no den de comer ni coka cola a los programadores después de las doce. Yo se lo he advertido.