.: WEREMSOFT :.

En el post anterior había hablado de los errores comunes que dificultan la estimación del esfuerzo para crear un videojuego. En este post voy a cambiar el enfoque, indicando las cosas que facilitan la estimación. Lo de “Cyclomátic Complexity“ lo voy a dejar para otro post, ya que no me va a dar el tiempo:

Cuestiones que facilitan la correcta estimación de esfuerzo

Enterarse de que es posible hacer con la herramienta que se utilizará
A la hora de idear el juego e incluir una funcionalidad, es conveniente averiguar si la misma es factible para la plataforma que estamos usando. Por ejemplo, si queremos un “efecto doppler” en un sonido(el la deformación del sonido que se produce cuando la fuente esta en movimiento y pasa cerca del observador a alta velocidad) y la plataforma que estamos utilizando es Adobe Flash, deberemos descartar la funcionalidad, ya que flash no puede generar ese tipo de efectos.

Hacer los deberes
Esto esta relacionado con el punto anterior, y es el hecho de no interrumpir a las personas que pueden indicarnos si algo es factible o no para una plataforma dada.
Para el ejemplo anterior, si estamos redactando un GDD(Game Design Document) y queremos saber si Flash permite generar un efecto doppler, busquemos en google antes de molestar a un desarrollador. Esto tiene varias ventajas.

1. No interrumpimos el trabajo de la susodicha persona(incluso si anotamos todas las dudas para preguntárselas todas juntas, requerirá una reunión para poder charlar sobre todas ellas).

2. Nos da la chance de, en el caso de que la plataforma no soporte una determinada funcionalidad, encontrar una forma de hacer algo parecido e igual de efectivo. Seguramente si una persona le preguntamos “¿Es posible hacer un efecto doppler en flash?”, esta persona nos dirá que no, nos conformaremos con esa respuesta y ahí terminará todo, pero si encontramos un ejemplo en internet, que nos indique como hacerlo(o simularlo), podemos mostrárselo a nuestro desarrollador amigo para que el la estudie y comprenda lo que queremos hacer(incluso puede que aprenda alguna técnica nueva!).
Lo que estoy tratando de decir es que si realizamos una pregunta fuera de un contexto, la otra persona nos responderá de la mejor manera posible, pero puede ser que no se llegue a una solución porque no se comprendió el problema o porque se ignora una técnica determinada.

3. Seremos más independientes y nuestro trabajo también tendrá menos interrupciones!.

Detallar las funcionalidades del juego tanto como sean posibles
Cuando se esta redactando una propuesta contrarreloj (posiblemente para captar un cliente), se deben redactar documentos a un alto nivel, con las funcionalidades básicas del juego y con una estimación aproximada. En ese contexto, realizar un GDD detallado no es viable, ya que consumiría demasiado tiempo para algo que no sabemos si generará un proyecto.
Una vez que la realización del proyecto y los constraints de tiempo y costos estan establecidos, se debe realizar un GDD con todos los detalles que nos sean posibles. Cuantos enemigos habrá, en cuantos niveles, el comportamiento de estos, variantes, jefes de nivel y sus comportamientos, etc.
Esto permitirá tener una visión mas clara del alcance del proyecto y permitirá una estimación del esfuerzo mas precisa.

El juego es mucho mas que la mecánica
Cuando se idea una mecánica, tener en cuenta que un juego es mucho mas que eso. Un juego tiene un flow, una GUI, interacción con backend(para guardar los records), integración con el sitio del cliente en el caso de se un advergame, paso entre niveles, etc.
Al realizar la estimación, debe tenerse en cuenta todo lo que “envuelve” el juego. No solo la mecánica.

Es todo por hoy, en el próximo post si hablaré de “Cyclomátic Complexity” y como usar este concepto para estimar el esfuerzo necesario para programar un juego.

Saludos!

Un juego, desde el punto de vista de desarrollo, es un sistema de software(también es arte, pero no voy a tocar ese punto de vista en este artículo).

El desarrollo de un juego suele verse como un proceso creativo, donde se involucra el desarrollo iterativo, la integración con el arte, el meaningfull gameplay y otros aspectos. Pero ver un juego como un sistema de software puede solucionarnos muchos problemas muy comunes que dificultan la correcta estimación del esfuerzo necesario para crear un juego.

Cuestiones que dificultan la correcta estimación de esfuerzo

Incluir muchas mecánicas diferentes
Cuando se nos da luz verde para hacer un juego, el primer impulso es hacer el mejor en su tipo, con una experiencia variada(tratando de evitar que el juego sea repetitivo), lo cual trata de alcanzarse mediante la inclusión de distintas mecánicas. Esto suele atentar contra el scope(el alcance de un juego) y el producto final puede resultar en muchas mecánicas débiles, en lugar de una sola mecánica solida y consistente.
El hecho de incluir muchas mecánicas diferentes puede acarrear muchos problemas derivados de intercambiar entre ellas(como guardar el estado del juego, contemplar que el usuario pierda en cada una de las mecánicas, el hecho de computar el score entre mecánicas heterogéneas, etc). Lo anterior hace que el testeo del juego se vuelva mas complejo, haciéndolo mas propenso a tener bugs no detectados durante la etapa de QA.
Cuando la mecánica es solida, se puede iterar sobre ella para incluir variantes mediante un diseño de niveles inteligente(tomar como ejemplo juegos como Portal, de valve).

Dejar todo para que se solucione por medio del “diseño iterativo”
Si se tiene una prometedora idea para un juego, debe dedicarsele el tiempo de análisis necesario(etapa de gamedesign) para que sea consistente. Esto es importante(e imprescindible) debido a que los procesos dentro del desarrollo de un juego son cada vez mas complejos, por consiguiente, iterar sobre ellos requiere cada vez mas esfuerzo.
Si se parte de definiciones difusas, llegar a buen termino con el proyecto será una tarea muy desgastante.
No se debe confundir el método de “desarrollo iterativo y creciente” con el método de “prueba y error“.

El desarrollo iterativo es una forma de obtener un producto. Esto requiere de un proceso que consta de:

* Etapa de inicialización
* Etapa de iteración
* Lista de control de proyecto

Si no se tienen estas etapas, no hay desarrollo iterativo. Ensayo y error es una forma de obtener conocimiento, no de obtener un producto escalable(y vendible!).

En sucesivos posts, trataré de ampliar lo expuesto sobre las cuestiones que dificultan la estimación de proyectos, y hablaré sobre algo llamado “Cyclomátic Complexity“, y como por medio de la cual se puede obtener estimaciones confiables a la hora de evaluar el esfuerzo necesario para crear un videojuego.

Hasta la próxima!.