Está en la página 1de 198

I NSTITUTO DE C OMPUTACI ÓN ,

FACULTAD DE I NGENIER ÍA - U NIVERSIDAD DE LA


R EP ÚBLICA

I NFORME DE P ROYECTO DE G RADO

Una Metodologı́a Ágil para Desarrollo


de Videojuegos

Autores: Tutores:
Nicolás Acerenza Eduardo Fernández
Ariel Coppes Tomás Laurenzo
Gustavo Mesa Diego Vallespir
Alejandro Viera

Septiembre 2009
Resumen

Tras relevar las empresas que desarrollan videojuegos en Uruguay, se detecta que
son pequeñas, generalmente abarcan proyectos de corta duración con equipos reduci-
dos y no cuentan con una metodologı́a para desarrollo formalizada. Sin embargo,
siguen algunos de los principios de las metodologı́as ágiles, las cuales se adaptan con
éxito al desarrollo de videojuegos a nivel mundial en realidades similares.
Como aporte al desarrollo de la industria en Uruguay, se construye la metodologı́a
SUM para Desarrollo de Videojuegos. Esta se adapta a las caracterı́sticas relevadas en
las empresas de desarrollo de videojuegos uruguayas y se basa en los principios ágiles,
utilizando Scrum y Extremme Programming como base de su construcción.
Para la validación y evaluación de SUM se desarrolla un caso de estudio donde
se contemplan algunas de las caracterı́sticas de la realidad local. En él, se implementa
un prototipo de videojuego 3D de acción, multijugador distribuido llamado Splinks
Deathmatch. Para su implementación se utiliza el lenguaje de programación Java y el
motor de videojuegos JMonkeyEngine. De la evaluación que se realiza al finalizar el
caso de estudio, se concluye que SUM cumplió con sus objetivos y ayudó a mitigar
varios de los problemas que se encuentran al desarrollar un videojuego. La evaluación
permitió mejorar SUM ya que se realizaron ajustes a los problemas detectados.
Índice General

1 Introducción 7
1.1 Descripción del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Plan de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Organización del Informe . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Estado del Arte 10


2.1 Cadena de Valor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Modelos de Ingreso . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Probar Antes de Comprar . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Retail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Publicidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.4 Advergaming . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.5 Suscripción . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.6 Torneos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.7 Microtransacciones . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.8 Móviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Plataformas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.3 Dispositivos Móviles . . . . . . . . . . . . . . . . . . . . . . 16
2.3.4 Consolas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Tipos de Videojuego . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 Casuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.2 Educativos . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.3 Hardcore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Roles y Disciplinas . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 Arte Sonoro . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.2 Arte Gráfico . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.3 Diseño de Juego . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.4 Programación . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.5 Producción . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.6 Verificación . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Metodologı́as para Desarrollo de Videojuegos . . . . . . . . . . . . . 20
ÍNDICE GENERAL 3

2.6.1 Codificar y Corregir . . . . . . . . . . . . . . . . . . . . . . 21


2.6.2 Cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6.3 Metodologı́as Ágiles . . . . . . . . . . . . . . . . . . . . . . 23
2.6.4 Adaptaciones de Metodologı́as Ágiles para Videojuegos . . . 26
2.6.5 Análisis de las Metodologı́as para Videojuegos . . . . . . . . 29

3 Relevamiento de la Industria de Videojuegos en Uruguay 31


3.1 Empresas Relevadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1 Batovi Game Studio . . . . . . . . . . . . . . . . . . . . . . 31
3.1.2 Kef Sensei . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.3 Mystery Studios . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.4 Powerful Robot Games . . . . . . . . . . . . . . . . . . . . . 33
3.2 Situación Actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.1 Fortalezas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.2 Debilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.3 Oportunidades . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.4 Amenazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Metodologı́as de Desarrollo Relevadas . . . . . . . . . . . . . . . . . 36

4 Metodologı́a SUM para Desarrollo de Videojuegos 38


4.1 Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Especificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5 Proceso de Entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5.1 Concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5.2 Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.3 Elaboración . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.4 Beta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5.5 Cierre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5.6 Gestión de Riesgos . . . . . . . . . . . . . . . . . . . . . . . 55
4.6 Guı́as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5 Evaluación de SUM para Desarrollo de Videojuegos 58


5.1 Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Evaluación de Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3 Evaluación del Proceso de Entrega . . . . . . . . . . . . . . . . . . . 60
5.3.1 Concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.2 Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.3 Elaboración . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3.4 Beta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.5 Cierre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.6 Gestión de Riesgos . . . . . . . . . . . . . . . . . . . . . . . 63
5.4 Evaluación de Guı́as . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6 Conclusiones y Trabajo Futuro 64


4 ÍNDICE GENERAL

Anexos

A Gestión del Proyecto 78


A.1 Fases y Actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.2 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

B Relevamiento 81
B.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
B.1.1 Batovi Game Studios . . . . . . . . . . . . . . . . . . . . . . 81
B.1.2 Kef Sensei . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
B.1.3 Powerful Robot Games . . . . . . . . . . . . . . . . . . . . . 82
B.1.4 Mystery Studios . . . . . . . . . . . . . . . . . . . . . . . . 82
B.2 Infraestructura, Tecnologı́as y Herramientas . . . . . . . . . . . . . . 82
B.2.1 Batovi Game Studios . . . . . . . . . . . . . . . . . . . . . . 83
B.2.2 Kef Sensei . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
B.2.3 Powerful Robot Games . . . . . . . . . . . . . . . . . . . . . 83
B.2.4 Mystery Studios . . . . . . . . . . . . . . . . . . . . . . . . 83
B.3 Aspectos de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . 83
B.3.1 Batovi Game Studios . . . . . . . . . . . . . . . . . . . . . . 84
B.3.2 Kef Sensei . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
B.3.3 Powerful Robot Games . . . . . . . . . . . . . . . . . . . . . 84
B.3.4 Mystery Studios . . . . . . . . . . . . . . . . . . . . . . . . 85
B.4 Equipos de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.4.1 Batovi Game Studios . . . . . . . . . . . . . . . . . . . . . . 85
B.4.2 Kef Sensei . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.4.3 Powerful Robot Games . . . . . . . . . . . . . . . . . . . . . 86
B.4.4 Mystery Studios . . . . . . . . . . . . . . . . . . . . . . . . 86
B.5 Metodologı́a de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . 86
B.5.1 Batovi Game Studios . . . . . . . . . . . . . . . . . . . . . . 86
B.5.2 Kef Sensei . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.5.3 Powerful Robot Games . . . . . . . . . . . . . . . . . . . . . 88
B.5.4 Mystery Studios . . . . . . . . . . . . . . . . . . . . . . . . 89

C Splinks Deathmatch - Documento de Concepto 91


C.1 Visión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
C.2 Género . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
C.3 Mecánica de Juego . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
C.4 Caracterı́sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
C.5 Ambientación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
C.6 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
C.7 Público Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
C.8 Plataforma Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
C.9 Tecnologı́as y Herramientas . . . . . . . . . . . . . . . . . . . . . . 93
C.10 Bocetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

D Splinks Deathmatch - Documento de Diseño de Juego 98


ÍNDICE GENERAL 5

D.1 Mecánica de Juego . . . . . . . . . . . . . . . . . . . . . . . . . . . 98


D.1.1 Personajes . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
D.1.2 Elementos Coleccionables . . . . . . . . . . . . . . . . . . . 99
D.1.3 Elementos de la Escena . . . . . . . . . . . . . . . . . . . . . 99
D.1.4 Modos de Juego . . . . . . . . . . . . . . . . . . . . . . . . 100
D.2 Interacción con el Usuario . . . . . . . . . . . . . . . . . . . . . . . 100
D.2.1 Cámaras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
D.2.2 Controles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
D.2.3 Información en Pantalla . . . . . . . . . . . . . . . . . . . . 101
D.2.4 Pantallas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
D.3 Personajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
D.3.1 Splink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
D.3.2 Criaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
D.4 Escenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

E Splinks Deathmatch - Documento de Diseño Técnico 106


E.1 Tecnologı́as Seleccionadas . . . . . . . . . . . . . . . . . . . . . . . 106
E.1.1 Generación de Contenidos . . . . . . . . . . . . . . . . . . . 106
E.1.2 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . 106
E.2 Estados del Juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
E.3 Escena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
E.4 Controles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
E.5 Sombras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
E.6 Colisiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
E.7 Máquina de Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
E.8 Controladores y Componentes . . . . . . . . . . . . . . . . . . . . . 115
E.9 Inteligencia Artificial . . . . . . . . . . . . . . . . . . . . . . . . . . 117
E.10 Información en Pantalla . . . . . . . . . . . . . . . . . . . . . . . . . 118
E.11 Contenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
E.12 Versionado y Liberaciones . . . . . . . . . . . . . . . . . . . . . . . 121
E.13 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

F Splinks Deathmatch - Evaluación Postmortem 123


F.1 ¿Qué Salió Mal? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
F.2 ¿Qué Salió Bien? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
F.3 Lecciones Aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . 126

G Metodologı́a SUM para Desarrollo de Videojuegos 127


G.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
G.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
G.2.1 Equipo de Desarrollo . . . . . . . . . . . . . . . . . . . . . . 127
G.2.2 Productor Interno . . . . . . . . . . . . . . . . . . . . . . . . 132
G.2.3 Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
G.2.4 Verificador Beta . . . . . . . . . . . . . . . . . . . . . . . . 135
G.3 Proceso de entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
G.4 Fase: Concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6 ÍNDICE GENERAL

G.4.1 Actividad: Desarrollo del Concepto . . . . . . . . . . . . . . 137


G.5 Fase: Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
G.5.1 Actividad: Planificación Administrativa . . . . . . . . . . . . 142
G.5.2 Actividad: Especificación del Videojuego . . . . . . . . . . . 147
G.6 Fase: Elaboración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
G.6.1 Actividad: Planificación de la Iteración . . . . . . . . . . . . 151
G.6.2 Actividad: Seguimiento de la Iteración . . . . . . . . . . . . . 155
G.6.3 Actividad: Desarrollo de Caracterı́sticas . . . . . . . . . . . . 157
G.6.4 Actividad: Cierre de la Iteración . . . . . . . . . . . . . . . . 158
G.7 Fase: Beta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
G.7.1 Actividad: Planificación de la Iteración . . . . . . . . . . . . 162
G.7.2 Actividad: Verificación del Videojuego . . . . . . . . . . . . 165
G.7.3 Actividad: Corrección del Videojuego . . . . . . . . . . . . . 167
G.8 Fase: Cierre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
G.8.1 Actividad: Liberación del Videojuego . . . . . . . . . . . . . 169
G.8.2 Actividad: Evaluación del Proyecto . . . . . . . . . . . . . . 171
G.9 Fase: Gestión de Riesgos . . . . . . . . . . . . . . . . . . . . . . . . 173
G.9.1 Actividad: Evaluación de Riesgos . . . . . . . . . . . . . . . 173
G.10 Productos de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . 176
G.10.1 Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
G.10.2 Salidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
G.11 Guı́as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
G.11.1 Artı́culos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
G.11.2 Conceptos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
G.11.3 Guı́as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
G.11.4 Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
G.11.5 Plantillas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
G.11.6 Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . 195
G.11.7 Material de apoyo . . . . . . . . . . . . . . . . . . . . . . . 196
Introducción
1
En este capı́tulo se describe el alcance y objetivos del proyecto de grado. En la
sección 1.1 se presenta la definición del proyecto y su contexto junto con los objetivos
y el resultado esperado. En la sección 1.2 se muestra el plan de trabajo a seguir. Por
último, en la sección 1.4 se describe la organización de este informe.

1.1 Descripción del Proyecto


Un videojuego, según Wolf [Wol07], es un programa de computación creado para
el entretenimiento en el que existe interacción entre una o varias personas y un aparato
electrónico. Los elementos que se esperan encontrar son: conflicto contra un oponente
o contra las circunstancias, reglas que determinan qué se puede hacer y qué no, el
uso de las habilidades del jugador (p.ej. destreza, estrategia o suerte) y un resultado
valorado (p.ej. obtener la mayor puntuación o realizar una tarea en el menor tiempo).
El desarrollo de un videojuego es una actividad multidisciplinaria que involucra,
entre otros, al desarrollo de software y a la creación audiovisual. El proceso de desa-
rrollo consta de sus propias etapas diferentes a las del software tradicional y al tener
objetivos difı́ciles de medir, como la diversión, construirlos constituye un gran desafı́o.
Este proyecto se enmarca en las actividades de los grupos de Ingenierı́a de Software
y del Centro de Cálculo. Tiene como objetivo proponer una metodologı́a para el desa-
rrollo de videojuegos afı́n con los requerimientos de la industria en el Uruguay. Para
ello, es necesario relevar el estado del arte de la ingenierı́a software en el desarrollo de
videojuegos y las distintas metodologı́as y procesos de desarrollo usados por las em-
presas de videojuegos de la industria local. Se espera también evaluar la metodologı́a
propuesta utilizándola en la implementación de un prototipo de videojuego.
Como resultado se espera obtener:

Estudio del estado del arte de los procesos para desarrollos de videojuegos.

Relevamiento sobre los procesos de desarrollos de videojuegos en la industria


nacional, sus principales carencias, necesidades y virtudes.

Propuesta de un proceso adecuado para la industria nacional (grupos humanos


reducidos, proyectos de pocos meses de duración, etc.).

7
8 1.2. PLAN DE TRABAJO

Evaluación de la metodologı́a propuesta.

Sitio web con la metodologı́a propuesta.

Artı́culo con los principales resultados.

1.2 Plan de Trabajo


Al comienzo del proyecto se establecen las principales fases y los hitos a alcanzar.
Las actividades que se realizan no se planifican antes de comenzar el proyecto, sino
que se van definiendo durante el transcurso de este.
Las fases que se definen son:

Relevamiento de la Industria de Videojuegos en Uruguay: entrevistar a represen-


tantes de las principales empresas uruguayas dedicadas al desarrollo de video-
juegos y analizar sus caracterı́sticas, metodologı́as y proceso de desarrollo.

Relevamiento del Estado del Arte: investigar la industria de videojuegos y en


particular la ingenierı́a de software aplicada a su desarrollo.

Definición del Alcance: determinar la metodologı́a a realizar en base a las carac-


terı́sticas y necesidades detectadas en la industria uruguaya y a lo relevado en el
estado del arte.

Construcción de la Metodologı́a: construir una metodologı́a para desarrollo de


videojuegos de acuerdo al alcance definido.

Caso de estudio: construir un prototipo de videojuego utilizando la metodologı́a


propuesta.

Análisis y Ajustes: analizar la ejecución del caso de estudio para detectar las
virtudes y carencias de la utilización de la metodologı́a propuesta y realizarle
ajustes.

Documentación: documentar los principales resultados obtenidos.

1.3 Publicaciones
Como parte del trabajo del proyecto de grado se publica un reporte técnico del
Pedeciba-Informática y un artı́culo en el Simposio Argentino de Ingenierı́a de Software
de las Jornadas Argentinas de Informática e Investigación Operativa.

Acerenza, N., Coppes, A., Mesa, G., Viera, A., Fernández, E., Laurenzo, T.,
Vallespir, D. “Una Metodologı́a para Desarrollo de Videojuegos: Versión Exten-
dida”. Facultad de Ingenierı́a, Universidad de la República, RT 09-13 PEDECIBA-
InCo, ISSN0797-6410, Montevideo, Uruguay, Julio, 2009.
CAPÍTULO 1. INTRODUCCIÓN 9

Acerenza, N., Coppes, A., Mesa, G., Viera, A., Fernández, E., Laurenzo, T.,
Vallespir, D. “Una Metodologı́a para Desarrollo de Videojuegos”. En anales del
Simposio de Ingenierı́a de Software - 38 Jornadas Argentinas de Informática e
Investigación Operativa, pp. 171-176, Mar del Plata, Argentina, Agosto, 2009.

1.4 Organización del Informe


El resto del presente informe tiene como objetivo presentar la metodologı́a desarro-
llada, los elementos utilizados para su creación y un análisis de su ejecución median-
te un caso de estudio. En el capı́tulo 2 se introducen los principales conceptos sobre
videojuegos y el estado del arte en ingenierı́a de software aplicada a este tipo de desa-
rrollos. En el capı́tulo 3 se presenta el análisis del relevamiento realizado en la industria
de videojuegos del Uruguay haciendo hincapié en las metodologı́as utilizadas para el
desarrollo. En el capı́tulo 4 se define la metodologı́a para desarrollo de videojuegos
propuesta. En el capı́tulo 5 se analizan los principales resultados obtenidos en la apli-
cación de la metodologı́a en un caso de estudio y los ajustes realizados luego de la
evaluación.
Se finaliza el informe con el capı́tulo 6 que presenta las conclusiones del proyecto
y las posibles lı́neas de trabajo futuro en el área.
En forma adicional se entregan los siguientes anexos:

Anexo A: cronograma de ejecución del proyecto de grado junto con las princi-
pales tareas realizadas.
Anexo B: análisis del relevamiento realizado en cada una de las empresas visi-
tadas.
Anexo C: concepto y motivación del Splinks Deathmatch.

Anexo D: diseño de juego del Splinks Deathmatch.


Anexo E: documento de diseño técnico del Splinks Deathmatch que detalla todas
las decisiones de diseño tomadas.
Anexo F: evaluación postmortem del videojuego construido que resume los as-
pectos positivos y negativos ocurridos durante su desarrollo junto con las lec-
ciones aprendidas.
Anexo G: especificación completa de la metodologı́a SUM para Desarrollo de
Videojuegos, tal como se describe en el sitio web
http://www.gemserk.com/sum/.
Estado del Arte
2
En este capı́tulo se presentan los principales conceptos sobre videojuegos necesa-
rios para la comprensión del resto del documento.
Las dos primeras secciones presentan los aspectos de negocio más importantes para
comprender cómo funciona la industria de videojuegos. En la sección 2.1 se muestra la
cadena de valor de la industria, mientras que en la sección 2.2 se introducen los mode-
los de ingreso existentes para comercializar videojuegos. En la sección 2.3 se detallan
las principales plataformas para las que se desarrollan videojuegos. En la sección 2.4
se caracterizan los tipos de videojuego de interés para nuestro trabajo. En la sección 2.5
se presentan las diferentes disciplinas y roles involucrados en el desarrollo de videojue-
gos. Por último, en la sección 2.6 se describen y analizan las metodologı́as utilizadas
actualmente.

2.1 Cadena de Valor


La industria de los videojuegos está en continuo crecimiento desde hace varios
años, el mercado de Estados Unidos en el 2006-2007 tuvo un crecimiento del 22 %
[ESA08] y el mercado europeo en el 2007-2008 tuvo un crecimiento del 15 % [aDe09].
En Estados Unidos las ventas de videojuegos del año 2007 fueron de 9.5 billones de
dólares [ESA08] sobrepasando a la industria cinematográfica, como ocurre desde hace
varios años. El 40 % de los europeos pasan entre seis y catorce horas a la semana
jugando videojuegos [ISF07].
Esta industria es similar en su estructura de negocios a otras industrias creativas
como la editorial, la cinematográfica y la discográfica, ya que se basa en la creación, pu-
blicación y distribución de productos de propiedad intelectual (obras o tı́tulos) [ADV04].
Para representar a las diversas etapas que un producto atraviesa en su camino al
consumidor final se utiliza una cadena de valor. Su nombre se debe a que cada eslabón
le agrega valor al producto o servicio final. En la Fig.2.1 se aprecia la cadena de valor de
la industria de los videojuegos [WR06] y la manera en que sus miembros interactúan.
La cadena comienza cuando los desarrolladores crean un nuevo videojuego. Este
proceso involucra la contribución de diseñadores de juego, productores, programadores,
artistas gráficos, artistas sonoros y otros. Lo que producen los desarrolladores es el
videojuego listo para pasar al siguiente nivel en su camino al consumidor final. Esta es
CAPÍTULO 2. ESTADO DEL ARTE 11

Figura 2.1: Cadena de Valor de la Industria de Videojuegos

tı́picamente una de las etapas más competitivas dado que hay muchos desarrolladores
y solo algunos videojuegos llegan a ser exitosos.
Existen tres eslabones que le brindan servicios o herramientas a los desarrolladores:
subcontratistas, proveedores de herramientas y fabricantes de consolas.
Los subcontratistas son individuos o compañı́as que se especializan en diferentes
áreas de contenido creativo y que son subcontratados por los desarrolladores para reali-
zar alguna parte especı́fica del videojuego (p.ej. captura de movimiento, diseño gráfico,
gráficos de alta calidad, música y efectos de sonido).
Los proveedores de herramientas juegan un rol muy importante en la construc-
ción de un videojuego. Sus productos ahorran tiempo a los desarrolladores haciendo
que tareas comunes sean más sencillas y permitiendo poner mayor foco en la creación
del videojuego. Algunos ejemplos de herramientas son motores 3D, frameworks, edi-
tores de imágenes y entornos de desarrollo.
Los fabricantes de consolas se encargan de diseñar y manufacturar los sistemas
de consolas. Cuando se desarrollan videojuegos para su plataforma cobran una licen-
cia por cada copia manufacturada. Estas empresas mantienen un estricto control sobre
qué tı́tulos obtienen la licencia, haciendo de las consolas un mercado altamente contro-
lado y hermético.
En el siguiente eslabón en la cadena se encuentran los publishers, que juegan un rol
12 2.2. MODELOS DE INGRESO

clave, por un lado trabajando junto con los desarrolladores para crear el videojuego y
por otro vendiendo y publicitando esos videojuegos. En lo que refiere a la creación, los
publishers suelen proveer servicios como financiamiento, supervisión de la producción,
aseguramiento de la calidad y manejo de liberaciones. Tı́picamente contratan a una
compañı́a de desarrollo externa para realizar un videojuego pagando a medida que
avanza el proyecto. Estos pagos suelen ser un adelanto de las ganancias por ventas, por
lo que si el videojuego es exitoso el desarrollador obtiene mayores ganancias. Los pu-
blishers suelen preparar los videojuegos para ser vendidos y generar las versiones para
las ventas internacionales. Además, se encargan del marketing y las relaciones públicas
y trabajan con distribuidores y retailers para llevar los videojuegos a los canales de
venta.
Los distribuidores agregan valor al publicar los videojuegos en cientos de canales
de venta.
En el eslabón final de la cadena se encuentran los retailers o portales. Tradicional-
mente los retailers son las tiendas y supermercados que venden videojuegos. En al-
gunos casos este papel es ocupado por los portales (páginas web que los consumidores
visitan para probar y comprar videojuegos), cuyo valor está determinado por el po-
tencial de ganancias que se relaciona directamente con el número de usuarios que lo
visitan regularmente. Suelen proveer contenido exclusivo, programas de subscripción,
concursos y caracterı́sticas de comunidad.
El dinero que alimenta a todos los eslabones de la cadena surge de los consumi-
dores. En algunos casos estos proveen dinero directamente al pagar por el videojuego
y en otros los anunciantes lo hacen en nombre del consumidor por patrocinar el video-
juego.

2.2 Modelos de Ingreso


A continuación se presentan los principales modelos de ingreso que se utilizan en
la industria de videojuegos y se describen sus caracterı́sticas, fortalezas y debilidades.
Esta sección se basa principalmente en la serie de artı́culos sobre el mercado de los
videojuegos presentados por Owain Bennallack [Cas08].

2.2.1. Probar Antes de Comprar


Los consumidores pueden jugar una demo limitada por algún mecanismo (p.ej.
tiempo, funcionalidades y cantidad de ejecuciones). Mientras transcurre el videojuego
se sugiere comprar la versión completa (up-sell) y una vez que expira la demo se debe
efectuar la compra para continuar jugando [Ben08b]. Una variante común es ofrecer
una versión web gratuita que se ejecuta en el navegador. Estas versiones pueden ser
jugadas cuantas veces quiera el usuario pero tienen menos funcionalidades, menor con-
tenido y baja calidad de sonidos y gráficos comparados con la versión completa para
descargar.
Las ganancias tı́picas de un desarrollador van desde el 20 % al 50 % sobre la venta.
Una forma de medir el éxito de un videojuego es observar la tasa de conversión, esto es,
CAPÍTULO 2. ESTADO DEL ARTE 13

el porcentaje de pruebas que se convierten en ventas. Generalmente esta tasa es baja,


1 % se considera buena y si se encuentra por encima del 2 % se considera excelente.
La mayor ventaja de este modelo es que permite al consumidor probar el video-
juego antes de comprarlo. Cuando la compra requiere de un pago electrónico tiene la
desventaja de que los menores de edad pueden no tener acceso. Otro problema es que
hay mucho material en esta modalidad, por lo cual los consumidores pueden disfrutar
de una gran cantidad de contenido sin que los desarrolladores obtengan ganancia. Solo
unos pocos videojuegos logran ganancias significativas, por lo que los desarrollos sue-
len ser financiados externamente minimizando el riesgo económico del desarrollador y
reduciendo sus ganancias.

2.2.2. Retail
El videojuego se vende en tiendas en diversos medios fı́sicos (p.ej. CDs, DVDs o
cartuchos) [Ben08a]. Este tipo de ventas es un mercado masivo y bien establecido.
Una caracterı́stica de este modelo es que el consumidor debe comprar el videojuego
para poder jugarlo. Esto puede ser ventajoso ya que, a diferencia de Probar Antes de
Comprar, el consumidor no tiene acceso al contenido sin pagar. Otra de las ventajas es
que al venderse en una caja puede ser comprado como un regalo. Además, se puede
acceder a consumidores que no tienen tarjetas de crédito y que no desean correr los
riesgos o no están familiarizados con la compra en lı́nea.
Como desventaja, este modelo adiciona los costos de fabricar los materiales fı́sicos
(p.ej. cajas y manuales) y distribuirlos. Esto agrega más intermediarios y por lo tanto
menores ganancias para el desarrollador. Además, las copias no vendidas significan
una pérdida económica importante haciendo más difı́cil conseguir una inversión para
vender el videojuego de esta forma.

2.2.3. Publicidad
Se muestran avisos publicitarios durante el videojuego que pueden ser de dos tipos:
carteles y cortes con anuncios. El primero consiste en mostrar avisos en carteles para
los videojuegos que se ejecutan en un navegador web. El segundo consiste en embeber
avisos cortos en el videojuego que son mostrados durante su inicio, entre niveles y/o
en otros intervalos durante su transcurso.
Este modelo no suele ser la principal fuente de ganancias del videojuego, sino un
ingreso complementario. Una de sus ventajas es que esta forma de publicidad es efec-
tiva gracias a la gran cantidad de visitantes que pasa por los portales de videojuegos.
Además, no se requiere de ventas para ganar dinero y puede generar ingresos de públi-
co que no puede comprar en lı́nea (p.ej. niños). Un aspecto negativo es que por la
facilidad para aplicar este modelo de ingreso existen una gran cantidad de sitios que
ofrecen videojuegos de mala calidad y que confunden a los consumidores.

2.2.4. Advergaming
Un patrocinador financia total o parcialmente el desarrollo del videojuego para pro-
mocionar una marca, producto o mensaje [WR06]. La diferencia con Publicidad es que
14 2.2. MODELOS DE INGRESO

los avisos forman parte del videojuego. El Advergaming incluye desde avisos sutiles,
como un cartel del patrocinador al costado de una cancha de fútbol o un ı́tem de la
marca, hasta un videojuego en el que se controla la mascota emblema del patrocinador.
En el primer caso, el patrocinador suele ser una fuente de ingresos extra mientras que
las ganancias principales vienen de la venta del videojuego. Si el videojuego está ente-
ramente dedicado a la marca suele ser totalmente financiado por el patrocinador, siendo
este el único ingreso del desarrollador.
Si la marca es popular puede atraer muchos jugadores, sin embargo, el videojuego
necesitará su propia página web y campaña de marketing e igualmente solo algunos
llegan a tener una audiencia amplia. Además, es difı́cil tanto para el desarrollador como
para el patrocinador evaluar el retorno de la inversión.

2.2.5. Suscripción
Surge en respuesta a los bajos porcentajes de consumidores que compran más de un
videojuego a través del modelo Probar Antes de Comprar [Ben08d]. Existen diversas
formas de Suscripción denominadas: Todo lo que Pueda Consumir, Compras por Mes
y Miembro Vip.
En Todo lo que Pueda Consumir, el consumidor paga una cuota fija por mes y
tiene la posibilidad de jugar en forma ilimitada a cualquier videojuego incluido en
la subscripción. En Compras por Mes, el consumidor paga una cuota fija por mes y
obtiene uno o más videojuegos gratis y descuentos al comprar otros. Siendo Miembro
Vip, el consumidor paga una cuota fija por mes y obtiene privilegios especiales (p.ej.
acceso a ı́tems o pantallas nuevas).
En este modelo las ganancias son repartidas entre el publisher y los desarrolladores
según la cantidad de partidas que se comienzan para cada tı́tulo en particular. Esta es
la única medida que se puede tomar con relativa precisión.
Tiene como ventaja la entrada de dinero recurrente y predecible mediante la fi-
delización del cliente. Además, pueden conseguir dinero de consumidores que nunca
pagarı́an por la descarga de un videojuego pero si por nuevos ı́tems o pantallas. Como
desventaja, este modelo es difı́cil de establecer y los servicios deben ofrecer contenido
exclusivo. Además, puede implicar una posible pérdida de ingresos para los desarrol-
ladores debido a consumidores que podrı́an haber comprado el videojuego utilizando
el modelo Probar Antes de Comprar a un costo mayor que mediante el pago de la
subscripción.

2.2.6. Torneos
Los jugadores pagan una cuota de entrada para participar en un torneo y el ganador
obtienen dinero o premios en mercaderı́as [Ben08c]. El organizador del torneo obtiene
sus ganancias quedándose con una parte de las cuotas por entrada.
Una ventaja es que los jugadores pagan por adelantado. Además, este tipo de mode-
lo atrae jugadores que gustan de las competencias y no están interesados solamente en
jugar. Los videojuegos que utilizan este modelo suelen permanecer buen tiempo en el
mercado ya que permiten a los jugadores ganar experiencia y conseguir mejores rivales
cada vez. Son los propios jugadores quienes proveen los incentivos para el videojuego,
CAPÍTULO 2. ESTADO DEL ARTE 15

tanto en competencia como en premios, lo que hace necesario una gran audiencia para
alcanzar una buena experiencia de juego.
La mayorı́a de los videojuegos que se practican en esta modalidad son simples, lo
que disminuye los costos de desarrollo. Por otro lado, los aspectos de seguridad son
crı́ticos para garantizar la credibilidad del torneo siendo necesario especial cuidado y
mayor inversión en la prevención de fraudes.

2.2.7. Microtransacciones

Se distribuye el videojuego en forma gratuita o por un precio bajo y luego se cobra a


los jugadores por complementos que se quieran incorporar (p.ej. nuevos niveles, armas
o mejoras en los personajes) [Ben08f]. Los consumidores perciben los complementos
como un beneficio y no como un costo, e incluso puede convertirse en una entrada de
dinero recurrente mientras se siga creando nuevo contenido.
Este modelo permite abatir la piraterı́a ya que la fuente principal de ingresos no es
la venta del videojuego sino la de los complementos y se puede tener un control mucho
más estricto sobre estos. En comparación con Retail, este modelo permite profundizar
el vı́nculo con el jugador lo que puede llevar a una mayor ganancia con el tiempo. Sin
embargo, no genera ganancias rápidamente sino que depende de las microtransacciones
que se realicen. Una de las dificultades es la necesidad de contar con un sistema de ad-
ministración de las cuentas de usuario más sofisticado que en otros modelos de ingreso.
También es difı́cil evaluar el valor de una nueva caracterı́stica ya que los jugadores se
pueden sentir estafados si son más costosas de lo que ellos consideran apropiado.

2.2.8. Móviles

Se realiza la compra del videojuego al acceder al portal de un operador a través de


un Dispositivo Móvil [Ben08e]. El videojuego puede ser utilizado tanto tiempo como
el usuario posea el dispositivo.
Una ventaja es que el pago se realiza a través del operador, como usualmente se
pagan el resto de los servicios del Dispositivo Móvil, por lo que el usuario se siente
cómodo con esta modalidad. Un problema es que tienen poca exposición debido a que
se debe lograr que el videojuego sea descargado solo por el nombre y una foto. Los
más exitosos consiguen ser descargados poco tiempo después de su salida al mercado
y luego sus ventas bajan drásticamente. Por esta corta duración de los tı́tulos es que se
destinan pocos fondos para el desarrollo, por lo que deben ser realizados rápidamente
y sin poner el foco en la calidad o la innovación [WMR+ 05].
En este modelo se agregan nuevos eslabones a la cadena de valor para llegar al
usuario final, como son los operadores y los fabricantes de dispositivos móviles. Por lo
tanto, el valor que paga el consumidor se divide entre muchos intermediarios reducien-
do las ganancias del desarrollador.
16 2.3. PLATAFORMAS

2.3 Plataformas
A continuación se presentan las caracterı́sticas más relevantes de las plataformas
para las que se desarrollan videojuegos, especı́ficamente: PC, Web, Dispositivos Mó-
viles y Consolas.

2.3.1. PC
Los videojuegos para PC se instalan y ejecutan desde la computadora del usuario
final. Los sistemas operativos para los que se desarrolla son Windows, Linux y Mac
OS. Se utilizan frameworks que permiten portar el código a cualquiera de estos sistemas
operativos sin realizar modificaciones (p.ej. Torque Game Builder [Gar08], Playground
SDK [Pla08c] y SDL [SDL08]).
Una ventaja al desarrollar videojuegos para PC es la variedad de tecnologı́as e-
xistentes, muchas gratuitas y de código abierto. Además, los videojuegos tienen tanto
potencial gráfico y de procesamiento como tenga la PC en la que se ejecuta. Esto es
beneficioso ya que siempre se pueden desarrollar videojuegos que aprovechen lo últi-
mo de la tecnologı́a de hardware. Por otro lado, esto puede ser una desventaja ya que
los consumidores que no cumplen con los requerimientos no pueden ejecutar el video-
juego. Adicionalmente, la gran variedad de configuraciones de hardware y software
que un consumidor puede tener implica que la verificación no pueda realizarse siempre
para todas las combinaciones.

2.3.2. Web
Son aquellos videojuegos que se ejecutan desde un navegador web sin la necesidad
de un instalador externo. Las tecnologı́as comúnmente usadas para desarrollar incluyen
Flash [Fla09], Shockwave [Sho09], Java [Mic08] y C++ [dJRS+ 06] distribuido vı́a un
control ActiveX [MSD09]. Suelen desarrollarse en un par de meses y no requieren una
gran inversión en recursos humanos o tecnológicos.
Tienen la ventaja de que los datos están en un servidor web, por lo que pueden
ser jugados accediendo a los datos del jugador desde cualquier lugar y en cualquier
momento. Generalmente no requieren ninguna configuración especı́fica y pueden ser
actualizados de forma transparente, lo que los hace idóneos para usuarios inexpertos.
Como desventaja, esta plataforma está más limitada en gameplay y gráficos que una
PC o Consola y además requiere de conexión a internet.

2.3.3. Dispositivos Móviles


Son videojuegos que se desarrollan para teléfonos celulares o PDAs. Estos dispo-
sitivos son portátiles y están en red, dos caracterı́sticas muy atractivas. Las tecnologı́as
más utilizadas en el desarrollo son J2ME [Mic09], BREW [QUA09] y Symbian OS
[Fou09].
En la actualidad, existen aproximadamente 3.300 millones de celulares en el mundo
[Onl08], esto convierte a los Dispositivos Móviles en un mercado muy atractivo para el
desarrollo de videojuegos. Entre las principales ventajas se encuentran que requieren
CAPÍTULO 2. ESTADO DEL ARTE 17

pocos recursos para su desarrollo y los proyectos tienen una duración corta, de uno
o dos meses. Como desventaja, se debe portar el videojuego a una gran variedad de
tipos de dispositivos para poder abarcar el mayor público posible, lo cual es complejo
y costoso ya que cada modelo tiene caracterı́sticas diferentes.

2.3.4. Consolas
Los videojuegos para Consolas son aquellos que se desarrollan para un dispositivo
diseñado especialmente para videojuegos. En la actualidad las Consolas que lideran el
mercado son Microsoft XBox 360 [Cor08b], Sony PlayStation 3 [Méx09a], Sony PSP
[Méx09b], Nintendo DS [Nin08a] y Nintendo Wii [Nin08b].
Desarrollar para Consolas es más costoso que para PC [Duf08] ya que requiere
una mayor inversión en personal, tiempo y recursos tecnológicos. Otra desventaja es
que se debe estar aprobado o certificado por la compañı́a a la que pertenece la con-
sola para poder obtener el kit de desarrollo y vender el videojuego, lo cual hace más
difı́cil acceder a este mercado. Existen algunas excepciones como Xbox Live Commu-
nity [Cor08c] y XNA Creators Club [Cor08a] que permiten publicar videojuegos para
ser descargados desde la Xbox 360 y además proveen herramientas de desarrollo para
esta consola y Windows.

2.4 Tipos de Videojuego


A continuación se presentan algunos tipos de videojuego de interés para nuestro
trabajo. Para cada uno se describen los modelos de ingreso y plataformas que se suelen
utilizar, la intención, el público objetivo y los géneros más comunes. Estas descrip-
ciones se basan en la International Game Developers Association (IGDA) [WR06].

2.4.1. Casuales
Son videojuegos fáciles de aprender, utilizan controles simples y presentan poca
complejidad en el gameplay. Su intención es que el jugador pueda divertirse y rela-
jarse sin requerir un alto grado de atención o compromiso. Las plataformas principales
para las que se desarrollan son PC, Web y Dispositivos Móviles, aunque se está in-
crementando el desarrollo para Consolas. Están dirigidos a una audiencia de hombres
y mujeres entre 35 y 65 años. En el mercado actual las mujeres son la mayorı́a de la
audiencia, aunque está creciendo el número de jugadores masculinos.
De acuerdo a la plataforma objetivo se siguen modelos de ingreso distintos. Cuando
la plataforma objetivo es PC se utiliza mayormente el modelo Probar Antes de Comprar
y en menor medida Suscripción y Retail. Cuando la plataforma es Web se utilizan los
modelos de Suscripción y Advergaming. Por último, cuando la plataforma objetivo es
Dispositivos Móviles el modelo de negocio seguido es el de Móviles.

2.4.2. Educativos
Son videojuegos cuya intención principal es educar o entrenar al jugador en una
actividad especı́fica. Un género muy utilizado en este tipo de videojuegos es la simu-
18 2.5. ROLES Y DISCIPLINAS

lación, donde el jugador puede llevar a cabo acciones como si fuera la vida real (p.ej.
simuladores de vuelo o de manejo de tanques).
Las audiencias son variadas y dependen de la temática a difundir. Las plataformas
o modelo de negocio varı́an según el videojuego. En la mayorı́a de los desarrollos el
financiamiento es externo ya que son especı́ficos para un propósito.

2.4.3. Hardcore
Estos videojuegos presentan complejidad en el control y en el aprendizaje, inno-
vación en el gameplay e historias y personajes desarrollados. Requieren que el jugador
tenga un alto grado de compromiso y destreza para progresar en el videojuego. Las
principales plataformas son PC y Consolas y el modelo de negocio por excelencia es
Retail, aunque existe un creciente uso del modelo de Microtransacciones y Suscrip-
ción. La audiencia a la que apuntan son hombres entre 18 y 34 años y entre los géneros
favoritos se encuentran aquellos donde hay acción y competencia intensa (p.ej. aven-
turas, deportes y pelea).

2.5 Roles y Disciplinas


Dentro de las disciplinas involucradas en el desarrollo de videojuegos se encuentran
la generación de contenidos audiovisuales (p.ej. bandas sonoras y modelos 3D), diseño
de juego y desarrollo de software, entre otros.
En esta sección se describen las principales disciplinas involucradas en el desarrollo
de un videojuego [IGD08]. Para cada una de estas se define el rol asociado y se presen-
tan algunas áreas especı́ficas según las distintas habilidades requeridas. Se debe notar
que las áreas presentadas no se desarrollan necesariamente en todos los proyectos.

2.5.1. Arte Sonoro


El arte sonoro involucra todas las caracterı́sticas relacionadas al audio del video-
juego. Entre las habilidades necesarias se encuentran, por ejemplo, tener conocimientos
de formatos de audio e instrumentos musicales. Además, es importante la colaboración
con otras disciplinas ya que el audio debe estar coordinado con el área visual y la lógica
para lograr una buena experiencia de juego. Se denomina artista sonoro al rol asociado
a esta disciplina. Las áreas especı́ficas relacionadas son:

Ingenierı́a de sonido: creación de todo el material de audio en el videojuego,


excepto la música. Se generan, editan, y comprimen los efectos sonoros para los
elementos del videojuego (p.ej. los sonidos que produce un personaje al realizar
una acción).

Composición: composición de las bandas sonoras del videojuego en el forma-


to que se requiera. Además, se define el estilo musical y las transiciones de la
música para cada uno de los estados o pantallas.
CAPÍTULO 2. ESTADO DEL ARTE 19

2.5.2. Arte Gráfico


En esta disciplina se desarrollan todas las caracterı́sticas relacionadas con el con-
tenido visual del videojuego. Entre las habilidades requeridas se encuentran, por e-
jemplo, diseño gráfico y modelado 3D de objetos. Se denomina artista gráfico al rol
asociado a esta disciplina. Las áreas especı́ficas relacionadas al arte gráfico son:

Arte de concepto: definición de la estética del videojuego. Se crean bocetos de los


personajes y del ambiente para dar vida a la visión de los diseñadores de juego.
Estos bocetos guı́an a los artistas gráficos durante el desarrollo para mantener la
coherencia de estilos. Es necesario contar con la habilidad para generar imágenes
de calidad rápidamente.
Modelado: construcción de los modelos de personajes y objetos del videojuego
(p.ej. un animal o un árbol). Para los personajes se requiere conocer de anatomı́a
humana o animal para hacerlos creı́bles y de animación para que se puedan
mover naturalmente. Para los objetos se requiere entrenamiento en diseño in-
dustrial o mecánico para conocer el balance, los materiales y la fı́sica de cada
elemento.
Animación: construcción de las animaciones que dan vida a los personajes a
partir de las acciones que estos pueden realizar.
Texturizado: creación de las texturas visibles que cubren los modelos tridimen-
sionales y los escenarios en el videojuego. Se requieren habilidades de fotografı́a
y de diseño gráfico.

2.5.3. Diseño de Juego


Esta disciplina involucra el diseño y especificación del gameplay definiendo las
reglas, modos de juego, escenarios, historia y personajes con sus capacidades y reac-
ciones. El objetivo principal al momento del diseño es lograr la diversión, para lo que
se debe balancear la dificultad y ajustar las distintas propiedades del gameplay. Entre
las habilidades necesarias se encuentra el tener un amplio conocimiento sobre video-
juegos y en particular sobre todos los elementos que hacen a su diseño. También es
necesario tener buenas habilidades de comunicación y conocimiento sobre las disci-
plinas de arte, sonido y programación para poder interactuar en forma efectiva. Se
denomina diseñador de juego al rol asociado a esta disciplina. Las áreas especı́ficas
relacionadas al diseño de juego son:

Diseño de juego: definición de las acciones que puede tomar el jugador, las re-
glas, los personajes y los modos en que se juega el videojuego.
Diseño de niveles: construcción de los niveles del juego, generando los escena-
rios en los que el jugador participa. Además, se determinan los desafı́os a resolver
en cada nivel.
Guión: creación de los diálogos, narrativas, instrucciones, historia y cualquier
otro texto requerido para el videojuego.
20 2.6. METODOLOGÍAS PARA DESARROLLO DE VIDEOJUEGOS

2.5.4. Programación
La disciplina de programación involucra la creación del código del videojuego y de
las herramientas necesarias para desarrollarlo. También se requiere de la participación
en la disciplina de los artistas gráficos y sonoros para lograr la integración de sus crea-
ciones al videojuego. Se denomina programador al rol asociado a esta disciplina. Las
áreas especı́ficas relacionadas son:

Programación de lógica: diseño, implementación y verificación de las carac-


terı́sticas que definen el videojuego. Estas caracterı́sticas incluyen desarrollar
la fı́sica, los elementos que componen el gameplay, la interfaz gráfica y la in-
teligencia artificial, entre otros.

Programación de contenido: integración del contenido audiovisual al videojuego.


Esto involucra implementar efectos, desarrollar partes del motor gráfico, opti-
mizar la compresión de video, desarrollar shaders y algoritmos de animación en
tiempo real, reproducir y mezclar sonidos en respuesta a eventos del videojuego
y reproducir música interactiva, entre otros.

Programación de componentes: desarrollo de los componentes del videojuego


que no necesariamente forman parte del gameplay. Los principales componentes
son el motor de juego, las herramientas para ayudar a los artistas y diseñadores
a interactuar con este y los componentes de red, entre otros.

2.5.5. Producción
La disciplina involucra la gestión del videojuego en su totalidad. Dentro de esta
se encuentra la interacción con el cliente, obtención de recursos y comunicación del
estado del videojuego a todos los involucrados, entre otros. Se denomina productor al
rol asociado a esta disciplina.

2.5.6. Verificación
Esta disciplina tiene como objetivo asegurar la calidad externa del videojuego. Las
principales actividades que se realizan son verificar las caracterı́sticas funcionales y no
funcionales del videojuego y reportar desviaciones del diseño, errores y cómo repli-
carlos para que puedan ser reparados. Se denomina verificador al rol asociado a esta
disciplina.

2.6 Metodologı́as para Desarrollo de Videojuegos


A partir de las mesas redondas realizadas en la Game Developer Conference (GDC)
sobre ingenierı́a de software aplicada videojuegos de los años 2002 [LS08], 2003
[Llo08a] y 2004 [Llo08c], se puede ver que las metodologı́as más utilizadas para el
desarrollo de videojuegos son codificar y corregir y variantes de cascada. En los
CAPÍTULO 2. ESTADO DEL ARTE 21

últimos años toma fuerza la tendencia a utilizar metodologı́as ágiles en varias empre-
sas desarrolladoras de videojuegos, convirtiéndose la adaptación con éxito de este tipo
de metodologı́as en tema central en las GDC de 2008 [Lew08] y 2009 [Kei09].
A continuación se describen las principales caracterı́sticas de las metodologı́as
mencionadas y se realiza un análisis sobre las ventajas y desventajas que tienen para
el desarrollo de videojuegos. Se pone especial énfasis en las metodologı́as ágiles y sus
adaptaciones en la industria, ya que se observa que sus caracterı́sticas son las que mejor
se adaptan con éxito al desarrollo de videojuegos, por los beneficios que reportan las
empresas que las implantan.

2.6.1. Codificar y Corregir


El modelo codificar y corregir (en ingles code-and-fix) consiste, según Steve Mc-
Connell [McC96], en escribir código y luego corregir los errores del mismo. Mc-
Connell afirma que “Si no se ha seleccionado explı́citamente el modelo de proceso,
probablemente se está utilizando codificar y corregir por defecto. Si no se ha hecho
mucha planificación, sin duda se está utilizando codificar y corregir”.

Figura 2.2: El modelo de codificar y corregir.

Este modelo comienza con una idea general de lo que se quiere construir, pudien-
do existir una especificación formal o no. Luego se utiliza cualquier combinación de
metodologı́as informales de diseño, codificación, corrección y verificación apropiadas
hasta que se obtiene el producto final.

2.6.2. Cascada
Las metodologı́as de tipo cascada o cascada iterativa se usan desde hace años en la
industria de videojuegos y en el software en general. Los proyectos de videojuegos en
particular, atraviesan ciertas fases que se convirtieron en estándares de la industria. En
la Fig.2.3 se muestra dicho modelo de proceso. A continuación se describen esas fases
y sus objetivos como las identifica Bob Bates en su libro Game Design [Bat04].
El desarrollo del concepto es la primera etapa del diseño de un videojuego. El
equipo en esta fase consiste solamente de un diseñador, un lı́der técnico, un artista de
concepto y un productor. El objetivo principal es decidir sobre que es el videojuego y
ponerlo en papel claramente de forma que cualquiera pueda entenderlo. Durante esta
fase se deciden los principales elementos del gameplay, se crea arte de concepto y se
comienza a escribir la historia.
22 2.6. METODOLOGÍAS PARA DESARROLLO DE VIDEOJUEGOS

Figura 2.3: El modelo de cascada para videojuegos

Los objetivos de la fase de preproducción son, completar el diseño del videojuego,


planificar el proyecto y crear la biblia de arte (describe la estética del videojuego y
todos los objetos visuales a ser creados). También se hacen prototipos técnicos que
demuestran la factibilidad de las nuevas tecnologı́as que se esperan utilizar. La prepro-
ducción prueba que el equipo puede hacer el videojuego y que vale la pena hacerlo.
La fase de producción, también llamada desarrollo, es el comienzo de la construc-
ción del videojuego. Durante esta se escribe el código, se crea el arte gráfico y el arte
sonoro, los niveles y el resto de los elementos que componen al videojuego. En esta
fase la idea sobre el videojuego puede cambiar o evolucionar, pudiéndose desarrollar
nuevas caracterı́sticas o eliminar otras. Se deben completar y mantener actualizados los
documentos ya generados.
La fase alfa comienza cuando existe una versión del videojuego que se puede jugar
de principio a fin. En esta versión se encuentran implementados el motor de juego, la
interfaz de usuario y todos los grandes subsistemas del videojuego. Esto no implica
que todo el contenido audiovisual esté terminado e integrado. Cuando se llega a la
versión alfa el foco del trabajo cambia de construir a terminar y de crear a corregir. Es
el momento para mirar en detalle las caracterı́sticas del videojuego y decidir si alguna
de ellas debe ser eliminada para cumplir con los tiempos planificados. Se incorporan
verificadores al proyecto para identificar la mayorı́a de errores posibles. Además, es la
primera vez que el videojuego es visto y evaluado por gente que no pertenece al equipo
de desarrollo.
En la fase beta existe una versión del videojuego con todo el contenido audiovisual
integrado y todas las caracterı́sticas implementadas. En esta fase el desarrollo se de-
tiene y lo único que se hace es corregir errores. El objetivo es estabilizar el proyecto y
eliminar la mayor cantidad de errores posible antes de liberar el juego.
CAPÍTULO 2. ESTADO DEL ARTE 23

Una vez solucionados los errores encontrados en la fase beta (o al menos los más
crı́ticos) se obtiene la versión candidata para la liberación final. Aquı́ se congela el códi-
go y queda pendiente de aprobación para pasar a ser la versión final. Solo se permite
corregir errores que son fatales para el progreso del videojuego.
En la fase de liberación se obtiene la versión final para comercializar una vez que
el videojuego se verifica y valida.

2.6.3. Metodologı́as Ágiles


Los procesos y metodologı́as ágiles se basan en el manifiesto ágil [Man08] que
plantea:

Individuos y sus interacciones frente a procesos y herramientas.


Software en funcionamiento frente a documentación exhaustiva.
Colaboración del cliente frente a una negociación de contrato.
Respuesta al cambio frente a seguir un plan.

Esto quiere decir que aunque los términos de la derecha tienen valor, se valoran
más los de la izquierda.

Son varias las metodologı́as ágiles existentes, algunos ejemplos son Open Up [c+ 08],
Crystal Methods [Coc06], Feature-Driven Development (FDD) [PF02] y Lean Deve-
lopment [Pop03], Scrum [SB01] y XP [BA04]. En particular aquı́ se describen las dos
últimas por la existencia de casos de éxito y los beneficios que reportan para desarro-
llo de videojuegos. También se presentan casos reales del uso en la práctica los cuales
incluyen las fortalezas y debilidades que se detectan en su adopción.

Scrum
Scrum es una metodologı́a ágil para administrar y controlar el desarrollo de soft-
ware de un producto en forma iterativa e incremental. Una de sus caracterı́sticas es que
no indica prácticas especı́ficas a seguir durante el desarrollo [ASR02]. Esto brinda fle-
xibilidad y permite ajustar el proceso a la realidad y forma de trabajo de cada proyecto,
ası́ como a los diferentes requerimientos de los clientes.
Según la descripción que realiza Ken Schwaber [SB01], Scrum se estructura en
tres fases denominadas pre-game, game y post-game como se muestra en la Fig.2.4.
Durante el pre-game se define el producto basado en las caracterı́sticas conocidas, es-
timando su tiempo y costo. También se analiza el sistema a construir, se define la ar-
quitectura y se realiza un diseño de alto nivel de la solución. La fase de game consta de
iteraciones, llamadas sprints que duran de dos a seis semanas y donde se desarrollan
las caracterı́sticas del producto. Al comienzo de cada una se realiza su planificación,
donde se describen, priorizan y estiman las caracterı́sticas que se van a desarrollar y
al concluir se evalúa su resultado. El post-game es el cierre del proyecto, donde se
prepara la liberación del producto, se verifican las versiones a entregar y se realiza la
documentación final.
24 2.6. METODOLOGÍAS PARA DESARROLLO DE VIDEOJUEGOS

Figura 2.4: Las fases de Scrum

La metodologı́a define tres roles entre los cuales se dividen todas las responsabili-
dades de un proyecto: Product Owner, Scrum Master y Scrum Team.
El Product Owner está a cargo del proyecto y es quien maneja y prioriza las
caracterı́sticas a desarrollar.
El Scrum Master es el responsable de que los miembros del equipo sigan el pro-
ceso como es debido y de remover los impedimentos que surjan en el transcurso
de este.
El Scrum Team es un equipo multidisciplinario y auto organizado, y su cometido
principal es construir el producto que el Product Owner especifica.
Además se define un conjunto de artefactos a utilizar: Product Backlog, Sprint
Backlog, Sprint Burndown Chart, Release Burndown Chart, Task Board y Potentia-
lly Shippable Product.

El Product Backlog representa el conjunto de todas las caracterı́sticas que definen


el producto.
El Sprint Backlog representa el conjunto de todas las caracterı́sticas y tareas a las
cuales el equipo se compromete a realizar durante la iteración actual.
El Sprint Burndown Chart representa gráficamente el trabajo que resta realizar
para la iteración actual.
El Release Burndown Chart representa gráficamente el progreso del trabajo res-
pecto al plan de entregas.
El Task Board representa el estado de las tareas que el equipo está realizando
durante la iteración actual.
El Potentially Shippable Product representa el producto actual, el obtenido por
todos los incrementos de cada iteración.
CAPÍTULO 2. ESTADO DEL ARTE 25

Extreme Programming
Extreme Programming (XP) es un proceso de desarrollo ágil que puede ser usado
por equipos de tamaño pequeño a mediano para desarrollar software de alta calidad
con un presupuesto y en un tiempo previsible, y con una sobrecarga de trabajo mı́nima
[BA04].
El proceso, mostrado en la Fig.2.5, consiste a grandes rasgos, en relevar los re-
querimientos a través de historias de usuario (User Stories). Luego se realiza el plan
para la siguiente liberación y se itera hasta desarrollar las funcionalidades acordadas.
Finalmente, si las pruebas de aceptación son aprobadas por el cliente, se obtiene una
liberación y se comienza de nuevo.

Figura 2.5: El proceso de XP

En resumen, XP es una colección de valores y buenas prácticas. La mayor parte


de estas han sido usadas en la industria durante años. XP las identifica y las agrupa,
ya qué usándolas en conjunto, es cuando realmente se obtiene el mayor beneficio. Las
doce prácticas de XP son:
Planning Game: determinar rápidamente el alcance de la próxima liberación
combinando las prioridades del negocio y las estimaciones técnicas. A medida
que la realidad cambia hay que actualizar el plan.
Small Releases: poner un sistema simple rápidamente en producción, luego libe-
rar nuevas versiones en ciclos cortos.
Metaphor: guiar el desarrollo con una simple historia de cómo funciona el sis-
tema.
Simple Design: el sistema debe ser diseñado tan simple como sea posible en
cada momento. La complejidad innecesaria es removida tan pronto como es des-
cubierta.
Testing First: continuamente escribir pruebas unitarias, que deben ejecutarse e-
xitosamente para continuar con el desarrollo. Los clientes escriben pruebas para
demostrar que las caracterı́sticas están terminadas.
Refactoring: reestructurar el sistema sin modificar su funcionamiento para re-
mover duplicación, mejorar la comunicación o agregar flexibilidad.
26 2.6. METODOLOGÍAS PARA DESARROLLO DE VIDEOJUEGOS

Pair Programming: todo el código es escrito con dos programadores en una


máquina.

Collective Ownership: cualquiera puede cambiar cualquier parte del código en


cualquier momento.

Continuous Integration: integrar y construir el sistema muchas veces por dı́a,


cada vez que una tarea es completada.

40 Hour Week: como regla, no trabajar más de cuarenta horas por semana.

On-site Customer: incluir un usuario en el equipo, este debe estar disponible todo
el tiempo para responder preguntas.

Coding Standards: escribir el código de acuerdo a los estándares definidos para


enfatizar la comunicación a través del código.

2.6.4. Adaptaciones de Metodologı́as Ágiles para Videojuegos


Existen varias empresas desarrolladoras de videojuegos que utilizan metodologı́as
ágiles, algunas de estas son: High Moon Studios [Hig08], Large Animal Games [Lar08],
Titus Interactive Studios [Gam08b] y Crytek [Cry08a]. Sin embargo, ninguna de sus
adaptaciones se encuentran especificadas formalmente o públicamente como una me-
todologı́a para desarrollo de videojuegos. A continuación se describen las adaptaciones
de estas empresas y los beneficios que reportan basados en su experiencia.

High Moon Studios


High Moon Studios utiliza Scrum y XP en todos sus desarrollos desde hace va-
rios años [Llo08b]. Generalmente realizan iteraciones de dos semanas con equipos de
alrededor de ocho personas donde el productor actúa como Scrum Master. Respetan
todos las actividades de Scrum y ponen mucho énfasis en las prácticas de XP para
el desarrollo de código. Entre las prácticas se destacan Pair Programming, Testing,
Continuous Integration y Refactor que aplican sin excepciones.
High Moon Studios es una de las empresas pioneras en utilizar Scrum para ges-
tionar el desarrollo de videojuegos, han publicado varias de sus experiencias en distin-
tos artı́culos y conferencias a modo de promover el uso de esta metodologı́a. Atribuyen
a las metodologı́as ágiles gran parte de su productividad y calidad de productos.

Large Animal Games


Large Animal Games adopta Scrum en forma progresiva hasta utilizarla en todos
sus proyectos [Tob08], esta decisión se toma principalmente para evitar depender de
ciertas personas clave.
En su adaptación el Scrum Master, rol realizado por el productor, utiliza el Product
Backlog Board para mantener todas las caracterı́sticas del videojuego ordenadas por
prioridad. La prioridad es asignada por el cliente, quien es ayudado por el diseñador de
CAPÍTULO 2. ESTADO DEL ARTE 27

juego con más experiencia para definir y priorizar las funcionalidades en forma correc-
ta. Con esta organización el equipo de desarrollo puede estimar aproximadamente que
caracterı́sticas se trabajan en cada sprint, y puede proyectar una fecha de finalización.
Su experiencia indica que se obtiene más éxito cuando la planificación se realiza
durante el desarrollo, en lugar de hacerla antes de este. El problema radica en que en
ese momento aún no está completo el Product Backlog por lo que es extremadamente
difı́cil establecer un calendario o predecir en forma efectiva. Es por esto que deciden
acortar las etapas previas para comenzar a desarrollar lo más pronto posible.
Al desarrollo de cada sprint le incorporan un par de reuniones que no estaban pre-
vistas por el proceso original. Además, le dan una particular importancia a la reunión
de demostración del sprint, por permitirles validar con el cliente las caracterı́sticas ya
implementadas.
Las reuniones que se agregan son:

Reunión de preparación del sprint: se realiza el dı́a anterior a la planificación del


sprint. En ella el equipo se interioriza del estado de las caracterı́sticas a imple-
mentar y se estiman mediante la utilización de Planning Poker [Coh08]. Luego
de estimadas, el Product Ownner prioriza estas tareas en el Product Backlog
Board.

Reunión de mitad de sprint: en ella se analiza el avance de las tareas acordadas


junto con el Product Owner. En caso de detectar problemas se pueden realizar
ajustes antes de finalizar el sprint. Los equipos que realizan iteraciones cortas
(una semana) no utilizan esta reunión.

Los beneficios que reportan incluyen que el foco en la calidad que antes dependı́a
de unos pocos individuos se distribuye entre todo el equipo. Además, los equipos nece-
sitan menos guı́a de los diseñadores y desarrolladores de mayor experiencia, lo que
permite que puedan dirigir un mayor número de equipos. También el cliente logra un
alto nivel de visibilidad del avance del proyecto y el impacto que tienen sus requeri-
mientos, permitiendo que el equipo pueda negociar de mejor forma los cambios.
Las dificultades se encuentran en la estimación del tiempo necesario para llevar
a cabo una tarea. También existen conflictos de solapamiento entre Product Backlog
Board y herramientas utilizadas anteriormente para el seguimiento de tareas y errores.
A pesar de esto destacan que las metodologı́as ágiles les permiten mantener los proble-
mas visibles y continuamente brindan oportunidades al equipo para discutir sus solu-
ciones.

Titus Interactive Studio


Titus Interactive Studio plantea una propuesta de adaptación de XP para el desarro-
llo de videojuegos llamada Extreme Game Development (XGD) [Dem08] en donde se
incorporan las prácticas de XP a las diferentes disciplinas del desarrollo de videojuegos.
A pesar de que no hay resultados publicados acerca de esta propuesta, se considera
interesante por su completa especificación.
En su adaptación el rol de cliente es cumplido por el productor, quien junto con el
diseñador de juego describen y priorizan las historias de usuario (User Stories) de las
28 2.6. METODOLOGÍAS PARA DESARROLLO DE VIDEOJUEGOS

cuales surgen las caracterı́sticas del videojuego. Una ventaja de que el cliente sea el
productor es que está en permanente contacto con el equipo para responder consultas
rápidamente.
Definen iteraciones de seis semanas de duración. Cada iteración comienza con el
Planning Game donde el equipo y el productor deciden qué caracterı́sticas serán im-
plementadas durante la misma. La iteración se divide en tres partes de dos semanas
cada una, donde tareas especı́ficas se definen, se planifican y se llevan a cabo. El pro-
greso se mide a través de la cantidad de pruebas unitarias y funcionales aprobadas.
Todas las noches se realiza una integración completa, incluyendo la integración del
contenido audiovisual de forma de minimizar el riesgo que esta implica en el desa-
rrollo de videojuegos. Intentan no definir roles especı́ficos en el equipo y utilizar Pair
Programming para evitar la concentración de conocimientos en pocas personas. Al
finalizar la iteración se libera la versión implementada, se realiza una pequeña cele-
bración y se comienza con la etapa de retroalimentación en la que evalúan lo realizado
y los problemas encontrados para hacer mejoras.
No se permite desarrollar una caracterı́stica sin tener pruebas automatizadas. Los
encargados de escribir las pruebas funcionales al momento de definir las historias de
usuario son el productor junto con el diseñador del juego y el lı́der de verificación. Por
otro lado, los programadores realizan pruebas unitarias y los artistas definen scripts
para automatizar pruebas sobre el contenido (p.ej. la cantidad de polı́gonos de un per-
sonaje no debe superar los 4000 en un nivel de detalle determinado o todos los cuadros
de una animación del personaje principal deben ser de 32x64 pı́xels). De esta manera,
el departamento de pruebas se puede enfocar en hacer todo tipo de pruebas no automa-
tizables.
Para la evaluación del proceso utilizan una lista denominada XGD dashboard que
contiene todas las prácticas y herramientas utilizadas y sirve para medir la eficacia y
eficiencia de las mismas. A estas se les asignan puntaje de cero a cinco, de esta forma el
gerente de proyecto puede medir cómo se siente el equipo respecto al proceso seguido.

Crytek
Crytek adopta Scrum para el desarrollo de Crysis, un videojuego AAA [Cry08b]. El
desarrollo se completa tras doce meses y cuenta con ochenta personas en doce equipos
multidisciplinarios de siete personas cada uno.
El videojuego al que aplican esta metodologı́a estaba en fase de producción uti-
lizando un proceso en cascada. La decisión de comenzar con Scrum se basa en que
estaban desarrollando demasiadas caracterı́sticas, eran incapaces de medir el progreso,
necesitaban reducir el alcance, y la visión se dificultaba debido al enorme cronograma
del proyecto.
La transición a Scrum la realizan gradualmente, comenzando por elegir un equipo
de personas, separarlo del equipo de producción en cascada y lograr que adopten la
metodologı́a. Esto lo repiten iterativamente hasta que todas las personas pertenezcan a
un equipo.
La estrategia utilizada implica:

utilizar equipos multidisciplinarios siempre que sea posible.


CAPÍTULO 2. ESTADO DEL ARTE 29

los equipos siempre deben trabajar en el mismo espacio fı́sico.

siempre resolver tareas de forma secuencial, nunca en simultáneo.

al priorizar, nunca asignar la misma prioridad a dos elementos distintos.

al actualizar el progreso, solo contar como completas las caracterı́sticas que están
funcionales en el ejecutable.

asegurarse de que los lı́deres de desarrollo no cumplan el rol de Scrum Master


en la nueva estructura.

De su experiencia concluyen que Scrum se puede escalar a proyectos grandes.


Además destacan que el Product Backlog les permite manejar las expectativas y guiar
al equipo.

2.6.5. Análisis de las Metodologı́as para Videojuegos


Petrillo et al. [PPTD09] identifican, a partir de una investigación hecha de post-
mortems, los problemas más comunes en la industria de videojuegos. Los mismos se
pueden apreciar en la Fig.2.6 que presenta el porcentaje de ocurrencia en cada proyec-
to de los problemas identificados. Entre estos se pueden destacar la definición de un
alcance irreal o ambicioso, la definición de demasiadas caracterı́sticas y el recorte de
estas cuando están parcialmente implementadas, problemas en la etapa de diseño, de
comunicación y retrasos en la planificación.

Figura 2.6: Ocurrencia de problemas [PPTD09]

De esta investigación Petrillo et al. concluyen que los principales problemas de la


industria de software tradicional también se encuentran en la industria de los video-
juegos. Esto hace pensar que las virtudes y defectos de las metodologı́as aplican de
manera similar en el desarrollo de software tradicional y en el de videojuegos.
30 2.6. METODOLOGÍAS PARA DESARROLLO DE VIDEOJUEGOS

La metodologı́a codificar y corregir tiene pocas ventajas y varias desventajas


[McC96]. Como ventaja, no se invierte tiempo extra en planificar, documentar, ase-
gurar la calidad, utilizar estándares u otras actividades fuera de la codificación y uti-
lizarlo requiere poca experiencia, ya que cualquiera que codifique ya está familiarizado
con el modelo. Entre las desventajas se encuentra que no hay medios para evaluar el
progreso, la calidad o identificar riesgos. Además, es costoso cambiar el código por la
poca preparación para la verificación y modificaciones, pierde la estructura luego de
varias correcciones y frecuentemente no satisface completamente las necesidades del
cliente. Esta metodologı́a parece apropiada solamente para proyectos pequeños que no
requieren de mantenimiento posterior.
Las metodologı́as de tipo cascada son adecuados para proyectos que están bien
comprendidos porque se puede atacar la complejidad de forma ordenada [McC96].
Funcionan bien cuando los requerimientos de calidad predominan sobre los de cos-
tos y cronograma. Además, al eliminar los cambios en el transcurso de las fases se
elimina una gran fuente de errores potenciales. Por otra parte, Craig Larman [Lar03]
enuncia que “la razón subyacente de las dificultades de cascada es que requiere de
problemas con pocos cambios, poca innovación y baja complejidad. No es adecuado
para proyectos complejos o inventivos”. Identifica como desventajas que se debe es-
pecificar completamente el producto y elaborar cronogramas y estimaciones confiables
por adelantado. Además, la verificación e integración se realiza en forma tardı́a. Otra
caracterı́stica negativa es que se encuentra valor en seguir lo planificado al pie de la
letra, lo que hace difı́cil lidiar con cambios frecuentes en los requerimientos. Se de-
duce que dados los principales problemas encontrados en la industria de videojuegos,
la rigidez de este tipo de procesos no es compatible con las caracterı́sticas cambiantes
de los videojuegos y la dificultad para planear y estimar estos proyectos.
Las metodologı́as ágiles son iterativas e incrementales y buscan obtener versiones
del producto en intervalos cortos y regulares de tiempo. Esto facilita una visión tem-
prana del resultado final, lo cual reduce la probabilidad de cambios de requerimientos
en forma tardı́a y brinda una mayor retroalimentación del cliente. Además permiten
tener una mayor visión y control del avance del proyecto, tanto al cliente como a los
desarrolladores. Esto se debe a que se pueden determinar nuevas estrategias, iteración
por iteración, para lograr llegar en tiempo y forma a los plazos requeridos. También
involucran a todo el equipo en las decisiones, lo que logra compromiso y motivación.
Como desventajas se identifica la dificultad en su adopción, ya que muchas veces im-
plica un cambio estructural en la organización, sobre todo en empresas grandes que
tienen un proceso y una estructura establecida. Además es difı́cil involucrar al cliente
en el proceso, ya que debe comprometerse a tener una interacción frecuente y continua.
Las caracterı́sticas que presentan las metodologı́as ágiles parecen mitigar los pro-
blemas más comunes que ocurren al desarrollar videojuegos. Sumando el éxito y los
beneficios que se reportan en numerosos casos de empresas de la industria que las
utilizan, se concluye que las metodologı́as ágiles son adecuadas para el desarrollo de
videojuegos.
Relevamiento de la Industria de
Videojuegos en Uruguay
3
Con la motivación de conocer la industria uruguaya de desarrollo de videojuegos
se realizan entrevistas entre marzo y abril del 2008 a cuatro empresas referentes en
este rubro. El relevamiento hace foco en las metodologı́as de desarrollo que utilizan e
incluye otros aspectos de las empresas como infraestructura, clientes, tipos de proyec-
tos y estrategias de negocio que permiten caracterizar a la industria. El detalle de cada
empresa se encuentra en el anexo B.
En la sección 3.1 se presentan las empresas relevadas y sus principales caracterı́sti-
cas. En la sección 3.2 se resume la situación actual de la industria uruguaya y se ana-
lizan sus fortalezas, debilidades, oportunidades y amenazas. Por último, en la sección
3.3 se muestran alguno de los principales aspectos de las metodologı́as de desarrollo
utilizadas por las empresas.

3.1 Empresas Relevadas


Las empresas relevadas son Batovi Game Studio [Bat08], Mystery Studios [Mys08],
Powerful Robot Games [Pow08] y Kef Sensei [Sen08]. La información presentada
está sujeta a la fecha de realización de las entrevistas.

3.1.1. Batovi Game Studio


La empresa surge como emprendimiento personal a mediados del año 2002 y en
el 2005 se consolida asociándose a IPcom [IPc09]. Trabajan para varios clientes co-
mo MTV [MTV09], Nickelodeon [Nic09] y Cartoon Network [Net09], entre otros. Han
desarrollado videojuegos del tipo Casual para las plataformas PC, Web y Dispositivos
Móviles y utilizan para estas el modelo de ingresos de Probar Antes de Comprar, Ad-
vergaming y Móviles respectivamente. En el caso de los videojuegos para Dispositivos
Móviles ellos mismos han financiado sus proyectos.
Cuenta con ocho integrantes de los cuales cinco son programadores y tres artistas
gráficos. Normalmente, en los proyectos el equipo se compone de dos o tres integrantes,
entre los que hay al menos un diseñador gráfico y un programador. Además, algún
miembro con experiencia participa como productor.

31
32 3.1. EMPRESAS RELEVADAS

En la Fig.3.1 se muestran algunos de los videojuegos desarrollados por la empresa.

Figura 3.1: DHL Driving Simulator - Bubbaloo Mix Skating - Arcade Fishing -
SpongeBob Driving Exam - Skimo: Avalancha - Andy and the Secret of Egypt

3.1.2. Kef Sensei


La empresa comienza en el año 2007 como ramificación de otra empresa de de-
sarrollo de software convencional. Su primer y único videojuego hasta el momento es
desarrollado tras ganar el concurso Developer Dash [Pla08a], una competencia impul-
sada por el publisher PlayFirst [Pla08b]. Este les financia el proyecto y les entrega un
porcentaje de las ganancias por las ventas. El videojuego es del tipo Casual para la
plataforma PC y se comercializa con el modelo de ingreso Probar Antes de Comprar.
Cuentan con seis personas, donde tres son programadores y tres son artistas gráfi-
cos. Uno de los programadores, además, participa como productor. En la Fig.3.2 se
muestra el videojuego desarrollado por la empresa.

Figura 3.2: Parking Dash


CAPÍTULO 3. VIDEOJUEGOS EN URUGUAY 33

3.1.3. Mystery Studios

La empresa se forma en junio del 2003 cuando desarrollan su primer videojuego.


Logran su primer éxito en el 2004 con Betty’s Beer Bar el cual definió un nuevo género
en la industria casual. Hasta ahora desarrollan únicamente videojuegos de tipo Casual
para la plataforma PC y utilizan para las ventas el modelo de ingreso Probar Antes
de Comprar. Han desarrollado varios videojuegos con financiación propia, además de
trabajar con publishers reconocidos como Ubisoft [Ubi09], Uclick [UCl09] y PopCap
[Pop08].
Cuenta con tres integrantes, siendo dos programadores y un artista gráfico. Para
sus desarrollos utilizan un framework propio implementado en C++, el cual además
comercializan.
En la Fig.3.3 se muestran algunos de los videojuegos desarrollados por la empresa.

Figura 3.3: Wild West Wendy - Pirate Poppers - The Lost Cases of Sherlock Holmes -
Brain Spa - Lavender’s Botanicals - Cathy’s Caribbean Club

3.1.4. Powerful Robot Games

La empresa se funda en el año 2002. Su videojuego más reconocido es el Big Fat


Awesome House Party para Cartoon Network [Net09], que llega a tener más de trece
millones de usuarios. Desarrollan diversos tipos de videojuegos, principalmente del
tipo Casual para la plataforma Web y con el el modelo de ingreso Advergaming.
Cuentan con un equipo de alrededor de veinte personas compuesto por cinco pro-
gramadores y siete artistas gráficos, además de productores, diseñadores de juego y
administrativos. En los proyectos suele participar un programador y uno o más artistas
gráficos, además de un productor y un diseñador de juego. Estos últimos participan en
varios proyectos a la vez.
En la Fig.3.4 se muestran algunos de los videojuegos desarrollados por la empresa.
34 3.2. SITUACIÓN ACTUAL

Figura 3.4: September 12th - Scuba Jojo - Debate Night, Obama’s unoficial game - The
Howard Dean Game - Path of the Jedi - Big Fat Awesome House Party

3.2 Situación Actual


La industria de videojuegos en uruguay es joven ya que transcurren solamente sie-
te años desde el surgimiento de la primer empresa. Durante estos años han aparecido
nuevas empresas y más proyectos, pero este crecimiento no parece ser significativo.
Esta industria no cuenta con una gran infraestructura y emplea entre tres y quince per-
sonas por empresa. La mayorı́a de los proyectos que se realizan se acotan a videojuegos
de tipo Casual para las plataformas PC y Web utilizando los modelos de ingreso Probar
Antes de Comprar y Advergaming. Su desarrollo habitualmente demanda entre dos y
doce meses.
No se tiene la oportunidad de desarrollar para ciertas plataformas (p.ej. Consolas)
ya que no se cuenta con los recursos tanto económicos como de personal con la capa-
citación y experiencia necesaria.
Actualmente, la mayorı́a de los proyectos dependen de la inversión de capitales
externos. La estrategia que plantean las empresas, como forma de mejorar los ingresos,
es desarrollar videojuegos por su propia cuenta o con financiamiento externo en etapas
avanzadas del desarrollo.
A continuación se presenta un análisis de fortalezas, oportunidades, debilidades y
amenazas (FODA) para la industria uruguaya de videojuegos. Este análisis se basa en:
el FODA para la industria uruguaya de software que se presenta en el “Plan de Re-
fuerzo de la Competitividad” realizado por la Oficina de Planeamiento y Presupuesto
(OPP) [OPP07], en el artı́culo “Industria de Desarrollo de Videojuegos en Argentina”
de la Asociación de Desarrolladores de Videojuegos Argentina (ADVA) [ADV04] co-
mo ejemplo de una realidad similar, y en el relevamiento realizado para el presente
trabajo.

3.2.1. Fortalezas
Capacidad de los recursos humanos: reconocida capacidad de los recursos hu-
manos uruguayos en las tecnologı́as de la información. Existe un conjunto de
CAPÍTULO 3. VIDEOJUEGOS EN URUGUAY 35

instituciones que brindan carreras a nivel de grado y de posgrado, dictados por


recursos humanos con formación a nivel de maestrı́a y doctorado.

Efecto cluster: dado que el paı́s es chico y los actores se conocen entre sı́, existe
una gran capacidad para hacer alianzas, asociaciones, investigaciones conjuntas,
crear entidades de mejora, trabajar conjuntamente entre universidades, empresas,
gobierno, instituciones intermedias, laboratorios e integrarse con otras cadenas
de valor y otras industrias. En particular, Proanima [Pro09] es un cluster que
integra empresas de producción de animación y desarrollo de videojuegos e in-
dustrias afines, para realizar proyectos y acciones que mejoren la gestión del
sector.

Costos competitivos: disponibilidad de recursos humanos altamente calificados


a costos competitivos internacionalmente.

3.2.2. Debilidades
Escasez de recursos humanos: la escasez de recursos humanos con la capacita-
ción adecuada, hace que los mejores profesionales queden sobrevalorados. Esto
afecta la competitividad ya que el costo de contratarlos es mayor.

Poca experiencia de profesionales en la industria: considerando que la industria


local de videojuegos es joven, la experiencia requerida para desarrollarlos radica
en pocas personas.

Falta de casos de éxito: actualmente, el paı́s no cuenta con una cantidad signi-
ficativa de casos de éxito para atraer potenciales inversores a proyectos de larga
escala.

Mercado interno chico: ventas locales insignificantes, lo que implica depender


exclusivamente del mercado internacional.

Falta de carreras especializadas: aunque existen en las universidades materias


sobre el desarrollo de videojuegos, estas no son suficientes para una formación
completa. Ejemplo de estas materias son las electivas dictadas por el laborato-
rio de simulación y videojuegos (GameLab) de la Universidad ORT, llamadas
Desarrollo de Videojuegos I y II sobre XNA. Por su parte la Universidad de
la República cuenta desde hace años con las electivas introducción a la com-
putación gráfica, computación gráfica avanzada, mientras que en el 2008 se dicta
el seminario de tecnologı́as interactivas y videojuegos.

3.2.3. Oportunidades
Nuevos mercados: la aparición de nuevas tecnologı́as y plataformas generan un
nuevo espacio de oportunidades para las empresas. Además, nuevas áreas están
buscando contenido en forma de videojuegos gracias a la influencia de la tec-
nologı́a en el entretenimiento moderno.
36 3.3. METODOLOGÍAS DE DESARROLLO RELEVADAS

Apoyo de organizaciones: existen instituciones que brindan el apoyo necesario


para canalizar el impulso de las empresas, buscando potenciar sus emprendimien-
tos. Un ejemplo de esto es Ingenio [Ing09], cuya incubadora brinda la infraestruc-
tura para la creación de nuevas empresas y promueve su crecimiento en un medio
protegido, además de ser organizadora de un concurso nacional de videojuegos.

Mercado en crecimiento: el mercado mundial de videojuegos está en constante


crecimiento. Incluso en el 2008, a pesar de la crisis económica, las ventas en el
mercado europeo registraron un crecimiento del 15 % [aDe09].

3.2.4. Amenazas
Creciente competencia: la competencia en los últimos años se ha incrementado
exponencialmente. Cada vez más paı́ses desarrollan su industria de videojuegos,
lo que llama la atención de inversionistas en búsqueda de bajos costos de de-
sarrollo. Este fenómeno está tomando importancia en Europa Oriental (Rusia,
Ucrania, Hungrı́a), el Sudeste de Asia (China, Singapur, Corea del Sur, India) y
América (Argentina, Brasil y México).

Subvenciones en otros paı́ses: algunos paı́ses ofrecen subsidios a los empren-


dimientos vinculados con el desarrollo de videojuegos, lo cual se transforma en
una amenaza competitiva. Esta clase de subsidios son ofrecidos en paı́ses ya con-
solidados internacionalmente (Unión Europea), y en paı́ses competidores (Brasil
y Argentina [dPCyT08]).

3.3 Metodologı́as de Desarrollo Relevadas


Las metodologı́as que siguen las empresas se basan en su experiencia y no están
formalmente definidas. Algunas, utilizan varias de las prácticas de metodologı́as ágiles
conocidas como Scrum y Extreme Programming.
En resumen, el proceso general de desarrollo de las empresas comienza por definir
y acordar la idea del videojuego a realizar. Luego, se especifican sus caracterı́sticas y
se planifican los plazos de entrega. Para la elaboración del videojuego se relevan dos
formas de trabajo, de las cuales la primera es la que se utiliza en la mayorı́a de las em-
presas y la segunda solo en una. La primera es iterativa e incremental con iteraciones de
corta duración, donde en cada una se diseña, implementa y verifica un subconjunto de
las caracterı́sticas del videojuego. Al final de la iteración se muestra el progreso logra-
do para evaluar el videojuego y realizar cambios sobre su especificación. La segunda
es secuencial, donde primero se realiza el diseño completo de la solución para luego
implementar y posteriormente verificar. Una vez terminada la elaboración, se realiza
una verificación funcional externa al equipo de desarrollo para detectar errores y eva-
luar el videojuego. A partir de los errores y evaluaciones que se reportan, se corrige el
videojuego hasta alcanzar la versión final, la cual se distribuye de acuerdo al medio de
distribución definido. El detalle completo del proceso de desarrollo relevado en cada
empresa se encuentra en la sección B.5 dentro del anexo B.
CAPÍTULO 3. VIDEOJUEGOS EN URUGUAY 37

Los equipos de desarrollo se conforman de dos a siete integrantes promedio, que


cubren los roles de productor, programador, artista gráfico y diseñador de juego. Los
contenidos de audio son realizados por empresas externas especializadas, ya que no
es redituable contar con personas dedicadas a esto. El productor es responsable del
seguimiento del proyecto y la comunicación con el cliente, generalmente es una única
persona y participa en varios proyectos a la vez. El diseño del juego es llevado a cabo
en algunos casos por el integrante de mayor experiencia y en otros por todo el equipo.
Todas las metodologı́as de las empresas relevadas se ven influenciadas por la forma
de financiar el proyecto. Cuando la financiación es externa, quien financia impone pla-
zos, prácticas y entregables a generar durante el desarrollo. Esto hace que el proceso sea
más ordenado y apunte a cumplir en tiempo y forma con los plazos impuestos. Quien
financia se encarga además de la verificación funcional externa, ası́ como del marketing
y la distribución del videojuego. Esta modalidad de trabajo tiene como desventajas la
pérdida de autonomı́a en cuanto a decisiones sobre aspectos del videojuego y la dismi-
nución de las ganancias al obtener un menor porcentaje sobre las ventas. Como ven-
tajas, permite generar experiencia, hacer conocida la empresa en el mercado y reducir
riesgos económicos. Todas las empresas adoptan esta modalidad ya que les permite
financiar sus propios proyectos de forma paralela o a futuro.
Cuando la propia empresa financia el proyecto, se cuenta con mayor flexibilidad
a la hora de decidir las caracterı́sticas y los plazos. Esto tiene como ventaja un ma-
yor tiempo para crear elementos divertidos que hagan atractivo al videojuego, pero en
contrapartida suponen el riesgo de invertir demasiado tiempo en busca de la perfec-
ción. La verificación funcional externa es menos formal ya que solamente se distribuye
el videojuego entre conocidos, además existe la posibilidad de negociar con más de
un distribuidor. Esta modalidad permite a la empresa obtener mayores ingresos pero
supone cargar con los riesgos de la inversión.
Como conclusión se extraen las siguientes caracterı́sticas que cumplen todas las
metodologı́as relevadas:
interacción fluida con el cliente.
flexibilidad ante los requerimientos cambiantes.

etapa de verificación externa bien marcada.


las decisiones se basan en la experiencia, sin utilizar técnicas especı́ficas.
se adaptan en cada proyecto para responder a las exigencias de los clientes.
Metodologı́a SUM para Desarrollo de
4
Videojuegos

En este capı́tulo se presenta la metodologı́a SUM para Desarrollo de Videojuegos


(SUM) concebida en el marco del proyecto de grado. SUM busca adaptarse a la realidad
del Uruguay de proyectos de corta duración y equipos multidisciplinarios de pocas
personas. Además, comparte las caracterı́sticas de las metodologı́as que se utilizan en
las empresas uruguayas, por ser iterativa con alto grado de participación del cliente y
flexible para adaptarse a los cambios y a diversos tipos de proyectos.
La versión de SUM que se presenta contiene los ajustes realizados luego de la
evaluación del caso de estudio que se encuentra en el capı́tulo 5. En la sección 4.1 se
presenta la motivación y las ventajas que se obtienen al formalizar una metodologı́a.
Luego, en la sección 4.2 se describe el estándar y la herramienta que se utiliza para
especificar SUM. En la sección 4.3 se definen los objetivos de SUM, mientras que en la
sección 4.4 se especifican sus roles. En la sección 4.5 se presenta el proceso de entrega
junto con sus fases, actividades y tareas. Por último, en la sección 4.6 se resumen las
guı́as de SUM. El detalle completo de la especificación de SUM se encuentra en el
anexo G y publicado en el sitio web de SUM [ACMV09].

4.1 Motivación
A partir del estudio del estado del arte de las metodologı́as para desarrollo de video-
juegos realizado se concluye que las metodologı́as ágiles parecen ser efectivas para
mitigar los problemas más comunes del desarrollo de videojuegos. Del relevamiento
de las metodologı́as de desarrollo utilizadas en Uruguay, se concluye que sus carac-
terı́sticas se asemejan a los principios ágiles por ser iterativas, flexibles a cambios e
interactuar frecuentemente con el cliente. Además, la actual utilización de prácticas de
metodologı́as ágiles en algunas empresas hace pensar que es factible su adopción.
Dado que no existe una metodologı́a basada en principios ágiles formalmente es-
pecificada para el desarrollo de videojuegos, se realiza una propuesta de estas carac-
terı́sticas con el objetivo de aportar al desarrollo de la industria local.
Formalizar una metodologı́a, según el estudio realizado por Henrik Terävä [Ter07],
tiene como ventajas:
CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 39

Asegurar un enfoque consistente y repetible a través de diversos proyectos.

Dar consistencia y permitir el seguimiento al ciclo de vida del proceso.

Facilitar la comunicación para las personas y para otros sistemas.

Facilitar la planificación, el seguimiento y la evaluación del proyecto.

Definir responsabilidades entre los miembros del equipo en forma clara.

Reducir la dependencia en personas especı́ficas.

Trabajar en forma rápida y eficiente.

Permitir el manejo, creación y distribución del conocimiento.

Asistir en el entrenamiento.

4.2 Especificación
SUM adapta para videojuegos la estructura y roles de Scrum descritos por Ken
Schwaber [SB01]. Se utiliza esta metodologı́a ya que brinda flexibilidad para definir el
ciclo de vida y puede ser combinada fácilmente con otras metodologı́as de desarrollo
para adaptarse a distintas realidades. Para la adaptación, se toma en cuenta la experien-
cia de las empresas de desarrollo de videojuegos que adaptan metodologı́as ágiles a
nivel mundial como se vio en el capı́tulo 2.
La definición de SUM se basa en el Software and Systems Process Engineering
Metamodel Specification (SPEM) 2.0 [Gro08], un meta-modelo para describir proce-
sos y metodologı́a desarrollado por el Object Management Group (OMG). Por ser un
estándar tiene como beneficio el definir un lenguaje común para todos los procesos lo
cual facilita su comprensión y comunicación. SPEM divide la metodologı́a en métodos
y proceso. Los métodos describen, independientemente del ciclo de vida del proyecto,
las tareas, roles, artefactos, técnicas, prácticas y guı́as. El proceso organiza los méto-
dos para crear diferentes modelos de proceso. Esta separación tiene como ventaja cen-
tralizar los métodos y ası́ poder definir o adaptar procesos que los usen en forma senci-
lla. Una ventaja de utilizar SPEM es que su estructura permite especificar el proceso de
desarrollo de videojuegos sin mencionar prácticas especı́ficas, lo que lo hace flexible y
adaptable a cada realidad. Además, la posibilidad de determinar guı́as permite brindar
un amplio espectro de buenas prácticas, técnicas, herramientas y posibles soluciones a
problemas comunes en el desarrollo de videojuegos.
Para especificar SUM se utiliza la herramienta Eclipse Process Framework (EPF)
[Fou08] ya que provee un marco de trabajo extensible basado en los conceptos de
SPEM 2.0. Esta herramienta permite definir, manejar y publicar procesos y métodos de
ingenierı́a de software.
Los principales elementos de SPEM utilizados son el proceso de entrega, las fases,
las actividades, las tareas y sus pasos, los roles y las guı́as. A continuación se describe
cada uno de estos elementos.
40 4.3. OBJETIVOS

Proceso de entrega: es un proceso especial que describe un enfoque completo


e integrado para ejecutar un determinado tipo de proyecto. Describe el ciclo de
vida completo de un proyecto de principio a fin descomponiéndolo en distintas
fases. Los elementos del proceso de entrega pueden ser adaptados a cada proyec-
to en particular lo cual aporta flexibilidad al momento de utilizarlo.

Fases: una fase es un perı́odo importante de tiempo durante un proceso de en-


trega. Durante una fase se alcanza un conjunto de objetivos bien definidos y
finaliza al alcanzar un hito importante. Se construye agrupando actividades que
comparten un tramo determinado del tiempo de vida de un proyecto. Al finalizar
cada fase se evalúa el objetivo planteado. Una evaluación satisfactoria permite
avanzar a la próxima fase del proyecto. Las fases en la mayorı́a de los casos se
ejecutan secuencialmente por estar relacionadas las entradas y salidas de cada
una.

Actividades: las actividades se utilizan como estructura para agrupar tareas rela-
cionadas entre sı́ según un objetivo común. Distintas actividades pueden llevarse
a cabo en paralelo, salvo excepciones en las que una actividad requiere de otra
para poder realizarse.

Tareas: una tarea es una unidad de trabajo llevada a cabo por un rol especı́fi-
co. Las tareas suelen generar una o más salidas determinadas. Muchas tareas
requieren de la finalización de otra para poder realizarse, por lo que sus salidas
determinan la dependencia entre ellas.

Pasos: los pasos son parte del trabajo requerido para realizar una tarea. El con-
junto de pasos de una tarea es una guı́a de como se puede realizar la misma. No
necesariamente se deben ejecutar todos los pasos cada vez que se realiza la tarea,
y el orden no tiene porque ser el especificado.

Roles: los roles definen a los responsables de llevar a cabo las tareas del proce-
so. Una persona puede ocupar varios roles, ası́ como también un rol puede ser
realizado por varias personas.

Guı́as: las guı́as proveen explicaciones e información adicional relacionada con


los elementos del proceso. Por ejemplo, una guı́a que explica o asiste en la reali-
zación de una tarea puede ser una checklist o un template, entre otros.

4.3 Objetivos
La metodologı́a SUM para Desarrollo de Videojuegos tiene como objetivos desa-
rrollar videojuegos de calidad en tiempo y costo, y la mejora continua del proceso para
incrementar la eficacia y eficiencia de este. Pretende obtener resultados predecibles,
administrar eficientemente los recursos y riesgos del proyecto, y lograr una alta pro-
ductividad del equipo de desarrollo. SUM fue concebida para que se adapte a diversos
tipos de proyectos con equipos multidisciplinarios pequeños (de dos a siete integrantes
que trabajan en un mismo lugar fı́sico o están distribuidos), de corta duración (menores
CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 41

a un año) y con alto grado de participación del cliente. Es una herramienta para saber
qué hacer y cuándo hacerlo, siendo responsabilidad de quienes lo ejecutan decidir cómo
realizar cada una de las actividades.

4.4 Roles
La metodologı́a define cuatro roles: Equipo de Desarrollo, Productor Interno, Cli-
ente y Verificador Beta. El Productor Interno y el Cliente se corresponden en forma
directa con los roles de Scrum Master y Product Owner de Scrum respectivamente.
El Equipo de Desarrollo tiene las caracterı́sticas del Scrum Team, pero a diferencia
de Scrum se definen subroles dentro del equipo. Estos se corresponden con los que
se utilizan habitualmente en la industria local y es necesario su definición ya que se
requiere una alta especialización para satisfacer las distintas disciplinas que involucra
el desarrollo de videojuegos, aspecto no contemplado en Scrum. Estos subroles son los
de Programador, Artista Gráfico, Artista Sonoro y Diseñador de Juego.
Dentro de las responsabilidades del Programador se encuentran definir la arqui-
tectura, realizar el diseño, implementación y verificación de los componentes de soft-
ware e integrar el contenido audiovisual del videojuego. Los roles de Artista Gráfico
y Artista Sonoro se encargan de la creación del contenido audiovisual del videojuego.
El Artista Gráfico realiza el arte de concepto, el arte 2D, el modelado 3D y la creación
de animaciones y texturas, entre otros. El Artista Sonoro se encarga de la creación,
grabación, mezcla y edición de los efectos de sonido y música del juego. Por último,
el rol de Diseñador de Juego es responsable de diseñar el gameplay, la historia, el am-
biente, los personajes y todos los elementos que hacen a la experiencia del jugador,
además de los niveles, misiones y los desafı́os que enfrenta el jugador.
El rol de Verificador Beta no está presente en Scrum pero sı́ se detecta su existencia
en el relevamiento de la realidad local y en la industria del videojuego en general. Su
responsabilidad es la de realizar la verificación funcional del videojuego y comunicar
el resultado de esta. Un Verificador Beta puede tener conocimientos y experiencia de
verificación de software o videojuegos. Sin embargo, puede no poseer experiencia ni
ser jugador frecuente y participar igualmente de la verificación, por ejemplo, al formar
parte de un focus group del videojuego.

4.5 Proceso de Entrega


El proceso de entrega se divide en fases iterativas e incrementales que se ejecu-
tan en forma secuencial con excepción de la fase de gestión de riesgos que se realiza
durante todo el proyecto. Las cinco fases secuenciales son: Concepto, Planificación,
Elaboración, Beta y Cierre. Estas se aprecian en la Fig.4.1. Las fases de Concepto, Pla-
nificación y Cierre se realizan en una única iteración, mientras que Elaboración y Beta
constan de múltiples iteraciones.
Las fases surgen como adaptación al desarrollo de videojuegos de las fases pre-
game, game y post-game que presenta Scrum, donde las dos primeras coinciden con
las fases de Planificación y Elaboración, mientras que la tercera se corresponde con la
42 4.5. PROCESO DE ENTREGA

Figura 4.1: Fases del proceso

fases de Beta y Cierre. Esta división se realiza ya que la fase Beta tiene caracterı́sticas
especiales en la industria de videojuegos. La fase de Concepto no se corresponde con
ninguna etapa de Scrum. Se agrega ya que cubre necesidades especı́ficas para el desa-
rrollo de videojuegos además de identificarse su uso en la realidad local y en la industria
mundial.
Las actividades y tareas desarrolladas en cada fase surgen de la investigación del
estado del arte y del relevamiento de la industria uruguaya. Las mismas son consi-
deradas como una primera aproximación y están sujetas a mejoras a partir de futuras
aplicaciones de la metodologı́a.
A continuación se describen cada una de las fases del proceso de entrega con sus
actividades y tareas sin llegar al detalle de los pasos en cada una.

4.5.1. Concepto
La fase tiene como objetivo principal definir el concepto del videojuego. Es una
fase corta en el tiempo que finaliza cuando se tiene el concepto validado entre todas las
partes involucradas. La validación no implica necesariamente tener definido todos los
aspectos del concepto en forma completa para pasar de fase.

Desarrollo del Concepto


Desarrollar el concepto del videojuego implica la realización de tres tareas para
definir aspectos de negocio, de elementos de juego y técnicos como se aprecia en la
Fig.4.2. El concepto del videojuego se construye a partir de ideas y propuestas de ca-
da rol involucrado sobre los aspectos a definir. Las propuestas se refinan a través de
reuniones y se analiza su factibilidad con pruebas de concepto. Estas tres tareas se rea-
CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 43

lizan en paralelo y durante toda la fase, ya que se puede comenzar con cualquiera de
ellas y cada una puede influenciar al resto.

Figura 4.2: Actividad - Desarrollo del Concepto

Definir aspectos de negocios


Se decide a qué público está orientado el videojuego y el modelo de negocios
a seguir. El Cliente y el Productor Interno son los responsables de ejecutar esta
tarea.
Definir aspectos de juego
Se determinan los principales aspectos del videojuego como son: visión, género,
gameplay, principales caracterı́sticas, historia y ambientación. Esta tarea involu-
cra también la posible creación de pruebas de concepto para evaluar las ideas y
minimizar el riesgo de que no sea divertido. Estas pueden ser simulaciones del
videojuego en papel, pruebas con videojuegos similares o codificación de pro-
totipos. Es importante que no se invierta más que el tiempo necesario para probar
la idea. Los responsables de esta tarea son el Equipo de Desarrollo, el Cliente y
el Productor Interno.
Definir aspectos técnicos
Se eligen los dispositivos de hardware en los que se podrá ejecutar el videojuego
además de las tecnologı́as y herramientas para realizar la implementación. Se
pueden realizar prototipos técnicos que prueben los aspectos seleccionados para
evaluar la factibilidad de su utilización. El Equipo de Desarrollo, el Cliente y el
Productor Interno son quienes deciden estos aspectos.

4.5.2. Planificación
La fase tiene como objetivos planificar las restantes fases del proyecto y especificar
las caracterı́sticas del videojuego. Para ello se realizan dos actividades cuyos resulta-
dos componen el plan del proyecto. Como se observa en la Fig.4.3, las actividades se
44 4.5. PROCESO DE ENTREGA

ejecutan en paralelo ya que sus salidas dependen entre sı́ (p.ej. el cronograma debe ser
coherente con el tiempo estimado para realizar las caracterı́sticas del videojuego). Se
espera que sea una fase corta que termina cuando se tiene el acuerdo del cliente so-
bre los planes y caracterı́sticas definidas. La planificación que se obtiene en esta fase
es flexible ya que en cada iteración de la fase de elaboración se puede modificar para
adaptarse a los cambios y reflejar la situación actual del proyecto.

Figura 4.3: Actividades de la Fase de Planificación

Planificación Administrativa
Esta actividad implica realizar cuatro tareas, como se aprecia en la Fig.4.4, con el
objetivo de definir diversos elementos del plan de proyecto. Se ejecutan en paralelo ya
que no existe un orden de ejecución definido. Este depende de la situación de partida
al planificar ya que si uno o más de estos elementos están definidos previamente, los
otros deben ajustarse para cumplir los requerimientos.

Definir objetivos del proyecto


Se definen los objetivos que se quieren alcanzar al finalizar el proyecto. Para cada
uno se deben determinar criterios de evaluación que permitan medir su éxito. Es
importante determinar cuáles son los resultados que se esperan obtener, ya que
estos guiarán el esfuerzo del equipo durante el desarrollo del proyecto. El Cliente
y el Productor Interno son los encargados de definir los objetivos.
Definir cronograma
Se determina el cronograma para las restantes fases del proyecto en base al
concepto del videojuego, los riesgos detectados y el resto de los elementos del
plan de proyecto. El cronograma se conforma con las fechas estimadas para el
comienzo de la fase de Elaboración, Beta y Cierre. Además, incluye la cantidad
de iteraciones a realizar durante la fase de elaboración junto con sus duraciones,
CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 45

Figura 4.4: Actividad - Planificación Administrativa

los criterios de finalización para la fase Beta y los hitos intermedios. Para definir
los criterios de finalización una posibilidad puede ser establecer una ventana de
tiempo determinada durante la cual no aparezcan errores crı́ticos o realizar de-
terminada cantidad de iteraciones. Los hitos intermedios de avance se definen
para cumplir con requerimientos del cliente, algo que es común por causa de los
contratos que se realizan en la industria de videojuegos [Bat03]. El Cliente y el
Productor Interno son los responsables de esta tarea.

Definir equipo de desarrollo


Se conforma el equipo de desarollo para el resto de las fases. Para esto, a partir
del concepto del videojuego se identifican las necesidades técnicas y artı́sticas
requeridas para la realización del proyecto. De acuerdo a estas y de la confor-
mación actual del equipo, se seleccionan las personas que van a formar parte del
equipo de desarrollo. Pueden existir cambios en el equipo de la fases anteriores
para poder cumplir con las necesidades detectadas.
En caso de que existan necesidades que las personas que integran el equipo no
pueden cubrir, estas deben ser cubiertas externamente. Los contratistas externos
se determinan dependiendo de la oferta de mano de obra para la necesidad a
cubrir y de las experiencias previas. El Productor Interno es el responsable de
realizar esta tarea. Es clave determinar la disponibilidad de los recursos (internos
o externos) para cubrir los requerimientos, ya que sino el proyecto puede no ser
factible.

Definir presupuesto
46 4.5. PROCESO DE ENTREGA

Se determina el costo total del proyecto y cómo obtener los recursos económi-
cos necesarios para realizarlo, de acuerdo al concepto del videojuego y el resto
de los aspectos del plan de proyecto. Dos de los componentes principales del
presupuesto son los salarios del equipo y los costos externos (p.ej. el costo del
hardware necesario para desarrollar o el pago a contratistas externos). El Produc-
tor Interno es el responsable de definir el presupuesto.

Especificación del Videojuego


Esta actividad consta de tres tareas cuyo propósito es especificar, estimar y priorizar
cada una de las caracterı́sticas funcionales y no funcionales que definen el videojuego.
Las tareas se ejecutan en forma secuencial tal cual muestra la Fig.4.5.

Figura 4.5: Actividad - Especificación del Videojuego

Una caracterı́stica funcional representa, en forma similar a una User Story de Ex-
treme Programming (XP) [Bec04], una funcionalidad del videojuego desde el punto de
vista del usuario final. Al ser definidas desde este punto de vista, las caracterı́sticas son
una excelente herramienta que tiene el cliente para comunicar al equipo los requeri-
mientos del videojuego y medir el avance durante todo el proyecto. Una caracterı́stica
no funcional representa una propiedad o cualidad que el videojuego debe presentar. Es-
tas caracterı́sticas suelen referir principalmente a atributos de calidad y a documentos
exigidos, entre otros.

Especificar caracterı́sticas
CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 47

Se determinan y describen cuáles son las caracterı́sticas funcionales y no fun-


cionales del videojuego tomando como base el concepto. La descripción de ca-
da caracterı́stica es breve pero contiene suficiente detalle para poder estimar el
tiempo necesario para realizarla. También se incluyen los criterios de evaluación
que sirven como herramienta para verificar la caracterı́stica y para eliminar am-
bigüedades en la definición de la misma. La ejecución de esta tarea es responsa-
bilidad del Equipo de Desarrollo y el Cliente.

Estimar caracterı́sticas
Se estima el tiempo que se requiere para realizar las caracterı́sticas del video-
juego definidas en la tarea anterior. Estimar permite dimensionar el esfuerzo y el
tiempo necesarios para completar el videojuego. El Equipo de Desarrollo es el
encargado de realizar la estimación.

Priorizar caracterı́sticas
Se determina la importancia de cada caracterı́stica definida para el videojuego.
Priorizar permite determinar el mejor orden en el cual deben ser desarrolladas
las caracterı́sticas de modo de maximizar el valor del videojuego y minimizar
riesgos. El Cliente y el Equipo de Desarrollo son los encargados de esta tarea,
utilizando las caracterı́sticas definidas y estimadas en las tareas anteriores. El
Cliente prioriza desde el punto de vista del usuario final, mientras que el Equipo
de Desarrollo aporta su visión para priorizar las caracterı́sticas que conllevan un
mayor riesgo técnico.

4.5.3. Elaboración
El objetivo de esta fase es implementar el videojuego. Para ello se trabaja en forma
iterativa e incremental para lograr una versión ejecutable del videojuego al finalizar
cada iteración. La secuencia de actividades que se sigue en cada iteración se muestra
en la Fig.4.6.
48 4.5. PROCESO DE ENTREGA

Figura 4.6: Actividades de la Fase Elaboración

Con esta forma de trabajo se puede evaluar el avance del proyecto, lo cual permite
realizar cambios a tiempo y tomar decisiones para cumplir con los plazos planificados.
Además, la experiencia adquirida permite mejorar la forma de trabajo en cada iteración
y aumentar la productividad. Se espera que esta fase sea la más extensa de todo el
proyecto.

Planificación de la Iteración
En esta actividad se crea el plan de la iteración que consta de sus objetivos, las
caracterı́sticas a implementar y las métricas a utilizar para el seguimiento. Consta de
tres tareas que se realizan en forma secuencial una única vez por iteración del modo
que se aprecia en la Fig.4.7.

Definir objetivos y métricas


Los objetivos describen lo que se pretende lograr al finalizar la iteración y se
utilizan para evaluar el éxito de la misma. Sirven también de guı́a para la toma
de decisiones en el transcurso de la iteración. De acuerdo a los objetivos plan-
teados, las métricas determinan qué aspectos medir, cómo hacerlo y cuáles son
los valores esperados para poder monitorear el avance del proyecto. El Cliente,
CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 49

Figura 4.7: Actividad - Planificación de la Iteración

el Equipo de Desarrollo y el Productor Interno son los responsables de realizar


la tarea.

Seleccionar caracterı́sticas
La selección de las caracterı́sticas se realiza en base a su prioridad y a los ob-
jetivos de la iteración. La suma de los tiempos estimados de las caracterı́sticas
seleccionadas no debe superar la duración de la iteración. El Cliente, el Equipo
de Desarrollo y el Productor Interno son responsables de realizar la selección.

Refinar caracterı́sticas
Cada caracterı́stica elegida se divide en tareas de menor duración lo cual hace
más sencillo estimarlas, asignarlas a un miembro del equipo, identificar desvia-
ciones, verificarlas y evaluar su completitud. Las tareas para desarrollo de video-
juegos se pueden agrupar de acuerdo a las disciplinas que involucran. Por ejem-
plo pueden existir tareas de contenido audiovisual, lógica de juego y desarrollo
de componentes de software, entre otros. Es el Equipo de Desarrollo quien deter-
mina las tareas necesarias para poder cumplir con las caracterı́sticas, por lo cual,
se convierten en responsables de su cumplimiento.

Desarrollo de Caracterı́sticas
Esta actividad consta de una sola tarea en la cual se desarrollan las caracterı́sticas
planificadas para la iteración a través de la ejecución de las tareas que la componen.
50 4.5. PROCESO DE ENTREGA

Desarrollar caracterı́sticas
Para desarrollar una caracterı́stica se deben completar todas las tareas definidas.
Una vez que se completan todas las tareas pendientes de una caracterı́stica, esta
se verifica de acuerdo a los criterios de evaluación establecidos. En caso de que
no cumpla con alguno de los criterios se debe corregir hasta que lo haga.
Los pasos a seguir para llevar a cabo una tarea se ilustran en la Fig.4.8. Los miem-
bros del equipo seleccionan las tareas de acuerdo a sus capacidades y una vez que
el equipo aprueba su elección, son responsables por su correcto cumplimiento.
Al ejecutar una tarea se pueden identificar nuevas tareas necesarias para comple-
tarla, en ese caso se ingresan como nuevas tareas de la iteración.

Figura 4.8: Proceso para desarrollo de tareas

Seguimiento de la Iteración
Su objetivo es el de mantener la visión y el control de la iteración en base a los
objetivos planteados. Consta de una única tarea que se realiza durante toda la iteración
en la cual se hace el seguimiento de la misma y se toman las acciones necesarias en
caso de ocurrir problemas.

Monitorear iteración
Se toman las medidas y se evalúan las métricas para tener visibilidad sobre el
estado de la iteración y medir la rapidez con la que equipo avanza hacia com-
CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 51

pletar los objetivos planificados. En forma permanente se comunica el estado


actual para determinar la existencia de problemas o desvı́os en los objetivos. En
caso de que ocurran se registra la causa, se proponen posibles soluciones y el
impacto en los objetivos de la iteración y del proyecto. El Productor Interno rea-
liza el seguimiento y mantiene informado del avance al cliente y al equipo. Las
soluciones a los problemas son acordadas entre los involucrados.

Cierre de la Iteración
Esta actividad tiene como objetivos evaluar el estado del videojuego y lo ocurrido
en el transcurso de la iteración para actualizar el plan de proyecto a la situación actual.
Para ello se ejecutan tres tareas en forma secuencial como se aprecia en la Fig.4.9.

Figura 4.9: Actividad - Cierre de la Iteración

Evaluar estado del videojuego


Se evalúa la versión del videojuego que se obtiene al finalizar la iteración a partir
de los criterios de evaluación determinados y la opinión del cliente. Con esta
evaluación el cliente puede obtener una medida del estado de cada caracterı́stica
planificada para la iteración. El Equipo de Desarrollo y el Productor Interno son
los encargados de realizar la presentación de las caracterı́sticas construidas en la
versión actual del videojuego.
Evaluar la iteración
Se identifican los problemas y dificultades que ocurrieron durante la iteración
y se determinan soluciones para estos. Estas soluciones se utilizan en próximas
52 4.5. PROCESO DE ENTREGA

iteraciones, pudiendo reflejarse como cambios al proceso o tareas. Los respon-


sables de esta actividad son el Equipo de Desarrollo y el Productor Interno, en
forma opcional puede participar el Cliente.

Actualizar plan del proyecto


Se actualiza el plan de proyecto para reflejar la situación actual. Todos los ele-
mentos están sujetos a cambios para poder administrar de la mejor manera los
problemas encontrados y los cambios de requerimientos. Al actualizar se pueden
agregar, cambiar o eliminar caracterı́sticas del videojuego ası́ como su priori-
zación y tiempo estimado. También está permitido modificar el cronograma y
definir o cambiar hitos, cambiar la composición del equipo o buscar nuevos con-
tratistas externos, y realizar ajustes al presupuesto. Se debe tener en cuenta que
de acuerdo a los cambios se deben reajustar todos los elementos del plan para
que sea consistente. El Cliente, el Equipo de Desarrollo y el Productor Interno
participan de la actualización, determinando los cambios a realizar.

4.5.4. Beta
La fase tiene por objetivos evaluar y ajustar distintos aspectos del videojuego, como
por ejemplo gameplay, diversión, curva de aprendizaje y curva de dificultad, y elimi-
nar la mayor cantidad de errores detectados. Se trabaja en forma iterativa liberando
distintas versiones del videojuego para verificar, como se aprecia en el detalle de la
Fig.4.10. En cada ciclo primero se planifica y distribuye la versión beta para ser ve-
rificada. Mientras esta se verifica, se reciben reportes de los verificadores beta con
los errores o evaluaciones realizadas. Estos reportes son analizados para detectar la
necesidad de realizar ajustes al videojuego.
Se puede optar por liberar una nueva versión del videojuego para verificar una vez
que se realizan los ajustes. El ciclo termina cuando se alcanza el criterio de finalización
establecido en el plan de proyecto.

Planificación de la Iteración
Esta actividad tiene como objetivo planificar diversos aspectos de la iteración y
distribuir efectivamente la versión beta para que sea verificada. Consta de dos tareas
que se ejecutan en forma secuencial como se aprecia en la Fig.4.11.

Planificar iteración
Se definen cuáles son los aspectos funcionales y no funcionales en los que poner
foco durante la verificación, los Verificadores Beta que evaluaran esos aspectos
y los medios por los que estos obtienen el videojuego y reportan los resultados.
También pueden ser ajustados, de acuerdo a la situación actual, los criterios de
finalización definidos en el plan del proyecto. Esta selección se realiza en cada
liberación de una nueva versión beta permitiendo ajustar estos elementos para
dar flexibilidad a la verificación. El Cliente y el Productor Interno son quienes
determinan estos aspectos.
CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 53

Figura 4.10: Actividades de la Fase Beta

Distribuir versión beta


Se proporciona a los Verificadores Beta la versión del videojuego a verificar a
través de los medios definidos. El Productor Interno es el responsable de esta
tarea.

Verificación del Videojuego


Esta actividad consta de una única tarea, en la cual se verifica la versión beta del
videojuego y se reportan los errores.

Verificar videojuego
Se verifica el videojuego poniendo foco en los aspectos funcionales y no fun-
cionales definidos, y se reportan los resultados obtenidos. Los resultados pueden
ser errores o las impresiones acerca de aspectos como elementos del videojuego
desbalanceados o poco atractivos. Los Verificadores Beta son quienes realizan la
verificación y comunican los resultados al equipo de desarrollo a través de los
medios de comunicación definidos.

Corrección del Videojuego


La actividad tiene como objetivo la corrección del videojuego de acuerdo a los
errores y evaluaciones reportadas en la verificación. Para ello se cuenta con dos tareas
que se ejecutan en paralelo, del modo que se aprecia en la Fig.4.12. En una se priorizan
y determinan los cambios a realizar y en otra se realizan los cambios de acuerdo a su
prioridad.
54 4.5. PROCESO DE ENTREGA

Figura 4.11: Actividad - Planificación de la iteración

Priorizar ajustes
Se definen los ajustes a realizar al videojuego en base a los resultados de la eva-
luación y a los errores encontrados. Luego se priorizan dependiendo del impacto
y la importancia que representan para el videojuego. El Equipo de Desarrollo
junto con el Cliente son los responsables de esta tarea.

Realizar ajustes
Se realizan los ajustes determinados hasta el momento en el orden de la prioridad
definida. Una vez seleccionado y realizado el ajuste, se debe verificar que fue
introducido con éxito en el videojuego. El Equipo de Desarrollo es el responsable
de esta tarea.

4.5.5. Cierre
Los objetivos de esta fase son poner a disposición del Cliente la versión final del
videojuego y evaluar el desarrollo del proyecto. Se compone de dos actividades secuen-
ciales como se puede apreciar en la Fig.4.13.

Liberación del Videojuego


Se realiza una única tarea en la que se construye la versión final del videojuego.

Entrega final
Se pone a disposición del Cliente la versión final del videojuego en las formas
establecidas de acuerdo a la especificación del videojuego. El entregable final
CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 55

Figura 4.12: Actividad - Corrección del Videojuego

está compuesto por el videojuego funcionando y otros artefactos acordados pre-


viamente que el cliente exija. Estos pueden ser documentos de diseño de juego,
de diseño de software, manuales de usuario, etc. Es el Equipo de Desarrollo
quien realiza las tareas necesarias para incorporar estos elementos mientras que
el Cliente debe dar el aval al entregable para dar por finalizada la tarea.

Evaluación del Proyecto


La evaluación consiste en una única tarea en la que se identifican aspectos relevan-
tes que ocurrieron durante el desarrollo del proyecto, se registran las lecciones apren-
didas y se realizan mejoras al proceso.

Evaluación postmortem

Se evalúa el proyecto a partir de las medidas tomadas durante el desarrollo, la


gestión de riesgos, la experiencia de cada participante y las evaluaciones realizadas
al finalizar cada iteración de la fase de elaboración. A partir de estos elementos se
identifican los problemas ocurridos, los éxitos conseguidos, las soluciones halladas,
el cumplimiento de objetivos y la certeza de las estimaciones. Con las conclusiones
extraı́das se construyen las lecciones aprendidas y se buscan alternativas para mejorar
el proceso. En la evaluación es recomendable que participen todas las personas que han
estado involucradas en el proyecto.

4.5.6. Gestión de Riesgos


Esta fase se realiza durante todo el proyecto, con el objetivo de minimizar la ocu-
rrencia y el impacto de problemas durante su ejecución. Esto se debe a que distintos
56 4.5. PROCESO DE ENTREGA

Figura 4.13: Actividades de la Fase de Cierre

riesgos pueden ocurrir en cualquiera de las fases, por lo cual, siempre debe existir un
seguimiento de los mismos.

Gestión de Riesgos
Consta de dos tareas que se realizan en forma simultánea en el tiempo del modo
que se aprecia en la Fig.4.14. La primera identifica los riesgos en cada momento del
proyecto y la segunda se encarga del seguimiento y de la aplicación de los planes de
mitigación y contingencia.

Figura 4.14: Actividad - Gestión de Riesgos

Identificar riesgos
CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 57

Se establecen los riesgos junto con su impacto, probabilidad de ocurrencia, me-


canismos de monitoreo, estrategia de mitigación y plan de contingencia. El E-
quipo de Desarrollo y el Productor Interno son los encargados en todo momento
de identificar los riesgos y definir los aspectos requeridos.
Monitorear riesgos
Se monitorean en forma continua los riesgos identificados para evaluar la proba-
bilidad de que ocurran y la eficacia de las acciones que se toman para mitigarlos.
La evaluación de los riesgos puede implicar la ejecución de nuevas acciones
para evitar que ocurran o la aplicación de los planes de contigencia en caso de
que sucedan. El productor interno es el encargado de monitorear y asegurar de
que se apliquen las estrategias de mitigación y contingencia.

4.6 Guı́as
Las guı́as son sugerencias, pautas y herramientas para seguir en forma efectiva y
eficaz las actividades que componen el proceso. A través de ellas, se incorporan a la
metodologı́a prácticas aplicadas con éxito para el desarrollo de videojuegos, además
de las lecciones aprendidas con la ejecución de cada proyecto. Se pueden asociar a
fases, actividades y tareas para dar pautas de cómo realizarlas. La definición de guı́as
brinda flexibilidad en como llevar a cabo el proceso ya que presenta varias alternativas
a utilizar según la situación y las necesidades que se tengan.
Actualmente SUM incluye las prácticas y herramientas de Scrum y XP, y además,
artı́culos publicados sobre la aplicación de metodologı́as ágiles en el desarrollo de
videojuegos. Además, se brindan como ejemplos las salidas obtenidas durante la eje-
cución del proceso en el caso de estudio.
Evaluación de SUM para Desarrollo de
5
Videojuegos

Con el fin de evaluar y realizar ajustes a la metodologı́a SUM para Desarrollo de


Videojuegos, se propone su puesta en práctica en una situación de ejemplo que busca
contemplar las condiciones de la industria local. En este capı́tulo se presenta el análisis
y la evaluación de dicha puesta en práctica. En la sección 5.1 se define en qué consiste
la propuesta. Luego, en la secciones 5.2, 5.3 y 5.4 se presentan la evaluación de SUM
de roles, proceso de entrega y guı́as respectivamente.

5.1 Definición
La propuesta consiste en el desarrollo de un prototipo de videojuego 3D de acción,
multijugador distribuido. El público objetivo son jugadores con cierta experiencia en
videojuegos sin ser especı́ficamente casuales o hardcore.
El lenguaje de programación seleccionado es Java y el entorno de desarrollo Eclipse
[Ecl08]. La motivación de esta elección es la de maximizar la cantidad de plataformas
objetivo y contar con un conjunto herramientas, bibliotecas y frameworks conocidos
por los integrantes. Dentro de estas herramientas se selecciona el motor de juegos 3D
de código abierto JMonkeyEngine [jMo08].
Para el control de versiones de código se utiliza la herramienta Svn [Sub08], para el
control de versiones de bibliotecas y especificación de proyectos la herramienta Maven
[Mav09a] y para el seguimiento de tareas y reporte de defectos la herramienta web Trac
[Tra09].
El proyecto es llevado a cabo por los cuatro integrantes de este proyecto de gra-
do, que cuentan en promedio con tres años de experiencia en tecnologı́as de informa-
ción pero con muy poca experiencia en el desarrollo de videojuegos, artes visuales
o sonidos. Además, dos de los integrantes tienen conocimientos en el área de com-
putación gráfica. Su capacidad de dedicación es en promedio de tres horas por dı́a cada
uno y sus horarios son generalmente desfasados entre sı́. Las vı́as de interacción remota
definidas incluyen la herramienta Google Talk [Goo09] para mensajerı́a instantánea y
Skype [Sky09] para comunicación por voz.
El rol de Cliente es cubierto por los integrantes del grupo, aunque la decisión de
CAPÍTULO 5. EVALUACIÓN DE SUM 59

aceptación final del videojuego la tienen los tutores del proyecto de grado. Además, se
tienen en cuenta para la toma de decisiones la opinión de potenciales usuarios finales.
El rol de Equipo de Desarrollo lo interpretan tres de los integrantes del grupo mientras
que el cuarto interpreta el rol de Productor Interno.
Para el desarrollo de contenidos visuales se cuenta con un equipo externo de pro-
fesionales con experiencia en contenidos 3D y 2D pero sin experiencia en desarrollo
de videojuegos. Al no existir un compromiso formal para exigir plazos de entrega y
dedicación no se los cuenta como parte de la propuesta sino como un recurso para au-
xiliar en el desarrollo. Las principales vı́as de comunicación son el correo electrónico
y mensajerı́a instantánea.
El objetivo de la propuesta es construir un prototipo de videojuego que sirva para
evaluar la mayor cantidad de aspectos de SUM. Debido a que la motivación no es la de
generar ingresos, se dejan de lado los aspectos de negocio y presupuesto.
El detalle del videojuego se puede encontrar en los anexos C, D, E y F.

5.2 Evaluación de Roles


Respecto al Equipo de Desarrollo, se observa que al participar en todas las deci-
siones del proyecto se aprovecha la experiencia y puntos de vista de cada uno, logrando
que se sientan motivados y comprometidos con el videojuego. Dentro de las decisiones
que toma exclusivamente el equipo, todos los integrantes tienen el mismo peso por lo
que asumen y comparten todas las responsabilidades. Los participantes de la propuesta
lo consideran una mejor opción, a partir de su experiencia personal, frente a la situación
en la que un miembro de mayor jerarquı́a imponga lo que considera mejor.
Se observa que se obtienen mejores resultados cuando el equipo interactúa en el
mismo lugar fı́sico, debido a que les permite expresar fácilmente sus ideas y reduce
los problemas de comunicación que ocurren en caso contrario. Además, la interacción
directa permite atacar rápidamente las diferencias de opiniones para evitar tomar de-
cisiones incorrectas. Dado que en el caso de la propuesta el equipo solo se compone
de programadores, no se obtienen observaciones en cuanto a la interacción entre disci-
plinas.
En cuanto al Productor Interno, se nota positivo que centraliza la comunicación
entre los integrantes del equipo y los mantiene enfocados en los objetivos de cada
iteración. Además, les permite concentrarse en las tareas de desarrollo mientras él se
encarga de realizar el seguimiento para detectar y resolver impedimentos.
Como en el caso de la propuesta los propios integrantes interpretan el rol de Cliente,
no se obtienen observaciones en cuanto a la participación de un cliente externo al
equipo. Se observan algunas diferencias entre lo que el grupo presentó como versión
final y lo que los tutores pretendı́an obtener. Esto comprueba que es importante la par-
ticipación de quien tiene la decisión final en los cierres de las iteraciones para poder
marcar a tiempo lo que pretende.
De acuerdo a lo observado en la interacción entre roles, se considera importante
definir una nomenclatura en común tanto en el Equipo de Desarrollo (p.ej. estándares
de código) como con el Cliente y proveedores (p.ej. definición de formatos de archivo
60 5.3. EVALUACIÓN DEL PROCESO DE ENTREGA

y especificación de requerimientos). No definirlos lleva a desacuerdos y problemas que


atrasan el proyecto.

5.3 Evaluación del Proceso de Entrega


A continuación se presenta, fase a fase, un conjunto de observaciones sobre sus
actividades y tareas junto con la evaluación realizada.

5.3.1. Concepto
Al realizar la actividad de Desarrollo del Concepto se definen los aspectos de
juego y técnicos. Se observa que cuando el propio equipo interpreta el rol de Cliente,
se tiende a minimizar el grado de especificidad de estos aspectos debido a que no
existen exigencias externas (p.ej. tiempos de entrega y documentos).
Se corrobora que la definición temprana de prototipos a realizar, tanto técnicos
como conceptuales, ayuda a evaluar la factibilidad del proyecto y mitigar riesgos.
Además, los prototipos permiten conocer las posibles dificultades que pueden surgir
con determinada tecnologı́a o caracterı́stica, por lo que la estimación e identificación
de riesgos se vuelve más precisa.
Se observa correcto el no obligar a definir completamente todos los aspectos del
concepto para pasar de fase ya que tener una idea de estos alcanza para comenzar la
planificación.

5.3.2. Planificación
El equipo, el tiempo de dedicación por integrante y la fecha lı́mite son parte de la
definición inicial de la propuesta (caso tı́pico en la industria local). Por lo tanto, de las
actividades de esta fase se realiza en forma completa la Especificación del Videojuego,
mientras que de la actividad de Planificación Administrativa solo se define la cantidad
de iteraciones y lo que se espera desarrollar en cada una.
Al estimar las caracterı́sticas en equipo, se observa que los integrantes se compro-
meten a los tiempos que ellos mismos determinan. A partir de la experiencia personal
de los integrantes en otros desarrollos, se observa que este hecho contrasta con la in-
conformidad que se genera cuando un gerente de proyecto se encarga de estimar todos
los tiempos y luego el equipo debe ajustarse a estos.
Se comprueba que priorizar caracterı́sticas, permite al Equipo de Desarrollo y al
Cliente determinar el mejor orden para desarrollarlas de forma de maximizar el valor
del producto y minimizar riesgos. Además, se observa que la especificación, estimación
e importancia de cada caracterı́stica son dependientes entre sı́, por lo que cuanto mejor
se realiza la especificación, más fácil es estimar y priorizar cada caracterı́stica.
Como las mismas personas cumplen tanto el rol de Cliente como de Equipo de
Desarrollo, lo cual trae como problema la pérdida de una visión externa. Sin embargo,
realizar esta tarea entre todos los integrantes del equipo resulta positivo, ya que los
distintos puntos de vista permiten obtener una priorización que se ajusta mejor a la que
espera el usuario final.
CAPÍTULO 5. EVALUACIÓN DE SUM 61

5.3.3. Elaboración
Se realizan todas las actividades definidas para esta fase detectando distintos ajustes
para mejorar SUM.
Durante la Planificación de la Iteración se nota positivo definir un objetivo ya que
ayuda al equipo a mantener el foco en un aspecto del videojuego durante su desarro-
llo. También, se observa positiva la flexibilidad que brinda el proceso para definir las
medidas a tomar en cada iteración de modo de adaptarse al equipo y a los objetivos.
Seleccionar caracterı́sticas que según su estimación no pueden ser desarrolladas
de forma completa durante la iteración, aumenta la dificultad para medir el avance.
Esto hace que sea mejor descomponer las caracterı́sticas para poder completarlas. El
refinamiento de las caracterı́sticas en tareas se nota beneficioso ya que permite di-
mensionar realmente el tamaño de una caracterı́stica en base al trabajo a realizar. La
precisión del refinamiento se observa que mejora iteración tras iteración gracias a la ex-
periencia generada. Además, identificar las tareas por disciplina ayuda a determinar las
capacidades necesarias para desarrollar la caracterı́stica y sirve para orientar al equipo
al decidir quienes serán los responsables de llevarla a cabo.
Un beneficio que se nota en el seguimiento de las tareas, es que se puede saber
cuánto resta para completar una caracterı́stica por la cantidad y dificultad de las tareas
a resolver. Sin embargo, se observa que al momento de planificar es difı́cil identificar
todas las tareas necesarias para completar una caracterı́stica ya que es común que surjan
nuevas tareas durante el transcurso de la iteración.
Se ajusta SUM quitando como paso obligatorio del proceso la estimación y la
definición de criterios de evaluación por tarea. Las razones se deben a que en la práctica
el costo de realizar este trabajo es alto debido a la corta duración de estas. Además, el
valor de las estimaciones se reduce con el surgimiento de tareas durante la iteración.
Durante el Desarrollo de Caracterı́sticas el Equipo de Desarrollo realiza cada una
de las tareas definidas hasta completarlas. Se comprueba que SUM provee libertad al
no especificar cómo realizar cada tarea pero requiere que este sea responsable y auto
organizado. Además, la interacción frecuente y la buena comunicación son fundamen-
tales para disminuir el riesgo de tomar malas decisiones.
Si bien se nota como positivo obtener la visión de otro miembro del equipo, no
siempre se pueden evaluar de forma cruzada las tareas. Esto se debe a lo granulares y
cortas que son y al conocimiento especı́fico de ciertos aspectos del desarrollo que se
requieren para verificarlas. Por estas razones se ajusta SUM quitando la verificación
cruzada de tareas como paso y se incorpora como una buena práctica debido a los
puntos positivos que demuestra cuando sı́ se puede realizar. Este hecho también influye
en el ajuste de quitar los criterios de evaluación por tarea mencionado previamente.
El Seguimiento de la Iteración permite mantener la visión y el control de la mis-
ma basándose en los objetivos planteados. Se observa que en caso de desviaciones,
el Productor Interno puede tomar acciones correctivas como recordar el objetivo de la
iteración o remover algún impedimento que no se identificó previamente. Se observa
dificultad al realizar esta actividad en forma remota ya que se necesitan herramientas
más complejas para mantener el estado del proyecto que cuando se trabaja en el mismo
lugar fı́sico. Además, se requiere de un mayor compromiso y disciplina por parte de
los integrantes del equipo para utilizar efectivamente estas herramientas.
62 5.3. EVALUACIÓN DEL PROCESO DE ENTREGA

Al evaluar el estado del videojuego en el Cierre de la Iteración se observa que


se puede evaluar la última versión desarrollada utilizando los criterios de evaluación
definidos y la opinión de los interesados. De esta forma se determina qué falta para
completar cada una de las caracterı́sticas y permite determinar el grado de avance del
videojuego. Se observa que no implementar de forma completa una caracterı́stica pre-
vista para la iteración afecta negativamente a la motivación del equipo y a la evaluación
del videojuego ya que no se obtienen resultados visibles.
Al evaluar la iteración se identifican problemas y se proponen mejoras. Al partici-
par todo el equipo se logra adaptar la forma de trabajo de la mejor manera para que
los integrantes se sientan cómodos al realizar las actividades. Se nota muy positiva esta
actividad ya que permite tener una instancia donde se puedan enfrentar todos los pro-
blemas cara a cara y buscar las soluciones entre todos. Las medidas tomadas durante la
iteración se muestran efectivas para determinar la certeza de las estimaciones y utilizar
esta información para realizar las próximas.
En base a estas evaluaciones se procede a actualizar el plan de proyecto, lo que
provee una oportunidad para ajustarlo respecto a la situación actual. Durante esta ins-
tancia se aprovecha la experiencia generada durante toda la iteración, tanto al desarro-
llar como al evaluar el videojuego. Además, se observa positivo que se pueden agregar
nuevas caracterı́sticas o quitar caracterı́sticas obsoletas, actualizando el plan de proyec-
to y el cronograma debidamente.
Se observa que la experiencia previa de los integrantes al realizar las actividades
es realmente importante. Trabajar en forma iterativa permite aprovechar rápidamente
la experiencia generada en iteraciones pasadas. En particular, se nota la ganancia al
especificar, estimar, priorizar y refinar en tareas las caracterı́sticas.

5.3.4. Beta
En esta fase el foco cambia de implementar caracterı́sticas a corregir defectos y
realizar ajustes sobre los aspectos del videojuego (p.ej. la diversión que provee). En
la práctica, los criterios de finalización de beta permiten determinar de forma clara
cuándo se debe terminar esta fase y además ayudan a mantener el foco. Otro punto que
se observa es que cambia la distribución de tiempos dedicados a las actividades, en
particular se reduce la cantidad de reuniones.
Se observa que seleccionar verificadores beta que representen al público objetivo
y definir aspectos sobre los cuales concentrar la verificación, permiten obtener una
mejor evaluación del videojuego. Además, se nota positivo priorizar continuamente los
ajustes a realizar ya que maximiza el valor agregado al videojuego.

5.3.5. Cierre
La Liberación del Videojuego se realiza utilizando los medios de distribución de-
finidos. No se encuentra ninguna observación a destacar en esta actividad.
Durante la Evaluación del Proyecto el equipo detecta puntos negativos, positivos
y lecciones aprendidas. Se observa la falta de elementos que permitan determinar una
medida del éxito del videojuego, por lo que se ajusta SUM incorporando la definición
de criterios de éxito al plan del proyecto durante la fase de planificación. De esta forma,
CAPÍTULO 5. EVALUACIÓN DE SUM 63

al momento de evaluar el proyecto se puede saber si los objetivos fueron alcanzados y


en qué medida. Este ajuste no se prueba durante el desarrollo, por lo que no se puede
concluir nada al respecto.

5.3.6. Gestión de Riesgos


En el caso de la propuesta, los riesgos que se detectan al comienzo del proyecto
se mantienen durante toda su ejecución y no surgen nuevos riesgos de relevancia. Al
realizar su seguimiento durante todas las fases del proyecto se observa la flexibilidad
para establecer diferentes planes de mitigación y contingencia de acuerdo a la fase y el
estado actual del proyecto. Se nota que es necesario involucrar a todos los participantes
del proyecto para identificar y mitigar efectivamente los riesgos.

5.4 Evaluación de Guı́as


En general, todas las guı́as sirven como punto de partida para realizar las activi-
dades cuando no se tiene ninguna experiencia. Las guı́as mencionadas en esta sección
junto con otras guı́as propuestas se describen en detalle en el anexo G. De las guı́as
propuestas, se encuentran de utilidad Brainstorming y Bocetos para definir el concep-
to, mientras que Planning Game y Planning Poker ayudan a planificar las iteraciones
y estimar las caracterı́sticas, respectivamente. Esto se debe a que todas aprovechan
la interacción y creatividad de los participantes y permiten unificar la visión de ca-
da uno para alcanzar resultados más precisos. Sprint Burndown Chart se muestra útil
para identificar rápidamente desviaciones en el avance de la iteración pero es difı́cil de
mantener cuando se trabaja en forma remota.
Dentro de las herramientas utilizadas, se observa muy positivo el uso de un sis-
tema de control de versionado de código, el cual permite a los desarrolladores realizar
seguimiento, mantener distintas versiones y compartir diferencias de código en forma
rápida y fácil. Para el manejo de tareas y reporte de errores, las herramientas web de
seguimiento se muestran de gran utilidad ya que permiten organizar de forma centrali-
zada el trabajo y brindan buena visibilidad del estado del videojuego.
Si bien todas las herramientas utilizadas ayudan durante la propuesta, la mayor
parte son de propósito general. A partir de esto, se observa claramente que se nece-
sitan más guı́as relacionadas especı́ficamente con el desarrollo de videojuegos (p.ej.
formatos de audio conocidos que se usan en videojuegos, lenguajes y herramientas de
scripting, técnicas de inteligencia artificial).
Conclusiones y Trabajo Futuro
6
Se alcanza el objetivo propuesto para el proyecto de grado al lograr especificar
formalmente y probar en un caso de estudio la metodologı́a SUM para Desarrollo de
Videojuegos, una metodologı́a ágil que se adapta a las caracterı́sticas relevadas en la
industria del Uruguay.
La falta de formación especı́fica en videojuegos junto con la falta de recursos
económicos son dos de los principales problemas que atentan contra el crecimiento
de la industria. Actualmente, la formación es mayoritariamente informal y se basa en
la experiencia personal de los miembros de la industria. Como consecuencia, existen
dificultades para transmitir estos conocimientos tanto entre pares como a nuevos de-
sarrolladores. Se considera que la formalización de SUM es un aporte al desarrollo de
la industria nacional ya que se puede utilizar como herramienta para la enseñanza a
nuevos desarrolladores además de servir a las empresas para la mejora de sus procesos
actuales.
Para la construcción de SUM se utilizan los principios de las metodologı́as ágiles
ya que del análisis del estado del arte en la industria de los videojuegos se concluye que
estos son adecuados. A esta conclusión se arriba en base a las experiencias documen-
tadas de varias empresas que utilizan metodologı́as ágiles para desarrollar videojuegos.
A pesar del éxito que reportan, no se encuentra ningún estudio formal que demuestre
su efectividad. Este hecho se puede minimizar a partir de la conclusión expresada por
Petrillo et al. [PPTD09] de que los problemas presentes en el desarrollo de software
tradicional y videojuegos son similares. Con esta conclusión se puede inferir que be-
neficios formalmente demostrados de metodologı́as ágiles aplicados al desarrollo de
software tradicional podrı́an resultar efectivas para desarrollar videojuegos. Además,
las metodologı́as de desarrollo utilizadas en la industria local, por ser iterativas, tener
interacción frecuente con el cliente y ser flexibles a cambios, tienen varios puntos en
común con los principios ágiles.
SUM se encuentra especificada formalmente siguiendo el estándar SPEM de mode-
lado de procesos de desarrollo de software e implementada con la herramienta EPF, lo
que permite comunicar el proceso en forma efectiva y extenderlo de forma simple. Este
hecho también se considera un aporte ya que en el estudio del estado del arte realizado
no se encontró ninguna metodologı́a ágil para videojuegos especificada de esta forma.
Con el fin de evaluar SUM se realiza un caso de estudio que consiste en imple-
mentar un prototipo de videojuego cuya definición se basa en las caracterı́sticas de la
CAPÍTULO 6. CONCLUSIONES Y TRABAJO FUTURO 65

industria uruguaya. Se alcanza el resultado esperado al lograr construir el prototipo que


contiene las caracterı́sticas básicas planteadas al inicio del desarrollo. Se concluye que
la experiencia es exitosa ya que se pone en práctica SUM y se genera mucha informa-
ción tanto para su evaluación como para su ajuste.
De la evaluación realizada a las observaciones tomadas durante el caso de estu-
dio, se concluye que SUM cumplió con sus objetivos y ayudó a mitigar varios de los
problemas ocurridos. Estos fueron similares a los problemas tı́picos de la industria pre-
sentados en la sección 2.6.5. La forma de trabajo iterativa que plantea SUM se deter-
mina útil, ya que en cada iteración se aprovecha la experiencia generada anteriormente,
permitiendo tomar mejores decisiones. También se destaca que obtener versiones del
videojuego en cada iteración da una visión del avance del proyecto y permite realizar
cambios a las funcionalidades a tiempo. Se detectan varios problemas con los cuales se
ajusta la metodologı́a para ser más efectiva, quedando como aspecto a mejorar la incor-
poración de una mayor cantidad de guı́as especı́ficas para desarrollo de videojuegos.
Las conclusiones de SUM que se obtienen son preliminares ya que el escenario
definido no prueba todos los aspectos de la metodologı́a y tampoco existe una evalua-
ción formal y empı́rica de la misma. Los aspectos que no pudieron ser evaluados son: la
interacción entre varias disciplinas, que el cliente no pertenezca al equipo de desarrollo
y aspectos de negocio y presupuesto. Además, el análisis puede ser subjetivo en algunos
puntos ya que la metodologı́a es evaluada por las mismas personas que la construyen.
Como trabajo futuro se considera:

Incorporar un mayor número de guı́as especı́ficas de desarrollo de videojuegos


para hacer más completa la metodologı́a.
Evaluar en nuevos casos de prueba en distintos contextos para medir efectiva-
mente su valor. Evaluar estas experiencias para ajustar la metodologı́a e integrar
las lecciones aprendidas como guı́as.
Presentar SUM a empresas de desarrollo de videojuegos en Uruguay para eva-
luarla en una experiencia práctica real.
Relevar empresas desarrolladoras de videojuegos de la región para detectar ca-
racterı́sticas comunes con la industria uruguaya y poder ajustar la metodologı́a a
estas para que tenga un mayor alcance.

Desarrollar un proceso para la gestión de negocios en videojuegos e incorporarlo


a SUM para que contemple todo el ciclo de vida de un videojuego y no solo el
desarrollo.
Implementar una herramienta para gestionar proyectos con SUM.
Bibliografı́a

[3DS09] Autodesk 3ds Max. Online, Fecha de Acceso: Abril 2009.


http://www.autodesk.es/adsk/servlet/index?siteID=
455755&id=12341473.
[ACMV09] Nicolás Acerenza, Ariel Coppes, Gustavo Mesa, y Alejandro Viera. Sum
para Desarrollo de Videojuegos. Online, Fecha de Acceso: Mayo 2009.
http://www.gemserk.com/sum.
[aDe09] aDeSe. Videojuegos - Resultados 2008. Reporte técnico, Asociación
Española de Distribuidores y Editores de Software de Entretenimiento,
Marzo 2009.
[ADV04] ADVA. Industria de Desarrollo de Videojuegos en Argentina. Reporte
técnico, Asociación de Desarrolladores de Videojuegos Argentina, Di-
ciembre 2004.
[ASR02] Pekka Abrahamsson, Outi Salo, y Jussi Ronkainen. Agile Software De-
velopment Methods. VTT Publications, 2002. ISBN 951-38-6009-4.
[AUD09] Audacity. Online, Fecha de Acceso: Agosto 2009.
http://audacity.sourceforge.net/?lang=es.
[BA04] Kent Beck y Cynthia Andres. Extreme Programming Explained: Embrace
Change (2nd Edition). Addison-Wesley Professional, 2004. ISBN 032-
12-7865-8.
[Bat03] Bob Bates. Game Developer´s Market Guide. Premier Press, 2003. ISBN
1-59200-104-1.
[Bat04] Bob Bates. Game Design (2nd edition). Thomson Course Technology
PTR, 2004. ISBN 1-59200-493-8.
[Bat08] Batovi Games Studio. Online, Fecha de Acceso: Marzo 2008.
http://www.batovi.com.
[Bec04] Kent Beck. User Stories Applied. Addison-Wesley Professional, 2004.
ISBN 0-32120-568-5.
[Ben08a] Owain Bennallack. Casual Biz Models No. 1, Retail distribution. Online,
Fecha de Acceso: Mayo 2008. http://www.casualgaming.biz/news/
27459/casual-biz-models-no1-retail-distribution.
[Ben08b] Owain Bennallack. Casual Biz Models No. 4, Try Before You Buy. On-
line, Fecha de Acceso: Mayo 2008. http://www.casualgaming.biz/
news/27467/Casual-Biz-Models-No-4-Try-Before-You-Buy.
[Ben08c] Owain Bennallack. Casual Biz Models No. 5, Cash prize tournaments &
skill-based gaming. Online, Fecha de Acceso: Mayo 2008. http://www.
casualgaming.biz/news/27483/Casual-Biz-Models-No-5-Cash-
prize-tournaments-skill-based-gaming.
BIBLIOGRAFÍA 67

[Ben08d] Owain Bennallack. Casual Biz Models No. 6, Subscription. Online,


Fecha de Acceso: Mayo 2008. http://www.casualgaming.biz/news/
27489/Casual-Biz-Models-No-6-Subscription.

[Ben08e] Owain Bennallack. Casual Biz Models No. 7, Mobile. Online, Fecha de
Acceso: Mayo 2008. http://www.casualgaming.biz/news/27490/
Casual-Biz-Models-No-7-Mobile.

[Ben08f] Owain Bennallack. Casual Biz Models No. 8, Microtransactions. Online,


Fecha de Acceso: Mayo 2008. http://www.casualgaming.biz/news/
27496/Casual-Biz-Models-No-8-Microtransactions.

[c+ 08] Eclipse contributors et al. Open Unified Process (OpenUP). Online, Fecha
de Acceso: Setiembre 2008.
http://epf.eclipse.org/wikis/openup.

[Cas08] CasualGaming.Biz. Casual Games. Online, Fecha de Acceso: Mayo


2008. http://www.casualgaming.biz/.

[Coc06] Alistair Cockburn. Agile Software Development: The Cooperative Game.


Addison Wesley Professional, 2006. ISBN 0-321-48275-1.

[Coh08] Mike Cohn. Planning Poker in detail. Online, Fecha de Acceso: Agosto
2008. http://www.planningpoker.com/detail.html.

[Cor08a] Microsoft Corporation. Quick start guide. Online, Fecha de Acceso: Abril
2008. http://creators.xna.com/en-US/quickstart_main.

[Cor08b] Microsoft Corporation. Xbox 360. Online, Fecha de Acceso: Mayo 2008.
http://www.xbox.com/en-US/hardware/default.htm.

[Cor08c] Microsoft Corporation. Xbox live community games. Online, Fecha


de Acceso: Abril 2008. http://www.xbox.com/en-US/community/
events/gdc2008/xna/default.htm.

[Cry08a] Crytek. Crysis. Online, Fecha de Acceso: Mayo 2008.


http://www.crytek.com/games/crysis/overview/.

[Cry08b] Crytek. Transition to Scrum midway through a AAA Development Cycle:


Lessons Learned. In Game Developer Conference, Marzo 2008.

[Dem08] Thomas Demachy. Extreme Game Development. Online, Fecha de


Acceso: Mayo 2008. http://www.gamasutra.com/resource_guide/
20030714/demachy_01.shtml.

[dJRS+ 06] Javier Garcı́a de Jalón, José Ignacio Rodrı́guez, José Marı́a Sarriegui, Al-
fonso Brazález, y Manuel González. Aprenda C++ como si estuviera
en primero. In Aprenda... como si estuviera en primero. Universidad de
Navarra, 2006.
68 BIBLIOGRAFÍA

[dPCyT08] Agencia Nacional de Promoción Cientı́fica y Tecnológica. Bases del lla-


mado para la adjudicación de aportes no reembolsables para pymes del
sector de la industria del software. Reporte técnico, Ministerio de Cien-
cia, Tecnologı́a e Innovación Productiva - Fondo Fiduciario de Promoción
de la Industria del Software, 2008.
[Duf08] Jill Duffy. Ask the Experts: Console vs PC Development. Online,
Fecha de Acceso: Octubre 2008. http://www.gamecareerguide.com/
features/513/ask_the_experts_console_vs_pc_.php.
[Ecl08] Eclipse.org. Online, Fecha de Acceso: Diciembre 2008.
http://www.eclipse.org/.
[ESA08] ESA. Essential facts about the computer and video game industry. Re-
porte técnico, Entertainment Software Association, 2008.
[Fla09] Adobe Flash Player. Online, Fecha de Acceso: Mayo 2009.
http://www.adobe.com/es/products/flashplayer/.
[Fou08] Eclipse Foundation. Eclipse Process Framework Project homepage. On-
line, Fecha de Acceso: Noviembre 2008.
http://www.eclipse.org/epf/.
[Fou09] Symbian Foundation. About the Symbian Foundation. Online, Fecha de
Acceso: Marzo 2009. http://www.symbian.org/about.php.
[Gam08a] Gamasutra. Features - postmortem. Online, Fecha de Acceso: Abril
2008. http://www.gamasutra.com/php-bin/article\_display.
php\?category=5.
[Gam08b] Moby Games. Titus interactive. Online, Fecha de Acceso: Junio 2008.
http://www.mobygames.com/company/titus-interactive-sa.
[Gar08] GarageGames. Torque Game Builder. Online, Fecha de Acceso: Mayo
2008. http://www.garagegames.com/products/torque/tgb/.
[GHJ95] Erich Gamma, Richard Helm, y Ralph E. Johnson. Design Patterns. Ele-
ments of Reusable Object-Oriented Software. Addison-Wesley Longman,
Amsterdam, 1st ed., reprint. edition, 1995.
[GIM09] Gimp. Online, Fecha de Acceso: Agosto 2009.
http://www.gimp.org/.
[Goo09] Google Talk. Online, Fecha de Acceso: Mayo 2009.
http://www.google.com/talk/.
[Gro08] Object Managment Group. Software and Systems Process Engineering
Metamodel Specification, version 2.0, Abril 2008.
[Hig08] High Moon Studios. Online, Fecha de Acceso: Julio 2008.
http://www.highmoonstudios.com/.
BIBLIOGRAFÍA 69

[IGD08] IGDA. Playfirst Services. Online, Fecha de Acceso: Abril 2008.


http://www.igda.org/breakingin/career_paths.htm.
[Ing09] Ingenio. Ingenio - Incubadora de Empresas de Base Tecnológica. Online,
Fecha de Acceso: Abril 2009.
http://latu21.latu.org.uy/ingenio/.
[IPc09] IPcom. Online, Fecha de Acceso: Marzo 2009.
http://www.ipcomsa.com.uy.
[ISF07] ISFE. Key Facts - The profile of the european videogamer. Reporte
técnico, Interactive Software Federation of Europe, 2007.
[JAV09] Java Web Start. Online, Fecha de Acceso: Marzo 2009.
http://java.sun.com/javase/technologies/desktop/
javawebstart/index.jsp.
[jMo08] jmonkeyengine.com. Online, Fecha de Acceso: Agosto 2008.
http://www.jmonkeyengine.com/.
[Kei09] Clinton Keith. Advanced Scrum and Agile Development. In Game De-
veloper Conference, Marzo 2009.
[Lar03] Craig Larman. Agile and Iterative Development: A Manager’s Guide.
Addison Wesley, 2003. ISBN 0-13111-155-8.
[Lar08] Large Animal Games. Online, Fecha de Acceso: Abril 2008.
http://www.largeanimal.com/.
[Lew08] Mike Lewis. Agile Development - Inside the GDC 2008. Online, Fecha
de Acceso: Abril 2008.
http://www.gamedev.net/columns/events/gdc2008/article.
asp\?id=1351.
[Llo08a] Noel Llopis. By the Books: Solid Software Engineering for Games. On-
line, Fecha de Acceso: Abril 2008.
http://www.convexhull.com/sweng/GDC2003.html.
[Llo08b] Noel Llopis. A day in the life. Online, Fecha de Acceso: Mayo 2008.
http://www.gamesfromwithin.com/articles/0602/000104.html.
[Llo08c] Noel Llopis. GDC 2004: Software Engineering Roundtable Summary.
Online, Fecha de Acceso: Abril 2008.
http://www.gamesfromwithin.com/articles/0403/000016.html.
[LS08] Noel Llopis y Brian Sharp. By the Books: Solid Software Engineering
for Games. Online, Fecha de Acceso: Abril 2008.
http://www.convexhull.com/sweng/GDC2002.html.
[LWJ08] Lightweight Java Game Library. Online, Fecha de Acceso: Agosto 2008.
http://www.lwjgl.org/.
70 BIBLIOGRAFÍA

[Man08] Agile Manifesto. Manifesto for Agile Software Development. Online,


Fecha de Acceso: Mayo 2008. http://agilemanifesto.org/.

[Mav09a] Maven. Online, Fecha de Acceso: Enero 2009.


http://maven.apache.org/.

[MAV09b] Maven Release Plugin. Online, Fecha de Acceso: Agosto 2009.


http://maven.apache.org/plugins/maven-release-plugin/.

[McC96] Steve McConnell. Rapid Development. Microsoft Press, 1996. ISBN


1-55615-900-5.

[Mic08] Sun Microsystems. Java. Online, Fecha de Acceso: Diciembre 2008.


http://www.java.com/es/download/whatis_java.jsp.

[Mic09] Sun Microsystems. Mobile java. Online, Fecha de Acceso: Abril 2009.
http://www.java.com/es/download/faq/whatis_j2me.xml.

[MSD09] MSDN. Active X control. Online, Fecha de Acceso: Abril 2009.


http://msdn.microsoft.com/en-us/library/aa268985.aspx.

[MTV09] MTV. Music television. Online, Fecha de Acceso: Mayo 2009.


http://www.mtv.es/.

[Méx09a] Sony México. Playstation 3. Online, Fecha de Acceso: Abril 2009.


http://www.sony.com.mx/ps3/.

[Méx09b] Sony México. Psp - playstation portable. Online, Fecha de Acceso: Abril
2009. http://www.sony.com.mx/psp/.

[Mys08] Computer Games and Games Download. Online, Fecha de Acceso: Mar-
zo 2008. http://www.mysterystudio.com/index.php.

[Net09] Cartoon Network. Online, Fecha de Acceso: Abril 2009.


http://www.mtv.es/.

[Nic09] Nickelodeon. Online, Fecha de Acceso: Abril 2009.


http://www.mundonick.com/.

[Nin08a] Nintendo. What is Nintendo DS? Online, Fecha de Acceso: Mayo 2008.
http://www.nintendo.com/ds/what.

[Nin08b] Nintendo. What is Wii? Online, Fecha de Acceso: Mayo 2008.


http://www.nintendo.com/wii/what.

[Okt05] Hanna Oktaba. Modelo de Procesos para la Industria de Software. Fac-


ultad de Ciencias, Universidad Autónoma de México, 2005.

[Onl08] ABS CBN News Online. Mobile phone users top 3.3 billion by end-2007:
report. Online, Fecha de Acceso: Junio 2008.
http://www.abs-cbnnews.com/storypage.aspx?StoryID=119336.
BIBLIOGRAFÍA 71

[OPE09a] OpenAL. Online, Fecha de Acceso: Agosto 2009.


http://connect.creativelabs.com/openal/default.aspx.

[OPE09b] OpenGL. Online, Fecha de Acceso: Agosto 2009.


http://www.opengl.org/.

[OPP07] OPP. Plan de Refuerzo de la Competitividad. Reporte técnico, Oficina de


Planeamiento y Presupuesto, 2007.

[PF02] Stephen Palmer y John Felsing. A Practical Guide to Feature-Driven


Development. Prentice-Hall, 2002. ISBN 0-13067-615-2.

[PHO09] Adobe Photoshop CS4. Online, Fecha de Acceso: Agosto 2009.


http://www.adobe.com/es/products/photoshop/photoshop/.

[Pla08a] PlayFirst. Earn Cash with Playfirst’s Second Annual Developer Dash!
Online, Fecha de Acceso: Abril 2008.
https://developer.playfirst.com/developerdash.

[Pla08b] PlayFirst. It’s my time to play. Online, Fecha de Acceso: Mayo 2008.
http://www.playfirst.com/.

[Pla08c] PlayFirst. Playground SDK. Online, Fecha de Acceso: Mayo 2008.


https://developer.playfirst.com/.

[Pop03] Mary Poppendieck. Lean Software Development: An Agile Toolkit for


Software Development Managers. Addison-Wesley Professional, 2003.
ISBN 0-32115-078-3.

[Pop08] PopCap. Online, Fecha de Acceso: Mayo 2008.


http://www.popcap.com/.

[Pow08] Powerful Robot Games. Online, Fecha de Acceso: Marzo 2008.


http://www.powerfulrobot.com.

[PPTD09] Fábio Petrillo, Marcelo Pimenta, Francisco Trindade, y Carlos Dietrich.


What went wrong? A Survey of Problems in Game Development. Com-
puters in Entertainment, 7(1), 2009.

[Pro09] Pronanima. Proanima - Uruguay. Online, Fecha de Acceso: Abril 2009.


http://www.proanima.org.uy/.

[QUA09] QUALCOMM. About Brew. Online, Fecha de Acceso: Agosto 2009.


http://brew.qualcomm.com/brew/en/about/about_brew.html.

[Rey99] Craig Reynolds. Steering Behaviors for Autonomous Characters. In


Game Developer Conference, 1999.

[SB01] Ken Schwaber y Mike Beedle. Agile Software Development with Scrum.
Prentice Hall PTR, 2001. ISBN 0-13067-634-9.
72 BIBLIOGRAFÍA

[SCE09] Scene Monitor. Online, Fecha de Acceso: Marzo 2009.


http://code.google.com/p/scenemonitor/.

[SDL08] SDL. Simple Directmedia Layer. Online, Fecha de Acceso: Mayo 2008.
http://www.libsdl.org/index.php.

[Sen08] Kef Sensei. Kef Sensei :: We Master Fun :: Home. Online, Fecha de
Acceso: Marzo 2008. http://www.kefsensei.com/.

[SHA08] Shadow Mapping and Shadow Volumes. Online, Fecha de Acceso: Agos-
to 2008.
http://www.devmaster.net/articles/shadow_techniques/.

[Sho09] Adobe Shockwave Player. Online, Fecha de Acceso: Mayo 2009.


http://www.adobe.com/products/shockwaveplayer/.

[Sky09] Skype. Online, Fecha de Acceso: Abril 2009. http://www.skype.com.

[SPR09] SpringSource.org. Online, Fecha de Acceso: Agosto 2009.


http://www.springsource.org/.

[Sub08] Subversion. Online, Fecha de Acceso: Diciembre 2008.


http://subversion.tigris.org/.

[Ter07] Henrik Terävä. Software Process Modeling with Eclipse Process Frame-
work and SPEM 2.0. Tesis de Maestrı́a, Universidad de Turquı́a, Octubre
2007.

[Tob08] Bliksem Tobey. Introducing Scrum at Large Animal Games: A look back
at the First year of agile development. Online, Fecha de Acceso: Mayo
2008.
http://www.gamasutra.com/view/feature/3677/introducing.

[Tra09] The Trac Project. Online, Fecha de Acceso: Enero 2009.


http://trac.edgewall.org/.

[Ubi09] Ubisoft. Online, Fecha de Acceso: Mayo 2009. http://www.ubi.com/.

[UCl09] Uclick. Online, Fecha de Acceso: Mayo 2009.


http://www.uclick.com/.

[WMR+ 05] D. Wisniewski, D. Morton, B. Robbins, J. Welch, S. DeBenedictis,


E. Dunin, J. Estanislao, D. James, G. Mills, G. Walton, y J. Valadares.
2005 Mobile Games White Paper. Reporte técnico, International Game
Developer Association, 2005.

[Wol07] Mark J. P. Wolf. The Video Game Explosion: A History from PONG to
PlayStation and Beyond, chapter 1. Greenwood Press, 2007. ISBN 0-
31333-868-X.
BIBLIOGRAFÍA 73

[WR06] Margaret Wallace y Brian Robbins. 2006 Casual Games White Paper.
Reporte técnico, International Game Developer Association, 2006.

[XST09] XStream. Online, Fecha de Acceso: Mayo 2009.


http://xstream.codehaus.org/.
Glosario

AAA
Denominación que se les da a los videojuegos en cuyo desarrollo se invierte un
gran presupuesto.

Advergaming
Es la práctica de utilizar un videojuego para publicitar un producto, organización
o punto de vista.

API
Aplication Programming Interface Es una interfaz que define la manera en que
los programas utilizan los servicios de las bibliotecas o sistemas operativos.

Biblia de arte
Documento que describe la estética del videojuego y todos los objetos visuales
a ser creados. Incluye los bocetos de personajes, escenarios, descripción de los
modelos 2D y 3D, animaciones, etc.

Biblia de diseño
Documento que define el videojuego describiéndolo en forma clara y detallada.
Detalla la mecánica de juego, gameplay, vistas, niveles, personajes, las distintas
pantallas, interfaz de usuario, historia, etc.

Bilboard
Elemento del mundo 3d que siempre apunta a la cámara.

Blog
Es un tipo de sitio web con entradas regulares de comentarios, descripciones de
eventos u otro tipo de material como imágenes y videos.

Ciclo de juego
Es un ciclo donde se procesa la entrada del usuario y se actualiza el estado del
videojuego.

Cluster
Concentración de empresas, instituciones y demás agentes, relacionados entre
sı́ por un mercado o producto, en una zona geográfica relativamente definida,
de modo de conformar en sı́ misma un polo de conocimiento especializado con
ventajas competitivas.

Curva de aprendizaje
Describe el grado de dominio sobre la forma de jugar el videojuego obtenido
durante el transcurso del tiempo.
Glosario 75

Curva de dificultad
Describe el grado de dificultad frente a los desafı́os planteados al jugador durante
el transcurso del tiempo.

Focus group
Forma de estudio cualitativo en el que se reúne a un grupo de personas para
indagar acerca de actitudes y reacciones frente a un producto, servicio, concep-
to, publicidad o idea. En el caso de los videojuegos habitualmente se indaga
acerca de la diversión que se obtiene al jugar, y se mide la curva de dificultad y
aprendizaje.
Framework
Estructura de soporte definida en la cual otro proyecto de software puede ser
organizado y desarrollado. Tı́picamente, puede incluir soporte de programas, bi-
bliotecas y un lenguaje interpretado entre otras piezas de software para ayudar a
desarrollar y unir los diferentes componentes de un proyecto.

Gameplay
Representa la experiencia que vive un jugador durante la interacción con un sis-
tema de juego.

HUD
Es una pantalla transparente que presenta información al usuario de tal forma que
éste no debe cambiar su punto de vista para ver dicha información. El origen del
nombre proviene del hecho de que el usuario puede ver la información necesaria
con la cabeza erguida (head up) y mirando al frente, en vez de bajar la cabeza
para revisar los instrumentos. Aunque su desarrollo inicial fue para las aeronaves
militares, actualmente se utilizan estos sistemas en la aviación civil, automóviles
y videojuegos, entre otros.

Mesh
Es una colección de vértices, aristas y caras que definen la forma de un poliedro
en computación gráfica 3D. Las caras usualmente consisten de triángulos, cua-
driláteros o simplemente polı́gonos convexos.
Model View Controller
Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que
separa los datos de una aplicación, la interfaz de usuario, y la lógica de control
en tres componentes distintos.
Motor de juego
Solución de software para la creación y desarrollo de videojuegos. Proveen de un
conjunto de herramientas integradas para la reutilización de ciertos componentes
de software presentes en cualquier videojuego.
76 Glosario

Niveles
Elemento en el que se subdivide un videojuego, el cual tiene asociado su propio
objetivo y desafı́os a cumplir.

PDA
Término utilizado para cualquier dispositivo pequeño, móvil, que crea, almacena
o envı́a información personal y financiera. Tiene uso personal y comercial.
Powerup
Son elementos que un personaje puede adquirir y que aumentan sus habilidades.

Publisher
Empresa que se dedica a financiar empresas de desarrollo y vender sus videojue-
gos.

Scripts
Un script o archivo de órdenes o archivo de procesamiento por lotes es un pro-
grama usualmente simple, que generalmente se almacena en un archivo de texto
plano y es interpretado en tiempo de ejecución.
Shaders
Conjunto de instrucciones gráficas destinadas para el acelerador gráfico, estas
instrucciones dan el aspecto final de un objeto.

Volumen acotante
En el contexto de computación gráfica, es un volumen simplificado que encierra
un modelo y es utilizado para optimizar cálculos(p.ej. un prisma regular o una
esfera).
Anexos

77
Gestión del Proyecto
A
En este documento se detalla la ejecución del proyecto de grado, mostrando las
diferentes etapas que compusieron al mismo y sus actividades principales.
El proyecto transcurre desde marzo de 2008 a setiembre de 2009 y las fases que
se ejecutan se basan en las planteadas en 1.2. Las actividades realizadas no fueron pla-
nificadas de antemano sino que surgen a partir de reuniones de coordinación entre el
grupo y los tutores. En la sección A.1 se comentan las principales actividades de cada
fase, mientras que en la sección A.2 se presenta el cronograma de cómo transcurrió el
proyecto.

A.1 Fases y Actividades


Durante la fase de Relevamiento de la Industria de Videojuegos en Uruguay se
prepararon y realizaron entrevistas a cuatro empresas de videojuegos de la industria
local. Además, se realizó un análisis que permitió identificar las caracterı́sticas propias
de la industria local, las virtudes y carencias que presentan las empresas en cuanto
a su metodologı́a de desarrollo y los problemas y desafı́os que enfrentan al realizar
videojuegos.
En la fase de Relevamiento del Estado del Arte se investigaron los conceptos ge-
nerales sobre videojuegos, su industria y las metodologı́as de desarrollo que se aplican.
Por lo detectado se profundizó en el estudio de metodologı́as ágiles para videojue-
gos. También se estudió el Modelo de Procesos para la Industria del Software (Mo-
ProSoft) [Okt05] como una posible alternativa para la gestión de negocios dentro de la
metodologı́a.
En la fase de Definición del Alcance se determinó la metodologı́a a realizar, me-
diante el estudio de distintas alternativas sobre el nivel de granularidad al cual llegar,
sus objetivos y su público objetivo.
Durante la fase de Construcción de la Metodologı́a se seleccionaron las herra-
mientas y estándares para especificar la metodologı́a. Con ellos se realizó la definición
del ciclo de vida, roles, actividades, tareas, pasos y guı́as de la metodologı́a propuesta.
En la fase de Caso de estudio se definió y realizó un prototipo de videojuego.
También se analizaron los resultados de evaluar la metodologı́a para posteriormente
realizar ajustes. La ejecución del caso de estudio en el cronograma del proyecto se
ANEXO A. GESTIÓN DEL PROYECTO 79

presenta en dos etapas ya que se detuvo su ejecución en espera de su evaluación por


parte de los tutores y luego se retomó para realizar ajustes al videojuego entregado.
La fase de Análisis y Ajustes consistió en la determinación y realización de los
ajustes a la metodologı́a, detectados a partir del análisis de la ejecución del caso de
estudio.
En la fase de Documentación se documentaron las entrevistas realizadas, el análi-
sis de la industria local, el estado del arte sobre conceptos de videojuegos (modelos de
negocio, cadena de valor, tipos de juego, carreras, etc.) y el análisis de metodologı́as
utilizadas en el desarrollo de videojuegos (procesos, roles, fases, etc.) junto con el
análisis del caso de estudio. En esta fase se incluyen la construcción y revisión de
las publicaciones realizadas durante el transcurso del proyecto. También se incluye el
tiempo dedicado a la confección del informe final.

A.2 Cronograma
El cronograma que se muestra en la Fig.A.1 representa el tiempo transcurrido en
semanas entre el comienzo y fin de cada fase presentada anteriormente. Además, se
presentan las principales actividades realizadas en cada una de las fases.
80 A.2. CRONOGRAMA

Figura A.1: Cronograma de Fases del Proyecto


Relevamiento de Empresas de
B
Videojuegos en Uruguay

Este anexo presenta la información relevada en las entrevistas realizadas a empresas


desarrolladoras de videojuegos en Uruguay.
Las personas entrevistadas personalmente fueron: Fernando Sansberro (director
de Batovi Game Studio), Ernesto Rodrı́guez (diseñador de juegos en Powerful Robot
Games), Eli Barnett (director de Kef Sensei) y Gabriel Gambetta (director de Mystery
Studios). Todas las entrevistas se llevaron a cabo entre marzo y abril de 2008.
La información se estructura en base a las preguntas realizadas. En la sección B.1
se presenta la historia de cada empresa. En la sección B.2 se muestra la infraestruc-
tura, tecnologı́a y herramientas con las que trabaja cada empresa. En la sección B.3
se resumen distintos aspectos de negocios de las empresas como ser sus estrategias de
financiamiento, clientes, proyectos y planes futuros. En la sección B.4 se presenta la
conformación de los equipos de trabajo, y por último, en la sección B.5 se especifican
las diferentes metodologı́as de desarrollo utilizadas en cada una de las empresas.

B.1 Historia
Esta sección presenta lo relevado en cuanto a los comienzos y el desarrollo hasta el
dı́a de hoy de cada una de las empresas.

B.1.1. Batovi Game Studios


Comienza como un emprendimiento personal de Fernando Sansberro a mediados
del año 2002. Su objetivo primario era vivir exclusivamente del desarrollo de video-
juegos. Desarrollan videojuegos para Dispositivos Móviles en los dos primeros años.
Con uno de ellos obtienen el segundo premio en un concurso de Nokia en Argentina.
En el 2004 continúan desarrollando videojuegos para Dispositivos Móviles y además
realizan trabajos de programación para empresas como Powerful Robot Games, NGD
Studios e In-Style Software. Finalmente, en el 2005 unen fuerzas con la empresa IP-
com, quien invierte para materializar realmente el proyecto.

81
82 B.2. INFRAESTRUCTURA, TECNOLOGÍAS Y HERRAMIENTAS

B.1.2. Kef Sensei


Surge en el año 2007 a partir de otra empresa que se dedica al desarrollo de software
convencional en la modalidad de outsourcing. Esta empresa realizaba algunos video-
juegos en Flash del tipo Casual con el modelo de negocios Advergaming a pedido de
clientes por lo que vislumbran la posibilidad de negocio en el área.
Al comenzar estudian la industria de videojuegos en distintos aspectos (tipos de
juegos, modelos de negocio, infraestructura necesaria, etc.) y determinan que van de-
sarrollar videojuegos del tipo Casual con el modelo de ingreso Probar Antes de Com-
prar. Concluyen esto dado los recursos con los que cuentan, los riesgos que pueden
enfrentar, y fundamentalmente su interés por este tipo de videojuego.
Su única implementación consiste en un prototipo con el cual participan a una com-
petencia impulsada por PlayFirst denominada Developer Dash. Resultan ganadores y
obtienen un contrato para terminar el desarrollo del prototipo presentado. Actualmente
están trabajando en ese proyecto.

B.1.3. Powerful Robot Games


Gonzalo Frasca y Sofı́a Battegazzore la fundan en en 2002 por dado que se vis-
lumbra la oportunidad de negocio por los contactos y participación de Frasca en la in-
dustria de videojuegos. Esto les permite conseguir proyectos desde el comienzo. Basan
sus desarrollos principalmente en videojuegos de tipo Casual con el modelo de ingreso
Advergaming. La empresa es reconocida por su éxito en el mercado llamado Foster’s
home for Imaginary Friends que desarrollaron para Cartoon Network.

B.1.4. Mystery Studios


Gabriel Gambetta junto con su hermana Florencia y un compañero de facultad, Es-
teban Guelvenzu, hacen su primer videojuego en junio del 2003. Este fue un fracaso
en términos económicos, pero les permite insertarse en el mercado de los videojuegos
del tipo Casual. Dado que la mayorı́a de los jugadores de videojuegos del tipo Casual
son mujeres, tienen la idea de hacer un videojuego donde la protagonista fuera una
mujer. Este videojuego es el Betty’s Beer Bar y en un principio fue rechazado porque
era totalmente distinto a todo lo que habı́a en ese momento. Igualmente, algunos por-
tales si lo aceptaron y tuvo éxito, incluso más de lo que esperaban. En los años 2005
y 2006 este videojuego marcó una tendencia, ya que en esos años los videojuegos ca-
suales más vendidos eran de ese estilo. Tras el éxito del Betty Beer’s Bar realizan otros
videojuegos entre los cuales está el Wild West Wendy, que fue muy superior al anterior
tanto en el aspecto gráfico como en los algoritmos de inteligencia artificial. A partir
de allı́ tuvieron muchos proyectos tanto propios como para clientes y se consolidaron
como empresa de videojuegos.

B.2 Infraestructura, Tecnologı́as y Herramientas


Esta sección presenta lo relevado en lo relativo a los recursos fı́sicos y técnicos de
las empresas.
ANEXO B. RELEVAMIENTO 83

B.2.1. Batovi Game Studios


Trabajan en una oficina con ocho PC (una para cada miembro del equipo) con
sistema operativo Linux y un servidor para el desarrollo. Utilizan Flash y Director para
desarrollo videojuegos para la plataforma Web. En los videojuegos para Dispositivos
Móviles usan Java (J2ME), Eclipse ME y los SDK y emuladores que brindan los fa-
bricantes (Nokia, Motorola, Siemens, Sony Ericsson, etc.). Para los videojuegos de PC
emplean Torque Game Builder. Cuando trabajan para un cliente que necesita verificar
lo que están haciendo, tienen un servidor para versionado de código (SVN) y para
seguimiento de errores. En otros casos no lo utilizan aunque reconocen que serı́a una
buena práctica.

B.2.2. Kef Sensei


Cuentan con una oficina con varias PC de mediano porte, equipos Mac para poder
verificar los videojuegos desarrollados y una consola de Xbox para realizar prototipos
de prueba. Utilizan C++ para la programación de la lógica y Lua para la lógica de
interfaz gráfica. Como framework para desarrollo usan PlayGround, ya que les per-
mite abstraer varias funcionalidades básicas como ejecutar scripts, cargar archivos de
sonido o imágenes, dibujar en pantalla una imagen, etc. Cuentan además con otras he-
rramientas como un editor de partı́culas y un editor de animaciones. También emplean
herramientas de diseño gráfico como Photoshop.

B.2.3. Powerful Robot Games


Cuentan con una oficina donde existe una PC para cada desarrollador, además de
distintas consolas de videojuegos tales como Nintendo DS, PSP, Gameboy. Desarrollan
en Flash y Director, mientras que utilizan Processing como herramientas de prototi-
pado. Utilizan herramientas para el seguimiento de errores y Photoshop para el diseño
gráfico. Cuentan con emuladores como el Mame para probar videojuegos existentes y
extraer ideas de los mismos.

B.2.4. Mystery Studios


Su lugar fı́sico de trabajo es una habitación en la casa de Gabriel Gambetta. Allı́ tie-
nen tres PC (una para cada integrante), un servidor para versiones y respaldos, dos
computadoras portátiles, un iBook y una Mini Mac. Utilizan el lenguaje C++ y cuentan
con un framework de desarrollo implementado por ellos que les permite escribir códi-
go portable a Windows, Linux y Mac. Este framework funciona con SDL, Direct3d y
OpenGL.

B.3 Aspectos de Negocio


Esta sección presenta lo relevado respecto a los tipos de proyectos, clientes, la
forma de comercialización de sus videojuegos y la estrategia a futuro de la empresa.
84 B.3. ASPECTOS DE NEGOCIO

B.3.1. Batovi Game Studios


Su estrategia de negocio se basa en realizar desarrollos de videojuegos que estén
financiados totalmente por sus clientes para no correr con riesgos económicos. Además,
por ser un departamento de IPcom tienen asegurado el financiamiento para los costos
de la empresa en caso de necesitarlo.
Desarrollan videojuegos Casuales para las plataformas PC, Web y Dispositivos
Móviles y utilizan para estas el modelo de ingresos de Advergaming, Probar Antes
de Comprar y Móviles respectivamente. En el caso de los videojuegos para Disposi-
tivos Móviles ellos mismos han financiado sus proyectos. La duración de los proyectos
va de un par de meses, en el caso de los más simples de Web y Dispositivos Móviles, a
ocho meses en el caso de PC.
Han trabajado para un gran número de clientes en muchos proyectos. Dado la larga
trayectoria ya tienen clientes que los contactan por iniciativa propia. Otros los con-
siguen dado que tienen gente dedicada al marketing buscando oportunidades.
A futuro están evaluando la posibilidad de hacer un videojuego financiado por ellos
que sea portable a varias plataformas.

B.3.2. Kef Sensei


Su estrategia es presentar prototipos a los clientes para conseguir financiación. De
esta forma logran solventar los costos del desarrollo y conseguir mejores beneficios a la
hora de negociar dado que parte del desarrollo ya esta hecho. Se enfocan en videojuegos
del tipo Casual para la plataforma Web y con el modelo de ingreso Probar Antes de
Comprar. Los tiempos de los proyectos son cortos, entre dos y seis meses de duración.
Su objetivo a futuro es crecer en cantidad de proyectos. Para esto, buscan al menos
un contrato para realizar un proyecto más este año y duplicar esa cifra para el año 2009.

B.3.3. Powerful Robot Games


Todos los proyectos que realizan les son encargados por clientes, por lo que toda la
etapa de desarrollo esta financiada por estos. La experiencia y la posición en el mercado
hace que siempre tengan proyectos de este estilo para realizar lo cual cubre sus costos
de operación. La mayorı́a de sus proyectos son videojuegos Casuales para la plataforma
Web con el modelo de ingreso Advergaming, cuyo desarrollo lleva entre cuatro y cinco
meses.
Los contactos con los clientes fueron logrados gracias a la experiencia acumulada
por Gonzalo Frasca en emprendimientos anteriores a la formación de la empresa, entre
ellos su principal cliente Cartoon Network.
A futuro piensan mejorar la organización del equipo estableciendo grupos fijos
encargados del desarrollo de cada videojuego. Estos grupos estarı́an formados por uno
o varios diseñadores gráficos y programadores. También tienen planeado comenzar a
desarrollar videojuegos del estilo casual con financiamiento propio.
ANEXO B. RELEVAMIENTO 85

B.3.4. Mystery Studios


Realizan proyectos financiados en forma propia y por clientes que por lo general
duran alrededor de seis meses. Se enfocan en videojuegos del tipo Casual para PC y
utilizan para las ventas el modelo de ingreso Probar Antes de Comprar. Nunca han
utilizado el modelo de ingresos Advergaming porque no les rinde económicamente.
Además de hacer videojuegos, ofrecen sus servicios como desarrolladores y artistas
gráficos. También venden su plataforma de desarrollo para ser utilizada por otros de-
sarrolladores.
Sus clientes son publishers y portales, los cuales en un principio contactaban vı́a
correo electrónico para lograr que distribuyeran sus videojuegos. Con el paso del tiem-
po y el éxito logrado, concretan distintos tipos de contrato que van desde desarrollos
a pedido del cliente a venta de derechos y distribución de videojuegos de desarrollo
propio.
A futuro piensan seguir realizando videojuegos en los cuales un cliente les financie
el desarrollo del proyecto. Esta decisión se debe a las caracterı́sticas del mercado y
a que no pueden asumir los riesgos económicos ante un fracaso. A su vez con estos
ingresos buscan financiar sus propios videojuegos y ası́ obtener mayor beneficio al
momento de negociar su venta. También tienen planeado seguir creciendo en cantidad
de proyectos que pueden abarcar al mismo tiempo. Para esto piensan mudarse este
año a un local exclusivo para la empresa y contratar más personal, evitando ası́ tener
integrantes del equipo trabajando en forma independiente. Tienen la idea de asignar
un desarrollador a cada proyecto y crear nuevos roles, en donde los integrantes del
equipo con mayor experiencia participen en todos los proyectos solucionando las partes
difı́ciles y realizando consultorı́a para explicar la forma de proceder.

B.4 Equipos de Trabajo


Esta sección presenta lo relevado respecto a la conformación del equipo de trabajo
de las empresas, la cantidad de personas asignadas y sus roles dentro de un proyecto.

B.4.1. Batovi Game Studios


Se compone de cinco programadores y tres diseñadores gráficos. Además, por ser
un departamento de IPcom tienen contador, profesor de inglés, secretaria y departa-
mento de marketing. El diseño del videojuego es realizado por los programadores con
mayor experiencia en el tipo de videojuego a desarrollar. Se cuenta también con el
rol de productor para coordinar el trabajo del equipo e interactuar con el cliente. Nor-
malmente por proyecto trabajan dos o tres personas, entre las que hay al menos un
diseñador gráfico y un programador. Igualmente cuando las fechas lı́mite lo requieren
se puede sumar más gente al proyecto para cumplir con los plazos.

B.4.2. Kef Sensei


Cuentan con seis personas, donde tres son programadores y tres son artistas gráfi-
cos. Uno de los programadores, además, participa como productor. No tienen, aunque
86 B.5. METODOLOGÍA DE DESARROLLO

les gustarı́a, una estructura basada en los roles de la industria de videojuegos ya que
carecen el rol de diseñador de videojuego. Esto ocurre por no existir alguien con la
formación académica especı́fica en el equipo, por lo que el rol lo cubren entre todos los
integrantes del mismo.

B.4.3. Powerful Robot Games


Se conforma de productores, administrativos, cinco programadores y siete artistas
gráficos, siendo en total 20 personas. Abarcan los roles de diseñador de juego, pro-
gramador, artista gráfico y encargado de producción. Este último que se encarga de la
comunicación entre el diseñador del juego y los desarrolladores (programador y artista
gráfico). En cuantos a los proyectos no tienen grupos de trabajo definidos aunque siem-
pre intentan tener un solo programador por proyecto, el cual asume la responsabilidad
total de la implementación del mismo.

B.4.4. Mystery Studios


Se compone de dos programadores y una directora de arte, contando además con
artistas que trabajan en forma independiente. El equipo se subdivide en función de
los proyectos, trabajando en todos al menos un programador, la directora de arte y un
artista.

B.5 Metodologı́a de Desarrollo


Esta sección presenta lo relevado en cuanto a las metodologı́as de desarrollo de las
empresas para desarrollar sus videojuegos. Se abarca la concepción del videojuego, su
planificación, construcción, disciplinas, verificación y la documentación que se realiza.

B.5.1. Batovi Game Studios


Para definir el concepto del videojuego a realizar se hace una tormenta de ideas
entre todos los integrantes del equipo. En el caso de un videojuego financiado por
un cliente normalmente está definida la temática o los personajes pero igualmente se
producen ideas para hacer la propuesta definitiva. Es común que se realicen prototipos
en papel o utilizar un pizarrón para discutir ideas de los videojuegos a desarrollar.
Dado que la mayorı́a de sus proyectos son simples y tienen experiencia, comienzan a
desarrollar el videojuego directamente sin realizar previamente prototipos de código.
Sin embargo, en caso de proyectos más complejos suelen realizarlos para validar con
el cliente.
Para estimar tiempos no realizan análisis formal y se basan en su experiencia para
determinar el cronograma. En los proyectos financiados por un cliente, las fechas de
entrega vienen dadas y ellos las aceptan en base a su experiencia en ese tipo de video-
juego.
Implementan en iteraciones de corta duración para tener un nuevo ejecutable para
probar cada aproximadamente dos semanas. Además, realizan reuniones diarias para
ANEXO B. RELEVAMIENTO 87

discutir el avance y las actividades del dı́a. Se desarrolla el código del videojuego y el
arte en forma paralela y por esta razón inicialmente los programadores utilizan sustitu-
tos de arte.
Generalmente el diseño gráfico del videojuego es realizado internamente, a excep-
ción de los proyectos de Advergaming en donde es común que se les provea bancos
de imágenes. En pocas oportunidades optaron por hacer el sonido ellos mismos ya que
no es una buena opción por el tiempo que les insume. Lo más común es que el sonido
se tercerice. Para esto se le envı́an planillas de los efectos y música requerida a un
sonidista y luego este les envı́a los sonidos.
No siguen un proceso formal de verificación y no realizan verificación unitaria.
Realizan revisiones de código para encontrar y arreglar errores que detectan en la ver-
ificación funcional del videojuego, apelando principalmente a los errores visibles des-
de la interfaz gráfica. Cumplen la misma tanto internamente entre los integrantes del
equipo como por medio de amigos y familiares a los que distribuyen el videojuego.
Hay casos en los cuales el cliente se encarga de esta mediante sus departamentos de
verificación, reduciendo ası́ la responsabilidad de la empresa ante dicha tarea.
En cuanto a documentación, cuando un cliente los financia realizan un documento
de concepto y un documento de diseño de juego que puede variar en cantidad de hojas
dependiendo de la complejidad del videojuego en cuestión. Cuando no se les requiere
de entregar la documentación, no la realizan.

B.5.2. Kef Sensei


Los proyectos surgen desde el lado comercial ya que buscan realizar videojue-
gos que se adapten al mercado y conseguir un cliente que lo financie. Para definir el
concepto del videojuego estudian el mercado y realizan una tormenta de ideas con la
premisa de adaptar o extender el gameplay de videojuegos con probado éxito. Utilizan
un pizarrón para registrar las ideas surgidas que se fotografı́a para tener de referencia.
Utilizan prototipos evolutivos que sirven como forma de presentarse al cliente y lograr
un contrato. También se utilizan para minimizar riesgos tecnológicos.
Realizan estimaciones de la duración del proyecto para evaluar la factibilidad de
lo que les presenta el cliente. La estimación se basan en su percepción de las tareas a
realizar y de su experiencia en el desarrollo de software convencional.
Para implementar realizan iteraciones cortas, de una o dos semanas, donde se de-
sarrolla un entregable con una serie de caracterı́sticas del videojuego. Al finalizar cada
iteración se produce una reunión con el cliente para la validar la versión entregada.
Resultado de este encuentro se encuentran errores a corregir, se detectan nuevas carac-
terı́sticas y se planifican las siguientes iteraciones.
El diseño del videojuego es realizado por todos los integrantes del equipo aunque
no invierten demasiado tiempo en esta actividad dado que el gameplay de sus video-
juegos no es original. El arte visual, al igual que el arte sonoro, es realizado por los
diseñadores gráficos del equipo. Sin embargo, la empresa tiene pensado tercerizar el
sonido a profesionales del área.
Se verifica en cada iteración siguiendo los requerimientos acordados con el cliente.
Esta verificación se realiza en base a una planilla que entrega el cliente sobre las carac-
terı́sticas del videojuego a construir en la iteración ası́ como sobre restricciones de hard-
88 B.5. METODOLOGÍA DE DESARROLLO

ware o sistemas operativos. Para la verificación funcional, el videojuego se distribuye


entre amigos y familiares. El cliente también se encarga de la verificación además de
evaluar otros aspectos como ser curva de aprendizaje del juego, curva de dificultad, si
el videojuego es intuitivo, atractivo, etc.
La mayorı́a de la documentación la realizan como exigencia del cliente que los
contrata. Entre la documentación exigida se encuentra el documento de diseño y una
planilla de pruebas. Esta planilla sirve para comunicar los requerimientos mı́nimos de
aceptación en cuanto verificación que se deben realizar para la liberación del video-
juego (p.ej.: poder ejecutarse en Mac o en 800x600). Internamente utilizan una wiki
para discutir y definir ideas además de documentar.

B.5.3. Powerful Robot Games


Todo proyecto comienza definiendo el concepto del videojuego con el cliente. Al
utilizar el modelo de ingresos de Advergaming habitualmente el entorno y los per-
sonajes son definidos por el cliente. La parte creativa se acota a definir el género del
videojuego a utilizar y para ello suelen basarse en referencias de videojuegos existentes
que tuvieron éxito.
Ya que es importante encontrar la diversión en forma temprana desarrollan prototi-
pos para tomar decisiones respecto a diversos aspectos del videojuego. Existen muchos
casos en donde por falta de tiempo el prototipo inicial que se realiza con sustitutos de
arte se toma como base del videojuego final.
Estiman en base a la experiencia previa adquirida por el desarrollo de videojuegos
similares para determinar las fechas de entrega.
La construcción del videojuego se realiza en forma secuencial, donde primero se
realiza el diseño completo para luego pasarlo a los programadores y artistas para que
estos lo implementen. El diseño del videojuego se concentra en pocas personas y para
realizarlo se juegan videojuegos para obtener ideas y diseñar un gameplay atractivo.
Esta investigación sirve también como base para construir el concepto de futuros video-
juegos a desarrollar y para promover la creatividad del equipo a la hora de realizar la
tormenta de ideas. Es una disciplina que se ejecuta en forma continua y existen car-
acterı́sticas del videojuego que se cambian durante el desarrollo debido a que no son
suficientemente divertidas o porque son demasiado costosas de realizar.
Ya que generalmente sus proyectos son con el modelo de ingresos de Advergam-
ing, es común que el cliente les provea referencias para que el artista gráfico utilice
existiendo casos en donde les entregan bancos de imágenes reduciendo ası́ su trabajo
en esta área. En cuanto al sonido de los videojuegos la mayor parte de los proyectos lo
tercerizan a una empresa local que se encarga de crear los sonidos requeridos. Suelen
especificarles por medio de un documento datos genéricos cómo deberı́a ser el sonido,
por ejemplo si es un loop o no, cuál es la duración del mismo, una descripción del
sonido y situaciones en las que se ejecuta. Hay casos en donde el propio cliente les
entrega sonidos y bandas sonoras.
No tienen definido un proceso formal de verificación. Suelen realizarlo entre los
integrantes del equipo y generalmente le dedican poco tiempo por ser proyectos cortos
y similares entre sı́. En algunos casos el cliente cuenta con un equipo de verificación
ANEXO B. RELEVAMIENTO 89

que reporta, mediante el uso de una herramienta para seguimiento de errores, los errores
o funcionalidades a cambiar.
La documentación se utiliza para interactuar con el cliente. Entre esos documentos
están el de concepto del videojuego y el documento de diseño del videojuego. Este
último depende mucho del proyecto, ya que en el caso de videojuegos originales resulta
extenso por la necesidad de detallar los conceptos nuevos.

B.5.4. Mystery Studios


Construyen el concepto a partir de ideas tanto de los integrantes del equipo o de
un cliente (en caso de tenerlo). Para obtener ideas juegan videojuegos con un estilo
similar al que planean desarrollar. También se hacen bocetos para ver el estilo visual
del videojuego y otros aspectos gráficos.
Para los proyectos que financian no realizan análisis para estimar sino que se basan
únicamente en su experiencia. Para los proyectos financiados por un cliente en general
las fechas de entrega vienen dadas, por lo que las aceptan, siempre y cuando los tiempos
propuestos sean racionales. Dado que usualmente tienen fechas limites muy apretadas
utilizan prototipos evolutivos ya que lo que comienza siendo un prototipo se termina
transformando en el videojuego final. A partir del concepto construyen los prototipos
utilizando substitutos del arte gráfico para probar caracterı́sticas del videojuego. Esto
les permite además darse cuenta si el videojuego va a ser divertido antes de comenzar
a hacer los gráficos.
Generalmente comienzan a implementar bastante rápido a partir de que tienen la
idea sin realizar una etapa marcada de diseño del videojuego ni iteraciones durante la
construcción del videojuego. Esto se debe a que los videojuegos de tipo Casual son muy
similares entre sı́ y tras años de experiencia se vuelve innecesario realizarlo. En caso de
tener un cliente se ven obligados a trabajar en iteraciones en donde se implementa un
conjunto de caracterı́sticas en cada una y se muestra el avance. Intentan seguir buenas
prácticas para implementar sobre todo en lo que respecta a la calidad del código. Una
de ellas es tratar siempre de escribir como sı́ fuera código final aún cuando se este
prototipando ya que esto ahorra tiempo más adelante. También tienen prohibido subir
código al repositorio que se sabe tiene errores, de esta forma cuando algo está finalizado
tienen menos que verificar.
Los gráficos se realizan cuando se tiene más claro cuáles son los que se van a
precisar, con qué tamaños, etc. Generalmente la construcción de los gráficos lleva más
tiempo que la programación del videojuego porque implica volúmenes de trabajo ma-
yor. En algunas ocasiones encargaron gráficos a otras empresas, aunque la dirección de
arte es siempre de ellos. Esto ocurre debido a que ante un gran volumen de trabajo solo
cuentan con una persona especializada en el equipo. En cuanto al arte sonoro se ven en
la necesidad de tercerizar porque no cuentan con el conocimiento necesario para lograr
un nivel profesional en esta área.
Cuando dan un videojuego por terminado realizan verificación funcional. La mis-
ma es informal y básicamente consta de distribuir el videojuego entre amigos y conoci-
dos para que lo prueben. Además, se envı́a a miembros de foros de desarrolladores de
videojuegos para aprovechar que estos pueden detectar más errores y expresar de mejor
forma lo que se considera habrı́a que modificar. Todos sus videojuegos tienen imple-
90 B.5. METODOLOGÍA DE DESARROLLO

mentado la posibilidad de enviar un correo electrónico con el reporte del error en caso
de falla. En proyectos financiados por un cliente este se encarga de realizar las pruebas.
Cuando se detectan errores se comunican utilizando herramientas de seguimiento de
errores
No realizan demasiada documentación principalmente porque son proyectos sufi-
cientemente simples técnicamente. Suelen usar listas de caracterı́sticas y algún docu-
mento corto de dos o tres páginas describiendo la idea del videojuego. Sin embargo,
cuando un cliente financia el proyecto muchas veces se requieren un documento de
diseño del videojuego para especificar qué es lo que se va a hacer. Estos documentos
son propios de cada cliente con diferentes exigencias y se extienden entre cuarenta y
cincuenta páginas.
Splinks Deathmatch - Documento de
C
Concepto

El propósito de este documento es introducir los conceptos y motivaciones del


proyecto Splinks Deathmatch. En la sección C.1 se presenta la visión del videojuego.
En la sección C.2 se define el género del videojuego. En la sección C.3 se presenta la
mecánica de juego. En la sección C.4 se presentan las caracterı́sticas del videojuego.
En la sección C.5 se detalla el ambiente donde se lleva a cabo el videojuego. En la sec-
ción C.6 se presenta la historia del videojuego. En la sección C.7 se describe el público
al que apunta el videojuego. En la sección C.8 se presenta la plataforma objetivo. En
la sección C.9 las tecnologı́as y herramientas que se van a utilizar. Por último, en la
sección C.10 se presentan algunos bocetos de arte.

C.1 Visión
Splinks Deathmatch es un juego 3D multijugador en donde podrás enfrentarte a
tus amigos en un combate a muerte. Tu personaje es un Splink, un extraterrestre capaz
de controlar cualquier tipo de criaturas con distintas habilidades y poderes. Utiliza las
mejores combinaciones de personajes, habilidades y powerups para lograr estrategias
únicas y vencer a tus oponentes.

C.2 Género
Es un juego de lucha multijugador, influenciado por los juegos Bomberman, Kong
y Soldat.

C.3 Mecánica de Juego


Inicialmente, el jugador controla un Splink, con el cual puede moverse dentro de la
arena de combate o poseer mentalmente a las criaturas. Una vez poseı́da la criatura, el
jugador pasa a controlarla pudiendo golpear otras criaturas, pisar a los demás Splinks

91
92 C.4. CARACTERÍSTICAS

y hacer uso de sus habilidades especiales. Además, puede desposeer a la criatura en


cualquier momento.
Existen diversos modos de juego:

Competencia a muerte: el objetivo es eliminar a los demás Splinks y ser el único


en permanecer vivo. Además, existe la posibilidad de jugar en equipos.

Supervivencia por tiempo: el objetivo es permanecer vivo por el mayor tiempo


posible, al morir se rota el turno al siguiente jugador y se reviven los jugadores
muertos. Estas rondas se repiten varias veces y el ganador es el que logra la mejor
suma de tiempos entre todas las rondas.

Capturar la bandera: similar al modo anterior, el jugador debe intentar capturar


la bandera y luego mantenerla el mayor tiempo posible. Al finalizar un tiempo
determinado, el jugador que mantuvo la bandera mayor proporción de tiempo es
el ganador.

C.4 Caracterı́sticas
Varios modos de juego: competencia a muerte, sobrevivir el mayor tiempo, cap-
turar banderas, etc.

Capacidad de controlar varios tipos de criaturas con distintas habilidades y ca-


racterı́sticas como fuerza, velocidad, resistencia y poder mental.

Jugar con amigos en una sola máquina o en una red local utilizando varios tipos
de controladores.

Un conjunto de powerups que hacen la experiencia del jugador mucho más diver-
tida, controlando la velocidad del personaje, área de control mental, resistencia,
inmortalidad, entre otros.

Poder jugar campeonatos y guardar las puntuaciones y estadı́sticas para determi-


nar quién es el mejor jugador.

Distintos tipos de terrenos con relieves, tierra, agua, nieve, entre otros.

C.5 Ambientación
La civilización de los Splinks no posee una tecnologı́a muy avanzada, en ciertos
aspectos es muy parecida al pueblo romano, a sus casas y ciudades.
Los lugares donde se realizan las luchas tienen una figura cilı́ndrica o rectangular
(ej: plazas de toros, coliseo romano) como un anfiteatro con gradas precarias.
ANEXO C. CONCEPTO 93

C.6 Historia
Los Splinks son la raza dominante en el planeta que habitan. Son débiles fı́sica-
mente pero con un gran poder mental, con el cual pueden poseer cualquier ser con
cerebro y hacerlo obedecer. De esta forma, domando a las demás criaturas de su plane-
ta han podido crear una gran civilización.
Además, tienen como tradición celebrar combates a muerte para determinar el
ganador y hacerle entrega del tı́tulo de campeón. Estos combates se celebran dentro
de anfiteatros en los cuales el público puede alentar a sus luchadores favoritos. Dentro
del área de combate se colocan diferentes criaturas que son controladas por los Splinks
para matar a los demás. Estas criaturas no están domadas lo cual dificulta el control de
los Splinks y hace más peligrosa la contienda.

C.7 Público Objetivo


Este juego está dirigido a jugadores sociales con cierta experiencia en videojuegos,
ni casuales ni hardcore, que les gusta compartir un rato con amigos, posiblemente en
un mismo espacio fı́sico.

C.8 Plataforma Objetivo


Las plataformas objetivo son: Windows, Linux y posiblemente Mac OS u otros sis-
temas que soporten la máquina virtual de Java.

C.9 Tecnologı́as y Herramientas


El juego se desarrollará en Java, haciendo uso del motor 3D JMonkeyEngine y de
las herramientas para generar contenido a ser usado por este. Para la codificación se
hará uso del entorno de desarrollo Eclipse.
Se cuenta con la posibilidad de utilizar controles de mando extra como el control
de Xbox360 para Windows, entre otros.

C.10 Bocetos
A continuación se presentan los bocetos realizados.
94 C.10. BOCETOS

Figura C.1: Bocetos de Alen Chimanosky

Figura C.2: Bocetos de Leonardo Silva


ANEXO C. CONCEPTO 95

Figura C.3: Bocetos de Diego Tapié

Figura C.4: Bocetos de Diego Tapié


96 C.10. BOCETOS

Figura C.5: Bocetos de Javier Miles


ANEXO C. CONCEPTO 97

Figura C.6: Bocetos de Javier Miles


Splinks Deathmatch - Documento de
D
Diseño de Juego

El propósito de este documento es especificar el diseño del videojuego Splinks


Deathmatch. Este incluye la descripción de su mecánica de juego, la interacción con
el usuario, los personajes y escenarios. En la sección D.1 se presenta la mecánica de
juego. En la sección D.2 cómo se realiza la interacción con el usuario. En la sección
D.3 cuáles son los personajes del videojuego. Por último, en la sección D.4 se detallan
los escenarios del videojuego.

D.1 Mecánica de Juego


La partida comienza con varias criaturas y Splinks distribuidos por el área de juego.
Controlando un Splink, cada jugador debe utilizar a las criaturas como medio para
golpear a las demás hasta lograr que los Splinks que las poseen sean expulsados y
ası́ queden vulnerables a los pisotones.
La escena está compuesta por el área de juego donde combaten los personajes y
otros elementos externos como por ejemplo las gradas y puertas con los cuales no se
puede interactuar. Durante la partida, aparecen criaturas y elementos coleccionables en
posiciones aleatorias o preestablecidas cada cierto tiempo, hasta un máximo preestable-
cido.

D.1.1. Personajes
Los personajes tienen diversos atributos que modifican la mecánica del juego. Los
Splinks tienen los atributos de velocidad, rango de control mental, energı́a mental y
energı́a vital. Las criaturas tienen los atributos de raza, velocidad, energı́a vital, daño
de golpe y daño de pisotón.
Tanto los Splinks como las criaturas pueden moverse únicamente dentro de los
lı́mites del área de juego y ningún personaje puede caminar por arriba de otro.
Un Splink puede controlar a una criatura solamente si se encuentra dentro de su
rango de control y su energı́a mental está completa. Cuando un Splink está controlando
una criatura su energı́a mental disminuye y si se queda sin energı́a mental, es expulsado.
ANEXO D. DISEÑO DE JUEGO 99

La energı́a mental se recupera automáticamente cuando el Splink no está controlando


a ninguna criatura.
Las criaturas pueden golpear a las demás criaturas o pisar a los Splinks. Cuando
una criatura recibe un golpe de otra criatura pierde energı́a vital dependiendo del daño
de golpe, si pierde toda su energı́a vital, muere y si algún Splink la controla éste es
expulsado. Cuando el Splink recibe un pisotón de una criatura, pierde energı́a vital
dependiendo del daño de pisotón y muere si pierde toda su energı́a vital.

D.1.2. Elementos Coleccionables


Son elementos que el jugador puede adquirir y que modifican la mecánica del juego
a partir de cambios en distintas propiedades de los personajes o del juego mismo. Estos
elementos se activan al ser tocados por un personaje.

Bomba: produce daño a la energı́a vital de los personajes dentro de un rango


determinado con centro en el lugar donde se recoge. El rango puede ser aleatorio
para cada bomba que aparezca y no es conocido hasta que se recoge, se debe
mostrar gráficamente el rango de explosión.

Modificadores de habilidades: producen distintos efectos sobre una de las ha-


bilidades del personaje (p.ej. la velocidad, el poder mental o la energı́a vital),
pudiendo aumentar o disminuir temporalmente o de forma definitiva.

Expulsar a los demás Splinks: mediante una descarga de energı́a permite expulsar
de las criaturas y a los Splinks que están dentro del rango de la descarga con
centro en el lugar donde se recoge.

Inmortalidad temporal: el daño de todos los ataques que reciba el jugador quedan
anulados durante un perı́odo de tiempo.

D.1.3. Elementos de la Escena


Son elementos de la escena que interactúan directa o indirectamente con los perso-
najes modificando la mecánica del juego. Particularmente existen trampas que afectan
de forma negativa sobre los personajes.

Arenas movedizas: Es una trampa que puede aparecer en cualquier lugar del
área de combate por un tiempo determinado y luego desaparece. Si una criatura
o Splink cae dentro, puede ser succionada hacia adentro cuando desaparezca,
teniendo unos pocos segundos para escapar.

Cañones de fuego: Los cañones de fuego se ubican en las paredes del estadio.
Se activan durante unos segundos cada cierto tiempo. Largan llamas capaces de
quemar a cualquiera que esté a su alcance.
100 D.2. INTERACCIÓN CON EL USUARIO

D.1.4. Modos de Juego


El objetivo del juego es eliminar a los Splinks oponentes y permanecer con vida.
Competencia a muerte: el objetivo es eliminar a los demás Splinks y ser el único
en permanecer vivo. Cuando queda únicamente un Splink vivo el juego termina
y el éste es el ganador.
Competencia a muerte con regeneración: igual al modo competencia a muerte
pero con una duración de tiempo fija y si un Splink muere regenera luego de
cierto tiempo, el ganador es el que haya provocado más muertes de Splinks.

D.2 Interacción con el Usuario


El juego tiene una perspectiva 3D, los dispositivos con los que interactúa el usuario
son el ratón y el teclado. Dentro del juego, puede realizar las siguientes acciones:
Acciones de interacción con el juego.

• Caminar con los personajes.


• Poseer criatura.
• Golpear criatura.
• Pisar Splink.
• Seleccionar criatura a poseer.

Otras

• Pausar el juego.
• Salir del juego.
• Cambiar la cámara.
• Rotar, alejar, acercar y cambiar la altura de la cámara.

D.2.1. Cámaras
Existen distintas cámaras que el usuario puede seleccionar durante la partida para
ajustar la perspectiva a su preferencia, estas son:
Cámara tercera persona libre: con eje en el jugador, se puede rotar, alejar, acercar
y modificar la altura.
Cámara tercera persona: se mantiene a una distancia y ángulo fijo, con eje en el
jugador.
Cámara fija aérea: está fija a una distancia alejada del jugador, no se puede mo-
dificar.
Cámara última posición: permanece fija en la posición de la última cámara y
persigue al jugador.
ANEXO D. DISEÑO DE JUEGO 101

D.2.2. Controles
En esta sección se explica como se realizan las acciones a partir de los dispositivos.

Básicos
El jugador puede mover a su personaje con las teclas W, A, S y D. Podrá seleccionar
la cámara con las teclas 1-4 y dependiendo de esta, podrá rotarla moviendo el ratón.
Con la tecla P puede pausar el juego, mientras que con Esc puede salir.

Avanzados
Dependiendo si el Splink del jugador está controlando mentalmente a una criatura
o no, los tres botones del ratón permiten realizar diferentes acciones.
Si no está controlando a una criatura entonces el usuario puede poseer una criatura
con el botón izquierdo del ratón (siempre que está dentro de su rango de posesión)
mientras que con el botón derecho puede seleccionar a que criatura (dentro del rango)
poseer.
Cuando se está controlando a una criatura, las acciones posibles son: golpe de puño
con el botón izquierdo, pisotón con el botón derecho y abandonar a una criatura con el
botón del medio del ratón.

D.2.3. Información en Pantalla


A continuación se describe la información que se presenta en pantalla durante el
juego.
Se separa esta información en dos grupos, información dentro de la escena e infor-
mación en la interfaz de usuario (HUD).

D.2.3.1. Información de Escena


Rango de control mental: alrededor del Splink del jugador se muestra un cı́rculo
a nivel del piso que indica hasta donde será capaz de saltar para controlar a
una criatura. Si el Splink no tiene su energı́a mental completa, el cı́rculo no se
mostrará ya que será incapaz de controlar criaturas.

Energı́a vital de los personajes: cada personaje distinto del Splink del jugador
tiene una barra sobre su cabeza que indica la energı́a vital del mismo. El color
varı́a de verde a rojo y disminuye su tamaño a medida que va perdiendo energı́a
vital.

Indicador de Splink del jugador: el Splink del jugador es remarcado, por ejemplo
con el número o nombre del jugador en la cabeza del personaje.

Criatura poseı́da: las criaturas poseı́das tienen un Splink que la controla en la


cabeza. Como cada Splink tiene un indicador de jugador, entonces se sabrá qué ju-
gador controla a qué criatura.
102 D.3. PERSONAJES

Criatura seleccionada para controlar: cuando un Splink tiene más de una criatura
en su rango de control mental, el jugador puede seleccionar qué criatura contro-
lar. La criatura seleccionada será identificada con un triángulo amarillo sobre su
cabeza.

D.2.3.2. Información de Interfaz de Usuario (HUD)


Radar: muestra las criaturas y Splinks dentro del área de juego. Ayuda a ubicarse
e identificar a nivel global las amenazas o vı́ctimas.
Energı́a de control mental del Splink del jugador: se muestra una barra de energı́a
de control mental que vara su color y tamaño dependiendo de la cantidad de
energı́a que posee el Splink.
Energı́a vital del Splink del jugador: se muestra una barra de energı́a vital que
varı́a su color y tamaño dependiendo de la cantidad de energı́a que posee el
Splink.
Tiempo: se muestra el tiempo de la partida. En el modo Competencia a muerte
con regeneración esta información toma mayor relevancia.
Tiempo para regeneración: en el modo Competencia a muerte con regeneración,
si el jugador está muerto, se muestra el tiempo que debe esperar para volver a
jugar.
Estadı́sticas: en el modo Competencia a muerte con regeneración se muestran es-
tadı́sticas como por ejemplo la cantidad de muertes ocasionadas por cada Splink,
posiblemente en forma de tabla.
En la siguiente figura podemos ver un boceto de la información de interfaz de
usuario.

D.2.4. Pantallas
A continuación se muestra un diagrama que muestra las pantallas que se esperan
tener en el juego.

D.3 Personajes
En esta sección se describe cada uno de los personajes del juego.

D.3.1. Splink
Los Splinks son una raza inteligente pero no tienen muchas capacidades fı́sicas,
dependen de otras criaturas para realizar acciones. Su poder es controlar las acciones
de las demás criaturas saltando en su cabeza. Cada Splink tiene un rango acotado dentro
del cual puede saltar, pudiendo saltar en 360 grados. El tiempo de control que tiene un
Splink sobre una criatura depende tanto del poder de control mental del Splink como
de la resistencia mental de la criatura.
ANEXO D. DISEÑO DE JUEGO 103

Figura D.1: Información de interfaz de usuario

Inteligencia Artificial
Los Splink controlados por el computador tienen un comportamiento básico. Cuan-
do su energı́a de control mental está completa buscan a la criatura más cercana para
controlar. Luego controlan a su criatura buscando al Splink vulnerable más cercano o
bien a la criatura controlada por el Splink más cercano e intenta golpearlo. Si se encuen-
tra recargando su energı́a de control mental, entonces huye de las criaturas buscando
estar a salvo.

Atributos
El Splink cuenta con los atributos de velocidad de movimiento, rango de control
mental, energı́a mental y resistencia vital.

D.3.2. Criaturas
Existen varios tipos de criaturas, son las distintas razas que viven en el planeta
de los Splink. Estas son muy poco inteligentes y fáciles de domar. Tienen distintas
habilidades dependiendo de su raza. Algunas son más fuertes o más rápidas, mientras
que otras tienen golpes especiales con mayor fuerza o rango de ataque.
104 D.3. PERSONAJES

Figura D.2: Pantallas del juego

Inteligencia Artificial

Las criaturas en general son tontas, vagan por el escenario sin importar que algún
Splink los esté acechando. Evitan las paredes y a las demás criaturas si detectan co-
lisión. Cada raza particular puede tener un comportamiento un poco diferente, algu-
nas pueden ser más inteligentes, intentar pisar a los Splink que pasan cerca, o bien
perseguirlos si se encuentran dentro de un rango.

Atributos

Las criaturas cuentan con los atributos de raza, velocidad de movimiento, resisten-
cia vital, fuerza de golpe, fuerza de pisotón y resistencia mental.

Razas

Actualmente solo existe una raza llamada Urso.


ANEXO D. DISEÑO DE JUEGO 105

D.4 Escenarios
El juego transcurre dentro de un estadio circular con caracterı́sticas muy similares
a un coliseo o plaza de toros. El área de combate debe ser suficientemente grande para
que puedan competir al menos 4 jugadores con 4 criaturas a la vez.
Actualmente existe un solo estadio aunque es deseable tener varios estadios para
seleccionar donde jugar.
Splinks Deathmatch - Documento de
E
Diseño Técnico

Este documento resume el diseño técnico del videojuego desarrollado, explican-


do cómo se resolvieron todos y cada uno de los problemas que se presentaron. En la
sección E.1 se presentan las tecnologı́as seleccionadas. En la sección E.2 se detallan
los estados de juego. En la sección E.3 se define cómo se manejó la escena. En la
sección E.11 se detallan los controles que se utilizan en el videojuego. En la sección
E.5 se presenta el manejo de las sombras. En la sección E.6 se describe el manejo de
las colisiones. En la sección E.7 se muestra la maquina de estados por los que pasa
el videojuego. En la sección E.8 se describen los controladores utilizados en el video-
juego. En la sección E.9 se detalla la inteligencia artificial implementada. En la sección
E.10 se presenta la información que aparece en pantalla. En la sección E.11 se muestran
los contenidos audiovisuales. En la sección E.12 se presenta el manejo de liberaciones
y versiones. Por último, en la sección E.13 se hace un resumen de las caracterı́sticas no
implementadas.

E.1 Tecnologı́as Seleccionadas


Para resolver el problema se seleccionaron un conjunto de herramientas tanto para
la generación de contenidos como para la implementación del videojuego.

E.1.1. Generación de Contenidos


El desarrollo de contenidos fue realizado tanto por el equipo externo de artistas
gráficos (modelos 3D y texturas) como por el equipo interno al desarrollo (audio y al-
gunas texturas). Se utilizaron las herramientas 3D Studio [3DS09] para la generación de
modelos y animaciones 3D, Gimp [GIM09] y Photoshop [PHO09] para la generación
de texturas y Audacity [AUD09] para generar los efectos y bandas sonoras.

E.1.2. Implementación
Se utilizó el motor de juego jMonkeyEngine [jMo08] que dibuja en pantalla uti-
lizando Lightweight Java Game Library (LWJGL) [LWJ08]. LWJGL es una biblioteca
ANEXO E. DISEÑO TÉCNICO 107

liviana que brinda acceso a las bibliotecas Open Graphics Library (OpenGL) [OPE09b]
y Open Audio Library (OpenAL) [OPE09a], además de proveer acceso a controladores
como Gamepads, Joysticks y volantes. En la Fig.E.1 se presenta el diagrama de com-
ponentes.

Figura E.1: Diagrama de componentes

Además, se utilizaron otras herramientas cuya descripción se presenta más adelante


en este capı́tulo.

E.2 Estados del Juego


El videojuego pasa por distintos estados durante su ciclo de vida, en la Fig.E.2 se
puede apreciar el diagrama de esta máquina de estados.

Figura E.2: Estados por los que pasa el videojuego

El videojuego comienza en el estado de inicio/carga el cual carga los recursos y


108 E.3. ESCENA

muestra una pantalla con la portada y una barra de progreso. Cuando la carga termina
se dirige al estado de tutorial el cual muestra una pantalla que explica las reglas del
juego y los controles. Cuando el usuario quita la pausa, se dirige al estado de juego
el cual procesa la lógica del videojuego. Desde esta, el usuario puede volver a pausar
para ver la pantalla anterior, o bien, cuando el jugador gana o pierde la partida se pasa
al estado de fin de juego que se encarga de mostrar quien ganó la partida.

E.3 Escena
La escena se manejó utilizando la estructura de grafo de escena provista por el
motor. Un grafo de escena es una estructura de datos que permite representar relaciones
lógicas entre elementos del videojuego y fácil manipulación de estas. En la Fig.E.3 se
presenta un diagrama simplificado del grafo de escena utilizado. Se utilizó la herra-
mienta Scene Monitor [SCE09] para obtener información y modificar datos en tiempo
de ejecución.

Figura E.3: Grafo de escena de ejemplo.

Por otro lado, también se definió una estructura propia para agrupar fácilmente ele-
mentos y lógica común, como por ejemplo, obtener todos los personajes que cumplen
cierta condición.

E.4 Controles
Se implementaron varios controles para la captura de datos de entrada del usuario
(teclado y ratón) que permiten manipular los distintos elementos del videojuego como
el personaje, la cámara y el estado.
ANEXO E. DISEÑO TÉCNICO 109

El control de personaje permite controlar al personaje a partir de distintas ac-


ciones del jugador utilizando una combinación del teclado y el ratón. El primero
se usó para determinar la dirección de movimiento mientras que el segundo para
ejecutar las acciones del personaje (p.ej. controlar mentalmente).

El control de cámara permite acercar, alejar, rotar y cambiar la altura de la


cámara. Además, provee la posibilidad de elegir distintas cámaras.

El control de estado de videojuego permite cambiar entre un estado u otro del


videojuego (p.ej. pausar el videojuego o salir del mismo).

Estos controles fueron implementados utilizando la clase Controller propia del


motor, la cual es actualizada en cada ciclo de juego. Los controles determinan en cada
actualización, a partir de las teclas o botones presionados, la acción a tomar.

E.5 Sombras

Para dibujar las sombras se utilizó el algoritmo shadow volumes [SHA08] de varias
pasadas implementado por el motor gráfico, por lo que el problema se redujo a utilizarlo
correctamente. Se proyectan únicamente las sombras de los personajes y se recalculan
en cada actualización del ciclo de juego. Se utilizó la herramienta Shadow Tweaker1 ,
la cual permite manipular varios parámetros en el procesamiento de las sombras. En la
Fig.E.4 se puede apreciar una imagen del videojuego con las sombras generadas.

Figura E.4: Sombras de los personajes sobre el terreno.

1 Herramienta distribuida con el motor.


110 E.6. COLISIONES

E.6 Colisiones
En esta sección se explica cómo se resolvió cada uno de los tipos de colisiones del
videojuego.

Movimiento
Las colisiones en el movimiento implican detectar cuándo un personaje no puede
moverse debido a que hay un obstáculo. Los obstáculos pueden ser los delimitadores
del área de juego u otros personajes.
La estrategia utilizada consiste en determinar si la próxima posición de un personaje
(usando el movimiento que corresponda) no presenta una colisión. Como el videojuego
se desarrolla solamente sobre una altura determinada, se propone simplificar estas co-
lisiones proyectando todo sobre el plano de juego y luego resolver colisiones simples
con volúmenes acotantes en dos dimensiones. En la Fig.E.5 se muestra esta técnica.

Figura E.5: Técnica para determinar si el movimiento presenta colisión

Inteligencia Artificial
La inteligencia artificial utiliza un comportamiento denominado obstacle avoi-
dance, el mismo requiere determinar posibles colisiones para evitarlas. Para este com-
portamiento se utiliza la técnica de detección de intersección de volúmenes acotantes.
Primero se define un volumen que encierra la posición actual del personaje y una posi-
ción hacia donde se quiere mover el personaje. Con este volumen y los volúmenes
de los demás personajes se hallan las intersecciones y se plantea la dirección del
movimiento para evitar colisiones. En la Fig.E.6 se muestra un personaje (el triángulo),
una serie de obstáculos y el volumen acotante utilizado para detectar las colisiones.

Cámaras
Una de las cámaras permite aumentar o reducir la distancia al personaje y rotar
con eje en él. Esta cámara tiene la dificultad de que no debe salir del área de juego en
ningún momento ya que sino podrı́a quedar detrás de objetos que obstruyen la visión
del jugador. Como solución, se optó por definir un área lı́mite por donde la cámara
puede moverse, en particular, este problema se resolvió proyectando a un plano en
forma similar a la resolución del movimiento planteada anteriormente. En este plano
se determina un rayo que se forma a partir de dos puntos, el personaje y la posición
ANEXO E. DISEÑO TÉCNICO 111

Figura E.6: Técnica de obstacle avoidance

actual de la cámara, y que se proyecta hasta cortar con el volumen acotante. En caso
de estar dentro no se hace nada, en caso de estar afuera del volumen se sobrescribe
la posición de la cámara con la posición del punto de intersección. En la Fig.E.7 se
presenta un diagrama de la técnica.

Figura E.7: Diagrama de colisión de la cámara con el estadio.

Ataque
El ataque implica determinar cuando un personaje debe recibir daño de otro perso-
naje que lo ataca. Se utilizaron dos estrategias distintas según el tipo de ataque: golpe o
pisotón. A continuación se explica en que consiste la estrategia utilizada en cada caso.

Golpe: consiste en añadir un volumen acotante invisible (una caja) al esqueleto


de la animación del personaje y luego determinar colisión entre esta caja y el
volumen acotante del objetivo. Esta estrategia provee de una gran precisión y
velocidad de procesamiento, pero tiene la desventaja de que hay que generarlo
en el momento de la construcción del modelo. En la Fig.E.8 se puede observar
la caja de golpe.
112 E.7. MÁQUINA DE ESTADOS

Figura E.8: Volumen acotante (en rosado) añadido al esqueleto de la criatura para de-
terminar las colisiones del golpe.

Pisotón: la estrategia utilizada consiste en determinar los personajes que están


dentro de un cı́rculo con centro en la posición de la criatura. A estos se les aplica
un daño dependiente de la distancia entre la colisión determinada y el centro del
cı́rculo. En la Fig.E.9 se puede observar la técnica utilizada.

Figura E.9: Técnica para la detección de pisotón.

E.7 Máquina de Estados


Cada personaje tiene un conjunto de estados que definen distintos comportamien-
tos. Para esto, se plantea una máquina de estados donde distintas acciones del usuario
o eventos internos al juego producen distintas transiciones. Considerando que el perso-
naje consiste en un conjunto de controladores y componentes (que se describen en la
próxima sección), cada estado implementa una lógica particular que determina qué con-
troladores están activos o no, para lo que se utilizó el patrón de diseño State Pattern
ANEXO E. DISEÑO TÉCNICO 113

[GHJ95].
Se manejan dos tipos de estados, unos donde el jugador puede interactuar y otros
de transición a otro estado. Un ejemplo de estado de transición es cuando el Splink salta
a poseer a una criatura y el jugador solo puede observar mientras se ejecuta la lógica
interna.
A continuación se explica la máquina de estados de cada personaje.

Splink
A continuación se explican los estados del Splink. En la Fig.E.10 se puede apreciar
la máquina de estados indicando las transiciones.

Figura E.10: Máquina de estados del Splink

Idle/Walking: Estado inicial. Durante este estado el jugador puede mover el


Splink e intentar poseer criaturas. En este estado el personaje puede recibir ataques.

GoingToPossess: Sucede cuando el Splink está yendo hacia la criatura, es un


estado de transición y el jugador no puede realizar ninguna acción.
114 E.7. MÁQUINA DE ESTADOS

Possessing: Sucede cuando está controlando una criatura, durante este estado
todas las acciones del Splink son redirigidas hacia la criatura que está controlan-
do.

Unpossessing: Sucede cuando el Splink pierde control de la criatura y es lan-


zado hacia el terreno, es un estado de transición y el jugador no puede realizar
ninguna acción.

Attacked: Sucede cuando el Splink recibe un pisotón de una criatura, es un


estado de transición y el jugador no puede realizar ninguna acción.

Dying: Sucede cuando el Splink pierde toda su energı́a, es un estado de transición


y el jugador no puede realizar ninguna acción.

Criatura
A continuación se explican los estados de la criatura. En la Fig.E.11 se puede apre-
ciar la máquina de estados indicando las transiciones.

Figura E.11: Máquina de estados de la criatura

Idle/Walking: Estado inicial. Durante este estado el jugador puede mover la


criatura y atacar otras criaturas o Splinks. En este estado el personaje puede
recibir ataques.
ANEXO E. DISEÑO TÉCNICO 115

Attacking: Sucede cuando la criatura está atacando a otras criaturas o Splinks


tanto por un golpe como por un pisotón. En este estado el personaje puede recibir
ataques.

Attacked: Sucede cuando la criatura recibe un golpe de otra criatura, es un


estado de transición y el jugador no puede realizar ninguna acción.

Dying: Sucede cuando la criatura pierde toda su energı́a vital, es un estado de


transición y el jugador no puede realizar ninguna acción.

E.8 Controladores y Componentes


Cada controlador realiza una lógica especı́fica. Cada personaje se compone de va-
rios controladores que son activados o desactivados desde cada estado del personaje
según corresponda para lograr el comportamiento necesario. Dentro de la lógica de
los controladores se encuentra por ejemplo la de recuperar energı́a mental cada cier-
to tiempo. Todos los controladores son subclases de la clase Controller propia del
motor. Esta se puede agregar a los nodos del grafo de escena y es actualizada en cada
ciclo de juego para ejecutar una lógica especı́fica. En Fig.E.12 se presenta, a modo de
ejemplo, un diagrama simplificado que muestra alguna de las relaciones con la API del
motor de juego.

Figura E.12: Componentes y controladores

Estos se presentan a continuación.

RecoverPossessionEnergyController: se activa cuando el Splink no está con-


trolando ninguna criatura. Recarga su energı́a cada cierto tiempo hasta el tope de
energı́a.
116 E.8. CONTROLADORES Y COMPONENTES

DecreasePossessionEnergyController: se activa en el momento que el Splink


esta controlando una criatura. Descarga su energı́a cada cierto tiempo hasta el
mı́nimo, en cuyo caso envı́a un evento para abandonar la criatura.

CharacterAnimationController: actualiza la animación del modelo 3D ac-


tual.

GravityController: activo tanto en el Splink como en la criatura. Se encarga


de mantener al personaje a la altura del terreno.

CharacterMoveController: se encarga de calcular la próxima posición de un


personaje a partir de su posición, velocidad y aceleración actuales, implemen-
tando un movimiento rectilı́neo uniformemente acelerado. Considerando si coli-
siona o no con otros elementos, aplica el movimiento correctamente o anula el
movimiento, respectivamente.

GoingToPossessController: se activa al momento de intentar controlar una


criatura. Se encarga de mover al Splink hacia la criatura y se desactiva en el
momento de alcanzarla.

UnpossessController: se activa en el Splink en el momento de perder control


sobre una criatura. Se encarga de moverlo hacia una posición aleatoria del terreno
y se desactiva al llegar a ella.

RouteCharacterController: se activa cuando muere un personaje. Se encarga


de hacer desaparecer el cuerpo de a poco moviéndolo hacia abajo del terreno.

RespawnCreaturesController: actúa a modo general y se encarga de regene-


rar criaturas en el área de juego en diversas posiciones preestablecidas cada un
tiempo determinado hasta un lı́mite de criaturas.

Los componentes agrupan funcionalidad pero no son actualizados en el ciclo de


juego. En particular se tienen los siguientes componentes:

AttackComponent: concentra la lógica de detectar y realizar un ataque. Tiene


varias subclases implementando diversas técnicas, en caso de detectar un ataque
envı́a eventos correspondientes.

BoundingAttackComponent: subclase de AttackComponent, detecta colisiones


a partir de un volumen acotante vinculado al esqueleto del modelo (técnica vista
en E.6). Utilizado para el golpe.

DiskAttackComponent: subclase de AttackComponent, detecta colisiones a


partir de un rango de distancia determinado a partir de la posición actual (técnica
vista en E.6). Utilizado para el pisotón.

HitPointsComponent: tiene la lógica de modificación de energı́a vital, enviando


eventos en caso de llegar a cero.
ANEXO E. DISEÑO TÉCNICO 117

E.9 Inteligencia Artificial


Para la implementación de la inteligencia artificial se usaron los conceptos expresa-
dos por Craig Reynolds en el artı́culo Steering Behaviors For Autonomous Characters
[Rey99].
Un agente autónomo es un sistema situado en un entorno que siente este entorno y
actúa sobre él, en el transcurso del tiempo, siguiendo sus propios propósitos. Se llama
agente autónomo a los agentes que poseen cierto grado de movimiento autónomo. Si un
agente autónomo se encuentra a una situación inesperada, como encontrar una pared
en su camino, este tendrá la habilidad de responder y ajustar su movimiento como
corresponda.
El movimiento de un agente autónomo puede ser dividido en tres capas:

Selección de acción: Esta parte del comportamiento del agente es responsable de


elegir sus objetivos y decidir qué plan seguir.

Dirección (steering): Esta capa es responsable de calcular las trayectorias re-


queridas para satisfacer los objetivos y planes establecidos por la capa de selec-
ción de acción. Los comportamientos de dirección (steering behaviors) son la
implementación de esta capa. Ellos producen una fuerza de dirección que des-
cribe hacia donde debe moverse un agente y cuán rápido debe viajar para llegar
a ese lugar.

Locomoción: Es la capa inferior y representa los aspectos mecánicos del movi-


miento del agente. Indica cómo viajar de A hacia B. Por ejemplo, si se imple-
mentan las mecánicas de un camello y un tanque y luego se les da un comando
para que viajen hacia el norte, usarán diferentes procesos mecánicos para crear
movimiento a pesar de que su objetivo es el mismo. Separando esta capa, es posi-
ble utilizar los mismos comportamientos para diferentes tipos de locomoción.

Se implementaron inteligencias artificiales para las criaturas libres y para los Splinks
que no son controlados por un jugador.

Criatura: se intenta lograr que se mueva por el área de juego de forma natural
evitando obstáculos. Se manejan los comportamientos de wander y obstacle
avoidance.

Splink: se busca que parezca controlado por otro jugador humano. Inicialmente
se mueve por la escena en busca de una criatura libre para poder controlarla. En
caso de que exista criatura libre suficientemente cerca, la persigue hasta contro-
larla. En caso de no haber criaturas o no tener energı́a suficiente, se mueve por
la escena intentando escapar de las criaturas controladas. Cuando controla una
criatura, busca otros Splinks para poder eliminarlos. Al acercarse al Splink deter-
mina el tipo de ataque a realizar dependiendo de si el Splink está controlando una
criatura o no. El comportamiento del Splink se divide en dos partes, cuando no
está controlando una criatura y cuando si lo está. En el primer caso se manejan los
comportamientos de chase creature, wander y obstacle avoidance. Para
118 E.10. INFORMACIÓN EN PANTALLA

el segundo caso se maneja el comportamientos de chase splink y obstacle


avoidance.

A continuación se explica cada uno de los comportamientos nombrados.

Wander: el personaje determina una posición aleatoria en el área de juego y luego


se mueve hacia allı́.

Obstacle avoidance: cuando el personaje detecta en su ruta un obstáculo, in-


tenta evitarlo.

Chase creature: sucede cuando el Splink no está controlando ninguna criatura


e intenta controlar alguna. Para ello primero elige la criatura más cercana dentro
un rango y luego la persigue.

Chase splink: sucede cuando el Splink está controlando una criatura e intenta
eliminar a los demás Splinks. Para ello primero elige al Splink más cercano dentro
de un rango y luego lo persigue.

E.10 Información en Pantalla


Se describen los elementos de información en pantalla durante el estado de juego
y se explica cómo se implementaron. Estos elementos se separan en dos grupos, los
del Head-up Display (HUD) y los de la escena. Dentro de los elementos del HUD se
encuentran las barras de energı́a vital y energı́a mental del personaje del jugador y el
radar como se pueden apreciar en la Fig.E.13. Dentro de los elementos de escena se
encuentran las barras de energı́a de las criaturas y los Splinks enemigos, la selección de
criatura a controlar y el cı́rculo que denota el rango de control mental del Splink. En el
documento de diseño anexo D se describe cada uno de ellos, en la Fig.E.14 se puede
apreciar el resultado final.
Se sigue el patrón de diseño Model View Controller. Algunos elementos gráficos
se implementaron directamente como subclases de Controller de la API del mo-
tor, agrupando tanto el view como el controller. Otros se separaron teniendo un
controller encargado de actualizar el view a partir de elementos del model (enti-
dades de juego). En la Fig.E.15 se presenta un diagrama de clases reflejando el segundo
caso.

RadarController: se encarga tanto de determinar donde están los personajes


como de dibujar el radar, dibujando un cı́rculo verde para el jugador, un cı́rculo
rojo para cada Splink contrario y un cı́rculo blanco para las criaturas.

CircleRangeController: se encarga de mostrar u ocultar un cı́rculo que deter-


mina el rango de control mental del Splink.

SelectTargetController: se encarga de indicar que criatura tiene selecciona-


da el jugador para ser controlada por su Splink.
ANEXO E. DISEÑO TÉCNICO 119

Figura E.13: Componentes gráficos del HUD

CharacterStatusController: se encarga de actualizar un View determinado


pasándole un conjunto de valores de un personaje (p.ej. la energı́a vital).
SplinkStatusController: similar al anterior pero utilizando datos especı́ficos
del Splink.
BarView: se encarga de dibujar en el HUD una barra a partir de un valor actual
y un valor total y de una interpolación de dos colores, uno para cuando la barra
está llena y otro para cuando está vacı́a.
SceneBarView: igual al anterior pero se dibuja dentro del grafo de escena, como
un bilboard.

E.11 Contenidos
Para los modelos 3D se utilizaron dos formatos, considerando si tienen animaciones
o no. Estos fueron MD5 y OBJ respectivamente. El formato MD5 permite especificar tanto
un mesh2 como las distintas animaciones3 . La carga se hace utilizando la API provista
por el motor para OBJ y una extensión llamada MD5Importer para MD5.
Para las texturas se utilizaron tanto JPG como PNG, el segundo en particular se uti-
lizó para aprovechar la transparencia (p.ej. para las rejas del estadio), ambos formatos
se cargan utilizando la API provista por el motor.
2 Un archivo con extensión .md5mesh que tiene el modelo con su esqueleto.
3 Varios archivos con extensión .md5anim que tienen las posiciones del esqueleto para cada animación.
120 E.11. CONTENIDOS

Figura E.14: Componentes gráficos de la escena

Para los sonidos y bandas sonoras se utilizó el formato OGG, la carga se realizó uti-
lizando la API provista por el motor.

Para la escena se definió un descriptor que especifica donde debe comenzar cada
personaje y con qué propiedades. La carga se hace a través de una clase encargada
de obtener la escena. En particular se realizaron dos implementaciones, una es por
código (fija) y otra a partir de un XML, lo cual permite modificar la escena fácilmente.
Se utilizó la biblioteca XStream [XST09] para implementar la transformación a XML de
la escena de forma transparente.

Para armar el contexto de la aplicación, especificando dependencias y configura-


ciones, se utilizó la biblioteca Spring [SPR09].
ANEXO E. DISEÑO TÉCNICO 121

Figura E.15: Diagrama de clases de los componentes gráficos

E.12 Versionado y Liberaciones


El control de versiones se realizó utilizando la herramienta subversion [Sub08] en
conjunto con la herramienta trac [Tra09]. Para cada iteración del desarrollo se creó un
hito con su nombre (p.ej. sprint1) en la herramienta trac, y dentro de este se agregaron
todas las tareas a desarrollar. Al finalizar, se etiquetó la revisión de código implemen-
tada hasta el momento y se generó una liberación a partir de esta, que luego se publi-
có en la página web. Este proceso se automatizó con el plugin maven-release-plugin
[MAV09b] de maven [Mav09a].
Finalmente, el videojuego fue puesto en producción usando la especificación Java
Networking Launch Protocol (JNLP) para que los usuarios puedan descargarlo vı́a la
tecnologı́a Java Web Start [JAV09]. Esta maneja tanto la descarga del videojuego como
las dependencias correspondientes a la plataforma del usuario final.

E.13 Resumen
En esta sección se presentan, a modo general, caracterı́sticas deseadas que no se im-
plementaron porque no están dentro del alcance. Estas caracterı́sticas están presentadas
en el anexo D.

Ventanas: un sistema de ventanas para navegar entre los distintos estados del
juego que permita por ejemplo personalizar distintos aspectos como los controles
o tipo de personaje.
122 E.13. RESUMEN

Elementos: durante la partida aparecen distintos elementos que permiten modi-


ficar la mecánica de juego como powerups y trampas, entre otros.

Multijugador: se puede jugar de a varios jugadores, ya sea dentro de la red local


o en la misma computadora.
Diversidad: distintos personajes para seleccionar, con distintos comportamientos
y modelos.
Splinks Deathmatch - Evaluación
F
Postmortem

Este anexo presenta una evaluación sobre el videojuego construido indicando las
cosas que salieron mal en la sección F.1, las cosas que salieron bien en la sección F.2
y las lecciones aprendidas en la sección F.3. La estructura seleccionada es la utilizada
por los postmortem publicados en Gamasutra [Gam08a].

F.1 ¿Qué Salió Mal?

En esta sección se explican diversos aspectos negativos ocurridos durante el desa-


rrollo.

Alcance Ambicioso
Dada la poca experiencia en desarrollo de videojuegos y la complejidad de las ca-
racterı́sticas, el alcance resultó demasiado ambicioso. Debido a esto, la caracterı́stica de
jugar desde la red local quedó fuera del prototipo desarrollado. La decisión de quitarla
se toma en mitad del proyecto, por su complejidad y el tiempo que lleva implementarla.
De todas maneras la ocurrencia del problema sirvió para probar como se adapta la
metodologı́a, resultando adecuada para el manejo de los cambios.

Resultado No Divertido
El videojuego en base teórica parece ser divertido, sin embargo, en el prototipo
desarrollado no logramos demostrarlo cómo se esperaba. Esto se debe a que no se
hace foco en la priorización de las caracterı́sticas que agregan diversión al videojuego,
ya que se opta por implementar solo la funcionalidad básica dentro del prototipo. Se
debió tomar en cuenta que un prototipo de videojuego debe ser divertido al momento
de priorizar.

123
124 F.1. ¿QUÉ SALIÓ MAL?

Mala Comunicación entre el Equipo


El haber desarrollado de forma remota llevó a que cada desarrollador trabajara
sobre un componente diferente para evitar superposiciones. Los problemas de comuni-
cación hicieron que se tomaran algunas decisiones sin consultar al resto, afectando al
momento de la integración de los componentes. Este problema pudo ser identificado de
forma temprana gracias a las evaluaciones de cada iteración, pero las soluciones pro-
puestas fueron solo parciales. Se cree que este hecho no habrı́a ocurrido si se hubiese
trabajado en el mismo lugar fı́sico.

Falta de Estándares y Nomenclatura


Dentro de la interacción entre desarrolladores, se notó la falta de estándares de codi-
ficación y nomenclatura, tanto para el código fuente como para nombrar los contenidos
generados y definir donde colocarlos.
Al momento de interactuar con los artistas no definir un estándar para la integración
de los modelos 3D y las animaciones al videojuego, implicó un aumento de tiempo en
la incorporación del arte gráfico. Esta falla fue principalmente por la poca experiencia
de los programadores y artistas gráficos.

Poca Investigación de las Tecnologı́as Seleccionadas


Si bien el motor jMonkeyEngine era el único motor 3D con buenas prestaciones
en Java y con todas las funcionalidades que se necesitaban, la decisión de utilizarlo
fue apresurada y faltó investigar más su arquitectura, leer a fondo la documentación e
implementar algún prototipo.
La documentación en lı́nea del motor no es del todo buena lo que llevó muchas
veces a recurrir a los foros para determinar como resolver uno u otro problema. A veces
resultó confusa y tediosa la programación porque existen funcionalidades innecesarias,
redundantes o fuera de uso en algunos componentes. Además, este motor está en cons-
tante desarrollo (para resolver errores o agregar mejoras) lo cual reduce la estabilidad
de nuestra aplicación si decidimos adaptarnos a las nuevas liberaciones del motor.

Poca Interacción con el Cliente Externo


Durante el proyecto existió poca interacción con el cliente externo lo que trajo como
problemas el atraso del proyecto por diferencias entre lo entregado y lo pretendido por
este. La razón principal para este problema se encuentra en que el rol cumplido por
el cliente externo no fue igual al planteado por la metodologı́a, lo cual implicó que el
equipo también tenga que hacerse cargo del rol. Esta forma de trabajo requerı́a una
mayor comunicación para que la toma de decisiones del equipo se correspondiera con
lo que el cliente externo esperaba y esto no se plasmó.

Dependencia a la Generación de Contenidos


Los contenidos (texturas, modelos y animaciones) se encargaron a un equipo exter-
no al equipo de desarrollo cuyos tiempos y prioridades eran muy diferentes. Algunas
ANEXO F. EVALUACIÓN POSTMORTEM 125

caracterı́sticas no pudieron ser terminadas hasta recibir los contenidos correspondientes


lo cual retrasó la culminación del proyecto. Una posible forma de mitigar este proble-
ma habrı́a sido buscar alternativas para satisfacer nuestras necesidades en este aspecto
y evitar la dependencia.

F.2 ¿Qué Salió Bien?


En esta sección se explican diversos aspectos que determinamos como positivos
durante el desarrollo.

Plataforma de Desarrollo
La plataforma de desarrollo, tanto el entorno como el lenguaje y las herramientas
utilizadas fueron una buena elección, principalmente por la facilidad de adopción frente
a la falta de práctica de los integrantes. Además permitió alcanzar correctamente todas
las plataformas objetivo de la propuesta (Windows, MacOS y Linux).

Decisiones en Conjunto
Este fue uno de los fuertes del proyecto, siempre que se pudo, se tomaron las deci-
siones en conjunto haciendo valer la diversidad de opiniones y discutiendo para llegar
a un consenso.

Blog
La decisión de la creación de un blog tanto para poder actualizar del estado del
videojuego a los potenciales usuarios como para obtener opiniones de estos, se con-
sidera acertada ya que permitió tener una vı́a de comunicación para mejorar el video-
juego. Además motivó al equipo al ver que varios usuarios lo seguı́an o comentaban
las entradas.

Metodologı́a Utilizada
La metodologı́a de desarrollo utilizada resultó fácil de adoptar. Un punto favorable
de su planteo es que el desarrollo mediante iteraciones sirvió para aprender mucho
sobre la marcha, permitiendo evaluar el alcance del proyecto iteración tras iteración y
mejorar en cada uno de los aspectos de la forma de trabajo.

Experiencia Generada
Todos los integrantes del desarrollo aprendieron muchas lecciones a partir de este
proyecto y generaron experiencia tanto para el desarrollo de videojuegos como en el
uso de SUM, lo cual resulta de mucho valor para futuros desarrollos.
126 F.3. LECCIONES APRENDIDAS

F.3 Lecciones Aprendidas


En esta sección se presentan algunas de las lecciones aprendidas en el transcurso
de la ejecución del proyecto.

Seleccionar caracterı́sticas en cada iteración de forma tal que se obtenga un in-


cremento importante que motive al equipo y promueva la respuesta del usuario.
Priorizar la búsqueda de la diversión.
Realizar un esfuerzo importante para conseguir buena comunicación ya que se
determina como un factor clave para minimizar los problemas.

Buscar la opinión de potenciales usuarios durante la fase de elaboración para que


las decisiones se ajusten a lo que espera el público objetivo.
Metodologı́a SUM para Desarrollo de
G
Videojuegos

En este documento se presenta en forma completa la metodologı́a SUM para De-


sarrollo de Videojuegos. Esta se adapta a la realidad del Uruguay de proyectos de corta
duración y equipos multidisciplinarios de pocas personas. Además, comparte las carac-
terı́sticas de las metodologı́as que se utilizan en las empresas uruguayas por ser iterativa
con alto grado de participación del cliente y flexible para adaptarse a los cambios y a
diversos tipos de proyectos.

G.1 Objetivos
La metodologı́a SUM para Desarrollo de Videojuegos tiene como objetivos de-
sarrollar videojuegos de calidad en tiempo y costo, ası́ como la mejora continua del
proceso para incrementar la eficacia y eficiencia de este. Pretende obtener resultados
predecibles, administrar eficientemente los recursos y riesgos del proyecto y lograr una
alta productividad del equipo de desarrollo. SUM fue concebida para que se adapte a
diversos tipos de proyectos con equipos multidisciplinarios pequeños (de dos a siete in-
tegrantes que trabajan en un mismo lugar fı́sico o están distribuidos), de corta duración
(menores a un año) y con alto grado de participación del cliente.

G.2 Roles
La metodologı́a define cuatro roles: Equipo de Desarrollo, Productor Interno, Cliente
y Verificador Beta.

G.2.1. Equipo de Desarrollo


Descripción
El equipo es multidisciplinario, se conforma de Diseñadores de Juego, Progra-
madores, Artistas Gráficos y Artistas Sonoros.

127
128 G.2. ROLES

Tareas Principales
Las tareas de las que este rol es responsable son las siguientes:
Actualizar plan de proyecto
Definir aspectos de juego
Definir aspectos de juego
Definir objetivos y métricas
Desarrollar caracterı́sticas
Entrega final
Especificar caracterı́sticas
Estimar caracterı́sticas
Evaluación postmortem
Evaluar estado del videojuego
Evaluar iteración
Identificar riesgos
Priorizar ajustes
Priorizar caracterı́sticas
Realizar ajustes
Refinar caracterı́sticas

Tareas Adicionales
Las tareas de las que este rol participa en forma adicional son las siguientes:
Definir aspectos de negocios
Definir cronograma
Definir equipo de desarrollo
Definir objetivos del proyecto
Definir presupuesto
Distribuir versión Beta
Monitorear iteración
Planificar iteración
Seleccionar caracterı́sticas
Verificar videojuego
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 129

Artefactos
Los artefactos de los cuales este rol participa en su construcción son los siguientes:

Concepto del juego

Lecciones aprendidas

Lista de cambios priorizados

Listado de riesgos

Mejoras al proceso

Plan del proyecto

Videojuego

G.2.1.1. Artista gráfico


Descripción
El Artista Gráfico crea todo el contenido gráfico del videojuego, incluyendo el arte
de concepto, arte 2D, modelos 3D, animaciones y texturas.
El arte y la animación son gran parte del trabajo requerido para el desarrollo del
videojuego. Las habilidades necesarias para un artista varı́an según los requerimientos
del juego en particular. De cualquier forma requieren conocimientos sobre las últimas
herramientas gráficas, creatividad, talento y técnica.
El Artista Gráfico debe trabajar de cerca con los diseñadores para hacer visibles sus
ideas. También deben colaborar con los programadores ya que son los que integrarán
los gráficos en el juego. Además, los artistas de sonido también se relacionan con su
trabajo ya que los efectos de sonido deben estar sincronizados con las animaciones.
Las habilidades necesarias para llevar a cabo el rol son las siguientes:

Talento creativo, originalidad y fuerte sentido visual.

Sólidos conocimientos de informática.

Tareas Principales
Las correspondientes al rol Equipo de Desarrollo

Tareas Adicionales
Las correspondientes al rol Equipo de Desarrollo

Artefactos
Las correspondientes al rol Equipo de Desarrollo
130 G.2. ROLES

G.2.1.2. Artista sonoro


Descripción
El Artista Sonoro se encarga de crear todos los efectos de sonido y música del
videojuego.
El Artista Sonoro debe tener buen oı́do para poder mezclar sonidos y hacer que
suene bien. Los efectos de sonido deben ser diseñados de forma que se correspondan
con lo que el jugador está viendo. El sonido da vida a la escena y complementa la
experiencia del jugador.
El Artista Sonoro deberá grabar, mezclar y editar sonidos. Además, tendrán que
componer la banda sonora del videojuego.
Las habilidades necesarias para llevar a cabo el rol son las siguientes:
Fuerte y equilibrado oı́do y ser capaz de diferenciar entre sonidos.
Conocimientos musicales.
Comprensión de la música electrónica y acústica.
Capacidad para hacer frente a las largas horas de tensión y las condiciones de
trabajo.
Buena comunicación.

Tareas Principales
Las correspondientes al rol Equipo de Desarrollo

Tareas Adicionales
Las correspondientes al rol Equipo de Desarrollo

Artefactos
Las correspondientes al rol Equipo de Desarrollo

G.2.1.3. Programador
Descripción
El Programador diseña, implementa y verifica el software que compone al video-
juego. El Programador tiene como principal responsabilidad implementar el software
que compone al videojuego. Además, deberá realizar el diseño de software necesario
para poder realizar el desarrollo y posteriormente verificarlo. Por lo tanto el progra-
mador debe tener conocimientos de diseño de software, implementación y verificación.
Las habilidades necesarias para llevar a cabo el rol son las siguientes:

Habilidades para programar.


Debe saber cómo funciona el sistema o aplicación en una prueba.
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 131

Debe estar familiarizado con la tarea de Verificación.

Disfrutar de los videojuegos

Tener habilidades para la solución de problemas.

Buena comunicación.

Trabajar bajo presión.

Tareas Principales
Las correspondientes al rol Equipo de Desarrollo

Tareas Adicionales
Las correspondientes al rol Equipo de Desarrollo

Artefactos
Las correspondientes al rol Equipo de Desarrollo

G.2.1.4. Diseñador de juego


Descripción
El Diseñador de Juego diseña el gameplay, historia, ambientación, personajes, nive-
les y todos los elementos que hacen a la experiencia del jugador. Todos estos factores
determinarán que tan divertido es el juego. Para asegurar la diversión debe mantener
balanceada la dificultad del videojuego y el aprendizaje del jugador.
Debe poder crear videojuegos apuntando especı́ficamente a una plataforma, género
y audiencia. Es importante que se mantenga al dı́a con el género del juego y conozca
bien las fortalezas y debilidades de los productos competidores.
Las habilidades necesarias para llevar a cabo el rol son las siguientes:

Ser creativo y original.

Entender bien el mercado y el público de los videojuegos.

Habilidades para resolver problemas.

Habilidades para narrar historias.

Ser buen comunicador.

Entender las capacidades y beneficios de las distintas plataformas, tecnologı́as y


técnicas de software.

Habilidades básicas de dibujo y diseño 3D.

Adaptarse rápido al cambio.


132 G.2. ROLES

Trabajar bien en equipo.

Trabajar bien bajo presión.

Tomar de buena manera las crı́ticas.

Estar actualizado con los desarrollos y las tendencias del mercado de videojue-
gos.

Tareas Principales
Las correspondientes al rol Equipo de Desarrollo

Tareas Adicionales
Las correspondientes al rol Equipo de Desarrollo

Artefactos
Las correspondientes al rol Equipo de Desarrollo

G.2.2. Productor Interno


Descripción
Encargado de guiar el desarrollo, de promover buenas prácticas y de interactuar con
los clientes.

Tareas Principales
Las tareas de las que este rol es responsable son las siguientes:

Actualizar plan de proyecto

Definir aspectos de juego

Definir aspectos de negocio

Definir aspectos técnicos

Definir cronograma

Definir equipo de desarrollo

Definir objetivos del proyecto

Definir objetivos y métricas

Distribuir versión beta

Entrega final
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 133

Evaluación postmortem
Evaluar estado del videojuego
Evaluar iteración
Planificar iteración
Priorizar ajustes
Priorizar caracterı́sticas
Seleccionar caracterı́sticas
Identificar riesgos
Monitorear riesgos

Tareas Adicionales
Las tareas de las que este rol participa en forma adicional son las siguientes:
Especificar caracterı́sticas
Estimar caracterı́sticas
Priorizar ajustes
Priorizar caracterı́sticas
Refinar caracterı́sticas
Seleccionar caracterı́sticas

Artefactos
Los artefactos de los cuales este rol participa en su construcción son los siguientes:

Acciones a tomar
Aspectos a verificar
Concepto del juego
Lecciones aprendidas
Listado de riesgos
Medidas
Mejoras al proceso
Plan del proyecto
Videojuego
134 G.2. ROLES

G.2.3. Cliente
Descripción
El Cliente es el encargado de especificar y mantener la visión del videojuego es-
perado. Representa los intereses de todos aquellos que se ven materialmente afectados
por los resultados del proyecto.
Durante el proyecto el cliente:
Define y valida el concepto del juego, aprueba los planes de proyecto y determina
los hitos.
Prioriza las caracterı́sticas y tareas que dan más valor al videojuego en cada
momento.
Evalúa el cumplimiento de las tareas y el producto obtenido al finalizar cada
iteración y participa de la evaluación del proyecto.
Prioriza los errores a corregir buscando la mejor calidad posible de acuerdo a sus
intereses.
Valida las versiones del producto.

Tareas Principales
Las tareas de las que este rol es responsable son las siguientes:
Actualizar plan de proyecto
Definir aspectos de juego
Definir aspectos de negocio
Definir aspectos técnicos
Definir cronograma
Definir objetivos del proyecto
Definir objetivos y métricas
Entrega final
Especificar caracterı́sticas
Evaluar estado del videojuego
Planificar iteración
Priorizar ajustes
Priorizar caracterı́sticas
Seleccionar caracterı́sticas
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 135

Tareas Adicionales
Las tareas de las que este rol participa en forma adicional son las siguientes:

Definir presupuesto

Estimar caracterı́sticas

Evaluación postmortem

Identificar riesgos

Monitorear iteración

Verificar videojuegos

Artefactos
Los artefactos de los cuales este rol participa en su construcción son los siguientes:

Concepto del juego

Lista de cambios priorizados

Plan del proyecto

Plan de la iteración

G.2.4. Verificador Beta


Descripción
Son los designados para realizar la verificación funcional del videojuego. Parti-
cipan fundamentalmente en la etapa beta del proyecto, ya que es cuando se obtiene la
primer versión completa del juego. Dependiendo del proyecto es posible que participen
verificadores beta un poco antes de dicha etapa.
Un Verificador Beta puede tener conocimientos y experiencia de verificación de
software o videojuegos. Sin embargo, puede no poseer experiencia ni ser jugador fre-
cuente y participar de la verificación por ejemplo al formar parte de un del videojuego.

Tareas Principales
Las tareas de las que este rol es responsable son las siguientes:

Verificar videojuego

Tareas Adicionales
N/A
136 G.3. PROCESO DE ENTREGA

Artefactos
Los artefactos de los cuales este rol participa en su construcción son los siguientes:

Evaluación y errores encontrados

G.3 Proceso de entrega


El proceso de entrega se divide en fases iterativas e incrementales que se ejecu-
tan en forma secuencial con excepción de la fase de gestión de riesgos que se realiza
durante todo el proyecto. Las cinco fases secuenciales son: Concepto, Planificación,
Elaboración, Beta y Cierre. Estas se aprecian en la Fig.G.1. Las fases de Concepto,
Planificación y Cierre se realizan en una única iteración, mientras que Elaboración y
Beta constan de múltiples iteraciones.

Figura G.1: Fases del proceso

G.4 Fase: Concepto


La fase tiene como objetivo principal definir y acordar el concepto del videojuego.

Descripción
En esta fase se busca definir los aspectos de negocio, técnicos y elementos de juego
sobre el producto a desarrollar. Los aspectos de negocio a decidir involucran los obje-
tivos del proyecto, a que audiencia se apunta y los posibles modelos de negocio. Los
elementos del juego a determinar son las principales caracterı́sticas, la historia, los per-
sonajes, la ambientación y el gameplay. Las decisiones técnicas involucran la elección
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 137

de las herramientas, las tecnologı́as a utilizar y las plataformas para las que se va a
desarrollar.
El concepto se construye entre el Equipo de Desarrollo, el Cliente y el Productor
Interno en forma iterativa a partir de ideas y propuestas de cada una de las partes sobre
los aspectos a definir. Las propuestas se refinan a través de reuniones y se analiza su
factibilidad con pruebas de concepto.
El flujo de actividades de la fase se muestra en la Fig. G.2.

Figura G.2: Fase - Concepto

Consideraciones Clave
Para lograr el acuerdo sobre el videojuego a desarrollar se debe tener el concepto
del juego validado entre las partes involucradas. No es necesario que el concepto
esté definido en forma completa para pasar de fase ya que hay aspectos que se
pueden determinar posteriormente.

El proceso de conceptualización puede llegar a tardar ya que depende de cuan


maduras se tengas las ideas. No se puede programar la inspiración, el concepto
puede aparecer en forma repentina pero lleva un tiempo definirlo. Es preferible
poder explorar el concepto sin tener fechas lı́mites muy cercanas.

G.4.1. Actividad: Desarrollo del Concepto


Descripción
Desarrollar el concepto del videojuego implica la realización de tres tareas para
definir aspectos de negocios, de elementos de juego y técnicos. El concepto se constru-
ye a partir de ideas y propuestas de cada rol involucrado sobre los aspectos a definir.
Las propuestas se refinan a través de reuniones y se analiza su factibilidad con pruebas
de concepto. Estas tres tareas se realizan en paralelo ya que se puede comenzar con
cualquiera de ellas y cada una puede influenciar al resto.
El flujo de tareas de la actividad se muestra en la Fig. G.3.

G.4.1.1. Tarea: Definir aspectos de juego


Descripción
Se determinan los principales aspectos del juego como son: visión, género, game-
play, principales caracterı́sticas, historia y ambientación. Esta tarea involucra también
la posible creación de pruebas de concepto para evaluar las ideas y minimizar el riesgo
138 G.4. FASE: CONCEPTO

Figura G.3: Actividad - Desarrollo del Concepto

de que no sea divertido. Es importante que no se invierta más que el tiempo necesario
para probar la idea.

Roles Responsables
Cliente
Equipo de Desarrollo
Productor Interno

Roles Adicionales
N/A

Entradas Obligatorias
N/A

Entradas Adicionales
Concepto del juego

Salidas
Concepto del juego

Pasos
Proponer ideas: Realizar una instancia en la cual todos puedan discutir y pro-
poner ideas para definir la visión y caracterı́sticas principales del juego. Es re-
comendable realizar bocetos para visualizar las ideas.
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 139

Definir la visión de juego: Describir en forma breve la experiencia que se quiere


crear con el juego, que lo hace excitante y lo diferencia de los demás. La visión
del juego debe responder a las preguntas: ¿Cuáles son los objetivos del juego?,
¿Cómo se logran estos objetivos?, ¿Cuáles son los retos del juego?, ¿En qué lugar
se desarrolla?
Definir género: Identificar el género del juego, este puede estar bien definido o
ser una mezcla de varios géneros conocidos. Es bueno incluir comparaciones con
otros tı́tulos del mismo género.
Definir gameplay: Definir el gameplay identificando el tipo de acciones que el
jugador puede realizar durante el juego. Se recomienda incluir ejemplos.
Definir caracterı́sticas: Listar las principales caracterı́sticas del juego y detallar
por que cada una es importante y cómo se podrán implementar. Se puede incluir
desde avances técnicos hasta estilos artı́sticos.
Definir historia y ambientación: Describir el universo del juego en detalle y ex-
plicar que hace a sus personajes únicos e interesantes. Se incluyen los personajes
principales, sus motivaciones y cómo lograrán sus objetivos o fracasarán en el
intento.
Realizar pruebas de concepto: Realizar pruebas para pulir lo mejor posible el
concepto del juego y minimizar los riesgos de que no sea divertido. Estas prue-
bas pueden ser simulaciones del juego en papel, pruebas con juegos similares,
codificación de prototipos u otro método que permita probar la idea. Es impor-
tante que no se invierta más que el tiempo necesario para probar la idea.

Guı́as Relacionadas
Bocetos
Brainstorming
Pruebas de Concepto

G.4.1.2. Tarea: Definir aspectos técnicos


Descripción
Se eligen los dispositivos de hardware en los que se podrá ejecutar el videojuego,
además de las tecnologı́as y herramientas para realizar la implementación. Se pueden
realizar prototipos técnicos que prueben los aspectos seleccionados para evaluar la
factibilidad de su utilización.

Roles Responsables
Cliente
Equipo de Desarrollo
Productor Interno
140 G.4. FASE: CONCEPTO

Roles Adicionales
N/A

Entradas Obligatorias
N/A

Entradas Adicionales
Concepto del juego

Salidas
Concepto del juego

Pasos
Definir plataformas: Determinar sobre que plataformas va a funcionar el video-
juego.

Definir tecnologı́as y herramientas: Realizar la elección de las herramientas y


las tecnologı́as a utilizar para el desarrollo. Es importante tener en cuenta los
conocimientos y capacidades del equipo.

Definir prototipos técnicos: En caso de requerir evaluar diferentes tecnologı́as se


pueden realizar prototipos técnicos. Estos permiten realizar una selección infor-
mada y mejorar las estimaciones.

Guı́as Relacionadas
N/A

G.4.1.3. Tarea: Definir aspectos de negocio


Descripción
Se decide a que público está orientado y el modelo de negocios a seguir.

Roles Responsables
Cliente

Productor Interno

Roles Adicionales
Equipo de Desarrollo
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 141

Entradas Obligatorias
N/A

Entradas Adicionales
Concepto del juego

Salidas
Concepto del juego

Pasos
Definir modelos de negocio: Definir los mecanismos por los cuales el juego
generará dinero.

Definir tecnologı́as y herramientas:

Definir público objetivo: Definir a que público está orientado el videojuego y


explicar por qué puede ser de interés para este.

Guı́as Relacionadas
Modelos de Negocio

G.5 Fase: Planificación


La fase tiene como objetivo planificar el proyecto

Descripción
La fase de planificación tiene dos objetivos principales, uno es planificar el resto
de las fases del proyecto y el otro especificar las caracterı́sticas a implementar del
videojuego. Para ello se realizan dos actividades cuyos resultados componen el plan
de proyecto. Estas se ejecutan en paralelo ya que las salidas que generan dependen
entre sı́, por ejemplo el cronograma debe ser coherente con el tiempo estimado y para
realizar las caracterı́sticas del videojuego.
Se espera que sea una fase corta que termina cuando se tiene el acuerdo del cliente
sobre los planes y caracterı́sticas definidas. La planificación que se obtiene en esta fase
es flexible ya que en cada iteración de la fase de elaboración se puede modificar para
adaptarse a los cambios y reflejar la situación actual del proyecto.
El flujo de actividades de la fase se muestra en la Fig.G.4.

Consideraciones Clave
N/A
142 G.5. FASE: PLANIFICACIÓN

Figura G.4: Fase - Planificación

G.5.1. Actividad: Planificación Administrativa


Descripción

Esta actividad implica realizar tres tareas con el objetivo de definir diversos ele-
mentos del plan de proyecto. Se ejecutan en paralelo ya que no existe un orden de
ejecución definido. Esto depende de la situación de partida al planificar ya que si uno
o más de estos elementos están definidos previamente, los otros deben ajustarse para
cumplir los requerimientos.
El flujo de tareas de la actividad se muestra en la Fig.G.5.

Figura G.5: Actividad - Planificación Administrativa


ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 143

G.5.1.1. Tarea: Definir objetivos del proyecto


Descripción
Definir los objetivos que se quieren alcanzar al finalizar el proyecto. Para cada
uno de ellos se debe definir un criterio para evaluar su éxito. Es importante plantear
cuáles son los resultados que se esperan obtener ya que estos guiarán el esfuerzo de los
miembros del equipo durante el proyecto.

Roles Responsables
Cliente

Productor Interno

Roles Adicionales
Equipo de desarrollo

Entradas Obligatorias
N/A

Entradas Adicionales
Plan del proyecto

Salidas
Plan del proyecto - Objetivos del proyecto

Pasos
Definir objetivos: Definir los objetivos que guiaran al proyecto. Estos determinan
cuáles son las medidas para el éxito al finalizar el proyecto.

Definir criterios de evaluación: Definir criterios de evaluación que permitan medir


si se alcanzaron los objetivos planteados.

G.5.1.2. Tarea: Definir Equipo de Desarrollo


Descripción
Se conforma el equipo de desarrollo para el resto de las fases. Para esto, a partir del
concepto del videojuego se identifican las necesidades técnicas y artı́sticas requeridas
para la realización del proyecto. De acuerdo a estas y de la conformación actual del
equipo, se seleccionan las personas que van a formar parte del equipo de desarrollo.
Pueden existir cambios en el equipo de las fases anteriores para poder cumplir con las
necesidades detectadas.
144 G.5. FASE: PLANIFICACIÓN

En caso de que existan necesidades que las personas que integran el equipo no
pueden cubrir, estas deben ser cubiertas externamente. Los contratistas externos se de-
terminan dependiendo de la oferta de mano de obra para la necesidad a cubrir y de las
experiencias previas que se hayan tenido con los mismos.

Roles Responsables
Productor Interno

Roles Adicionales
Cliente

Equipo de Desarrollo

Entradas Obligatorias
Concepto del juego

Entradas Adicionales
Plan del Proyecto

Salidas
Plan del Proyecto - Definición del Equipo

Pasos
Identificar necesidades del proyecto: Dado el concepto, identificar que conocimien-
tos y cuantos especialistas se necesitan para cumplir con los requerimientos del
proyecto.

Definir Equipo de Desarrollo: Seleccionar a los miembros del equipo para el


resto del proyecto en base a sus habilidades y necesidades a cubrir.

Definir contratistas externos: Identificar las tareas que el equipo de desarrollo


no podrá realizar, por lo que deben ser tercerizadas. Determinar el contratista
externo que hará el trabajo dependiendo de la oferta de mano de obra para la
tarea a realizar y de la experiencia previa con los este.

G.5.1.3. Tarea: Definir Cronograma


Descripción
Se determina el cronograma para las restantes fases del proyecto en base al con-
cepto del videojuego, los riesgos detectados y el resto de los elementos del plan de
proyecto. El cronograma se conforma con las fechas estimadas para el comienzo de la
fase de elaboración, beta y cierre. Además, incluye la cantidad de iteraciones a realizar
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 145

durante la fase de elaboración junto con sus duraciones y los criterios de finalización
para la fase beta. Una posibilidad para definir este criterio puede ser establecer una
ventana de tiempo determinada durante la cual no aparezcan errores crı́ticos o realizar
determinada cantidad de iteraciones. Se pueden determinar, además hitos intermedios
de avance para cumplir con requisitos del cliente, algo que es común por causa de los
contratos que se realizan en la industria de videojuegos.

Roles Responsables
Cliente

Productor Interno

Roles Adicionales
Equipo de Desarrollo

Entradas Obligatorias
Concepto del juego

Entradas Adicionales
Plan del Proyecto

Salidas
Plan del Proyecto - Cronograma

Pasos
Definir cronograma de elaboración: Definir la cantidad de iteraciones y la du-
ración que tendrán durante la etapa de elaboración.

Definir cronograma de Beta: Se deben definir las iteraciones de la fase beta y los
criterios para su finalización.

Definir cierre del proyecto: Definir la posible fecha de cierre del proyecto.

Definir hitos: Definir los hitos de pasaje de fases y los hitos adicionales requeri-
dos por el cliente. Para cada uno de ellos se debe especificar claramente los
objetivos a alcanzar.

Guı́as Relacionadas
Planning Game
146 G.5. FASE: PLANIFICACIÓN

G.5.1.4. Tarea: Definir Presupuesto

Descripción

Se determina el costo total del proyecto y cómo obtener los recursos económicos
necesarios para realizarlo, de acuerdo al concepto del videojuego y el resto de los as-
pectos del plan de proyecto.
Algunos de los costos que pueden ser tenidos en cuenta son:

Salarios del personal

Hardware

Licencias de software

Costos de contratistas externos

Adquisición de Propiedad Intelectual

Marketing y Relaciones Públicas

Porcentaje de los costos fijos (alquiler de local, viajes, cuentas, etc.)

Roles Responsables

Productor Interno

Roles Adicionales

Equipo de Desarrollo

Cliente

Entradas Obligatorias

Concepto del juego

Entradas Adicionales

Plan del Proyecto

Salidas

Plan del Proyecto - Presupuesto


ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 147

G.5.2. Actividad: Especificación del Videojuego


Descripción
Esta actividad consta de tres tareas que se ejecutan en forma secuencial. Su propósito
es describir, estimar y priorizar cada una de las caracterı́sticas funcionales y no fun-
cionales del videojuego.
Una caracterı́stica funcional representa, en forma similar a una User Story de XP,
una funcionalidad del videojuego desde el punto de vista del usuario final. Al ser
definidas desde este punto de vista, las caracterı́sticas son una excelente herramienta
que tiene el cliente para comunicar al equipo los requisitos del videojuego y medir
el avance durante todo el proyecto. Una caracterı́stica no funcional representa una
propiedad o cualidad que el videojuego debe presentar. Estas caracterı́sticas suelen
referir principalmente a atributos de calidad y a documentos exigidos, entre otros.
El flujo de tareas de la actividad se muestra en la Fig.G.6.

Figura G.6: Actividad - Especificación del Videojuego

G.5.2.1. Tarea: Especificar Caracterı́sticas


Descripción
Se determinan y describen cuáles son las caracterı́sticas funcionales y no fun-
cionales del videojuego tomando como base el concepto. La descripción de cada carac-
terı́stica es breve pero contiene suficiente detalle para poder estimar el tiempo necesario
148 G.5. FASE: PLANIFICACIÓN

para realizarla. También se pueden incluir criterios de evaluación que sirven como he-
rramienta para verificar la caracterı́stica y para eliminar ambigüedades en la definición
de la misma.

Roles Responsables
Cliente
Equipo de Desarrollo

Roles Adicionales
Productor Interno

Entradas Obligatorias
Concepto del juego

Entradas Adicionales
Plan del proyecto

Salidas
Plan del proyecto - Conjunto de Caracterı́sticas del Videojuego

Pasos
Definir caracterı́sticas: Se determinan y describen cuáles son las caracterı́sticas
funcionales y no funcionales del videojuego.
Definir criterios de evaluación: Se definen cuáles son los criterios de aceptación
para comprobar la correctitud y completitud de cada caracterı́stica a realizar en
la iteración. Esto ayuda a eliminar ambigüedades en la definición de la carac-
terı́stica.

Guı́as Relacionadas
Planning Game
Trac

G.5.2.2. Tarea: Estimar Caracterı́sticas


Descripción
Se estima el tiempo que se requiere para realizar las caracterı́sticas definidas. Esti-
mar permite dimensionar el esfuerzo y el tiempo necesarios para completar el video-
juego. Se debe tener en cuenta que no todas las caracterı́sticas tienen por que ser esti-
madas, sin embargo, las más importantes deben ser tenidas en cuenta.
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 149

Roles Responsables
Equipo de Desarrollo

Roles Adicionales
Productor Interno

Cliente

Entradas Obligatorias
Concepto del juego

Plan del Proyecto - Conjunto de Caracterı́sticas del Videojuego

Entradas Adicionales
Plan del proyecto

Salidas
Plan del proyecto - Conjunto de Caracterı́sticas del Videojuego

Guı́as Relacionadas
Estimation Techniques

Agile Estimating

Trac

G.5.2.3. Tarea: Priorizar Caracterı́sticas


Descripción
Se determina la importancia de cada caracterı́stica definida para el videojuego. Prio-
rizar permite determinar el mejor orden en el cual deben ser desarrolladas las carac-
terı́sticas de modo de maximizar el valor del videojuego y minimizar riesgos. El cliente
y el equipo son los encargados de esta tarea, utilizando las caracterı́sticas ya definidas
y estimadas. El cliente prioriza desde el punto de vista del usuario final mientras que el
equipo aporta su visión para priorizar las caracterı́sticas que conllevan un mayor riesgo
técnico.

Roles Responsables
Equipo de Desarrollo

Cliente
150 G.6. FASE: ELABORACIÓN

Roles Adicionales

Productor Interno

Entradas Obligatorias

Concepto del juego

Plan del Proyecto - Conjunto de Caracterı́sticas del Videojuego

Entradas Adicionales

Plan del proyecto

Salidas

Plan del proyecto - Conjunto de Caracterı́sticas del Videojuego

Guı́as Relacionadas

Planning Game

Story Points

Definición de Rangos de Aceptación

Priotizing the backlog

Trac

G.6 Fase: Elaboración

Descripción

El objetivo de esta fase es implementar el videojuego. Para ello se trabaja en forma


iterativa e incremental para lograr una versión ejecutable del videojuego al finalizar
cada iteración.
Con esta forma de trabajo se puede evaluar el avance del proyecto, lo cual permite
realizar cambios a tiempo y tomar decisiones para cumplir con los plazos planificados.
Además, la experiencia adquirida permite mejorar la forma de trabajo en cada iteración
y aumentar la productividad. Se espera que esta fase sea la más extensa de todo el
proyecto.
El flujo de actividades de la fase se muestra en la Fig.G.7.
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 151

Figura G.7: Fase - Elaboración

G.6.1. Actividad: Planificación de la Iteración


Descripción

En esta actividad se crea el plan de la iteración que consta de sus objetivos, las
métricas a utilizar para el seguimiento y las caracterı́sticas a implementar. Consta de
tres tareas que se realizan en forma secuencial una única vez por iteración.
El flujo de tareas de la actividad se muestra en la Fig.G.8.

G.6.1.1. Tarea: Definir bjetivos y métricas

Descripción

Se definen los objetivos y métricas para la iteración. Los objetivos describen que se
pretende lograr al finalizar la iteración y se utilizan para evaluar el éxito de la misma.
Sirven también de guı́a para la toma de decisiones en el transcurso de la iteración.
De acuerdo a los objetivos planteados, las métricas determinan que aspectos medir,
cómo hacerlos y cuáles son los valores esperados para poder monitorear el avance del
proyecto.
152 G.6. FASE: ELABORACIÓN

Figura G.8: Actividad - Planificación de la iteración

Roles Responsables
Cliente

Productor Interno

Equipo de desarrollo

Entradas Obligatorias
Plan del Proyecto - Conjunto de caracterı́sticas del videojuego

Entradas Adicionales
Plan del proyecto

Salidas
Plan de la iteración - Conjunto de caracterı́sticas de la iteración

Plan de la iteración - Métricas

Plan de la iteración - Objetivos de la iteración


ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 153

Pasos
Definir objetivos

Definir métricas

G.6.1.2. Tarea: Seleccionar caracterı́sticas


Descripción
Seleccionar las caracterı́sticas que se van a desarrollar durante la iteración. La se-
lección de las caracterı́sticas se realiza en base a su prioridad y a los objetivos de la
iteración. La suma de los tiempos estimados de las caracterı́sticas seleccionadas no
debe superar la duración de la iteración.

Roles Responsables
Cliente

Roles Adicionales
Productor Interno

Equipo de desarrollo

Entradas Obligatorias
Plan del proyecto - Conjunto de caracterı́sticas del videojuego

Entradas Adicionales
Plan del Proyecto

Salidas
Plan de la iteración - Conjunto de caracterı́sticas de la iteración

Guı́as Relacionadas
Planning Game

Story Points

Estimation Techniques

Release Burndown Chart

Sprint Burndown Chart

Sprint planning meeting


154 G.6. FASE: ELABORACIÓN

G.6.1.3. Tarea: Refinar caracterı́sticas

Descripción

Descomponer las caracterı́sticas del producto planificadas para la iteración en ta-


reas de menor complejidad. Cada caracterı́stica elegida, se divide en tareas de menor
duración lo cual hace más sencillo estimarlas, asignarlas a un miembro del equipo,
identificar desviaciones, verificarlas y evaluar su completitud. Las tareas para desarro-
llo de videojuegos se pueden agrupar de acuerdo a las disciplinas que involucran. Por
ejemplo pueden existir tareas de contenido audiovisual, lógica de juego y desarrollo de
los componentes de software.
Es el equipo de desarrollo quien determina las tareas necesarias para poder cumplir
con las caracterı́sticas por lo cuál se convierten en responsables de su cumplimiento.
Para cada tarea se definen uno o más criterios de evaluación que permitan demostrar
que se ha completado.

Roles Responsables

Equipo de desarrollo

Roles Adicionales

Productor Interno

Entradas Obligatorias

Plan de la iteración - Conjunto de caracterı́sticas de la iteración

Entradas Adicionales

Videojuego

Plan de la iteración - Conjunto de tareas de la iteración

Salidas

Plan de la iteración - Conjunto de tareas de la iteración

Consideraciones Clave

Cada tarea se debe poder realizar en un perı́odo de tiempo corto por una persona.

Guı́as Relacionadas

Etiquetar tareas
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 155

G.6.2. Actividad: Seguimiento de la Iteración


Descripción
Su objetivo es el de mantener la visión y el control de la iteración en base a los
objetivos planteados. Consta de una única tarea que se realiza durante toda la iteración
en la cual se hace el seguimiento de la misma y se toman las acciones necesarias en
caso de ocurrir problemas.
El flujo de tareas de la actividad se muestra en la Fig.G.9.

Figura G.9: Actividad - Seguimiento de la iteración

G.6.2.1. Tarea: Monitorear iteración


Descripción
Su propósito es monitorear el avance de la iteración para detectar problemas e im-
pedimentos que no permitan cumplir con los objetivos planteados. Para ello es nece-
sario definir métricas, registrar medidas y comunicar sus resultados. Se toman las me-
didas y se evalúan las métricas para tener visibilidad sobre el estado de la iteración y
medir la rapidez con la que el equipo avanza hacia completar los objetivos planifica-
dos. En forma permanente se comunica el estado actual para determinar la existencia
de problemas o desvı́os en los objetivos. En caso de que ocurran se registra la causa, se
identifican posibles soluciones y el impacto en los objetivos de la iteración del proyec-
to.
El productor interno realiza el seguimiento y mantiene informado al cliente y al
equipo del avance. Las soluciones a los problemas son acordadas entre los involucra-
dos.

Roles Responsables
Productor Interno

Roles Adicionales
Cliente

Equipo de desarrollo
156 G.6. FASE: ELABORACIÓN

Entradas Obligatorias

Plan de la iteración - Conjunto de caracterı́sticas de la iteración

Plan de la iteración - Conjunto de tareas de la iteración

Plan de la iteración - Métricas

Plan de la iteración - Objetivos de la iteración

Salidas

Medidas

Plan de la iteración - Conjunto de tareas de la iteración

Pasos

Manejar problemas: A través del seguimiento de la iteración y de la comuni-


cación se detectan problemas e impedimentos para progresar. Una vez detectados
se registra la causa, el impacto y se identifican posibles soluciones. Si el proble-
ma es crı́tico o toma mucho tiempo para ser resuelto se ingresa como una tarea en
la lista de tareas de la iteración. Si son desviaciones crı́ticas a los objetivos o se
detecta que los objetivos son inalcanzables, el productor interno puede trabajar
con el equipo y el cliente para renegociar los objetivos de la iteración y enfocarse
en las caracterı́sticas más prioritarias durante lo que resta de la iteración.

Determinar y comunicar el estado actual del proyecto: Determinar el estado ac-


tual del proyecto en base a las medidas registradas respecto a lo planificado para
la iteración. Comunicar al cliente y al equipo el estado y las perspectivas. La
comunicación permite reducir el riesgo de la desconexión entre el equipo y el
cliente y permite actuar más rápido en caso de encontrar problemas.

Registrar medidas: Tomar medidas de la iteración según las métricas definidas.


Las métricas permiten tener visibilidad sobre el estado de la iteración y miden
la rapidez de cómo el equipo avanza hacia completar los objetivos planificados
para la iteración.

Guı́as Relacionadas

Release Burndown Chart

Scrum Daily Meeting

Sprint Burndown Chart


ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 157

G.6.3. Actividad: Desarrollo de Caracterı́sticas


Descripción
Esta actividad consta de una sola tarea en la cual se desarrollan las caracterı́sticas
planificadas para la iteración a través de la ejecución de las tareas que la componen.
El flujo de tareas de la actividad se muestra en la Fig.G.10.

Figura G.10: Actividad - Desarrollo de caracterı́sticas

G.6.3.1. Tarea: Desarrollar caracterı́sticas


Descripción
Se desarrollan y verifican las caracterı́sticas planificadas para la iteración a través
de la ejecución de las tareas que la componen. Para desarrollar una caracterı́stica se
deben completar todas las tareas definidas. Una vez que se completan todas las tar-
eas pendientes de una caracterı́stica, esta se verifica de acuerdo a los criterios de eva-
luación establecidos. En caso de que no cumpla con alguno de los criterios se debe
corregir hasta que lo haga. Los miembros del equipo seleccionan las tareas de acuer-
do a sus capacidades y una vez que el equipo aprueba su elección, son responsables
por el cumplimiento de estas. Al ejecutar una tarea se pueden identificar nuevas tareas
necesarias para completarla, en ese caso se ingresan como nuevas tareas de la iteración.

Roles Responsables
Productor Interno

Equipo de desarrollo

Entradas Obligatorias
Plan de la iteración

Videojuego

Entradas Adicionales
Plan del proyecto
158 G.6. FASE: ELABORACIÓN

Salidas
Videojuego
Plan de la iteración - Métricas

Pasos
Seleccionar tarea: Un miembro del equipo selecciona una de la tareas necesarias
para desarrollar una caracterı́stica y comunica al equipo su decisión. El equipo
aprueba la decisión y quien selecciona la tarea es responsable de que se realice.
Ejecutar tarea: El miembro del equipo ejecuta la tarea de la cual es responsable.
La tarea se considera finalizada cuando cumple con los criterios de aceptación
definidos.
Verificar caracterı́stica: Una vez que se terminan todas las tareas de una carac-
terı́stica, esta se verifica según los criterios de aceptación definidos. Si las prue-
bas son satisfactorias, la caracterı́stica se da por completa. En caso contrario se
crean nuevas tareas para corregir los errores encontrados.

Guı́as Relacionadas
XP Practices

G.6.4. Actividad: Cierre de la Iteración


Descripción
Esta actividad tiene como objetivos evaluar el estado del videojuego y lo ocurrido
en el transcurso de la iteración para actualizar el plan de proyecto a la situación actual.
El flujo de tareas de la actividad se muestra en la Fig.G.11.

G.6.4.1. Tarea: Definir Objetivos y Métricas


Descripción
Mostrar al cliente la versión del videojuego que se obtiene al finalizar la iteración.
Se evalúa la versión del videojuego que se obtiene al finalizar la iteración a partir de
los criterios de evaluación determinados y la opinión del cliente. Con esta evaluación el
cliente puede obtener una medida del estado de cada caracterı́stica planificada para la
iteración. El equipo de desarrollo y el productor interno son los encargados de realizar
la presentación de las caracterı́sticas construidas en la versión actual del videojuego.

Roles Responsables
Cliente
Productor Interno
Equipo de desarrollo
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 159

Figura G.11: Actividad - Cierre de la iteración

Entradas Obligatorias
Videojuego

Plan de la iteración - Conjunto de caracterı́sticas de la iteración

Plan de la iteración - Conjunto de caracterı́sticas del videojuego

Plan de la iteración - Objetivos de la iteración

Salidas
Plan del proyecto - Conjunto de caracterı́sticas del videojuego

Plan de la iteración - Conjunto de tareas de la iteración

Guı́as Relacionadas
Blog

G.6.4.2. Tarea: Evaluar iteración


Descripción
Evaluar el grado de cumplimiento de los objetivos de la iteración. Para los objetivos
que no se alcanzan se debe determinar las causas para evitar que se repitan. Además,
160 G.6. FASE: ELABORACIÓN

se deben identificar otros problemas y dificultades que ocurren durante la iteración y


determinar soluciones para estos.

Roles Responsables
Productor Interno

Equipo de desarrollo

Entradas Obligatorias
Medidas

Entradas Adicionales
Lecciones aprendidas

Mejoras al proceso

Objetivos de la iteración

Salidas
Conjunto de tareas de la iteración

Lecciones aprendidas

Mejoras al proceso

Pasos
Identificar los elementos positivos y negativos: De la experiencia de cada par-
ticipante se extraen los aspectos positivos y negativos que ocurrieron durante la
iteración.

Evaluar el cumplimiento de los objetivos: Según los objetivos de la iteración


evaluar el cumplimiento de cada uno de estos. En caso de no haberse conseguido
se debe estudiar el impacto y las acciones a tomar.

Proponer mejoras al proceso: Proponer soluciones posibles a los problemas de-


tectados e identificar ajustes y mejoras necesarias al proceso. Si las soluciones
son realizables como tareas, se pueden agregar a las tareas de la próxima itera-
ción. Con los problemas identificados y las soluciones se actualizan las lecciones
aprendidas.

Guı́as Relacionadas
Scrum Daily Meeting
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 161

G.6.4.3. Tarea: Actualizar Plan del Proyecto


Descripción
Se actualiza el plan de proyecto para reflejar la situación actual. Todos los elemen-
tos están sujetos a cambios para poder administrar de la mejor manera los problemas
encontrados y los cambios de requerimientos.

Roles Responsables
Cliente
Productor Interno
Equipo de desarrollo

Entradas Adicionales
Plan del proyecto

Salidas
Plan del proyecto

Pasos
Determinar cambios: Determinar los cambios a realizar en el plan del proyecto.
Realizar cambios: Realizar los cambios determinados.

Consideraciones Clave
De acuerdo a los cambios se deben reajustar todos los elementos del plan para que
sea consistente.

G.7 Fase: Beta


Descripción
La fase tiene como objetivos evaluar y ajustar distintos aspectos del videojuego
como por ejemplo gameplay, diversión, curva de aprendizaje y curva de dificultad,
además de eliminar la mayor cantidad de errores detectados. Se trabaja en forma itera-
tiva liberando distintas versiones del videojuego para verificar. En cada ciclo primero
se planifica y distribuye la versión beta para ser verificada. Mientras esta se verifica, se
envı́an reportes con los errores o evaluaciones realizadas. Estos reportes son analizados
para ver la necesidad de realizar ajustes al videojuego.
Se puede optar por liberar una nueva versión del videojuego para verificar una vez
que se realizan los ajustes.El ciclo termina cuando se alcanza el criterio de finalización
establecido en el plan de proyecto.
El flujo de actividades de la fase se muestra en la Fig.G.12.
162 G.7. FASE: BETA

Figura G.12: Fase - Beta

G.7.1. Actividad: Planificación de la Iteración


Descripción
Esta actividad tiene como objetivo planificar diversos aspectos de la iteración y
distribuir efectivamente la versión beta para que sea verificada. Consta de dos tareas
que se ejecutan en forma secuencial, planificar iteración y distribuir versión beta.
El flujo de tareas de la actividad se muestra en la Fig.G.13.

G.7.1.1. Tarea: Planificar Iteración


Descripción
Se definen cuáles son los aspectos funcionales y no funcionales en los que poner
foco durante la verificación, los verificadores beta que evalúan esos aspectos y los
medios por los que se obtiene el videojuego y reportan los resultados. También pueden
ser ajustados, de acuerdo a la situación actual, los criterios de finalización definidos en
el plan de proyecto.
Esta selección se realiza cada liberación de una nueva versión beta permitiendo
ajustar estos elementos para dar flexibilidad a la verificación.

Roles Responsables
Cliente

Productor Interno
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 163

Figura G.13: Actividad - Planificación de la Iteración

Roles Adicionales
Equipo de desarrollo

Entradas Obligatorias
Concepto del juego
Videojuego
Plan del proyecto - Conjunto de caracterı́sticas del videojuego
Plan del proyecto - Objetivos del proyecto

Entradas Adicionales
Evaluación y errores encontrados
Lecciones aprendidas
Lista de cambios priorizados

Salidas
Aspectos a verificar
164 G.7. FASE: BETA

Pasos
Definir aspectos funcionales y no funcionales: Definir que aspectos serán tenidos
en cuenta a la hora de verificar el videojuego.
Definir medios de distribución: Definir cómo será distribuida la versión beta a
los verificadores beta.
Definir cómo se reportan los errores: Definir los medios con los que los verifi-
cadores beta reportarán los errores encontrados.
Definir verificadores beta: Determinar las personas que estarán a cargo de en-
contrar errores a corregir.

Consideraciones Clave
N/A

Guı́as Relacionadas
N/A

G.7.1.2. Tarea: Distribuir Versión Beta


Descripción
La distribución implica definir los medios para hacer llegar la versión a los veri-
ficadores, la forma en que estos comunican los errores y cuáles son los aspectos que
deben verificar.

Roles Responsables
Productor Interno

Roles Adicionales
Equipo de desarrollo

Entradas Obligatorias
Conjunto de caracterı́sticas del videojuego
Videojuego

Entradas Adicionales
N/A

Salidas
Aspectos a verificar
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 165

Pasos
Definir verificadores Beta: Definir las personas que participarán como verifi-
cadores Beta.

Definir medio de comunicación con verificadores: Definir la forma mediante la


cual los verificadores obtienen el videojuego y cómo reportan los resultados de
la verificación.

Definir aspectos a verificar: Definir los aspectos del videojuego en los que se
debe poner foco al realizar la verificación.

Distribuir el videojuego: Hacer llegar el videojuego a los verificadores beta.

Consideraciones Clave
N/A

Guı́as Relacionadas
Blog

Sistema de seguimiento de errores

G.7.2. Actividad: Verificación del Videojuego


Descripción
Esta actividad consta de una única tarea en la cual se verifica la versión beta del
videojuego y se reportan los errores.
El flujo de tareas de la actividad se muestra en la Fig.G.14.

Figura G.14: Actividad - Verificación del videojuego

G.7.2.1. Tarea: Verificar Videojuego


Descripción
Verificar el videojuego poniendo foco en los aspectos funcionales y no funcionales
definidos y reportar los resultados. Los resultados pueden ser errores, por ejemplo fallas
166 G.7. FASE: BETA

en el código, o las impresiones acerca de aspectos como elementos del juego desbalan-
ceados o elementos poco atractivos.

Roles Responsables

Verificador Beta

Roles Adicionales

Cliente

Equipo de desarrollo

Entradas Obligatorias

Aspectos a verificar

Videojuego

Entradas Adicionales

N/A

Salidas

Evaluación y errores encontrados

Pasos

Evaluar y verificar: Evaluar y verificar el videojuego.

Reportar resultados: Reportar al equipo de desarrollo los resultados de la evalua-


ción y los errores encontrados, según los aspectos marcados a verificar.

Consideraciones Clave

N/A

Guı́as Relacionadas

Focus groups
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 167

G.7.3. Actividad: Corrección del Videojuego


Descripción
La actividad tiene como objetivo la corrección del videojuego de acuerdo a los
errores y evaluaciones reportadas en la verificación. Para ello se cuenta con dos tareas
que se ejecutan en paralelo. En una se priorizan y determinan los cambios a realizar y
en otra se realizan los cambios de acuerdo a su prioridad.
El flujo de tareas de la actividad se muestra en la Fig.G.15.

Figura G.15: Actividad - Corrección del videojuego

G.7.3.1. Tarea: Priorizar Ajustes


Descripción
En base a los resultados de la evaluación y verificación del videojuego se debe
definir los cambios a realizar. Estos cambios son priorizados según el impacto y la
importancia que tienen en el videojuego.

Roles Responsables
Cliente

Equipo de desarrollo

Roles Adicionales
Productor Interno
168 G.7. FASE: BETA

Entradas Obligatorias
Evaluación y errores encontrados

Lista de cambios priorizados

Entradas Adicionales
N/A

Salidas
Lista de cambios priorizados

Pasos
Evaluar cambios: En base a los resultados de la evaluación y a los errores encon-
trados se evalúa que cambios hacer al videojuego.

Priorizar cambios: Priorizar los cambios dependiendo del impacto y la importan-


cia que representan para el producto.

Consideraciones Clave
N/A

Guı́as Relacionadas
N/A

G.7.3.2. Tarea: Realizar ajustes


Descripción
Corregir los errores encontrados hasta el momento para eliminar los errores antes
de liberar el juego. El error se debe seleccionar de la Lista de cambios priorizados,
teniendo en cuenta la prioridad del mismo y el costo de corregirlo.
Una vez seleccionado y realizado un ajuste, se debe verificar que fue introducido
con éxito en el videojuego.

Roles Responsables
Equipo de desarrollo

Roles Adicionales
N/A
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 169

Entradas Obligatorias
Lista de cambios priorizados
Videojuego

Entradas Adicionales
N/A

Salidas
Lista de cambios priorizados
Videojuego

Pasos
Seleccionar cambio: Seleccionar un cambio de la lista de cambios priorizados y
comunicar la elección al equipo. Esta elección debe tener en cuenta las capaci-
dades del miembro del equipo y especialmente la priorización del cambio.
Realizar cambio: Realizar el cambio seleccionado.
Verificar: Verificar que el error o aspecto no funcional que el cambio corrige fue
solucionado y que no se ingresaron nuevos defectos.

Consideraciones Clave
N/A

Guı́as Relacionadas
N/A

G.8 Fase: Cierre


Descripción
Sus objetivos son poner a disposición del cliente la versión final del videojuego y
evaluar el desarrollo del proyecto. Se compone de dos actividades que se ejecutan en
forma secuencial, liberación del videojuego y evaluación del proyecto.
El flujo de actividades de la fase se muestra en la Fig.G.16.

G.8.1. Actividad: Liberación del Videojuego


Descripción
Se realiza una única tarea en la que se construye la versión final del videojuego.
El flujo de tareas de la actividad se muestra en la Fig.G.17.
170 G.8. FASE: CIERRE

Figura G.16: Fase - Cierre

Figura G.17: Actividad - Liberación del videojuego

G.8.1.1. Tarea: Entrega Final


Descripción
Dependiendo de la plataforma de distribución del videojuego se deben desarrollar
distintas actividades para la poder comercializar el producto.
El entregable final consiste de el videojuego funcionando con todo su contenido.
También puede incluir documentación y otros productos exigidos por el cliente.
El producto debe ser validado por el cliente para dar por finalizada la tarea.

Roles Responsables
Cliente

Productor Interno
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 171

Equipo de desarrollo

Roles Adicionales
N/A

Entradas Obligatorias
Conjunto de caracterı́sticas del videojuego

Videojuego

Entradas Adicionales
N/A

Salidas
Videojuego

Pasos
Definir entregable: Definir los elementos que componen el entregable final.

Realizar entregable: Realizar las tareas necesarias para incorporar todos los ele-
mentos que contiene el entregable final.

Validar entregable: El cliente recibe el entregable final, lo evalúa y si todo es


correcto pasa a ser la versión final.

Consideraciones Clave
N/A

Guı́as Relacionadas
N/A

G.8.2. Actividad: Evaluación del Proyecto


Descripción
La evaluación del proyecto consiste en una única tarea en la que se identifican
aspectos relevantes que ocurrieron durante el desarrollo del proyecto, se registran las
lecciones aprendidas y se plantean mejoras al proceso.
El flujo de tareas de la actividad se muestra en la Fig.G.18.
172 G.8. FASE: CIERRE

Figura G.18: Actividad - Evaluación del proyecto

G.8.2.1. Tarea: Evaluación Postmortem


Descripción
Se evalúa el proyecto a partir de las medidas tomadas durante el desarrollo, la
gestión de riesgos, la experiencia de cada participante y las evaluaciones realizadas
al finalizar cada iteración de la fase de elaboración.
A partir de estos se identifican los problemas ocurridos, los éxitos conseguidos, las
soluciones halladas, el cumplimiento de objetivos y la certeza de las estimaciones. Las
conclusiones extraı́das se construyen las lecciones aprendidas y se buscan alternativas
para mejorar el proceso.

Roles Responsables
Productor Interno
Equipo de desarrollo

Roles Adicionales
Cliente

Entradas Obligatorias
Lecciones aprendidas
Listado de riesgos
Mejoras al proceso
Métricas

Entradas Adicionales
N/A

Salidas
Lecciones aprendidas
Mejoras al proceso
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 173

Pasos
Evaluar Proyecto: Evaluar lo sucedido durante el desarrollo identificando pro-
blemas ocurridos, éxitos conseguidos, cumplimiento de objetivos y certeza de
las estimaciones.
Registrar lecciones aprendidas: De las conclusiones extraı́das de la evaluación,
registrar las lecciones aprendidas que pueden ser de utilidad en futuros proyectos.
Proponer mejoras a la metodologı́a: Realizar las modificaciones a la metodologı́a
utilizada, de forma que se ajuste mejor al equipo y que prevenga los problemas
enfrentados durante el proyecto.

Consideraciones Clave
Es recomendable que participen todas las personas que han estado involucradas al
proyecto.

Guı́as Relacionadas

G.9 Fase: Gestión de Riesgos


Descripción
Esta fase se realiza durante todo el proyecto con el objetivo de minimizar la ocu-
rrencia y el impacto de problemas. Esto se debe a que distintos riesgos pueden ocurrir
en cualquiera de las fases por lo cual siempre debe existir un seguimiento de los mis-
mos.
El flujo de actividades de la fase se muestra en la Fig.G.19.

Figura G.19: Fase - Gestión de Riesgos

G.9.1. Actividad: Evaluación de Riesgos


Descripción
Consta de dos tareas que se realizan en forma simultánea en el tiempo. La primera
identifica los riesgos en cada momento del proyecto y la segunda se encarga del seguimien-
174 G.9. FASE: GESTIÓN DE RIESGOS

to y de la aplicación de los planes de mitigación y contingencia.


El flujo de tareas de la actividad se muestra en la Fig.G.20.

Figura G.20: Actividad - Planificación de la iteración

G.9.1.1. Tarea: Identificar Riesgos

Descripción

El equipo identifica los riesgos del proyecto, realiza un análisis cualitativo de los
mismos para determinar un orden de magnitud y actualiza el Listado de riesgos. El
productor interno ayuda en la decisión sobre a cuáles riesgos hay que responder y a
cuáles hay que tener en cuenta.
Las respuestas a los riesgos pueden incluir evitarlos o mitigarlos. Dependiendo del
caso, se tendrán que crear tareas especı́ficas durante el proyecto para asegurarse que las
respuestas a los riesgos serán priorizadas y tomadas por el equipo de la misma forma
que las demás tareas del proyecto.
Durante el proyecto, nuevos supuestos y preocupaciones pueden surgir. El equipo
identifica y prioriza nuevos riesgos actualizando la lista de riesgos.
Se debe tener al cliente informado de los riesgos encontrados.

Roles Responsables

Productor Interno

Equipo de desarrollo
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 175

Roles Adicionales
Cliente

Entradas Obligatorias
N/A

Entradas Adicionales
Listado de riesgos

Salidas
Listado de riesgos

Pasos
Identificar riesgos: Identificar los riesgos que afronta el proyecto y describirlos.

Evaluar riesgos: Definir el impacto que tiene el riesgo sobre el desarrollo y la


probabilidad de que ocurra. Definir la forma de medir el riesgo para determinar
en que momento deja de existir en el proyecto.

Determinar estrategias para mitigar los riesgos: Determinar las estrategias a seguir
para mitigar los riesgos.

Establecer planes de contingencia: Realizar un plan de contingencia para los


riesgos que tienen alto impacto en el proyecto. Este plan debe especificar cómo
actuar en caso de que el riesgo ocurra y cuáles son las acciones a tomar para
recuperarse.

Consideraciones Clave
N/A

Guı́as Relacionadas
N/A

G.9.1.2. Tarea: Monitorear Riesgos


Descripción
Se monitorean en forma continua los riesgos identificados para evaluar la probabi-
lidad de que ocurran y la eficacia de las acciones que se toman para mitigarlos.
La evaluación de los riesgos puede implicar la ejecución de nuevas acciones para
evitar que ocurran o, en caso de que sucedan, aplicar los planes de contingencia.
176 G.10. PRODUCTOS DE TRABAJO

Roles Responsables
Productor Interno

Roles Adicionales
N/A

Entradas Obligatorias
Listado de riesgos

Entradas Adicionales
N/A

Salidas
Acciones a tomar

Pasos
N/A

Consideraciones Clave
N/A

Guı́as Relacionadas
N/A

G.10 Productos de Trabajo


Cada producto de trabajo cuenta con su descripción, los roles que lo modifican y las
tareas de las cuales son entradas y salidas. A continuación se presentan los productos
de trabajo de cada tarea divididos por artefactos y salidas.

G.10.1. Artefactos
G.10.1.1. Artefacto: Concepto del Juego
Descripción
Contiene las definiciones sobre que trata el juego, gameplay, caracterı́sticas, histo-
ria, audiencia objetivo, género, herramientas, lenguajes a utilizar y plataforma. El nivel
de detalle de cada definición varı́a de acuerdo a las necesidades del juego a definir.
Puede incluir bocetos de concepto realizados por un artista que definan las ideas sobre
el arte del juego.
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 177

Modificado por
Cliente

Equipo de desarrollo

Productor Interno

Tareas
Entrada a:

• Definir cronograma
• Definir equipo de desarrollo
• Definir presupuesto
• Especificar caracterı́sticas
• Estimar caracterı́sticas
• Priorizar caracterı́sticas
• Definir aspectos de juego
• Definir aspectos de negocios
• Definir aspectos técnicos

Salida de:

• Definir aspectos de juego


• Definir aspectos de negocios
• Definir aspectos técnicos

G.10.1.2. Artefacto: Conjunto de Caracterı́sticas del Videojuego


Descripción
Incluye la especificación, estimación y prioridad de cada una de las caracterı́sticas
que definen el videojuego.
Asociando a cada caracterı́stica el estado en que se encuentra (pendiente, en cur-
so, verificada, finalizada) nos permite seguir la evolución del producto a lo largo del
proyecto.

Modificado por
Cliente

Equipo de desarrollo

Productor Interno
178 G.10. PRODUCTOS DE TRABAJO

Tareas
Entrada a:

• Definir objetivos y métricas


• Distribuir versión Beta
• Entrega final
• Estimar caracterı́sticas
• Evaluar estado del videojuego
• Priorizar caracterı́sticas
• Seleccionar caracterı́sticas

Salida de:

• Especificar caracterı́sticas
• Estimar caracterı́sticas
• Evaluar estado del videojuego
• Priorizar caracterı́sticas

G.10.1.3. Artefacto: Cronograma


Descripción
Es el cronograma del proyecto donde se especifican las fechas de inicio y fin de
cada fase y que hitos se deben cumplir. Además, registra la cantidad de iteraciones que
se realizarán.

Modificado por
Cliente

Productor Interno

Tareas
Salida de:

• Definir cronograma

G.10.1.4. Artefacto: Objetivos del Proyecto


Descripción
Describe los objetivos que se quieren alcanzar al finalizar el proyecto. Para cada
uno se deben determinar criterios de evaluación que permitan medir su éxito.
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 179

Modificado por
Cliente

Productor Interno

Tareas
Salida de:

• Definir objetivos del proyecto

G.10.1.5. Artefacto: Plan del Proyecto


Descripción
Sirve como guı́a para la ejecución y control del proyecto. En el se registran las
principales decisiones acerca de la planificación.
Está compuesto por los artefactos y salidas:

Conjunto de caracterı́sticas del videojuego

Cronograma

Definición del equipo

Objetivos del proyecto

Presupuesto

Modificado por
Cliente

Equipo de desarrollo

Productor Interno

Tareas
Entrada a:

• Actualizar plan del proyecto


• Definir cronograma
• Definir equipo de desarrollo
• Definir objetivos del proyecto
• Definir objetivos y métricas
• Definir presupuesto
• Desarrollar caracterı́sticas
180 G.10. PRODUCTOS DE TRABAJO

• Especificar caracterı́sticas
• Estimar caracterı́sticas
• Priorizar caracterı́sticas
• Seleccionar caracterı́sticas
• Definir objetivos y métricas
• Distribuir versión Beta
• Entrega final
• Estimar caracterı́sticas
• Evaluar estado del videojuego
• Priorizar caracterı́sticas
• Seleccionar caracterı́sticas
Salida de:
• Actualizar plan del proyecto
• Definir cronograma
• Definir equipo de desarrollo
• Definir objetivos del proyecto
• Definir presupuesto
• Especificar caracterı́sticas
• Estimar caracterı́sticas
• Evaluar estado del videojuego
• Priorizar caracterı́sticas

G.10.1.6. Artefacto: Presupuesto


Descripción
Es el calculo de el presupuesto que requiere el proyecto. Se suele se calcular para
cada mes del proyecto.
Algunos de los costos que se registran son:
Salarios del personal
Hardware
Licencias de software
Costos de contratistas externos
Engine royalties
Adquisición de Propiedad Intelectual
Marketing y Relaciones Públicas
Un porcentaje de los costos fijos (alquiler de local, viajes, cuentas, etc.)
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 181

Modificado por
Productor Interno

Tareas
Salida de:

• Definir presupuesto

G.10.1.7. Artefacto: Conjunto de Caracterı́sticas de la Iteración


Descripción
Reúne las caracterı́sticas seleccionadas a ser implementadas durante una iteración.
Cada caracterı́stica se compone de la descripción, la prioridad definida, la estimación de
su duración y el criterio de evaluación definido para determinar el nivel de completitud.

Modificado por
Cliente

Equipo de desarrollo

Productor Interno

Tareas
Entrada a:

• Evaluar estado del videojuego


• Monitorear iteración
• Refinar caracterı́sticas

Salida de:

• Definir objetivos y métricas


• Seleccionar caracterı́sticas

G.10.1.8. Artefacto: Conjunto de Tareas de la Iteración


Descripción
Es el conjunto de tareas que deben ser realizadas para cumplir con las caracterı́sti-
cas de la iteración.
182 G.10. PRODUCTOS DE TRABAJO

Modificado por
Cliente
Equipo de desarrollo
Productor Interno

Tareas
Entrada a:
• Monitorear iteración
• Refinar caracterı́sticas
Salida de:
• Evaluar estado del videojuego
• Evaluar iteración
• Monitorear iteración
• Refinar caracterı́sticas

G.10.1.9. Artefacto: Medidas


Descripción
Las medidas son el registro de los elementos definidos por las métricas durante el
desarrollo. El objetivos es registrar lo ocurrido para diagnosticar problemas y hacer
seguimiento del proyecto.

Modificado por
Productor Interno

Tareas
Entrada a:
• Evaluar iteración
Salida de:
• Monitorear iteración

G.10.1.10. Artefacto: Métricas


Descripción
Una métrica es una medida definida sobre algún aspecto del desarrollo o del pro-
ceso empleado. Permite, previa comparación con valores de referencia o esperados,
obtener conclusiones sobre el aspecto medido. De esta forma se pueden detectar prob-
lemas.
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 183

Modificado por
Cliente

Equipo de desarrollo

Productor Interno

Tareas
Entrada a:

• Evaluación postmortem
• Monitorear iteración

Salida de:

• Definir objetivos y métricas


• Desarrollar caracterı́sticas

G.10.1.11. Artefacto: Plan de la Iteración


Descripción
El plan de la iteración incluye los objetivos y métricas de la iteración, las carac-
terı́sticas a implementar y las tareas a realizar para cumplir con estas últimas.
Está compuesto por los artefactos y salidas:

Conjunto de caracterı́sticas de la iteración

Conjunto de tareas de la iteración

Métricas

Objetivos de la iteración

Modificado por
N/A

Tareas
Entrada a:

• Desarrollar caracterı́sticas
• Evaluación postmortem
• Evaluar estado del videojuego
• Monitorear iteración
• Refinar caracterı́sticas
184 G.10. PRODUCTOS DE TRABAJO

• Evaluar iteración
• Refinar caracterı́sticas

Salida de:

• Definir objetivos y métricas


• Desarrollar caracterı́sticas
• Evaluar estado del videojuego
• Evaluar iteración
• Monitorear iteración
• Refinar caracterı́sticas
• Seleccionar caracterı́sticas

G.10.1.12. Artefacto: Lista de Cambios Priorizados


Descripción
Lista de los cambios a realizar priorizados según el impacto en el producto. Esta
lista es utilizada por el equipo para seleccionar los errores a corregir.

Modificado por
Cliente

Equipo de desarrollo

Tareas
Entrada a:

• Priorizar ajustes
• Realizar ajustes

Salida de:

• Priorizar ajustes
• Realizar ajustes

G.10.1.13. Artefacto: Listado de Riesgos


Descripción
Esta lista identifica, en orden de prioridad decreciente, todos los riesgos asociados
al proyecto. Sirve como punto de foco para las actividades del proyecto y es la base
sobre la cual se organizan las iteraciones.
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 185

Modificado por
Equipo de desarrollo

Productor Interno

Tareas
Entrada a:

• Evaluación postmortem
• Monitorear Riesgos
• Identificar riesgos

Salida de:

• Identificar riesgos

G.10.2. Salidas
G.10.2.1. Salida: Definición del Equipo
Descripción
Registra los integrantes del equipo para el proyecto y que roles cumplen.

Modificado por
Productor Interno

Tareas
Salida de:

• Definir equipo de desarrollo

G.10.2.2. Salida: Lecciones Aprendidas


Descripción
Conjunto de lecciones aprendidas que reflejan los puntos positivos y negativos
del proceso durante el desarrollo del producto, que permiten realizar mejoras y tomar
mejores decisiones si vuelven a ocurrir los mismo problemas.

Modificado por
Equipo de desarrollo

Productor Interno
186 G.10. PRODUCTOS DE TRABAJO

Tareas
Entrada a:

• Evaluación postmortem
• Evaluar iteración

Salida de:

• Evaluación postmortem
• Evaluar iteración

G.10.2.3. Salida: Mejoras al Proceso


Descripción
De la experiencia de seguir el proceso surgen una serie de elementos de mejora. En
cada mejora a realizar se debe explicar que aspecto se apunta a mejorar, si abarca al
proceso o a la forma de trabajo, quien es el responsable de esta mejora, la prioridad y
que tareas son necesarias para llevarla a cabo.

Modificado por
Equipo de desarrollo

Productor Interno

Tareas
Entrada a:

• Evaluación postmortem
• Evaluar iteración

Salida de:

• Evaluación postmortem
• Evaluar iteración

G.10.2.4. Salida: Objetivos de la Iteración


Descripción
Describen brevemente que se pretende de la iteración y sirven de guı́a para las
decisiones a tomar.
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 187

Modificado por
Cliente
Equipo de desarrollo
Productor Interno

Tareas
Entrada a:
• Evaluar estado del videojuego
• Monitorear iteración
• Evaluar iteración
Salida de:
• Definir objetivos y métricas

G.10.2.5. Salida: Videojuego


Descripción
Ejecutable del videojuego con su contenido.

Modificado por
Cliente
Equipo de desarrollo
Productor Interno

Tareas
Entrada a:
• Desarrollar caracterı́sticas
• Distribuir versión Beta
• Entrega final
• Evaluar estado del videojuego
• Realizar ajustes
• Verificar videojuego
• Refinar caracterı́sticas
Salida de:
• Desarrollar caracterı́sticas
• Entrega final
• Realizar ajustes
188 G.10. PRODUCTOS DE TRABAJO

G.10.2.6. Salida: Aspectos a Verificar


Descripción
Son los aspectos funcionales y no funcionales en los que los verificadores beta
deben poner foco.

Modificado por
Productor Interno

Tareas
Entrada a:

• Verificar videojuego

Salida de:

• Distribuir versión Beta

G.10.2.7. Salida: Evaluación y Errores Encontrados


Descripción
Resultado de la evaluación del videojuego y lista de los errores encontrados.

Modificado por
Verificador Beta

Tareas
Entrada a:

• Priorizar ajustes

Salida de:

• Verificar videojuego

G.10.2.8. Salida: Acciones a Tomar


Descripción
Conjunto de acciones a ejecutar para mitigar un riesgo o aplicar un plan de contin-
gencia.

Modificado por
Productor Interno
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 189

Tareas
Salida de:

• Monitorear Riesgos

G.11 Guı́as
Las guı́as son sugerencias, pautas y herramientas para seguir en forma efectiva y
eficaz las actividades que componen el proceso. A través de ellas, se incorporan a la
metodologı́a prácticas aplicadas con éxito para el desarrollo de videojuegos, además de
las lecciones aprendidas con la ejecución de cada proyecto.

G.11.1. Artı́culos
G.11.1.1. Artı́culo: Agile Estimating
Descripción
Artı́culo sobre aspectos relacionados a la estimación utilizando metodologı́as ágiles.

Elementos Relacionados
Estimar caracterı́sticas

G.11.1.2. Artı́culo: Scrum and XP From the Trenches


Descripción
Libro en el que se explica de forma teórico-práctica cómo aplicar Scrum en proyec-
tos reales.

Elementos Relacionados
Definición de rangos de aceptación

G.11.2. Conceptos
G.11.2.1. Concepto: Bocetos
Descripción
Dibujos que representan aspectos del concepto del juego.

Elementos Relacionados
Definir aspectos de juego
190 G.11. GUÍAS

G.11.2.2. Concepto: Brainstorming

Descripción

Es una herramienta de trabajo grupal que facilita el surgimiento de nuevas ideas


sobre un tema o problema determinado, en un ambiente relajado.

Elementos Relacionados

Definir aspectos de juego

G.11.2.3. Concepto: Prueba de Concepto

Descripción

Herramienta utilizada para evaluar y validar ideas.

Elementos Relacionados

Definir aspectos de juego

G.11.2.4. Concepto: Focus Groups

Descripción

En un focus group se reúne a un grupo de personas para indagar acerca de actitudes


y reacciones frente a un producto, servicio, concepto, publicidad, idea o empaque.

Elementos Relacionados

Verificar videojuego

G.11.2.5. Concepto: Risk

Descripción

Un riesgo es cualquier cosa que pueda interponerse en el camino al éxito y es


actualmente desconocido o incierto. Usualmente, un riesgo es clasificado por su pro-
babilidad de ocurrir y el impacto sobre el proyecto si ocurre.

Elementos Relacionados

Listado de riesgos
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 191

G.11.3. Guı́as
G.11.3.1. Guı́a: Etiquetar Tareas
Descripción
Definir etiquetas para las tareas, por ejemplo, “gráficos”, “ia”, “audio”, “diseño”,
“documentación”. Luego, en la etapa de definición de tareas, asignar a cada tarea una
o más de las etiquetas definidas.
De este modo se tiene una categorización de tareas que sirve a los miembros del
equipo hora de seleccionar las tareas a realizar. Además, permite tomar medidas sobre
la proporción de tipos de tareas y tiempos y ayuda a evitar sobrecargar miembros del
equipo que realizan determinados tipos de tarea.

Elementos Relacionados
Refinar caracterı́sticas

G.11.3.2. Guı́a: Product Backlog


Descripción
Es una lista que contiene toda las funcionalidades de el producto. El product back-
log es un artefacto de Scrum.

Elementos Relacionados
Conjunto de caracterı́sticas del videojuego

G.11.3.3. Guı́a: Release Burndown Chart


Descripción
Un burn down chart es una representación gráfica del trabajo que falta por hacer y
del tiempo en un proyecto. El release burndown chart es un artefacto de Scrum.

Elementos Relacionados
Monitorear iteración

Seleccionar caracterı́sticas

G.11.3.4. Guı́a: Scrum Daily Meeting


Descripción
La reunión diaria de Scrum es una reunión rápida que comprende a todos los miem-
bros del equipo y al scrum master.
192 G.11. GUÍAS

Elementos Relacionados
Evaluar iteración
Monitorear iteración

G.11.3.5. Guı́a: Sprint Backlog


Descripción
Es una lista de las tareas que se desarrollarán durante un sprint. El sprint backlog
es un artefacto de Scrum.

Elementos Relacionados
Conjunto de caracterı́sticas de la iteración

G.11.3.6. Guı́a: Sprint Burndown Chart


Descripción
Un burn down chart es una representación gráfica del trabajo que falta por hacer y
del tiempo en un proyecto. El sprint burndown chart es un artefacto de Scrum.

Elementos Relacionados
Monitorear iteración
Seleccionar caracterı́sticas

G.11.3.7. Guı́a: Sprint Planning Meeting


Descripción
La Sprint Planning Meeting es donde el equipo de Scrum y el Product owner deter-
minan que caracterı́sticas y tareas se intentarán realizar en el próximo sprint.

Elementos Relacionados
Seleccionar caracterı́sticas

G.11.4. Ejemplos
G.11.4.1. Ejemplo: Bocetos del Juego Splinks Deathmatch
Descripción
Se presentan los bocetos de concepto generados para el juego Splinks Deathmatch.

Elementos Relacionados
Bocetos
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 193

G.11.4.2. Ejemplo: Concepto del Juego Splinks Deathmatch


Descripción
Se presenta el documento de concepto creado para el juego Splinks DeathMatch.

Elementos Relacionados
Documento de concepto

G.11.4.3. Ejemplo: Blog del Juego Splinks Deathmatch


Descripción
El blog creado para el Splinks Deathmatch de donde se puede seguir el desarrollo
y bajar la última versión del videojuego.

Elementos Relacionados
Blog

G.11.4.4. Ejemplo: Cronograma del Juego Splinks Deathmatch


Descripción
El cronograma realizado para el desarrollo de Splinks Deathmatch.

Elementos Relacionados
Cronograma

G.11.4.5. Ejemplo: Diseño del Juego Splinks Deathmatch


Descripción
Se presenta el documento de diseño creado para el juego Splinks DeathMatch

Elementos Relacionados
Cronograma

G.11.4.6. Ejemplo: Riesgos Splinks Deathmatch


Descripción
Se presenta el listado de riesgos generado para el juego Splinks Deathmatch

Elementos Relacionados
Lista de riesgos
194 G.11. GUÍAS

G.11.5. Plantillas
G.11.5.1. Plantilla: Documento de concepto
Descripción
Un documento que permite registrar las definiciones tomadas en fase de Concepto.

Elementos Relacionados
Concepto del juego

G.11.5.2. Plantilla: Documento de Diseño del Juego


Descripción
El documento de diseño del juego debe tener la representación más actual del todo
lo que hay que conocer sobre las experiencias del jugador en el juego. Esto debe in-
cluir información completa sobre el gameplay, interfaz de usuario, historia, personajes,
inteligencia artificial y otros aspectos del videojuego.

Elementos Relacionados
Conjunto de caracterı́sticas del videojuego

G.11.5.3. Plantilla: Especificación de Caracterı́sticas


Descripción
Planilla excel para registrar la especificación de las caracterı́sticas del videojuego y
mantener la priorización y el estado de cada caracterı́stica.

Elementos Relacionados
Conjunto de caracterı́sticas de la iteración

Conjunto de caracterı́sticas del videojuego

G.11.5.4. Plantilla: Index Cards Product Backlog


Descripción
Se presenta una hoja de cálculo que permite generar un listado de caracterı́sticas
del juego mediante el uso de Index Cards. Las Index Cards son una herramienta para
generar el Product Backlog de scrum.

Elementos Relacionados
Conjunto de caracterı́sticas del videojuego
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 195

G.11.5.5. Plantilla: Plan del Proyecto

Descripción

El plan del proyecto es una guı́a que dice cómo va a ser construido el juego. Se
divide en varias secciones independientes que son Plan de Personal, Plan de Recursos,
Seguimiento de Proyecto, Presupuesto, Cronograma e Hitos y Riesgos.

Elementos Relacionados

Plan del proyecto

G.11.5.6. Plantilla: Lista de Riesgos

Descripción

Una lista o tabla contieniendo los atributos de cada riesgo, un hoja de cálculo puede
ser una buena alternativa para registrar los riesgos.

Elementos Relacionados

Listado de riesgos

G.11.6. Herramientas
G.11.6.1. Herramienta: Blog

Descripción

Es una herramienta que sirve para comunicar el estado del videojuego a los poten-
ciales usuarios, ası́ como obtener sus opiniones y generar un ámbito de discusión sobre
el videojuego.

Elementos Relacionados

Distribuir versión Beta

Evaluar estado del videojuego

G.11.6.2. Herramienta: Trac

Descripción

Es una herramienta web para el manejo de proyectos y seguimiento de errores.


Provee una Wiki integrada, una interfaz para el control de versiones y una serie de
funciones para mantenerse al dı́a con los eventos y cambios del proyecto.
196 G.11. GUÍAS

Elementos Relacionados
Especificar caracterı́sticas

Estimar caracterı́sticas

Priorizar caracterı́sticas

G.11.6.3. Herramienta: Sistema de Seguimiento de Errores


Descripción
Un sistema de seguimiento de errores es una aplicación de software diseñada para
asistir a los verificadores y programadores a realizar el seguimiento de los errores re-
portados.

Elementos Relacionados
Distribuir versión Beta

G.11.7. Material de apoyo


G.11.7.1. Material de apoyo: Modelo de Negocios Adevergaming
Descripción
Se describen el modelo de ingresos de Adevergaming.

G.11.7.2. Material de apoyo: Modelo de Negocios Donaciones


Descripción
Se describen el modelo de ingresos de Donaciones.

G.11.7.3. Material de apoyo: Modelo de Negocios Microtransacciones


Descripción
Se describen el modelo de ingresos de Microtransacciones.

G.11.7.4. Material de apoyo: Modelo de Negocios Móviles


Descripción
Se describen el modelo de ingresos de Móviles.

G.11.7.5. Material de apoyo: Modelo de Negocios Probar antes de comprar


Descripción
Se describen el modelo de ingresos de Probar antes de comprar.
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 197

G.11.7.6. Material de apoyo: Modelo de Negocios Publicidad


Descripción
Se describen el modelo de ingresos de Publicidad.

G.11.7.7. Material de apoyo: Modelo de Negocios Retail


Descripción
Se describen el modelo de ingresos de Retail.

G.11.7.8. Material de apoyo: Modelo de negocios Suscripciones


Descripción
Se describen el modelo de ingresos de Suscripciones.

G.11.7.9. Material de apoyo: Modelo de Negocios Torneos


Descripción
Se describen el modelo de ingresos de Torneos.

G.11.7.10. Material de apoyo: Modelos de Negocios


Descripción
Se describen los modelos de negocio utilizados en la industria de videojuegos.

G.11.7.11. Material de apoyo: Scrum and XP From the trenches


Descripción
Libro en el que se explica de forma teórico-práctica cómo aplicar Scrum en proyec-
tos reales.