Aquí estamos una semana más. La verdad es que nos ha encantado la recepción del artículo de la semana pasada, nos ha pillado por sorpresa completamente. Pensábamos que el artículo podía interesar a algunos programadores, o a gente con interés en saber más sobre el sector videojuegos, pero no esperábamos esta respuesta. Así que aquí estoy de nuevo para seguir contando el proceso de creación de un videojuego.

La semana pasada empecé con los antecedentes y la toma de decisiones sobre qué producto realizar, así como los primeros diseños. Este artículo abarcará dos semanas, y es mucho más denso ya que contiene menos elementos gráficos, y más texto sobre metodologías , herramientas y decisiones sobre mecánicas de juego, interfaz y el desarrollo del primer prototipo.

Antes de seguir con el proceso de producción, explicaré un poco cómo trabajamos, que herramientas usamos y qué metodologías seguimos, ya que de esta manera se entienden mejor muchas de las decisiones que hemos tomado.

Game Tools

Estas son algunas de las herramientas que usamos:

• MAC: imprescindible si desarrollas juegos para iOS y Android. Lo tienes todo en un solo ordenador perfectamente integrado con Unity3D.

• Eclipse: para Android y desarrollo en Java del backend en GAE

• Xcode: para compilar las versiones iOS

• Openoffice: documentos del juego, hojas de cálculo para definir progresión, economía, etc.

• Adobe Photoshop y Flash: suscripción mensual (pago por uso). Es una opción muy asequible que te permite trabajar con las mejores herramientas por menos de 30€/al mes (tenerlo todo legal y barato, es posible)

• Bitbucket (Atlassian) : repositorio de código (gratis hasta 5 usuarios y funciona genial)

• Sourcetree (Atlassian): cliente gratis de Git y Mercurial. Se integra a la perfección con Bitbucket.

• Jira (Atlassian): gestión de proyecto (imprescindible para gestionar las tareas diarias/semanales)

• Testflight: para publicar betas del juego en iOS

• Jenkins (open source): software para realizar integración contínua. Genial para automatizar el proceso de builds diarias, subidas a Testflight, betas… etc.

Game Development Methodologies

En cuanto a las metodologías, usamos varias, adaptadas a nuestras necesidades y a nuestra capacidad productiva. En resumen nos guiamos por estos principios:

• Regla del 20/80 (personalizada): vamos a hacer ese 20% de trabajo que construirá el 80% del producto final.

• Minimum Viable Product (MVP): crea el producto mínimo para salir rápidamente a producción e itera a partir del mismo. Si no puedes publicar en 4-6 semanas, algo estás haciendo mal.

• La estimación inicial del tiempo que tardaremos en hacer algo, lo multiplicamos por 3 y ese será el tiempo real. Por lo tanto, debemos sacar todos los detalles superfluos y todas las funcionalidades y mecánicas no importantes y dejar solo el “core” (lo básico).

• KISS = Keep it Simple, Stupid!: nos lo recordamos a nosotros mismos cada día.

• Si no lo podemos representar gráficamente (en diseños de pantallas del juego) no lo vamos a programar.

• Ciclo semanal de versiones de test: cada semana sacamos una build para ver como vamos.

También tenemos un reunión diaria a principio del día para ver como va todo el mundo en sus tareas y por si alguno se atasca. Esta reunión diaria permite que todo el mundo sepa que tareas estamos haciendo todos, y así poder dar su opinión sobre el producto que estamos haciendo.

La ventaja de empresas pequeñas como la nuestra es que todo es muy directo y familiar. La comunicación es clara y sin barreras, y eso permite una gran efectividad en el desarrollo. Por otra parte, al ser equipos pequeños, la capacidad productiva es muy limitada. Este último punto, que mas bien parece una desventaja, es en realidad una ventaja, ya que te obliga maximizar y focalizarte en lo realmente importante.

Game Design

Otro punto que es bastante importante es formalizar mínimamente el juego y sus mecánicas. Tras probar varios juegos llegamos a las siguientes conclusiones:

• No  vamos a inventar nada: intentar ser originales e innovadores en un juego en 4-6 semanas es tirar el dinero y garantía de fracaso absoluto. Vamos a mejorar lo existente. Sobretodo prestando detalle en aquellos puntos que creemos no se han cuidado bien en los juegos ya publicados: aspecto gráfico, usabilidad, interacción social y, el más importante, personalización completa.

• Vamos a tomar lo mejor de cada uno de los juegos que hemos probado y a hacer nuestra versión. Los juegos principales de referencia son: Tamagotchi, Pou y Pocket Pup

Siendo formales, al diseñar un videojuego, deberíamos crear un GDD (Game Design Document) donde se documente todo lo relativo al videojuego. El GDD es algo así como la biblia del mismo.

La realidad es que no hay tiempo para hacer un GDD como Erú manda, así que trabajamos con un docmento que describe las cuatro características del juego y una hoja de cálculo donde se introducen las mecánicas básicas (hambre, sueño, energía…etc), logros, tienda  y descripción de la economía virtual. Partimos de una base, la implementamos, la probamos y luego iteramos hasta ajustar valores.

Durante las primeras semanas de publicación ajustaremos los valores de economía (precio de las cosas y monedas que se consiguen), a partir del feedback de los usuarios y de nuestras estadísticas de juego.

Game Design: Minigames

Y llegamos al tema de los minijuegos: Aunque no todos los juegos de mascotas virtuales tienen minijuegos, y ciertamente no creemos que sean necesarios para que el juego tenga éxito, es cierto que tampoco perjudican. La cuestión es delicada: ¿los tendrá? Nos encantaría, pero para la primera versión, no podemos.

Cada minijuego tiene un coste de desarollo elevado (en tiempo y dinero). Solo para que os hagáis una idea, cada uno puede llevarnos 1-2 semanas diseñarlo, programarlo y probarlo. Se necesita un artista al menos 1 o 2 días y luego un programador. Eso supone unos costes de producción de entre 1.000 y 2.000€ por cada minijuego (sueldos + seguridad social + costes indirectos). En un equipo tan pequeño como el nuestro (2 programadores, un game designer-producer y un artista) y con serios límites de presupuesto, no es viable incluirlos como parte de un ciclo de producción de 4-6 semanas. Solo el desarrollo del «core» del juego ya se va a comer ese tiempo (y eso que una parte del equipo trabaja de lunes a domingo).

Así que tomamos esta decisión: Minijuegos Sí, pero no en la primera versión. La primera versión incluirá las mecánicas básicas de la mascota, toda la parte de interacción social (marcar como favoritos otros Petogotchi, buscar a tus amigos) y la personalización de colores, ropa, disfraces… etc.

Game Interface

Aquí tenéis algunas imágenes de los primeros diseños de interfaz de usuario que hicimos:

Fijaos que los iconos de estado de la parte superior son diferentes, ya que son dos de las pruebas que hicimos (los más parecidos a los finales son los de la izquierda).

Game Fx

Otro punto crítico es el apartado de Fx y musical. En Blinzy no tenemos un músico en plantilla así que debíamos buscar un freelance para este proyecto. A tal fin, pusimos un anuncio convocando un “concurso” para seleccionar el artista.

Preparamos los vídeos que aparecen en el artículo que publicamos la semana pasada y contactamos con más de 60 músicos que nos habían escrito interesándose por el proyecto. Al final, y tras unos días de selección, nos quedamos con el trabajo de David, de Machinet Música.

Aunque no todos los sonidos que hizo nos gustaron, si que hubo un par que consideramos que los había clavado. David lleva ya un par de semanas trabajando en los sonidos, y pronto podréis ver los resultados de su trabajo.

Game State Machine

Y llegamos a un punto clave en el desarrollo: definir el corazón del petogotchi, su máquina de estados. No voy a entrar en detalles sobre todas las discusiones y brainstormings que tuvimos durante 3 días. El trabajo fué realmente intensivo, y por desgracia, no me acordé mucho de hacer fotos y documentar todo el proceso, pero si que tengo una imagen que os dará una idea de lo complejo que fue el proceso. La versión final de Petogotchi difiere un poco, pero va por este camino.

Al final, más que una máquina de estados, decidimos construir una máquina de máquinas de estados. Debido a la gran cantidad de combinaciones posibles entre acciones, tipos de ojos, pupilas, pelo, manos… etc

Es decir, cada parte del cuerpo de Petogotchi y sus complementos, tienen estados asociados (visible o no visible). Y por encima de ellos, tenemos una gran máquina de estados que lo controla toda: por ejemplo, si nuestro Petogotchi se pone triste, simplemente aplicamos las características distintivas de estar triste (tipo de ojos, pupilas…etc) sin modificar lo que ya tenga activo (que ni lo sabemos, ni nos importa). De esta manera no tenemos que precalcular ni saber todos los estados posibles (sería una locura, debido a la gran cantidad de combinaciones).

Game Programing: primera versión e interfaz de usuario

Otro punto crítico trabajando con Unity es la la interfaz de usuario. Un punto débil que tiene Unity en teléfonos móviles y tablets es el número de draw calls que se hacen. Unity no está muy bien preparado para trabajar con muchos elementos de interfaz de usuario (botones, iconos, flechas, listas de elementos, etc…) Si creas estos elementos como Game Objects, lo único que conseguirás es multiplicar las draw calls y que al final afecte al rendimiento del terminal.

Por suerte hay una serie de plugins que puedes comprar en Asset Store de Unity3D que te permiten diseñar una interfaz de usuario interesante (en realidad son plugins que luego transforman los elementos de UI en una mesh de manera que son llamados en una sola, o muy pocas, draw calls) y que dan un gran resultado en móviles.

Aquí tenéis una imagen de la complejidad y multitud de elementos en una pantalla de Petogotchi.

Game Prototype

A continuación tenéis algunos de los videos que grabamos con las primeras pruebas de ejecución dentro del Unity (el último incluye las primeras pruebas de sonidos).

Game Test: Xperia S

Finalmente, empezamos a programar. Llegado a este punto y tras una semana de programación, probamos el primer prototipo. A continuación tenéis algunos de los videos en que petogotchi ya vive y se mueve dentro de Unity y el primer prototipo cargado en el Xperia S!

A destacar que la interfaz está completamente desalineada con el dispositivo, muchos iconos están escondidos y el 95% de los botones aún no funcionan bien. Todavía faltaba mucho trabajo por hacer, pero queda muy poco tiempo. De hecho ya vemos que seguramente tendremos una semana de retraso en la publicación de la beta.

Y por último, dejo mi twitter y el de Blinzy Studios, por si queréis seguirnos y estar al día de todas las novedades de nuestros juegos.

¡Hasta la próxima semana!