eduardomillan.com

Este fin de semana he participado por tercer año consecutivo en el Global Game Jam, una “compo” a nivel mundial de 48 horas. El último día, en el grupo comentamos las cosas que no se deben hacer en una compo del estilo. Gorka, uno de los compañeros, ha publicado ya una versión más que recomendable y muy completa, así que recalcaré algunas cosas y añadiré alguna otra. Ahí va,

Gameplay: el objetivo es tener un programa jugable. Es decir, el “core” es la jugabilidad o gameplay. Por eso mismo, hay que comenzar pensando en cómo se va a jugar a nuestro juego, cuál va a ser su base de interacción con el jugador. La historia, el interfaz… es relleno, y se puede fijar o adaptar más adelante, sobre la marcha incluso, pero nuestro “core” debe ser diseñado lo primero.

Descarta ideas. La idea del juego debe ser realmente sencilla, explicable y comprendible en menos de 30 segundos, a lo sumo. Hay que empezar por definir una mecánica base y principal, que debe ser suficiente para jugar. Las posibles mecánicas extra, se deben ir añadiendo en función del tiempo sobrante, pudiendo prescindir de ellas sin problema. Con esta premisa, la idea debe estar muy ajustada al tiempo, y debe ser desarrollable (aka estimación fiable) por un sólo programador en la mitad del tiempo dado (si son 48 horas, se tendría que poder hacer en menos de 25..). Hay géneros que tienden a no encajar en esto, como RTS, TBG, aventura gráfica… (en general todo lo que implique mucha IA, física compleja..) así que hay que descartarlos a priori o darlos tanto la vuelta que apenas parezcan ese género. Eso significa que hay que darle muchas vueltas y descartar más y más hasta tener una idea factible (y a ser posible, original!), sobre la que maquillar un diseño. Y no se programa hasta que esto no se tenga claro.

GDD, máximo un folio. Si hemos hecho bien los dos primeros puntos, deberíamos ser capaces de tener nuestro documento de diseño en tan sólo un folio. Sencillo, entendible, ágil. Si alguien tiene una duda, se lo preguntará al productor (leer punto siguiente) o directamente lo verá en un golpe de vista. No hay tiempo para leer El Quijote! ;)

Productor = diseñador. En desarrollos largos / que conlleven muchas personas, es normal y necesario que diseñador y productor no sean la misma persona. Pero en una compo, tener esos dos perfiles separados es un error y un despilfarro de recursos humanos. El producer debe estar pendiente del game designer, “pactando” con él cada tema, algo nada eficiente con un tiempo más que escaso. La comunicación y la escucha es vital en el equipo y si hay un game designer y un producer, tiende a difuminarse mucho, por la definición de ambos perfiles. Una misma persona puede encargarse de ambos roles, tanto por carga de trabajo como por ser complementarios, y será mucho más productivo a la hora de repartir tareas, ajustar el diseño, coordinar los hitos y comunicar cambios…

Código funcional, que no atractivo. Cuando hay que centrarse en tener algo operativo, no hay tiempo para currarse el código. La arquitectura deberá ser tan simple, que hasta el programador más newbie pueda entenderlo, replicarlo, añadir cosas… y debe ser totalmente modular. Si hay más de un programador, uno será quien lleve el peso, la estructura general y el gameplay. El otro, se encargará de los menús, la UI, las funciones de mecánicas secundarias…  y todo tiene que encajar sin perder horas tratando de integrar o descifrando la arquitectura. Si sólo hay un programador, habrá que reducir al mínimo todo lo que no sea gameplay básico.

Lo más óptimo suele ser tener un equipo formado por un grafista, dos programadores y un diseñador / productor. No siempre es posible, y esto puede variar mucho, pero algo que hay que tener muy claro es que hay que adaptar el juego a los perfiles con los que se cuenta. No tiene sentido hacer un juego cuya base son las animaciones “chulas” si no tenemos grafista, o un juego con cierta complejidad en la mecánica si solo hay un programador y apenas tiene experiencia… Parece obvio, pero in situ se suele pasar por alto hasta que es demasiado tarde…

Por último, las primeras tareas están muy definidas: juntar a todo el equipo para la tormenta de ideas, sobre la que decidir y descartar. Con el esbozo de la idea en mente, el productor se pondrá a diseñar el esqueleto, a darle forma al diseño, a tareas logísticas (svn, cuentas…) mientras que el programador comenzará con la base del programa y el artista a probar con el look&feel. Con la base definida, ir refinando de forma iterativa… Resumiendo todo en tres palabras, producir, ajustar y gameplay. ;)

Al poco tiempo de comenzar a desarrollar el Zombie Master: Typing Trainer (juego más adictivo de la Imagine Mobile de Microsoft!) publiqué un post con las primeras impresiones sobre la plataforma. Con la segunda parte publicada (Zombie Master: Brain Trainer) y Snowflakes (juego ganador del concurso @meetapp) también disponible desde hace alguna semana, toca seguir comentando detalles acerca del desarrollo / publicación para los dispositivos con Windows Phone 7.

Segmentación. WP7 presume de no tener segmentación alguna. Un mismo .xap (el archivo comprimido de la aplicación) debería funcionar exactamente igual en cualquier dispositivo pero para hacerlo funcionar en el prototipo de Samsung y en los HTC, tuve que hacer algunos retoques al código. No daba error, ni excepciones, pero al iniciar el juego, “petaba“. Tocando allí y allá, se producían resultados dispares: “pete” al iniciar desde el teléfono pero no desde el compilador, que funcionase bien al darle a reanudar… Indagando y haciendo más pruebas, llegué a la conclusión de que los problemas se debían a un asunto de memoria, que en algunos terminales no debe estar muy pulida su gestión y hay que optimizar al máximo. Y, por otro lado,  algunos HTC tienen problemas extra con el driver de sonido…

Certificación. Hemos tenido varios “failed” en el proceso de certificación de las apps, debido a pequeñas “chorradas”. En algunos casos, sin embargo, fueron pasadas por alto y actualizamos a posteriori, pero no deja de ser curioso que la aprobación a la primera depende mucho de la “suerte”. Cuando se falla, se recibe un informe con las cosas a pulir, casi siempre muy concretas. En cuanto a rapidez, de 3 a 5 días parece lo normal…

Marketplace. El hecho de no tener una mínima interfaz web donde verlo (como tiene Apple) es un handicap importante, sobre todo a la hora de compartir el enlace directo del market, que sólo funcionará desde IE y con Zune instalado (Existen páginas que recopilan la info del marketplace, pero queda muy raro no tener un sitio oficial de Microsoft). Y desde el teléfono, no me gusta cómo está organizado, a nivel gráfico y estructural se ve bastante “pobre”, demasiado “simplón”. El punto más a favor es que todavía la aglomeración de apps no es excesiva, y puede dar lugar a una oportunidad. El estar en “novedades” es vital, pero si justo cuando tú publicas, al rato, salen muchas otras apps… el mismo problema de siempre, caerás pronto en el olvido…

Ventas. El otro día leía que se habían alcanzado el millón y medio de Windows Phone 7 vendidos, aunque en España esa cifra tiende a cero. Sobre las descargas, se sigue notando mucho la diferencia entre “gratis” y “de pago”, aun con el sistema de prueba o trial. Microsoft “penaliza” las apps gratuitas (con una licencia, sólo puedes publicar 5) y el sistema de publicidad no está muy potenciado (la api de Microsoft es exclusiva para desarrolladores de USA), así que la estrategia es un poco que la versión trial sea la versión gratuita, y la compra añada funcionalidades premium. Pero sigue siendo difícil la conversión…

Panel de control: desde hace poco funciona el reporte de estadísticas, que tiene una semana de retraso (ves datos de hace una semana para atrás). Tampoco es que sea muy específico, pero si tiene la funcionalidad indispensable: descargas, ventas… echando de menos algún filtro que otro… (ratio de conversión, terminales… y cosas del estilo).

Apoyo. El apoyo de Microsoft para el desarrollo ha sido muy importante. Permitirnos hacer testing en sus oficinas / aula de la politécnica, los concursos, el soporte por email…  nada que ver con Apple. ;)

pd.- Y a todo esto, felices fiestas! ;)

Estas dos últimas semanas, he tomado el relevo en el desarrollo de un juego para Windows Phone 7 (el nuevo smartphone que sacará Microsoft el próximo mes), un proyecto que desde Undead, con la colaboración de Miguel Murat (gran diseñador que “parió” la idea), tenemos pensado presentar en la Imagine Mobile. A priori, sólo iba a encargarme del project management, pero debido a la indisponibilidad de un colaborador, tuve que desempolvar XNA y comenzar en temas de desarrollo.

El inicio del proyecto comenzó hace varios meses, pero debido a que no encontraba un programador para ello, el “inicio real” se retrasó muchas semanas. Comenzamos a trabajar en Silverlight, debido al uso de teclado en el gameplay del juego, pero al retomarlo yo, decidí migrar a XNA, pues apenas habíamos avanzado y con tal entorno me siento más cómodo, al haberlo tocado ya en varias ocasiones. Además, por lo que he podido ver, Silverlight tiende a quedarse muy corto para el tema de juegos. :(

Al igual que la versión 3.1, la 4.0 es muy productiva. 15 días dándole duro, contando la “pérdida” de mucho tiempo mirando documentación, “trasteando“, haciendo pruebas… y estamos en un punto muy avanzado. Más en concreto,

Puntos positivos

• Ahora la carpeta “content“, donde se alojaba todo el contenido (texturas, modelos, sonidos, xml…) está en un proyecto aparte, dentro de la solución. Me convence este aislamiento, parece que queda todo más estructurado.
• La lectura de XML, no recuerdo si ha mejorado algo respecto a la versión anterior, pero es gloria bendita.
• Los “game components“, algo así como componentes u objetos del juego, sigue siendo un acierto. Es tan cómodo para gestionar elementos…
• La gestión del “multitouch” parece currada. Todavía no le acabo de pillar el sentido a algunas cosas, pero en principio resulta fácil, y parece que hay mucho control.
• El Visual Studio 2010, seguro de sol. ;) Si no es el mejor IDE que he tocado, poco le falta. La documentación del msdn, es con lo que he ido tirando, sin problemas. (Aunque la organización del concurso también me ha resuelto dudejas :P)

Puntos negativos

• Si leer un XML con los datos de los niveles es fácil, para leer un simple fichero de texto, la cosa no es tan inmediata. Dentro del Content, no te los reconoce, además que está pensado para serializar, con una clase y demás. Así que hay que montar una movidilla con funciones típicas del IO / Stream. Para un sólo dato, no es demasiado sangrante, pero para guardar una tabla de puntuaciones, o varios datos de configuración de usuario, hay que “parsear” a mano, según el formato que le demos al fichero de texto, que está en el sistema a saber dónde, haciendo difícil tocarlo a mano. Vamos, que no entiendo por qué no se permite el mismo proceso de leer xml, para escribir, desde la misma clase que serializa.
• Desde XNA, no se pueden llamar a la mayoría de funciones básicas implementadas en Silverlight, del mismo modo que a la inversa. Esto nos ha supuesto un problema, pues no tenemos manera de llamar a la API relacionada con teclado. Y desde Silverlight, no tenemos acceso a clases básicas en juegos, como la “Game” ó “Graphics“. No me parece mal este hecho, pero sí que la API de XNA para la gestión de teclado sólo consista en un par de funciones que solo sirven para coger un dato del usuario, pero no para interactuar con el gameplay. En iPhone sí es posible!
• Alguna cosilla por ahí que tampoco termino de entender (aka ¿?), siendo ya temas relativos a clases o funciones concretas.

En general, es un entorno que gusta mucho; se programa cómodo, incluso con las cosas negativas y limitaciones. El día 16 sale la versión final de las herramientas, trabajando ahora con la beta. Queda por ver cómo serán las cosas a nivel de negocio, pero como plataforma de desarrollo, me convence.