.: WEREMSOFT :.

En esta nueva seccion voy a imitar una buena idea que vi en un blog llamado RockPaperShotgun(piedra, papel o escopeta), a lo que le llaman “El diario del domingo”(The Sunday Papers).

La idea es, una vez a la semana, hacer un post con el resumen de todo lo que me llamo la atención en Internet.

Me mueven tres poderosas razones:

1. Guardar los links interesantes que veo por Internet.

2. Ejercitar el difícil arte de la escritura.

3. Filtrar para ustedes mis lectores(si es que hay alguno) el ruido de Internet para que esten un poco mas informados y se den una vuelta por el sitio, al menos, una vez a la semana.

Mi ambiciosa espectativa es formar parte de el ritual dominguero de toda persona de habla hispana que se interese por los videojuegos en flash, la programación en actionscript y el mundo de los videojuegos interesantes que salen para las consolas PS3 y Wii(mismas que poseo y con las que paso bastante tiempo).

Si un puniado de entusiastas tiene abierto mi sitio un domingo a la manana junto al mate o al cafe con leche me voy a sentir realizado.

Sin mas, largamos la primer edición del diario del domingo de WeremSoft. Bienvenidos.

Lo que paso en la semana

Dos juegos me volaron la peluca en esta semana que paso. Por un lado, tenemos un hermoso, divertido y muy profundo juego de Terry Cavanagh, llamado Don`t Look Back. Este juego sorprende por su poder de síntesis en la realización de sus escenarios, donde nos sentimos protagonistas de un viaje a lugares peligrosos y su muy entretenido galayo. Tiene un par de bosses y un inesperado final.

El otro de los juegos que me encanto es Schizophrenzy. Otro plataformero en flash del sitio de adult swim. Este trata de un investigador privado que sufre de alucinaciones. A medida que este va perdiendo su energía(cordura) va viendo mas y mas cosas raras(monstruos que escapen monstruos y pies que caen del cielo) y va pudiendo hacer mas y mas cosas raras(caminar por las paredes o nadar por los aires). La musica es muy buena y el tutorial que te ensenia a jugarlo muy gracioso.

Tambien me estuve asombrando con el demo tecnologico de Boffswana. Aunque un poco viejito, muestra como usar la camara web por medio de flash para generar realidad aumentada(objetos 3D montados en tiempo real sobre video). Si tienen una impresora a la mano, hagan el experimento que esta increíble.

Me baje la ultima version de ElectroServer y voy a ver si hago algun multiplayer en flash bajo esta plataforma y aunque la primera impresion me parece un poco tosca(no hay muchos tutoriales para juegos realtime en flash) voy a darle una oportunidad.

El sábado quería comprar un juego para play 3 y estaba medio indeciso entre las opciones que habia considerado: Street Fighter IV, KillZone 2 y Resident Evil 5. Luego de leer metacritic(sitio que elavora un score basandose en las reviews de varios otro sitios web, entre los que esta gamespot) me decidi por Street Fighter IV, y puedo asegurarles que fue una muy buena decisión.

Estuve viendo una herramienta para testear performance de flash 10, que ofrece una interesante funcionalidad que consiste en comparar 2 scripts que uno quiera, y ejecutarla 10000 veces para ver cual es la mas eficiente. Bájenla, compilenla y ejecútenla. Serán mucho mejores programadores en actionscript 3 después de jugar un rato con ella.

Estuve viendo un juego hecho en Unity3D, llamado Blush, que se parece muchísimo a un prototipo que hice en threemelons en un first tueday. Es una pena que no podamos implementar todas las ideas que se nos ocurren.

Eso fue todo lo que paso en la semana. Feliz domingo para la juventud!

Hoy voy a hablarles de algo llamado Complejidad Ciclomática (o Complejidad Condicional) es una forma de medir la complejidad lógica de una porción de código.

La misma se basa en el siguiente principio:

“Mientras mas variados sean los caminos que pueda tomar el flujo de ejecución de un programa, mas esfuerzo será necesario para idearlo, desarrollarlo y testearlo.” – Pablo Weremczuk*

Para dar un ejemplo mas cercano a la vida real, vamos a imaginar una función(como en C o javascript) y que esta función solo asigna valores a un puñado de variables. En ella no hay if’s, ni for’s, ni while’s ni ningún elemento que compare una variable con otra o con algún valor.

Por ser una función tan simple, no tiene bifurcaciones, por lo que con solo ejecutarla una vez, habremos recorrido todos los caminos que puede tomar el flujo del programa.

En este caso, la complejidad de la función es de 2(numero de bifurcaciones o “condiciones” + 1). Para facilitar las cosas, vamos a imaginar que contamos 1 por la declaración de la función y le sumamos otro 1, porque así lo dicen los libros.

Si en esta función tuviéramos un if(preguntar si una variable realmente tiene el valor que le indicamos), la complejidad de la función crecerá en 1. Ya que para recorrer cada camino posible que puede tomar el flujo de ejecución del programa necesitaremos correr la función al menos 2 veces. Por lo que la complejidad de dicha función nos queda de la siguiente manera:

Complejidad = 1 + 1 + 1 = 3

Los números 1 que se indican arriba corresponden a la declaración de la función, el camino principal(fuera del if) y el camino secundario(cuando se entra al if) respectivamente.

Ahora vamos a complicar un poco la cosa. Imaginemos que cada variable que recibe un valor dentro de esta función esta contenida dentro de una clase(como en java o C++). Entonces agregaremos un 1 a la cuenta por cada variable declarada y otro 1 por la declaración de la clase.

Así, la clase mas simple que podemos llegar a crear, es tan compleja como:

1 por la declaración de la clase
+
1 por cada declaración de variable.
+
1 por la declaración de la función(que puede ser el constructor).
+
1 por cada if que se encuentre dentro de la función.

Lo que nos da un total de 4 + (cantidad de declaraciones de variables) unidades de esfuerzo.

Para simplificar las cosas, solo mencioné los if’s, pero deben tenerse en cuenta todas las instrucciones que puedan aumentar la cantidad de caminos que puede seguir el flujo de ejecución de un programa. Incrementan en una UE(unidad de esfuerzo) la complejidad de un programa:

* Cada If
* Cada operador binario dentro de un if (and u or)
* Cada else/else if(misma consideracion con los and y or)
* Cada while, for, do, también contemplando los operadores lógicos.
* Cada declaración de variable, publica, provada o local(las variables dentro de un método).

¿Ok, para que nos sirve todo esto? Muy sencillo, esto nos sirve para poder determinar cuantas unidades de esfuerzo(en adelante UE) fueron necesarios para crear una determinada pieza de código.

Suficiente por ahora

Como decía un profesor: “Para una buena práctica, no hay nada mejor que una buena teoría”.

Así que dejo el tema acá para que asimilen este concepto. En la próxima entrega les explico como usar la complejidad condicional para estimar cuanto tiempo nos lleva desarrollar un juego, con una envidiable presición.

Como diría Leonard Nimoy: Adiós! y sigan mirando al cielo!

* Esta frase me la atribuyo a mi mismo, ya que es la definición mas compacta que pude idear para explicarles este principio que tantas alegrías me ha traído.

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!.