Bitácora Cell Fusion

Bueno, parece que vamos retomando de nuevo el ritmo.

Hoy antes de hablar de Cell Fusion, quiero hablar de otro tema.

Llevo un tiempo pensando en colaborar de forma mas activa a crear cultura de desarrollo también desde el blog; ya no solo con el objetivo de hacer de sus contenidos algo más ameno y útil, sino de intentar ayudar a implantar la costumbre de generar documentación en castellano sobre desarrollo de videjuegos.

Obviamente, hacerme dueño de la idea seria una estupidez por mi parte, ya que esta nace a raíz de la experiencia que surge de leer publicaciones de personas que ya se molestan en hacerlo y nos ayudan a mejorar como desarrolladores con sus articulos. Este tipo de actitud, en la que cada uno se toma la molestia de compartir lo aprendido con sus colegas generando documentación, es otra de las posturas que creo que puede ayudar a crear un ambiente adecuado para la industria hispana.

En lo que a mi bestialidad se refiere, comenzaré a aportar mi granito de arena haciendo lo propio también desde el punto de vista personal, no ya únicamente como parte de un colectivo. Intentaré generar información más a menudo mientras animo a otros a tomar la misma iniciativa. La mayoria de las veces esto conlleva un mayor riesgo de error, ya que a menudo dicha documentación se basa en la experiencia personal, pero también aporta experiencias únicas y mayores posibilidades de corrección y aprendizaje. Es la gracia del contraste.

A ver si así conseguimos crear más culturilla de desarrollo a través de nuestras bitácoras. En serio, resulta muy interesante conocer como hace las cosas cada uno.

Bueno, pues vamos a ser coherentes con el discursito y vamos al lio. No tengo tanta experiencia como me gustaria, pero llevo bastante tiempo recopilando ejemplos y plantillas de proyectos que me han servido para aprender. Partiendo de esta creciente base autodidacta, hablaré del documento de diseño, ese “papelajo ínutil” de cuya ardua escritura se escaquea tanto “desarrollador chapucero” *.

En primer lugar, creo que es importante dejar claro que un documento de diseño puede variar mucho de un desarrollador a otro, ya que no existe una unica forma de hacerlo. Sin embargo, si que es posible crear plantillas que puedan servir de referencia, a partir de las cuales crear el documento que más se adecue a nuestro proyecto y necesidades.

En segundo lugar, creo que también resultaría interesante comentar que si se hubiera que agrupar los documentos en diferentes tipos, podría hacerse un listado como este:

Tipos de documentos:

Documento conceptual. Lector neutro.

Documento técnico: Define implementación. Lector técnico.

Documento mixto. Lectores neutros y técnicos.

Esto no lo he sacado de ningún manual, así que no es más que una observación personal basada en mis lecturas. Si crees que es confusa, o que deberia modificarse, no te cortes y házmelo saber junto con tus porqués. Así aprendemos todos.

Cuando hablo de “Documentos conceptuales“, hablo de documentos en los que el contenido y las secciones se concentran más en el concepto, estudio de mercado y motivos por los que se piensa que el concepto de juego puede ser un éxito, que en los detalles técnicos del mismo. Este tipo de documento suele ser bastante cortito en proporción con los documentos más técnicos. Me parece un modelo de documento muy útil cuando estás barajando ideas para nuevos proyectos, o si quieres convencer a alguien de la viabilidad de tu idea.

Por el contrario, cuando hablo de “Documentos técnicos” hablo de documentos muy detallados, en los que el contenido se centra mucho mas en el como se hacen las cosas a nivel técnico. A mi personalmente este tipo de documentos me resulta muy confuso y varia una bárbaridad dependiendo del tipo de tecnología que utilices. Estos documentos estan orientados a un lector netamente técnico, más que a un lector neutro. Pueden resultar muy utiles para los programadores o técnicos de sonido una vez el proyecto esta en marcha, pero no sirve para vender una idea.

He querido dejar para el final los documentos que he bautizado como “Mixtos” porque son los que creo que mas se amoldan a las necesidades de los que utilizamos herramientas RAD para el desarrollo de videojuegos en pequeños grupos o de forma individual.

Los documentos mixtos están orientados tanto para un lector neutro como para creativos y técnicos. En el se realiza un acercamiento conceptual al principio del documento y se van expresando claramente los objetivos y necesidades del proyecto en cada campo sin caer en excesos a la hora de hacer especificaciones técnicas. Si tuviera que definir en un párrafo el concepto de este tipo de documento seria algo asi como:

Premisa de diseño:

“Define sin espacio para la duda qué y como quieres que funcione cada elemento del juego, pero no especifiques como implementarlo técnicamente, los que mejor sabran como hacerlo son los propios técnicos. Se honesto contigo mismo y no intentes ser músico, programador, grafista y diseñador al mismo tiempo. Si tienes dudas, no te cortes, consulta.”

Voy a hacer un primer acercamiento exponiendo cuales podrían ser las secciones de un documento como el que acabo de mencionar. Más adelante, en próximas entradas, iré explicando mejor que incluye cada sección y como deberíamos abordarla.

Documento de diseño mixto.

Mecánica

Concepto

Flujo

Actores

Elementos

Física y estadística

IA

Multijugador

Interfaz

Organigrama

Requisitos funcionales

Mock-ups

Elementos GUI

Gráficos

Objetivos

Arte 2D y animación

GUI

Marketing y empaquetado

Entorno

Elementos del juego

FX

Arte 3D y animacion

GUI

Marketing y empaquetado

Entorno

Elementos del juego

FX

Cinemática

Video

Música y sonido

Objetivos

Sonido

GUI

FX

Actores

Elementos del juego

Entorno

Movimiento

Música

Alarmas

Pantallas de entorno

Nivel

Situaciones

Cinemáticas

Historia

Niveles

Diagrama de niveles

Revelación de activos

Bases de diseño

Hasta aqui llegamos hoy con los documentos de diseño. Más adelante intentaré profundizar algo más en este esquema.

Vamos ahora con Cell Fusion:

Los objetivos que me propuse para los últimos días del mes fueron estos:

Pulir curva de dificultad del nivel 4 hasta que superar el nivel un 50%+ de las partidas.

Pulir curva de dificultad del nivel 5 hasta que superar el nivel un 25%+ de las partidas.

Pulir los proyectiles de los “Dualshot”.

Definir el “Product Backlog mensual” de Agosto.

Los he cumplido sin problemas, pero durante el proceso he decidido que en el “Product Backlog mensual” de Agosto no voy a complicarme puliendo las curvas de dificultad. Lo dejaré para el final una vez tenga diseñados todos los enemigos.

He decido también, que salvo cambios de última hora el juego contara con 8 fases divididas en 10 oleadas cada una y 8 jefes finales. Cuando tenga terminadas todas las fases tomaré en serio la opción de añadir un segundo modo de juego para añadir variedad a la mecánica. Pero primero lo primero: Terminar de implementar el concepto original. Una vez lo tenga, haremos los estudios pertinentes, no sea que no merezca la pena. “Keep it simple, Stupid” como dirían algunos.

Así pues, el “Product Backlog Mensual” de Agosto quedaría de la siguiente manera:

Product Backlog Agosto

Objetivo:

Implementar 3 prototipos de nivel

Metas:

Diseñar 3 nuevos tipos base de enemigo.

Crear las 3 variantes de IAs.

Crear 3 fondos nuevos.

Partiendo de este “Product Backlog” los objetivos del primer Sprint quedan así:

Objetivos Sprint 4 – 10 Agosto

Diseñar 1 enemigo.

Implementar 1 IA.

Crear 1 fondo.

Deseadme suerte. 🙂 ¡Nos leemos!

---

* Sí, a mi también me ha pasado antes y me he puesto a picar código cual mono harto de setas sin hacerme mi “mapa”, por eso hablo con conocimiento de causa. Ya lo diría en su día el Cordero: “El que esté libre de pecado, que tire la primera piedra” – y el que no, “dos piedras” -.

---

About The Author