Basado en el curso «Designing Mobile Games with a Game Design Document» de Christopher Kao para Pluralsight.

https://app.pluralsight.com/library/courses/designing-mobile-games-game-design-document-1827/table-of-contents

¿Que es un GDD (Game Design Document)?

Es un documento que incluye todos la información del juego. Incluye los siguientes aspectos:

Mécanica del juego: Determina si es un rpg, plataforma, puzzle, etc. Define subsistemas, mejoras de personaje, sistema de compra, economía del juego, etc. Todos esos subsistemas deben ser escritos y explicados dentro del juego.

• Analizando la mecánica

1. Piense en la mecánica: movimientos, ataques, acertijos.
2. ¿Puede ser prototipado?, si no es así, ¿se puede descomponer en partes más pequeña para su prototipo?
3. ¿Cómo se comunican entre si los sistemas del juego?

Organiza el juego en secciones manejables: explica a alguien que no conoce el juego como funciona, además permite reconocer que sistemas son mas importantes de construir en primera medida.

Da al equipo de desarrollo un punto de partida para trabajar. Ya sea un equipo de una sola persona o más, es importante tener un archivo de documentación para que los desarrolladores puedan guiarse. El documento de desarrollo debe darle respuestas claras acerca del juego. Debe responder a dos preguntas: grandes, que son sistemas de trabajo, mecánica de monetización, estilo de arte. Las respuestas medias son aspectos técnicos del juego, como valores núméricos.

¿Para quien son los GDD?

• Para los programadores
• Artistas (pero no es una guia de estilo, sino guia de funcionalidad)
• Equipo de marketing (no necesariamente todo el documento les es valioso)

1. Secciones del documento GDD

Introducción

Es la descripción de la historia, en gran medida la descripción que aparece en la plataforma de venta o en la carátula del juego.

Concepto

Acá se explica la mecánica del juego pero no explica la historia.

Características

Son detalles específicos del juego, aspectos relevantes que lo definen. Ejemplo: niveles autogenerados, 4 protagonistas, personajes configurables.

Plataforma objetivo

Es la plataforma donde corre el juego, IOS, Android, PS, Xbox, Nintendo, PC, etc.

Género

Categoriza el juego según la mecánica. FPS, puzzle, SIM, etc.

Audiencia objetivo

Aunque lo que cualquiera desea es que todo el mundo pruebe el juego, siempre hay grupos demográficos que aceptan un tipo de juego más que otro.

Juegos de referencia

Son los juegos que son similares al que se están creado. Sirven como comparativa de calidad y competencia.

---

2. Ejemplo del GDD

Introducción

Bienvenidos a Ciudad Vida, un lugar donde hay que pagar para vivir (Si…. la película de Justin Timberlake donde se mueren si no pagan y pueden llegar a ser inmortales)

Concepto

Ciudad Vida es una mezcla de In Time con The Running Man. El jugador controla a uno de los cuatro personajes de la historia, quienes participan por monedas que les darán tiempo extra para seguir avanzando y conseguir librarse de su prisión del tiempo.

Características

• 4 niveles
• Puzzle mediante cambio de color
• Más de 100 power ups
• Mundo Sci fi

Plataforma objetivo

• iOS
• Android

Género

• Plataforma

Audiencia Objetivo

• Adolecentes a adulto, de 15-25

Juegos de referencia

• Temple Run
• Super Mario Bros
• Pitfall

3. Mecánica del juego

Ejemplo de análisis de mécanica

Correr y saltar

Coleccionar monedas

Poderes

Cuando se consigue un hongo Mario crece.

Si consigue una flor, obtiene poder para lanzar fuego.

¿Qué pasa si obtiene dos poderes iguales?

• Hongo + Hongo = nada
• Flor + Flor = nada
• Flor + nada = crece y no adquiere poder https://www.youtube.com/watch?v=4-QXKl3qK6g

Diagrama de flujo en GDD

Los diagramas de flujo pueden ayudar a visualizar diferentes aspectos del juego, no solo lógica del programa. Estos son unos ejemplos:

• Mapa general
• Recorrido de pantalla a pantalla
• Menú de opciones
• Relación entre menú y pantallas
• Relaciones entre jugabilidad (juego normal, muerte, reinicio, etc)
• Separar el sistema en subsistemas (salvado, compras, etc)

Wireframe

El modelado del marco nos permite ver problemas de funcionalidad antes de enviar a producción.

Los diseñadores de interfaz necesitan ver estos diseños para saber como proceder.

Estos diseños no tienen gran calidad visual y esto es agrede, porque su objetivo es evaluar la funcionalidad en lugar de dar pistas de diseño, de eso se encarga la sección de Arte Conceptual.

Deben ser fácilmente manipulables para hacer cambios rápidos.

Es recomendable colocar comentarios en el wireframe para analizar una idea e identificar errores de diseño o lógica.

Los pasos del ciclo de producción son los siguientes:

1. Diseño (menor costo para hacer cambios)
2. Prototipo
3. Construcción
4. QA (quality assurance, «gestión de calidad») (mayor costo para hacer cambios)

Mientras más adelante se vaya en el proceso, más caro sale hacer cambios. Lo mejor es hacer los cambios lo más pronto posible.

• 

• 

Estilo del arte y detalles de narrativa

El GDD está principalmente enfocado para desarrolladores de software, no es una guía de estilo y no debe ser usado de esa forma. La finalidad del arte que se incluye en el GDD es la de ser un punto de referencia acerca de lo que debe expresar el juego, pero no de dice a los artistas como dibujarlo.

Incluye lo siguiente:

Entorno: explica el lugar donde se desarrolla el juego.

Protagonistas: explica como se ve el protagonista, su estatura, estilo de diseño (realista, animado, infantil, etc).

Interfaz de usuario: explica como quiere que se vea la interfaz que el usuario va a tener. Por ejemplo si el juego es futurista, se esperaría una interfaz moderna tipo sci fi.

Primera iteración del estilo de arte

Cuando se diseña por primera vez la sección de arte, no se espera que sean imágenes de concepto de alto nivel, ni siquiera se espera algún tipo de diseño propio. Para ello se emplean fotografías de entorno o arte real que ilustre aquella idea que se quiere plasmar en el juego.

Si el juego es de vikingos, se pueden incluir imágenes de museos o entornos reales.

Historia y diálogo

No se escribe la historia completa ni los diálogos completos dentro del GDD, eso temas van aparte.

Mecánicas para retención de usuarios

Retención es simplemente lo que lo hace volver a jugar el juego nuevamente.

NO ES lo que lo hace jugar por largo tiempo.

La mecánica de retención debe ser desarrollada en el principio ya que es difícil añadirla posteriormente.

Lo principal para que el juego produzca retención es que tenga una mecánica divertida.

Fundamentos de retención

• Profundidad del juego: Muchas cosas por hacer, habilidades por perfeccionar.
• Cambiar el sistema de juego: añadir nuevo contenido, evolucionar los mundos, competición.
• Asignación de cargos: es el hecho de ponerle tareas al usuario (para que lo obligue a volver luego), por ejemplo en los juegos de granjas, donde las cosechas tienen un tiempo de crecimiento y el usuario vuelve al juego para recoger la cosecha.
• Tiempo de enfriamiento: es el tiempo de espera para volver a utilizar una función del juego.
• Conexión emocional: es el apego que genera el usuario por el personaje, por ejemplo en juegos de mascotas o citas.

Caso de estudio: Clash of Clans

• Tiene profundidad de jugabilidad, muchas cosas por hacer.
• El estilo de juego cambia, los mundos evolucionan, hay competición.
• Tiene asignación de cargos, porque tiene elementos de construcción que requieren tiempo para construirse.
• Tiene tiempos de espera.
• Genera obligación para cuidar de dicho entorno.

Viralidad del juego

Es la habilidad de atraer público, ya sea por mano propia o de forma orgánica.

Formas de conseguir viralidad

• Compartir por redes sociales.
• Pedir ayuda a amigos para así ganar recursos.
• Boca a boca.
• Retos en grupo. Se le pide ayuda a amigos para completar una tarea.

Viralidad y retención hacen parte del núcleo del juego, por lo que no se pueden dejar aparte o para desarrollo posterior. Ambos tópicos van en la sección de mecánica del juego.

Cosas que recordar

• Mantener el juego relevante.
• Incentivar el juego, ya sea obtener algo en el juego o conseguir una respuesta emocional.
• Hacerlo fácil para compartir, que el menú no sea difícil de manejar.
• No esperar que porque se tiene un botón de compartir en el juego, la gente va a llegar y le dará compartir. Eso no añade viralidad al juego, porque no lo hace sencillo de compartir, ya que desconecta la diversión del juego con una tarea fuera de este.

Sistema de salvado

Es un aspecto muy importante que no se puede pasar por alto y debe tener su propia sección en el GDD.

Se puede guardar local o en línea.

Se puede tener juegos por perfil.

Para compras en línea y guardado de archivos, Apple y Google tienen reglas estrictas sobre el particular y deben considerarse.

Rastreo de métricas, para esto se necesita una solución cloud.

En el GDD se hace una lista de aquello que necesita ser salvado, luego los ingenieros determinan como almacenar correctamente dicha información.

Ejemplo:

• Nivel del jugador
• Experiencia del jugador
• Monedas del jugador
• Items del jugador
• Información del perfil
  • Fotos
  • Nombres
  • Ligas
  • Login
  • Password
  • etc.

Monetización del juego

Sencillamente es como el juego va a hacer dinero.

Debe pensarse acerca de la monetización en las primeras etapas del juego. Nuevamente, mientras más tarde se asigne al núcleo del juego, más caro será hacer la modificaciones.

Alternativas de cobro

• Premium: cobrar un valor fijo por la aplicación.
  • Pros
    • Después de la venta ya no importa el juego.
    • Requiere poca inversión para el mantenimiento.
  • Contras
    • Menor audiencia.
    • Las ventas se reducen rápidamente después de la fecha de lanzamiento.
• Freemium: dar gratis el juego y tener cobro interno.
  • Pros
    • Da la posibilidad de tener muchos jugadores probando el juego.
    • Posibilidad de que el jugador gaste dinero sin límite.
    • Mayor tiempo de vida útil del juego.
  • Contras
    • Muchos gastos internos frustran al jugador y se van
    • Muchos jugadores que no pagan (la mayoría), eso eleva el costo de servicio.

Consumibles del juego

Son opciones de compra, generalmente en juegos fremium. Hay dos tipos, permanentes, aquellos que el jugador conserva eternamente y consumibles, aquellos que se gastan y debe volver a adquirir.

Actualización del GDD

Un documento GDD no es algo fijo, que solo tiene una versión, al contrario, puede recibir modificaciones. Se puede usar un control de versiones para seguir el rastro a los cambios del documento.

Una recomendación podría ser usar LateX junto a Bitbucket.

---

https://en.wikipedia.org/wiki/Super_Mario_Bros.

https://www.upwork.com/hiring/for-clients/importance-of-wireframing-mobile-apps/

https://www.worldofleveldesign.com/categories/csgo-tutorials/csgo-how-to-draw-top-down-layouts.php

https://www.behance.net/gallery/56464093/ENVIRONMENT-CONCEPT-ART-ENVIRONMENT-DESIGN

http://lukasz.io/work/firefall-video-game-scifi-ui/

https://www.behance.net/gallery/68962197/Random-Character-Design-18

https://www.androidcentral.com/clash-clans-android-tips-and-tricks

Ver en Medium.com