Postmortem: Dual Zone

Hoy, mientras navegaba un poco me he encontrado con este interesante “Postmortem” de un proyecto de la joven empresa Ninja Fever. Me ha resultado especialmente interesante porque, entre otras cosas, refuerza algunas de las creencias que ya tenia con respecto a la importancia del binomio “Marketing-Diseño”.

Eso es todo. Os dejo con el articulo. Espero que os resulte tan interesante como a mi.

Ninja Fever es una empresa creada a mediados de 2009 en Castellón, orientada al desarrollo de títulos para descarga on-line de las principales plataformas de consola.

Como primer título, se eligió Dual Zone, un remake de un antiguo proyecto como grupo amateur, mejorado y adaptado para la consola Xbox Live, en la sección Indie Games.

Qué fue bien

  1. La calidad. Planteamos el juego para que tuviera una calidad visual superior a la existente en el bazar de juegos independientes, y una jugabilidad original. Gracias al buen hacer de nuestra grafista freelance, conseguimos sobradamente el primer apartado y, según la crítica, también el segundo. Como veremos más adelante, esto no implica necesariamente que el juego fuera un éxito de ventas. Como detalle anecdótico, la música ha sido muy bien valorada en general, pese a ser el aspecto en el que menos esfuerzos se invirtió.
  2. Las reviews. Tanto de medios especializados como las críticas de particulares, han sido muy positivas en su gran mayoría. Incluso en medios muy exigentes, la nota más baja ha sido de 7 sobre 10, y muchos de ellos valoran positivamente tanto la curva de aprendizaje como haber tenido en cuenta posibles problemas de daltonismo en jugadores. Estas reviews han supuesto una estupenda forma de dar visibilidad a la empresa por su lanzamiento a los medios de comunicación. De nuevo, veremos que esto no supone necesariamente verse reflejado en las cifras de ventas.
  3. El poner los sistemas a punto. El proyecto se empezó cuando aún no teníamos siquiera montado el estudio de desarrollo, de forma que uno de sus principales objetivos era el de ayudarnos a establecer una metodología de desarrollo (o su base) desde la que partir para los demás proyectos. En definitiva, Dual Zone ha sido un banco de pruebas perfecto para testear el buen funcionamiento de herramientas como Mantis o Subversion, las copias de seguridad, el blog interno de desarrollo o el propio Framework para desarrollar en XNA. En este sentido, al terminar el proyecto, todos los sistemas están casi completamente funcionales, y la metodología general de producción ha mejorado considerablemente.
  4. La obtención de información sobre el panorama del mercado. Contrastar nuestras expectativas de mercado con la realidad nos ha aportado multitud de datos interesantes, como por ejemplo el funcionamiento del ciclo de validación de los juegos para XBLIG por parte de otros desarrolladores y su idiosincrasia interna, los peculiares títulos más vendidos, que la calidad no es un factor determinante, y en general el caos interno de esta sección de esta plataforma en concreto.
  5. La experiencia de un primer trabajo con freelance. A pesar de todo lo que podemos mejorar en este aspecto (y que detallaremos más adelante), la experiencia de trabajar a distancia con una infografista ha sido muy enriquecedora. Ha ayudado haber trabajado previamente con ella in situ en el desarrollo de un proyecto anterior en otra compañía.

Trailer screenshot

Qué fue mal

  1. Las ventas. Hemos calculado la necesidad de unas 10.000 compras para llegar al punto de equilibrio. Tras un mes en el mercado, hemos vendido 21 copias. Los ratios de descarga/compra de 1’15% (aproximadamente 1.700 descargas con las mencionadas copias) nos han puesto de manifiesto que Dual Zone no es un juego apto para el público general, quizá demasiado difícil para algunos usuarios o repetitivo. Las bajas ventas han extrañado incluso a otros desarrolladores de XBLIG, que nos han apuntado como posibles factores que el trailer, la demo y la descripción del juego no representaran con la suficiente fidelidad su contenido. Extrapolando con las estadísticas de precios de las aplicaciones más vendidas para iPhone, quizá la elección del precio (el rango medio de 240 MSP, frente a los 80 MSP o los 400 MSP) haya sido contraproducente.
  2. La carencia total de un documento de diseño. El haber partido de la idea de un proyecto anterior y en medio de la vorágine de la constitución de la empresa supuso el no darle la importancia debida a la definición extensa y por escrito de los componentes del juego y sus interacciones. El no tener plasmado en ninguna parte la visión del juego (dos jugadores opuestos pero complementarios) ocasionó una deficiencia en la comunicación con la grafista y la pérdida de rumbo del propio programador, en forma del propuestas de adición de contenido incoherente con el universo del juego, la petición de gráficos sin una definición suficiente y, lo que es peor, el alargamiento innecesario del tiempo de desarrollo.
  3. La explotación ineficaz de los recursos gráficos. Pese a contar con un alto nivel de calidad gráfico, se les podría haber sacado mucho más partido invirtiendo algo más de tiempo en la creación de alguna cinemática introductoria a las partidas en las que se permitiera ver mejor las naves (que, a pesar de tener bastante detalle, apenas se aprecian sus formas), o en asuntos como el sistema de partículas, las explosiones de los enemigos o los propios modelos enemigos (al ver su versión grande, se nota su baja poligonalización).
  4. Las herramientas de trabajo. Dado que hemos ido construyendo el pipeline sobre la marcha, hemos tenido problemas paralelizando el framework de programación a la vez que el propio juego, además de bugs en herramientas de exportación de modelado y shaders de terceros. En conjunto, estos problemas ralentizaron el proyecto considerablemente. Como problema adicional, el no disponer aún de servidor FTP propio ha supuesto un handicap de comunicación con la grafista (a añadir a los problemas de comunicación anteriores). Anecdóticamente, nos costó horrores encontrar una tarjeta de memoria oficial para la Xbox con la que hacer ciertas pruebas.
  5. El proceso de revisión. Fue lento, caótico y desesperante. Tener estancado el juego para su review durante tiempos inciertos, o incluso recibir puntuaciones negativas en el bazar aún sin haber comprado el juego nos dio bastante mala impresión sobre el sistema de XBLIG.

Qué hemos aprendido

En cuanto al marketing, que es necesario invertir más tiempo estudiando el mercado existente para crear proyectos que se adapten mejor a los gustos patentes a un precio adecuado. La falta de un documento de diseño detallado y consensuado entre programador y grafista desde su concepción es inadmisible para futuros proyectos. El focus testing hubiera ayudado a la hora de encontrar debilidades en el gameplay, el trailer y la descripción, debilidades que sólo pudimos encontrar en estadios demasiado avanzados del juego.
Finalmente, aunque en conjunto el proyecto ha cumplido los cometidos para los que fue pensado, nos deja un mal sabor de boca el ver que en la plataforma triunfa otro tipo de juegos.

Desarrollador: Ninja Fever
Publisher: Ninja Fever
Fecha de salida: 7 de diciembre de 2009
Plataforma: Xbox Live Indie Games
Número de desarrolladores a tiempo completo: 1
Número de contratados: 1
Tiempo de desarrollo: 3 meses
Software de desarrollo: Visual C# Express, 3DStudio Max, Photoshop, Acid Xpress
Tecnología: Framework XNA Ninja, kW X-port

3 comentarios sobre “Postmortem: Dual Zone

  1. Está muy interesante el texto. He visto el trailer, y ciertamente no llama demasiado la atención, e incluso no queda clara la mecánica de juego.

    De todas formas, creo que hay que poner un poquito más de amor y arte a lo que se hace, aunque tenga fines comerciales, sobre todo si pretendes vivir de ello o ser un referente. El juego se ve un poco soso y monótono, y no parece estar acompañado de secuencias, ilustraciones y demás historias (o de lo contrario seguro que aparecerían en el trailer). Pero lo suyo sería jugarlo y opinar después, claro.

    No obstante, si quieres vender, has de ofrecer calidad en todos los aspectos, o así lo veo yo. Y desde luego, llegas a más gente con mecánicas de juego más sencillas (soy aficionado a los juegos de dos botones: salto y disparo, jeje).

    El problema que veo aquí es que para que salga rentable el tema, el desarrollo del proyecto no debe durar demasiado. Tú puedes hacer un estudio de mercado previo, pero si el desarrollo se alarga, ese estudio puede quedar obsoleto, y más a la velocidad que se mueve el mundillo. Y la consecuencia de un tiempo de desarrollo corto es que no se alcanza la calidad deseada para el producto… Vender pronto el carbón, o vender tarde el diamante. Hay que decidir.

    Un saludo.

  2. Pues si, estoy deacuerdo contigo en lo de los tiempos de desarrollo.

    En cuanto al tiempo de desarrollo de este proyecto en concreto… parece que ha sido bastante rápido, parece haber “fallado” mas por temas de marketing que otra cosa. Un vídeo mejor montado, un estudio previo algo mas intenso (yo creo que mas por el tema precio que por la mecánica)… y sobre todo un mejor marketing.

    A ver si localizo y traduzco un articulo que tenia por ahí sobre que es lo que mas falla en el desarrollo independiente.

    De todas formas creo que aunque no hayan conseguido un éxito comercial si que han avanzado mucho. Han logrado coordinarse, montar la empresa y pulir su juego en un periodo de tiempo bastante corto. Habrá que estar pendientes de que sacan próximamente. 🙂

  3. Completar un proyecto ya es un logro, y los integrantes de esta empresa pueden estar orgullosos. Pero es difícil vencer al “triángulo de producción”:

    http://blog.production-now.com/2007/10/production-triangle.html

    Por ejemplo, es lo que pasa con los juegos indie casuales que infectan la red: escogen “tiempo de desarrollo corto” y “bajo coste de producción” (para que el negocio salga rentable), a costa de la “calidad del producto”. Pero yo creo que si no hay calidad, es difícil que salga rentable.

    Es un tema interesante.

Deja un comentario