Desarrollo de un Videojuego para Playsation 2 Usando PacoGL
Transcripción
Desarrollo de un Videojuego para Playsation 2 Usando PacoGL
Proyecto Fin de Carrera. Facultad de Informática Universidad de Las Palmas de Gran Canaria Desarrollo de un Videojuego para Playsation 2 Usando PacoGL Autor Tutor Cotutor : Abraham Martı́n Expósito : Domingo Benı́tez Dı́az : Agustı́n Trujillo Pino Índice general 1. Introducción 1.1. El sector de los videojuegos . . . . . . 1.2. El proceso de desarrollo . . . . . . . . 1.3. El Grupo de Videojuegos de la ULPGC 1.4. PacoGL . . . . . . . . . . . . . . . . . 1.5. Nuestro proyecto . . . . . . . . . . . . 1.6. Motivaciones . . . . . . . . . . . . . . 1.7. Objetivos . . . . . . . . . . . . . . . . 1.8. Metodologia . . . . . . . . . . . . . . . 1.8.1. Análisis . . . . . . . . . . . . . 1.8.2. Diseño . . . . . . . . . . . . . . 1.8.3. Implementación . . . . . . . . . 1.8.4. Prueba . . . . . . . . . . . . . . 1.9. Recursos necesarios . . . . . . . . . . . 1.9.1. Hardware . . . . . . . . . . . . 1.9.2. Software . . . . . . . . . . . . . 1.10. Plan de trabajo y temporización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 4 5 5 6 7 8 8 9 9 9 10 10 10 10 11 2. Diseño del Videojuego 2.1. Introducción . . . . . . . . 2.2. Antecedentes . . . . . . . 2.3. Descripción . . . . . . . . 2.4. Caracterı́sticas Relevantes 2.5. Género . . . . . . . . . . . 2.6. Plataforma . . . . . . . . 2.7. Arte Conceptual . . . . . 2.8. Diseño gráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12 12 12 13 13 13 13 16 . . . . 24 24 24 31 32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Resultados y Conclusiones 3.1. Objetivos del proyecto . . . . . . . 3.1.1. Rendimiento de la aplicación 3.1.2. Estabilidad . . . . . . . . . 3.1.3. Versión beta del videojuego 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ÍNDICE GENERAL 3.1.4. Validación de la librerı́a gráfica PacoGL 3.1.5. Versión para PC del juego . . . . . . . . 3.2. Objetivos secundarios . . . . . . . . . . . . . . . 3.2.1. Jugabilidad . . . . . . . . . . . . . . . . 3.2.2. Calidad gráfica . . . . . . . . . . . . . . 3.2.3. Conclusiones . . . . . . . . . . . . . . . 3.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . 4. Manuales de Usuario 4.1. Cómo ejecutar un archivo .elf en la Playstation 2 4.1.1. a) Usando un pendrive. . . . . . . . . . . . 4.1.2. b) A través de una red local. . . . . . . . . 4.2. Balls: Manual de usuario . . . . . . . . . . . . . . 4.2.1. Arranque . . . . . . . . . . . . . . . . . . 4.2.2. Controles . . . . . . . . . . . . . . . . . . ÍNDICE GENERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 34 35 36 36 36 36 . . . . . . 38 38 38 39 42 42 42 2 Capı́tulo 1 Introducción 1.1. El sector de los videojuegos Hace unos años se hablaba del sorprendente aumento del mercado de los videojuegos, que superaba ya a la industria del cine y a la musical, en resumen, se decı́a que el sector de los videojuegos era el futuro del mercado del ocio audiovisual. Hoy ya no tenemos que referirnos a los videojuegos como algo futuro, ya es una realidad más que asentada en nuestras vidas. En la actualidad, prácticamente en todas las casas podemos encontrarnos con una consola de videojuegos, un ordenador o un teléfono móvil, todos dispositivos para los que se pueden desarrollar videojuegos. Además la sociedad avanza con la tecnologı́a, y la mayorı́a de los niños (tengo que reconocer, que a mi pesar) ya prefieren una consola de última generación antes que una bicicleta, unos patines, o cualquier juguete más tı́pico de finales del siglo XX. Son tantos y tan variados los usuarios de los videojuegos, que quizás ya no podemos hablar del videojuego como un simple entretenimiento, hay videojuegos que nos pueden ayudar a aprender matemáticas o fı́sica, o incluso a desarrollar habilidades que no nos puede enseñar un libro, tales como conducción de vehı́culos, agudeza visual o incluso capacidades estratégicas. De hecho, en los últimos tiempos el sector de los videojuegos ha comenzado a orientar en cierta medida muchos de sus productos en la lı́nea del aprendizaje y el uso de la inteligencia. Juegos como Brain Training, English Training y Mind Quiz para Nintendo DS o Buzz para PS2 mezclan la diversión con el conocimiento y la inteligencia, algo que apenas podı́amos encontrar hace unos pocos años. Son muchos y muy variados los géneros de videojuegos que podemos encontrarnos, para todos los gustos, edades y habilidades. La mayoria de ellos podemos clasificarlos dentro de la siguiente lista: Deportes (FIFA, Virtua Tennis, NBA, Athens 2004). Simulación (Ace Combat, Flight Simulator). 3 1.2. EL PROCESO DE DESARROLLO Arcade (Space Invaders, Guitar Hero, Metal Slug). Shoot’em up (Quake, Unreal, Half Life). Survival horror (Residen Evil, Silent Hill). Lucha (Tekken, Street Fighter, Mortal Kombat). Plataformas (Sonic, Super Mario, Crash Bandicoot). Estrategia (Age of Empires, Warcraft, Starcraft). Rol (Final Fantasy, Neverwinter Nights). MMORPG1 (Final Fantasy XI, World of Warcraft, Lineage). Aventura gráfica (Discworld, Myst). Puzzle (Tetris, Columns, Puzzle Booble). Educativos (English Training). 1.2. El proceso de desarrollo En el desarrollo de un videojuego comercial pueden participar decenas de profesionales: jefe de proyecto, diseñadores de juegos, diseñadores gráficos, programadores, guionistas, animadores gráficos, compositores, testadores, etc. Además, el desarrollo de un videojuego se divide en varias etapas (las tı́picas para cualquier desarrollo software): análisis, diseño, implementación y prueba. Por todas estas razones podemos afirmar que la experiencia en el proceso de desarrollo de un videojuego es fundamental para que un proyecto de esta clase salga bien. Se han dado muchos casos en la industria del videojuego en los que el lanzamiento de un juego se ha tenido que retrasar enormemente, como fue el caso del Half Life 2 (más de un año), o el más llamativo, el del Duke Nukem Forever, en el que en un primer momento se esperaba su lanzamiento para 1999, pero a dı́a de hoy en 2008 todavı́a no tiene fecha definitiva de salida al mercado. Son dos ejemplos muy significativos de lo que puede pasar si la planificación y la dirección de un proyecto de videojuegos no están extremadamente cuidadas. Dado que, como futuros ingenieros, deberemos estar capacitados para poder dirigir un proyecto informático, y el desarrollo de un videojuego lo es, hemos decidido que en nuestro proyecto abarcaremos la mayorı́a de las tareas tı́picas en el desarrollo de un videojuego: previsualización, diseño de fases, diseño y elaboración de los modelos 3D (escenario, objetos, personajes, etc.), generación de texturas, creación de sonidos, implementación, optimización, prueba, etc. Realizando un proyecto completo, de principio 1 MMORPG: Massive(ly) Multiplayer Online Role-Playing Game, Juego de Rol Multijugador Masivo Online. CAPÍTULO 1. INTRODUCCIÓN 4 1.3. EL GRUPO DE VIDEOJUEGOS DE LA ULPGC a fin, sobre un videojuego, esperamos obtener el bagaje necesario para poder afrontar en el futuro un proyecto de mayores dimensiones, y cuando obtengamos la experiencia necesaria, poder dirigir un proyecto de desarrollo de un videojuego comercial. 1.3. El Grupo de Videojuegos de la ULPGC A principios de 2006 Francisco Espino Espino, alumno de la Facultad de Informática de la ULPGC, en su proyecto fin de carrera “Evaluación y Desarrollo de Aplicaciones para la Arquitectura Sony Playstation 2” [8] creo la API gráfica para Playstation 2 PacoGL. Su repercusión en los medios fue notable, y en los foros españoles de desarrollo de videojuegos se ha hablado bastante de este proyecto, y es que PacoGL es una herramienta novedosa en el mundo del software libre para Playstation 2 y pretende establecerse como alternativa en el desarrollo de videojuegos para dicha plataforma. Dicho proyecto motivó la creación del Grupo de Videojuegos de la Facultad y Escuela Universitarias de Informática de la ULPGC, al cual pertenecemos. La formación de profesionales para el mundo de los videojuegos en España, y en concreto en Canarias, es escasa, y con la creación de este grupo se ha puesto la primera piedra para que en un futuro la ULPGC pueda ser puntera en España en el ámbito de la formación universitaria orientada a los videojuegos. El proyecto de Francisco Espino no se ha quedado estancado, y Jose Manuel Gil Álvarez continuó su trabajo en el proyecto ”‘ Benchmarks para Playstation 2”[9], donde implementó una segunda versión de la librerı́a PacoGL. El proyecto al que dedicaremos la presente memoria es el tercero que finaliza con éxito el Grupo de Videojuegos, en el que inicialmente se ha seguido una lı́nea de investigación y desarrollo sobre la Playstation 2. En el futuro se pretende establecer nuevas lı́neas de trabajo sobre las consolas PSP y Playstation 3. 1.4. PacoGL Nuestro proyecto será un videojuego para Playstation 2, y como no podı́a ser de otra manera, usaremos la API PacoGL para su desarrollo. La principal caracterı́stica de PacoGL es que cumple el estándar OpenGL 1.1, lo que inhibe al programador de la necesidad de conocer las caracterı́sticas hardware de la consola, pudiendo programar los gráficos en alto nivel. OpenGL es, con permiso de Direct3d, el estándar gráfico por excelencia, con la ventaja de que es de libre distribución, escalable y multiplataforma. Programar para una consola de videojuegos siempre ha sido una tarea muy compleja, ya que conlleva un proceso de estudio y aprendizaje de los componentes hardware y la microarquitectura para poder usar ese hardware de forma eficiente. Usando PacoGL podemos evitar todo ese proceso y programar directamente en un lenguaje de alto nivel (C/C++), que es a lo que la mayorı́a de los programadores CAPÍTULO 1. INTRODUCCIÓN 5 1.5. NUESTRO PROYECTO Figura 1.1: Distribución interna del Emotion Engine estamos acostumbrados. Normalmente programar en alto nivel resta eficiencia a nuestro código, ya que usamos instrucciones muy generales y no usamos directamente la “máquina”, por lo que el objetivo de PacoGL ha sido proporcionar una herramienta a los programadores que use eficientemente el hardware de la PS2. De hecho, la implementación de las librerı́as está hecha usando el ensamblador MIPS de la PS2 y teniendo en cuenta todos los componentes del Emotion Engine (ver Figura 1.1) para conseguir un mayor paralelismo, cosa que pocas librerı́as gráficas de libre distribución para PS2 han hecho. Disponiendo de una herramienta para generar gráficos de calidad en la PS2 podemos afrontar el desarrollo de un videojuego para esta consola, con la ventaja de que, al cumplir PacoGL el estándar OpenGL 1.1, la parte gráfica de nuestro videojuego será compilable no solo para PS2, sino también para PC (Unix, Windows o Mac), con la salvedad de que el manejo de ventanas, el sonido y la interfaz con el usuario (gamepad, teclado) habrá que programarlos especı́ficamente para cada plataforma. 1.5. Nuestro proyecto En el proyecto que nos atañe vamos a desarrollar un videojuego prácticamente desde cero, apoyándonos, eso sı́, en la API PacoGL. Diseñaremos modelos 3D, crearemos texturas, elaboraremos fases, programaremos la aplicación, la testearemos y la optimizaremos. Consideramos que es necesario conocer de primera mano todas las etapas por las que pasa un videojuego en su desarrollo para poder realizar en un futuro tareas de dirección, planificación, coordinación, etcétera en un proyecto real. No olvidemos que un ingeniero informático no es un mero programador, y aunque la programación del videojuego posiblemente sea la parte más extensa de nuesCAPÍTULO 1. INTRODUCCIÓN 6 1.6. MOTIVACIONES tro proyecto, no será necesariamente la más importante, ni de la que aprenderemos más. Las tareas que abordaremos serán las siguientes: Estudio de los conceptos de diseño de videojuegos. Elaboración del guión. Aprendizaje del entorno de programación de la Playstation 2. Diseño de los modelos 3D (objetos y escenario). Elaboración de las texturas. Diseño e implementación de la aplicación. Diseño e implementación de la fı́sica del juego. Implementación de las reglas de juego. Implementación de funciones para evaluación del rendimiento gráfico. Testeo y análisis de rendimiento de la librerı́a PacoGL sobre nuestro juego. Optimización. Diseño e implementación multiplataforma: Playstation 2 y PC (Linux). Nuestro videojuego será un shoot’em up (juego de disparos), aunque también podrı́amos encasillarlo en el genero “arcade”. Estará compuesto por una única fase dentro de un escenario cerrado (una habitación). Básicamente el juego consistirá en disparar a las bolas que van entrando en la habitación, con la dificultad de que a medida que pase el tiempo las bolas irán apareciendo con más frecuencia. Cuando haya 20 bolas o más en el escenario termina el juego. Podremos guardar las mejores puntuaciones. 1.6. Motivaciones Son varias las motivaciones que nos han llevado a la realización de este proyecto: Salida profesional. Pensamos que el sector de los videojuegos es una de las salidas más atractivas que tiene esta carrera. Además es una industria que aún está por explotar en España, ası́ que todo lo que aprendamos durante el desarrollo de este proyecto creemos que nos será muy útil en el futuro para abrirnos paso en la mundo de los videojuegos. CAPÍTULO 1. INTRODUCCIÓN 7 1.7. OBJETIVOS Afición y realización personal. Para qué negarlo. Una de nuestras principales motivaciones a la hora de realizar este proyecto ha sido nuestra afición a los videojuegos. Jugamos bastante y siempre hemos sentido mucha curiosidad por saber cómo funcionan los juegos. Gran parte de la culpa de que estemos estudiando ingenierı́a informática se debe a esa afición y a esa curiosidad. Terminar un videojuego que funcione, y más en una consola, nos llenará de satisfacción, el mejor colofón para terminar la carrera. 1.7. Objetivos En la realización de este proyecto vamos a tratar de alcanzar los siguientes objetivos principales: Conseguir, al menos, una versión beta 2 del videojuego. Aunque venga implı́cito en el punto anterior, conseguir que el juego sea estable y robusto en la Playstation 2. Alcanzar un rendimiento gráfico aceptable, concretamente conseguir una tasa aproximada de 25 frames por segundo. Completar una versión para PC del videojuego, cumpliendo también con los objetivos anteriores. Analizar, testear y validar la librerı́a gráfica PacoGL para su uso en videojuegos para Playstation 2. Cumpliendo con los objetivos anteriores, podremos darnos por satisfechos. Además, también nos hemos marcado una serie de objetivos secundarios, que aunque no entran dentro de las labores de un ingeniero informático, si será interesante analizarlos una vez finalice el desarrollo: Obtener una buena jugabilidad. Que el juego sea divertido y adictivo. Conseguir que los gráficos sean atractivos, siempre dentro de nuestros lı́mites como diseñadores gráficos. 1.8. Metodologia Para el desarrollo de nuestro proyecto usaremos una metodologı́a tı́pica de ingenierı́a del software: el desarrollo en espiral. Éste consta de cuatro etapas: 2 Se dice que un videojuego está en su versión beta cuando únicamente quedan por pulir o completar algunos aspectos del juego, como alguna fase, textura, sonidos, diálogos, etc. El juego, funcionalmente, está completo y es estable. CAPÍTULO 1. INTRODUCCIÓN 8 1.8. METODOLOGIA Análisis. Diseño. Implementación. Prueba. Se justifica este tipo de desarrollo con el hecho de que no es posible culminar el proyecto siguiendo las 4 etapas de forma lineal, sin regresar nunca a una etapa anterior. El proceso de desarrollo de un software, y en concreto, el de un videojuego, es un proceso de elaboración y refinamiento. Describamos los pasos a seguir en cada una de las cuatro etapas de desarrollo. 1.8.1. Análisis Esta primera etapa la enfocaremos al estudio del entorno de desarrollo y aprendizaje de las herramientas necesarias para afrontar el desarrollo de un videojuego para Playstation 2. Además, de cara a la elaboración del guión del juego, analizaremos algunos videojuegos para obtener ideas que nos puedan ser útiles. 1.8.2. Diseño Esta etapa es quizá la más importante del desarrollo, ya que será cuando decidiremos cómo será el videojuego que queremos hacer, tanto funcionalmente como gráficamente. Un buen diseño nos facilitará mucho las cosas en etapas posteriores, y aunque será inevitable volver a esta etapa una vez comience la implementación, será clave para la calidad y la duración de nuestro proyecto refinar al máximo el diseño del videojuego. 1.8.3. Implementación En esta etapa “construiremos” la aplicación en base al diseño hecho en la etapa anterior. Implementaremos el videojuego para dos plataformas (Playstation 2 y PC), lo cual deberemos tener en cuenta desde la etapa de diseño. A priori las partes que difieren en cada plataforma están bien diferenciadas: ventanas (sólo PC), controles y sonido. La parte gráfica debe ser compatible para ambas plataformas ya que PacoGL cumple el estándar OpenGL 1.1. La etapa de implementación deberá contener una sub-etapa necesaria para cumplir nuestros objetivos: la optimización. En la versión para PC es posible que no nos encontremos con problemas de rendimiento, pero en la Playstation 2 los recursos hardware son más limitados, y será necesaria una codificación eficiente para que nuestro videojuego pueda tener un rendimiento mı́nimo de 25 frames por segundo. CAPÍTULO 1. INTRODUCCIÓN 9 1.9. RECURSOS NECESARIOS La metodologı́a a seguir para compaginar la implementación sobre ambas plataformas será implementar primero una porción para PC (p.e. un módulo o una clase), y una vez probada en dicha plataforma comprobar su correcto funcionamiento en la Playstation 2. De este modo entraremos en un ciclo en el que iremos avanzando en ambas plataformas. Serı́a un error pretender realizar primero una implementación completa para una de las plataformas y luego portar el código para la otra plataforma, hemos de tener en cuenta que estamos aprendiendo a desarrollar aplicaciones para Playstation 2 y en la migración de una aplicación completa de una plataforma a otra podrı́an aparecer conflictos que nos obligaran a recodificar funciones o incluso clases enteras. 1.8.4. Prueba En cada iteración del ciclo de desarrollo deberemos dedicar un tiempo a realizar pruebas a nuestro videojuego. Tanto la funcionalidad del videojuego, como la estabilidad y el rendimiento deberán estar correctamente testados pasa asegurarnos de que los objetivos de nuestro proyecto se vean cumplidos. 1.9. Recursos necesarios Para el desarrollo de nuestro proyecto, necesitaremos disponer de los siguientes recursos: 1.9.1. Hardware 1 PC con conexión a Internet. Con él trabajaremos y enviaremos los ejecutables a la Playstation 2. 1 Playstation 2 con un Pad. Indispensable para ejecutar nuestro videojuego. 1 Televisor con entrada por componentes o por euroconector. A ella conectaremos la Playstation 2. 1 Pendrive USB compatible con la Playstation 2. Necesario para ejecutar determinadas utilidades en la Playstation 2. 1.9.2. Software Distribución Linux con las herramientas tı́picas (Editor C-C++, compilador GCC-G++, navegador, etc.). El entorno de desarrollo para Playstation 2 está creado para funcionar sobre Linux. Librerı́as GLUT (OpenGL). Necesarias para que funcione la parte gráfica de nuestro videojuego en su versión para PC (Linux). CAPÍTULO 1. INTRODUCCIÓN 10 1.10. PLAN DE TRABAJO Y TEMPORIZACIÓN PS2SDK. Librerı́a que nos dara soporte para acceder al pad de la Playstation 2, a la memory card y a otros componentes de la consola. PacoGL. Librerı́a gráfica que utilizaremos para los gráficos del videojuego sobre la Playstation 2. Disco SwapMagic. Necesitamos esta utilidad para saltarnos la protección de la consola y poder ejecutar nuestro videojuego. ps2link - ps2client. Herramientas que permitirán la comunicación entre el PC y la Playstation 2. Blender. Con esta herramienta crearemos los modelos 3D que utilizaremos en el videojuego. Gimp o Photoshop. Con ellas crearemos las texturas que aplicaremos a los modelos 3D. 1.10. Plan de trabajo y temporización La distribución temporal de las diferentes etapas de las que se compone nuestro proyecto es la siguiente: Análisis y Herramientas (170 horas). Esta será la primera etapa que abordaremos, en ella aprenderemos a utilizar el entorno de desarrollo, los entresijos de OpenGL y los conceptos básicos de diseño de videojuegos. Abarcará los meses de marzo, abril y mayo de 2007. Diseño del guión, diseño gráfico y orientado a objetos (135 horas). Esta etapa se distribuirá sobre la mitad del desarrollo, durante los meses de abril, mayo, junio y julio de 2007. Implementación (200 horas). Esta etapa es la más extensa, y es donde aplicaremos gran parte de lo trabajado y aprendido en las etapas anteriores. Abarcará los meses de junio, julio, agosto, octubre y noviembre de 2007. En septiembre nos tomaremos un descanso. Validación y pruebas (40 horas). Esta será la etapa final del proyecto. Aunque deberémos realizar validaciones y pruebas prácticamente desde el comienzo de la implementación, la mayorı́a del trabajo se concentrará al final, sobre los meses de noviembre, diciembre y enero de 2008. CAPÍTULO 1. INTRODUCCIÓN 11 Capı́tulo 2 Diseño del Videojuego 2.1. Introducción Balls es un mini-juego arcade para Playstation 2 y PC en el que el jugador tiene que usar toda su punterı́a y precisión con los controles para eliminar todos los objetivos que se le pongan por delante. Cuanto más rápido acierte el jugador, más puntos conseguirá para entrar en el ranking del juego. La velocidad, los bonus y la posibilidad de guardar los records son algunas de las caracterı́sticas que hacen de Balls un juego muy divertido. 2.2. Antecedentes Balls ha tomado como referencia juegos del tipo Super Pang, Puzzle Bobble o Rayman: Raving Rabbids. Más que modificar los juegos mencionados, hemos intentado sacar ideas de todos y combinarlas hasta obtener un videojuego consistente y con la posibilidad de añadir nuevos elementos que favorezcan la diversión. Juegos arcade hay cientos, y es muy complicado innovar para obtener un juego que se desmarque de los demás, de ahı́ que hayamos optado por tomar como referencia los juegos arcade más divertidos del mercado. 2.3. Descripción El objetivo del juego es que obtengas el mayor número de puntos posible para ganarte un puesto en el ranking del juego, para ello tendrás que disparar a las bolas que irán saliendo de las paredes de la habitación y eliminarlas. Tu arma dispone de dos tipos de disparo: una ráfaga de balas y un misil. Las balas son ilimitadas, pero tendrás que recargar tu arma cada vez que se vacı́e un cargador. Los misiles son limitados, y se obtienen mediante bonus. Además de las lanzaderas de bolas, cada pared tiene un pequeño hangar. De uno de ellos saldrá de vez en cuando una avioneta 12 2.4. CARACTERÍSTICAS RELEVANTES que podrás derribar de un disparo, si lo consigues obtendrás un bonus, si no consigues derribarla antes de que aterrice en el otro hangar, habrás perdido la oportunidad. En el fondo de la habitación tienes un televisor, te podrás distraer con sus imágenes, pero atento, porque en un momento dado podrás disparar a un objetivo que saldrá en la tele. Si consigues acertarle te llevarás un premio. ¿Cómo conseguir muchos puntos? Las pelotas tienen vida limitada, si no las eliminas, desaparecerán, ¿por qué? Las pelotas son más valiosas en el momento en el que son lanzadas, y a medida que pase el tiempo valdrán menos, hasta que se queden quietas, entonces ya no servirán para nada y desaparecerán, por lo tanto cuanto antes elimines una pelota, más puntos te dará! También puedes conseguir muchos puntos usando los misiles. Un misil explota cuando choca con una pared o con una pelota/avioneta. El misil tiene un radio de acción determinado, todos los objetivos que se encuentren dentro de ese radio, serán dañados. La partida terminará cuando haya demasiadas pelotas en el suelo. En ese momento podrás introducir tu puntuación en el ranking acompañada de tu nombre. 2.4. Caracterı́sticas Relevantes La caracterı́stica más relevante de nuestro videojuego es el uso de la librerı́a gráfica PacoGL, de libre distribución y desarrollada por alumnos de la Facultad de Informática de la ULPGC. 2.5. Género Balls es un Shooter Arcade, donde se mezclan la velocidad, diversión y sencillez de los juegos arcade con la punterı́a de los shooters. 2.6. Plataforma Balls está disponible para Playstation 2 y PC (Linux). 1 jugador. 2.7. Arte Conceptual En los gráficos 2.1, 2.3 y 2.2 podemos ver las primeras aproximaciones a nuestro juego hechas sobre el papel. CAPÍTULO 2. DISEÑO DEL VIDEOJUEGO 13 2.7. ARTE CONCEPTUAL Figura 2.1: Boceto de previsualización de nuestro juego. Figura 2.2: Bocetos de previsualización de nuestro juego. CAPÍTULO 2. DISEÑO DEL VIDEOJUEGO 14 2.7. ARTE CONCEPTUAL Figura 2.3: Boceto de previsualización de nuestro juego. CAPÍTULO 2. DISEÑO DEL VIDEOJUEGO 15 2.8. DISEÑO GRÁFICO 2.8. Diseño gráfico Para el desarrollo de nuestro videojuego ha sido necesario el diseño de una serie de modelos 3D, imprescindibles para dar forma y plasmar en pantalla las ideas elaboradas en el diseño del guión del videojuego. Estos modelos se componen básicamente de dos elementos: una estructura tridimensional que da forma al modelo, y una textura o “piel” que aporta estética y realismo al mismo. Los modelos que mostramos a continuación son las versiones definitivas que hemos utilizado en nuestro videojuego. Para llegar a los modelos que necesitábamos hemos tenido que modificar la mayorı́a de ellos varias veces, tanto la geometrı́a como las texturas. Enumeremos pues los modelos que componen nuestro videojuego. Bola Se compone de 26 caras y 15 vértices. La textura es de 8x8 pı́xels. Es el elemento que más se repite en el escenario, por lo que hempo procurado mininizar el número de caras y la resolución de la textura. CAPÍTULO 2. DISEÑO DEL VIDEOJUEGO 16 2.8. DISEÑO GRÁFICO Suelo La malla que forma el suelo está compuesta por 4 caras y 6 vértices. La textura tiene una resolución de 128x128 pı́xels. Hemos podido ahorrarnos las caras posteriores del suelo ya que nunca son visibles en el juego. Hangar Compuesto por 12 caras, y 8 vértices. Su textura tiene una resolución de 128x128 pı́xels. Dado que la textura contiene texto no hemos podido reducir más la calidad para que el texto sea legible. CAPÍTULO 2. DISEÑO DEL VIDEOJUEGO 17 2.8. DISEÑO GRÁFICO Impacto La malla está formada por 5 caras y 8 vértices. Es el único modelo que hemos creado que no tiene textura. Su tamaño es bastante pequeño, por lo que hemos considerado que será suficiente con aplicarle un color uniforme usando OpenGL. Arma Compuesta por 276 caras y 150 vértices, es el modelo más complejo que hemos diseñado. Su textura es de 128x128 pı́xels. CAPÍTULO 2. DISEÑO DEL VIDEOJUEGO 18 2.8. DISEÑO GRÁFICO Misil Se compone de 46 caras y 37 vértices. Su textura es de 16x16 pı́xels. Avioneta (normal) El modelo está formado por 46 caras y 25 vértices. Es el modelo al que más hemos tenido que reducir la calidad (al principio tenı́a más de 500 caras). Su textura tiene una resolución de 32x32 pı́xels. CAPÍTULO 2. DISEÑO DEL VIDEOJUEGO 19 2.8. DISEÑO GRÁFICO Avioneta (dañada) El modelo es el mismo que el de la avioneta normal. Solo varı́a la textura, a la que se le han añadido unas estalladuras para simular que la avioneta está a punto de romperse. Techo Modelo simple de 4 caras y 6 vértices. Su textura es un mosaico de 64x64 pı́xels. CAPÍTULO 2. DISEÑO DEL VIDEOJUEGO 20 2.8. DISEÑO GRÁFICO Fondo Otro modelo simple de 2 caras y 4 vértices, cuya textura tiene una resolución de 128x128 pı́xels. Lanzadera Modelo compuesto por 29 caras y 23 vértices. La textura tiene una resolución de 64x64 pı́xels. CAPÍTULO 2. DISEÑO DEL VIDEOJUEGO 21 2.8. DISEÑO GRÁFICO Pared En realidad son dos modelos simétricos, uno para la pared izquierda, y otro para la pared derecha del escenario. Cada pared está compuesta por 70 caras y 46 vértices. La textura es un mosaico de 64x64 pı́xels, y es la misma que se usa para el techo. Alfabeto El alfabeto es una textura de 256x256 pı́xels subdividida en ”parcelas“ de 32x32 pı́xels. Cada una de ellas contiene un carácter. CAPÍTULO 2. DISEÑO DEL VIDEOJUEGO 22 2.8. DISEÑO GRÁFICO Menú Textura de fondo del menú del juego. Su resolución es de 256x256 pı́xels. Es fácil adivinar que su elaboración se ha hecho a partir de una captura del propio videojuego, aplicándole posteriormente una serie de efectos y colores. CAPÍTULO 2. DISEÑO DEL VIDEOJUEGO 23 Capı́tulo 3 Resultados y Conclusiones 3.1. Objetivos del proyecto Vamos a analizar, uno por uno, todos los objetivos que nos hemos marcado a lo largo de este proyecto. Hemos de distinguir entre objetivos principales, y objetivos secundarios. Los principales han sido llevar el videojuego a una versión beta, alcanzar una tasa aceptable de frames por segundo, que la aplicación sea estable y que demuestre la validez de la librerı́a grafica PacoGL para realizar videojuegos para la Playstation 2. Además del desarrollo de una versión para PC. Como objetivos secundarios nos hemos marcado conseguir un nivel aceptable de jugabilidad y adictividad en el juego y unos gráficos atractivos. 3.1.1. Rendimiento de la aplicación En este análisis del rendimiento de nuestro videojuego hemos utilizado cuatro versiones del mismo: Centralizada no optimizada. Centralizada optimizada. Distribuida no optimizada. Distribuida optimizada. Cuando hablamos de versión distribuida o centralizada estamos haciendo alusión a la versión utilizada de la librerı́a PacoGL1 . En cuanto a las versiones optimizada y no optimizada, nos referimos a si incluyen o no las optimizaciones que hemos realizado en el código del videojuego, tanto en el apartado gráfico como en el del cálculo de la 1 La versión centralizada de PacoGL utiliza únicamente el core del Emotion Engine para realizar los cálculos, mientras que la versión distribuida se apoya en la unidad vectorial VU1, diseñada precisamente para acelerar los gráficos. 24 3.1. OBJETIVOS DEL PROYECTO Figura 3.1: Rendimiento en frames por segundo de las distintas versiones. fı́sica. De este modo evaluaremos las mejoras introducidas por ambos factores: el uso de la versión mejorada de PacoGL y la optimización del código de nuestro juego. En el gráfico 3.1 vemos los frames por segundo obtenidos en los benchmarks realizados a las distintas versiones de nuestro juego, alcanzando los 22 FPS de media en la versión optimizada distribuida. El objetivo final de este apartado, que era alcanzar los 25 frames por segundo, no ha sido alcanzado al 100 %, pero hemos quedado contentos con los resultados. Podemos ver en el gráfico 3.2 cómo en el desarrollo de una partida tı́pica, en la primera mitad obtenemos una tasa que ronda los 25 fps, mientras que en la segunda mitad, cuando hay más elementos en el escenario de juego, la tasa cae hasta los 16 fps aproximadamente. Con la intención de conseguir que el videojuego no bajara nunca de los 25 fps podrı́amos haber modificado las reglas del juego, de modo que el game over se produjera al haber 10 bolas en el escenario, en lugar de 20 como dispusimos inicialmente, disminuyendo ası́ las exigencias de la aplicación. No pretendemos manipular artificialmente los resultados de los benchmarks realizados con nuestro videojuego, queremos ser objetivos y valorar realmente tanto nuestra eficiencia como programadores, como la validez de la librerı́a PacoGL para crear videojuegos para la Playstation 2. CAPÍTULO 3. RESULTADOS Y CONCLUSIONES 25 3.1. OBJETIVOS DEL PROYECTO Figura 3.2: FPS, miles de triángulos por segundo y elementos en pantalla a lo largo de una partida normal (versión distribuida optimizada). Además, es llevando la librerı́a gráfica hasta sus lı́mites, y no de otro modo, como conseguiremos evaluar su calidad y su rendimiento de forma realista. De poco hubiera servido realizar un videojuego extremadamente sencillo que nunca bajara de los 50 fps que la consola tiene como lı́mite. Si observamos los frames por segundo en el gráfico 3.2 podemos ver como se produce un “efecto escalón”, el rendimiento es estable a 25 fps, de pronto comienza a saltar entre los 25 y los 16 fps, hasta que se estabiliza en torno a los 16 fps. ¿Y a qué se debe esto? Este efecto es una consecuencia tı́pica del uso de técnicas de paralelismo. La librerı́a gráfica PacoGL utiliza la unidad vectorial VU1 del Emotion Engine para optimizar los cálculos vectoriales y matriciales. Mientras esas unidades vectoriales no se llenen, podrán mantener un ritmo constante, en nuestro caso, rondando los 25 fps, pero desde el momento en que su capacidad es sobrepasada, se produce un “salto” en el rendimiento, bajando en nuestro caso a tasas que rondan los 16 fps. Análisis de las optimizaciones Analicemos las optimizaciones realizadas. Como podemos ver en los gráficos 3.3 y 3.4, la mejora obtenida en el rendimiento del juego al utilizar la versión distribuida de las librerı́as PacoGL es bastante notable, consiguiendo un speed-up del 39 %. Después de realizar las optimizaciones sobre el código de nuestro videojuego, tanto de la parte gráfica como de la parte de la fı́sica, también hemos conseguido un aumento considerable de las prestaciones, pasando de un speed-up del 39 % a un speed-up del 58 %. Ahora, analicemos las optimizaciones por separado. Si aislamos la parte de la CAPÍTULO 3. RESULTADOS Y CONCLUSIONES 26 3.1. OBJETIVOS DEL PROYECTO Figura 3.3: Incremento del rendimiento gráfico utilizando como base la versión centralizada no optimizada. Figura 3.4: Desglose de los tiempos de ejecución de cada parte del programa. CAPÍTULO 3. RESULTADOS Y CONCLUSIONES 27 3.1. OBJETIVOS DEL PROYECTO Figura 3.5: Comparación del speed-up obtenido en la parte gráfica y en la parte fı́sica, y el speed-up global debido a cada parte. fı́sica del juego, el speed-up conseguido en la optimización ha sido del 18,20 % (ver figura 3.5). Si miramos la parte gráfica, podemos ver como el speed-up conseguido es del 14 %, algo por debajo del conseguido en la parte de la fı́sica del juego. Pero estos datos son medidas del rendimiento aislando ambos componentes. Si comparamos las mejoras introducidas en el rendimiento global de la aplicación por cada uno de ellos, observamos como la optimización de la parte gráfica contribuye aumentando el rendimiento de la aplicación en un 12 %, mientras que la optimización de la parte de la fı́sica apenas contribuye con un 1,4 %. ¿Por qué ocurre esto? Es muy simple, como ya habı́amos adelantado en el capitulo anterior, optimizar una parte de la aplicación que ocupa un porcentaje alto del tiempo de CPU nos va a reportar más beneficios en el rendimiento global que optimizar una parte que ocupa un porcentaje bajo del tiempo de CPU. En nuestro caso la parte gráfica ocupaba un 87,44 % del tiempo de CPU, mientras que el cálculo de la fı́sica suponı́a un 9,21 %. De ahı́ que por mucho que consiguiéramos mejorar la parte del cálculo de la fı́sica, la mejora global del juego debido a esa optimización no iba a ser notable. Otra cuestión que podemos analizar es por qué el rendimiento baja a medida que avanza la partida. Es obvio que la causa es el incremento de objetos en el escenario a medida que avanza la partida, bolas fundamentalmente. Como podemos ver en la figura 3.2, el numero de elementos en el escenario afecta al rendimiento de nuestro videojuego de forma inversamente proporcional, a mayor número de objetos, CAPÍTULO 3. RESULTADOS Y CONCLUSIONES 28 3.1. OBJETIVOS DEL PROYECTO Figura 3.6: Distribución del tiempo de CPU a lo largo de una partida entre la parte gráfica y el cálculo de la fı́sica (versión distribuida optimizada). menor rendimiento. Pero vamos a analizar en qué medida afecta este incremento al rendimiento de los gráficos y al rendimiento de la fı́sica. En el gráfico 3.6 podemos observar cómo a medida que avanza la partida, la parte del cálculo de la fı́sica va ganando peso frente a la parte gráfica. ¿Cual es la razón por la que la complejidad de la fı́sica aumenta más rápido que la complejidad gráfica? La respuesta es que la complejidad gráfica aumenta linealmente con el aumento de objetos en pantalla, mientras que la complejidad de la fı́sica aumenta siguiendo una curva. Concretamente, el aumento de la complejidad de la fı́sica se debe una pequeña explosión combinatoria. El número de tests de colisión que han de realizarse entre todas las bolas del escenario viene dado por la siguiente fórmula, correspondiente a la combinación sin repetición de n elementos, combinados de 2 en 2: C2n = n! n ∗ (n − 1) = 2! ∗ (n − 2)! 2 En el gráfico 3.7 vemos enfrentadas la complejidad gráfica y la complejidad fı́sica. Hemos indicado el lı́mite donde nuestro juego finaliza, que es cuando hay 20 bolas en pantalla. Si comparamos el gráfico 3.6 con el gráfico 3.7 podemos llegar a la conclusión de que si vamos introduciendo bolas en nuestro escenario indefinidamente, llegará un CAPÍTULO 3. RESULTADOS Y CONCLUSIONES 29 3.1. OBJETIVOS DEL PROYECTO Figura 3.7: Aumento de la complejidad de los gráficos y de la fı́sica. Nuestro juego se detiene al alcanzar las 20 bolas en pantalla (versión distribuida optimizada). momento en que el cálculo de la fı́sica será más pesado que el de los gráficos. Y esto nos ha llevado a otra conclusión más interesante aún: con esta experiencia, ahora tendremos más capacidad de prever si un proceso, que a priori no supone un gran porcentaje de tiempo de CPU, en otras circunstancias podrı́a llegar a ser más pesado computacionalmente. Imaginemos que se desarrolla una nueva versión de la librerı́a PacoGL, y que su rendimiento es mucho mejor que el de la versión actual, lo cual nos permitirı́a desarrollar un juego más complejo, y utilizamos el mismo “motor de fı́sica” que hemos desarrollado. Por ejemplo, creamos un juego donde coexisten más de 100 elementos colisionables entre sı́. El cuello de botella dejarı́an de ser los gráficos y pasarı́a a ser el cálculo de la fı́sica. Conclusiones De los resultados y la experiencia obtenidos en este apartado, hemos sacado las siguientes conclusiones: Es muy importante saber reconocer qué partes de un videojuego merecen más atención a la hora de optimizar. La experiencia con las herramientas y con la plataforma es esencial. No basta con implementar el juego para que funcione correctamente, se ha de programar lo más eficientemente posible. CAPÍTULO 3. RESULTADOS Y CONCLUSIONES 30 3.1. OBJETIVOS DEL PROYECTO Diseñar y programar un videojuego con las tecnologı́as de hoy en dı́a requiere una formación ingenieril, saber usar un lenguaje de programación no es suficiente si queremos obtener buenos resultados y ser competitivos. El conocimiento del hardware y la capacidad de programar a bajo nivel son imprescindibles para desarrollar videojuegos para consolas. Para finalizar, podemos decir que estamos satisfechos con los resultados en el apartado de rendimiento. Con la nueva versión de la librerı́a y las optimizaciones realizadas, el juego ha incrementado su rendimiento gráfico, alcanzando los 25 frames por segundo en muchas ocasiones, aunque no hemos conseguido llegar a los 25 FPS de media en el transcurso de una partida tipo. Aun ası́, consideramos que una tasa de 22 FPS de media, teniendo en cuenta que partı́amos de una tasa de 14 FPS antes de introducir las mejoras, supone una mejora suficiente como para ser optimistas con los resultados. Por otro lado, el tiempo de respuesta a los controles del juego, tanto en la versión para Playstation 2, como en la versión para PC es imperceptible por el usuario. Como ya hemos dicho en otros capı́tulos, que el usuario note un retraso entre el instante en el que realiza una acción, y el instante en el que esa acción se ve en la pantalla, es nefasto para la calidad del videojuego. En nuestro caso hemos conseguido un buen tiempo de respuesta, que unido a una tasa de FPS aceptable, hacen que el rendimiento gráfico del videojuego cumpla nuestros objetivos. 3.1.2. Estabilidad A lo largo del desarrollo nos hemos encontrado con distintos problemas de estabilidad en nuestra aplicación, han sido los siguientes: Bucles infinitos en el cálculo de la fı́sica. Errores de segmentación al cargar el audio. Errores de renderizado de triángulos. Los bucles infinitos en el cálculo de la fı́sica se debı́an básicamente, y explicándolo sin entrar en muchos detalles, a que en ocasiones al aparecer una nueva bola en el escenario, ésta lo hacia intersectando con una ya existente, y nuestro motor de fı́sica no “sabe” resolver esta situación. Hemos solucionado este inconveniente asegurándonos de que cada bola nueva no sea “colisionable” mientras haya alguna bola intersectando con ella. Además, en el bucle donde se producı́a el fallo hemos puesto un “contador de iteraciones” que al llegar a un valor determinado, envı́a un mensaje de advertencia por terminal y se salta el cálculo de la colisión, evitando el bucle infinito, pero dejando sin resolver la colisión. Desde que hemos adoptado esta solución, no se han producido más fallos de este tipo, ni han aparecido mensajes de advertencia en los numerosos CAPÍTULO 3. RESULTADOS Y CONCLUSIONES 31 3.1. OBJETIVOS DEL PROYECTO tests realizados. En la fase de implementación del sonido nos hemos encontrado con que la librerı́a que proporciona PS2SDK para implementar el audio da bastantes problemas. Por ejemplo, no se pueden tener más de 3 sonidos cargados en memoria porque siempre ocurre un fallo de segmentación. En ocasiones esto sucede incluso al cargar un único sonido. Al no disponer de otra librerı́a de sonido para Playstation 2 hemos decidido dejar el apartado del sonido de lado y centrarnos en otros aspectos del juego. Hay que decir que en la versión para PC el sonido si está implementado, pero no hemos tenido tiempo para elaborar una banda sonora completa. En el apartado gráfico nos hemos encontrado con que en sucesivas ejecuciones de nuestro videojuego sin resetear la consola, comienzan a pasar cosas extrañas como triángulos que desaparecen o recortes con los bordes de la pantalla mal hechos. Este problema siempre se soluciona al resetear la consola. Después de realizar muchas pruebas tanto nosotros como los desarrolladores de la versión de PacoGL utilizada, hemos llegado a la conclusión de que ese fallo no es debido a nuestro juego ni a la librerı́a PacoGL, sino a la herramienta de carga de los ejecutables en la Playstation 2, la Ps2link. Después de abordar estos 3 problemas, podemos afirmar que la estabilidad de la versión final de nuestro videojuego es bastante buena. En todos los tests realizados durante las últimas fases del desarrollo no nos hemos vuelto a encontrar los fallos descritos anteriormente, ni ha aparecido ninguno nuevo. 3.1.3. Versión beta del videojuego Funcionalmente nuestro juego se ha completado. Además hemos conseguido que sea estable y robusto, por lo tanto podemos decir que hemos alcanzado una versión beta. De cualquier modo debemos puntualizar que algunos elementos de la fase que hemos diseñado (Ver Documento 2 de diseño, pág. 12) no han sido implementados. Es el caso, por ejemplo, de la “televisión” del fondo de la habitación, donde se pensaban incluir una serie de objetivos del juego, y por falta de tiempo hemos decidido sustituir por una pared normal. Además, la librerı́a PS2SDK no nos proporciona un acceso fiable sintetizador de sonido de la Playstation 2, por lo que, a pesar de tener implementado el módulo de sonido del juego, hemos tenido que desecharlo. La iluminación del juego también ha sido desechada, a pesar de estar implementada, ya que la versión utilizada de PacoGL no incluye iluminación. CAPÍTULO 3. RESULTADOS Y CONCLUSIONES 32 3.1. OBJETIVOS DEL PROYECTO 3.1.4. Validación de la librerı́a gráfica PacoGL Vamos a hacer un pequeño análisis de la librerı́a gráfica PacoGL. Veremos si el subconjunto del estándar implementado es suficiente, si la librerı́a es estable, si los resultados en pantalla son correctos, su facilidad de instalación y su sencillez de uso. Funcionalidad y completitud PacoGL implementa un subconjunto del estándar OpenGL 1.1, por lo que muchas funcionalidades no se han tenido en cuenta. En la página ?? enumeramos una por una cuales han sido implementadas y cuales no. Para mayor información aconsejamos leer los manuales de usuario que vienen con PacoGL. Después de haber trabajado paralelamente con PacoGL y con la versión de OpenGL para Linux (GLUT), podemos decir que están implementadas las funcionalidades básicas. Sólo hemos echado en falta dos: el blending (en la primera versión de PacoGL) y la iluminación (en la última versión de PacoGL, que es la que hemos utilizado). Al estar implementadas en distintas versiones de la librerı́a no dudamos que coexistirán en futuras versiones. Estabilidad En cuanto a la estabilidad de la librerı́a, hemos de decir que no nos hemos encontrado con ningún problema, no se han producido “cuelgues” ni fallos destacables de ningún tipo. Es más, si comparamos PacoGL con su homónima para PC (GLUT freeglut), nos encontramos con que esta última nos ha dado bastantes problemas con las texturas, mostrando en ocasiones texturas incorrectas o no mostrando algunas por pantalla directamente. ¡Por lo tanto podemos decir que PacoGL estable y robusta incluso frente a una versión para PC desarrollada desde 1999 y que actualmente va por la versión 2.4.0! Fidelidad Comparando los resultados mostrados por pantalla tanto por PacoGL como por GLUT, corroboramos que el renderizado de las primitivas por parte de PacoGL se ciñe perfectamente al estándar, partiendo de la base, claro está, de que GLUT es una buena referencia para contrastar este aspecto. Tanto las perspectivas, como los colores, rotaciones, traslaciones, texturizado, etcétera, se ven reflejados en pantalla del mismo modo por ambas librerı́as. Solamente hemos alcanzado a ver diferencias de nitidez, brillo o contraste, todas achacables a las diferencias entre los monitores utilizados, una televisión convencional en el caso de la Playstation 2, y un monitor TFT en el caso del PC. Podemos comparar los resultados en la figura 3.8. CAPÍTULO 3. RESULTADOS Y CONCLUSIONES 33 3.1. OBJETIVOS DEL PROYECTO Figura 3.8: Capturas del juego en el PC (izquierda) y en la Playstation 2 (derecha). Facilidad de instalación y uso La instalación de PacoGL se hace un poco larga ya que previamente debemos instalar la PS2SDK. En el apéndice de este documento explicamos detalladamente cómo instalar ambas librerı́as. Siguiendo dichas explicaciones podremos instalar las librerı́as sin problemas, aunque podemos encontrarnos con los problemas tı́picos al instalar aplicaciones en Linux, como dependencias o incompatibilidades, por lo que será recomendable tener experiencia con este sistema operativo. Una vez instalado todo, su uso se hace sencillo si tenemos nociones de OpenGL y sabemos manejarnos con archivos makefile. Tanto PS2SDK como PacoGL traen algunos samples de ejemplo bastante útiles en los que podemos fijarnos para realizar nuestros primeros programas para Playstation 2. 3.1.5. Versión para PC del juego En la versión para PC nos hemos encontrado con dos problemas que en ningún caso han aparecido en la versión para Playstation 2: problemas en la carga de texturas y errores en las colisiones al disparar el arma. Lo curioso es que estos errores aparecen arbitrariamente al ejecutar una misma compilación del juego, unas veces aparecen y otras no. El problema con las texturas es, sencillamente, que en ocasiones no muestra una o dos texturas por pantalla. Hemos comprobado que la textura que falla depende del orden de carga de las texturas, por lo que es posible que hayamos pasado por alto alguna particularidad de la librerı́a utilizada (GLUT) a la hora de cargar las texturas. Como hemos dicho, si ejecutamos la aplicación sucesivas veces, en algunas ejecuciones el problema persiste y en otras desaparece. No hemos encontrado una solución para este problema que, reiteramos, no ocurre en la versión para Playstation 2, por lo que sospechamos que GLUT tiene alguna particularidad o bug que desconocemos. En cuanto al segundo error, hemos comprobado que lo que ocurre es que por CAPÍTULO 3. RESULTADOS Y CONCLUSIONES 34 3.2. OBJETIVOS SECUNDARIOS algún motivo no se cargan bien las coordenadas de las paredes, y la bala o el misil colisionan nada mas ser disparados, como si el arma estuviera pegada a una pared “invisible”. Al igual que el error anterior, ocurre arbitrariamente en sucesivas ejecuciones de la misma compilación. Además nunca nos hemos encontrado con este bug en la versión para Playstation 2, por lo que hemos deducido que el fallo debe encontrarse en una zona dependiente de la plataforma (ratón y teclado o librerı́a GLUT), en el compilador para PC, o en el propio sistema operativo (Ubuntu 7.10). A pesar de estos dos fallos, hemos conseguido una versión del juego que realmente funciona, y sin añadir demasiado código. En cuanto al rendimiento diremos que no es comparable el obtenido en la PS2 al obtenido en el PC. En una máquina de prestaciones “medias” hemos obtenido tasas por encima de los 200 frames por segundo, mientras que en una máquina de prestaciones relativamente altas, hemos superado incluso los 1000 FPS. Ordenador de gama media: AMD XP 1700+ (1,5 Ghz) 1 GB RAM DDR (266 Mhz) Nvidia Geforce FX 5700 Ultra 128 MB DDR3 Disco duro ATA 7200 rpm (40 GB) Ordenador de gama media/alta: Intel Core2Duo T7250 (2,0 Ghz) 2 GB RAM DDR2 (667 Mhz) Nvidia Geforce Go 8600M GT 256 MB DDR3 Disco duro SATA 5400 rpm (200 GB) 3.2. Objetivos secundarios Para verificar la consecución de estos objetivos secundarios de jugabilidad y calidad gráfica, hemos contado con la colaboración de varias personas ajenas al proyecto. Dado que la opinión que se puede dar tanto de la jugabilidad, como de la calidad gráfica, es bastante subjetiva, hemos considerado que la opinión de unas personas que no han participado en el desarrollo será mucho más útil y cercana a lo que serı́a un usuario final de nuestra aplicación. En definitiva, ellos actuarán de beta-testers de nuestro videojuego. CAPÍTULO 3. RESULTADOS Y CONCLUSIONES 35 3.3. TRABAJO FUTURO 3.2.1. Jugabilidad En cuanto a la jugabilidad, hemos recibido las siguientes crı́ticas: Cuesta un poco hacerse con los controles al principio. El juego llega a cansar fı́sicamente al tener que disparar en muchas ocasiones si quieres evitar el game over. El juego recuerda a los tı́picos mini-juegos que se pueden encontrar en muchas páginas web en formato flash o java. 3.2.2. Calidad gráfica En cuanto a los gráficos, hemos recibido las siguientes crı́ticas: Los gráficos son algo “feos”, sobre todo los de las paredes, se nota que se podrı́a haber trabajado más en ellos. Se podrı́an haber introducido mas efectos especiales. El fondo del menú sı́ está logrado. 3.2.3. Conclusiones Tal y como sospechábamos, nuestra habilidad como artistas gráficos deja bastante que desear. Algo comprensible, eso si, ya que somos ingenieros. Nuestras obras de arte no se miden con el rasero de la estética, sino con el de la calidad, funcionalidad y la innovación. En cuanto a la jugabilidad, hemos aprendido algo muy importante: hay que tener en cuenta la opinión de usuarios potenciales del videojuego desde las fases más tempranas del desarrollo. Será ası́, y no de otro modo, como realmente conseguiremos un juego que guste de verdad, que sea adictivo y divertido. 3.3. Trabajo futuro Siguiendo la lı́nea de investigación y desarrollo que han llevado tanto nuestro proyecto, como otros proyectos paralelos del Grupo de Videojuegos, proponemos las siguientes ideas para proyectos futuros: Implementación de PacoGL para Playstation 3. Serı́a el salto natural despues de haber conseguido buenos resultados para la Playstation 2. En los comienzos de la PS2 el panorama de desarrollo libre para la consola no estaba tan avanzado como lo está en la Playstation 3 en sus primeros meses de vida, por lo que no serı́a CAPÍTULO 3. RESULTADOS Y CONCLUSIONES 36 3.3. TRABAJO FUTURO descabellado realizar un proyecto de investigación y desarrollo sobre la nueva consola de Sony. Implementación de PacoGL para PSP. También seria interesante obtener una versión de PacoGL para la consola portatil de Sony. Al no tener las prestaciones y la complejidad hardware de la Playstation 2, podrı́amos profundizar más y conseguir resultados más cercanos a los juegos comerciales. Implementación de librerı́as de sonido para Playstation 2. Dado que no hemos conseguido obtener una librerı́a de sonido aceptable para la consecución de nuestro proyecto, hemos pensado que serı́a una buena idea complementar PacoGL con una librerı́a (llamada, porque no, PacoAL), basada en el estándar OpenAL (homólogo a OpenGL pero en el ámbito del audio). Completar PacoGL con las funciones OpenGL 1.1 no implementadas. Dado que PacoGL tiene funciones del estándar sin implementar (las de iluminación, por ejemplo), serı́a interesante añadir más funcionalidades a las actuales. Desarrollo de un motor de fı́sica a modo de librerı́a e integrarlo en nuestro videojuego. Nuestro motor de fı́sica está diseñado de una forma mas bien monolı́tica y poco modular. Se ha implementado especı́ficamente para nuestro videojuego. Un buen proyecto podrı́a ser crear una liberı́a de fı́sica, optimizada sobre las unidades vectoriales de la Playstation 2. Podrı́a utilizarse parte del código del propio videojuego para las librerı́as, y luego modificar el código restante para integrar el motor de fı́sica nuevo. CAPÍTULO 3. RESULTADOS Y CONCLUSIONES 37 Capı́tulo 4 Manuales de Usuario 4.1. Cómo ejecutar un archivo .elf en la Playstation 2 4.1.1. a) Usando un pendrive. Para ello necesitaremos: 1 pendrive USB CD/DVD SwapMagic (nosotros hemos usado la versión 3.6). Este método nos permite tener hasta 4 ejecutables en el pendrive haciendo lo siguiente: Creamos el directorio “SWAPMAGIC” en el directorio raı́z del pendrive. Copiamos los ejecutables .elf en el directorio creado (hasta 4 ejecutables). Renombramos los archivos del siguiente modo: SMBOOT0.ELF SMBOOT1.ELF SMBOOT2.ELF SMBOOT3.ELF Ahora introducimos el pendrive en el puerto USB de la Playstation 2, y la arrancamos con el SwapMagic en el lector. Cuando llegue al menú principal del SwapMagic podremos arrancar cualquiera de los 4 ejecutables usando la correspondiente combinación de botones del pad de la Playstation 2: Arriba Arriba Arriba Arriba + + + + L1 L2 R1 R2 38 4.1. CÓMO EJECUTAR UN ARCHIVO .ELF EN LA PLAYSTATION 2 Nota: Hemos tenido problemas con este método para ejecutar .elf que acceden a otros archivos (p.e. el sample texture de la ps2sdk accede a la textura texture.raw y no funciona). 4.1.2. b) A través de una red local. El anterior método tiene algunas desventajas, como que a veces el pendrive no graba bien el .elf, o que se pierde mucho tiempo grabando los .elf en el pendrive desde el PC para luego introducirlo en la consola. Además hemos comprobado que usando el método anterior existen problemas para ejecutar aplicaciones que usan archivos (texturas, sonidos, etc.). Para hacer más rápida la forma en la que enviamos los .elf a la Playstation 2, y evitar otras complicaciones, nos comunicaremos directamente con la consola desde el PC, a través de una red local. Para ello necesitaremos: CD/DVD SwapMagic (nosotros usamos la versión 3.6). 1 pendrive USB. el adaptador de red de la Playstation 2 (la PS2 Slim lo lleva integrado). una tarjeta de red en nuestro PC. un cable de red (RJ45) cruzado. ps2link (disponible en la web [14]). ps2client (incluida en la PS2SDK). La utilidad ps2link se ejecuta en la consola haciendo de servidor, y la utilidad ps2client (incluida en la PS2SDK) que se ejecuta en el PC haciendo de cliente. Primero nos descargaremos el .zip de la última versión de ps2link de la página [14]. En nuestro caso hemos utilizado la versión 1.46. La descomprimimos en una carpeta. Ahora, siguiendo los mismos pasos que en la alternativa a), creamos en el directorio raı́z del pendrive una carpeta llamada SWAPMAGIC. Copiaremos en ella el archivo ejecutable de la ps2link (suele llamarse ps2link.elf ) y el archivo de configuración que lo acompaña (ipconfig.dat). Renombramos el ejecutable ps2link.elf y lo llamamos SMBOOT0.ELF. CAPÍTULO 4. MANUALES DE USUARIO 39 4.1. CÓMO EJECUTAR UN ARCHIVO .ELF EN LA PLAYSTATION 2 Ahora cuando arranque el CD del SwapMagic, podremos arrancar la ps2link desde el pendrive mediante la combinación de teclas arriba + L1. Si sale una pantalla en negro mostrando los datos de la conexión (ip y máscara de red) y terminando con un “ready”, todo habrá salido correctamente y ya tenemos la Playstation 2 preparada para comunicarse en red. El siguiente paso será configurar la red en el PC. Bastará con asignar a la tarjeta de red la ip 192.168.0.1 y la máscara 255.255.255.0. Podemos realizar un ping a la consola para comprobar que la conexión funciona: ping 192.168.0.10 La ip 192.168.0.10 es la que usará por defecto la consola si no modificamos el archivo ipconfig.dat de la ps2link. Ahora, si queremos ejecutar un .elf en la Playstation 2, no tenemos más que ejecutar el siguiente comando desde una terminal en el PC: psc2lient execee host:ejecutable.elf Este modo de arrancar los ejecutables nos será muy útil en el desarrollo ya que gracias a la utilidad ps2client dispondremos de un terminal sobre el que imprimir mensajes de debugging. El ejecutable ps2client lo proporciona la librerı́a PS2SDK, por lo tanto las variables de entorno asociadas han de estar bien configuradas para que ps2client funcione correctamente (ver apéndice ??). Reseteando la consola. Si durante la ejecución de un .elf en la Playstation 2 queremos detener la ejecución y/o ejecutar otro ejecutable, deberemos “resetear” la ps2link usando el comando ps2client reset Configurando la red manualmente. La ps2link asigna por defecto a la Playstation 2 la ip 192.168.0.10, ip que también usa por defecto ps2client. Si por cualquier causa no se puede usar esa ip, podemos asignarla manualmente. Primero le asignaremos la ip a la Playstation 2 configurando la ps2link. Esta utilidad se apoya en un archivo de configuración llamado ipconfig.dat, que ha de encontrarse en el mismo directorio que el ejecutable de la ps2link y que por defecto contiene las siguientes lı́neas: ipconfig.dat 192.168.0.10 255.0.0.0 192.168.0.1 # EXTRACNF = mc0:extra.cnf; CAPÍTULO 4. MANUALES DE USUARIO 40 4.1. CÓMO EJECUTAR UN ARCHIVO .ELF EN LA PLAYSTATION 2 En la primera lı́nea se encuentra la ip de la consola, la mascara de red y la puerta de enlace. Editando este archivo podremos configurar la red según nos interese. Luego, podremos ejecutar un .elf en la Playstation 2 usando la ps2client con la opción -h. Por ejemplo, si la Playstation 2 usara la ip 10.13.20.25 el comando que deberemos utilizar es: ps2client -h 10.13.20.25 execee host:texture.elf CAPÍTULO 4. MANUALES DE USUARIO 41 4.2. BALLS: MANUAL DE USUARIO 4.2. Balls: Manual de usuario 4.2.1. Arranque Para arrancar Balls en la Playstation 2 deberemos seguir los siguientes pasos: 1. Descargar el juego de la web [11]. 2. Descomprimir en un directorio. 3. Conectar la Playstation 2 al PC usando un cable de red cruzado y arrancar la Ps2link tal y como se explica en el Apéndice A.2, opción b. 4. Arrancar el juego tal y como se indica en el Apéndice A.2, opción b. El ejecutable se llama balls.elf. También podemos grabar la ISO del juego en un CD y cargarla en la Playstation 2 utilizando un cd swap. 4.2.2. Controles Menús Arriba: mover arriba. Abajo: mover abajo. Equis: seleccionar opción. Juego Stick izquierdo: apuntar. Equis: disparar. Cı́rculo: disparar misil. R1: fijar una bola / soltar una bola fijada. R2: invertir el eje vertical del arma. Start: pausa. CAPÍTULO 4. MANUALES DE USUARIO 42 Bibliografı́a [1] Brent Fox Game Interface Design. Thomson Course Technology PTR, 2005 [2] Chris Seddon OpenGL Game Programming. Wordware Publishing, 2005 [3] Richard S. Wright/Benjamin Lipchak Programación OpenGL. Anaya Multimedia, 2005 [4] Sony Computer Entertaiment Inc. VU User’s Manual Version 3.1. SCEI, 2001 [5] Tim Ryan The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal. Gamasutra Website, 1999. [6] Tim Ryan The Anatomy of a Design Document, Part 2: Documentation Guidelines for the Functional and Technical Specifications. Gamasutra Website, 1999. [7] Tom Meigs Ultimate Game Design. Building Game Worlds. McGraw Hill, 2003 [8] Francisco Espino Espino. Evaluación y Desarrollo de Aplicaciones para la Arquitectura Sony Playstation 2. Facultad de Informática de la ULPGC, 2006 [9] José Manuel Gil Álvarez. Creación de Benchmarks para el Análisis de Prestaciones de la Arquitectura Playstation 2. Facultad de Informática de la ULPGC, 2008. [10] http://www.gamasutra.com [11] http://www.pacogl.com [12] http://www.martinreddy.net/gfx/3d/OBJ.spec [13] http://svn.ps2dev.org [14] http://ps2dev.org/ps2/Loaders/PS2 side boot loaders/ 43