Introducción Este proyecto consiste básicamente en la realización de un videojuego 2D para iPhone que permita al equipo tener un primer acercamiento al desarrollo y venta de aplicaciones a través del App Store. Además, se pretende investigar los procesos y prácticas que se aplican actualmente en la industria de los videojuegos y combinarlos con las prácticas de ORTsf para obtener un proceso que se adapte a nuestras necesidades.

Objetivos de Proyecto Finalizar el proyecto con un videojuego que sirva como base para el desarrollo de aplicaciones para iOS. También se espera adquirir los conocimientos necesarios desde el punto de vista de la conceptualización, diseño arquitectónico, gestión, programación, testing, entre otras actividades necesarias para el desarrollo de aplicaciones. Por último se espera culminar el proyecto con un producto que pueda ser ofrecido a través del App Store.

Objetivos de Producto Desarrollar un videojuego 2D para iPhone del género plataforma de buena calidad, que sea divertido para el público objetivo que sigue este tipo de juegos. También se busca diseñar un juego que aproveche algunas de las pioneras virtudes que hacen al éxito del iPhone.

Roles GEPRO Game Designer Arquitecto SQA SCM Líder de Testing Art Designer Audio Designer Ignacio Ferrero Salvador Cetraro Ignacio Ferrero

Game Design

Boceto

¿Qué es Hungry Chick? Consiste en un personaje que debe pasar por distintos puntos (estaciones) de cada pantalla, en un determinado orden y con un tiempo máximo. Enemigos. Los enemigos se cubrirán con estructuras que los protegerán de posibles ataques.

Inspirado en…

¿Porque iPhone? App Store 5 billones de app descargadas 1 billon de dolares pagado a desarrolladores (70%) iAds Apple reconocida “Worlds Biggest Tecnology Company” (BBC News)

Fuente: Nielsen para Q ¿Porque iPhone?

Principales restriciónes para ofrecer aplicaciónes en el AppStore Bugs Free Descripción acorde a la funcionalidad de la aplicación Licencia Developer

Diseño de la aplicación

Game Engine Game Engine es un término que hace referencia a una serie de rutinas de programación que facilitan al desarrollador con el diseño, la creación y la representación de un videojuego. Entre los motores que se analizaron encontramos:

Open Source Desarrollado en Objetive-C y C++ Primera versión estable en mayo de 2008 Compatibilidad para aplicaciones de iOS/Android Motores de Física (Box2D, Chipmunk)Chipmunk Manejo de transformaciones (rotación, traslación, escalamiento, entre otros) Sistema de partículas Soporte Touch/Accelerometro Orientado 2D Pixelar Game Engine

Entorno de desarrollo Desarrollado en Objetive-C y C++ IDE de desarrollo: Xcode Game Engine: Cocos2D Physics Engine: Box2D

Ambiente de Desarrollo iPhone 3GS Maquina Virtual (Snow Leopard) Mac Book Pro (Snow Leopard)

Gestión del proyecto

Ciclo de Vida Iterativo Definición de Requerimientos Diseño del Sistema Desarrollo Re diseño Prueba Desarrollo Re diseño Prueba Desarrollo Re diseño Prueba 132 Liberación

Etapas Preproducción Preproducción: En la etapa de preproducción, el equipo investigarán y se capacitara en las áreas temáticas y herramientas más importantes relacionadas con el desarrollo del videojuego. Además se realizó el GDD (Game Design Document) en el cual se especifican los requerimientos funcionales del videojuego, el TDD (Technical Design Document) y los planes necesarios para la implementación del proyecto.

Etapas Producción Producción: Una vez establecidos los requerimientos se pasa a la etapa de producción. En esta se procede a la obtención de los recursos gráficos, de sonido y a la construcción del videojuego. Liberación Liberación: Por último se pasa a la etapa de liberación en la cual se realiza un Alpha Test y un Beta Test para encontrar y solucionar errores en el producto final. También se realizan las actividades de cierre del proyecto como por ejemplo, documentación, registro de errores encontrados, entre otras.

Cronograma Preproducción: hasta (15 sem) Producción: hasta (20 sem) Liberación: hasta (10 sem)

Preproducción Game Concept (Definición del Juego) GDD TDD Plan del Proyecto Capacitación Prototipo (Prototipo reutilizable) Manejo de Texturas 2D (investigación inicial) Movimiento Pollito (símil Blimp) Disparo proyectil (disparo símil Angry Birds) Física de estructuras (como Angry Birds sin romper bloques)

Preproducción Resultados obtenidos Game Concept GDD y TDD (aprobados por cliente) Plan de proyecto Prototipo Atraso de 40 hrs (1 semana)

Resultados Primera Iteración First Playable Funcionalidad Blimp Gestos Editor de Niveles Producción

Resultados Segunda Iteración First Playable Funcionalidad Blimp Gestos Editor de Niveles Producción

Editor de Niveles Microsoft Windows Snow Leopard iOS

Software Quality Assurance (SQA)

Este proceso tiene por objetivo dar la confianza adecuada de que cada uno de los procesos en el proyecto cumplirán con un conjunto de niveles de calidad de manera de que el producto de software lograre satisfacer los requisitos y expectativas de sus clientes y/o usuarios. Para esto definimos: Definición de Estándares Criterios de Aceptación Actividades de Control de Calidad Métricas Pruebas SQA

Definición de Estándares: Estándares de Documentación Estándares de Codificación Estándares en el uso de herramientas Criterios de Aceptación Criterios de Aceptación de Documentos Criterios de Aceptación de Código Criterios de Aceptación de Recursos

SQA Actividades de Control de Calidad:

SQA Pruebas Testing Unitario (Producción) Testing de Integración (Producción) Testing de Regresión (Producción) First Playable (Produccion) Testing de Sistema (Liberacion) Testing de Aceptacion (Liberacion)

First Playable Se busca tener una primera versión del juego en etapas tempranas de desarrollo. Es el primer punto en el que un juego tiene modo de juego demostrable, y además personas externas al proyecto lo usan y dan una opinión del mismo. SQA

Testing de Aceptación Alfa testing: se lleva a cabo por usuarios potenciales en el lugar de desarrollo, bajo un entorno controlado Beta testing: se lleva a cabo por usuarios potenciales bajo entornos externos al área de desarrollo, que no pueden ser controlados por el desarrollador Cerrado Encuestas SQA

Software Configuration Management (SCM)

SCM Este proceso tiene por objetivo dar la confianza adecuada de que cada uno de los elementos de configuración del proyecto podrá ser accedido en cualquier momento por cualquiera de los integrantes del proyecto. Se utilizan 2 repositorios web, uno para le código (cerrado) y otro para la documentación y recursos (abierto) Respaldos cada 15 días Software de sincronización: Tortoise (Windows) SCPlugIn(MAC OSX) Xcode (MAC OSX)

SCM Estructura del repositorio

Indicadores del Proyecto

Esfuerzo Primera Iteración N° ReqDescripción Horas Estimadas Horas Reales % Real 1Funcionalidad del Personaje principal1537,5250 % 2Flecha guía % 5Plataformas500 % 7Obstáculos1000 % 10Scrolling en Tres Leyers % 13Tiempo12867 % 20Zoom y Gestos % 14Editor de niveles % Integración, Testing y Corrección iteración I % Total Horas Primera Iteración137221,5162 %

Esfuerzo Si bien la primera iteración llevo un 62% mas de esfuerzo, no consumió un 62% mas de tiempo. Se trabajaron mas horas El tiempo de gestión, reuniones, cursos y armado de planes fue menor al estimado. La primera iteración consumió un 50% mas de tiempo.

PV vs EV

PV vs AC

¿Porque el atraso? Errores en la estimación de horas por tarea Desconocimientos de las herramientas de desarrollo Tareas no contempladas

Indicadores del Producto

ID MétricaCaracteristicaFecha de RegistroCalculoResultadoInterpretacion 1 Funcionalidad (producto) 25/09/2010 Requerimientos FACIL X = A / B, X = 4/12 A = Número de requerimientos implementados B = Número de requerimientos definidos 0,33 Se lleva un 33% de la implmentación facil 1 Funcionalidad (producto) 25/09/2010 Requerimientos MEDIOS X = A / B, X = 4/10 A = Número de requerimientos implementados B = Número de requerimientos definidos 0,40 Se lleva un 40% de la implementación media 1 Funcionalidad (producto) 25/09/2010 Requerimientos DIFICILES X = A / B, X = 1/4 A = Número de requerimientos implementados B = Número de requerimientos definidos 0,25 Se lleva un 25% de la implmentacion dificil 6 Performance (producto) 25/09/2010 X = B - A A = Tiempo al solicitar comenzar el juego B = Tiempo al comenzar el juego 1s Buena (Blimp 6s, Angry Birds 11s) 7 Performance (producto) 25/09/2010 X = B - A A = Tiempo al solicitar comenzar un nivel B = Tiempo al comenzar un nivel 2s Buena (Blimp 3s, Blimp Birds 1s)

Riesgos IDEnunciado R1Retrasos en el cronograma debido a errores en la estimación y planificación. R2 Retrasos en el cronograma debido a la falta de experiencia con las herramientas de desarrollo, lenguajes y tecnologías. R3Retrasos en la entrega de los recursos gráficos R4Mala calidad de los recursos gráficos entregados R5Retrasos en la entrega de los recursos de sonido R6Mala calidad de los recursos gráficos entregados R7 Incumplimiento de los requerimientos establecidos debido a la limitantes del motor del juego R8Insatisfacción del cliente respecto al producto final. R9Insatisfacción del público objetivo respecto al producto final. R10Problemas para subir la aplicación al App Store

Ponderación de Riesgos IDProbabilidadImpactoValor del Riesgo R10,483,2 R20,452 R30,130,3 R40,330,9 R50,120,2 R60,120,2 R70,472,8 R80,361,8 R90,531,5 R100,180,8

Número Ocurrencia en el tiempo DescripciónINICIALJULIOAGOSTOSETIEMBRE R2Mediano plazo Retrasos en el cronograma debido a la falta de experiencia con las herramientas de desarrollo, lenguajes y tecnologías. 3,63 4,2

Número Ocurrencia en el tiempo DescripciónINICIALJULIOAGOSTOSETIEMBRE R3Mediano PlazoRetrasos en la entrega de los recursos gráficos2233,5

Próximos pasos Terminar Primera Iteración First Playable Testing Métricas y Encuestas Integración Recursos Segunda Iteración