Puesto que el fin de año está cerca, será propicio hacer el correspondiente balance, y seguro que entre las metas para el 2012 está volver a tener una buena frecuencia de actualización del blog. La verdad es que siempre digo lo mismo, y a pesar de que haya cosas que compartir o de las que expresar mi opinión, la falta de tiempo tiende a hacer estragos y siempre se acaban produciendo grandes periodos de inactividad. En resumen, a ver si esta vez no. Esperémoslo ;)
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! ;)
Cumplidas las primeras semanas con el HTC Desire y, pasando por tanto a Android como móvil primario, toca hacer una revisión de ambas plataformas. En general, como usuario, Android me gusta, pero tiene muchos “handicaps“…
Gana Android (aka me gusta)
Aunque la usabilidad no es el fuerte, y todavía hay ciertas carencias de aplicaciones, la flexibilidad del sistema me parece un acierto. Muchas funcionalidades, como
Gana iPhone (aka no me gusta)
El punto más en contra, sin duda, está relacionado con la experiencia de usuario. Siempre que tocaba un móvil con Android, me perdía. Y adoptándolo como sistema primario, no fue menos. A todo se acostumbra uno, pero los primeros días uno se siente algo perdido, cosa que con iPhone no pasa. En relación a ello, hace alguna semana twiteaba..
Si iPhone es el amigo de los niños, Android es el amigo de los ingenieros.
En cuanto a puntos más concretos, por ejemplo,
En otro post, tocará la comparativa desde el punto de vista de desarrollador…
Últimamente vengo observando ciertas prácticas nada recomendables, y me parece curioso el punto común de los “practicantes”: inmigrantes analógicos recién llegados al medio digital. Con este “palabro” me refiero a las personas que han adoptado internet como medio “ajeno” o como una oportunidad más, en contraposición a los nativos digitales, que han nacido o se han metido en el mundo digital desde sus inicios, evolucionando con él. (Por supuesto, sin connotaciones despectivas ;)
El caso es que la práctica observada consiste en registrarse en una red social (vertical o profesional, de forma mayoritaria), meterse en grupos y postear en ellos siempre los mismos mensajes, como si se tratara de un bot. En algunas ocasiones los mensajes son “spam” camuflado, preguntando o argumentando las bondades acerca de un producto / servicio que, curiosamente, su empresa ofrece, pero sin el mínimo tono de debate. Y en otras ocasiones, el anuncio es directo, sin ningún maquillaje.
Igual que con el spam masivo al correo, es algo que causa muy mala impresión. Es molesto, demuestra una obsesión (o desesperación) por vender y no contribuye a generar una buena imagen ni a dar pie al networking. Eso no es (un buen) marketing…
Si hay algo que puede resumir una buena o mala impresión de un producto, es la “experiencia de usuario“, (User Xperience ó UX). El término parece estar muy de moda, y es un concepto muy amplio, pero se traduce en ponérselo muy fácil, en todos los sentidos, al usuario. Que sea el aunténtico protagonista, que tenga el control, que sepa todo cuánto está haciendo sin volverse loco… Que cuando termine de usarlo, tenga una sonrisa en la cara, esté feliz.
Convertir al usuario en el rey, puede suponer la ventaja abismal entre un producto y otro, a pesar de que el menos usable tenga más funcionalidad y sea más potente. Pero si la gente no sabe usarlo, o le supone un “trauma“, no contará con una aceptación comparable al que, con menos capacidad, es una gozada de manejo. Y esto es aplicable a muchos ámbitos, incluso a una empresa de servicios, convirtiendo la experiencia de usuario en “experiencia de cliente“. Y un usuario / cliente enamorado puede ser el mejor marketing para una marca (los fanboys de Apple, por ejemplo).
Sin embargo, hay infinidad de casos en que es un auténtico suplicio tener esa buena experiencia, rozando en muchos casos lo ilógico. Hace alguna semana entré en una web para comprar unas entradas, que solicitaba el registro. ¿Registro para comprar, una vez puntual? ¿Al menos que sea opcional, no? Después de todo ello, una ventana detrás de otra, más datos… la página “peta” y he de rellenar el formulario de nuevo, funcionando finalmente, pero tras perder mucho tiempo y con un “mosqueo” importante. Si no hubiese sido “vital” a nivel personal, hubiera desistido. Y el otro día, misma intención en otra página, pero sin resultado eficaz ni eficiente, por un proceso de pago traumático. Resultado: no hay compra.
Hará una semana, Orange me dejó 6 días sin teléfono. Hicieron la portabilidad puntuales, pero se equivocaron con el envío (pérdida de contratos). Mil llamadas a mil números, donde nadie solucionó nada. A base de insistir, por fin llega, pero sólo con una copia del contrato (fotocopias!). La sensación de “chapuza” tiende a infinito.
Como usuario, otra cosa que me llama la atención, es los botones en los smartphones táctiles. Si un dispositivo es táctil, más de un botón (que no sea teclado querty, que puede resultar más cómodo o el silenciador) sobra; se supone que toda la gestión del interfaz (como volver atrás, sacar las búsquedas…) debe ser a través de la pantalla.
Por lo que voy observando, parece que cada vez más se va contando con profesionales dedicados a estudiar la UX, al menos en startups de internet. E incluso he conocido alguna empresa dedicada a ofrecer servicios de consultoría en este campo. Aka puede ser una especialidad de futuro…
El otro día fuí invitado a la apertura de la segunda edición del club de tu negocio, una iniciativa de AJE que combina formación y networking y de la que he hablado varias veces por el blog de Undead. El caso es que la ponencia me encantó. El tema tratado era como una especie de consejos para llevar a buen puerto nuestra empresa, y para solventar con éxito nuestra misión como empresarios.
Me hizo mucha gracia una expresión que repetió muchas veces, como palabras finales a una afirmación. Por ejemplo, hablando de cuánto trabaja un emprendedor…
“Si quieres trabajar 40 horas semanales, busca trabajo en el infojobs”
O…
“El emprendedor no se va de puente, aprovecha que no hay llamadas para reflexionar sobre su plan. Si quieres irte de puente, al infojobs”
“Si quieres un mes de vacaciones, al infojobs…”
La verdad es que el ponente (una lástima no recordar su nombre :(, pero la empresa es A Priori) tuvo mucha labia, y supo expresar lo que debe y no debe hacer un emprendedor, y cómo ha de plantear sus actos (los que hace y los que deja de hacer). También tuvo muchas alusiones al “cliente“, a ver si en otro post lo comento. ;)
Muchas veces he comentado la importancia de contar con un diseñador (“game designer“) en cualquier proyecto, por indie que pueda ser, como rol que tome las decisiones principales en cuanto a las mecánicas, reglas o fundamentos del juego. Siempre es muy valorable que los miembros de un equipo den su opinión, pero el diseñador tiene la última palabra, descartando aquello que no encaje, adaptando ideas… en definitiva, siendo el “jefe” en el área de diseño.
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í,
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. ;)
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
Puntos negativos
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.
De vuelta de Campus Party Valencia 2010, una Campus algo diferente, pues he participado en más “cosas” de las que suele ser habitual… dejando un buen sabor de boca, a pesar de que a nivel organizativo, el evento quizá va perdiendo puntos.
Martes y Miércoles presenté Win or Defeat y Somflee respectivamente, en el espacio llamado “Campuseros Presentan“, una iniciativa destinada a apoyar a proyectos creados por campuseros. Somflee pasó a la final, presentando de nuevo la aplicación el viernes al mediodía, en el auditorio del museo. Terminé bastante contento, varios compañeros y amigos me dijeron que fue genial, aunque siempre se puede mejorar, y creo que mucho. ;) De forma paralela, grabé un vídeo para Movistar, que estaban eligiendo los 10 mejores proyectos para darles apoyo, pero tampoco gané en ese frente…
Por otro lado, al final la organización decidió realizar la compo rápida de desarrollo de videojuegos, con las mismas normas de años anteriores. (Se rumoreó reducir el tiempo, pero se mantuvo la esencia inicial). El martes por la mañana José Zanni, Ex3 y yo, decidimos apuntarnos…. El viernes noche presentamos nuestro juego (minuto 14), y el sábado… ¡premio! Ganamos el primer premio, siendo considerados por el jurado como el mejor de 4 propuestas. La idea es continuar el desarrollo de White & World, pues tiene un concepto atractivo y se puede sacar de ahí un juego publicable. :D
Y en cuanto a eventos de networking, tocó mi primer eat&twitts, en el que además de comer productos “alternativos” de “gourmet“, pude conocer a gente muy interesante. Y el segundo championstwitt, donde jugué con el equipo Xing Champions Twitts, volviendo a quedar en cuarto puesto (estamos ya mayores..).
Por último, me tocaron varios premios en un sorteo de Ozone (cascos, ratón y alfombrilla), una empresa dedicada a periféricos y afines para gamers…
