Ingeniería de Software y Videojuegos

Arte y Ciencia… Son los dos primeros términos que se me vienen a la mente cuando hablo de videojuegos. De hecho, cuando asisto a una charla o conferencia relacionada a videojuegos, me encuentro muy a menudo con dos grupos bien diferenciados: Por un lado los artistas (músicos, diseñadores, ilustradores, entre otros), y por otro lado a los programadores (técnicos, científicos de computación o ingenieros). Mucho ya se ha hablado sobre si un videojuego es arte o no y siento que hoy por hoy no hay un consenso establecido. Como ingeniero, no es de mi competencia dar un juicio crítico acerca de ello, sin embargo, al estar dentro del grupo de los programadores, también tengo una sensación de que aun no queda muy claro si para construir videojuegos es necesario tener un mayor contexto que el de la programación, como la ingeniería. Por ello, me gustaría analizar un tema que casi nunca es  tomado en cuenta cuando se discute acerca de la construcción de un videojuego: La Ingeniería de Software.

Para comenzar, quisiera citar a Jesse Schell, autor del libro “The Art of Game Design”, en el cual, en uno de sus apartados discute acerca de los ciclos de diseño-programación, en donde menciona que para poder afrontar ciclos prolongados de prueba y mejora, el diseñador de juegos debe saber como hacer para que cada ciclo valga la pena y como llevar a cabo los ciclos mencionados lo más rápido posible. En dicho apartado, el autor concluye: “Los ingenieros de software han pensado mucho sobre este problema durante los últimos 40 años y han logrado desarrollar algunas técnicas bastante útiles”

Lo anterior me lleva a pensar en los muchos métodos que los ingenieros de software han ido desarrollando, mejorando y modelando, según el autor durante 40 años, y que en la actualidad siguen evolucionando, llegando a existir diferentes métodos formales de construcción de software, unos derivados de otros, y que en algunos casos llegan a aplicarse al pie de la letra y en otros, sólo sirven de referencia para crear un método adaptado a un contexto en específico. Sin embargo, sin una buena comunicación entre ingenieros, diseñadores de juegos y artistas, no habría una correcta sinergia entre los grupos. A continuación, propongo un modelo de interacción entre algunas disciplinas que, pudiendo haber más, intervienen en el proceso de construcción de un videojuego:

Interacción propuesta entre disciplinas

Si observamos el modelo propuesto, podríamos afirmar que las expresiones artísticas, así como el diseño de juegos (o más conocido actualmente como game design en inglés) muy poco tienen que ver con la ingeniería de software. Sin embargo, tanto artistas y diseñadores así como ingenieros deben llevar a cabo un proceso sinérgico con el objetivo de materializar el producto final. Personalmente, considero que dicha sinergia es necesaria, hasta en cierta forma obligatoria, para que el proceso de construcción no se torne quizá en algo caótico. Es así, que se podría conceptualizar a la ingeniería de software, bajo el contexto de la construcción de un videojuego, como una disciplina de soporte tanto para el arte como el diseño.

Ya con ese concepto en mente, podemos suponer que en la mayoría de nuestros proyectos de creación de videojuegos, desde el punto de vista de la ingeniería de software, deberíamos implementar, de alguna manera, un método sistemático y disciplinado que logre procesar de forma correcta los outputs de los diseñadores y artistas. Para ello, se han desarrollado varios modelos de construcción de software, que en complemento con los métodos formales, fácilmente podrían ser aplicados en los videojuegos, ya que al fin y al cabo, éstos últimos son productos de software (Software de Entretenimiento). Permitanme, entonces, citar algunos de los modelos más conocidos actualmente:

– El modelo iterativo incremental: Es hoy por hoy el modelo más utilizado y sobre el cual muchos métodos, tanto ágiles como tradicionales, logran establecer su marco de trabajo. Entre ellos, RUP, SCRUM, XP, etc. Su mayor ventaja es entrega temprana de versiones funcionales del producto.

RUP y su modelo iterativo-incremental

Iteraciones evolutivas ágiles de SCRUM

– El modelo espiral: Basado prácticamente en riesgos y prototipado. Se desarrollan constantemente prototipos con el objetivo de mitigar riesgos en la implementación. Este modelo es mencionado por Schell como una propuesta para el desarrollo evolutivo.

Modelo Espiral

– El modelo cascada: Uno de los primeros modelos y tambien el menos utilizado en su forma mas pura, esto debido a su poca flexibilidad para regresar hacia atrás en las etapas de construcción.

Modelo Cascada

Y así como los modelos de construcción de software, existen las llamadas “Buenas Prácticas“, aplicables a todos los modelos. Cabe resaltar que las buenas prácticas son normalmente agrupadas por disciplinas o áreas. Por ejemplo, según el modelo de madurez CMMI para desarrollo de software, elaborado por la Carnegie Mellon Software Engineering Institute, para el área Gestión de Requerimientos, una buena práctica es mantener una base de datos de requerimientos así como un historial de cambios para cada uno de estos. En buena cuenta, se podría mencionar “N” buenas prácticas provenientes de diferentes fuentes. Sin embargo, personalmente yo recomiendo mucho el CMMI como base de buenas prácticas adaptables a cualquier realidad. (Para más información sobre CMMI y buenas prácticas: Modelo CMMI o Librería del SEI)

Ahora, volviendo a la preocupación de Schell sobre los ciclos de diseño-programación, y teniendo en cuenta que existen múltiples modelos, métodos y buenas prácticas que podríamos adecuar para utilizarlas en nuestros procesos de construcción, aparece otra pregunta: ¿Qué usar y cuándo…? Pues bien, la realidad es que no hay una regla exacta de qué y cuándo usar ya que esto va a depender de la naturaleza de cada proyecto al que nos enfrentemos. Entonces, para responder a la pregunta, podríamos reducir un poco el alcance de la misma y, reformulándola obtendríamos: ¿Qué usar y cuándo en la mayoría de proyectos de desarrollo de videojuegos en la realidad de nuestra industria? Ok, con ello podríamos tener una respuesta menos subjetiva pero igual dependerá de la realidad de cada proyecto.

Teniendo en cuenta que muchos de los proyectos que podría estar llevando a cabo la mayoría de empresas (o en algunos casos personas) en la industria local serían de servicios a terceros, estaríamos hablando de proyectos cuyas características más comunes suelen ser:

1. Restricción de tiempo: Aquellos en los cuales el cliente impone una fecha de entrega inamovible.
2. Alcance de producto poco aterrizado: Aquellos en que se solicita construir un producto de software sin tener claro gran porcentaje de los requisitos del mismo.
3. Costos ajustados: Aquellos en los que la configuración del proyecto propuesto al cliente depende de lo que este mismo solicita como condiciones de participación (normalmente cuando se tratan de concursos públicos)

Con las características expuestas, y considerando la naturaleza de los proyectos de desarrollo de videojuegos de no solo encontrar el balance funcional y no funcional sino también del factor diversión, se sugiere revisar un método de rápido desarrollo que permita al equipo de construcción poder contar con versiones funcionales del producto para poder probar lo más temprano posible sus características y así desechar lo que no de valor al cliente y continuar evolucionando lo que si. Con lo descrito, se podría sugerir un modelo iterativo-incremental con métodos formales ágiles de desarrollo y sobretodo considerar la aplicación de buenas prácticas. Por ejemplo, utilizar una metodología ágil como SCRUM, TDD, FDD o TREDD podrían ayudar a “ordenar la casa” en proyectos con características como las descritas líneas arriba. Por cierto, existe un libro que explica muy bien como aplicar SCRUM en el desarrollo de un videojuego llamado Agile Game Development with Scrum y se puede encontrar en Amazon.com

 – Otra vez insisto, esto dependerá de la naturaleza de cada proyecto –

Para concluir, quisiera resumir algunas de las ideas mas importantes planteadas en el presente artículo, y ojalá que a partir de estas, inicie una discusión acerca del tema propuesto:

1. El desarrollar un videojuego es mas que programar un producto de software.
2. En muchos proyectos de desarrollo de videojuegos es necesario utilizar principios de ingeniería de software para asegurar el éxito de los mismos.
3. En el proceso de construcción de un videojuego es importante la aplicación de un conjunto de modelos, métodos y buenas prácticas que permitan implementar las características de un producto de software con un diseño en particular.
4. La ingeniería de software podría ser considerada como una disciplina de soporte en el proceso de producción de un videojuego.
5. Los modelos, métodos y buenas prácticas mencionadas y referenciadas en el presente artículo no deben ser consideradas como reglas, mas si como sugerencias para ser tomadas y aplicadas en diferentes proyectos según su propia realidad.
6. Aun hay mucho que discutir para llegar a una conclusión formal sobre si uno u otro método de construcción es el mejor para estandarizarlo a nuestra industria local, la cual aun es muy joven aun.

Finalmente invito a la comunidad a crear grupos de investigación que ayuden a llegar a un nivel de madurez que permita desarrollar proyectos cada vez mas complejos y con los que la industria local de videojuegos pueda crecer de manera exponencial, tal cual como ha venido sucediendo con la industria del software tradicional.