[OT] Ya está disponible Robot Strike Bowling en el Marketplace de Windows Phone 7!

Así es, tras varios días de pruebas,  Robot Strike Bowling ya se puede descargar gratuitamente en el marketplace de Windows Phone 7. Lo cierto es que ha sido uno de los primeros juegos españoles en ser certificado! Si tienes ganas de curiosear esta u otras aplicaciones/juegos para Windows Phone 7 y no eres uno de los afortunados que disponen de un dispositivo para acceder, puedes hacerlo de dos maneras:

[WP7] Comprobar la conectividad del teléfono

Tu aplicación o juego para Phone 7 (esto vale para Silverlight y XNA) usa webservices u otros tipos de comunicación con el mundo… en un entorno tan variante como es el de un móvil, es lógico comprobar que hay conectividad antes de llamar a un webservice no os parece? Para ello el espacio de nombres Microsoft.Phone.Net.NetworkInformation tiene cosas interesantes!

Tenemos a NetworkInterfaceType, que nos devolverá la interfaz de red a la que estamos conectados -es un enumerado con muchísimos valores, que nos dirá si tenemos Wifi, ADSL, etc-, o bien que no hay conexión disponible (NetworkInterfaceType.None). El uso es muy sencillo, aunque la ejecución algo lenta, por lo que hay que tener eso en cuenta cuando lo usemos: 

var red = NetworkInterface.NetworkInterfaceType;

if (red == NetworkInterfaceType.Wireless80211)
    System.Diagnostics.Debug.WriteLine(«estamos con wifi»);
else if (red == NetworkInterfaceType.None)
    System.Diagnostics.Debug.WriteLine(«sin conexión»); 

En este caso he comrobado si la conexión es wifi, pero si queremos saber si hay conexión valdría con red != NetworkInterfaceType.None

Para ello también existe el método GetIsNetworkAvailable(), más rápido, pero que no funciona con el emulador (siempre devuelve true):

bool hayRed = Microsoft.Phone.Net.NetworkInformation.NetworkInterface.GetIsNetworkAvailable();

 

Así pues si necesitamos acceder a esta información, yo recomendaría crear un método que wrapee esta funcionalidad, y ejecute un método u otro del framework dependiendo de si estamos en modo depuración o no.

[WP7] Ya podemos subir aplicaciones al marketplace de Windows Phone 7!

Por fin! Tras meses de angustiosa espera, ya podemos subir nuestras aplicaciones a la nueva aplicación de Microsoft creada para tal objetivo, que a su vez «absorve» a la página XNA Creators Club. La nueva web para subir apps, incluyendo juegos, al marketplace es: http://create.msdn.com

Yo ya he subido mi juego! Y tú, ¿a qué estás esperando? 😛

[WP7] Quieres certificar una aplicación para el Marketplace? Asegura el tiro con la clase DeviceExtendedProperties

En una aplicación o juego puede llegar a ser útil obtener el identificador único del dispositivo, o bien el nombre del fabricante, la memória total del teléfono, la memória en uso de nuestra aplicación… todo esto es posible con la clase DeviceExtendedProperties. No obstante no se recomienda usar esta clase en modo producción, ya que en el momento de ser instalada la aplicación le saltará un aviso al usuario. Más bien está pensada para que se use en modo depuración, para hacer un profiling de nuestra aplicación, viendo cuanta memoria consume. Si nuestra App o juego consume demasiada memoria, es posible que no se supere los requisitos de certificación para publicarla en el marketplace.

Los datos que podemos obtener con esta clase, disponible en el namespace Windows.Phone.Info son:

DeviceExtendedProperties.GetValue(«DeviceManufacturer»).ToString()
DeviceExtendedProperties.GetValue(«DeviceName»).ToString()
DeviceExtendedProperties.GetValue(«DeviceUniqueId»).ToString()
DeviceExtendedProperties.GetValue(«DeviceFirmwareVersion»).ToString()
DeviceExtendedProperties.GetValue(«DeviceHardwareVersion»).ToString()
DeviceExtendedProperties.GetValue(«DeviceTotalMemory»).ToString()
DeviceExtendedProperties.GetValue(«ApplicationCurrentMemoryUsage»).ToString()
DeviceExtendedProperties.GetValue(«ApplicationPeakMemoryUsage»).ToString()

Podéis encontrar más información de esta clase en el MSDN.

[XNA] Cómo desarrollar un Indie Game – Parte II

Continuando con el caso real de el desarrollo de un Indie Game, y habiendo hablado ya de la creación del equipo de desarrollo y la planificación, me centraré hoy en cómo hicimos el diseño y las pruebas de concepto, viendo ejemplos de código y las librerías utilizadas para el desarrollo del juego para Windows Phone 7, Robot Strike Bowling.

 Robot Strike Bowling: Pruebas de concepto

De forma paralela al diseño, e incluso un poco antes de comenzar este, es bueno realizar alguna prueba de concepto, esto es, programar una pequeña prueba de que lo que queremos hacer es viable. Esto no tiene que ser una versión detallada del juego que queremos hacer, sinó pequeños bloques aislados que creemos que podrán resultar complicados de hacer (pues sí, nos guste o no hay que comenzar por lo más difícil). En el caso de Robot Strike Bowling, hicimos algunas pruebas con el engine de física utilizado (Bepu Physics). Esta fué nuestra prueba de concepto:

[View:http://www.youtube.com/watch?v=nbO_pV23_NE:550:0] 

Es importante realizar alguna prueba de concepto ya que los programadores acostumbramos a alucinar un poco en cuanto a nuestras aspiraciones en cuanto nos ponemos a programar un videojuego, así que este tipo de pruebas nos puede ayudar a tocar de pies en el suelo, y evitar hacer un montón de trabajo que sería inútil si resulta que el juego es inviable. Puede ser inviable normalmente porque no se disponga de la experiencia necesaria para desarrollar el tipo de juego que se quiere hacer.

Robot Strike Bowling: Diseño

Casi todos sabemos, o deberíamos saber, que es importante saber qué queremos hacer antes de ponernos a picar código… y en el mundo de los videojuegos hay otro factor a tener en cuenta: si lo que queremos hacer es factible, o lo que es lo mismo, si somos capaces de hacerlo. Es muy importante darle a esta fase la importancia que merece, y es mucha. En el caso de Robot Strike, le dimos importancia, pero seguramente no la suficiente. Dedicar más tiempo al diseño nos habría ahorrado varios futuros problemas. Pero es lo que pasa en cualquier proyecto donde vamos justos de tiempo y no hay recursos: se recortan el diseño y las pruebas!

En fin, que nuestro diseño fué a muy alto nivel. Seguramente este diseño es aceptable como diseño conceptual, pero no como diseño técnico. Este diseño conceptual definirá en mayor detalle qué es lo que queremos hacer, sin entrar mucho en cómo lo vamos a hacer. En este caso generé un documento con un índice muy parecido a este:

  • Game Mechanics
    • Characters, describe los personajes del juegos, que pueden ser usados por humanos o por la AI
    • Game Play Elements, posibles objetos que el jugador puede ir recogiendo durante el juego, como armas y mejoras
    • Game Physics, define qué tipo de físicas utiliza el juego
    • Artificial Intelligence, define por encima qué tipo de AI tendrá el juego
    • Multiplayer, explica si hay modo multijugador y cómo funciona este
  • User Intrerface
    • Flowchart, flujos de navegación, muy útiles
    • Requisitos funcionales, que describen qué es lo que hace el gameplay en sí mismo
    • GUI Objects define los objetos que te puedes encontrar por la interfaz
  • Art and Video, Idealmente contendrá una lista de todo el arte y vídeo que habrá en el juego, o al menos un esbozo inicial…
    • 2D Art & Animation
    • GUI
    • Terrains
    • Game Play elements
    • Special Effects
    • 3D Art & animation
    • Cinematics
    • Video
  • Sound & Music, se definirán los objetivos de la música, el estilo que se desea transmitir. Se pueden detallar formatos de archivos, tamaño máximo, etc.
    • FX, es una lista de todos los FX que se van a identificar
      • GUI
      • FX
      • Characters
      • Game Play elements
      • Enironment, terrains
      • Motion
    • Music
      • Event Jingles, éxito, fracaso, muerte, victoria, etc
      • Shell screen, para créditos títulos y final de juego
      • Level Themes, música específica para cada nivel
      • Situations, música específica para situaciones como acción o peligro
  • Level Requirements
    • Level diagram, viene a ser un diagrama que define cómo se accede de un nivel a otro. En algunos juegos será lineal, pero en otros no.
    • Asset Reservation Schedule, tabla que indica en qué momento del juego ciertas partes del juego deben ser rebeladas al jugador
    • Level design seeds, son borradores del diseño de los niveles, y pueden estar sujetos a cambios posteriores

Nota: Este índice está generado a partir de varios documentos, principalmente de GameDev.net, adaptado a Robot Bowling Strike, que a mi entender nos han sido tremendamente útiles, eso no quiere decir que tenga que ser útil a cualquier proyecto de videojuegos exactamente con este índice y contenidos, pero estoy seguro que sí que será positivo invertir tiempo en hacer un diseño.

Este sería el diagrama de flujo de nuestro juego. Contiene elementos, como la entidad «Juego» que puede (y debe) ser desglosada en mayor detalle en otro diagrama.

 

Y así queda el tema por el momento… próximamente… espero centrarme ya un poco en la parte más técnica!

Concurso de diseño XNA Community

XNA Community ha organizado un concurso en el que puedes ganar varios premios de forma muy sencilla. Sólo tienes que diseñar un logotipo para
el grupo de usuarios XNA Community, como se describe en las bases del concurso. Los premios son los siguientes:

  1. Consola XBOX 360 negra de 250GB
  2. Pack de 2 juegos para XBOX 360
  3. Pack de 2 juegos para XBOX 360

Me parece que es una muy buena oportunidad para conseguir fantásticos premios!

El concurso está organizado por XNA Community, y patrocinado por Microsoft Iberica y Enea Games. Más información en la página oficial del concurso.

[XNA] Cómo desarrollar un Indie Game – Parte I

Los siguientes artículos tratarán de una experiencia real en el desarrollo de un Indie Game. Hablaré desde los distintos puntos de vista que he experimentado en el desarrollo de Robot Strike Bowling, desde el proceso de diseño hasta el desarrollo, incluyendo los problemas encontrados por el camino, tanto técnicos como humanos. También enseñaré código de cómo se han hecho ciertas partes del juego, las que están bien, las que son mejorables y las que están mal. Otras cosas las juzgaréis cada uno de vosotros… en esta pequeña «guía» no se encuentra la iluminación, sinó una experiencia que puede ser útil a otras personas.

Robot Strike Bowling: Los preludios

Hace mucho mucho tiempo, en una galaxia muy lejana… un programador de XNA y un grafista (Jordi Gimenez, diseñador gráfico, modelador 3D e ilustrador 2D) coincidieron en la red, no se sabe muy bien como. Comenzaron a colaborar en pequeños ejemplos que el programador desarrollaba para su blog. Ninguno de los dos había publicado jamás un videojuego completo en un marketplace, pero decidieron que debían producir uno. Todo empezó en Barcelona, en una presentación organizada por Microsoft de Windows Phone 7 y XNA, que ofrecían Javier Cantón y Eduardo Ortega. Su charla-evangelización sufrió efecto, muchos de los asistentes salimos de la sala con unos incrementados deseos de producir un videojuego, algunos no pudieron soportarl tanta emoción y se tiraron por la ventana, otros comenzaron a programar cuando todavía ni siquiera habían encendido sus ordenadores, como tecleando en el aire. Yo ya tenía experiencia en pequeños proyectos que nunca se terminaron y esta vez quería hacerlo bien, así que intentaría no cometer los errores del pasado. Para mi las decisiones más importantes en este momento fueron:

  • Elegir un tipo de juego lo más sencillo posible, pero que me motivase lo suficiente hacerlo
  • Asumir que, sin querer ponerme medallas, tenía los conocimientos suficientes para hacer un juego, aunque este fuera simple
  • Buscar en mi interior si disponía del tiempo suficiente para terminarlo y renunciar a algunas cosas para disponer de más ratos
  • Encontrar un equipo competente, de confianza y con el mismo compromiso implacable
  • Decidir que queríamos presentar el juego a Imagine Mobile

Es muy importante aquí estar seguros de que disponemos de los conocimientos suficientes, y eso no es haber leído un libro… es haber programado XNA, en varias situaciones y tipos de escenarios. Si no tenemos los suficientes conocimientos y somos conscientes de ello, lo mejor será unirse a otro equipo que sí tenga la experiencia necesaria, eso será muy bueno para aprender.

Dónde y cómo buscar un equipo

Si te falta gente en tu equipo, hay varias páginas donde puedes encontrar gente que colaborará gratuitamente en tu proyecto en XNA Community, Stratos, y por supuesto en el foro de XNA Creators Club. Para empezar, no busques 10 personas para tu equipo, eso es inmanejable en un juego Indie. Si quieres que se una a tu equipo gente buena, tendrás que demostrar que tu proyecto es serio y estás capacitado para llevarlo a cabo, así que explica muy bien de qué va tu proyecto, y si es posible ten preparado el documento Game Concept, que se explica a continuación.

Y así fué. Dado que los miembros del equipo éramos distantes geográficamente (Jordi Gimenez en BCN, yo en Lleida, y más tarde se incorporaría David Yingling, para crear la música y FX de sonido, en Seattle), así que si queríamos que las cosas salieran bien debíamos intentar mantener la mejor comunicación y de forma lo más productiva posible, porqué además de hacer el juego, todos nosotros tenemos nuestros trabajos y vidas -sí, aunque parezca mentira!-, así que decidimos reunirnos todos los jueves telemáticamente el grafista y yo, que haríamos el diseño conceptual del juego. Es muy importante respetar esas reuniones, sin excusa posible, porque sinó se pierden los objetivos, las metas, y la planificación se va al garete. Pero ya me estoy adelantando…

Lo primero que hicimos fue decidir qué tipo de juego queríamos hacer, concretando la lluvia de ideas que habíamos tenido sobre el papel, o Word en este caso :-P. Primero definimos un documento al que llamamos «Game Concept«. El nombre es bastante autodescriptivo… muchas guías de diseño de videojuegos hablan de este concepto, pero resumiendo mucho, este documento básicamente contiene la idea general de lo que será el juego, las funcionalidades básicas, género, la plataforma en la que se ejecutará, etc. Todo sin entrar muy al detalle, alcanzando el documento una longitud mínima, de dos páginas (sin incluir el concept art que va en assets a parte). Nosotros utilizamos este índice para crear este documento:

  • Introduction
  • Background
  • Description
  • Key features
  • Genere
  • Platform
  • Concept Art

Robot Strike Bowling: Planificación

Lo anterior no podía considerarse una fase de diseño con todas las de la ley, era más bien decidir qué juego queríamos hacer. Ahora que lo sabíamos, teníamos que definir una planifiación. La planificación -realizada con Microsoft Project- indicaba fechas clave en las que debíamos tener realizadas ciertas partes del juego si queríamos terminarlo a tiempo para el concurso. Aquí es muy importante no ser demasiado optimistas cuando lo que estamos haciendo es un juego Indie: no disponemos de un número de horas fijas a la semana, y mucho menos al día para trabajar! Hacer este tipo de planificación es mucho más complicado de la que haríamos en un proyecto de software en la empresa en la que trabajo desarrollando aplicaciones de gestión. Un día tendrás que ir a sacar al perro, o al siguiente puede que sencillamente no tengas ganas de alargar la jornada laboral de 8 o 9 horas 😛 así que miremos de ser lo más realistas posible, e incluso un poco pesimistas, con la planificación.

Ojo, tampoco pongamos una planificación a un año vista, porque si el proyecto se alarga demasiado, es provable que el proyecto muera por desmotivación de los miembros del equipo, o simplemente a estos les salgan compromisos personales más importantes que hacer un juego como hobby… así que centrémonos en el objetivo: hacer un juego completo, lo más sencillo posible, en el mínimo tiempo posible. En un proyecto indie los recursos (humanos) hoy están y mañana no se sabe… así que cuanto menos dure el desarrollo mejor, más posibilidades de que no nos tire ningún miembro del equipo. Un recurso es muy difícil de sustituir en este tipo de proyectos…

Otra cosa que puede parecer complicada en un principio es cuánto tiempo asignar a cada tarea. Nosotros no nos rompimos la cabeza con eso, en su lugar nos concentramos más en los hitos, si terminábamos antes de lo previsto el diseño, mejor, si se nos retrasaba… tendríamos un problema, pero había que hacer lo que fuera para terminar como mínimo, el mismo día en que se alcanzaba el hito. Esta estrategia no sería válida en proyectos profesionales, en los que un día de trabajo supone un coste, multiplicado por el número de recursos… un coste mucho mayor, y ahí sí que hay que llevar un control mucho mayor, pero no es el caso que nos ocupa…

Robot Strike Bowling: Diseño y pruebas de concepto

Esto se verá en el próximo episodio amigos…