CMPGPV: Como Manejar Proyectos Grandes de Programación de Videojuegos

introducción: Capitán de mar y guerra

Proyectos, proyectos y proyectos. A lo largo de mi tiempo queriendo hacer videojuegos y un tanto mas como programador me he topado muchas veces con la misma historia. Proyectos de videojuegos que no llegan a ninguna parte. Grandes ideas que se quedan solo en eso y que nunca llegan a ser jugables. Y no crean que esto solo se ve en aficionados que no han programado nunca en su vida. También lo he visto en grupos de programadores muy avanzados. Yo mismo tengo varios proyectos muertos y enterrados por ahí. Lo que nos lleva a la pregunta: ¿Dejar un proyecto de programación de videojuegos tiene algo que ver con la habilidad del programador? La respuesta es no. Pero antes veamos una historia para ver de quién es la culpa.

Remontémonos a la época de los grandes navegantes, ambiciosos piratas y batallas navales. En esos tiempos los barcos de guerra no tenian uno sino dos capitanes: Uno era el mismo que tenía cualquier otro barco y que sabía como navegar y orientarse en el mar mientras el otro era el que sabía como combatir y estaba a cargo de la batalla. En esos tiempos sobrevivir no era cuestión solamente de saber pelear pues uno de estos poderosos barcos era capaz de hundir a toda una flota enemiga sin una sola baja y sin embargo regresar al puerto con menos de la mitad de la tripulación por culpa de enfermedades, accidentes o cualquier otro error que cometiera el capitán de mar.

Pues bien, he conocido muchos casos (el mio incluido) de programadores experimentados que dejan sus proyectos a medias o con tantos errores que sus programas son virtualmente inútiles. Es común escuchar a programadores que no reconocen su propio código luego de haberlo dejado de lado por tan solo una semana o el caso mas común de sistemas tan mal diseñados que el autor tiene que regresar una y otra vez a cualquier hora del dia a solucionar un problema. En esta serie verán que esto no tiene tanto que ver con si un programador es bueno o no.

Regresando a los guerreros antiguos nada garantiza que ganaremos la guerra solo porque podamos ganar todas las batallas. En la guerra hay muchas mas cosas que pueden matarnos además de las armas: Poderosos barcos de guerra se perdieron en el mar, ciudades amuralladas vieron morir a sus defensores por falta de alimentos, soldados murieron de frio al intentar invadir Rusia en tiempos de Napoleón y muchos otros en climas cálidos fueron víctimas de enfermedades tropicales y cayeron mucho antes de enfrentarse al enemigo. Por no mencionar la gran cantidad de efectivos que regresaron de la Primera Guerra sin piernas no por culpa de las balas y las bombas sino por tomar a la ligera el lodo y humedad acumulados en el interior de sus botas. Pero los tiempos han cambiado y hoy en dia si revisamos el equipo que portan los actuales soldados veremos que menos de la cuarta parte de lo que cargan son armas. La mayor parte de lo que llevan son cosas como provisiones, medicinas y herramienta que les permitieran cosas tan elementales como dormir o ir al baño en plena naturaleza. Algunos están tan bien equipados que pueden sobrevivir sin problemas por dos semanas antes de ser rescatados. Por no mencionar que cuentan con sistemas de comunicación y una red de computadoras y personal que les ayuda y brinda información para sobrevivir en sus misiones.

En esta serie discutiremos esos aspectos de sobrevivencia adaptados a programación en este caso de videojuegos que es el tema donde mas he visto y vivido este tipo de situaciones. Si alguno de ustedes que estudió y leyó un poco mas que las presentaciones de Power Point en sus clases de ingeniería en computación tal vez algunas de las cosas que voy a mencionar en esta serie se les hagan conocidas. Pues hay muchos libros que hablan sobre como administrar proyectos grandes de programación pero tales lecturas son tan somníferas y tediosas que nadie de los que vengan aquí seguido va a querer leer. Así que les pido que si tienen algún comentario al respecto tomen esto en cuenta. Estos escritos no tienen ni pretenden tener nada de eso que llaman rigor académico.

Una Guerra de Cinco Fases:
Espionaje, Estrategia, Asalto, Dominio y Expansión

Tan solo la parte de programación de un videojuego requiere mucho trabajo. No basta con escribir un código que funcione bien la primera vez. De hecho un proyecto de programación serio es igual que una operación militar que consta de cinco fases: Espionaje, Estrategia, Asalto, Dominio y Expansión. Veamos en breve cada una

Espionaje: En esta fase se investiga toda la información de lo que queremos programar. Ya sea nosotros o alguien que nos encargue hacer el proyecto. Esta información se recibe en forma de texto escrito y hay procedimientos mas o menos mecánicos que permiten extraer información que nos lleve a identificar cosas como estructuras de datos, módulos, funciones, variables y todo aquello con lo que vamos a trabajar. Es el equivalente a obtener un informe detallado del enemigo, el terreno y los objetivos.

Estrategia: Una vez con la información sobre qué es lo que vamos a hacer lo que sigue es definir como hacerlo. Para ello existe una construcción gráfica que define el sistema completo. Piensen en esta construcción como el mapa del territorio enemigo. Este mapa contiene información de todo tipo siendo las mas importantes la manera como circulan los datos dentro del programa y el código que se encarga de trabajar con estos mientras se mueven. Esta etapa puede parecer larga y aburrida pero si se hace bien acelerará por mucho la programación, disminuirá el tiempo de reparación de errores y sobre todo permitirá poner al corriente a cualquiera que intente unirse al proyecto.

Asalto: Esta es la primera parte donde entra la programación. Si el mapa definido en la fase de estrategia es bueno el programador puede hacer cosas que se antojarian imposibles sin él como por ejemplo trabajar en diferentes puntos del sistema o pausar y retomar el trabajo en cualquier momento. También es posible repartir el trabajo entre muchos programadores disminuyendo el riesgo de que sus códigos se estorben entre si o aislar los módulos para aminorar la posibilidad de que un error en uno de ellos afecte los demás. Esta es la parte mas emocionante pero también donde puede haber mas caos. Es importante que el progamador recurra con frecuencia a toda la información generada en las 2 etapas anteriores cada que se sienta perdido. Otro punto de esta etapa es que ya se tiene un producto que aunque no está terminado es mínimamente usable

Dominio: No basta con tener un sistema que funcione para nosotros si no podemos garantizar un mínimo de confianza. La fase de dominio consiste en buscar todas las amenazas y debilidades de nuestro nuevo sistema y corregirlas. Si en la guerra que es programar un proyecto grande la fase de asalto fue apoderarse de un territorio enemigo la fase de dominio consiste en localizar y eliminar a la resistencia así como mejorar las defensas en los sitios vulnerables por donde nos puedan atacar. De nuevo el mapa estratégico y los informes de inteligencia nos pueden dar información que nos ayudará a dar caza a estas amenazas.

Expansión: Pero ningún sistema es perfecto o al menos no tan perfecto como para permanecer sin cambios por siempre. Los cambios para detectar y neutralizar amenazas son pocos en comparación con los cambios que hay que hacer para que el sistema se adecue a nuevas necesidades. Tarde o temprano llegará el momento en que queramos adaptar nuestro juego a nuevas plataformas, agregar nuevas características o simplemente tomar alguna de sus partes para poder usarla con confianza en proyectos futuros. Hay una manera organizada de hacer cambios en los proyectos de programación que reduzcan la aparición de nuevos errores al mínimo. Un proyecto de programación bien diseñado puede intercambiar cualquiera de sus partes sin poner en peligro el resto del sistema.

En fin, en esta serie veremos como manejar proyectos grandes de programación sin correr los peligros que hacen que estos queden inconclusos. En la siguiente entrada veremos lo mínimo que necesitamos para mantener estas bestias controladas. Sistemas que pueden ir desde una libreta y un lapiz hasta un cuarto lleno con personal de apoyo. Por cierto, para escribir esta serie estoy usando una versión adaptada del mismo sistema que les estoy describiendo aquí así que lo mas seguro es que esta serie si llegue a su final o en el peor de los casos no salga a la luz. Tal vez me tome meses termirarla pero esta vez termirará. Sin mas los dejo y prepárense porque participar en un proyecto grande de programación es entrar en una auténtica guerra.