¡Bienvenido a mi cubil!

| Suscríbete vía RSS

25 febrero 2010


Comparte este artículo: | Menéame | Fresqui | Enchílame | Technorati |

Los problemas de los RPGs

| 7 comentarios |

Saludos lupinos amiguetes.

Hoy he decidido traeros la traducción de una entrada de un blog que me ha parecido la mar de interesante. La entrada original en "The amazing spectacular world of Blanof" la podéis encontrar aquí y hace referencia al desarrollo de un juego de Rol, comenta algunas verdades, nos ofrece algunas percepciones algo mas subjetivas y en general, nos ofrece lo que a mi parecer es una experiencia interesante.

De nuevo, he recurrido a la interpretación libre para darle soltura al texto. Espero que no os importe. *

Los problemas de los RPGs

Adquirí Game Maker en Mayo del 2005. Poco tiempo después, uno de los primeros juegos que comencé a desarrollar fue un juego de rol, mejor conocido como RPG. De hecho, aún se puede encontrar el hilo original, aunque los enlaces de descarga han sido borrados hace tiempo. Invertí más de un año trabajando en él y el juego nunca llego a completarse.

Comparemos esa historia con esta: Comencé a trabajar en Dubloon en Mayo del 2009. En menos de un mes ya he realizado un mayor progreso con este juego que en todo el desarrollo anterior de mi primer RPG. También se ve mejor, se juega mejor, funciona mejor y es mas fácil trabajar en él.

Básicamente lo que quiero decir es que hacer un RPG es complejo y no es un desarrollo adecuado para inexpertos. No estoy diciendo que sea algo imposible, pero en términos de desarrollo, los RPGs presentan muchos mas obstáculos que cualquier otro género de videojuegos que se te pueda ocurrir. Así, como parte de una historia preventiva, o a modo de "Diario de desarrollador", voy a hablaros de lo que he aprendido haciendo RPGs y algunos de las dificultades en su diseño.

Una de las primera cosas de las que siempre habla la gente a tratar este tema, es la cantidad de experiencia técnica que se precisa. Cuando hablas sobre el funcionamiento interno de un RPG, estás viendo un montón de datos que deben ser organizados, computados y machacados constantemente. Debes manejar inventarios, estadísticas de personajes, cálculos de batalla, y así sucesivamente. Puede ser duro llevar un seguimiento de todo esto, sobre todo cuando tu equipo de desarrollo consiste en una sola persona, necesitas tener soltura con términos como los arrays, estructuras de memoria, y todas esas cosas divertidas. Quizás no debería decirlo, pero yo programe mi primer RPG sin tener esos conocimientos y es horrible, duro.

Proyectos como un RPG, no son desarrollos que se deban hacer rápidamente. El código que escribes debe ser funcional, comentado y lo suficientemente organizado como para que puedas volver a verlo un año después y entender perfectamente que es lo que hace. Cuando los nuevos desarrolladores comienzan diciendo que quieren hacer el RPG de sus sueños, al igual que hice yo, suele ser la razón por la que les digo que no podrán hacerlo.

Los RPGs no son solo complejos de desarrollar técnicamente, también lo son a nivel artístico. A diferencia de juegos de otros géneros, la expectación que se tiene sobre un buen RPG es una larga duración. La mayoría de los juegos independientes pueden terminarse fácilmente en una hora, o incluso menos. Para conseguir esa gran diferencia en horas de juego, necesitas añadir diferentes mecánicas e ideas para mantener la variedad y el interés. El problema que encuentro en muchos RPGs es que a menudo caen en repetir patrones aburridos: explorar mazmorras, machacar, luchar con los jefes, desplazarnos hacia la siguiente mazmorra. En la actualidad los juegos se mueven muy rápidamente y los diseñadores tienen una gran responsabilidad combatiendo por mantener el interés del jugador. ¡No dejes que tu juego se estropee! “RPG” no tiene porque ser sinónimo de “aburrido”, y si dedicas el tiempo suficiente en pensar en el sentimiento y el ritmo de tu juego, es totalmente posible unirlos en un juego de rol que resulte divertido y atractivo.

Parece evidente que los juegos de rol no son tan bien recibidos hoy en día como lo eran antes. Lo descubrí dolorosamente cuando subí “Dubloon” a IndieGames en Julio de 2009. La gente envió comentarios tipo "sólo otro juego de rol" sin tan siquiera haberlo jugado. Los juegos de rol no son tan apreciados tanto en estos días, esta tendencia se puede observar en las listas de “mejores características” del año en Indiegames. La mayoría de los géneros quedan bien delimitados y con 15-20 juegos incluidos en su lista, mientras que los RPGs están agrupados junto con otros dos géneros similares y apenas consiguen un total de 10 títulos innovadores.

En el mercado actual, se hacen un montón de promesas para convencer al público de que su RPG es especial. Tal vez estoy reaccionando con demasiada fuerza a un grupo minoritario de “enemigos” del género, pero nunca es mala idea tenerlos en cuenta para tratar de innovar. Hay que ser consciente de la imagen de tu juego: ¿cómo lo ven los jugadores? Hay una razón por qué existen listas como éstas y es importante que familiarizarse con los clichés del género... para poder romperlos.

¿Están muertos los juegos de rol? Yo no lo creo, en absoluto. Ofrecen una experiencia muy particular al jugador, haciéndole sentir el crecimiento del personaje y la aventura de una forma que ningún otro género puede ofrecer. Lo que es importante al hacer un buen RPG es saber que es bueno, que no lo es tanto, y hacer uso de esas cualidades en tu favor. Cuando comencé con mi primer RPG, empecé sólo porque quería hacer un juego de rol, y no creo que esa sea la forma correcta de abordar este tipo de proyectos. Un juego de rol, no es interesante sólo por el hecho de serlo. Cuando empecé a Dubloon, era porque quería hacer un juego de piratas, y decidimos que el mejor género para ofrecer ese tipo de experiencia era un juego de rol. Deja que el género sea tu herramienta... no te conviertas en una herramienta del genero.





*: y si os importa... os podéis poner a hacer encajes de bolillos. XD

18 febrero 2010


Comparte este artículo: | Menéame | Fresqui | Enchílame | Technorati |

Postmortem: Dual Zone

| 3 comentarios |

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

17 febrero 2010


Comparte este artículo: | Menéame | Fresqui | Enchílame | Technorati |

Bitácora Cell Fusion: Actualizacion Product Backlog.

| 0 comentarios |

Saludos lupinos manada.

Por el momento no os puedo contar nada, pero por el momento parece que se me están abriendo nuevas puertas y cerrando las de épocas pretéritas, tanto a nivel laboral, como vocacional e incluso espiritual*. Supongo que a lo largo del año os podré ir informando un poco conforme vayan cristalizando las cosas.

Con respecto a Cell Fusion, por el momento sigo sin poder volver a una dinámica estable, motivo por el que estoy prefiriendo no ponerme fechas en estos momentos. Simplemente, me limito a coger un elemento de la lista y me pongo a trabajar hasta completarlo. Eso si, procuro aprovechar cada momento libre que se me presenta y la verdad es que estoy quedando satisfecho con los resultados. Tras la culminación de la tarea de los sprites, la pila de trabajo va tomando el siguiente aspecto:

Objetivos restantes ("Product Backlog"):

- Intro 1
- Intro 2


- Textos intermedios

- Tutorial
- Final

- Nivel 6
- Ajustes Items

- Completar sprites Sondas
- Añadir nuevas armas [En reconsideración]



Sprint 1: Terminar Intro 1 y hacer los ajustes de los Items.

Semana 1:

- Insertar introducción al inicio.
- Mostrar los textos centrados junto a la imagen.
- Añadir efectos de transición entre imagenes.
- Añadir sonidos y música.

Semana 2:

- Crear los sprites de los nuevos ítems.
- Crear su funcionalidad.
- Redistribuirlos.


Sprint 2: Hacer Intro 2

Semana 1:

- Crear texto.
- Insertar introducción al inicio del nivel.

Semana 2:

- Crear imágenes.
- Añadir sonidos y música.


Sprint 3: Textos intermedios y Final

Semana 1:

- Crear textos (Creados, pero no traducidos)
- Crear imágenes (No me convence como quedan)

Semana 2:

- Insertar los textos al inicio de cada nivel
- Insertar final
- Añadir sonidos y música. (Los sonidos aún no me convencen)


Sprint 4: Tutorial


- Crear textos tutorial
- Crear imágenes tutorial
- Ubicar tutorial


Sprint 5: Nivel 6 completo.

Semana 1:

- Crear imagen jefe final.
- Crear patrones jefe final.

Semana 2:

- Crear flujo nivel.


Sprint 6: Imágenes para las sondas y nuevas armas

Semana 1:

- Crear 18/18 imágenes para las nuevas sondas

Semana 2:[En reconsideración]

- Crear ítems para las nuevas armas
- Implementar las nuevas armas



Eso es todo por hoy con respecto a Cell Fusion.

¡Nos leemos!



* Si alguno quiere venir en pos de mí, niéguese a sí mismo, tome su cruz cada día, y sígame. Porque quien quiera salvar su vida, la perderá; pero quien pierda su vida por mí, ése la salvará. Pues, ¿de qué le sirve al hombre haber ganado el mundo entero, si él mismo se pierde o se arruina?


07 febrero 2010


Comparte este artículo: | Menéame | Fresqui | Enchílame | Technorati |

Bitácora Cell Fusion: "Remasterizado" de Sprites

| 5 comentarios |

¡Saludos lupinos!.

Como ya comenté en la anterior entrada, si bien ando mas liado que el chapísta de MazingerZ, al menos ya tengo tiempo suficiente como para poder seguir desarrollando Cell Fusion.

Uno de los objetivos que tengo enumerados en el "Product Backlog" de la recta final, es la creación y pulimento de los sprites de todas las sondas del juego. Que si bien son pequeñitas, tienen diseños muy mejorables.

La verdad es que a la hora de ponerme manos a la obra me he dado cuenta de como ha ido pasando el tiempo a lo largo del desarrollo y como la experiencia a comenzado a notarse en el apartado gráfico. En mi opinión he mejorado bastante en cuanto a la gestión de la luz y la impresión de volumen. Ahora mismo llevo editadas 9 de las 18 sondas y como compensación a mi larga ausencia, me gustaría enseñaros algunos de estos sprites.


A vuestra siniestra están situadas las imágenes antiguas, a la diestra, las editadas.


También, aunque parezca mentira, me esta yendo bastante bien el gestionar Pixelamos. Ver y traducir tanto tutorial, criticar y observar los trabajos de otros, es muy útil para crecer. A la hora de incluir las sondas en el juego, es posible que tenga que aumentar el contraste y bajar el brillo como consecuencia del efecto Blur.

04 febrero 2010


Comparte este artículo: | Menéame | Fresqui | Enchílame | Technorati |

Regreso a la circulación

| 0 comentarios |

He de admitirlo, los últimos acontecimientos me han desbordado.

El nacimiento de Diana, el cambio de vida, las mudanzas, la inestabilidad laboral... han convertido mi vida en un auténtico desorden.

Me gustaría poder decir que hablo a toro pasado, pero la verdad es que no. Sin embargo, si es cierto que al menos ya estoy en casa y que poco a poco empiezo a amoldarme a la situación.

Durante los últimos días he estado haciendo un poco de "propósito de enmienda" aprovechando el descalabro de mi planificación para las últimas semanas del año. Por una parte, como ya comenté, terminé por animarme a crear la comunidad de Pixel Art, que tanto tiempo llevaba pensando en montar. Hoy a las pocas semanas de haberla creado, ya llega a los 130 usuarios y dispone de una actividad bastante agradable. Por otra, hace poco decidí ponerme manos a la obra y montar de nuevo toda Comunidad Game Maker salvando los datos antiguos, documentando el proceso para futuros administradores y haciendo un cribado en el equipo para sanear la gestión de la comunidad. Ha sido un follón, pero la verdad es que ha quedado mejor que nunca. Otro peso que me quito de encima.

El pequeño retiro, aunque ha sido estresante en muchos aspectos, me ha permitido ver el proyecto de Cell Fusion con un poco mas de perspectiva y librarme de algunas de mis ansiedades por no cumplir objetivos antes de las fechas estipuladas. Si algo tiene bueno caerse, es que del suelo, no pasas. :P

Pero bueno, tampoco se puede decir que no haya estado haciendo nada, conste. Lo que he podido avanzar, ha quedado bastante bien. Se vé que el participar en la comunidad de Pixel Art me está ayudando a aprender mejor la senda del pixel. Sigo sin poder considerarme una eminencia, pero la verdad es que estoy muy contento con lo que me va saliendo.

Por el momento he terminado con el jefe final, que ha resultado ser enorme, casi demasiado, pero que con la rutina sencilla que le he terminado por programar, cumple con lo que el juego necesitaba representando un desafío aceptable.

También he portado el proyecto a GM8, que tiene un intérprete más potente y unos tiempos de carga sensiblemente inferiores con respecto a sus predecesores.

Por último, ahora mismo me estoy dedicando a rehacer todas las sondas. Ahora mismo llevo 6/18 con buenos resultados, al menos para mi gusto. Ahora las variantes de cada modelo se diferencian más entre sí y tienen un acabado bastante más correcto.

En cuanto al guión... al final me parece que le voy a pegar un señor hachazo, ya que tiene poco peso en el juego. Si lo hubiera tenido más en cuenta durante el proceso de diseño, no me vería en esta situación, pero bueno, tampoco se puede decir que no haya aprendido de todo esto.

Objetivos restantes ("Product Backlog"):

- Intro 1
- Intro 2


- Textos intermedios

- Tutorial
- Final

- Nivel 6
- Ajustes Items

- Completar sprites Sondas
- Añadir nuevas armas [En reconsideración]


Sprint 1, semanas 41-42: Terminar Intro 1 y hacer los ajustes de los Items.

Semana 1:

- Insertar introducción al inicio.
- Mostrar los textos centrados junto a la imagen.
- Añadir efectos de transición entre imagenes.
- Añadir sonidos y música.

Semana 2:

- Crear los sprites de los nuevos ítems.
- Crear su funcionalidad.
- Redistribuirlos.


Sprint 2, semanas 43-44: Hacer Intro 2

Semana 1:

- Crear texto.
- Insertar introducción al inicio del nivel.

Semana 2:

- Crear imágenes.
- Añadir sonidos y música.


Sprint 3, semanas 44-45: Textos intermedios y Final

Semana 1:

- Crear textos (Creados, pero no traducidos)
- Crear imágenes (No me convence como quedan)

Semana 2:

- Insertar los textos al inicio de cada nivel
- Insertar final
- Añadir sonidos y música. (Los sonidos aún no me convencen)


Sprint 4, semanas 46-47: Tutorial


- Crear textos tutorial
- Crear imágenes tutorial
- Ubicar tutorial


Sprint 5, semanas 48-49: Nivel 6 completo.

Semana 1:

- Crear imagen jefe final.
- Crear patrones jefe final.

Semana 2:

- Crear flujo nivel.


Sprint 6, semanas 50-51: Imágenes para las sondas y nuevas armas

Semana 1:

- Crear 12/18 imágenes para las nuevas sondas

Semana 2:[En reconsideración]

- Crear ítems para las nuevas armas
- Implementar las nuevas armas



Bueno, pues esto es todo por hoy, tan pronto como me sea posible, estaré aquí de nuevo con vosotros.

¡Nos leemos!