Una Metodología Ágil para Desarrollo de Videojuegos

Transcripción

1 INSTITUTO DE COMPUTACIÓN, FACULTAD DE INGENIERÍA - UNIVERSIDAD DE LA REPÚBLICA INFORME DE PROYECTO DE GRADO Una Metodología Ágil para Desarrollo de Videojuegos Autores: Nicolás Acerenza Ariel Coppes Gustavo Mesa Alejandro Viera Tutores: Eduardo Fernández Tomás Laurenzo Diego Vallespir Septiembre 2009

2 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 reducidos 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.

3 Índice General 1 Introducción del Proyecto Plan de Trabajo Publicaciones Organización del Informe Estado del Arte Cadena de Valor Modelos de Ingreso Probar Antes de Comprar Retail Publicidad Advergaming Suscripción Torneos Microtransacciones Móviles Plataformas PC Web Dispositivos Móviles Consolas Tipos de Videojuego Casuales Educativos Hardcore Roles y Disciplinas Arte Sonoro Arte Gráfico Diseño de Juego Programación Producción Verificación Metodologías para Desarrollo de Videojuegos

4 ÍNDICE GENERAL Codificar y Corregir Cascada Metodologías Ágiles Adaptaciones de Metodologías Ágiles para Videojuegos Análisis de las Metodologías para Videojuegos Relevamiento de la Industria de Videojuegos en Uruguay Empresas Relevadas Batovi Game Studio Kef Sensei Mystery Studios Powerful Robot Games Situación Actual Fortalezas Debilidades Oportunidades Amenazas Metodologías de Desarrollo Relevadas Metodología SUM para Desarrollo de Videojuegos Motivación Especificación Objetivos Roles Proceso de Entrega Concepto Planificación Elaboración Beta Cierre Gestión de Riesgos Guías Evaluación de SUM para Desarrollo de Videojuegos Definición Evaluación de Roles Evaluación del Proceso de Entrega Concepto Planificación Elaboración Beta Cierre Gestión de Riesgos Evaluación de Guías Conclusiones y Trabajo Futuro 64

5 4 ÍNDICE GENERAL Anexos A Gestión del Proyecto 78 A.1 Fases y Actividades A.2 Cronograma B Relevamiento 81 B.1 Historia B.1.1 Batovi Game Studios B.1.2 Kef Sensei B.1.3 Powerful Robot Games B.1.4 Mystery Studios B.2 Infraestructura, Tecnologías y Herramientas B.2.1 Batovi Game Studios B.2.2 Kef Sensei B.2.3 Powerful Robot Games B.2.4 Mystery Studios B.3 Aspectos de Negocio B.3.1 Batovi Game Studios B.3.2 Kef Sensei B.3.3 Powerful Robot Games B.3.4 Mystery Studios B.4 Equipos de Trabajo B.4.1 Batovi Game Studios B.4.2 Kef Sensei B.4.3 Powerful Robot Games B.4.4 Mystery Studios B.5 Metodología de Desarrollo B.5.1 Batovi Game Studios B.5.2 Kef Sensei B.5.3 Powerful Robot Games B.5.4 Mystery Studios C Splinks Deathmatch - Documento de Concepto 91 C.1 Visión C.2 Género C.3 Mecánica de Juego C.4 Características C.5 Ambientación C.6 Historia C.7 Público Objetivo C.8 Plataforma Objetivo C.9 Tecnologías y Herramientas C.10 Bocetos D Splinks Deathmatch - Documento de Diseño de Juego 98

6 ÍNDICE GENERAL 5 D.1 Mecánica de Juego D.1.1 Personajes D.1.2 Elementos Coleccionables D.1.3 Elementos de la Escena D.1.4 Modos de Juego D.2 Interacción con el Usuario D.2.1 Cámaras D.2.2 Controles D.2.3 Información en Pantalla D.2.4 Pantallas D.3 Personajes D.3.1 Splink D.3.2 Criaturas D.4 Escenarios E Splinks Deathmatch - Documento de Diseño Técnico 106 E.1 Tecnologías Seleccionadas E.1.1 Generación de Contenidos E.1.2 Implementación E.2 Estados del Juego E.3 Escena E.4 Controles E.5 Sombras E.6 Colisiones E.7 Máquina de Estados E.8 Controladores y Componentes E.9 Inteligencia Artificial E.10 Información en Pantalla E.11 Contenidos E.12 Versionado y Liberaciones E.13 Resumen F Splinks Deathmatch - Evaluación Postmortem 123 F.1 Qué Salió Mal? F.2 Qué Salió Bien? F.3 Lecciones Aprendidas G Metodología SUM para Desarrollo de Videojuegos 127 G.1 Objetivos G.2 Roles G.2.1 Equipo de Desarrollo G.2.2 Productor Interno G.2.3 Cliente G.2.4 Verificador Beta G.3 Proceso de entrega G.4 Fase: Concepto

7 6 ÍNDICE GENERAL G.4.1 Actividad: Desarrollo del Concepto G.5 Fase: Planificación G.5.1 Actividad: Planificación Administrativa G.5.2 Actividad: Especificación del Videojuego G.6 Fase: Elaboración G.6.1 Actividad: Planificación de la Iteración G.6.2 Actividad: Seguimiento de la Iteración G.6.3 Actividad: Desarrollo de Características G.6.4 Actividad: Cierre de la Iteración G.7 Fase: Beta G.7.1 Actividad: Planificación de la Iteración G.7.2 Actividad: Verificación del Videojuego G.7.3 Actividad: Corrección del Videojuego G.8 Fase: Cierre G.8.1 Actividad: Liberación del Videojuego G.8.2 Actividad: Evaluación del Proyecto G.9 Fase: Gestión de Riesgos G.9.1 Actividad: Evaluación de Riesgos G.10 Productos de Trabajo G.10.1 Artefactos G.10.2 Salidas G.11 Guías G.11.1 Artículos G.11.2 Conceptos G.11.3 Guías G.11.4 Ejemplos G.11.5 Plantillas G.11.6 Herramientas G.11.7 Material de apoyo

8 1 Introducción En este capítulo se describe el alcance y objetivos del proyecto de grado. En la sección 1.1 se presenta la definición del proyecto y su contexto junto con los objetivos y el resultado esperado. En la sección 1.2 se muestra el plan de trabajo a seguir. Por último, en la sección 1.4 se describe la organización de este informe. 1.1 del Proyecto Un videojuego, según Wolf [Wol07], es un programa de computación creado para el entretenimiento en el que existe interacción entre una o varias personas y un aparato electrónico. Los elementos que se esperan encontrar son: conflicto contra un oponente o contra las circunstancias, reglas que determinan qué se puede hacer y qué no, el uso de las habilidades del jugador (p.ej. destreza, estrategia o suerte) y un resultado valorado (p.ej. obtener la mayor puntuación o realizar una tarea en el menor tiempo). El desarrollo de un videojuego es una actividad multidisciplinaria que involucra, entre otros, al desarrollo de software y a la creación audiovisual. El proceso de desarrollo consta de sus propias etapas diferentes a las del software tradicional y al tener objetivos difíciles de medir, como la diversión, construirlos constituye un gran desafío. Este proyecto se enmarca en las actividades de los grupos de Ingeniería de Software y del Centro de Cálculo. Tiene como objetivo proponer una metodología para el desarrollo de videojuegos afín con los requerimientos de la industria en el Uruguay. Para ello, es necesario relevar el estado del arte de la ingeniería software en el desarrollo de videojuegos y las distintas metodologías y procesos de desarrollo usados por las empresas de videojuegos de la industria local. Se espera también evaluar la metodología propuesta utilizándola en la implementación de un prototipo de videojuego. Como resultado se espera obtener: Estudio del estado del arte de los procesos para desarrollos de videojuegos. Relevamiento sobre los procesos de desarrollos de videojuegos en la industria nacional, sus principales carencias, necesidades y virtudes. Propuesta de un proceso adecuado para la industria nacional (grupos humanos reducidos, proyectos de pocos meses de duración, etc.). 7

9 PLAN DE TRABAJO Evaluación de la metodología propuesta. Sitio web con la metodología propuesta. Artículo con los principales resultados. 1.2 Plan de Trabajo Al comienzo del proyecto se establecen las principales fases y los hitos a alcanzar. Las actividades que se realizan no se planifican antes de comenzar el proyecto, sino que se van definiendo durante el transcurso de este. Las fases que se definen son: Relevamiento de la Industria de Videojuegos en Uruguay: entrevistar a representantes de las principales empresas uruguayas dedicadas al desarrollo de videojuegos y analizar sus características, metodologías y proceso de desarrollo. Relevamiento del Estado del Arte: investigar la industria de videojuegos y en particular la ingeniería de software aplicada a su desarrollo. Definición del Alcance: determinar la metodología a realizar en base a las características y necesidades detectadas en la industria uruguaya y a lo relevado en el estado del arte. Construcción de la Metodología: construir una metodología para desarrollo de videojuegos de acuerdo al alcance definido. Caso de estudio: construir un prototipo de videojuego utilizando la metodología propuesta. Análisis y Ajustes: analizar la ejecución del caso de estudio para detectar las virtudes y carencias de la utilización de la metodología propuesta y realizarle ajustes. Documentación: documentar los principales resultados obtenidos. 1.3 Publicaciones Como parte del trabajo del proyecto de grado se publica un reporte técnico del Pedeciba-Informática y un artículo en el Simposio Argentino de Ingeniería de Software de las Jornadas Argentinas de Informática e Investigación Operativa. Acerenza, N., Coppes, A., Mesa, G., Viera, A., Fernández, E., Laurenzo, T., Vallespir, D. Una Metodología para Desarrollo de Videojuegos: Versión Extendida. Facultad de Ingeniería, Universidad de la República, RT PEDECIBA- InCo, ISSN , Montevideo, Uruguay, Julio, 2009.

10 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 , Mar del Plata, Argentina, Agosto, Organización del Informe El resto del presente informe tiene como objetivo presentar la metodología desarrollada, los elementos utilizados para su creación y un análisis de su ejecución mediante un caso de estudio. En el capítulo 2 se introducen los principales conceptos sobre videojuegos y el estado del arte en ingeniería de software aplicada a este tipo de desarrollos. En el capítulo 3 se presenta el análisis del relevamiento realizado en la industria de videojuegos del Uruguay haciendo hincapié en las metodologías utilizadas para el desarrollo. En el capítulo 4 se define la metodología para desarrollo de videojuegos propuesta. En el capítulo 5 se analizan los principales resultados obtenidos en la aplicación de la metodología en un caso de estudio y los ajustes realizados luego de la evaluación. Se finaliza el informe con el capítulo 6 que presenta las conclusiones del proyecto y las posibles líneas de trabajo futuro en el área. En forma adicional se entregan los siguientes anexos: Anexo A: cronograma de ejecución del proyecto de grado junto con las principales tareas realizadas. Anexo B: análisis del relevamiento realizado en cada una de las empresas visitadas. Anexo C: concepto y motivación del Splinks Deathmatch. Anexo D: diseño de juego del Splinks Deathmatch. Anexo E: documento de diseño técnico del Splinks Deathmatch que detalla todas las decisiones de diseño tomadas. Anexo F: evaluación postmortem del videojuego construido que resume los aspectos positivos y negativos ocurridos durante su desarrollo junto con las lecciones aprendidas. Anexo G: especificación completa de la metodología SUM para Desarrollo de Videojuegos, tal como se describe en el sitio web

11 2 Estado del Arte En este capítulo se presentan los principales conceptos sobre videojuegos necesarios para la comprensión del resto del documento. Las dos primeras secciones presentan los aspectos de negocio más importantes para comprender cómo funciona la industria de videojuegos. En la sección 2.1 se muestra la cadena de valor de la industria, mientras que en la sección 2.2 se introducen los modelos de ingreso existentes para comercializar videojuegos. En la sección 2.3 se detallan las principales plataformas para las que se desarrollan videojuegos. En la sección 2.4 se caracterizan los tipos de videojuego de interés para nuestro trabajo. En la sección 2.5 se presentan las diferentes disciplinas y roles involucrados en el desarrollo de videojuegos. Por último, en la sección 2.6 se describen y analizan las metodologías utilizadas actualmente. 2.1 Cadena de Valor La industria de los videojuegos está en continuo crecimiento desde hace varios años, el mercado de Estados Unidos en el tuvo un crecimiento del 22% [ESA08] y el mercado europeo en el tuvo un crecimiento del 15% [ade09]. En Estados Unidos las ventas de videojuegos del año 2007 fueron de 9.5 billones de dólares [ESA08] sobrepasando a la industria cinematográfica, como ocurre desde hace varios años. El 40% de los europeos pasan entre seis y catorce horas a la semana jugando videojuegos [ISF07]. Esta industria es similar en su estructura de negocios a otras industrias creativas como la editorial, la cinematográfica y la discográfica, ya que se basa en la creación, publicación y distribución de productos de propiedad intelectual (obras o títulos) [ADV04]. Para representar a las diversas etapas que un producto atraviesa en su camino al consumidor final se utiliza una cadena de valor. Su nombre se debe a que cada eslabón le agrega valor al producto o servicio final. En la Fig.2.1 se aprecia la cadena de valor de la industria de los videojuegos [WR06] y la manera en que sus miembros interactúan. La cadena comienza cuando los desarrolladores crean un nuevo videojuego. Este proceso involucra la contribución de diseñadores de juego, productores, programadores, artistas gráficos, artistas sonoros y otros. Lo que producen los desarrolladores es el videojuego listo para pasar al siguiente nivel en su camino al consumidor final. Esta es

12 CAPÍTULO 2. ESTADO DEL ARTE 11 Figura 2.1: Cadena de Valor de la Industria de Videojuegos típicamente una de las etapas más competitivas dado que hay muchos desarrolladores y solo algunos videojuegos llegan a ser exitosos. Existen tres eslabones que le brindan servicios o herramientas a los desarrolladores: subcontratistas, proveedores de herramientas y fabricantes de consolas. Los subcontratistas son individuos o compañías que se especializan en diferentes áreas de contenido creativo y que son subcontratados por los desarrolladores para realizar 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 construcció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, editores 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 licencia por cada copia manufacturada. Estas empresas mantienen un estricto control sobre qué títulos obtienen la licencia, haciendo de las consolas un mercado altamente controlado y hermético. En el siguiente eslabón en la cadena se encuentran los publishers, que juegan un rol

13 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 publishers 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. Tradicionalmente los retailers son las tiendas y supermercados que venden videojuegos. En algunos 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 potencial 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 consumidores. 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 videojuego. 2.2 Modelos de Ingreso A continuación se presentan los principales modelos de ingreso que se utilizan en la industria de videojuegos y se describen sus características, fortalezas y debilidades. Esta sección se basa principalmente en la serie de artículos sobre el mercado de los videojuegos presentados por Owain Bennallack [Cas08] Probar Antes de Comprar Los consumidores pueden jugar una demo limitada por algún mecanismo (p.ej. tiempo, funcionalidades y cantidad de ejecuciones). Mientras transcurre el videojuego se sugiere comprar la versión completa (up-sell) y una vez que expira la demo se debe efectuar la compra para continuar jugando [Ben08b]. Una variante común es ofrecer una versión web gratuita que se ejecuta en el navegador. Estas versiones pueden ser jugadas cuantas veces quiera el usuario pero tienen menos funcionalidades, menor contenido y baja calidad de sonidos y gráficos comparados con la versión completa para descargar. Las ganancias típicas de un desarrollador van desde el 20% al 50% sobre la venta. Una forma de medir el éxito de un videojuego es observar la tasa de conversión, esto es,

14 CAPÍTULO 2. ESTADO DEL ARTE 13 el porcentaje de pruebas que se convierten en ventas. Generalmente esta tasa es baja, 1% se considera buena y si se encuentra por encima del 2% se considera excelente. La mayor ventaja de este modelo es que permite al consumidor probar el videojuego antes de comprarlo. Cuando la compra requiere de un pago electrónico tiene la desventaja de que los menores de edad pueden no tener acceso. Otro problema es que hay mucho material en esta modalidad, por lo cual los consumidores pueden disfrutar de una gran cantidad de contenido sin que los desarrolladores obtengan ganancia. Solo unos pocos videojuegos logran ganancias significativas, por lo que los desarrollos suelen ser financiados externamente minimizando el riesgo económico del desarrollador y reduciendo sus ganancias 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 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 efectiva 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úblico 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 Advergaming Un patrocinador financia total o parcialmente el desarrollo del videojuego para promocionar una marca, producto o mensaje [WR06]. La diferencia con Publicidad es que

15 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á enteramente 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 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 fidelizació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 desarrolladores 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 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 modelo 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,

16 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 Microtransacciones Se distribuye el videojuego en forma gratuita o por un precio bajo y luego se cobra a los jugadores por complementos que se quieran incorporar (p.ej. nuevos niveles, armas o mejoras en los personajes) [Ben08f]. Los consumidores perciben los complementos como un beneficio y no como un costo, e incluso puede convertirse en una entrada de dinero recurrente mientras se siga creando nuevo contenido. Este modelo permite abatir la piratería ya que la fuente principal de ingresos no es la venta del videojuego sino la de los complementos y se puede tener un control mucho más estricto sobre estos. En comparación con Retail, este modelo permite profundizar el vínculo con el jugador lo que puede llevar a una mayor ganancia con el tiempo. Sin embargo, no genera ganancias rápidamente sino que depende de las microtransacciones que se realicen. Una de las dificultades es la necesidad de contar con un sistema de administración de las cuentas de usuario más sofisticado que en otros modelos de ingreso. También es difícil evaluar el valor de una nueva característica ya que los jugadores se pueden sentir estafados si son más costosas de lo que ellos consideran apropiado Móviles Se realiza la compra del videojuego al acceder al portal de un operador a través de un Dispositivo Móvil [Ben08e]. El videojuego puede ser utilizado tanto tiempo como el usuario posea el dispositivo. Una ventaja es que el pago se realiza a través del operador, como usualmente se pagan el resto de los servicios del Dispositivo Móvil, por lo que el usuario se siente cómodo con esta modalidad. Un problema es que tienen poca exposición debido a que se debe lograr que el videojuego sea descargado solo por el nombre y una foto. Los más exitosos consiguen ser descargados poco tiempo después de su salida al mercado y luego sus ventas bajan drásticamente. Por esta corta duración de los títulos es que se destinan pocos fondos para el desarrollo, por lo que deben ser realizados rápidamente y sin poner el foco en la calidad o la innovación [WMR + 05]. En este modelo se agregan nuevos eslabones a la cadena de valor para llegar al usuario final, como son los operadores y los fabricantes de dispositivos móviles. Por lo tanto, el valor que paga el consumidor se divide entre muchos intermediarios reduciendo las ganancias del desarrollador.

17 PLATAFORMAS 2.3 Plataformas A continuación se presentan las características más relevantes de las plataformas para las que se desarrollan videojuegos, específicamente: PC, Web, Dispositivos Móviles y Consolas 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 último 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 videojuego. 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 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 Dispositivos Móviles Son videojuegos que se desarrollan para teléfonos celulares o PDAs. Estos dispositivos son portátiles y están en red, dos características muy atractivas. Las tecnologías más utilizadas en el desarrollo son J2ME [Mic09], BREW [QUA09] y Symbian OS [Fou09]. En la actualidad, existen aproximadamente millones de celulares en el mundo [Onl08], esto convierte a los Dispositivos Móviles en un mercado muy atractivo para el desarrollo de videojuegos. Entre las principales ventajas se encuentran que requieren

18 CAPÍTULO 2. ESTADO DEL ARTE 17 pocos recursos para su desarrollo y los proyectos tienen una duración corta, de uno o dos meses. Como desventaja, se debe portar el videojuego a una gran variedad de tipos de dispositivos para poder abarcar el mayor público posible, lo cual es complejo y costoso ya que cada modelo tiene características diferentes 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 consola 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 Community [Cor08c] y XNA Creators Club [Cor08a] que permiten publicar videojuegos para ser descargados desde la Xbox 360 y además proveen herramientas de desarrollo para esta consola y Windows. 2.4 Tipos de Videojuego A continuación se presentan algunos tipos de videojuego de interés para nuestro trabajo. Para cada uno se describen los modelos de ingreso y plataformas que se suelen utilizar, la intención, el público objetivo y los géneros más comunes. Estas descripciones se basan en la International Game Developers Association (IGDA) [WR06] 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 relajarse 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á incrementando 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 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-

19 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 Hardcore Estos videojuegos presentan complejidad en el control y en el aprendizaje, innovació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 Suscripció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. aventuras, deportes y pelea). 2.5 Roles y Disciplinas Dentro de las disciplinas involucradas en el desarrollo de videojuegos se encuentran la generación de contenidos audiovisuales (p.ej. bandas sonoras y modelos 3D), diseño de juego y desarrollo de software, entre otros. En esta sección se describen las principales disciplinas involucradas en el desarrollo de un videojuego [IGD08]. Para cada una de estas se define el rol asociado y se presentan algunas áreas específicas según las distintas habilidades requeridas. Se debe notar que las áreas presentadas no se desarrollan necesariamente en todos los proyectos Arte Sonoro El arte sonoro involucra todas las características relacionadas al audio del videojuego. Entre las habilidades necesarias se encuentran, por ejemplo, tener conocimientos de formatos de audio e instrumentos musicales. Además, es importante la colaboración con otras disciplinas ya que el audio debe estar coordinado con el área visual y la lógica para lograr una buena experiencia de juego. Se denomina artista sonoro al rol asociado a esta disciplina. Las áreas específicas relacionadas son: Ingeniería de sonido: creación de todo el material de audio en el videojuego, excepto la música. Se generan, editan, y comprimen los efectos sonoros para los elementos del videojuego (p.ej. los sonidos que produce un personaje al realizar una acción). Composición: composición de las bandas sonoras del videojuego en el formato que se requiera. Además, se define el estilo musical y las transiciones de la música para cada uno de los estados o pantallas.

20 CAPÍTULO 2. ESTADO DEL ARTE Arte Gráfico En esta disciplina se desarrollan todas las características relacionadas con el contenido visual del videojuego. Entre las habilidades requeridas se encuentran, por e- jemplo, diseño gráfico y modelado 3D de objetos. Se denomina artista gráfico al rol asociado a esta disciplina. Las áreas específicas relacionadas al arte gráfico son: Arte de concepto: definición de la estética del videojuego. Se crean bocetos de los personajes y del ambiente para dar vida a la visión de los diseñadores de juego. Estos bocetos guían a los artistas gráficos durante el desarrollo para mantener la coherencia de estilos. Es necesario contar con la habilidad para generar imágenes de calidad rápidamente. Modelado: construcción de los modelos de personajes y objetos del videojuego (p.ej. un animal o un árbol). Para los personajes se requiere conocer de anatomía humana o animal para hacerlos creíbles y de animación para que se puedan mover naturalmente. Para los objetos se requiere entrenamiento en diseño industrial o mecánico para conocer el balance, los materiales y la física de cada elemento. Animación: construcción de las animaciones que dan vida a los personajes a partir de las acciones que estos pueden realizar. Texturizado: creación de las texturas visibles que cubren los modelos tridimensionales y los escenarios en el videojuego. Se requieren habilidades de fotografía y de diseño gráfico Diseño de Juego Esta disciplina involucra el diseño y especificación del gameplay definiendo las reglas, modos de juego, escenarios, historia y personajes con sus capacidades y reacciones. El objetivo principal al momento del diseño es lograr la diversión, para lo que se debe balancear la dificultad y ajustar las distintas propiedades del gameplay. Entre las habilidades necesarias se encuentra el tener un amplio conocimiento sobre videojuegos y en particular sobre todos los elementos que hacen a su diseño. También es necesario tener buenas habilidades de comunicación y conocimiento sobre las disciplinas de arte, sonido y programación para poder interactuar en forma efectiva. Se denomina diseñador de juego al rol asociado a esta disciplina. Las áreas específicas relacionadas al diseño de juego son: Diseño de juego: definición de las acciones que puede tomar el jugador, las reglas, los personajes y los modos en que se juega el videojuego. Diseño de niveles: construcción de los niveles del juego, generando los escenarios 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.

21 METODOLOGÍAS PARA DESARROLLO DE VIDEOJUEGOS 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 creaciones al videojuego. Se denomina programador al rol asociado a esta disciplina. Las áreas específicas relacionadas son: Programación de lógica: diseño, implementación y verificación de las características que definen el videojuego. Estas características incluyen desarrollar la física, los elementos que componen el gameplay, la interfaz gráfica y la inteligencia artificial, entre otros. Programación de contenido: integración del contenido audiovisual al videojuego. Esto involucra implementar efectos, desarrollar partes del motor gráfico, optimizar la compresión de video, desarrollar shaders y algoritmos de animación en tiempo real, reproducir y mezclar sonidos en respuesta a eventos del videojuego y reproducir música interactiva, entre otros. Programación de componentes: desarrollo de los componentes del videojuego que no necesariamente forman parte del gameplay. Los principales componentes son el motor de juego, las herramientas para ayudar a los artistas y diseñadores a interactuar con este y los componentes de red, entre otros 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 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 replicarlos para que puedan ser reparados. Se denomina verificador al rol asociado a esta disciplina. 2.6 Metodologías para Desarrollo de Videojuegos A partir de las mesas redondas realizadas en la Game Developer Conference (GDC) sobre ingeniería de software aplicada videojuegos de los años 2002 [LS08], 2003 [Llo08a] y 2004 [Llo08c], se puede ver que las metodologías más utilizadas para el desarrollo de videojuegos son codificar y corregir y variantes de cascada. En los

22 CAPÍTULO 2. ESTADO DEL ARTE 21 últimos años toma fuerza la tendencia a utilizar metodologías ágiles en varias empresas 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 Codificar y Corregir El modelo codificar y corregir (en ingles code-and-fix) consiste, según Steve Mc- Connell [McC96], en escribir código y luego corregir los errores del mismo. Mc- Connell afirma que Si no se ha seleccionado explícitamente el modelo de proceso, probablemente se está utilizando codificar y corregir por defecto. Si no se ha hecho mucha planificación, sin duda se está utilizando codificar y corregir. Figura 2.2: El modelo de codificar y corregir. Este modelo comienza con una idea general de lo que se quiere construir, pudiendo 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 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.

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

24 CAPÍTULO 2. ESTADO DEL ARTE 23 Una vez solucionados los errores encontrados en la fase beta (o al menos los más críticos) se obtiene la versión candidata para la liberación final. Aquí se congela el código 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 Metodologías Ágiles Los procesos y metodologías ágiles se basan en el manifiesto ágil [Man08] que plantea: Individuos y sus interacciones frente a procesos y herramientas. Software en funcionamiento frente a documentación exhaustiva. Colaboración del cliente frente a una negociación de contrato. Respuesta al cambio frente a seguir un plan. Esto quiere decir que aunque los términos de la derecha tienen valor, se valoran más los de la izquierda. Son varias las metodologías ágiles existentes, algunos ejemplos son Open Up [c + 08], Crystal Methods [Coc06], Feature-Driven Development (FDD) [PF02] y Lean Development [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 desarrollo 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 software 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 flexibilidad 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, estimando su tiempo y costo. También se analiza el sistema a construir, se define la arquitectura 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.

25 METODOLOGÍAS PARA DESARROLLO DE VIDEOJUEGOS Figura 2.4: Las fases de Scrum La metodología define tres roles entre los cuales se dividen todas las responsabilidades 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 proceso 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 Potentially Shippable Product. El Product Backlog representa el conjunto de todas las características que definen el producto. El Sprint Backlog representa el conjunto de todas las características y tareas a las cuales el equipo se compromete a realizar durante la iteración actual. El Sprint Burndown Chart representa gráficamente el trabajo que resta realizar para la iteración actual. El Release Burndown Chart representa gráficamente el progreso del trabajo respecto al plan de entregas. El Task Board representa el estado de las tareas que el equipo está realizando durante la iteración actual. El Potentially Shippable Product representa el producto actual, el obtenido por todos los incrementos de cada iteración.

26 CAPÍTULO 2. ESTADO DEL ARTE 25 Extreme Programming Extreme Programming (XP) es un proceso de desarrollo ágil que puede ser usado por equipos de tamaño pequeño a mediano para desarrollar software de alta calidad con un presupuesto y en un tiempo previsible, y con una sobrecarga de trabajo mínima [BA04]. El proceso, mostrado en la Fig.2.5, consiste a grandes rasgos, en relevar los requerimientos a través de historias de usuario (User Stories). Luego se realiza el plan para la siguiente liberación y se itera hasta desarrollar las funcionalidades acordadas. Finalmente, si las pruebas de aceptación son aprobadas por el cliente, se obtiene una liberación y se comienza de nuevo. Figura 2.5: El proceso de XP En resumen, XP es una colección de valores y buenas prácticas. La mayor parte de estas han sido usadas en la industria durante años. XP las identifica y las agrupa, ya qué usándolas en conjunto, es cuando realmente se obtiene el mayor beneficio. Las doce prácticas de XP son: Planning Game: determinar rápidamente el alcance de la próxima liberación combinando las prioridades del negocio y las estimaciones técnicas. A medida que la realidad cambia hay que actualizar el plan. Small Releases: poner un sistema simple rápidamente en producción, luego liberar nuevas versiones en ciclos cortos. Metaphor: guiar el desarrollo con una simple historia de cómo funciona el sistema. Simple Design: el sistema debe ser diseñado tan simple como sea posible en cada momento. La complejidad innecesaria es removida tan pronto como es descubierta. Testing First: continuamente escribir pruebas unitarias, que deben ejecutarse e- xitosamente para continuar con el desarrollo. Los clientes escriben pruebas para demostrar que las características están terminadas. Refactoring: reestructurar el sistema sin modificar su funcionamiento para remover duplicación, mejorar la comunicación o agregar flexibilidad.

27 METODOLOGÍAS PARA DESARROLLO DE VIDEOJUEGOS Pair Programming: todo el código es escrito con dos programadores en una máquina. Collective Ownership: cualquiera puede cambiar cualquier parte del código en cualquier momento. Continuous Integration: integrar y construir el sistema muchas veces por día, cada vez que una tarea es completada. 40 Hour Week: como regla, no trabajar más de cuarenta horas por semana. On-site Customer: incluir un usuario en el equipo, este debe estar disponible todo el tiempo para responder preguntas. Coding Standards: escribir el código de acuerdo a los estándares definidos para enfatizar la comunicación a través del código Adaptaciones de Metodologías Ágiles para Videojuegos Existen varias empresas desarrolladoras de videojuegos que utilizan metodologías ágiles, algunas de estas son: High Moon Studios [Hig08], Large Animal Games [Lar08], Titus Interactive Studios [Gam08b] y Crytek [Cry08a]. Sin embargo, ninguna de sus adaptaciones se encuentran especificadas formalmente o públicamente como una metodología para desarrollo de videojuegos. A continuación se describen las adaptaciones de estas empresas y los beneficios que reportan basados en su experiencia. High Moon Studios High Moon Studios utiliza Scrum y XP en todos sus desarrollos desde hace varios años [Llo08b]. Generalmente realizan iteraciones de dos semanas con equipos de alrededor de ocho personas donde el productor actúa como Scrum Master. Respetan todos las actividades de Scrum y ponen mucho énfasis en las prácticas de XP para el desarrollo de código. Entre las prácticas se destacan Pair Programming, Testing, Continuous Integration y Refactor que aplican sin excepciones. High Moon Studios es una de las empresas pioneras en utilizar Scrum para gestionar el desarrollo de videojuegos, han publicado varias de sus experiencias en distintos artículos y conferencias a modo de promover el uso de esta metodología. Atribuyen a las metodologías ágiles gran parte de su productividad y calidad de productos. Large Animal Games Large Animal Games adopta Scrum en forma progresiva hasta utilizarla en todos sus proyectos [Tob08], esta decisión se toma principalmente para evitar depender de ciertas personas clave. En su adaptación el Scrum Master, rol realizado por el productor, utiliza el Product Backlog Board para mantener todas las características del videojuego ordenadas por prioridad. La prioridad es asignada por el cliente, quien es ayudado por el diseñador de

28 CAPÍTULO 2. ESTADO DEL ARTE 27 juego con más experiencia para definir y priorizar las funcionalidades en forma correcta. 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 previstas por el proceso original. Además, le dan una particular importancia a la reunión de demostración del sprint, por permitirles validar con el cliente las características ya implementadas. Las reuniones que se agregan son: Reunión de preparación del sprint: se realiza el día anterior a la planificación del sprint. En ella el equipo se interioriza del estado de las características a implementar y se estiman mediante la utilización de Planning Poker [Coh08]. Luego de estimadas, el Product Ownner prioriza estas tareas en el Product Backlog Board. Reunión de mitad de sprint: en ella se analiza el avance de las tareas acordadas junto con el Product Owner. En caso de detectar problemas se pueden realizar ajustes antes de finalizar el sprint. Los equipos que realizan iteraciones cortas (una semana) no utilizan esta reunión. Los beneficios que reportan incluyen que el foco en la calidad que antes dependía de unos pocos individuos se distribuye entre todo el equipo. Además, los equipos necesitan 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 requerimientos, 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 problemas visibles y continuamente brindan oportunidades al equipo para discutir sus soluciones. Titus Interactive Studio Titus Interactive Studio plantea una propuesta de adaptación de XP para el desarrollo de videojuegos llamada Extreme Game Development (XGD) [Dem08] en donde se incorporan las prácticas de XP a las diferentes disciplinas del desarrollo de videojuegos. A pesar de que no hay resultados publicados acerca de esta propuesta, se considera interesante por su completa especificación. En su adaptación el rol de cliente es cumplido por el productor, quien junto con el diseñador de juego describen y priorizan las historias de usuario (User Stories) de las

29 METODOLOGÍAS PARA DESARROLLO DE VIDEOJUEGOS cuales surgen las características del videojuego. Una ventaja de que el cliente sea el productor es que está en permanente contacto con el equipo para responder consultas rápidamente. Definen iteraciones de seis semanas de duración. Cada iteración comienza con el Planning Game donde el equipo y el productor deciden qué características serán implementadas 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 progreso 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 desarrollo 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 celebració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 personaje 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 automatizables. 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 utilizando un proceso en cascada. La decisión de comenzar con Scrum se basa en que estaban desarrollando demasiadas características, eran incapaces de medir el progreso, necesitaban reducir el alcance, y la visión se dificultaba debido al enorme cronograma del proyecto. La transición a Scrum la realizan gradualmente, comenzando por elegir un equipo de personas, separarlo del equipo de producción en cascada y lograr que adopten la metodología. Esto lo repiten iterativamente hasta que todas las personas pertenezcan a un equipo. La estrategia utilizada implica: utilizar equipos multidisciplinarios siempre que sea posible.

30 CAPÍTULO 2. ESTADO DEL ARTE 29 los equipos siempre deben trabajar en el mismo espacio físico. siempre resolver tareas de forma secuencial, nunca en simultáneo. al priorizar, nunca asignar la misma prioridad a dos elementos distintos. al actualizar el progreso, solo contar como completas las características que están funcionales en el ejecutable. asegurarse de que los líderes de desarrollo no cumplan el rol de Scrum Master en la nueva estructura. De su experiencia concluyen que Scrum se puede escalar a proyectos grandes. Además destacan que el Product Backlog les permite manejar las expectativas y guiar al equipo Análisis de las Metodologías para Videojuegos Petrillo et al. [PPTD09] identifican, a partir de una investigación hecha de postmortems, los problemas más comunes en la industria de videojuegos. Los mismos se pueden apreciar en la Fig.2.6 que presenta el porcentaje de ocurrencia en cada proyecto de los problemas identificados. Entre estos se pueden destacar la definición de un alcance irreal o ambicioso, la definición de demasiadas características y el recorte de estas cuando están parcialmente implementadas, problemas en la etapa de diseño, de comunicación y retrasos en la planificación. Figura 2.6: Ocurrencia de problemas [PPTD09] De esta investigación Petrillo et al. concluyen que los principales problemas de la industria de software tradicional también se encuentran en la industria de los videojuegos. Esto hace pensar que las virtudes y defectos de las metodologías aplican de manera similar en el desarrollo de software tradicional y en el de videojuegos.

31 METODOLOGÍAS PARA DESARROLLO DE VIDEOJUEGOS La metodología codificar y corregir tiene pocas ventajas y varias desventajas [McC96]. Como ventaja, no se invierte tiempo extra en planificar, documentar, asegurar la calidad, utilizar estándares u otras actividades fuera de la codificación y utilizarlo requiere poca experiencia, ya que cualquiera que codifique ya está familiarizado con el modelo. Entre las desventajas se encuentra que no hay medios para evaluar el progreso, la calidad o identificar riesgos. Además, es costoso cambiar el código por la poca preparación para la verificación y modificaciones, pierde la estructura luego de varias correcciones y frecuentemente no satisface completamente las necesidades del cliente. Esta metodología parece apropiada solamente para proyectos pequeños que no requieren de mantenimiento posterior. Las metodologías de tipo cascada son adecuados para proyectos que están bien comprendidos porque se puede atacar la complejidad de forma ordenada [McC96]. Funcionan bien cuando los requerimientos de calidad predominan sobre los de costos y cronograma. Además, al eliminar los cambios en el transcurso de las fases se elimina una gran fuente de errores potenciales. Por otra parte, Craig Larman [Lar03] enuncia que la razón subyacente de las dificultades de cascada es que requiere de problemas con pocos cambios, poca innovación y baja complejidad. No es adecuado para proyectos complejos o inventivos. Identifica como desventajas que se debe especificar completamente el producto y elaborar cronogramas y estimaciones confiables por adelantado. Además, la verificación e integración se realiza en forma tardía. Otra característica negativa es que se encuentra valor en seguir lo planificado al pie de la letra, lo que hace difícil lidiar con cambios frecuentes en los requerimientos. Se deduce que dados los principales problemas encontrados en la industria de videojuegos, la rigidez de este tipo de procesos no es compatible con las características cambiantes de los videojuegos y la dificultad para planear y estimar estos proyectos. Las metodologías ágiles son iterativas e incrementales y buscan obtener versiones del producto en intervalos cortos y regulares de tiempo. Esto facilita una visión temprana del resultado final, lo cual reduce la probabilidad de cambios de requerimientos en forma tardía y brinda una mayor retroalimentación del cliente. Además permiten tener una mayor visión y control del avance del proyecto, tanto al cliente como a los desarrolladores. Esto se debe a que se pueden determinar nuevas estrategias, iteración por iteración, para lograr llegar en tiempo y forma a los plazos requeridos. También involucran a todo el equipo en las decisiones, lo que logra compromiso y motivación. Como desventajas se identifica la dificultad en su adopción, ya que muchas veces implica un cambio estructural en la organización, sobre todo en empresas grandes que tienen un proceso y una estructura establecida. Además es difícil involucrar al cliente en el proceso, ya que debe comprometerse a tener una interacción frecuente y continua. Las características que presentan las metodologías ágiles parecen mitigar los problemas más comunes que ocurren al desarrollar videojuegos. Sumando el éxito y los beneficios que se reportan en numerosos casos de empresas de la industria que las utilizan, se concluye que las metodologías ágiles son adecuadas para el desarrollo de videojuegos.

32 3 Relevamiento de la Industria de Videojuegos en Uruguay Con la motivación de conocer la industria uruguaya de desarrollo de videojuegos se realizan entrevistas entre marzo y abril del 2008 a cuatro empresas referentes en este rubro. El relevamiento hace foco en las metodologías de desarrollo que utilizan e incluye otros aspectos de las empresas como infraestructura, clientes, tipos de proyectos y estrategias de negocio que permiten caracterizar a la industria. El detalle de cada empresa se encuentra en el anexo B. En la sección 3.1 se presentan las empresas relevadas y sus principales características. En la sección 3.2 se resume la situación actual de la industria uruguaya y se analizan sus fortalezas, debilidades, oportunidades y amenazas. Por último, en la sección 3.3 se muestran alguno de los principales aspectos de las metodologías de desarrollo utilizadas por las empresas. 3.1 Empresas Relevadas Las empresas relevadas son Batovi Game Studio [Bat08], Mystery Studios [Mys08], Powerful Robot Games [Pow08] y Kef Sensei [Sen08]. La información presentada está sujeta a la fecha de realización de las entrevistas Batovi Game Studio La empresa surge como emprendimiento personal a mediados del año 2002 y en el 2005 se consolida asociándose a IPcom [IPc09]. Trabajan para varios clientes como MTV [MTV09], Nickelodeon [Nic09] y Cartoon Network [Net09], entre otros. Han desarrollado videojuegos del tipo Casual para las plataformas PC, Web y Dispositivos Móviles y utilizan para estas el modelo de ingresos de Probar Antes de Comprar, Advergaming y Móviles respectivamente. En el caso de los videojuegos para Dispositivos Móviles ellos mismos han financiado sus proyectos. Cuenta con ocho integrantes de los cuales cinco son programadores y tres artistas gráficos. Normalmente, en los proyectos el equipo se compone de dos o tres integrantes, entre los que hay al menos un diseñador gráfico y un programador. Además, algún miembro con experiencia participa como productor. 31

33 EMPRESAS RELEVADAS En la Fig.3.1 se muestran algunos de los videojuegos desarrollados por la empresa. Figura 3.1: DHL Driving Simulator - Bubbaloo Mix Skating - Arcade Fishing - SpongeBob Driving Exam - Skimo: Avalancha - Andy and the Secret of Egypt Kef Sensei La empresa comienza en el año 2007 como ramificación de otra empresa de desarrollo de software convencional. Su primer y único videojuego hasta el momento es desarrollado tras ganar el concurso Developer Dash [Pla08a], una competencia impulsada por el publisher PlayFirst [Pla08b]. Este les financia el proyecto y les entrega un porcentaje de las ganancias por las ventas. El videojuego es del tipo Casual para la plataforma PC y se comercializa con el modelo de ingreso Probar Antes de Comprar. Cuentan con seis personas, donde tres son programadores y tres son artistas gráficos. Uno de los programadores, además, participa como productor. En la Fig.3.2 se muestra el videojuego desarrollado por la empresa. Figura 3.2: Parking Dash

34 CAPÍTULO 3. VIDEOJUEGOS EN URUGUAY Mystery Studios La empresa se forma en junio del 2003 cuando desarrollan su primer videojuego. Logran su primer éxito en el 2004 con Betty s Beer Bar el cual definió un nuevo género en la industria casual. Hasta ahora desarrollan únicamente videojuegos de tipo Casual para la plataforma PC y utilizan para las ventas el modelo de ingreso Probar Antes de Comprar. Han desarrollado varios videojuegos con financiación propia, además de trabajar con publishers reconocidos como Ubisoft [Ubi09], Uclick [UCl09] y PopCap [Pop08]. Cuenta con tres integrantes, siendo dos programadores y un artista gráfico. Para sus desarrollos utilizan un framework propio implementado en C++, el cual además comercializan. En la Fig.3.3 se muestran algunos de los videojuegos desarrollados por la empresa. Figura 3.3: Wild West Wendy - Pirate Poppers - The Lost Cases of Sherlock Holmes - Brain Spa - Lavender s Botanicals - Cathy s Caribbean Club Powerful Robot Games La empresa se funda en el año Su videojuego más reconocido es el Big Fat Awesome House Party para Cartoon Network [Net09], que llega a tener más de trece millones de usuarios. Desarrollan diversos tipos de videojuegos, principalmente del tipo Casual para la plataforma Web y con el el modelo de ingreso Advergaming. Cuentan con un equipo de alrededor de veinte personas compuesto por cinco programadores y siete artistas gráficos, además de productores, diseñadores de juego y administrativos. En los proyectos suele participar un programador y uno o más artistas gráficos, además de un productor y un diseñador de juego. Estos últimos participan en varios proyectos a la vez. En la Fig.3.4 se muestran algunos de los videojuegos desarrollados por la empresa.

35 SITUACIÓN ACTUAL Figura 3.4: September 12th - Scuba Jojo - Debate Night, Obama s unoficial game - The Howard Dean Game - Path of the Jedi - Big Fat Awesome House Party 3.2 Situación Actual La industria de videojuegos en uruguay es joven ya que transcurren solamente siete años desde el surgimiento de la primer empresa. Durante estos años han aparecido nuevas empresas y más proyectos, pero este crecimiento no parece ser significativo. Esta industria no cuenta con una gran infraestructura y emplea entre tres y quince personas por empresa. La mayoría de los proyectos que se realizan se acotan a videojuegos de tipo Casual para las plataformas PC y Web utilizando los modelos de ingreso Probar Antes de Comprar y Advergaming. Su desarrollo habitualmente demanda entre dos y doce meses. No se tiene la oportunidad de desarrollar para ciertas plataformas (p.ej. Consolas) ya que no se cuenta con los recursos tanto económicos como de personal con la capacitación y experiencia necesaria. Actualmente, la mayoría de los proyectos dependen de la inversión de capitales externos. La estrategia que plantean las empresas, como forma de mejorar los ingresos, es desarrollar videojuegos por su propia cuenta o con financiamiento externo en etapas avanzadas del desarrollo. A continuación se presenta un análisis de fortalezas, oportunidades, debilidades y amenazas (FODA) para la industria uruguaya de videojuegos. Este análisis se basa en: el FODA para la industria uruguaya de software que se presenta en el Plan de Refuerzo de la Competitividad realizado por la Oficina de Planeamiento y Presupuesto (OPP) [OPP07], en el artículo Industria de Desarrollo de Videojuegos en Argentina de la Asociación de Desarrolladores de Videojuegos Argentina (ADVA) [ADV04] como ejemplo de una realidad similar, y en el relevamiento realizado para el presente trabajo Fortalezas Capacidad de los recursos humanos: reconocida capacidad de los recursos humanos uruguayos en las tecnologías de la información. Existe un conjunto de

36 CAPÍTULO 3. VIDEOJUEGOS EN URUGUAY 35 instituciones que brindan carreras a nivel de grado y de posgrado, dictados por recursos humanos con formación a nivel de maestría y doctorado. Efecto cluster: dado que el país es chico y los actores se conocen entre sí, existe una gran capacidad para hacer alianzas, asociaciones, investigaciones conjuntas, crear entidades de mejora, trabajar conjuntamente entre universidades, empresas, gobierno, instituciones intermedias, laboratorios e integrarse con otras cadenas de valor y otras industrias. En particular, Proanima [Pro09] es un cluster que integra empresas de producción de animación y desarrollo de videojuegos e industrias afines, para realizar proyectos y acciones que mejoren la gestión del sector. Costos competitivos: disponibilidad de recursos humanos altamente calificados a costos competitivos internacionalmente Debilidades Escasez de recursos humanos: la escasez de recursos humanos con la capacitación adecuada, hace que los mejores profesionales queden sobrevalorados. Esto afecta la competitividad ya que el costo de contratarlos es mayor. Poca experiencia de profesionales en la industria: considerando que la industria local de videojuegos es joven, la experiencia requerida para desarrollarlos radica en pocas personas. Falta de casos de éxito: actualmente, el país no cuenta con una cantidad significativa de casos de éxito para atraer potenciales inversores a proyectos de larga escala. Mercado interno chico: ventas locales insignificantes, lo que implica depender exclusivamente del mercado internacional. Falta de carreras especializadas: aunque existen en las universidades materias sobre el desarrollo de videojuegos, estas no son suficientes para una formación completa. Ejemplo de estas materias son las electivas dictadas por el laboratorio de simulación y videojuegos (GameLab) de la Universidad ORT, llamadas Desarrollo de Videojuegos I y II sobre XNA. Por su parte la Universidad de la República cuenta desde hace años con las electivas introducción a la computación gráfica, computación gráfica avanzada, mientras que en el 2008 se dicta el seminario de tecnologías interactivas y videojuegos 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 tecnología en el entretenimiento moderno.

37 METODOLOGÍAS DE DESARROLLO RELEVADAS Apoyo de organizaciones: existen instituciones que brindan el apoyo necesario para canalizar el impulso de las empresas, buscando potenciar sus emprendimientos. Un ejemplo de esto es Ingenio [Ing09], cuya incubadora brinda la infraestructura para la creación de nuevas empresas y promueve su crecimiento en un medio protegido, además de ser organizadora de un concurso nacional de videojuegos. Mercado en crecimiento: el mercado mundial de videojuegos está en constante crecimiento. Incluso en el 2008, a pesar de la crisis económica, las ventas en el mercado europeo registraron un crecimiento del 15% [ade09] 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 desarrollo. Este fenómeno está tomando importancia en Europa Oriental (Rusia, Ucrania, Hungría), el Sudeste de Asia (China, Singapur, Corea del Sur, India) y América (Argentina, Brasil y México). Subvenciones en otros países: algunos países ofrecen subsidios a los emprendimientos vinculados con el desarrollo de videojuegos, lo cual se transforma en una amenaza competitiva. Esta clase de subsidios son ofrecidos en países ya consolidados internacionalmente (Unión Europea), y en países competidores (Brasil y Argentina [dpcyt08]). 3.3 Metodologías de Desarrollo Relevadas Las metodologías que siguen las empresas se basan en su experiencia y no están formalmente definidas. Algunas, utilizan varias de las prácticas de metodologías ágiles conocidas como Scrum y Extreme Programming. En resumen, el proceso general de desarrollo de las empresas comienza por definir y acordar la idea del videojuego a realizar. Luego, se especifican sus características y se planifican los plazos de entrega. Para la elaboración del videojuego se relevan dos formas de trabajo, de las cuales la primera es la que se utiliza en la mayoría de las empresas y la segunda solo en una. La primera es iterativa e incremental con iteraciones de corta duración, donde en cada una se diseña, implementa y verifica un subconjunto de las características del videojuego. Al final de la iteración se muestra el progreso logrado para evaluar el videojuego y realizar cambios sobre su especificación. La segunda es secuencial, donde primero se realiza el diseño completo de la solución para luego implementar y posteriormente verificar. Una vez terminada la elaboración, se realiza una verificación funcional externa al equipo de desarrollo para detectar errores y evaluar el videojuego. A partir de los errores y evaluaciones que se reportan, se corrige el videojuego hasta alcanzar la versión final, la cual se distribuye de acuerdo al medio de distribución definido. El detalle completo del proceso de desarrollo relevado en cada empresa se encuentra en la sección B.5 dentro del anexo B.

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

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

40 CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 39 Asegurar un enfoque consistente y repetible a través de diversos proyectos. Dar consistencia y permitir el seguimiento al ciclo de vida del proceso. Facilitar la comunicación para las personas y para otros sistemas. Facilitar la planificación, el seguimiento y la evaluación del proyecto. Definir responsabilidades entre los miembros del equipo en forma clara. Reducir la dependencia en personas específicas. Trabajar en forma rápida y eficiente. Permitir el manejo, creación y distribución del conocimiento. Asistir en el entrenamiento. 4.2 Especificación SUM adapta para videojuegos la estructura y roles de Scrum descritos por Ken Schwaber [SB01]. Se utiliza esta metodología ya que brinda flexibilidad para definir el ciclo de vida y puede ser combinada fácilmente con otras metodologías de desarrollo para adaptarse a distintas realidades. Para la adaptación, se toma en cuenta la experiencia 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 procesos 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étodos para crear diferentes modelos de proceso. Esta separación tiene como ventaja centralizar los métodos y así poder definir o adaptar procesos que los usen en forma sencilla. 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.

41 OBJETIVOS Proceso de entrega: es un proceso especial que describe un enfoque completo e integrado para ejecutar un determinado tipo de proyecto. Describe el ciclo de vida completo de un proyecto de principio a fin descomponiéndolo en distintas fases. Los elementos del proceso de entrega pueden ser adaptados a cada proyecto en particular lo cual aporta flexibilidad al momento de utilizarlo. Fases: una fase es un período importante de tiempo durante un proceso de entrega. Durante una fase se alcanza un conjunto de objetivos bien definidos y finaliza al alcanzar un hito importante. Se construye agrupando actividades que comparten un tramo determinado del tiempo de vida de un proyecto. Al finalizar cada fase se evalúa el objetivo planteado. Una evaluación satisfactoria permite avanzar a la próxima fase del proyecto. Las fases en la mayoría de los casos se ejecutan secuencialmente por estar relacionadas las entradas y salidas de cada una. Actividades: las actividades se utilizan como estructura para agrupar tareas relacionadas 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ífico. 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 conjunto 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 proceso. Una persona puede ocupar varios roles, así como también un rol puede ser realizado por varias personas. Guías: las guías proveen explicaciones e información adicional relacionada con los elementos del proceso. Por ejemplo, una guía que explica o asiste en la realización de una tarea puede ser una checklist o un template, entre otros. 4.3 Objetivos La metodología SUM para Desarrollo de Videojuegos tiene como objetivos desarrollar 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 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 integrantes que trabajan en un mismo lugar físico o están distribuidos), de corta duración (menores

42 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, Cliente 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 arquitectura, realizar el diseño, implementación y verificación de los componentes de software 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 ambiente, los personajes y todos los elementos que hacen a la experiencia del jugador, además de los niveles, misiones y los desafíos que enfrenta el jugador. El rol de Verificador Beta no está presente en Scrum pero sí se detecta su existencia en el relevamiento de la realidad local y en la industria del videojuego en general. Su responsabilidad es la de realizar la verificación funcional del videojuego y comunicar el resultado de esta. Un Verificador Beta puede tener conocimientos y experiencia de verificación de software o videojuegos. Sin embargo, puede no poseer experiencia ni ser jugador frecuente y participar igualmente de la verificación, por ejemplo, al formar parte de un focus group del videojuego. 4.5 Proceso de Entrega El proceso de entrega se divide en fases iterativas e incrementales que se ejecutan en forma secuencial con excepción de la fase de gestión de riesgos que se realiza durante todo el proyecto. Las cinco fases secuenciales son: Concepto, Planificación, Elaboración, Beta y Cierre. Estas se aprecian en la Fig.4.1. Las fases de Concepto, Planificación y Cierre se realizan en una única iteración, mientras que Elaboración y Beta constan de múltiples iteraciones. Las fases surgen como adaptación al desarrollo de videojuegos de las fases pregame, game y post-game que presenta Scrum, donde las dos primeras coinciden con las fases de Planificación y Elaboración, mientras que la tercera se corresponde con la

43 PROCESO DE ENTREGA Figura 4.1: Fases del proceso fases de Beta y Cierre. Esta división se realiza ya que la fase Beta tiene características especiales en la industria de videojuegos. La fase de Concepto no se corresponde con ninguna etapa de Scrum. Se agrega ya que cubre necesidades específicas para el desarrollo 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 consideradas 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 Concepto La fase tiene como objetivo principal definir el concepto del videojuego. Es una fase corta en el tiempo que finaliza cuando se tiene el concepto validado entre todas las partes involucradas. La validación no implica necesariamente tener definido todos los aspectos del concepto en forma completa para pasar de fase. Desarrollo del Concepto Desarrollar el concepto del videojuego implica la realización de tres tareas para definir aspectos de negocio, de elementos de juego y técnicos como se aprecia en la Fig.4.2. El concepto del videojuego se construye a partir de ideas y propuestas de cada rol involucrado sobre los aspectos a definir. Las propuestas se refinan a través de reuniones y se analiza su factibilidad con pruebas de concepto. Estas tres tareas se rea-

44 CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 43 lizan en paralelo y durante toda la fase, ya que se puede comenzar con cualquiera de ellas y cada una puede influenciar al resto. Figura 4.2: Actividad - Desarrollo del Concepto Definir aspectos de negocios Se decide a qué público está orientado el videojuego y el modelo de negocios a seguir. El Cliente y el Productor Interno son los responsables de ejecutar esta tarea. Definir aspectos de juego Se determinan los principales aspectos del videojuego como son: visión, género, gameplay, principales características, historia y ambientación. Esta tarea involucra también la posible creación de pruebas de concepto para evaluar las ideas y minimizar el riesgo de que no sea divertido. Estas pueden ser simulaciones del videojuego en papel, pruebas con videojuegos similares o codificación de prototipos. Es importante que no se invierta más que el tiempo necesario para probar la idea. Los responsables de esta tarea son el Equipo de Desarrollo, el Cliente y el Productor Interno. Definir aspectos técnicos Se eligen los dispositivos de hardware en los que se podrá ejecutar el videojuego además de las tecnologías y herramientas para realizar la implementación. Se pueden realizar prototipos técnicos que prueben los aspectos seleccionados para evaluar la factibilidad de su utilización. El Equipo de Desarrollo, el Cliente y el Productor Interno son quienes deciden estos aspectos 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 resultados componen el plan del proyecto. Como se observa en la Fig.4.3, las actividades se

45 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 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. Figura 4.3: Actividades de la Fase de Planificación Planificación Administrativa Esta actividad implica realizar cuatro tareas, como se aprecia en la Fig.4.4, con el objetivo de definir diversos elementos del plan de proyecto. Se ejecutan en paralelo ya que no existe un orden de ejecución definido. Este depende de la situación de partida al planificar ya que si uno o más de estos elementos están definidos previamente, los otros deben ajustarse para cumplir los requerimientos. Definir objetivos del proyecto Se definen los objetivos que se quieren alcanzar al finalizar el proyecto. Para cada uno se deben determinar criterios de evaluación que permitan medir su éxito. Es importante determinar cuáles son los resultados que se esperan obtener, ya que estos guiarán el esfuerzo del equipo durante el desarrollo del proyecto. El Cliente y el Productor Interno son los encargados de definir los objetivos. Definir cronograma Se determina el cronograma para las restantes fases del proyecto en base al concepto del videojuego, los riesgos detectados y el resto de los elementos del plan de proyecto. El cronograma se conforma con las fechas estimadas para el comienzo de la fase de Elaboración, Beta y Cierre. Además, incluye la cantidad de iteraciones a realizar durante la fase de elaboración junto con sus duraciones,

46 CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 45 Figura 4.4: Actividad - Planificación Administrativa los criterios de finalización para la fase Beta y los hitos intermedios. Para definir los criterios de finalización una posibilidad puede ser establecer una ventana de tiempo determinada durante la cual no aparezcan errores críticos o realizar determinada cantidad de iteraciones. Los hitos intermedios de avance se definen para cumplir con requerimientos del cliente, algo que es común por causa de los contratos que se realizan en la industria de videojuegos [Bat03]. El Cliente y el Productor Interno son los responsables de esta tarea. Definir equipo de desarrollo Se conforma el equipo de desarollo para el resto de las fases. Para esto, a partir del concepto del videojuego se identifican las necesidades técnicas y artísticas requeridas para la realización del proyecto. De acuerdo a estas y de la conformación actual del equipo, se seleccionan las personas que van a formar parte del equipo de desarrollo. Pueden existir cambios en el equipo de la fases anteriores para poder cumplir con las necesidades detectadas. En caso de que existan necesidades que las personas que integran el equipo no pueden cubrir, estas deben ser cubiertas externamente. Los contratistas externos se determinan dependiendo de la oferta de mano de obra para la necesidad a cubrir y de las experiencias previas. El Productor Interno es el responsable de realizar esta tarea. Es clave determinar la disponibilidad de los recursos (internos o externos) para cubrir los requerimientos, ya que sino el proyecto puede no ser factible. Definir presupuesto

47 PROCESO DE ENTREGA 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 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 Productor Interno es el responsable de definir el presupuesto. Especificación del Videojuego Esta actividad consta de tres tareas cuyo propósito es especificar, estimar y priorizar cada una de las características funcionales y no funcionales que definen el videojuego. Las tareas se ejecutan en forma secuencial tal cual muestra la Fig.4.5. Figura 4.5: Actividad - Especificación del Videojuego Una característica funcional representa, en forma similar a una User Story de Extreme 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 requerimientos del videojuego y medir el avance durante todo el proyecto. Una característica no funcional representa una propiedad o cualidad que el videojuego debe presentar. Estas características suelen referir principalmente a atributos de calidad y a documentos exigidos, entre otros. Especificar características

48 CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 47 Se determinan y describen cuáles son las características funcionales y no funcionales del videojuego tomando como base el concepto. La descripción de cada característica es breve pero contiene suficiente detalle para poder estimar el tiempo necesario para realizarla. También se incluyen los criterios de evaluación que sirven como herramienta para verificar la característica y para eliminar ambigüedades en la definición de la misma. La ejecución de esta tarea es responsabilidad del Equipo de Desarrollo y el Cliente. Estimar características Se estima el tiempo que se requiere para realizar las características del videojuego 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 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.

49 PROCESO DE ENTREGA Figura 4.6: Actividades de la Fase Elaboración Con esta forma de trabajo se puede evaluar el avance del proyecto, lo cual permite realizar cambios a tiempo y tomar decisiones para cumplir con los plazos planificados. Además, la experiencia adquirida permite mejorar la forma de trabajo en cada iteración y aumentar la productividad. Se espera que esta fase sea la más extensa de todo el proyecto. Planificación de la Iteración En esta actividad se crea el plan de la iteración que consta de sus objetivos, las características a implementar y las métricas a utilizar para el seguimiento. Consta de tres tareas que se realizan en forma secuencial una única vez por iteración del modo que se aprecia en la Fig.4.7. Definir objetivos y métricas Los objetivos describen lo que se pretende lograr al finalizar la iteración y se utilizan para evaluar el éxito de la misma. Sirven también de guía para la toma de decisiones en el transcurso de la iteración. De acuerdo a los objetivos planteados, las métricas determinan qué aspectos medir, cómo hacerlo y cuáles son los valores esperados para poder monitorear el avance del proyecto. El Cliente,

50 CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 49 Figura 4.7: Actividad - Planificación de la Iteración el Equipo de Desarrollo y el Productor Interno son los responsables de realizar la tarea. Seleccionar características La selección de las características se realiza en base a su prioridad y a los objetivos de la iteración. La suma de los tiempos estimados de las características seleccionadas no debe superar la duración de la iteración. 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 desviaciones, verificarlas y evaluar su completitud. Las tareas para desarrollo de videojuegos se pueden agrupar de acuerdo a las disciplinas que involucran. Por ejemplo pueden existir tareas de contenido audiovisual, lógica de juego y desarrollo de componentes de software, entre otros. Es el Equipo de Desarrollo quien determina 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.

51 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 miembros 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 completarla, en ese caso se ingresan como nuevas tareas de la iteración. Figura 4.8: Proceso para desarrollo de tareas Seguimiento de la Iteración Su objetivo es el de mantener la visión y el control de la iteración en base a los objetivos planteados. Consta de una única tarea que se realiza durante toda la iteración en la cual se hace el seguimiento de la misma y se toman las acciones necesarias en caso de ocurrir problemas. Monitorear iteración Se toman las medidas y se evalúan las métricas para tener visibilidad sobre el estado de la iteración y medir la rapidez con la que equipo avanza hacia com-

52 CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 51 pletar los objetivos planificados. En forma permanente se comunica el estado actual para determinar la existencia de problemas o desvíos en los objetivos. En caso de que ocurran se registra la causa, se proponen posibles soluciones y el impacto en los objetivos de la iteración y del proyecto. El Productor Interno realiza el seguimiento y mantiene informado del avance al cliente y al equipo. Las soluciones a los problemas son acordadas entre los involucrados. Cierre de la Iteración Esta actividad tiene como objetivos evaluar el estado del videojuego y lo ocurrido en el transcurso de la iteración para actualizar el plan de proyecto a la situación actual. Para ello se ejecutan tres tareas en forma secuencial como se aprecia en la Fig.4.9. Figura 4.9: Actividad - Cierre de la Iteración Evaluar estado del videojuego Se evalúa la versión del videojuego que se obtiene al finalizar la iteración a partir de los criterios de evaluación determinados y la opinión del cliente. Con esta evaluación el cliente puede obtener una medida del estado de cada característica planificada para la iteración. El Equipo de Desarrollo y el Productor Interno son los encargados de realizar la presentación de las características construidas en la versión actual del videojuego. Evaluar la iteración Se identifican los problemas y dificultades que ocurrieron durante la iteración y se determinan soluciones para estos. Estas soluciones se utilizan en próximas

53 PROCESO DE ENTREGA iteraciones, pudiendo reflejarse como cambios al proceso o tareas. Los responsables de esta actividad son el Equipo de Desarrollo y el Productor Interno, en forma opcional puede participar el Cliente. Actualizar plan del proyecto Se actualiza el plan de proyecto para reflejar la situación actual. Todos los elementos están sujetos a cambios para poder administrar de la mejor manera los problemas encontrados y los cambios de requerimientos. Al actualizar se pueden agregar, cambiar o eliminar características del videojuego así como su priorización y tiempo estimado. También está permitido modificar el cronograma y definir o cambiar hitos, cambiar la composición del equipo o buscar nuevos contratistas externos, y realizar ajustes al presupuesto. Se debe tener en cuenta que de acuerdo a los cambios se deben reajustar todos los elementos del plan para que sea consistente. El Cliente, el Equipo de Desarrollo y el Productor Interno participan de la actualización, determinando los cambios a realizar 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 eliminar 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 En cada ciclo primero se planifica y distribuye la versión beta para ser verificada. 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 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.

54 CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 53 Figura 4.10: Actividades de la Fase Beta Distribuir versión beta Se proporciona a los Verificadores Beta la versión del videojuego a verificar a través de los medios definidos. El Productor Interno es el responsable de esta tarea. Verificación del Videojuego Esta actividad consta de una única tarea, en la cual se verifica la versión beta del videojuego y se reportan los errores. Verificar videojuego Se verifica el videojuego poniendo foco en los aspectos funcionales y no funcionales definidos, y se reportan los resultados obtenidos. Los resultados pueden ser errores o las impresiones acerca de aspectos como elementos del videojuego desbalanceados o poco atractivos. Los Verificadores Beta son quienes realizan la verificación y comunican los resultados al equipo de desarrollo a través de los medios de comunicación definidos. Corrección del Videojuego La actividad tiene como objetivo la corrección del videojuego de acuerdo a los errores y evaluaciones reportadas en la verificación. Para ello se cuenta con dos tareas que se ejecutan en paralelo, del modo que se aprecia en la Fig En una se priorizan y determinan los cambios a realizar y en otra se realizan los cambios de acuerdo a su prioridad.

55 PROCESO DE ENTREGA Figura 4.11: Actividad - Planificación de la iteración Priorizar ajustes Se definen los ajustes a realizar al videojuego en base a los resultados de la evaluació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 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 secuenciales como se puede apreciar en la Fig Liberación del Videojuego Se realiza una única tarea en la que se construye la versión final del videojuego. Entrega final Se pone a disposición del Cliente la versión final del videojuego en las formas establecidas de acuerdo a la especificación del videojuego. El entregable final

56 CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 55 Figura 4.12: Actividad - Corrección del Videojuego está compuesto por el videojuego funcionando y otros artefactos acordados previamente que el cliente exija. Estos pueden ser documentos de diseño de juego, de diseño de software, manuales de usuario, etc. Es el Equipo de Desarrollo quien realiza las tareas necesarias para incorporar estos elementos mientras que el Cliente debe dar el aval al entregable para dar por finalizada la tarea. Evaluación del Proyecto La evaluación consiste en una única tarea en la que se identifican aspectos relevantes que ocurrieron durante el desarrollo del proyecto, se registran las lecciones aprendidas y se realizan mejoras al proceso. Evaluación postmortem Se evalúa el proyecto a partir de las medidas tomadas durante el desarrollo, la gestión de riesgos, la experiencia de cada participante y las evaluaciones realizadas al finalizar cada iteración de la fase de elaboración. A partir de estos elementos se identifican los problemas ocurridos, los éxitos conseguidos, las soluciones halladas, el cumplimiento de objetivos y la certeza de las estimaciones. Con las conclusiones extraídas se construyen las lecciones aprendidas y se buscan alternativas para mejorar el proceso. En la evaluación es recomendable que participen todas las personas que han estado involucradas en el proyecto Gestión de Riesgos Esta fase se realiza durante todo el proyecto, con el objetivo de minimizar la ocurrencia y el impacto de problemas durante su ejecución. Esto se debe a que distintos

57 PROCESO DE ENTREGA Figura 4.13: Actividades de la Fase de Cierre riesgos pueden ocurrir en cualquiera de las fases, por lo cual, siempre debe existir un seguimiento de los mismos. Gestión de Riesgos Consta de dos tareas que se realizan en forma simultánea en el tiempo del modo que se aprecia en la Fig La primera identifica los riesgos en cada momento del proyecto y la segunda se encarga del seguimiento y de la aplicación de los planes de mitigación y contingencia. Figura 4.14: Actividad - Gestión de Riesgos Identificar riesgos

58 CAPÍTULO 4. SUM PARA DESARROLLO DE VIDEOJUEGOS 57 Se establecen los riesgos junto con su impacto, probabilidad de ocurrencia, mecanismos de monitoreo, estrategia de mitigación y plan de contingencia. El E- quipo de Desarrollo y el Productor Interno son los encargados en todo momento de identificar los riesgos y definir los aspectos requeridos. Monitorear riesgos Se monitorean en forma continua los riesgos identificados para evaluar la probabilidad de que ocurran y la eficacia de las acciones que se toman para mitigarlos. La evaluación de los riesgos puede implicar la ejecución de nuevas acciones para evitar que ocurran o la aplicación de los planes de contigencia en caso de que sucedan. El productor interno es el encargado de monitorear y asegurar de que se apliquen las estrategias de mitigación y contingencia. 4.6 Guías Las guías son sugerencias, pautas y herramientas para seguir en forma efectiva y eficaz las actividades que componen el proceso. A través de ellas, se incorporan a la metodología prácticas aplicadas con éxito para el desarrollo de videojuegos, además de las lecciones aprendidas con la ejecución de cada proyecto. Se pueden asociar a fases, actividades y tareas para dar pautas de cómo realizarlas. La definición de guías brinda flexibilidad en como llevar a cabo el proceso ya que presenta varias alternativas a utilizar según la situación y las necesidades que se tengan. Actualmente SUM incluye las prácticas y herramientas de Scrum y XP, y además, artículos publicados sobre la aplicación de metodologías ágiles en el desarrollo de videojuegos. Además, se brindan como ejemplos las salidas obtenidas durante la ejecución del proceso en el caso de estudio.

59 5 Evaluación de SUM para Desarrollo de Videojuegos Con el fin de evaluar y realizar ajustes a la metodología SUM para Desarrollo de Videojuegos, se propone su puesta en práctica en una situación de ejemplo que busca contemplar las condiciones de la industria local. En este capítulo se presenta el análisis y la evaluación de dicha puesta en práctica. En la sección 5.1 se define en qué consiste la propuesta. Luego, en la secciones 5.2, 5.3 y 5.4 se presentan la evaluación de SUM de roles, proceso de entrega y guías respectivamente. 5.1 Definición La propuesta consiste en el desarrollo de un prototipo de videojuego 3D de acción, multijugador distribuido. El público objetivo son jugadores con cierta experiencia en videojuegos sin ser específicamente casuales o hardcore. El lenguaje de programación seleccionado es Java y el entorno de desarrollo Eclipse [Ecl08]. La motivación de esta elección es la de maximizar la cantidad de plataformas objetivo y contar con un conjunto herramientas, bibliotecas y frameworks conocidos por los integrantes. Dentro de estas herramientas se selecciona el motor de juegos 3D de código abierto JMonkeyEngine [jmo08]. Para el control de versiones de código se utiliza la herramienta Svn [Sub08], para el control de versiones de bibliotecas y especificación de proyectos la herramienta Maven [Mav09a] y para el seguimiento de tareas y reporte de defectos la herramienta web Trac [Tra09]. El proyecto es llevado a cabo por los cuatro integrantes de este proyecto de grado, que cuentan en promedio con tres años de experiencia en tecnologías de informació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 computació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

60 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 profesionales 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 auxiliar en el desarrollo. Las principales vías de comunicación son el correo electrónico y mensajería instantánea. El objetivo de la propuesta es construir un prototipo de videojuego que sirva para evaluar la mayor cantidad de aspectos de SUM. Debido a que la motivación no es la de generar ingresos, se dejan de lado los aspectos de negocio y presupuesto. El detalle del videojuego se puede encontrar en los anexos C, D, E y F. 5.2 Evaluación de Roles Respecto al Equipo de Desarrollo, se observa que al participar en todas las decisiones del proyecto se aprovecha la experiencia y puntos de vista de cada uno, logrando que se sientan motivados y comprometidos con el videojuego. Dentro de las decisiones que toma exclusivamente el equipo, todos los integrantes tienen el mismo peso por lo que asumen y comparten todas las responsabilidades. Los participantes de la propuesta lo consideran una mejor opción, a partir de su experiencia personal, frente a la situación en la que un miembro de mayor jerarquía imponga lo que considera mejor. Se observa que se obtienen mejores resultados cuando el equipo interactúa en el mismo lugar físico, debido a que les permite expresar fácilmente sus ideas y reduce los problemas de comunicación que ocurren en caso contrario. Además, la interacción directa permite atacar rápidamente las diferencias de opiniones para evitar tomar decisiones incorrectas. Dado que en el caso de la propuesta el equipo solo se compone de programadores, no se obtienen observaciones en cuanto a la interacción entre disciplinas. En cuanto al Productor Interno, se nota positivo que centraliza la comunicación entre los integrantes del equipo y los mantiene enfocados en los objetivos de cada iteración. Además, les permite concentrarse en las tareas de desarrollo mientras él se encarga de realizar el seguimiento para detectar y resolver impedimentos. Como en el caso de la propuesta los propios integrantes interpretan el rol de Cliente, no se obtienen observaciones en cuanto a la participación de un cliente externo al equipo. Se observan algunas diferencias entre lo que el grupo presentó como versión final y lo que los tutores pretendían obtener. Esto comprueba que es importante la participación de quien tiene la decisión final en los cierres de las iteraciones para poder marcar a tiempo lo que pretende. De acuerdo a lo observado en la interacción entre roles, se considera importante definir una nomenclatura en común tanto en el Equipo de Desarrollo (p.ej. estándares de código) como con el Cliente y proveedores (p.ej. definición de formatos de archivo

61 EVALUACIÓN DEL PROCESO DE ENTREGA y especificación de requerimientos). No definirlos lleva a desacuerdos y problemas que atrasan el proyecto. 5.3 Evaluación del Proceso de Entrega A continuación se presenta, fase a fase, un conjunto de observaciones sobre sus actividades y tareas junto con la evaluación realizada 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 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 comprometen 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 inconformidad 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.

62 CAPÍTULO 5. EVALUACIÓN DE SUM 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 desarrollo. 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 dimensionar 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 experiencia 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 fundamentales 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 misma 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.

63 EVALUACIÓN DEL PROCESO DE ENTREGA Al evaluar el estado del videojuego en el Cierre de la Iteración se observa que se puede evaluar la última versión desarrollada utilizando los criterios de evaluación definidos y la opinión de los interesados. De esta forma se determina qué falta para completar cada una de las características y permite determinar el grado de avance del videojuego. Se observa que no implementar de forma completa una característica prevista para la iteración afecta negativamente a la motivación del equipo y a la evaluación del videojuego ya que no se obtienen resultados visibles. Al evaluar la iteración se identifican problemas y se proponen mejoras. Al participar todo el equipo se logra adaptar la forma de trabajo de la mejor manera para que los integrantes se sientan cómodos al realizar las actividades. Se nota muy positiva esta actividad ya que permite tener una instancia donde se puedan enfrentar todos los problemas cara a cara y buscar las soluciones entre todos. Las medidas tomadas durante la iteración se muestran efectivas para determinar la certeza de las estimaciones y utilizar esta información para realizar las próximas. En base a estas evaluaciones se procede a actualizar el plan de proyecto, lo que provee una oportunidad para ajustarlo respecto a la situación actual. Durante esta instancia se aprovecha la experiencia generada durante toda la iteración, tanto al desarrollar como al evaluar el videojuego. Además, se observa positivo que se pueden agregar nuevas características o quitar características obsoletas, actualizando el plan de proyecto y el cronograma debidamente. Se observa que la experiencia previa de los integrantes al realizar las actividades es realmente importante. Trabajar en forma iterativa permite aprovechar rápidamente la experiencia generada en iteraciones pasadas. En particular, se nota la ganancia al especificar, estimar, priorizar y refinar en tareas las características 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 Cierre La Liberación del Videojuego se realiza utilizando los medios de distribución definidos. 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,

64 CAPÍTULO 5. EVALUACIÓN DE SUM 63 al momento de evaluar el proyecto se puede saber si los objetivos fueron alcanzados y en qué medida. Este ajuste no se prueba durante el desarrollo, por lo que no se puede concluir nada al respecto Gestión de Riesgos En el caso de la propuesta, los riesgos que se detectan al comienzo del proyecto se mantienen durante toda su ejecución y no surgen nuevos riesgos de relevancia. Al realizar su seguimiento durante todas las fases del proyecto se observa la flexibilidad para establecer diferentes planes de mitigación y contingencia de acuerdo a la fase y el estado actual del proyecto. Se nota que es necesario involucrar a todos los participantes del proyecto para identificar y mitigar efectivamente los riesgos. 5.4 Evaluación de Guías En general, todas las guías sirven como punto de partida para realizar las actividades cuando no se tiene ninguna experiencia. Las guías mencionadas en esta sección junto con otras guías propuestas se describen en detalle en el anexo G. De las guías propuestas, se encuentran de utilidad Brainstorming y Bocetos para definir el concepto, mientras que Planning Game y Planning Poker ayudan a planificar las iteraciones y estimar las características, respectivamente. Esto se debe a que todas aprovechan la interacción y creatividad de los participantes y permiten unificar la visión de cada uno para alcanzar resultados más precisos. Sprint Burndown Chart se muestra útil para identificar rápidamente desviaciones en el avance de la iteración pero es difícil de mantener cuando se trabaja en forma remota. Dentro de las herramientas utilizadas, se observa muy positivo el uso de un sistema de control de versionado de código, el cual permite a los desarrolladores realizar seguimiento, mantener distintas versiones y compartir diferencias de código en forma rápida y fácil. Para el manejo de tareas y reporte de errores, las herramientas web de seguimiento se muestran de gran utilidad ya que permiten organizar de forma centralizada el trabajo y brindan buena visibilidad del estado del videojuego. Si bien todas las herramientas utilizadas ayudan durante la propuesta, la mayor parte son de propósito general. A partir de esto, se observa claramente que se necesitan más guías relacionadas específicamente con el desarrollo de videojuegos (p.ej. formatos de audio conocidos que se usan en videojuegos, lenguajes y herramientas de scripting, técnicas de inteligencia artificial).

65 6 Conclusiones y Trabajo Futuro Se alcanza el objetivo propuesto para el proyecto de grado al lograr especificar formalmente y probar en un caso de estudio la metodología SUM para Desarrollo de Videojuegos, una metodología ágil que se adapta a las características relevadas en la industria del Uruguay. La falta de formación específica en videojuegos junto con la falta de recursos económicos son dos de los principales problemas que atentan contra el crecimiento de la industria. Actualmente, la formación es mayoritariamente informal y se basa en la experiencia personal de los miembros de la industria. Como consecuencia, existen dificultades para transmitir estos conocimientos tanto entre pares como a nuevos desarrolladores. Se considera que la formalización de SUM es un aporte al desarrollo de la industria nacional ya que se puede utilizar como herramienta para la enseñanza a nuevos desarrolladores además de servir a las empresas para la mejora de sus procesos actuales. Para la construcción de SUM se utilizan los principios de las metodologías ágiles ya que del análisis del estado del arte en la industria de los videojuegos se concluye que estos son adecuados. A esta conclusión se arriba en base a las experiencias documentadas de varias empresas que utilizan metodologías ágiles para desarrollar videojuegos. A pesar del éxito que reportan, no se encuentra ningún estudio formal que demuestre su efectividad. Este hecho se puede minimizar a partir de la conclusión expresada por Petrillo et al. [PPTD09] de que los problemas presentes en el desarrollo de software tradicional y videojuegos son similares. Con esta conclusión se puede inferir que beneficios formalmente demostrados de metodologías ágiles aplicados al desarrollo de software tradicional podrían resultar efectivas para desarrollar videojuegos. Además, las metodologías de desarrollo utilizadas en la industria local, por ser iterativas, tener interacción frecuente con el cliente y ser flexibles a cambios, tienen varios puntos en común con los principios ágiles. SUM se encuentra especificada formalmente siguiendo el estándar SPEM de modelado de procesos de desarrollo de software e implementada con la herramienta EPF, lo que permite comunicar el proceso en forma efectiva y extenderlo de forma simple. Este hecho también se considera un aporte ya que en el estudio del estado del arte realizado no se encontró ninguna metodología ágil para videojuegos especificada de esta forma. Con el fin de evaluar SUM se realiza un caso de estudio que consiste en implementar un prototipo de videojuego cuya definición se basa en las características de la

66 CAPÍTULO 6. CONCLUSIONES Y TRABAJO FUTURO 65 industria uruguaya. Se alcanza el resultado esperado al lograr construir el prototipo que contiene las características básicas planteadas al inicio del desarrollo. Se concluye que la experiencia es exitosa ya que se pone en práctica SUM y se genera mucha información tanto para su evaluación como para su ajuste. De la evaluación realizada a las observaciones tomadas durante el caso de estudio, se concluye que SUM cumplió con sus objetivos y ayudó a mitigar varios de los problemas ocurridos. Estos fueron similares a los problemas típicos de la industria presentados en la sección La forma de trabajo iterativa que plantea SUM se determina útil, ya que en cada iteración se aprovecha la experiencia generada anteriormente, permitiendo tomar mejores decisiones. También se destaca que obtener versiones del videojuego en cada iteración da una visión del avance del proyecto y permite realizar cambios a las funcionalidades a tiempo. Se detectan varios problemas con los cuales se ajusta la metodología para ser más efectiva, quedando como aspecto a mejorar la incorporación de una mayor cantidad de guías específicas para desarrollo de videojuegos. Las conclusiones de SUM que se obtienen son preliminares ya que el escenario definido no prueba todos los aspectos de la metodología y tampoco existe una evaluación formal y empírica de la misma. Los aspectos que no pudieron ser evaluados son: la interacción entre varias disciplinas, que el cliente no pertenezca al equipo de desarrollo y aspectos de negocio y presupuesto. Además, el análisis puede ser subjetivo en algunos puntos ya que la metodología es evaluada por las mismas personas que la construyen. Como trabajo futuro se considera: Incorporar un mayor número de guías específicas de desarrollo de videojuegos para hacer más completa la metodología. Evaluar en nuevos casos de prueba en distintos contextos para medir efectivamente su valor. Evaluar estas experiencias para ajustar la metodología e integrar las lecciones aprendidas como guías. Presentar SUM a empresas de desarrollo de videojuegos en Uruguay para evaluarla en una experiencia práctica real. Relevar empresas desarrolladoras de videojuegos de la región para detectar características comunes con la industria uruguaya y poder ajustar la metodología a estas para que tenga un mayor alcance. Desarrollar un proceso para la gestión de negocios en videojuegos e incorporarlo a SUM para que contemple todo el ciclo de vida de un videojuego y no solo el desarrollo. Implementar una herramienta para gestionar proyectos con SUM.

67 Bibliografía [3DS09] Autodesk 3ds Max. Online, Fecha de Acceso: Abril &id= [ACMV09] Nicolás Acerenza, Ariel Coppes, Gustavo Mesa, y Alejandro Viera. Sum para Desarrollo de Videojuegos. Online, Fecha de Acceso: Mayo [ade09] adese. Videojuegos - Resultados Reporte técnico, Asociación Española de Distribuidores y Editores de Software de Entretenimiento, Marzo [ADV04] [ASR02] ADVA. Industria de Desarrollo de Videojuegos en Argentina. Reporte técnico, Asociación de Desarrolladores de Videojuegos Argentina, Diciembre Pekka Abrahamsson, Outi Salo, y Jussi Ronkainen. Agile Software Development Methods. VTT Publications, ISBN [AUD09] Audacity. Online, Fecha de Acceso: Agosto [BA04] [Bat03] [Bat04] Kent Beck y Cynthia Andres. Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional, ISBN Bob Bates. Game Developer s Market Guide. Premier Press, ISBN Bob Bates. Game Design (2nd edition). Thomson Course Technology PTR, ISBN [Bat08] Batovi Games Studio. Online, Fecha de Acceso: Marzo [Bec04] Kent Beck. User Stories Applied. Addison-Wesley Professional, ISBN [Ben08a] [Ben08b] [Ben08c] Owain Bennallack. Casual Biz Models No. 1, Retail distribution. Online, Fecha de Acceso: Mayo /casual-biz-models-no1-retail-distribution. Owain Bennallack. Casual Biz Models No. 4, Try Before You Buy. Online, Fecha de Acceso: Mayo news/27467/casual-biz-models-no-4-try-before-you-buy. Owain Bennallack. Casual Biz Models No. 5, Cash prize tournaments & skill-based gaming. Online, Fecha de Acceso: Mayo casualgaming.biz/news/27483/casual-biz-models-no-5-cashprize-tournaments-skill-based-gaming.

68 BIBLIOGRAFÍA 67 [Ben08d] Owain Bennallack. Casual Biz Models No. 6, Subscription. Online, Fecha de Acceso: Mayo /Casual-Biz-Models-No-6-Subscription. [Ben08e] [Ben08f] Owain Bennallack. Casual Biz Models No. 7, Mobile. Online, Fecha de Acceso: Mayo Casual-Biz-Models-No-7-Mobile. Owain Bennallack. Casual Biz Models No. 8, Microtransactions. Online, Fecha de Acceso: Mayo /Casual-Biz-Models-No-8-Microtransactions. [c + 08] Eclipse contributors et al. Open Unified Process (OpenUP). Online, Fecha de Acceso: Setiembre [Cas08] CasualGaming.Biz. Casual Games. Online, Fecha de Acceso: Mayo [Coc06] [Coh08] [Cor08a] Alistair Cockburn. Agile Software Development: The Cooperative Game. Addison Wesley Professional, ISBN Mike Cohn. Planning Poker in detail. Online, Fecha de Acceso: Agosto Microsoft Corporation. Quick start guide. Online, Fecha de Acceso: Abril [Cor08b] Microsoft Corporation. Xbox 360. Online, Fecha de Acceso: Mayo [Cor08c] Microsoft Corporation. Xbox live community games. Online, Fecha de Acceso: Abril events/gdc2008/xna/default.htm. [Cry08a] Crytek. Crysis. Online, Fecha de Acceso: Mayo [Cry08b] Crytek. Transition to Scrum midway through a AAA Development Cycle: Lessons Learned. In Game Developer Conference, Marzo [Dem08] Thomas Demachy. Extreme Game Development. Online, Fecha de Acceso: Mayo /demachy_01.shtml. [djrs + 06] Javier García de Jalón, José Ignacio Rodríguez, José María Sarriegui, Alfonso Brazález, y Manuel González. Aprenda C++ como si estuviera en primero. In Aprenda... como si estuviera en primero. Universidad de Navarra, 2006.

69 68 BIBLIOGRAFÍA [dpcyt08] Agencia Nacional de Promoción Científica y Tecnológica. Bases del llamado para la adjudicación de aportes no reembolsables para pymes del sector de la industria del software. Reporte técnico, Ministerio de Ciencia, Tecnología e Innovación Productiva - Fondo Fiduciario de Promoción de la Industria del Software, [Duf08] Jill Duffy. Ask the Experts: Console vs PC Development. Online, Fecha de Acceso: Octubre features/513/ask_the_experts_console_vs_pc_.php. [Ecl08] Eclipse.org. Online, Fecha de Acceso: Diciembre [ESA08] ESA. Essential facts about the computer and video game industry. Reporte técnico, Entertainment Software Association, [Fla09] Adobe Flash Player. Online, Fecha de Acceso: Mayo [Fou08] [Fou09] Eclipse Foundation. Eclipse Process Framework Project homepage. Online, Fecha de Acceso: Noviembre Symbian Foundation. About the Symbian Foundation. Online, Fecha de Acceso: Marzo [Gam08a] Gamasutra. Features - postmortem. Online, Fecha de Acceso: Abril php\?category=5. [Gam08b] Moby Games. Titus interactive. Online, Fecha de Acceso: Junio [Gar08] [GHJ95] GarageGames. Torque Game Builder. Online, Fecha de Acceso: Mayo Erich Gamma, Richard Helm, y Ralph E. Johnson. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley Longman, Amsterdam, 1st ed., reprint. edition, [GIM09] Gimp. Online, Fecha de Acceso: Agosto [Goo09] Google Talk. Online, Fecha de Acceso: Mayo [Gro08] Object Managment Group. Software and Systems Process Engineering Metamodel Specification, version 2.0, Abril [Hig08] High Moon Studios. Online, Fecha de Acceso: Julio

70 BIBLIOGRAFÍA 69 [IGD08] IGDA. Playfirst Services. Online, Fecha de Acceso: Abril [Ing09] Ingenio. Ingenio - Incubadora de Empresas de Base Tecnológica. Online, Fecha de Acceso: Abril [IPc09] IPcom. Online, Fecha de Acceso: Marzo [ISF07] ISFE. Key Facts - The profile of the european videogamer. Reporte técnico, Interactive Software Federation of Europe, [JAV09] Java Web Start. Online, Fecha de Acceso: Marzo javawebstart/index.jsp. [jmo08] jmonkeyengine.com. Online, Fecha de Acceso: Agosto [Kei09] Clinton Keith. Advanced Scrum and Agile Development. In Game Developer Conference, Marzo [Lar03] Craig Larman. Agile and Iterative Development: A Manager s Guide. Addison Wesley, ISBN [Lar08] Large Animal Games. Online, Fecha de Acceso: Abril [Lew08] [Llo08a] Mike Lewis. Agile Development - Inside the GDC Online, Fecha de Acceso: Abril asp\?id=1351. Noel Llopis. By the Books: Solid Software Engineering for Games. Online, Fecha de Acceso: Abril [Llo08b] Noel Llopis. A day in the life. Online, Fecha de Acceso: Mayo [Llo08c] [LS08] Noel Llopis. GDC 2004: Software Engineering Roundtable Summary. Online, Fecha de Acceso: Abril Noel Llopis y Brian Sharp. By the Books: Solid Software Engineering for Games. Online, Fecha de Acceso: Abril [LWJ08] Lightweight Java Game Library. Online, Fecha de Acceso: Agosto

71 70 BIBLIOGRAFÍA [Man08] Agile Manifesto. Manifesto for Agile Software Development. Online, Fecha de Acceso: Mayo [Mav09a] Maven. Online, Fecha de Acceso: Enero [MAV09b] Maven Release Plugin. Online, Fecha de Acceso: Agosto [McC96] Steve McConnell. Rapid Development. Microsoft Press, ISBN [Mic08] Sun Microsystems. Java. Online, Fecha de Acceso: Diciembre [Mic09] Sun Microsystems. Mobile java. Online, Fecha de Acceso: Abril [MSD09] MSDN. Active X control. Online, Fecha de Acceso: Abril [MTV09] MTV. Music television. Online, Fecha de Acceso: Mayo [Méx09a] Sony México. Playstation 3. Online, Fecha de Acceso: Abril [Méx09b] [Mys08] Sony México. Psp - playstation portable. Online, Fecha de Acceso: Abril Computer Games and Games Download. Online, Fecha de Acceso: Marzo [Net09] Cartoon Network. Online, Fecha de Acceso: Abril [Nic09] Nickelodeon. Online, Fecha de Acceso: Abril [Nin08a] Nintendo. What is Nintendo DS? Online, Fecha de Acceso: Mayo [Nin08b] Nintendo. What is Wii? Online, Fecha de Acceso: Mayo [Okt05] [Onl08] Hanna Oktaba. Modelo de Procesos para la Industria de Software. Facultad de Ciencias, Universidad Autónoma de México, ABS CBN News Online. Mobile phone users top 3.3 billion by end-2007: report. Online, Fecha de Acceso: Junio

72 BIBLIOGRAFÍA 71 [OPE09a] OpenAL. Online, Fecha de Acceso: Agosto [OPE09b] OpenGL. Online, Fecha de Acceso: Agosto [OPP07] OPP. Plan de Refuerzo de la Competitividad. Reporte técnico, Oficina de Planeamiento y Presupuesto, [PF02] Stephen Palmer y John Felsing. A Practical Guide to Feature-Driven Development. Prentice-Hall, ISBN [PHO09] Adobe Photoshop CS4. Online, Fecha de Acceso: Agosto [Pla08a] PlayFirst. Earn Cash with Playfirst s Second Annual Developer Dash! Online, Fecha de Acceso: Abril [Pla08b] PlayFirst. It s my time to play. Online, Fecha de Acceso: Mayo [Pla08c] PlayFirst. Playground SDK. Online, Fecha de Acceso: Mayo [Pop03] Mary Poppendieck. Lean Software Development: An Agile Toolkit for Software Development Managers. Addison-Wesley Professional, ISBN [Pop08] PopCap. Online, Fecha de Acceso: Mayo [Pow08] Powerful Robot Games. Online, Fecha de Acceso: Marzo [PPTD09] Fábio Petrillo, Marcelo Pimenta, Francisco Trindade, y Carlos Dietrich. What went wrong? A Survey of Problems in Game Development. Computers in Entertainment, 7(1), [Pro09] Pronanima. Proanima - Uruguay. Online, Fecha de Acceso: Abril [QUA09] QUALCOMM. About Brew. Online, Fecha de Acceso: Agosto [Rey99] Craig Reynolds. Steering Behaviors for Autonomous Characters. In Game Developer Conference, [SB01] Ken Schwaber y Mike Beedle. Agile Software Development with Scrum. Prentice Hall PTR, ISBN

73 72 BIBLIOGRAFÍA [SCE09] Scene Monitor. Online, Fecha de Acceso: Marzo [SDL08] SDL. Simple Directmedia Layer. Online, Fecha de Acceso: Mayo [Sen08] [SHA08] Kef Sensei. Kef Sensei :: We Master Fun :: Home. Online, Fecha de Acceso: Marzo Shadow Mapping and Shadow Volumes. Online, Fecha de Acceso: Agosto [Sho09] Adobe Shockwave Player. Online, Fecha de Acceso: Mayo [Sky09] Skype. Online, Fecha de Acceso: Abril [SPR09] SpringSource.org. Online, Fecha de Acceso: Agosto [Sub08] Subversion. Online, Fecha de Acceso: Diciembre [Ter07] [Tob08] Henrik Terävä. Software Process Modeling with Eclipse Process Framework and SPEM 2.0. Tesis de Maestría, Universidad de Turquía, Octubre Bliksem Tobey. Introducing Scrum at Large Animal Games: A look back at the First year of agile development. Online, Fecha de Acceso: Mayo [Tra09] The Trac Project. Online, Fecha de Acceso: Enero [Ubi09] Ubisoft. Online, Fecha de Acceso: Mayo [UCl09] Uclick. Online, Fecha de Acceso: Mayo [WMR + 05] D. Wisniewski, D. Morton, B. Robbins, J. Welch, S. DeBenedictis, E. Dunin, J. Estanislao, D. James, G. Mills, G. Walton, y J. Valadares Mobile Games White Paper. Reporte técnico, International Game Developer Association, [Wol07] Mark J. P. Wolf. The Video Game Explosion: A History from PONG to PlayStation and Beyond, chapter 1. Greenwood Press, ISBN X.

74 BIBLIOGRAFÍA 73 [WR06] Margaret Wallace y Brian Robbins Casual Games White Paper. Reporte técnico, International Game Developer Association, [XST09] XStream. Online, Fecha de Acceso: Mayo

75 Glosario AAA Denominación que se les da a los videojuegos en cuyo desarrollo se invierte un gran presupuesto. Advergaming Es la práctica de utilizar un videojuego para publicitar un producto, organización o punto de vista. API Aplication Programming Interface Es una interfaz que define la manera en que los programas utilizan los servicios de las bibliotecas o sistemas operativos. Biblia de arte Documento que describe la estética del videojuego y todos los objetos visuales a ser creados. Incluye los bocetos de personajes, escenarios, descripción de los modelos 2D y 3D, animaciones, etc. Biblia de diseño Bilboard Blog 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. Elemento del mundo 3d que siempre apunta a la cámara. 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 Cluster Es un ciclo donde se procesa la entrada del usuario y se actualiza el estado del videojuego. 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.

76 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, concepto, 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 Gameplay HUD Mesh Estructura de soporte definida en la cual otro proyecto de software puede ser organizado y desarrollado. Típicamente, puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otras piezas de software para ayudar a desarrollar y unir los diferentes componentes de un proyecto. Representa la experiencia que vive un jugador durante la interacción con un sistema de juego. 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. 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, cuadrilá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.

77 76 Glosario Niveles PDA Powerup Publisher Scripts Shaders Elemento en el que se subdivide un videojuego, el cual tiene asociado su propio objetivo y desafíos a cumplir. 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. Son elementos que un personaje puede adquirir y que aumentan sus habilidades. Empresa que se dedica a financiar empresas de desarrollo y vender sus videojuegos. Un script o archivo de órdenes o archivo de procesamiento por lotes es un programa usualmente simple, que generalmente se almacena en un archivo de texto plano y es interpretado en tiempo de ejecución. 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).

78 Anexos 77

79 A Gestión del Proyecto 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 planificadas de antemano sino que surgen a partir de reuniones de coordinación entre el grupo y los tutores. En la sección A.1 se comentan las principales actividades de cada fase, mientras que en la sección A.2 se presenta el cronograma de cómo transcurrió el proyecto. A.1 Fases y Actividades Durante la fase de Relevamiento de la Industria de Videojuegos en Uruguay se prepararon y realizaron entrevistas a cuatro empresas de videojuegos de la industria local. Además, se realizó un análisis que permitió identificar las características propias de la industria local, las virtudes y carencias que presentan las empresas en cuanto a su metodología de desarrollo y los problemas y desafíos que enfrentan al realizar videojuegos. En la fase de Relevamiento del Estado del Arte se investigaron los conceptos generales sobre videojuegos, su industria y las metodologías de desarrollo que se aplican. Por lo detectado se profundizó en el estudio de metodologías ágiles para videojuegos. También se estudió el Modelo de Procesos para la Industria del Software (Mo- ProSoft) [Okt05] como una posible alternativa para la gestión de negocios dentro de la metodología. En la fase de Definición del Alcance se determinó la metodología a realizar, mediante el estudio de distintas alternativas sobre el nivel de granularidad al cual llegar, sus objetivos y su público objetivo. Durante la fase de Construcción de la Metodología se seleccionaron las herramientas y estándares para especificar la metodología. Con ellos se realizó la definición del ciclo de vida, roles, actividades, tareas, pasos y guías de la metodología propuesta. En la fase de Caso de estudio se definió y realizó un prototipo de videojuego. También se analizaron los resultados de evaluar la metodología para posteriormente realizar ajustes. La ejecución del caso de estudio en el cronograma del proyecto se

80 ANEXO A. GESTIÓN DEL PROYECTO 79 presenta en dos etapas ya que se detuvo su ejecución en espera de su evaluación por parte de los tutores y luego se retomó para realizar ajustes al videojuego entregado. La fase de Análisis y Ajustes consistió en la determinación y realización de los ajustes a la metodología, detectados a partir del análisis de la ejecución del caso de estudio. En la fase de Documentación se documentaron las entrevistas realizadas, el análisis de la industria local, el estado del arte sobre conceptos de videojuegos (modelos de negocio, cadena de valor, tipos de juego, carreras, etc.) y el análisis de metodologías utilizadas en el desarrollo de videojuegos (procesos, roles, fases, etc.) junto con el análisis del caso de estudio. En esta fase se incluyen la construcción y revisión de las publicaciones realizadas durante el transcurso del proyecto. También se incluye el tiempo dedicado a la confección del informe final. A.2 Cronograma El cronograma que se muestra en la Fig.A.1 representa el tiempo transcurrido en semanas entre el comienzo y fin de cada fase presentada anteriormente. Además, se presentan las principales actividades realizadas en cada una de las fases.

81 80 A.2. CRONOGRAMA Figura A.1: Cronograma de Fases del Proyecto

82 B Relevamiento de Empresas de Videojuegos en Uruguay Este anexo presenta la información relevada en las entrevistas realizadas a empresas desarrolladoras de videojuegos en Uruguay. Las personas entrevistadas personalmente fueron: Fernando Sansberro (director de Batovi Game Studio), Ernesto Rodríguez (diseñador de juegos en Powerful Robot Games), Eli Barnett (director de Kef Sensei) y Gabriel Gambetta (director de Mystery Studios). Todas las entrevistas se llevaron a cabo entre marzo y abril de La información se estructura en base a las preguntas realizadas. En la sección B.1 se presenta la historia de cada empresa. En la sección B.2 se muestra la infraestructura, tecnología y herramientas con las que trabaja cada empresa. En la sección B.3 se resumen distintos aspectos de negocios de las empresas como ser sus estrategias de financiamiento, clientes, proyectos y planes futuros. En la sección B.4 se presenta la conformación de los equipos de trabajo, y por último, en la sección B.5 se especifican las diferentes metodologías de desarrollo utilizadas en cada una de las empresas. B.1 Historia Esta sección presenta lo relevado en cuanto a los comienzos y el desarrollo hasta el día de hoy de cada una de las empresas. B.1.1. Batovi Game Studios Comienza como un emprendimiento personal de Fernando Sansberro a mediados del año Su objetivo primario era vivir exclusivamente del desarrollo de videojuegos. Desarrollan videojuegos para Dispositivos Móviles en los dos primeros años. Con uno de ellos obtienen el segundo premio en un concurso de Nokia en Argentina. En el 2004 continúan desarrollando videojuegos para Dispositivos Móviles y además realizan trabajos de programación para empresas como Powerful Robot Games, NGD Studios e In-Style Software. Finalmente, en el 2005 unen fuerzas con la empresa IPcom, quien invierte para materializar realmente el proyecto. 81

83 82 B.2. INFRAESTRUCTURA, TECNOLOGÍAS Y HERRAMIENTAS B.1.2. Kef Sensei Surge en el año 2007 a partir de otra empresa que se dedica al desarrollo de software convencional en la modalidad de outsourcing. Esta empresa realizaba algunos videojuegos en Flash del tipo Casual con el modelo de negocios Advergaming a pedido de clientes por lo que vislumbran la posibilidad de negocio en el área. Al comenzar estudian la industria de videojuegos en distintos aspectos (tipos de juegos, modelos de negocio, infraestructura necesaria, etc.) y determinan que van desarrollar videojuegos del tipo Casual con el modelo de ingreso Probar Antes de Comprar. Concluyen esto dado los recursos con los que cuentan, los riesgos que pueden enfrentar, y fundamentalmente su interés por este tipo de videojuego. Su única implementación consiste en un prototipo con el cual participan a una competencia impulsada por PlayFirst denominada Developer Dash. Resultan ganadores y obtienen un contrato para terminar el desarrollo del prototipo presentado. Actualmente están trabajando en ese proyecto. B.1.3. Powerful Robot Games Gonzalo Frasca y Sofía Battegazzore la fundan en en 2002 por dado que se vislumbra la oportunidad de negocio por los contactos y participación de Frasca en la industria de videojuegos. Esto les permite conseguir proyectos desde el comienzo. Basan sus desarrollos principalmente en videojuegos de tipo Casual con el modelo de ingreso Advergaming. La empresa es reconocida por su éxito en el mercado llamado Foster s home for Imaginary Friends que desarrollaron para Cartoon Network. B.1.4. Mystery Studios Gabriel Gambetta junto con su hermana Florencia y un compañero de facultad, Esteban Guelvenzu, hacen su primer videojuego en junio del Este fue un fracaso en términos económicos, pero les permite insertarse en el mercado de los videojuegos del tipo Casual. Dado que la mayoría de los jugadores de videojuegos del tipo Casual son mujeres, tienen la idea de hacer un videojuego donde la protagonista fuera una mujer. Este videojuego es el Betty s Beer Bar y en un principio fue rechazado porque era totalmente distinto a todo lo que había en ese momento. Igualmente, algunos portales si lo aceptaron y tuvo éxito, incluso más de lo que esperaban. En los años 2005 y 2006 este videojuego marcó una tendencia, ya que en esos años los videojuegos casuales más vendidos eran de ese estilo. Tras el éxito del Betty Beer s Bar realizan otros videojuegos entre los cuales está el Wild West Wendy, que fue muy superior al anterior tanto en el aspecto gráfico como en los algoritmos de inteligencia artificial. A partir de allí tuvieron muchos proyectos tanto propios como para clientes y se consolidaron como empresa de videojuegos. B.2 Infraestructura, Tecnologías y Herramientas Esta sección presenta lo relevado en lo relativo a los recursos físicos y técnicos de las empresas.

84 ANEXO B. RELEVAMIENTO 83 B.2.1. Batovi Game Studios Trabajan en una oficina con ocho PC (una para cada miembro del equipo) con sistema operativo Linux y un servidor para el desarrollo. Utilizan Flash y Director para desarrollo videojuegos para la plataforma Web. En los videojuegos para Dispositivos Móviles usan Java (J2ME), Eclipse ME y los SDK y emuladores que brindan los fabricantes (Nokia, Motorola, Siemens, Sony Ericsson, etc.). Para los videojuegos de PC emplean Torque Game Builder. Cuando trabajan para un cliente que necesita verificar lo que están haciendo, tienen un servidor para versionado de código (SVN) y para seguimiento de errores. En otros casos no lo utilizan aunque reconocen que sería una buena práctica. B.2.2. Kef Sensei Cuentan con una oficina con varias PC de mediano porte, equipos Mac para poder verificar los videojuegos desarrollados y una consola de Xbox para realizar prototipos de prueba. Utilizan C++ para la programación de la lógica y Lua para la lógica de interfaz gráfica. Como framework para desarrollo usan PlayGround, ya que les permite abstraer varias funcionalidades básicas como ejecutar scripts, cargar archivos de sonido o imágenes, dibujar en pantalla una imagen, etc. Cuentan además con otras herramientas como un editor de partículas y un editor de animaciones. También emplean herramientas de diseño gráfico como Photoshop. B.2.3. Powerful Robot Games Cuentan con una oficina donde existe una PC para cada desarrollador, además de distintas consolas de videojuegos tales como Nintendo DS, PSP, Gameboy. Desarrollan en Flash y Director, mientras que utilizan Processing como herramientas de prototipado. Utilizan herramientas para el seguimiento de errores y Photoshop para el diseño gráfico. Cuentan con emuladores como el Mame para probar videojuegos existentes y extraer ideas de los mismos. B.2.4. Mystery Studios Su lugar físico de trabajo es una habitación en la casa de Gabriel Gambetta. Allí tienen tres PC (una para cada integrante), un servidor para versiones y respaldos, dos computadoras portátiles, un ibook y una Mini Mac. Utilizan el lenguaje C++ y cuentan con un framework de desarrollo implementado por ellos que les permite escribir código portable a Windows, Linux y Mac. Este framework funciona con SDL, Direct3d y OpenGL. B.3 Aspectos de Negocio Esta sección presenta lo relevado respecto a los tipos de proyectos, clientes, la forma de comercialización de sus videojuegos y la estrategia a futuro de la empresa.

85 84 B.3. ASPECTOS DE NEGOCIO B.3.1. Batovi Game Studios Su estrategia de negocio se basa en realizar desarrollos de videojuegos que estén financiados totalmente por sus clientes para no correr con riesgos económicos. Además, por ser un departamento de IPcom tienen asegurado el financiamiento para los costos de la empresa en caso de necesitarlo. Desarrollan videojuegos Casuales para las plataformas PC, Web y Dispositivos Móviles y utilizan para estas el modelo de ingresos de Advergaming, Probar Antes de Comprar y Móviles respectivamente. En el caso de los videojuegos para Dispositivos Móviles ellos mismos han financiado sus proyectos. La duración de los proyectos va de un par de meses, en el caso de los más simples de Web y Dispositivos Móviles, a ocho meses en el caso de PC. Han trabajado para un gran número de clientes en muchos proyectos. Dado la larga trayectoria ya tienen clientes que los contactan por iniciativa propia. Otros los consiguen dado que tienen gente dedicada al marketing buscando oportunidades. A futuro están evaluando la posibilidad de hacer un videojuego financiado por ellos que sea portable a varias plataformas. B.3.2. Kef Sensei Su estrategia es presentar prototipos a los clientes para conseguir financiación. De esta forma logran solventar los costos del desarrollo y conseguir mejores beneficios a la hora de negociar dado que parte del desarrollo ya esta hecho. Se enfocan en videojuegos del tipo Casual para la plataforma Web y con el modelo de ingreso Probar Antes de Comprar. Los tiempos de los proyectos son cortos, entre dos y seis meses de duración. Su objetivo a futuro es crecer en cantidad de proyectos. Para esto, buscan al menos un contrato para realizar un proyecto más este año y duplicar esa cifra para el año B.3.3. Powerful Robot Games Todos los proyectos que realizan les son encargados por clientes, por lo que toda la etapa de desarrollo esta financiada por estos. La experiencia y la posición en el mercado hace que siempre tengan proyectos de este estilo para realizar lo cual cubre sus costos de operación. La mayoría de sus proyectos son videojuegos Casuales para la plataforma Web con el modelo de ingreso Advergaming, cuyo desarrollo lleva entre cuatro y cinco meses. Los contactos con los clientes fueron logrados gracias a la experiencia acumulada por Gonzalo Frasca en emprendimientos anteriores a la formación de la empresa, entre ellos su principal cliente Cartoon Network. A futuro piensan mejorar la organización del equipo estableciendo grupos fijos encargados del desarrollo de cada videojuego. Estos grupos estarían formados por uno o varios diseñadores gráficos y programadores. También tienen planeado comenzar a desarrollar videojuegos del estilo casual con financiamiento propio.

86 ANEXO B. RELEVAMIENTO 85 B.3.4. Mystery Studios Realizan proyectos financiados en forma propia y por clientes que por lo general duran alrededor de seis meses. Se enfocan en videojuegos del tipo Casual para PC y utilizan para las ventas el modelo de ingreso Probar Antes de Comprar. Nunca han utilizado el modelo de ingresos Advergaming porque no les rinde económicamente. Además de hacer videojuegos, ofrecen sus servicios como desarrolladores y artistas gráficos. También venden su plataforma de desarrollo para ser utilizada por otros desarrolladores. Sus clientes son publishers y portales, los cuales en un principio contactaban vía correo electrónico para lograr que distribuyeran sus videojuegos. Con el paso del tiempo y el éxito logrado, concretan distintos tipos de contrato que van desde desarrollos a pedido del cliente a venta de derechos y distribución de videojuegos de desarrollo propio. A futuro piensan seguir realizando videojuegos en los cuales un cliente les financie el desarrollo del proyecto. Esta decisión se debe a las características del mercado y a que no pueden asumir los riesgos económicos ante un fracaso. A su vez con estos ingresos buscan financiar sus propios videojuegos y así obtener mayor beneficio al momento de negociar su venta. También tienen planeado seguir creciendo en cantidad de proyectos que pueden abarcar al mismo tiempo. Para esto piensan mudarse este año a un local exclusivo para la empresa y contratar más personal, evitando así tener integrantes del equipo trabajando en forma independiente. Tienen la idea de asignar un desarrollador a cada proyecto y crear nuevos roles, en donde los integrantes del equipo con mayor experiencia participen en todos los proyectos solucionando las partes difíciles y realizando consultoría para explicar la forma de proceder. B.4 Equipos de Trabajo Esta sección presenta lo relevado respecto a la conformación del equipo de trabajo de las empresas, la cantidad de personas asignadas y sus roles dentro de un proyecto. B.4.1. Batovi Game Studios Se compone de cinco programadores y tres diseñadores gráficos. Además, por ser un departamento de IPcom tienen contador, profesor de inglés, secretaria y departamento de marketing. El diseño del videojuego es realizado por los programadores con mayor experiencia en el tipo de videojuego a desarrollar. Se cuenta también con el rol de productor para coordinar el trabajo del equipo e interactuar con el cliente. Normalmente por proyecto trabajan dos o tres personas, entre las que hay al menos un diseñador gráfico y un programador. Igualmente cuando las fechas límite lo requieren se puede sumar más gente al proyecto para cumplir con los plazos. B.4.2. Kef Sensei Cuentan con seis personas, donde tres son programadores y tres son artistas gráficos. Uno de los programadores, además, participa como productor. No tienen, aunque

87 86 B.5. METODOLOGÍA DE DESARROLLO les gustaría, una estructura basada en los roles de la industria de videojuegos ya que carecen el rol de diseñador de videojuego. Esto ocurre por no existir alguien con la formación académica específica en el equipo, por lo que el rol lo cubren entre todos los integrantes del mismo. B.4.3. Powerful Robot Games Se conforma de productores, administrativos, cinco programadores y siete artistas gráficos, siendo en total 20 personas. Abarcan los roles de diseñador de juego, programador, artista gráfico y encargado de producción. Este último que se encarga de la comunicación entre el diseñador del juego y los desarrolladores (programador y artista gráfico). En cuantos a los proyectos no tienen grupos de trabajo definidos aunque siempre intentan tener un solo programador por proyecto, el cual asume la responsabilidad total de la implementación del mismo. B.4.4. Mystery Studios Se compone de dos programadores y una directora de arte, contando además con artistas que trabajan en forma independiente. El equipo se subdivide en función de los proyectos, trabajando en todos al menos un programador, la directora de arte y un artista. B.5 Metodología de Desarrollo Esta sección presenta lo relevado en cuanto a las metodologías de desarrollo de las empresas para desarrollar sus videojuegos. Se abarca la concepción del videojuego, su planificación, construcción, disciplinas, verificación y la documentación que se realiza. B.5.1. Batovi Game Studios Para definir el concepto del videojuego a realizar se hace una tormenta de ideas entre todos los integrantes del equipo. En el caso de un videojuego financiado por un cliente normalmente está definida la temática o los personajes pero igualmente se producen ideas para hacer la propuesta definitiva. Es común que se realicen prototipos en papel o utilizar un pizarrón para discutir ideas de los videojuegos a desarrollar. Dado que la mayoría de sus proyectos son simples y tienen experiencia, comienzan a desarrollar el videojuego directamente sin realizar previamente prototipos de código. Sin embargo, en caso de proyectos más complejos suelen realizarlos para validar con el cliente. Para estimar tiempos no realizan análisis formal y se basan en su experiencia para determinar el cronograma. En los proyectos financiados por un cliente, las fechas de entrega vienen dadas y ellos las aceptan en base a su experiencia en ese tipo de videojuego. Implementan en iteraciones de corta duración para tener un nuevo ejecutable para probar cada aproximadamente dos semanas. Además, realizan reuniones diarias para

88 ANEXO B. RELEVAMIENTO 87 discutir el avance y las actividades del día. Se desarrolla el código del videojuego y el arte en forma paralela y por esta razón inicialmente los programadores utilizan sustitutos de arte. Generalmente el diseño gráfico del videojuego es realizado internamente, a excepció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 verificación funcional del videojuego, apelando principalmente a los errores visibles desde la interfaz gráfica. Cumplen la misma tanto internamente entre los integrantes del equipo como por medio de amigos y familiares a los que distribuyen el videojuego. Hay casos en los cuales el cliente se encarga de esta mediante sus departamentos de verificación, reduciendo así la responsabilidad de la empresa ante dicha tarea. En cuanto a documentación, cuando un cliente los financia realizan un documento de concepto y un documento de diseño de juego que puede variar en cantidad de hojas dependiendo de la complejidad del videojuego en cuestión. Cuando no se les requiere de entregar la documentación, no la realizan. B.5.2. Kef Sensei Los proyectos surgen desde el lado comercial ya que buscan realizar videojuegos que se adapten al mercado y conseguir un cliente que lo financie. Para definir el concepto del videojuego estudian el mercado y realizan una tormenta de ideas con la premisa de adaptar o extender el gameplay de videojuegos con probado éxito. Utilizan un pizarrón para registrar las ideas surgidas que se fotografía para tener de referencia. Utilizan prototipos evolutivos que sirven como forma de presentarse al cliente y lograr un contrato. También se utilizan para minimizar riesgos tecnológicos. Realizan estimaciones de la duración del proyecto para evaluar la factibilidad de lo que les presenta el cliente. La estimación se basan en su percepción de las tareas a realizar y de su experiencia en el desarrollo de software convencional. Para implementar realizan iteraciones cortas, de una o dos semanas, donde se desarrolla un entregable con una serie de características del videojuego. Al finalizar cada iteración se produce una reunión con el cliente para la validar la versión entregada. Resultado de este encuentro se encuentran errores a corregir, se detectan nuevas características y se planifican las siguientes iteraciones. El diseño del videojuego es realizado por todos los integrantes del equipo aunque no invierten demasiado tiempo en esta actividad dado que el gameplay de sus videojuegos no es original. El arte visual, al igual que el arte sonoro, es realizado por los diseñadores gráficos del equipo. Sin embargo, la empresa tiene pensado tercerizar el sonido a profesionales del área. Se verifica en cada iteración siguiendo los requerimientos acordados con el cliente. Esta verificación se realiza en base a una planilla que entrega el cliente sobre las características del videojuego a construir en la iteración así como sobre restricciones de hard-

89 88 B.5. METODOLOGÍA DE DESARROLLO ware o sistemas operativos. Para la verificación funcional, el videojuego se distribuye entre amigos y familiares. El cliente también se encarga de la verificación además de evaluar otros aspectos como ser curva de aprendizaje del juego, curva de dificultad, si el videojuego es intuitivo, atractivo, etc. La mayoría de la documentación la realizan como exigencia del cliente que los contrata. Entre la documentación exigida se encuentra el documento de diseño y una planilla de pruebas. Esta planilla sirve para comunicar los requerimientos mínimos de aceptación en cuanto verificación que se deben realizar para la liberación del videojuego (p.ej.: poder ejecutarse en Mac o en 800x600). Internamente utilizan una wiki para discutir y definir ideas además de documentar. B.5.3. Powerful Robot Games Todo proyecto comienza definiendo el concepto del videojuego con el cliente. Al utilizar el modelo de ingresos de Advergaming habitualmente el entorno y los personajes son definidos por el cliente. La parte creativa se acota a definir el género del videojuego a utilizar y para ello suelen basarse en referencias de videojuegos existentes que tuvieron éxito. Ya que es importante encontrar la diversión en forma temprana desarrollan prototipos para tomar decisiones respecto a diversos aspectos del videojuego. Existen muchos casos en donde por falta de tiempo el prototipo inicial que se realiza con sustitutos de arte se toma como base del videojuego final. Estiman en base a la experiencia previa adquirida por el desarrollo de videojuegos similares para determinar las fechas de entrega. La construcción del videojuego se realiza en forma secuencial, donde primero se realiza el diseño completo para luego pasarlo a los programadores y artistas para que estos lo implementen. El diseño del videojuego se concentra en pocas personas y para realizarlo se juegan videojuegos para obtener ideas y diseñar un gameplay atractivo. Esta investigación sirve también como base para construir el concepto de futuros videojuegos a desarrollar y para promover la creatividad del equipo a la hora de realizar la tormenta de ideas. Es una disciplina que se ejecuta en forma continua y existen características del videojuego que se cambian durante el desarrollo debido a que no son suficientemente divertidas o porque son demasiado costosas de realizar. Ya que generalmente sus proyectos son con el modelo de ingresos de Advergaming, es común que el cliente les provea referencias para que el artista gráfico utilice existiendo casos en donde les entregan bancos de imágenes reduciendo así su trabajo en esta área. En cuanto al sonido de los videojuegos la mayor parte de los proyectos lo tercerizan a una empresa local que se encarga de crear los sonidos requeridos. Suelen especificarles por medio de un documento datos genéricos cómo debería ser el sonido, por ejemplo si es un loop o no, cuál es la duración del mismo, una descripción del sonido y situaciones en las que se ejecuta. Hay casos en donde el propio cliente les entrega sonidos y bandas sonoras. No tienen definido un proceso formal de verificación. Suelen realizarlo entre los integrantes del equipo y generalmente le dedican poco tiempo por ser proyectos cortos y similares entre sí. En algunos casos el cliente cuenta con un equipo de verificación

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

91 90 B.5. METODOLOGÍA DE DESARROLLO mentado la posibilidad de enviar un correo electrónico con el reporte del error en caso de falla. En proyectos financiados por un cliente este se encarga de realizar las pruebas. Cuando se detectan errores se comunican utilizando herramientas de seguimiento de errores No realizan demasiada documentación principalmente porque son proyectos suficientemente simples técnicamente. Suelen usar listas de características y algún documento 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.

92 C Splinks Deathmatch - Documento de Concepto El propósito de este documento es introducir los conceptos y motivaciones del proyecto Splinks Deathmatch. En la sección C.1 se presenta la visión del videojuego. En la sección C.2 se define el género del videojuego. En la sección C.3 se presenta la mecánica de juego. En la sección C.4 se presentan las características del videojuego. En la sección C.5 se detalla el ambiente donde se lleva a cabo el videojuego. En la sección C.6 se presenta la historia del videojuego. En la sección C.7 se describe el público al que apunta el videojuego. En la sección C.8 se presenta la plataforma objetivo. En la sección C.9 las tecnologías y herramientas que se van a utilizar. Por último, en la sección C.10 se presentan algunos bocetos de arte. C.1 Visión Splinks Deathmatch es un juego 3D multijugador en donde podrás enfrentarte a tus amigos en un combate a muerte. Tu personaje es un Splink, un extraterrestre capaz de controlar cualquier tipo de criaturas con distintas habilidades y poderes. Utiliza las mejores combinaciones de personajes, habilidades y powerups para lograr estrategias únicas y vencer a tus oponentes. C.2 Género Es un juego de lucha multijugador, influenciado por los juegos Bomberman, Kong y Soldat. C.3 Mecánica de Juego Inicialmente, el jugador controla un Splink, con el cual puede moverse dentro de la arena de combate o poseer mentalmente a las criaturas. Una vez poseída la criatura, el jugador pasa a controlarla pudiendo golpear otras criaturas, pisar a los demás Splinks 91

93 92 C.4. CARACTERÍSTICAS y hacer uso de sus habilidades especiales. Además, puede desposeer a la criatura en cualquier momento. Existen diversos modos de juego: Competencia a muerte: el objetivo es eliminar a los demás Splinks y ser el único en permanecer vivo. Además, existe la posibilidad de jugar en equipos. Supervivencia por tiempo: el objetivo es permanecer vivo por el mayor tiempo posible, al morir se rota el turno al siguiente jugador y se reviven los jugadores muertos. Estas rondas se repiten varias veces y el ganador es el que logra la mejor suma de tiempos entre todas las rondas. Capturar la bandera: similar al modo anterior, el jugador debe intentar capturar la bandera y luego mantenerla el mayor tiempo posible. Al finalizar un tiempo determinado, el jugador que mantuvo la bandera mayor proporción de tiempo es el ganador. C.4 Características Varios modos de juego: competencia a muerte, sobrevivir el mayor tiempo, capturar banderas, etc. Capacidad de controlar varios tipos de criaturas con distintas habilidades y características como fuerza, velocidad, resistencia y poder mental. Jugar con amigos en una sola máquina o en una red local utilizando varios tipos de controladores. Un conjunto de powerups que hacen la experiencia del jugador mucho más divertida, controlando la velocidad del personaje, área de control mental, resistencia, inmortalidad, entre otros. Poder jugar campeonatos y guardar las puntuaciones y estadísticas para determinar quién es el mejor jugador. Distintos tipos de terrenos con relieves, tierra, agua, nieve, entre otros. C.5 Ambientación La civilización de los Splinks no posee una tecnología muy avanzada, en ciertos aspectos es muy parecida al pueblo romano, a sus casas y ciudades. Los lugares donde se realizan las luchas tienen una figura cilíndrica o rectangular (ej: plazas de toros, coliseo romano) como un anfiteatro con gradas precarias.

94 ANEXO C. CONCEPTO 93 C.6 Historia Los Splinks son la raza dominante en el planeta que habitan. Son débiles físicamente 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 planeta han podido crear una gran civilización. Además, tienen como tradición celebrar combates a muerte para determinar el ganador y hacerle entrega del título de campeón. Estos combates se celebran dentro de anfiteatros en los cuales el público puede alentar a sus luchadores favoritos. Dentro del área de combate se colocan diferentes criaturas que son controladas por los Splinks para matar a los demás. Estas criaturas no están domadas lo cual dificulta el control de los Splinks y hace más peligrosa la contienda. C.7 Público Objetivo Este juego está dirigido a jugadores sociales con cierta experiencia en videojuegos, ni casuales ni hardcore, que les gusta compartir un rato con amigos, posiblemente en un mismo espacio físico. C.8 Plataforma Objetivo Las plataformas objetivo son: Windows, Linux y posiblemente Mac OS u otros sistemas que soporten la máquina virtual de Java. C.9 Tecnologías y Herramientas El juego se desarrollará en Java, haciendo uso del motor 3D JMonkeyEngine y de las herramientas para generar contenido a ser usado por este. Para la codificación se hará uso del entorno de desarrollo Eclipse. Se cuenta con la posibilidad de utilizar controles de mando extra como el control de Xbox360 para Windows, entre otros. C.10 Bocetos A continuación se presentan los bocetos realizados.

95 94 C.10. BOCETOS Figura C.1: Bocetos de Alen Chimanosky Figura C.2: Bocetos de Leonardo Silva

96 ANEXO C. CONCEPTO 95 Figura C.3: Bocetos de Diego Tapié Figura C.4: Bocetos de Diego Tapié

97 96 C.10. BOCETOS Figura C.5: Bocetos de Javier Miles

98 ANEXO C. CONCEPTO 97 Figura C.6: Bocetos de Javier Miles

99 D Splinks Deathmatch - Documento de Diseño de Juego El propósito de este documento es especificar el diseño del videojuego Splinks Deathmatch. Este incluye la descripción de su mecánica de juego, la interacción con el usuario, los personajes y escenarios. En la sección D.1 se presenta la mecánica de juego. En la sección D.2 cómo se realiza la interacción con el usuario. En la sección D.3 cuáles son los personajes del videojuego. Por último, en la sección D.4 se detallan los escenarios del videojuego. D.1 Mecánica de Juego La partida comienza con varias criaturas y Splinks distribuidos por el área de juego. Controlando un Splink, cada jugador debe utilizar a las criaturas como medio para golpear a las demás hasta lograr que los Splinks que las poseen sean expulsados y así queden vulnerables a los pisotones. La escena está compuesta por el área de juego donde combaten los personajes y otros elementos externos como por ejemplo las gradas y puertas con los cuales no se puede interactuar. Durante la partida, aparecen criaturas y elementos coleccionables en posiciones aleatorias o preestablecidas cada cierto tiempo, hasta un máximo preestablecido. 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.

100 ANEXO D. DISEÑO DE JUEGO 99 La energía mental se recupera automáticamente cuando el Splink no está controlando a ninguna criatura. Las criaturas pueden golpear a las demás criaturas o pisar a los Splinks. Cuando una criatura recibe un golpe de otra criatura pierde energía vital dependiendo del daño de golpe, si pierde toda su energía vital, muere y si algún Splink la controla éste es expulsado. Cuando el Splink recibe un pisotón de una criatura, pierde energía vital dependiendo del daño de pisotón y muere si pierde toda su energía vital. D.1.2. Elementos Coleccionables Son elementos que el jugador puede adquirir y que modifican la mecánica del juego a partir de cambios en distintas propiedades de los personajes o del juego mismo. Estos elementos se activan al ser tocados por un personaje. Bomba: produce daño a la energía vital de los personajes dentro de un rango determinado con centro en el lugar donde se recoge. El rango puede ser aleatorio para cada bomba que aparezca y no es conocido hasta que se recoge, se debe mostrar gráficamente el rango de explosión. Modificadores de habilidades: producen distintos efectos sobre una de las habilidades del personaje (p.ej. la velocidad, el poder mental o la energía vital), pudiendo aumentar o disminuir temporalmente o de forma definitiva. Expulsar a los demás Splinks: mediante una descarga de energía permite expulsar de las criaturas y a los Splinks que están dentro del rango de la descarga con centro en el lugar donde se recoge. Inmortalidad temporal: el daño de todos los ataques que reciba el jugador quedan anulados durante un período de tiempo. D.1.3. Elementos de la Escena Son elementos de la escena que interactúan directa o indirectamente con los personajes modificando la mecánica del juego. Particularmente existen trampas que afectan de forma negativa sobre los personajes. Arenas movedizas: Es una trampa que puede aparecer en cualquier lugar del área de combate por un tiempo determinado y luego desaparece. Si una criatura o Splink cae dentro, puede ser succionada hacia adentro cuando desaparezca, teniendo unos pocos segundos para escapar. Cañones de fuego: Los cañones de fuego se ubican en las paredes del estadio. Se activan durante unos segundos cada cierto tiempo. Largan llamas capaces de quemar a cualquiera que esté a su alcance.

101 100 D.2. INTERACCIÓN CON EL USUARIO D.1.4. Modos de Juego El objetivo del juego es eliminar a los Splinks oponentes y permanecer con vida. Competencia a muerte: el objetivo es eliminar a los demás Splinks y ser el único en permanecer vivo. Cuando queda únicamente un Splink vivo el juego termina y el éste es el ganador. Competencia a muerte con regeneración: igual al modo competencia a muerte pero con una duración de tiempo fija y si un Splink muere regenera luego de cierto tiempo, el ganador es el que haya provocado más muertes de Splinks. D.2 Interacción con el Usuario El juego tiene una perspectiva 3D, los dispositivos con los que interactúa el usuario son el ratón y el teclado. Dentro del juego, puede realizar las siguientes acciones: Acciones de interacción con el juego. Otras Caminar con los personajes. Poseer criatura. Golpear criatura. Pisar Splink. Seleccionar criatura a poseer. 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 modificar. Cámara última posición: permanece fija en la posición de la última cámara y persigue al jugador.

102 ANEXO D. DISEÑO DE JUEGO 101 D.2.2. Controles En esta sección se explica como se realizan las acciones a partir de los dispositivos. Básicos El jugador puede mover a su personaje con las teclas W, A, S y D. Podrá seleccionar la cámara con las teclas 1-4 y dependiendo de esta, podrá rotarla moviendo el ratón. Con la tecla P puede pausar el juego, mientras que con Esc puede salir. Avanzados Dependiendo si el Splink del jugador está controlando mentalmente a una criatura o no, los tres botones del ratón permiten realizar diferentes acciones. Si no está controlando a una criatura entonces el usuario puede poseer una criatura con el botón izquierdo del ratón (siempre que está dentro de su rango de posesión) mientras que con el botón derecho puede seleccionar a que criatura (dentro del rango) poseer. Cuando se está controlando a una criatura, las acciones posibles son: golpe de puño con el botón izquierdo, pisotón con el botón derecho y abandonar a una criatura con el botón del medio del ratón. D.2.3. Información en Pantalla A continuación se describe la información que se presenta en pantalla durante el juego. Se separa esta información en dos grupos, información dentro de la escena e información en la interfaz de usuario (HUD). D Información de Escena Rango de control mental: alrededor del Splink del jugador se muestra un círculo a nivel del piso que indica hasta donde será capaz de saltar para controlar a una criatura. Si el Splink no tiene su energía mental completa, el círculo no se mostrará ya que será incapaz de controlar criaturas. Energía vital de los personajes: cada personaje distinto del Splink del jugador tiene una barra sobre su cabeza que indica la energía vital del mismo. El color varía de verde a rojo y disminuye su tamaño a medida que va perdiendo energía vital. Indicador de Splink del jugador: el Splink del jugador es remarcado, por ejemplo con el número o nombre del jugador en la cabeza del personaje. Criatura poseída: las criaturas poseídas tienen un Splink que la controla en la cabeza. Como cada Splink tiene un indicador de jugador, entonces se sabrá qué jugador controla a qué criatura.

103 102 D.3. PERSONAJES D 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 controlar. La criatura seleccionada será identificada con un triángulo amarillo sobre su cabeza. Información de Interfaz de Usuario (HUD) Radar: muestra las criaturas y Splinks dentro del área de juego. Ayuda a ubicarse e identificar a nivel global las amenazas o víctimas. Energía de control mental del Splink del jugador: se muestra una barra de energía de control mental que vara su color y tamaño dependiendo de la cantidad de energía que posee el Splink. Energía vital del Splink del jugador: se muestra una barra de energía vital que varía su color y tamaño dependiendo de la cantidad de energía que posee el Splink. Tiempo: se muestra el tiempo de la partida. En el modo Competencia a muerte con regeneración esta información toma mayor relevancia. Tiempo para regeneración: en el modo Competencia a muerte con regeneración, si el jugador está muerto, se muestra el tiempo que debe esperar para volver a jugar. Estadísticas: en el modo Competencia a muerte con regeneración se muestran estadísticas como por ejemplo la cantidad de muertes ocasionadas por cada Splink, posiblemente en forma de tabla. En la siguiente figura podemos ver un boceto de la información de interfaz de usuario. D.2.4. Pantallas A continuación se muestra un diagrama que muestra las pantallas que se esperan tener en el juego. D.3 Personajes D.3.1. En esta sección se describe cada uno de los personajes del juego. 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.

104 ANEXO D. DISEÑO DE JUEGO 103 Figura D.1: Información de interfaz de usuario Inteligencia Artificial Los Splink controlados por el computador tienen un comportamiento básico. Cuando 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 encuentra 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.

105 104 D.3. PERSONAJES Figura D.2: Pantallas del juego Inteligencia Artificial Las criaturas en general son tontas, vagan por el escenario sin importar que algún Splink los esté acechando. Evitan las paredes y a las demás criaturas si detectan colisión. Cada raza particular puede tener un comportamiento un poco diferente, algunas 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, resistencia vital, fuerza de golpe, fuerza de pisotón y resistencia mental. Razas Actualmente solo existe una raza llamada Urso.

106 ANEXO D. DISEÑO DE JUEGO 105 D.4 Escenarios El juego transcurre dentro de un estadio circular con características muy similares a un coliseo o plaza de toros. El área de combate debe ser suficientemente grande para que puedan competir al menos 4 jugadores con 4 criaturas a la vez. Actualmente existe un solo estadio aunque es deseable tener varios estadios para seleccionar donde jugar.

107 E Splinks Deathmatch - Documento de Diseño Técnico Este documento resume el diseño técnico del videojuego desarrollado, explicando cómo se resolvieron todos y cada uno de los problemas que se presentaron. En la sección E.1 se presentan las tecnologías seleccionadas. En la sección E.2 se detallan los estados de juego. En la sección E.3 se define cómo se manejó la escena. En la sección E.11 se detallan los controles que se utilizan en el videojuego. En la sección E.5 se presenta el manejo de las sombras. En la sección E.6 se describe el manejo de las colisiones. En la sección E.7 se muestra la maquina de estados por los que pasa el videojuego. En la sección E.8 se describen los controladores utilizados en el videojuego. En la sección E.9 se detalla la inteligencia artificial implementada. En la sección E.10 se presenta la información que aparece en pantalla. En la sección E.11 se muestran los contenidos audiovisuales. En la sección E.12 se presenta el manejo de liberaciones y versiones. Por último, en la sección E.13 se hace un resumen de las características no implementadas. E.1 Tecnologías Seleccionadas Para resolver el problema se seleccionaron un conjunto de herramientas tanto para la generación de contenidos como para la implementación del videojuego. E.1.1. Generación de Contenidos El desarrollo de contenidos fue realizado tanto por el equipo externo de artistas gráficos (modelos 3D y texturas) como por el equipo interno al desarrollo (audio y algunas texturas). Se utilizaron las herramientas 3D Studio [3DS09] para la generación de modelos y animaciones 3D, Gimp [GIM09] y Photoshop [PHO09] para la generación de texturas y Audacity [AUD09] para generar los efectos y bandas sonoras. E.1.2. Implementación Se utilizó el motor de juego jmonkeyengine [jmo08] que dibuja en pantalla utilizando Lightweight Java Game Library (LWJGL) [LWJ08]. LWJGL es una biblioteca

108 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 componentes. Figura E.1: Diagrama de componentes Además, se utilizaron otras herramientas cuya descripción se presenta más adelante en este capítulo. E.2 Estados del Juego El videojuego pasa por distintos estados durante su ciclo de vida, en la Fig.E.2 se puede apreciar el diagrama de esta máquina de estados. Figura E.2: Estados por los que pasa el videojuego El videojuego comienza en el estado de inicio/carga el cual carga los recursos y

109 108 E.3. ESCENA muestra una pantalla con la portada y una barra de progreso. Cuando la carga termina se dirige al estado de tutorial el cual muestra una pantalla que explica las reglas del juego y los controles. Cuando el usuario quita la pausa, se dirige al estado de juego el cual procesa la lógica del videojuego. Desde esta, el usuario puede volver a pausar para ver la pantalla anterior, o bien, cuando el jugador gana o pierde la partida se pasa al estado de fin de juego que se encarga de mostrar quien ganó la partida. E.3 Escena La escena se manejó utilizando la estructura de grafo de escena provista por el motor. Un grafo de escena es una estructura de datos que permite representar relaciones lógicas entre elementos del videojuego y fácil manipulación de estas. En la Fig.E.3 se presenta un diagrama simplificado del grafo de escena utilizado. Se utilizó la herramienta Scene Monitor [SCE09] para obtener información y modificar datos en tiempo de ejecución. Figura E.3: Grafo de escena de ejemplo. Por otro lado, también se definió una estructura propia para agrupar fácilmente elementos 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.

110 ANEXO E. DISEÑO TÉCNICO 109 El control de personaje permite controlar al personaje a partir de distintas acciones del jugador utilizando una combinación del teclado y el ratón. El primero se usó para determinar la dirección de movimiento mientras que el segundo para ejecutar las acciones del personaje (p.ej. controlar mentalmente). El control de cámara permite acercar, alejar, rotar y cambiar la altura de la cámara. Además, provee la posibilidad de elegir distintas cámaras. El control de estado de videojuego permite cambiar entre un estado u otro del videojuego (p.ej. pausar el videojuego o salir del mismo). Estos controles fueron implementados utilizando la clase Controller propia del motor, la cual es actualizada en cada ciclo de juego. Los controles determinan en cada actualización, a partir de las teclas o botones presionados, la acción a tomar. E.5 Sombras Para dibujar las sombras se utilizó el algoritmo shadow volumes [SHA08] de varias pasadas implementado por el motor gráfico, por lo que el problema se redujo a utilizarlo correctamente. Se proyectan únicamente las sombras de los personajes y se recalculan en cada actualización del ciclo de juego. Se utilizó la herramienta Shadow Tweaker 1, la cual permite manipular varios parámetros en el procesamiento de las sombras. En la Fig.E.4 se puede apreciar una imagen del videojuego con las sombras generadas. Figura E.4: Sombras de los personajes sobre el terreno. 1 Herramienta distribuida con el motor.

111 110 E.6. COLISIONES E.6 Colisiones En esta sección se explica cómo se resolvió cada uno de los tipos de colisiones del videojuego. Movimiento Las colisiones en el movimiento implican detectar cuándo un personaje no puede moverse debido a que hay un obstáculo. Los obstáculos pueden ser los delimitadores del área de juego u otros personajes. La estrategia utilizada consiste en determinar si la próxima posición de un personaje (usando el movimiento que corresponda) no presenta una colisión. Como el videojuego se desarrolla solamente sobre una altura determinada, se propone simplificar estas colisiones proyectando todo sobre el plano de juego y luego resolver colisiones simples con volúmenes acotantes en dos dimensiones. En la Fig.E.5 se muestra esta técnica. Figura E.5: Técnica para determinar si el movimiento presenta colisión Inteligencia Artificial La inteligencia artificial utiliza un comportamiento denominado obstacle avoidance, el mismo requiere determinar posibles colisiones para evitarlas. Para este comportamiento 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 posició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

112 ANEXO E. DISEÑO TÉCNICO 111 Figura E.6: Técnica de obstacle avoidance actual de la cámara, y que se proyecta hasta cortar con el volumen acotante. En caso de estar dentro no se hace nada, en caso de estar afuera del volumen se sobrescribe la posición de la cámara con la posición del punto de intersección. En la Fig.E.7 se presenta un diagrama de la técnica. Figura E.7: Diagrama de colisión de la cámara con el estadio. Ataque El ataque implica determinar cuando un personaje debe recibir daño de otro personaje que lo ataca. Se utilizaron dos estrategias distintas según el tipo de ataque: golpe o pisotón. A continuación se explica en que consiste la estrategia utilizada en cada caso. Golpe: consiste en añadir un volumen acotante invisible (una caja) al esqueleto de la animación del personaje y luego determinar colisión entre esta caja y el volumen acotante del objetivo. Esta estrategia provee de una gran precisión y velocidad de procesamiento, pero tiene la desventaja de que hay que generarlo en el momento de la construcción del modelo. En la Fig.E.8 se puede observar la caja de golpe.

113 112 E.7. MÁQUINA DE ESTADOS Figura E.8: Volumen acotante (en rosado) añadido al esqueleto de la criatura para determinar las colisiones del golpe. Pisotón: la estrategia utilizada consiste en determinar los personajes que están dentro de un círculo con centro en la posición de la criatura. A estos se les aplica un daño dependiente de la distancia entre la colisión determinada y el centro del círculo. En la Fig.E.9 se puede observar la técnica utilizada. Figura E.9: Técnica para la detección de pisotón. E.7 Máquina de Estados Cada personaje tiene un conjunto de estados que definen distintos comportamientos. Para esto, se plantea una máquina de estados donde distintas acciones del usuario o eventos internos al juego producen distintas transiciones. Considerando que el personaje consiste en un conjunto de controladores y componentes (que se describen en la próxima sección), cada estado implementa una lógica particular que determina qué controladores están activos o no, para lo que se utilizó el patrón de diseño State Pattern

114 ANEXO E. DISEÑO TÉCNICO 113 [GHJ95]. Se manejan dos tipos de estados, unos donde el jugador puede interactuar y otros de transición a otro estado. Un ejemplo de estado de transición es cuando el Splink salta a poseer a una criatura y el jugador solo puede observar mientras se ejecuta la lógica interna. A continuación se explica la máquina de estados de cada personaje. Splink A continuación se explican los estados del Splink. En la Fig.E.10 se puede apreciar la máquina de estados indicando las transiciones. Figura E.10: Máquina de estados del Splink Idle/Walking: Estado inicial. Durante este estado el jugador puede mover el Splink e intentar poseer criaturas. En este estado el personaje puede recibir ataques. GoingToPossess: Sucede cuando el Splink está yendo hacia la criatura, es un estado de transición y el jugador no puede realizar ninguna acción.

115 114 E.7. MÁQUINA DE ESTADOS Possessing: Sucede cuando está controlando una criatura, durante este estado todas las acciones del Splink son redirigidas hacia la criatura que está controlando. Unpossessing: Sucede cuando el Splink pierde control de la criatura y es lanzado hacia el terreno, es un estado de transición y el jugador no puede realizar ninguna acción. Attacked: Sucede cuando el Splink recibe un pisotón de una criatura, es un estado de transición y el jugador no puede realizar ninguna acción. Dying: Sucede cuando el Splink pierde toda su energía, es un estado de transición y el jugador no puede realizar ninguna acción. Criatura A continuación se explican los estados de la criatura. En la Fig.E.11 se puede apreciar la máquina de estados indicando las transiciones. Figura E.11: Máquina de estados de la criatura Idle/Walking: Estado inicial. Durante este estado el jugador puede mover la criatura y atacar otras criaturas o Splinks. En este estado el personaje puede recibir ataques.

116 ANEXO E. DISEÑO TÉCNICO 115 Attacking: Sucede cuando la criatura está atacando a otras criaturas o Splinks tanto por un golpe como por un pisotón. En este estado el personaje puede recibir ataques. Attacked: Sucede cuando la criatura recibe un golpe de otra criatura, es un estado de transición y el jugador no puede realizar ninguna acción. Dying: Sucede cuando la criatura pierde toda su energía vital, es un estado de transición y el jugador no puede realizar ninguna acción. E.8 Controladores y Componentes Cada controlador realiza una lógica específica. Cada personaje se compone de varios controladores que son activados o desactivados desde cada estado del personaje según corresponda para lograr el comportamiento necesario. Dentro de la lógica de los controladores se encuentra por ejemplo la de recuperar energía mental cada cierto tiempo. Todos los controladores son subclases de la clase Controller propia del motor. Esta se puede agregar a los nodos del grafo de escena y es actualizada en cada ciclo de juego para ejecutar una lógica específica. En Fig.E.12 se presenta, a modo de ejemplo, un diagrama simplificado que muestra alguna de las relaciones con la API del motor de juego. Estos se presentan a continuación. Figura E.12: Componentes y controladores RecoverPossessionEnergyController: se activa cuando el Splink no está controlando ninguna criatura. Recarga su energía cada cierto tiempo hasta el tope de energía.

117 116 E.8. CONTROLADORES Y COMPONENTES DecreasePossessionEnergyController: se activa en el momento que el Splink esta controlando una criatura. Descarga su energía cada cierto tiempo hasta el mínimo, en cuyo caso envía un evento para abandonar la criatura. CharacterAnimationController: actualiza la animación del modelo 3D actual. GravityController: activo tanto en el Splink como en la criatura. Se encarga de mantener al personaje a la altura del terreno. CharacterMoveController: se encarga de calcular la próxima posición de un personaje a partir de su posición, velocidad y aceleración actuales, implementando un movimiento rectilíneo uniformemente acelerado. Considerando si colisiona o no con otros elementos, aplica el movimiento correctamente o anula el movimiento, respectivamente. GoingToPossessController: se activa al momento de intentar controlar una criatura. Se encarga de mover al Splink hacia la criatura y se desactiva en el momento de alcanzarla. UnpossessController: se activa en el Splink en el momento de perder control sobre una criatura. Se encarga de moverlo hacia una posición aleatoria del terreno y se desactiva al llegar a ella. RouteCharacterController: se activa cuando muere un personaje. Se encarga de hacer desaparecer el cuerpo de a poco moviéndolo hacia abajo del terreno. RespawnCreaturesController: actúa a modo general y se encarga de regenerar criaturas en el área de juego en diversas posiciones preestablecidas cada un tiempo determinado hasta un límite de criaturas. Los componentes agrupan funcionalidad pero no son actualizados en el ciclo de juego. En particular se tienen los siguientes componentes: AttackComponent: concentra la lógica de detectar y realizar un ataque. Tiene varias subclases implementando diversas técnicas, en caso de detectar un ataque envía eventos correspondientes. BoundingAttackComponent: subclase de AttackComponent, detecta colisiones a partir de un volumen acotante vinculado al esqueleto del modelo (técnica vista en E.6). Utilizado para el golpe. DiskAttackComponent: subclase de AttackComponent, detecta colisiones a partir de un rango de distancia determinado a partir de la posición actual (técnica vista en E.6). Utilizado para el pisotón. HitPointsComponent: tiene la lógica de modificación de energía vital, enviando eventos en caso de llegar a cero.

118 ANEXO E. DISEÑO TÉCNICO 117 E.9 Inteligencia Artificial Para la implementación de la inteligencia artificial se usaron los conceptos expresados por Craig Reynolds en el artículo Steering Behaviors For Autonomous Characters [Rey99]. Un agente autónomo es un sistema situado en un entorno que siente este entorno y actúa sobre él, en el transcurso del tiempo, siguiendo sus propios propósitos. Se llama agente autónomo a los agentes que poseen cierto grado de movimiento autónomo. Si un agente autónomo se encuentra a una situación inesperada, como encontrar una pared en su camino, este tendrá la habilidad de responder y ajustar su movimiento como corresponda. El movimiento de un agente autónomo puede ser dividido en tres capas: Selección de acción: Esta parte del comportamiento del agente es responsable de elegir sus objetivos y decidir qué plan seguir. Dirección (steering): Esta capa es responsable de calcular las trayectorias requeridas para satisfacer los objetivos y planes establecidos por la capa de selección de acción. Los comportamientos de dirección (steering behaviors) son la implementación de esta capa. Ellos producen una fuerza de dirección que describe hacia donde debe moverse un agente y cuán rápido debe viajar para llegar a ese lugar. Locomoción: Es la capa inferior y representa los aspectos mecánicos del movimiento del agente. Indica cómo viajar de A hacia B. Por ejemplo, si se implementan las mecánicas de un camello y un tanque y luego se les da un comando para que viajen hacia el norte, usarán diferentes procesos mecánicos para crear movimiento a pesar de que su objetivo es el mismo. Separando esta capa, es posible utilizar los mismos comportamientos para diferentes tipos de locomoción. Se implementaron inteligencias artificiales para las criaturas libres y para los Splinks que no son controlados por un jugador. Criatura: se intenta lograr que se mueva por el área de juego de forma natural evitando obstáculos. Se manejan los comportamientos de wander y obstacle avoidance. Splink: se busca que parezca controlado por otro jugador humano. Inicialmente se mueve por la escena en busca de una criatura libre para poder controlarla. En caso de que exista criatura libre suficientemente cerca, la persigue hasta controlarla. 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 determina 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

119 118 E.10. INFORMACIÓN EN PANTALLA el segundo caso se maneja el comportamientos de chase splink y obstacle avoidance. A continuación se explica cada uno de los comportamientos nombrados. Wander: el personaje determina una posición aleatoria en el área de juego y luego se mueve hacia allí. Obstacle avoidance: cuando el personaje detecta en su ruta un obstáculo, intenta evitarlo. Chase creature: sucede cuando el Splink no está controlando ninguna criatura e intenta controlar alguna. Para ello primero elige la criatura más cercana dentro un rango y luego la persigue. Chase splink: sucede cuando el Splink está controlando una criatura e intenta eliminar a los demás Splinks. Para ello primero elige al Splink más cercano dentro de un rango y luego lo persigue. E.10 Información en Pantalla Se describen los elementos de información en pantalla durante el estado de juego y se explica cómo se implementaron. Estos elementos se separan en dos grupos, los del Head-up Display (HUD) y los de la escena. Dentro de los elementos del HUD se encuentran las barras de energía vital y energía mental del personaje del jugador y el radar como se pueden apreciar en la Fig.E.13. Dentro de los elementos de escena se encuentran las barras de energía de las criaturas y los Splinks enemigos, la selección de criatura a controlar y el círculo que denota el rango de control mental del Splink. En el documento de diseño anexo D se describe cada uno de ellos, en la Fig.E.14 se puede apreciar el resultado final. Se sigue el patrón de diseño Model View Controller. Algunos elementos gráficos se implementaron directamente como subclases de Controller de la API del motor, agrupando tanto el view como el controller. Otros se separaron teniendo un controller encargado de actualizar el view a partir de elementos del model (entidades de juego). En la Fig.E.15 se presenta un diagrama de clases reflejando el segundo caso. RadarController: se encarga tanto de determinar donde están los personajes como de dibujar el radar, dibujando un círculo verde para el jugador, un círculo rojo para cada Splink contrario y un círculo blanco para las criaturas. CircleRangeController: se encarga de mostrar u ocultar un círculo que determina el rango de control mental del Splink. SelectTargetController: se encarga de indicar que criatura tiene seleccionada el jugador para ser controlada por su Splink.

120 ANEXO E. DISEN O TE CNICO 119 Figura E.13: Componentes gra ficos del HUD CharacterStatusController: se encarga de actualizar un View determinado pasa ndole un conjunto de valores de un personaje (p.ej. la energı a vital). SplinkStatusController: similar al anterior pero utilizando datos especı ficos del Splink. BarView: se encarga de dibujar en el HUD una barra a partir de un valor actual y un valor total y de una interpolacio n de dos colores, uno para cuando la barra esta llena y otro para cuando esta vacı a. SceneBarView: igual al anterior pero se dibuja dentro del grafo de escena, como un bilboard. E.11 Contenidos Para los modelos 3D se utilizaron dos formatos, considerando si tienen animaciones o no. Estos fueron MD5 y OBJ respectivamente. El formato MD5 permite especificar tanto un mesh2 como las distintas animaciones3. La carga se hace utilizando la API provista por el motor para OBJ y una extensio n llamada MD5Importer para MD5. Para las texturas se utilizaron tanto JPG como PNG, el segundo en particular se utilizo 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 extensio n.md5mesh que tiene el modelo con su esqueleto. archivos con extensio n.md5anim que tienen las posiciones del esqueleto para cada animacio n. 3 Varios

121 120 E.11. CONTENIDOS Figura E.14: Componentes gráficos de la escena Para los sonidos y bandas sonoras se utilizó el formato OGG, la carga se realizó utilizando la API provista por el motor. Para la escena se definió un descriptor que especifica donde debe comenzar cada personaje y con qué propiedades. La carga se hace a través de una clase encargada de obtener la escena. En particular se realizaron dos implementaciones, una es por código (fija) y otra a partir de un XML, lo cual permite modificar la escena fácilmente. Se utilizó la biblioteca XStream [XST09] para implementar la transformación a XML de la escena de forma transparente. Para armar el contexto de la aplicación, especificando dependencias y configuraciones, se utilizó la biblioteca Spring [SPR09].

122 ANEXO E. DISEÑO TÉCNICO 121 Figura E.15: Diagrama de clases de los componentes gráficos E.12 Versionado y Liberaciones El control de versiones se realizó utilizando la herramienta subversion [Sub08] en conjunto con la herramienta trac [Tra09]. Para cada iteración del desarrollo se creó un hito con su nombre (p.ej. sprint1) en la herramienta trac, y dentro de este se agregaron todas las tareas a desarrollar. Al finalizar, se etiquetó la revisión de código implementada hasta el momento y se generó una liberación a partir de esta, que luego se publicó en la página web. Este proceso se automatizó con el plugin maven-release-plugin [MAV09b] de maven [Mav09a]. Finalmente, el videojuego fue puesto en producción usando la especificación Java Networking Launch Protocol (JNLP) para que los usuarios puedan descargarlo vía la tecnología Java Web Start [JAV09]. Esta maneja tanto la descarga del videojuego como las dependencias correspondientes a la plataforma del usuario final. E.13 Resumen En esta sección se presentan, a modo general, características deseadas que no se implementaron 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.