Preguntando por ahí hubo un buen feedback de gente interesada en participar. La idea es hacer encuentros informales, pero con una agenda definida, donde se tratasen temas técnicos, de negocio, de marketing…. en diferentes formatos como ponencias, talleres o mesas redondas. Disponer de un tiempo para el networking y la charla distendida con unas cervezas, facilitando así oportunidades de conocer socios, empleados, colaboradores… o simplemente hacer un poco de piña.

El primer paso ha sido crear una página en facebook, con el nombre provisional de “Game Dev Meetings“. Allí hay varias encuestas para tratar de encontrar un nombre más atractivo, con el que seguir dando pasos como el dominio y la web, como canal más efectivo de comunicación. ¿Te apuntas? ;)

¿Barreras? He leído un comentario que refleja un sentimiento común entre gente técnica sin experiencia empresarial. Algo así como que no es justo que otra persona se lleve parte de tu trabajo por “tutorizar”. Y es que de nuevo, vender está infravalorado. Y quien dice vender, dice toda la parte de negocio y empresa. O de game design y control de calidad. Desde la parte de desarrollo no se valoran esas partes, de igual modo que en ocasiones la tecnología queda en segundo plano desde negocio. Pero todas son necesarias e igual de importantes para tener éxito (quizás no para sobrevivir).

En conclusión, creo que tutorizar proyectos / empresas puede ser un buen planteamiento, con resultados muy positivos, en todos los sentidos y para todos los interesados.

¿Localizar videojuegos para mercados concretos? Hay compañías especializadas en publicar juegos para un mercado local, por ejemplo en China, Corea o Japón. Android es una buena opción, donde todo está más liberalizado y hay posibilidad de markets específicos (como el gigante de Amazon, pero local), pero también hay oportunidades en otros dispositivos, como televisiones. Contando con una empresa de allí para ese proceso de localización / adaptación, llegar a los usuarios es más fácil a priori…

¿Ir a plataformas no saturadas? Puede ser. Dar con una que funcione cuesta, pero la competencia es menor y, por tanto, las probabilidades de visibilidad, en principio, son mayores. Windows Phone 7, la tienda de Intel AppUp para los Ultrabooks, los nuevos libros electrónicos, las smartTVs, las tiendas de los navegadores web… hay mucho para ir estudiando y tanteando. Un proyecto sencillo, aunque esté muy pulido, en iOS lo tiene muy crudo, pero en estas plataformas alternativas puede llegar a destacar sin tanto esfuerzo. Las compañías que promueven estos mercados están deseosas de nuevos contenidos de calidad, así que es también probable que “se mojen” apoyando al desarrollador, teniendo una relación más directa y más opciones de aparecer, por ejemplo, como app destacada.

Yo creo que hacer rentable un estudio indie es viable. Pero hay que dar con el “negocio” adecuado…

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. ;)

Sin embargo, en equipos muy pequeños, o incluso en proyectos llevados por una misma persona, la figura del diseñador queda algo difusa si coincide con el programador. Es decir, que diseñador y programador sean la misma persona. En este caso, se suelen “fundir” demasiado los roles y relajar los detalles. Así,

• El diseño es más fácil que cambie de forma muy constante, incluso que se comience a programar sin documento de diseño, pues lo irá adaptando el programador sobre la marcha. Y eso puede dar lugar a muchas incoherencias, aspectos que no terminen de encajar….
• La percepción es subjetiva. Cuando se tiene un diseñador dando “caña”, los errores, las mejoras… se van dectectando y puliendo de forma más clara. Si no, a pesar de que el programador sea consciente, puede considerar cosas válidas que no lo sean tanto, o dejar de lado los detalles que aporten una diferenciación con la competencia.
• Especialización. Lo de siempre: tener un especialista en cada campo o rol, aporta un valor realmente único. Y se nota mucho, tanto en el juego en sí (jugabilidad, mecánicas, interacción) como en los detalles, cuándo hay detrás un diseñador.

En el desarrollo indie, todo el mundo tiende a hacer de todo, pero es algo que en la medida de lo posible, hay que tratar de evitar. ;)

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.

En las pymes solemos ajustar mucho más los tiempos, la producción… pero aún así el desarrollo de videojuegos es un arte complejo. Cualquier funcionalidad, por trivial que pueda parecer, lleva un coste elevado, así como toda la integración de diseño, grafismo, sonido, programación… Por A, por B, por C… muchos proyectos han terminado en “la papelera de reciclaje“, en fases muy dispares, desde la propia pre-producción, hasta ya metidos en faena… así que aunque de momento por Undead no hemos “matado” ninguno, es toda una satisfacción haber cerrado mi segundo proyecto como “producer” o “project manager“.

No se trata de ningún mmorpg (todavía xD!), pero como dice el título, más vale proyecto cerrado que…

La idea

Tras la presentación pública de las primeras ideas (y tras el anuncio de las restricciones de juego), hubo una que me llamó la atención. Un mono subiendo por plataformas a la torre de un castillo. Me recordaba a juegos muy adictivos de hace años… así que “compramos”, a falta de tener grafista para otra de las ideas atrayentes. Tras formar el grupo, comenzamos el trabajo…

Qué fue bien

• Scrum Lite: agenciarnos un armario para organizar las tareas (ya lo hicimos el año pasado) puede llegar a ser muy productivo y motivante. En líneas generales, cumplimos con el planteamiento, a pesar de saltarnos algunas cosillas y sufrir estrés a las últimas horas.
• Adictivo! Aunque el juego nos quedó muy simple, resultó “picar” bastante. El jurado y el resto de compañeros lo valoraron como muy adictivo, si bien los niveles al poco de juego se volvían imposibles. Hardcore, hardcore…
• Detalles. Son poco notables, pero ahí están. El mono tiene menos impulso si corre sobre una plataforma que va en sentido contrario, o le sale “humo” en función de la potencia del salto a realizar (presionando la  tecla espacio mayor o menor tiempo)…
• XNA. Hacía mucho tiempo que no tocaba nada en XNA (y en general, en temas relativos a juegos de escritorio), pero la plataforma sin duda es muy intuitiva. El último día me ayudó Naranjo en temas de programación, que tampoco lo había tocado, y también hizo cosillas en poco tiempo. Elegir el lenguaje adecuado a la necesidad y propósitos, es vital.

Qué fue mal

• La impresión general. Aunque no era el objetivo, pasamos del menú y otros detalles, dando una sensación al juego de poco acabado. Si hay algo que cuesta mucho a nivel de programación y no tiene un efecto muy visible en el juego, es mejor obviarlo y ofrecer una imagen más terminada. Nosotros pulimos mucho esos detalles, pero no otros como hacer más visual el reloj o el interfaz de juego. El jugador con lo que se queda, es con lo que se nota a simple vista.
• Equipo compensado. A priori el juego no era muy complejo. Pero siempre surgen cosas inesperadas, imprevistos… y un sólo programador es complicado que pueda llevar todo, hay que ajustar muy bien el tipo de juego desde el principio. Y nos pilló un poco el toro…
• Hardcore! No hubo mucho tiempo para testing (nos comimos toda esa parte de la planificación), así que no tuvimos oportunidad de ajustar un poco los niveles. El juego se tenía que pasar en 5 minutos, pero sólo Naranjo logró tal hito.. y la mayoría no pasaba de la segunda o tercera zona, de las 5 existentes.

El proyecto se puede descargar de la página del Global Game Jam, y el vídeo, en youtube.