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.

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

About The Author

Oniric

See author's posts