Desarrollo de un Videojuego para Playsation 2 Usando PacoGL

Transcripción

Proyecto Fin de Carrera. Facultad de Informática
Universidad de Las Palmas de Gran Canaria
Desarrollo de un Videojuego para
Playsation 2 Usando PacoGL
Autor
Tutor
Cotutor
: Abraham Martı́n Expósito
: Domingo Benı́tez Dı́az
: Agustı́n Trujillo Pino
Índice general
1. Introducció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. Análisis . . . . . . . . . . . . .
1.8.2. Diseño . . . . . . . . . . . . . .
1.8.3. Implementación . . . . . . . . .
1.8.4. Prueba . . . . . . . . . . . . . .
1.9. Recursos necesarios . . . . . . . . . . .
1.9.1. Hardware . . . . . . . . . . . .
1.9.2. Software . . . . . . . . . . . . .
1.10. Plan de trabajo y temporización . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
5
5
6
7
8
8
9
9
9
10
10
10
10
11
2. Diseño del Videojuego
2.1. Introducción . . . . . . . .
2.2. Antecedentes . . . . . . .
2.3. Descripción . . . . . . . .
2.4. Caracterı́sticas Relevantes
2.5. Género . . . . . . . . . . .
2.6. Plataforma . . . . . . . .
2.7. Arte Conceptual . . . . .
2.8. Diseño grá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 aplicación
3.1.2. Estabilidad . . . . . . . . .
3.1.3. Versión beta del videojuego
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ÍNDICE GENERAL
3.1.4. Validación de la librerı́a gráfica PacoGL
3.1.5. Versión para PC del juego . . . . . . . .
3.2. Objetivos secundarios . . . . . . . . . . . . . . .
3.2.1. Jugabilidad . . . . . . . . . . . . . . . .
3.2.2. Calidad gráfica . . . . . . . . . . . . . .
3.2.3. Conclusiones . . . . . . . . . . . . . . .
3.3. Trabajo futuro . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
4. Manuales de Usuario
4.1. Cómo ejecutar un archivo .elf en la Playstation 2
4.1.1. a) Usando un pendrive. . . . . . . . . . . .
4.1.2. b) A través de una red local. . . . . . . . .
4.2. Balls: Manual de usuario . . . . . . . . . . . . . .
4.2.1. Arranque . . . . . . . . . . . . . . . . . .
4.2.2. Controles . . . . . . . . . . . . . . . . . .
ÍNDICE GENERAL
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
34
35
36
36
36
36
.
.
.
.
.
.
38
38
38
39
42
42
42
2
Capı́tulo 1
Introducción
1.1.
El sector de los videojuegos
Hace unos añ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 más
que asentada en nuestras vidas. En la actualidad, prácticamente en todas las casas
podemos encontrarnos con una consola de videojuegos, un ordenador o un teléfono
móvil, todos dispositivos para los que se pueden desarrollar videojuegos. Además la
sociedad avanza con la tecnologı́a, y la mayorı́a de los niños (tengo que reconocer, que
a mi pesar) ya prefieren una consola de última generación antes que una bicicleta,
unos patines, o cualquier juguete más tı́pico de finales del siglo XX.
Son tantos y tan variados los usuarios de los videojuegos, que quizás ya no
podemos hablar del videojuego como un simple entretenimiento, hay videojuegos que
nos pueden ayudar a aprender matemáticas o fı́sica, o incluso a desarrollar habilidades
que no nos puede enseñar un libro, tales como conducción de vehı́culos, agudeza visual
o incluso capacidades estratégicas. De hecho, en los ú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 diversión con el
conocimiento y la inteligencia, algo que apenas podı́amos encontrar hace unos pocos
años.
Son muchos y muy variados los gé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).
Simulació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 grá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, diseñadores de juegos, diseñadores gráficos, programadores,
guionistas, animadores gráficos, compositores, testadores, etc. Además, el desarrollo de
un videojuego se divide en varias etapas (las tı́picas para cualquier desarrollo software):
análisis, diseño, implementació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 (más de un año), o el má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 planificación y la dirección de un proyecto de videojuegos no están extremadamente cuidadas.
Dado que, como futuros ingenieros, deberemos estar capacitados para poder dirigir
un proyecto informá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: previsualización, diseño de fases, diseño y elaboración de los modelos 3D
(escenario, objetos, personajes, etc.), generación de texturas, creación de sonidos, implementación, optimización, prueba, etc. Realizando un proyecto completo, de principio
1
MMORPG: Massive(ly) Multiplayer Online Role-Playing Game, Juego de Rol Multijugador Masivo Online.
CAPÍTULO 1. INTRODUCCIÓ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 Informática de la ULPGC, en su proyecto fin de carrera “Evaluación y Desarrollo
de Aplicaciones para la Arquitectura Sony Playstation 2” [8] creo la API gráfica
para Playstation 2 PacoGL. Su repercusión en los medios fue notable, y en los foros
españ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 motivó la creación del Grupo de Videojuegos de la Facultad y Escuela Universitarias de Informática de la ULPGC, al cual pertenecemos. La formación
de profesionales para el mundo de los videojuegos en España, y en concreto en Canarias, es escasa, y con la creación de este grupo se ha puesto la primera piedra para
que en un futuro la ULPGC pueda ser puntera en España en el ámbito de la formación universitaria orientada a los videojuegos. El proyecto de Francisco Espino no se
ha quedado estancado, y Jose Manuel Gil Álvarez continuó su trabajo en el proyecto ”‘ Benchmarks para Playstation 2”[9], donde implementó una segunda versión de
la librerı́a PacoGL. El proyecto al que dedicaremos la presente memoria es el tercero
que finaliza con éxito el Grupo de Videojuegos, en el que inicialmente se ha seguido
una lı́nea de investigació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 será 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 estándar OpenGL 1.1, lo que inhibe al programador de la
necesidad de conocer las caracterı́sticas hardware de la consola, pudiendo programar
los gráficos en alto nivel. OpenGL es, con permiso de Direct3d, el estándar gráfico por
excelencia, con la ventaja de que es de libre distribució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
5
1.5. NUESTRO PROYECTO
Figura 1.1: Distribución interna del Emotion Engine
estamos acostumbrados. Normalmente programar en alto nivel resta eficiencia a
nuestro código, ya que usamos instrucciones muy generales y no usamos directamente
la “má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
implementación de las librerı́as está 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 gráficas de libre distribución
para PS2 han hecho.
Disponiendo de una herramienta para generar grá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 estándar OpenGL 1.1, la parte gráfica de nuestro videojuego
será compilable no solo para PS2, sino tambié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) habrá que programarlos especı́ficamente para cada plataforma.
1.5.
Nuestro proyecto
En el proyecto que nos atañe vamos a desarrollar un videojuego prácticamente
desde cero, apoyándonos, eso sı́, en la API PacoGL. Diseñaremos modelos 3D,
crearemos texturas, elaboraremos fases, programaremos la aplicació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 dirección, planificación, coordinación, etcétera en un proyecto
real. No olvidemos que un ingeniero informático no es un mero programador, y
aunque la programación del videojuego posiblemente sea la parte más extensa de nuesCAPÍTULO 1. INTRODUCCIÓN
6
1.6. MOTIVACIONES
tro proyecto, no será necesariamente la más importante, ni de la que aprenderemos más.
Las tareas que abordaremos serán las siguientes:
Estudio de los conceptos de diseño de videojuegos.
Elaboración del guión.
Aprendizaje del entorno de programación de la Playstation 2.
Diseño de los modelos 3D (objetos y escenario).
Elaboración de las texturas.
Diseño e implementación de la aplicación.
Diseño e implementación de la fı́sica del juego.
Implementación de las reglas de juego.
Implementación de funciones para evaluación del rendimiento gráfico.
Testeo y análisis de rendimiento de la librerı́a PacoGL sobre nuestro juego.
Optimización.
Diseño e implementación multiplataforma: Playstation 2 y PC (Linux).
Nuestro videojuego será un shoot’em up (juego de disparos), aunque también podrı́amos encasillarlo en el genero “arcade”. Estará compuesto por una única fase dentro
de un escenario cerrado (una habitación). Básicamente el juego consistirá en disparar
a las bolas que van entrando en la habitación, con la dificultad de que a medida que
pase el tiempo las bolas irán apareciendo con más frecuencia. Cuando haya 20 bolas o
má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 realización de este proyecto:
Salida profesional. Pensamos que el sector de los videojuegos es una de las salidas más atractivas que tiene esta carrera. Además es una industria que aún está por
explotar en España, ası́ que todo lo que aprendamos durante el desarrollo de este
proyecto creemos que nos será muy útil en el futuro para abrirnos paso en la mundo
de los videojuegos.
7
1.7. OBJETIVOS
Afición y realización personal. Para qué negarlo. Una de nuestras principales
motivaciones a la hora de realizar este proyecto ha sido nuestra afición a los videojuegos.
Jugamos bastante y siempre hemos sentido mucha curiosidad por saber cómo funcionan
los juegos. Gran parte de la culpa de que estemos estudiando ingenierı́a informática se
debe a esa afición y a esa curiosidad. Terminar un videojuego que funcione, y más en
una consola, nos llenará de satisfacción, el mejor colofón para terminar la carrera.
1.7.
Objetivos
En la realización de este proyecto vamos a tratar de alcanzar los siguientes objetivos
principales:
Conseguir, al menos, una versió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 gráfico aceptable, concretamente conseguir una tasa
aproximada de 25 frames por segundo.
Completar una versión para PC del videojuego, cumpliendo también con los
objetivos anteriores.
Analizar, testear y validar la librerı́a gráfica PacoGL para su uso en videojuegos
para Playstation 2.
Cumpliendo con los objetivos anteriores, podremos darnos por satisfechos. Además,
también nos hemos marcado una serie de objetivos secundarios, que aunque no entran
dentro de las labores de un ingeniero informático, si será interesante analizarlos una
vez finalice el desarrollo:
Obtener una buena jugabilidad. Que el juego sea divertido y adictivo.
Conseguir que los gráficos sean atractivos, siempre dentro de nuestros lı́mites
como diseñadores grá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. Éste consta de cuatro etapas:
2
Se dice que un videojuego está en su versión beta cuando únicamente quedan por pulir o completar
algunos aspectos del juego, como alguna fase, textura, sonidos, diálogos, etc. El juego, funcionalmente,
está completo y es estable.
8
1.8. METODOLOGIA
Análisis.
Diseño.
Implementació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 elaboración y refinamiento. Describamos los pasos a seguir en cada una de las cuatro
etapas de desarrollo.
1.8.1.
Aná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. Además, de cara a la elaboración del guión del juego, analizaremos
algunos videojuegos para obtener ideas que nos puedan ser útiles.
1.8.2.
Diseño
Esta etapa es quizá la más importante del desarrollo, ya que será cuando decidiremos
cómo será el videojuego que queremos hacer, tanto funcionalmente como gráficamente.
Un buen diseño nos facilitará mucho las cosas en etapas posteriores, y aunque será inevitable volver a esta etapa una vez comience la implementación, será clave para la
calidad y la duración de nuestro proyecto refinar al máximo el diseño del videojuego.
1.8.3.
Implementación
En esta etapa “construiremos” la aplicación en base al diseñ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 diseño. A priori las partes que
difieren en cada plataforma están bien diferenciadas: ventanas (sólo PC), controles y
sonido. La parte gráfica debe ser compatible para ambas plataformas ya que PacoGL
cumple el estándar OpenGL 1.1.
La etapa de implementación deberá contener una sub-etapa necesaria para cumplir
nuestros objetivos: la optimización. En la versión para PC es posible que no nos
encontremos con problemas de rendimiento, pero en la Playstation 2 los recursos
hardware son más limitados, y será necesaria una codificación eficiente para que
nuestro videojuego pueda tener un rendimiento mı́nimo de 25 frames por segundo.
9
1.9. RECURSOS NECESARIOS
La metodologı́a a seguir para compaginar la implementación sobre ambas plataformas será implementar primero una porción para PC (p.e. un mó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 implementación completa
para una de las plataformas y luego portar el código para la otra plataforma, hemos
de tener en cuenta que estamos aprendiendo a desarrollar aplicaciones para Playstation 2 y en la migración de una aplicació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 iteració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 deberá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 conexión a Internet. Con é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
Distribución Linux con las herramientas tı́picas (Editor C-C++, compilador
GCC-G++, navegador, etc.). El entorno de desarrollo para Playstation 2
está creado para funcionar sobre Linux.
Librerı́as GLUT (OpenGL). Necesarias para que funcione la parte gráfica de
nuestro videojuego en su versión para PC (Linux).
10
1.10. PLAN DE TRABAJO Y TEMPORIZACIÓ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 gráfica que utilizaremos para los gráficos del videojuego sobre
la Playstation 2.
Disco SwapMagic. Necesitamos esta utilidad para saltarnos la protección de la
consola y poder ejecutar nuestro videojuego.
ps2link - ps2client. Herramientas que permitirán la comunicació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 temporización
La distribución temporal de las diferentes etapas de las que se compone nuestro
proyecto es la siguiente:
Análisis y Herramientas (170 horas). Esta será la primera etapa que abordaremos,
en ella aprenderemos a utilizar el entorno de desarrollo, los entresijos de OpenGL
y los conceptos básicos de diseño de videojuegos. Abarcará los meses de marzo,
abril y mayo de 2007.
Diseño del guión, diseño gráfico y orientado a objetos (135 horas). Esta etapa se
distribuirá sobre la mitad del desarrollo, durante los meses de abril, mayo, junio
y julio de 2007.
Implementación (200 horas). Esta etapa es la más extensa, y es donde aplicaremos
gran parte de lo trabajado y aprendido en las etapas anteriores. Abarcará los
meses de junio, julio, agosto, octubre y noviembre de 2007. En septiembre nos
tomaremos un descanso.
Validación y pruebas (40 horas). Esta será la etapa final del proyecto. Aunque
deberémos realizar validaciones y pruebas prácticamente desde el comienzo de la
implementación, la mayorı́a del trabajo se concentrará al final, sobre los meses
de noviembre, diciembre y enero de 2008.
11
Capı́tulo 2
Diseño del Videojuego
2.1.
Introducció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 precisión con los controles para eliminar todos los objetivos que se le pongan por delante. Cuanto más rápido acierte el jugador, más puntos
conseguirá 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. Más que modificar los juegos mencionados, hemos intentado
sacar ideas de todos y combinarlas hasta obtener un videojuego consistente y con la
posibilidad de añadir nuevos elementos que favorezcan la diversión. Juegos arcade hay
cientos, y es muy complicado innovar para obtener un juego que se desmarque de los
demás, de ahı́ que hayamos optado por tomar como referencia los juegos arcade más
divertidos del mercado.
2.3.
Descripción
El objetivo del juego es que obtengas el mayor número de puntos posible para
ganarte un puesto en el ranking del juego, para ello tendrás que disparar a las bolas
que irán saliendo de las paredes de la habitación y eliminarlas. Tu arma dispone de
dos tipos de disparo: una ráfaga de balas y un misil. Las balas son ilimitadas, pero
tendrás que recargar tu arma cada vez que se vacı́e un cargador. Los misiles son
limitados, y se obtienen mediante bonus. Además de las lanzaderas de bolas, cada
pared tiene un pequeño hangar. De uno de ellos saldrá de vez en cuando una avioneta
12
2.4. CARACTERÍSTICAS RELEVANTES
que podrás derribar de un disparo, si lo consigues obtendrás un bonus, si no consigues derribarla antes de que aterrice en el otro hangar, habrás perdido la oportunidad.
En el fondo de la habitación tienes un televisor, te podrás distraer con sus
imágenes, pero atento, porque en un momento dado podrás disparar a un objetivo
que saldrá en la tele. Si consigues acertarle te llevarás un premio. ¿Cómo conseguir
muchos puntos? Las pelotas tienen vida limitada, si no las eliminas, desaparecerán,
¿por qué? Las pelotas son más valiosas en el momento en el que son lanzadas, y a
medida que pase el tiempo valdrán menos, hasta que se queden quietas, entonces ya
no servirán para nada y desaparecerán, por lo tanto cuanto antes elimines una pelota,
más puntos te dará!
Tambié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 acción
determinado, todos los objetivos que se encuentren dentro de ese radio, serán dañados.
La partida terminará cuando haya demasiadas pelotas en el suelo. En ese momento
podrás introducir tu puntuación en el ranking acompañada de tu nombre.
2.4.
Caracterı́sticas Relevantes
La caracterı́stica más relevante de nuestro videojuego es el uso de la librerı́a gráfica
PacoGL, de libre distribución y desarrollada por alumnos de la Facultad de Informática
de la ULPGC.
2.5.
Género
Balls es un Shooter Arcade, donde se mezclan la velocidad, diversión y sencillez de
los juegos arcade con la punterı́a de los shooters.
2.6.
Plataforma
Balls está disponible para Playstation 2 y PC (Linux). 1 jugador.
2.7.
Arte Conceptual
En los gráficos 2.1, 2.3 y 2.2 podemos ver las primeras aproximaciones a nuestro
juego hechas sobre el papel.
CAPÍTULO 2. DISEÑO DEL VIDEOJUEGO
13
2.7. ARTE CONCEPTUAL
Figura 2.1: Boceto de previsualización de nuestro juego.
Figura 2.2: Bocetos de previsualización de nuestro juego.
14
2.7. ARTE CONCEPTUAL
Figura 2.3: Boceto de previsualización de nuestro juego.
15
2.8. DISEÑO GRÁFICO
2.8.
Diseño gráfico
Para el desarrollo de nuestro videojuego ha sido necesario el diseño de una serie de
modelos 3D, imprescindibles para dar forma y plasmar en pantalla las ideas elaboradas
en el diseño del guión del videojuego. Estos modelos se componen básicamente de dos
elementos: una estructura tridimensional que da forma al modelo, y una textura o
“piel” que aporta estética y realismo al mismo.
Los modelos que mostramos a continuación son las versiones definitivas que hemos
utilizado en nuestro videojuego. Para llegar a los modelos que necesitá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 vértices. La textura es de 8x8 pı́xels. Es el elemento
que más se repite en el escenario, por lo que hempo procurado mininizar el número de
caras y la resolución de la textura.
16
Suelo
La malla que forma el suelo está compuesta por 4 caras y 6 vértices. La textura
tiene una resolució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 vértices. Su textura tiene una resolución de 128x128
pı́xels. Dado que la textura contiene texto no hemos podido reducir más la calidad
para que el texto sea legible.
17
Impacto
La malla está formada por 5 caras y 8 vértices. Es el único modelo que hemos
creado que no tiene textura. Su tamaño es bastante pequeño, por lo que hemos
considerado que será suficiente con aplicarle un color uniforme usando OpenGL.
Arma
Compuesta por 276 caras y 150 vértices, es el modelo más complejo que hemos
diseñado. Su textura es de 128x128 pı́xels.
18
Misil
Se compone de 46 caras y 37 vértices. Su textura es de 16x16 pı́xels.
Avioneta (normal)
El modelo está formado por 46 caras y 25 vértices. Es el modelo al que más hemos
tenido que reducir la calidad (al principio tenı́a más de 500 caras). Su textura tiene
una resolución de 32x32 pı́xels.
19
Avioneta (dañada)
El modelo es el mismo que el de la avioneta normal. Solo varı́a la textura, a la que se
le han añadido unas estalladuras para simular que la avioneta está a punto de romperse.
Techo
Modelo simple de 4 caras y 6 vértices. Su textura es un mosaico de 64x64 pı́xels.
20
Fondo
Otro modelo simple de 2 caras y 4 vértices, cuya textura tiene una resolución de
128x128 pı́xels.
Lanzadera
Modelo compuesto por 29 caras y 23 vértices. La textura tiene una resolución de
64x64 pı́xels.
21
Pared
En realidad son dos modelos simétricos, uno para la pared izquierda, y otro para
la pared derecha del escenario. Cada pared está compuesta por 70 caras y 46 vé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 carácter.
22
Menú
Textura de fondo del menú del juego. Su resolución es de 256x256 pı́xels. Es fácil
adivinar que su elaboración se ha hecho a partir de una captura del propio videojuego,
aplicándole posteriormente una serie de efectos y colores.
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 versión beta, alcanzar
una tasa aceptable de frames por segundo, que la aplicación sea estable y que demuestre
la validez de la librerı́a grafica PacoGL para realizar videojuegos para la Playstation 2.
Además del desarrollo de una versión para PC. Como objetivos secundarios nos hemos
marcado conseguir un nivel aceptable de jugabilidad y adictividad en el juego y unos
gráficos atractivos.
3.1.1.
Rendimiento de la aplicación
En este aná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 versión distribuida o centralizada estamos haciendo alusión a
la versió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 código del videojuego, tanto en el apartado gráfico como en el del cálculo de la
1
La versión centralizada de PacoGL utiliza únicamente el core del Emotion Engine para realizar
los cálculos, mientras que la versión distribuida se apoya en la unidad vectorial VU1, diseñada precisamente para acelerar los grá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 versión mejorada de PacoGL y la optimización del código de nuestro juego.
En el grá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
versió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 gráfico 3.2 có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 más elementos en el escenario de juego, la tasa cae
hasta los 16 fps aproximadamente.
Con la intenció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 aplicació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.
CAPÍTULO 3. RESULTADOS Y CONCLUSIONES
25
Figura 3.2: FPS, miles de triángulos por segundo y elementos en pantalla a lo largo de
una partida normal (versión distribuida optimizada).
Además, es llevando la librerı́a grá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 gráfico 3.2 podemos ver como se produce
un “efecto escaló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 qué se debe esto?
Este efecto es una consecuencia tı́pica del uso de técnicas de paralelismo. La librerı́a
gráfica PacoGL utiliza la unidad vectorial VU1 del Emotion Engine para optimizar
los cálculos vectoriales y matriciales. Mientras esas unidades vectoriales no se llenen,
podrá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.
Análisis de las optimizaciones
Analicemos las optimizaciones realizadas. Como podemos ver en los gráficos 3.3 y
3.4, la mejora obtenida en el rendimiento del juego al utilizar la versión distribuida de
las librerı́as PacoGL es bastante notable, consiguiendo un speed-up del 39 %. Después
de realizar las optimizaciones sobre el código de nuestro videojuego, tanto de la
parte gráfica como de la parte de la fı́sica, tambié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
26
Figura 3.3: Incremento del rendimiento gráfico utilizando como base la versión centralizada no optimizada.
Figura 3.4: Desglose de los tiempos de ejecución de cada parte del programa.
27
Figura 3.5: Comparación del speed-up obtenido en la parte grá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 optimización ha sido del 18,20 % (ver
figura 3.5). Si miramos la parte grá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 aplicación por cada uno de
ellos, observamos como la optimización de la parte gráfica contribuye aumentando el
rendimiento de la aplicación en un 12 %, mientras que la optimización de la parte de
la fı́sica apenas contribuye con un 1,4 %.
¿Por qué ocurre esto? Es muy simple, como ya habı́amos adelantado en el capitulo
anterior, optimizar una parte de la aplicación que ocupa un porcentaje alto del tiempo
de CPU nos va a reportar más beneficios en el rendimiento global que optimizar una
parte que ocupa un porcentaje bajo del tiempo de CPU. En nuestro caso la parte gráfica ocupaba un 87,44 % del tiempo de CPU, mientras que el cálculo de la fı́sica suponı́a
un 9,21 %. De ahı́ que por mucho que consiguiéramos mejorar la parte del cálculo de la fı́sica, la mejora global del juego debido a esa optimización no iba a ser notable.
Otra cuestión que podemos analizar es por qué 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 número de objetos,
28
Figura 3.6: Distribución del tiempo de CPU a lo largo de una partida entre la parte
gráfica y el cálculo de la fı́sica (versión distribuida optimizada).
menor rendimiento. Pero vamos a analizar en qué medida afecta este incremento al
rendimiento de los gráficos y al rendimiento de la fı́sica. En el gráfico 3.6 podemos
observar cómo a medida que avanza la partida, la parte del cálculo de la fı́sica va
ganando peso frente a la parte gráfica.
¿Cual es la razón por la que la complejidad de la fı́sica aumenta más rápido que la
complejidad gráfica? La respuesta es que la complejidad grá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 pequeña explosión combinatoria. El número de tests de colisión
que han de realizarse entre todas las bolas del escenario viene dado por la siguiente
fórmula, correspondiente a la combinación sin repetición de n elementos, combinados
de 2 en 2:
C2n =
n!
n ∗ (n − 1)
=
2! ∗ (n − 2)!
2
En el gráfico 3.7 vemos enfrentadas la complejidad grá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 gráfico 3.6 con el gráfico 3.7 podemos llegar a la conclusión
de que si vamos introduciendo bolas en nuestro escenario indefinidamente, llegará un
29
Figura 3.7: Aumento de la complejidad de los gráficos y de la fı́sica. Nuestro juego se
detiene al alcanzar las 20 bolas en pantalla (versión distribuida optimizada).
momento en que el cálculo de la fı́sica será más pesado que el de los gráficos. Y esto
nos ha llevado a otra conclusión más interesante aún: con esta experiencia, ahora
tendremos má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 más pesado
computacionalmente. Imaginemos que se desarrolla una nueva versión de la librerı́a
PacoGL, y que su rendimiento es mucho mejor que el de la versión actual, lo cual
nos permitirı́a desarrollar un juego más complejo, y utilizamos el mismo “motor de
fı́sica” que hemos desarrollado. Por ejemplo, creamos un juego donde coexisten más
de 100 elementos colisionables entre sı́. El cuello de botella dejarı́an de ser los gráficos
y pasarı́a a ser el cá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 qué partes de un videojuego merecen más
atenció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 más eficientemente posible.
30
Diseñar y programar un videojuego con las tecnologı́as de hoy en dı́a requiere
una formación ingenieril, saber usar un lenguaje de programació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 versión de la librerı́a y las optimizaciones
realizadas, el juego ha incrementado su rendimiento grá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 versión
para Playstation 2, como en la versió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 acción, y el instante en el que esa acció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 grá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 aplicación, han sido los siguientes:
Bucles infinitos en el cálculo de la fı́sica.
Errores de segmentación al cargar el audio.
Errores de renderizado de triángulos.
Los bucles infinitos en el cálculo de la fı́sica se debı́an básicamente, y explicándolo
sin entrar en muchos detalles, a que en ocasiones al aparecer una nueva bola en el
escenario, ésta lo hacia intersectando con una ya existente, y nuestro motor de fı́sica no
“sabe” resolver esta situación. Hemos solucionado este inconveniente asegurándonos
de que cada bola nueva no sea “colisionable” mientras haya alguna bola intersectando
con ella. Ademá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 cálculo de la colisión, evitando el bucle infinito, pero dejando
sin resolver la colisión. Desde que hemos adoptado esta solución, no se han producido
más fallos de este tipo, ni han aparecido mensajes de advertencia en los numerosos
31
tests realizados.
En la fase de implementació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 más de 3 sonidos cargados en memoria porque siempre
ocurre un fallo de segmentación. En ocasiones esto sucede incluso al cargar un ú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 versión para PC el sonido si está implementado, pero no hemos tenido
tiempo para elaborar una banda sonora completa.
En el apartado gráfico nos hemos encontrado con que en sucesivas ejecuciones de
nuestro videojuego sin resetear la consola, comienzan a pasar cosas extrañas como
triángulos que desaparecen o recortes con los bordes de la pantalla mal hechos. Este
problema siempre se soluciona al resetear la consola. Después de realizar muchas pruebas tanto nosotros como los desarrolladores de la versión de PacoGL utilizada, hemos
llegado a la conclusió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.
Después de abordar estos 3 problemas, podemos afirmar que la estabilidad de la
versión final de nuestro videojuego es bastante buena. En todos los tests realizados
durante las últimas fases del desarrollo no nos hemos vuelto a encontrar los fallos
descritos anteriormente, ni ha aparecido ninguno nuevo.
3.1.3.
Versión beta del videojuego
Funcionalmente nuestro juego se ha completado. Además hemos conseguido que
sea estable y robusto, por lo tanto podemos decir que hemos alcanzado una versión
beta. De cualquier modo debemos puntualizar que algunos elementos de la fase que
hemos diseñado (Ver Documento 2 de diseño, pág. 12) no han sido implementados. Es
el caso, por ejemplo, de la “televisión” del fondo de la habitación, donde se pensaban
incluir una serie de objetivos del juego, y por falta de tiempo hemos decidido sustituir
por una pared normal.
Ademá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 módulo de
sonido del juego, hemos tenido que desecharlo. La iluminación del juego también ha
sido desechada, a pesar de estar implementada, ya que la versión utilizada de PacoGL
no incluye iluminación.
32
3.1.4.
Validación de la librerı́a gráfica PacoGL
Vamos a hacer un pequeño análisis de la librerı́a gráfica PacoGL. Veremos si el
subconjunto del estándar implementado es suficiente, si la librerı́a es estable, si los
resultados en pantalla son correctos, su facilidad de instalación y su sencillez de uso.
Funcionalidad y completitud
PacoGL implementa un subconjunto del estándar OpenGL 1.1, por lo que muchas
funcionalidades no se han tenido en cuenta. En la página ?? enumeramos una por una
cuales han sido implementadas y cuales no. Para mayor información aconsejamos leer
los manuales de usuario que vienen con PacoGL.
Después de haber trabajado paralelamente con PacoGL y con la versión de OpenGL
para Linux (GLUT), podemos decir que están implementadas las funcionalidades
básicas. Sólo hemos echado en falta dos: el blending (en la primera versión de PacoGL)
y la iluminación (en la última versión de PacoGL, que es la que hemos utilizado). Al
estar implementadas en distintas versiones de la librerı́a no dudamos que coexistirán
en futuras versiones.
Estabilidad
En cuanto a la estabilidad de la librerı́a, hemos de decir que no nos hemos encontrado con ningún problema, no se han producido “cuelgues” ni fallos destacables de
ningún tipo. Es más, si comparamos PacoGL con su homónima para PC (GLUT freeglut), nos encontramos con que esta ú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 versión para PC desarrollada desde 1999 y que actualmente va por
la versió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
ciñe perfectamente al estándar, partiendo de la base, claro está, de que GLUT es una
buena referencia para contrastar este aspecto. Tanto las perspectivas, como los colores,
rotaciones, traslaciones, texturizado, etcé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
televisió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.
33
Figura 3.8: Capturas del juego en el PC (izquierda) y en la Playstation 2 (derecha).
Facilidad de instalación y uso
La instalación de PacoGL se hace un poco larga ya que previamente debemos
instalar la PS2SDK. En el apéndice de este documento explicamos detalladamente
có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
será 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 útiles en los que podemos fijarnos para realizar nuestros primeros programas
para Playstation 2.
3.1.5.
Versión para PC del juego
En la versión para PC nos hemos encontrado con dos problemas que en ningún
caso han aparecido en la versió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 compilació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 aplicación sucesivas veces, en algunas
ejecuciones el problema persiste y en otras desaparece. No hemos encontrado una
solución para este problema que, reiteramos, no ocurre en la versió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
34
3.2. OBJETIVOS SECUNDARIOS
algú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 compilación. Además nunca nos hemos encontrado con
este bug en la versión para Playstation 2, por lo que hemos deducido que el fallo
debe encontrarse en una zona dependiente de la plataforma (rató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 versión del juego que realmente
funciona, y sin añadir demasiado código. En cuanto al rendimiento diremos que no es
comparable el obtenido en la PS2 al obtenido en el PC. En una máquina de prestaciones
“medias” hemos obtenido tasas por encima de los 200 frames por segundo, mientras
que en una má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 consecución de estos objetivos secundarios de jugabilidad y calidad
gráfica, hemos contado con la colaboración de varias personas ajenas al proyecto. Dado
que la opinión que se puede dar tanto de la jugabilidad, como de la calidad gráfica,
es bastante subjetiva, hemos considerado que la opinión de unas personas que no han
participado en el desarrollo será mucho más útil y cercana a lo que serı́a un usuario
final de nuestra aplicación. En definitiva, ellos actuarán de beta-testers de nuestro
videojuego.
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
páginas web en formato flash o java.
3.2.2.
Calidad gráfica
En cuanto a los gráficos, hemos recibido las siguientes crı́ticas:
Los gráficos son algo “feos”, sobre todo los de las paredes, se nota que se podrı́a
haber trabajado más en ellos.
Se podrı́an haber introducido mas efectos especiales.
El fondo del menú sı́ está logrado.
3.2.3.
Conclusiones
Tal y como sospechábamos, nuestra habilidad como artistas grá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 estética, sino con el de la calidad, funcionalidad y la
innovación.
En cuanto a la jugabilidad, hemos aprendido algo muy importante: hay que tener en
cuenta la opinión de usuarios potenciales del videojuego desde las fases más tempranas
del desarrollo. Será 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 investigación y desarrollo que han llevado tanto nuestro proyecto, como otros proyectos paralelos del Grupo de Videojuegos, proponemos las siguientes
ideas para proyectos futuros:
Implementació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 está en la Playstation 3 en sus primeros meses de vida, por lo que no serı́a
36
3.3. TRABAJO FUTURO
descabellado realizar un proyecto de investigación y desarrollo sobre la nueva
consola de Sony.
Implementación de PacoGL para PSP. También seria interesante obtener una
versió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 más y
conseguir resultados más cercanos a los juegos comerciales.
Implementación de librerı́as de sonido para Playstation 2. Dado que no hemos
conseguido obtener una librerı́a de sonido aceptable para la consecució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 estándar OpenAL
(homólogo a OpenGL pero en el ámbito del audio).
Completar PacoGL con las funciones OpenGL 1.1 no implementadas. Dado que
PacoGL tiene funciones del estándar sin implementar (las de iluminación, por
ejemplo), serı́a interesante añadir má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 está diseñ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 código del
propio videojuego para las librerı́as, y luego modificar el código restante para
integrar el motor de fı́sica nuevo.
37
Capı́tulo 4
Manuales de Usuario
4.1.
Có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 versión 3.6).
Este mé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 menú principal del SwapMagic
podremos arrancar cualquiera de los 4 ejecutables usando la correspondiente combinación de botones del pad de la Playstation 2:
Arriba
Arriba
Arriba
Arriba
+
+
+
+
L1
L2
R1
R2
38
4.1. CÓMO EJECUTAR UN ARCHIVO .ELF EN LA PLAYSTATION 2
Nota: Hemos tenido problemas con este mé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 través de una red local.
El anterior mé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. Además hemos comprobado que usando
el método anterior existen problemas para ejecutar aplicaciones que usan archivos
(texturas, sonidos, etc.).
Para hacer más rá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 través de una red local. Para ello necesitaremos:
CD/DVD SwapMagic (nosotros usamos la versió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 última versión de ps2link de la página [14].
En nuestro caso hemos utilizado la versió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 configuración que
lo acompaña (ipconfig.dat). Renombramos el ejecutable ps2link.elf y lo llamamos
SMBOOT0.ELF.
CAPÍTULO 4. MANUALES DE USUARIO
39
Ahora cuando arranque el CD del SwapMagic, podremos arrancar la ps2link desde
el pendrive mediante la combinación de teclas arriba + L1. Si sale una pantalla en
negro mostrando los datos de la conexión (ip y máscara de red) y terminando con un
“ready”, todo habrá salido correctamente y ya tenemos la Playstation 2 preparada
para comunicarse en red.
El siguiente paso será configurar la red en el PC. Bastará con asignar a la tarjeta de
red la ip 192.168.0.1 y la máscara 255.255.255.0. Podemos realizar un ping a la consola
para comprobar que la conexión funciona:
ping 192.168.0.10
La ip 192.168.0.10 es la que usará 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 más que ejecutar
el siguiente comando desde una terminal en el PC:
psc2lient execee host:ejecutable.elf
Este modo de arrancar los ejecutables nos será muy ú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 apéndice ??).
Reseteando la consola. Si durante la ejecución de un .elf en la Playstation 2 queremos detener la ejecució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 tambié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 configuració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;
40
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 según nos interese. Luego,
podremos ejecutar un .elf en la Playstation 2 usando la ps2client con la opció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
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 Apéndice A.2, opción b.
4. Arrancar el juego tal y como se indica en el Apéndice A.2, opción b. El ejecutable
se llama balls.elf.
También podemos grabar la ISO del juego en un CD y cargarla en la Playstation 2
utilizando un cd swap.
4.2.2.
Controles
Menús
Arriba: mover arriba.
Abajo: mover abajo.
Equis: seleccionar opció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.
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 Programació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. Evaluación y Desarrollo de Aplicaciones para la Arquitectura Sony Playstation 2. Facultad de Informática de la ULPGC, 2006
[9] José Manuel Gil Álvarez. Creación de Benchmarks para el Análisis de Prestaciones
de la Arquitectura Playstation 2. Facultad de Informá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

Desarrollo de un Videojuego para Playsation 2 Usando PacoGL

Transcripción

Documentos relacionados