RSS Feed
Twitter
January 12th, 2010 
NinjaFever
Postmortem
Dual Zone
Ninja Fever is a studio born in the second half of 2009 in Castellón, focused to on-line downloadable games development for the main console platforms.
For its first title, Dual Zone was chosen as a remake of an old amateur project, empowered and adapted for the Xbox Live Indie Games platform.
—–
What went right
-
Quality. The game was planned to have a better visual quality than the XBLIG average and an original gameplay. Thanks to our graphical artist’s skills we reached by far the first item and, according to the reviews, also the second one. But as we’ll see later, this doesn’t mean necessarily good sales. As an anecdote, the music was very well received by reviewers, even when we put much more effort in other aspects of the game.
-
The reviews. The great majority of specialized media and individuals were very positive, with a lowest score of 7/10. Lots of them appreciate the learning curve and the avoiding of possible player color-blindness issues. These reviews helped us give some visibility to our studio in its massive media launch. Again, we’ll see that this doesn’t necessarily have an effect in sales.
-
All systems functional. When the project started, we didn’t even had a studio. One of its main goals was to help us establish a development methodology (or its bases at least) that we could use in our next projects. Definitely, Dual Zone has been a test ground to check the proper functioning of several tools as Mantis or Subversion, backups, a private developer blog or the XNA Framework itself. In that sense, at the end of the project, almost all systems were functional and general development methodology was improved considerably.
-
Getting information about the market ground. Contrasting our sales expectations against reality gave us lots of interesting data, such as the validation game’s cycle for XBLIG by other developers and its idiosyncrasy, the peculiar best sellers, the fact that quality isn’t a deciding factor, and overall, the internal chaos of this specific platform section.
-
The experience of a first job with freelances. Despite all that can be improved in this area (we will talk about it further), the experience of telecommuting with a graphical artist has been very enriching. It helped to have worked together previously for another company.
What went wrong
-
Sales. We estimated 10K units sold to reach the break-even point. After a month in the market, we have sold 21 units. Download/Buy ratio of 1’15% (almost 1.700 downloads) tells us Dual Zone isn’t suitable for all audiences, maybe too hard for some players or maybe repetitive gameplay. These low sales have surprised even other XBLIG developers, that pointed us as possible factors a low representativity of the trailer, the demo or the game description in the marketplace. Extrapolating with better iPhone application sellers, maybe also the price chosen (middle range of 240 MSP, instead of 80 MSP or 400 MSP) has been counterproductive.
-
Total lack of design document. Since we took the idea from an older project and we were in the middle of our company creation whirlpool, we didn’t give the time and attention required to write and define extensively all the game components and interactions. The game vision (two opposite but complementary players) wasn’t even written anywhere, and that caused a communication failure with the graphical artist and occasional course loses of the programmer, in the form of content addition requests that where incoherent with the game’s universe, not accurate graphic requierements and, which is worse, the unnecessary development time delay.
-
Low exploitation of the graphical resources. Despite the high graphical quality, they could have had a much better mise en scène: investing more time in the creation of some cinematic intro to the play would have allowed people to see the space ships better (that, although they are high detailed, their shapes are barely seen), or improving the particle system, the enemy explosions or the enemy models themselves (in their bigger versions, hard edges can be seen).
-
Work tools. As we were building the pipeline on the way, we suffered problems parallelizing the programming framework with the game itself. In addition to this, some third party model and shader exporter bugs contributed to slow down the development considerably. As an additional trouble, we didn’t have yet a FTP server and this was another communication handicap between us and the graphical artist. Anecdotally, we had serious trouble in order to find an official Xbox Memory Card for testing.
-
The review process. It was slow, chaotic and exasperating. The fact of having the game stopped for its review during uncertain time, or even to get low scores in the marketplace without buying the game gave us a very bad impression about the XBLIG system.
And we learnt…
In the marketing foreground, we need to invest much more time in market studies in order to create projects better adapted to the user preferences and with a suitable prize. The lack of a detailed design document agreed by programmers and art staff from its conception is inadmissible for future projects. Focused testing would have helped in finding weaknesses in the game play, the trailer and the description, weaknesses that we only found when the game was too much advanced.
In conclusion, although the overall project has reached their original goals, it left us a bad taste to see that other kind of games succeeded in the platform.
—–
Developer: Ninja Fever
Publisher: Ninja Fever
Release Date: December 7th, 2009
Platform: Xbox Live Indie Games
Number of full-time developers: 1
Number of contractors: 1
Length of development: 3 months
Development software: Visual C# Express, 3DStudio Max, Photoshop, Acid Xpress
Technology: Ninja Framework XNA, kW X-port
PostMortem
Dual Zone
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 plataforma la consola Xbox Live, en la sección Indie Games.
Qué fue bien
-
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ó.
-
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.
-
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.
-
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.
-
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
-
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, algo que averiguaremos cambiando el precio en el próximo update.
-
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.
-
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).
-
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.
-
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 (por llamarles de algún modo).
Desarrollador: Ninja Fever
Publisher: Ninguno
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 propio, kW X-port
Posted in 
Tags: 
[...] Dual Zone Postmortem has been selected as a featured post on [...]