Desde hace poco más de un año he estado trabajando de la mano con Christian y Julián en un proyecto de mediana envergadura llamado Dark Recon. El juego, en pocas palabras, es un shooter-puzzle en tercera persona con vista isométrica orientado un jugador dedicado, o lo que se llama hardcore. Más allá de describir el juego per se, porque más allá de hablar del juego lo importante es desarrollarlo, hay varias lecciones que he ido aprendiendo en este tiempo de experimentación que vale la pena compartir.
Lo importante es mostrar y resolver
Aunque pueda sonar un poco mediocre a nivel académico, lo importante no es si la solución es la óptima, más eficiente, o la más limpia; lo importante es entregar tan pronto como sea posible. Esto, al menos, en la fase inicial de desarrollo de gameplay e ideas para que a nivel de diseño se pueda realmente aprobar o descartar lo que en papel pareciera ser el camino a tomar. El papel aguanta todo, pero el feedback del jugador es realmente la pieza más importante del proceso inicial del desarrollo del “juguete” y primer prototipo del juego.
Esto no quiere decir que sea aceptable tener un código totalmente desorganizado y falto de modularidad; la idea es que exista un balance y tratar de hacer las cosas bien desde el principio. ¿Cómo saber si algo se está haciendo bien? Experiencia. Mientras más se desarrolle, más se le meta mano al código y más se itere, es más fácil ver patrones y encontrar maneras de optimizar para ajustar cambios.
Sobreplanificar está sobrevalorado
No es posible ver más allá de las primeras entregas y no es viable planificar de más porque, al final del día, el desarrollo de un juego es iterativo y experimental; no es un software a la medida con especificaciones “duras” de inicio a fin. Esto sucede mucho en la formación académica en donde lo ideal es abstraer lo suficiente como para ofrecer una solución general al problema que tenemos en la mano. Sin embargo, el desarrollo de juegos es similar en este sentido al desarrollo de un truco de magia. Nosotros conocemos qué tenemos y qué no tenemos, por lo que la forma de avanzar más rápido es resolver el problema específico y en base a eso resolver el problema general, si llegase a hacer falta.
Refrescar las bases en la medida de lo necesario
Si hay conocimientos de algoritmos, matemáticas y física que por algún motivo no recordamos, son etéreos o desconocemos, es humanamente poco factible nivelarse bien en el área antes de continuar. La meta es desarrollar juegos y aprender en el camino. Al encontrar una pared técnica lo importante es sortearla de la mejor manera posible con el montón de recursos en línea: videos en YouTube, láminas, tutoriales. Lo importante es entender rápidamente el problema de base, y luego buscar la solución en código.
Sí es bueno tener algún libro técnico como lectura recreativa de nivelación así como leemos novelas, blogs y revistas; pero existe la vida: responsabilidades, celebraciones, problemas, etc. Ésto es algo que normalmente tenemos cableado desde pequeños por la forma en la que aprendemos: si no tenemos las bases, no podremos avanzar. Lo que normalmente aprendes, y en mi caso por las malas, es que es posible aprender las bases caminando y construyendo. Quizás no sea lo óptimo, utópico o ideal (valga el uso de sinónimos), pero es necesario y punto.
Si existe una herramienta que te ayude, úsala
Esto tiene que ver con nuestra migración de XNA a Unity. Aun cuando el trabajo del 2012 fue en nuestro fluctuante tiempo libre, este 2013 pudimos hacer el trabajo de un año en 2 meses. No sólo la comunidad de Unity es grande y activa como para ayudarnos a resolver los problemas del juego con material existente en línea, sino que el motor tiene herramientas de mediano nivel que muchos APIs no tienen (raycasting, eres tú, perrito jajaja :D). Más allá de la publicidad que le podamos hacer a Unity, siempre recuerdo lo que Valve hizo para mover cielo y tierra a fin de licensiar el Quake Engine en su momento. ¿Podían crear un motor desde cero? De bolas que podían, pero la idea era tener una herramienta que facilitara las cosas a fin de mostrar y resolver a fin de dedicar esfuerzos en desarrollar Half-Life.
Aun así, con cada iteración se fueron agregando más y más cosas, a tal punto que se volvió un motor nuevo conocido hoy en día como el Source Engine. Esta experiencia hace match y es uno de los ejemplos perfectos al señalamiento de Josh Petrie en cuanto a “hacer juegos, no motores”.