Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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
Anexos
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
Estudio del estado del arte de los procesos para desarrollos de videojuegos.
7
8 1.2. PLAN DE TRABAJO
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.
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.
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.
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.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
2.2.8. Móviles
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.
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.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).
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:
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.
ú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.
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
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.
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
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.
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.
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.
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:
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.
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:
al actualizar el progreso, solo contar como completas las caracterı́sticas que están
funcionales en el ejecutable.
31
32 3.1. EMPRESAS RELEVADAS
Figura 3.1: DHL Driving Simulator - Bubbaloo Mix Skating - Arcade Fishing -
SpongeBob Driving Exam - Skimo: Avalancha - Andy and the Secret of Egypt
Figura 3.3: Wild West Wendy - Pirate Poppers - The Lost Cases of Sherlock Holmes -
Brain Spa - Lavender’s Botanicals - Cathy’s Caribbean Club
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.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
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.
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.
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.
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
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).
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
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
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.
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.
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.
lizan en paralelo y durante toda la fase, ya que se puede comenzar con cualquiera de
ellas y cada una puede influenciar al resto.
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.
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.
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 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.
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
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
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.
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.
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
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.
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
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.
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.
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
Evaluación postmortem
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.
Identificar riesgos
CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 57
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
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.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
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
[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.
[c+ 08] Eclipse contributors et al. Open Unified Process (OpenUP). Online, Fecha
de Acceso: Setiembre 2008.
http://epf.eclipse.org/wikis/openup.
[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.
[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
[Mic09] Sun Microsystems. Mobile java. Online, Fecha de Acceso: Abril 2009.
http://www.java.com/es/download/faq/whatis_j2me.xml.
[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.
[Nin08a] Nintendo. What is Nintendo DS? Online, Fecha de Acceso: Mayo 2008.
http://www.nintendo.com/ds/what.
[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
[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/.
[SB01] Ken Schwaber y Mike Beedle. Agile Software Development with Scrum.
Prentice Hall PTR, 2001. ISBN 0-13067-634-9.
72 BIBLIOGRAFÍA
[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/.
[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.
[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.
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.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
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.
81
82 B.2. INFRAESTRUCTURA, TECNOLOGÍAS Y HERRAMIENTAS
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.
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.
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.
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
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.
91
92 C.4. CARACTERÍSTICAS
C.4 Caracterı́sticas
Varios modos de juego: competencia a muerte, sobrevivir el mayor tiempo, cap-
turar banderas, etc.
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.
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.10 Bocetos
A continuación se presentan los bocetos realizados.
94 C.10. BOCETOS
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
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.
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
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.
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 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.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
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
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
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
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.
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.
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
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.
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.
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
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.
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.
Figura E.8: Volumen acotante (en rosado) añadido al esqueleto de la criatura para de-
terminar las colisiones del golpe.
[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.
Possessing: Sucede cuando está controlando una criatura, durante este estado
todas las acciones del Splink son redirigidas hacia la criatura que está controlan-
do.
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.
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
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.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
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.
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
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].
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?
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
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.
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:
Lecciones aprendidas
Listado de riesgos
Mejoras al proceso
Videojuego
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
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:
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
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
Tareas Principales
Las tareas de las que este rol es responsable son las siguientes:
Definir cronograma
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:
Plan de la iteración
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:
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.
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.
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
Guı́as Relacionadas
Bocetos
Brainstorming
Pruebas de Concepto
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.
Guı́as Relacionadas
N/A
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.
Guı́as Relacionadas
Modelos de Negocio
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
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.
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.
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.
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
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:
Hardware
Licencias de software
Roles Responsables
Productor Interno
Roles Adicionales
Equipo de Desarrollo
Cliente
Entradas Obligatorias
Entradas Adicionales
Salidas
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
Roles Responsables
Equipo de Desarrollo
Roles Adicionales
Productor Interno
Cliente
Entradas Obligatorias
Concepto del juego
Entradas Adicionales
Plan del proyecto
Salidas
Plan del proyecto - Conjunto de Caracterı́sticas del Videojuego
Guı́as Relacionadas
Estimation Techniques
Agile Estimating
Trac
Roles Responsables
Equipo de Desarrollo
Cliente
150 G.6. FASE: ELABORACIÓN
Roles Adicionales
Productor Interno
Entradas Obligatorias
Entradas Adicionales
Salidas
Guı́as Relacionadas
Planning Game
Story Points
Trac
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.
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
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
Pasos
Definir objetivos
Definir métricas
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
Descripción
Roles Responsables
Equipo de desarrollo
Roles Adicionales
Productor Interno
Entradas Obligatorias
Entradas Adicionales
Videojuego
Salidas
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
Roles Responsables
Productor Interno
Roles Adicionales
Cliente
Equipo de desarrollo
156 G.6. FASE: ELABORACIÓN
Entradas Obligatorias
Salidas
Medidas
Pasos
Guı́as Relacionadas
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
Roles Responsables
Cliente
Productor Interno
Equipo de desarrollo
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 159
Entradas Obligatorias
Videojuego
Salidas
Plan del proyecto - Conjunto de caracterı́sticas del videojuego
Guı́as Relacionadas
Blog
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.
Guı́as Relacionadas
Scrum Daily Meeting
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 161
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.
Roles Responsables
Cliente
Productor Interno
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 163
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
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 aspectos a verificar: Definir los aspectos del videojuego en los que se
debe poner foco al realizar la verificación.
Consideraciones Clave
N/A
Guı́as Relacionadas
Blog
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
Pasos
Consideraciones Clave
N/A
Guı́as Relacionadas
Focus groups
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 167
Roles Responsables
Cliente
Equipo de desarrollo
Roles Adicionales
Productor Interno
168 G.7. FASE: BETA
Entradas Obligatorias
Evaluación y errores encontrados
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.
Consideraciones Clave
N/A
Guı́as Relacionadas
N/A
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
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.
Consideraciones Clave
N/A
Guı́as Relacionadas
N/A
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
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.
Determinar estrategias para mitigar los riesgos: Determinar las estrategias a seguir
para mitigar los riesgos.
Consideraciones Clave
N/A
Guı́as Relacionadas
N/A
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.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:
Modificado por
Cliente
Equipo de desarrollo
Productor Interno
178 G.10. PRODUCTOS DE TRABAJO
Tareas
Entrada a:
Salida de:
• Especificar caracterı́sticas
• Estimar caracterı́sticas
• Evaluar estado del videojuego
• Priorizar caracterı́sticas
Modificado por
Cliente
Productor Interno
Tareas
Salida de:
• Definir cronograma
Modificado por
Cliente
Productor Interno
Tareas
Salida de:
Cronograma
Presupuesto
Modificado por
Cliente
Equipo de desarrollo
Productor Interno
Tareas
Entrada a:
• 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
Modificado por
Productor Interno
Tareas
Salida de:
• Definir presupuesto
Modificado por
Cliente
Equipo de desarrollo
Productor Interno
Tareas
Entrada a:
Salida de:
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
Modificado por
Productor Interno
Tareas
Entrada a:
• Evaluar iteración
Salida de:
• Monitorear iteración
Modificado por
Cliente
Equipo de desarrollo
Productor Interno
Tareas
Entrada a:
• Evaluación postmortem
• Monitorear iteración
Salida de:
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:
Modificado por
Cliente
Equipo de desarrollo
Tareas
Entrada a:
• Priorizar ajustes
• Realizar ajustes
Salida de:
• Priorizar ajustes
• Realizar ajustes
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:
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
Modificado por
Equipo de desarrollo
Productor Interno
Tareas
Entrada a:
• Evaluación postmortem
• Evaluar iteración
Salida de:
• Evaluación postmortem
• Evaluar iteración
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
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
Modificado por
Productor Interno
Tareas
Entrada a:
• Verificar videojuego
Salida de:
Modificado por
Verificador Beta
Tareas
Entrada a:
• Priorizar ajustes
Salida de:
• Verificar videojuego
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
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
Descripción
Elementos Relacionados
Descripción
Elementos Relacionados
Descripción
Elementos Relacionados
Verificar videojuego
Descripción
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
Elementos Relacionados
Conjunto de caracterı́sticas del videojuego
Elementos Relacionados
Monitorear iteración
Seleccionar caracterı́sticas
Elementos Relacionados
Evaluar iteración
Monitorear iteración
Elementos Relacionados
Conjunto de caracterı́sticas de la iteración
Elementos Relacionados
Monitorear iteración
Seleccionar caracterı́sticas
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
Elementos Relacionados
Documento de concepto
Elementos Relacionados
Blog
Elementos Relacionados
Cronograma
Elementos Relacionados
Cronograma
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
Elementos Relacionados
Conjunto de caracterı́sticas del videojuego
Elementos Relacionados
Conjunto de caracterı́sticas de la iteración
Elementos Relacionados
Conjunto de caracterı́sticas del videojuego
ANEXO G. SUM PARA DESARROLLO DE VIDEOJUEGOS 195
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
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
Descripción
Elementos Relacionados
Especificar caracterı́sticas
Estimar caracterı́sticas
Priorizar caracterı́sticas
Elementos Relacionados
Distribuir versión Beta