Metodologías para el desarrollo de videojuegos

PEDECIBA Informática Instituto de Computación – Facultad de Ingeniería Universidad de la República Montevideo, Uruguay

Reporte Técnico RT 09-13 Una metodología para desarrollo de videojuegos: versión extendida

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

2009

Acerenza, Nicolás; Coppes, Ariel; Viera, Alejandro; Fernández, Eduardo; Laurenzo, Tomás; Vallespir, Diego. Una metodología para desarrollo de videojuegos: versión extendida ISSN 0797-6410 Reporte Técnico RT 09-13 PEDECIBA Instituto de Computación – Facultad de Ingeniería Universidad de la República Montevideo, Uruguay, 2009

Una Metodolog´ıa para Desarrollo de Videojuegos Versi´ on Extendida Nicol´ as Acerenza, Ariel Coppes, Gustavo Mesa, Alejandro Viera Eduardo Fern´ andez, Tom´as Laurenzo, y Diego Vallespir Instituto de Computaci´ on - Facultad de Ingenier´ıa Universidad de la Rep´ ublica, Uruguay {nicoace, ariel.coppes, gmhaisburu, aleviera6}@gmail.com {eduardof, laurenzo, dvallesp}@fing.edu.uy

Resumen. Tras relevar las empresas que desarrollan videojuegos en Uruguay, se detecta que son peque˜ nas en infraestructura, que abarcan generalmente proyectos de corta duraci´ on con equipos reducidos y que no cuentan con una metodolog´ıa para desarrollo formalizada. Las metodolog´ıas que utilizan siguen principios de las metodolog´ıas a ´giles que se adaptan con ´exito para el desarrollo de videojuegos a nivel mundial y aplican a realidades similares. En particular se registran casos de ´exito con adaptaciones de Scrum y XP, aunque ´estas tampoco se encuentran formalizadas. Este art´ıculo define y especifica SUM, una metodolog´ıa para el desarrollo de videojuegos que se adapta a las caracter´ısticas de la industria en Uruguay y sigue los principios a ´giles, utilizando Scrum y XP como base de la propuesta.

Palabras clave: procesos de desarrollo de software, ingenier´ıa de software emp´ırica, videojuegos, metodolog´ıas ´agiles.

1

Introducci´ on

Dos de los problemas que atentan contra el crecimiento de la industria de videojuegos en Uruguay son la falta de recursos econ´omicos y de una formaci´on espec´ıfica en el ´ area. Este u ´ltimo aspecto 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. El presente trabajo tiene como objetivo definir una metodolog´ıa para el desarrollo de videojuegos -que llamaremos SUM- la cu´al busca adaptarse a la realidad del Uruguay y hacer un aporte al desarrollo de su industria. En particular se toman Scrum y XP como base de SUM por la existencia de casos de ´exito y los beneficios que reportan para desarrollo de videojuegos. Adem´as, la actual utilizaci´ on de algunos de sus principios en la industria local facilitan su adopci´on.

2

El trabajo se estructura de la siguiente forma: en la secci´on 2 se presenta el estado del arte de las metodolog´ıas ´agiles para el desarrollo de videojuegos, y se hace foco en Scrum y XP para los cuales se describen sus caracter´ısticas y las adaptaciones en la industria. En la secci´on 3 se expone el relevamiento de la industria de videojuegos en Uruguay con una breve descripci´on de ella y el resumen de las metodolog´ıas seguidas. En la secci´on 4 se resumen los principales aspectos de la metodolog´ıa, sus roles y ciclo de vida. El detalle completo de SUM se encuentra publicado en [SUM09]. En la secci´on 5 se presentan las conclusiones y el trabajo que se lleva a cabo actualmente para evaluar la metodolog´ıa.

2

´ Metodolog´ıas Agiles para Videojuegos

La tendencia a utilizar metodolog´ıas ´agiles para videojuegos tom´o fuerza en los u ´ltimos a˜ nos por existir varios casos de empresas en la industria que logran adaptar estas metodolog´ıas y adem´as ser un tema actual en uno de los eventos principales como es la Game Developer Conference (GDC) [Kei09]. A pesar de esto, ninguna de estas adaptaciones est´a especificada formal y p´ ublicamente. Estos son los principales beneficios que reportan los casos de ´exito al utilizar metodolog´ıas ´ agiles: 1. Al ser metodolog´ıas iterativas e incrementales se obtienen versiones jugables del producto en intervalos regulares de tiempo. Esto facilita una visi´on temprana del resultado final del juego, lo cual reduce la probabilidad de cambios de requerimientos en forma tard´ıa y brinda una mayor retroalimentaci´on del cliente. 2. Permiten tener una mayor visi´on y control del avance del proyecto, tanto al cliente como a los desarrolladores. Esto se debe a que se pueden determinar nuevas estrategias, iteraci´on por iteraci´on, para lograr llegar en tiempo y forma a los plazos requeridos. 3. Involucran a todo el equipo en las decisiones, lo que logra compromiso y motivaci´ on. 2.1

Scrum

Scrum es una metodolog´ıa ´ agil para gerenciar y controlar el desarrollo de software de un producto en forma iterativa e incremental. Una de sus caracter´ısticas es que no indica pr´ acticas espec´ıficas a seguir durante el desarrollo [ASR02], lo que 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. Existen casos de empresas en la industria que logran adaptar esta metodolog´ıas para videojuegos y les reporta beneficios, por ejemplo High Moon Studios [Kei07], Large Animal Games [Tob08], Crytek [Cry08], Relic [Rel08], DICE [Nut08] y Nokia [Gam08]. Seg´ un la descripci´ on que realiza Ken Schwaber[SB01], Scrum se estructura en tres fases denominadas pre-game, game y post-game. Durante el pre-game se

3

define el producto basado en las caracter´ısticas conocidas, estimando su tiempo y costo. Tambi´en se analiza el sistema a construir, se define la arquitectura y se realiza un dise˜ no de alto nivel de la soluci´on. La fase de game consta de iteraciones, que duran de dos a seis semanas, donde se desarrollan las caracter´ısticas del producto. Al comienzo de cada una se realiza su planificaci´on, donde se describen, priorizan y estiman las caracter´ısticas que se van a desarrollar y al concluir se eval´ ua su resultado. El post-game es el cierre del proyecto, donde se prepara la liberaci´ on del producto, se verifican las versiones a entregar y se realiza la documentaci´ on final. 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 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. 2.2

Extreme Programming

Extreme programming(XP) es un proceso de desarrollo ´agil que puede ser usado por equipos de tama˜ no peque˜ no a mediano para desarrollar software de alta calidad en un tiempo previsible y con una sobrecarga de trabajo m´ınima [BA04]. En resumen, XP es una colecci´on de valores, derechos y buenas pr´acticas, las cuales han sido utilizadas durante a˜ nos en la industria de desarrollo de software. XP las identifica y las agrupa, ya que, us´andolas en conjunto, es cuando realmente se obtiene el mayor beneficio. En la industria de videojuegos, la empresa High Moon Studios [Kei08] reporta la utilizaci´ on exitosa de algunas de las pr´acticas de XP. A su vez Titus Interactive Studios plantea una propuesta de adaptaci´on de XP para el desarrollo de videojuegos llamada Extreme Game Development(XGD) [Dem08] en donde incorporan las pr´ acticas de XP a las diferentes disciplinas del desarrollo de videojuegos. No hay resultados publicados acerca de esta propuesta, ya que, la empresa cerr´ o antes de finalizar los proyectos que la segu´ıan.

3

Relevamiento de la Industria Uruguaya

Con la motivaci´ on de conocer la industria uruguaya de videojuegos se realizan entrevistas entre marzo y abril de 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. Las empresas relevadas fueron Batovi Game Studio [Bat08], Mystery Studios [Mys08], Powerful Robot Games [Pow08] y Kef Sensei [Kef08].

4

En resumen, la industria se caracteriza por ser joven (han transcurrido siete a˜ nos desde la fundaci´ on de la primer empresa), y por estar formadas por empresas peque˜ nas en infraestructura y en cantidad de personal (entre tres y quince personas por empresa). La mayor´ıa de los proyectos que se realizan se acotan a videojuegos de tipo casual o advergaming (videojuegos que publicitan una marca o producto) para las plataformas PC y web, cuyo desarrollo demanda entre dos y doce meses. Esto se debe a los recursos disponibles, tanto econ´omicos como de personal con la capacitaci´ on y experiencia necesaria. Sin embargo, la industria busca crecer econ´ omicamente, para ello la estrategia que plantean las empresas es desarrollar videojuegos por su propia cuenta o con financiamiento en etapas avanzadas del desarrollo como forma de mejorar los ingresos. Los equipos de desarrollo se conforman de tres a cuatro integrantes promedio, cubriendo los roles de productor, programador, artista gr´afico y dise˜ nador de juego. Los contenidos de audio son realizados por empresas externas especializadas, ya que no cuentan con personas capacitadas o econ´omicamente no lo consideran redituable. El productor se responsabiliza del seguimiento del proyecto y la comunicaci´ on con el cliente, generalmente es una u ´nica persona y participa en varios proyectos a la vez. El dise˜ no del juego es llevado a cabo en algunos casos por el integrante de mayor experiencia y en otros por todo el equipo. El proceso general de desarrollo 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´on 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. Esta es iterativa e incremental con ciclos de corta duraci´ on, donde en cada ciclo se dise˜ na, implementa y verifican un subconjunto de las caracter´ısticas del videojuego. Al final del ciclo se muestra el progreso logrado para evaluar el videojuego y realizar cambios sobre su especificaci´on. La segunda es secuencial, donde primero se realiza el dise˜ no completo de la soluci´on para luego implementar y posteriormente verificar. Una vez terminada la elaboraci´ on se realiza una verificaci´on 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´on final, la cual se distribuye de acuerdo al modelo de negocio determinado. La metodolog´ıa utilizada se ve influenciada por la forma de financiar el proyecto, se basan en su experiencia y no est´an formalmente definidas. Cuando la financiaci´ on es externa, quien financia, impone plazos, pr´acticas y entregables a generar durante el desarrollo. Esto hace que el proceso sea m´as ordenado y apunte a cumplir en tiempo y forma con los plazos impuestos. Quien financia se encarga adem´ as de la verificaci´on funcional externa, as´ı como del marketing y la distribuci´ on del videojuego. Esta modalidad de trabajo tiene como desventajas la p´erdida de autonom´ıa en cuanto a decisiones sobre aspectos del videojuego y la disminuci´ on 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´omicos. Todas las empresas adoptan esta modal-

5

idad, 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. Esta flexibilidad tiene como ventaja un mayor tiempo para crear elementos divertidos que hagan atractivo al juego, pero en contrapartida suponen el riesgo de invertir demasiado tiempo en busca de la perfecci´on. La verificaci´on funcional externa es menos formal ya que solamente se distribuye el videojuego entre conocidos, adem´as existe la posibilidad de negociar con m´as de un distribuidor. Esta modalidad permite a la empresa obtener mayores ingresos pero supone cargar con los riesgos de la inversi´ on. Las metodolog´ıas utilizadas para el desarrollo de videojuegos siguen principios ´ agiles por ser iterativas e incrementales, tener interacci´on frecuente con el cliente y ser flexibles ante los requerimientos cambiantes. Otra caracter´ıstica es que las decisiones se toman en base a la experiencia, sin existir un proceso definido ni t´ecnicas espec´ıficas a seguir. Para ello algunas empresas utilizan varias de las pr´ acticas de metodolog´ıas ´agiles conocidas como Scrum y XP.

4

Metodolog´ıa SUM para Videojuegos

Dado que no existe una metodolog´ıa ´agil formalmente especificada para el desarrollo de videojuegos se realiza una propuesta como aporte a la industria. La misma sigue los principios de las metodolog´ıas ´agiles y adapta la estructura y roles de Scrum. Esta adaptaci´on busca contemplar a la realidad relevada en la industria en Uruguay y resumir la experiencia de los casos que adaptan con ´exito estas metodolog´ıas para obtener sus beneficios. La metodolog´ıa SUM para videojuegos tiene como objetivo desarrollar videojuegos de calidad en tiempo y costo, as´ı como la mejora continua del proceso para incrementar su eficacia y eficiencia. 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 equipos multidisciplinarios peque˜ nos (de tres a siete integrantes que trabajan en un mismo lugar f´ısico o est´en distribuidos), y para proyectos cortos (menores a un a˜ no de duraci´ on) con alto grado de participaci´on del cliente. La definici´ on de la metodolog´ıa se basa en el Software and Systems Process Engineering Metamodel Specification(SPEM) 2.0 [Gro07], un meta-modelo para describir procesos y metodolog´ıa desarrollado por el Object Management Group (OMG). Una ventaja de utilizar SPEM es que su estructura permite especificar el proceso de desarrollo de videojuegos sin mencionar pr´acticas espec´ıficas, lo que lo hace flexible y adaptable a cada realidad. Para especificar la metodolog´ıa se utiliza Eclipse Process Framework (EPF) [Fou08] ya que provee un marco de trabajo extensible basado en los conceptos de SPEM 2.0 para definir y manejar procesos de desarrollo de software. SUM adapta para videojuegos la estructura y roles de Scrum descritas por Ken Schwaber [SB01]. Se utiliza esta metodolog´ıa ya que brinda flexibilidad para

6

definir el ciclo de vida y puede ser combinado f´acilmente con otras metodolog´ıas para adaptarse a distintas realidades. 4.1

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. Es necesario esta definici´on ya que se requiere una alta especializaci´on para satisfacer las distintas disciplinas que involucra del desarrollo de videojuegos, aspecto no contemplado en Scrum. ´ Estos se corresponden con los que se utilizan habitualmente en la industria local y son los de programador, artista gr´afico, artista sonoro y dise˜ nador de juego. El programador define la arquitectura, realiza el dise˜ no, implementaci´on y verificaci´ on de los componentes de software e integra el contenido audiovisual del videojuego. Los subroles de artista gr´afico y artista sonoro se encargan de la creaci´ on del contenido audiovisual del videojuego. El artista gr´afico realiza el arte de concepto, el arte 2D, el modelado 3D y la creaci´on de animaciones y texturas. El artista sonoro se encarga de la creaci´on, grabaci´on, mezcla y edici´on de los efectos de sonido y m´ usica del juego. Por u ´ltimo el dise˜ nador de juego es el encargado de dise˜ nar el gameplay, la historia, el ambiente, los personajes y todos los elementos que hacen a la experiencia del jugador. Adem´as, dise˜ na los niveles, misiones y los desaf´ıos que enfrenta el jugador. El rol de verificador beta no est´a 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´on funcional del videojuego y comunicar su resultado. Sin embargo puede no poseer experiencia ni ser jugador frecuente y participar igualmente de la verificaci´on, por ejemplo, al formar parte de un focus group del videojuego. 4.2

Ciclo de Vida

El ciclo de vida se divide en fases iterativas e incrementales que se ejecutan en forma secuencial con excepci´on de la fase de gesti´on de riesgos que se realiza durante todo el proyecto. Las cinco fases secuenciales son: concepto, planificaci´on, elaboraci´ on, beta y cierre, como se aprecia en la Fig.1. Las fases de concepto, planificaci´ on y cierre se realizan en una u ´nica iteraci´on, mientras que elaboraci´on y beta constan de m´ ultiples iteraciones. Las fases surgen como adaptaci´on al desarrollo de videojuegos de las fases pre-game,game y post-game que presenta Scrum, donde las dos primeras coinciden con las fases de planificaci´on y elaboraci´on, mientras que la tercera se corresponde con la fases de beta y cierre. Esta divisi´on 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 y se agrega ya que

7

Fig. 1. Fases del proceso

cubre necesidades espec´ıficas para el desarrollo de videojuegos y se identifica su uso en la realidad local y en la industria mundial. Los objetivos principales de cada fase son los siguientes: – Concepto: Tiene como objetivo principal definir el concepto del videojuego lo que implica definir aspectos de negocio (p´ ublico objetivo, modelo de negocio), de elementos de juego (principales caracter´ısticas, gameplay, personajes e historia entre otros) y t´ecnicos (lenguajes y herramientas para el desarrollo). 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´es de reuniones y se analiza su factibilidad con pruebas de concepto. Esta fase finaliza cuando se tiene el concepto validado entre todas las partes involucradas. No es necesario que el concepto est´e definido en forma completa para pasar de fase, ya que hay aspectos que se pueden determinar posteriormente. – Planificaci´ on: La fase tiene como objetivo principal planificar las restantes fases del proyecto. Para ello es necesario definir el cronograma del proyecto junto con sus principales hitos, conformar el equipo para la fase de elaboraci´ on de acuerdo a las necesidades t´ecnicas del proyecto, determinar y tercerizar las tareas que el equipo no pueda cumplir, definir el presupuesto y especificar el videojuego. El cronograma del proyecto determina la cantidad de iteraciones y su duraci´ on en la fase de elaboraci´on junto con las fechas en las que se planea realizar el pasaje a las etapas beta y cierre. Pueden existir hitos intermedios de avance para cumplir con requerimientos del cliente, algo que es com´ un por causa de los contratos que se realizan en la industria de videojuegos [Bat03].

8

Se conforma el equipo para el resto de las etapas del proyecto de acuerdo a las necesidades t´ecnicas y art´ısticas que se identifican Esta definici´on puede implicar cambios en el equipo de la fase anterior para cumplir con los requerimientos. En caso de que existan necesidades que las personas que integran el equipo no pueden cubrir, est´as deben ser cubiertas por contratistas externos. La selecci´ on y la contrataci´on de estos tambi´en es parte de esta tarea. Definir el presupuesto consiste en determinar cu´ales son y c´omo obtener los recursos econ´ omicos necesarios para realizar el proyecto. Dos de los componentes principales del presupuesto son los salarios del equipo y los costos externos, como por ejemplo el hardware necesario para desarrollar o el pago a contratistas externos. Estos aspectos componen la planificaci´on administrativa del proyecto, y es el productor interno el responsable de la actividad. Se apoya en el equipo para detectar las necesidades del proyecto y elaborar el cronograma. El cliente tambi´en participa, ya que debe dar el aval al cronograma y al presupuesto. Especificar el videojuego consisten en describir, estimar y priorizar cada una de las caracter´ısticas que definen el videojuego. Una caracter´ıstica 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. La descripci´ on de cada caracter´ıstica es breve pero permite suficiente detalle para poder estimar el tiempo necesario para realizarla. Al ser definidas desde el punto de vista del usuario final, 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. El proceso para especificar las caracter´ısticas consta de tres pasos. En el primero el equipo junto con el cliente determinan y describen, a partir del concepto del juego, cu´ ales son las caracter´ısticas funcionales y no funcionales del videojuego. La descripci´ on incluye los criterios de aceptaci´on que sirven como herramienta para verificar la caracter´ıstica y para eliminar ambig¨ uedades en la definici´on de la misma. En segunda instancia el cliente, con el apoyo del equipo, prioriza estas caracter´ısticas de acuerdo a su importancia, y por u ´ltimo el equipo estima cuanto tiempo requiere realizar cada una. La especificaci´on que se obtiene en esta fase es flexible ya que a lo largo del proyecto se pueden agregar, modificar y eliminar caracter´ısticas, mientras que la prioridad y la estimaci´ on de cada caracter´ıstica se actualiza en cada iteraci´on de la fase de elaboraci´ on. – Elaboraci´ on: El objetivo de esta fase es implementar el videojuego. Para ello se trabaja en forma iterativa e incremental para lograr una versi´on ejecutable del videojuego al finalizar cada iteraci´on. El proceso sigue la secuencia de actividades que se muestra en la Fig.1 y que se detallan a continuaci´on. 1. Planificar iteraci´ on: En esta actividad se planifican los objetivos a cumplir, las m´etricas a utilizar en el seguimiento, las caracter´ısticas a implementar y las tareas necesarias para ello. Los objetivos describen que se pretende lograr al finalizar la iteraci´on y se utilizan para evaluar el ´exito de la misma. Sirven tambi´en de gu´ıa para la toma de decisiones en el transcurso de

9

la iteraci´ on. La selecci´on de las caracter´ısticas se realiza en base a su prioridad y a los objetivos de la iteraci´on. La suma de los tiempos estimados de las caracter´ısticas seleccionadas no debe superar la duraci´on de la iteraci´ on. Existen diversas t´ecnicas para llevar a cabo esta tarea, las cuales se brindan como gu´ıas del proceso. Cada caracter´ıstica elegida, se divide en tareas de menor duraci´on lo cual hace m´as sencillo estimarlas, asignarlas a un miembro del equipo, identificar desviaciones, verificarlas y evaluar su completitud. El cliente y el equipo son los responsables de definir los objetivos y las caracter´ısticas a implementar. El equipo adem´as determina las tareas necesarias para realizar las caracter´ısticas. 2. Seguimiento de la iteraci´on: su prop´osito es mantener la visi´on y el control de la iteraci´ on en base a los objetivos planteados. Para ello es necesario definir m´etricas, registrar medidas y comunicar sus resultados. En caso que ocurran problemas se deben identificar soluciones posibles de acuerdo a su impacto en los objetivos de la de iteraci´on y del proyecto. Posibles soluciones pueden ser, ingresar nuevas tareas a realizar en la iteraci´ on o cambiar el plan de la iteraci´on en caso de desviaciones cr´ıticas. El productor interno realiza el seguimiento y mantiene informado al cliente y al equipo del avance. Las soluciones a los problemas son acordadas entre las personas involucradas. 3. Desarrollar caracter´ısticas: se desarrollan las caracter´ısticas planificadas a trav´es de la ejecuci´on de las tareas que la componen. Una vez que se completan todas las tareas pendientes de una caracter´ıstica, esta se verifica de acuerdo a los criterios de aceptaci´on establecidos. En caso de que no cumpla con alguno de los criterios se debe corregir hasta que lo haga. El proceso para llevar a cabo una tarea se ilustra en la Fig.2. Los miembros del equipo seleccionan las tareas de acuerdo a sus capacidades, y una vez que el equipo aprueba su elecci´on, son responsables por el correcto cumplimiento de estas. Al ejecutar una tarea se pueden identificar nuevas tareas necesarias para completarla, en ese caso se ingresan como nuevas tareas de la iteraci´on. Una vez que se completa la tarea esta es verificada y en caso de encontrar errores se reportan para ser corregidos. 4. Cierre de la iteraci´ on: Esta actividad implica la evaluaci´on del estado del videojuego y de lo ocurrido en el transcurso de la iteraci´on para actualizar el plan de proyecto respecto a la situaci´on actual. A partir de los criterios de aceptaci´on el cliente puede obtener una medida del estado de cada caracter´ıstica planificada para la iteraci´on. El equipo y el productor interno son los encargados de presentarle la versi´on actual del videojuego con las caracter´ısticas construidas. Con esta evaluaci´ on se actualiza el plan de proyecto de acuerdo a la situaci´on actual y se pueden agregar, cambiar o eliminar caracter´ısticas del videojuego, as´ı como modificar la prioridad y tiempo estimado de cada una de ellas. Estos cambios los realizan el cliente y el equipo, mientras que el productor interno es responsable de actualizar el plan de proyecto.

10

Fig. 2. Proceso para desarrollo de tareas

La evaluaci´ on de la iteraci´on consiste en identificar problemas y dificultades que ocurrieron durante la iteraci´on y determinar soluciones para estos. Los responsables de esta actividad son el equipo y el productor interno, en forma opcional puede participar el cliente. – Beta: La fase tiene como objetivos evaluar y ajustar distintos aspectos del videojuego como por ejemplo gameplay, diversi´on, curva de aprendizaje y curva de dificultad, adem´ as de eliminar la mayor cantidad de errores detectados. Se trabaja en forma iterativa liberando distintas versiones del videojuego para verificar. Para ello primero se distribuye la versi´on beta del videojuego a verificar y se determinan los aspectos a evaluar y la forma de comunicaci´on. Mientras la versi´ on se verifica, se env´ıan reportes con los errores o evaluaciones realizadas. Estos reportes son analizados para ver la necesidad de realizar ajustes al videojuego. Se puede optar por liberar una nueva versi´on del videojuego para verificar una vez que se realizan los ajustes. El ciclo termina cuando se alcanza el criterio de finalizaci´on establecido en el plan del proyecto. El productor interno y cliente seleccionan a los verificadores beta, proporcionan la versi´ on a probar y establecen los mecanismos de comunicaci´on. Los verificadores beta reportan los errores encontrados y sus reacciones sobre los aspectos mencionados, mientras el equipo de desarrollo es qui´en corrige el videojuego.

11

– Cierre: Esta fase tiene como objetivos entregar la versi´on final del videojuego al cliente seg´ un las formas establecidas y evaluar el desarrollo del proyecto. Para la evaluaci´ on se estudian los problemas ocurridos, los ´exitos conseguidos, las soluciones halladas, el cumplimiento de objetivos y la certeza de las estimaciones. Con las conclusiones extra´ıdas se registran las lecciones aprendidas y se plantean mejoras a la metodolog´ıa. En la evaluaci´on es recomendable que participen todas las personas que han estado involucradas en el proyecto. – Gesti´ on de riesgos: Esta fase se realiza durante todo el proyecto con el objetivo de minimizar la ocurrencia y el impacto de problemas. Esto se debe a que distintos riesgos pueden ocurrir en cualquiera de las fases, por lo cual siempre debe existir un seguimiento de los mismos. Para cada uno de los riesgos que se identifican se debe establecer la probabilidad y el impacto de ocurrencia, mecanismos de monitoreo, estrategia de mitigaci´on y plan de contingencia. 4.3

Gu´ıas

Las gu´ıas son sugerencias, pautas y herramientas para llevar a cabo en forma efectiva y eficaz las actividades que componen el proceso. A trav´es de ellas, se incorporan a la metodolog´ıa pr´acticas aplicadas con ´exito para el desarrollo de videojuegos, adem´ as de las lecciones aprendidas con el desarrollo de cada proyecto. Actualmente SUM incluye las pr´acticas y herramientas de Scrum y XP, y adem´ as, art´ıculos publicados sobre la aplicaci´on de metodolog´ıas ´agiles en el desarrollo de videojuegos.

5

Conclusiones

Se presenta el uso de metodolog´ıas ´agiles en la industria de videojuegos a nivel mundial y las caracter´ısticas de la industria uruguaya de videojuegos. Se detecta, mediante entrevistas a las empresas de desarrollo de videojuegos m´as relevantes a nivel nacional, las distintas carencias existentes. Entre ellas se encuentra la falta de formalizaci´ on de una metodolog´ıa de desarrollo. Con el conocimiento que se obtiene se crea una metodolog´ıa para desarrollo de videojuegos que se adapta a la realidad local. Se basa en los principios de las metodolog´ıas ´ agiles, para obtener los beneficios que estas reportan. Esta metodolog´ıa se especifica con la herramienta EPF cumpliendo con el est´andar SPEM, lo que permite comunicar el proceso en forma efectiva y extenderlo de forma simple. Actualmente la metodolog´ıa est´a siendo evaluada en un caso de estudio que consiste en el desarrollo de un videojuego 3d de acci´on, multijugador distribuido, utilizando el lenguaje de programaci´on Java. Se cuenta con cuatro integrantes con experiencia en tecnolog´ıas de informaci´on pero sin experiencia en el desarrollo de videojuegos, artes visuales ni sonidos. El rol de equipo de desarrollo lo

12

constituyen tres de los integrantes del grupo, mientras que el cuarto interpreta el rol de productor interno. Las decisiones sobre el videojuego son realizadas por los integrantes del grupo, contando con la opini´on de potenciales usuarios e interesados en el desarrollo. Este caso de estudio permitir´a mejorar y realizar ajustes a la metodolog´ıa propuesta.

Referencias [ASR02] Pekka Abrahamsson, Outi Salo, and Jussi Ronkainen. Agile Software Development Methods. VTT Publications, 2002. [BA04] Kent Beck and Cynthia Andres. Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional, 2004. [Bat03] Bob Bates. Game Developer´s Market Guide, chapter 1. Premier Press, 2003. [Bat08] Batovi Games Studio. Online, Mayo 2008. http://www.batovi.com. [Bec04] Kent Beck. User Stories Applied. Addison-Wesley Professional, 2004. [Cry08] Crytek. Transition to scrum midway through a aaa development cycle: Lessons learned. In Game Developer Conference, Marzo 2008. [Dem08] Thomas Demachy. Extreme game development. Online, Mayo 2008. http://www.gamasutra.com/resource guide/20030714/demachy 01.shtml. [Fou08] Eclipse Foundation. Eclipse process framework project homepage. online, Noviembre 2008. www.eclipse.org/epf/. [Gam08] Gamasutra. Interview: Nokia’s scott foe - a member of the reset generation. Online, Mayo 2008. http://www.gamasutra.com/php-bin/news index.php?story=19210. [Gro07] Object Managment Group. Software and systems process engineering metamodel specification, version 2.0, 2007. [Kef08] Kef Sensei. Online, Mayo 2008. http://www.kefsensei.com/. [Kei07] Clinton Keith. Scrum rising. Game Developer Magazine, pages 22–26, Febrero 2007. [Kei08] Clinton Keith. An agile restrospective. In Game Developer Conference, Febrero 2008. [Kei09] Clinton Keith. Advanced scrum and agile development. In Game Developer Conference, Marzo 2009. [Mys08] Mystery Studio. Computer Games and Games Download. Online, Mayo 2008. http://www.mysterystudio.com/index.php. [Nut08] Christian Nutt. Living on the edge: Dice’s owen o’brien speaks. Online, Mayo 2008. http://www.gamasutra.com/view/feature/3684/living. [Pow08] Powerful Robot Games. Online, Mayo 2008. http://www.powerfulrobot.com. [Rel08] Relic. About relic. Online, Mayo 2008. http://www.relic.com/about/. [SB01] Ken Schwaber and Mike Beedle. Agile Software Development with Scrum. Prentice Hall PTR, 2001. [SUM09] SUM. Online, 2009. http://www.gemserk.com/sum. [Tob08] Bliksem Tobey. Introducing scrum at large animal games: a look back at the first year of agile development. Online, Mayo 2008. http://www.gamasutra.com/view/feature/3677/introducing.