Air Warriors Documentation

Proyecto fin de carrera
Desarrollo de un videojuego en la plataforma

PlayStation Portable (PSP)
Jon Alonso Masa

Carlos Calvo Serrano
Director: Alejandro de Celis Solana
Bilbao, septiembre de 2007

Resumen
Un videojuego es un programa informático creado fundamentalmente para divertir. Se basa en

la interacción entre una persona y un aparato electrónico (videoconsola, teléfono móvil, PC…)
donde se ejecuta. Los videojuegos recrean entornos virtuales en los cuales el jugador puede
controlar un personaje o cualquier otro elemento de dicho entorno para conseguir una serie de
objetivos por medio de unas reglas determinadas. Tras este sencillo concepto subyace un
complejo conjunto de tecnologías y de técnicas de programación que van desde la generación
y gestión de entornos 3D, a la aplicación de sofisticados algoritmos de programación.
El propósito de este proyecto es desarrollar un videojuego en una plataforma novedosa como

es la videoconsola PSP. Se trata ante todo de completar, dentro de un marco funcional
reducido, el proceso de creación de un videojuego, desde su concepción hasta su terminación.
Esto requiere el conocimiento y dominio de diferentes diseños y técnicas de programación
empleados en este tipo de aplicaciones, así como un profundo trabajo previo de investigación
acerca de las posibilidades que existen en cuanto a la programación de videojuegos para la
PSP. Este estudio inicial abarca tanto aspectos técnicos de la videoconsola objetivo, como
lenguajes de programación, librerías y herramientas, y precede al diseño e implementación del
videojuego, que constituyen el verdadero grueso del proyecto. Dada la envergadura de un
proyecto de estas características, la mayor parte del esfuerzo va dirigida a las tecnologías de
gráficos 3D y WI-FI.
Descriptores
Programación 3D, WI-FI, videojuego, PSP, C++.
iii
Índice de contenido
1. INTRODUCCIÓN ................................................................................................................ 1
2. OBJETIVOS DEL PROYECTO .............................................................................................. 3
2.1 NECESIDAD DE PARTIDA....................................................................................................3

2.2 DEFINICIÓN DEL PROYECTO .............................................................................................3
2.2.1 Objetivos del proyecto......................................................................................... 3
2.2.2 Alcance del proyecto .......................................................................................... 4
2.3 PRODUCTO FINAL...............................................................................................................5
2.4 DESCRIPCIÓN DE LA REALIZACIÓN .................................................................................5
2.4.1 Método de desarrollo........................................................................................... 5
2.4.2 Tareas principales ................................................................................................. 6
2.5 ORGANIZACIÓN.................................................................................................................8
2.5.1 Esquema organizativo .......................................................................................... 8
2.5.2 Equipo de trabajo ................................................................................................. 9
2.6 CONDICIONES DE EJECUCIÓN ......................................................................................10
2.6.1 Entorno de trabajo.............................................................................................. 10
2.6.2 Interlocución durante el proyecto.................................................................... 10
2.6.3 Recepción de los productos ............................................................................. 11
2.6.4 Gestión de cambios, modificaciones e incidencias ...................................... 11
2.7 PLANIFICACIÓN................................................................................................................11
2.7.1 Estimación de cargas de trabajo ..................................................................... 11
2.7.2 Reparto de cargas por perfiles ......................................................................... 13
2.7.3 Plan de trabajo.................................................................................................... 14
3. INVESTIGACIÓN TECNOLÓGICA................................................................................... 17
3.1 INTRODUCCIÓN................................................................................................................17
3.2 PSP ......................................................................................................................................17
3.2.1 Características técnicas .................................................................................... 18
3.2.2 Escena .................................................................................................................. 20
3.3 LTE GE .................................................................................................................................21
3.3.1 Sistema de coordenadas................................................................................... 22
3.3.2 Estructura del motor............................................................................................ 23
3.3.3 Clase IUnknown ................................................................................................... 24
3.3.4 Grafo de escena................................................................................................. 25
3.3.5 Temporizador ....................................................................................................... 25
3.3.6 Animadores.......................................................................................................... 25
3.3.7 Cámaras............................................................................................................... 26
3.3.8 Octree .................................................................................................................. 27
3.3.9 Eventos ................................................................................................................. 27
3.3.10 Efectos especiales .............................................................................................. 27
3.3.11 Colisiones.............................................................................................................. 30
3.3.12 Terreno irregular................................................................................................... 31
v
3.3.13 Skybox ................................................................................................................... 32
3.3.14 Sombras ................................................................................................................ 33
3.4 HERRAMIENTAS Y TUTORIALES ........................................................................................ 33
3.4.1 Programación ...................................................................................................... 33
3.4.1.1 Cómo ejecutar hombrew en la PSP ...............................................................................33
3.4.1.2 PSPLINK .................................................................................................................................36
3.4.1.3 iR Shell...................................................................................................................................39
3.4.1.4 Cómo instalar LTE GE en sistemas Win32 .......................................................................40
3.4.1.5 Cómo compilar una aplicación creada con LTE GE usando Microsoft Visual C++
2005 Express Edition ...........................................................................................................41
3.4.1.6 Cómo preparar una aplicación de prueba con LTE GE ............................................44
3.4.1.7 Resolución de problemas de programación ...............................................................48
3.4.2 Modelado ............................................................................................................ 50
3.4.2.1 MilkShape 3D ......................................................................................................................51
3.4.2.2 Cómo corregir la posición y el desplazamiento en los archivos SMD .....................53
3.4.2.3 Q3Radiant ...........................................................................................................................54
3.4.2.4 WAD2BMP............................................................................................................................57
3.4.3 Comunicaciones ................................................................................................. 57
3.4.3.1 Modo ad-hoc. ....................................................................................................................59
3.4.3.2 Modo infraestructura.........................................................................................................59
4. ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA ............................................................ 61
4.1 INTRODUCCIÓN ............................................................................................................... 61

4.2 DESCRIPCIÓN GENERAL ................................................................................................. 61
4.3 ELEMENTOS DEL SISTEMA................................................................................................. 62
4.3.1 Opciones y modos de juego ............................................................................. 62
4.3.2 Modo aventura ................................................................................................... 64
4.3.2.1 Acciones del personaje del jugador..............................................................................64
4.3.2.2 Elementos del juego..........................................................................................................64
4.3.2.3 HUD .......................................................................................................................................65
4.3.2.4 Cámara ...............................................................................................................................65
4.3.2.5 Colisiones .............................................................................................................................65
4.3.3 Modo arcade ...................................................................................................... 65
4.3.3.1 Acciones de la nave del jugador ...................................................................................65
4.3.3.2 Atributos de las naves .......................................................................................................66
4.3.3.3 Elementos del juego..........................................................................................................67
4.3.3.4 HUD .......................................................................................................................................69
4.3.3.5 Cámara ...............................................................................................................................69
4.3.3.6 Colisiones .............................................................................................................................69
5. ESPECIFICACIÓN DEL DISEÑO........................................................................................ 71
5.1 INTRODUCCIÓN ............................................................................................................... 71

5.2 DIAGRAMA DE ESTADOS ................................................................................................ 71
5.3 DIAGRAMA DE CLASES ................................................................................................... 74
5.3.1 Estados y máquina de estados ......................................................................... 75
vi
5.3.1.1 Clase State ..........................................................................................................................75
5.3.1.2 Clase StateMachine ..........................................................................................................75
5.3.2 Clases base elementales ................................................................................... 76
5.3.2.1 Clase Object3D ..................................................................................................................76
5.3.2.2 Clase GameObject3D ......................................................................................................76
5.3.3 Elementos del menú ........................................................................................... 76
5.3.3.1 Clase SelectionBallMenu ..................................................................................................76
5.3.3.2 Clases SelectionBall y LightingSelectionBall ..................................................................77
5.3.3.3 Clases LightingBillboard y FlyCircleLightingBillboard ...................................................77
5.3.3.4 Clase TexturedBox..............................................................................................................77
5.3.4 Comportamientos............................................................................................... 77
5.3.4.1 Clase Behaviour..................................................................................................................77
5.3.4.2 Clases ObjectBehaviour, GameBehaviour y PlayerSpaceshipBehaviour ...............77
5.3.4.3 Clase NormalFireBehaviour ..............................................................................................78
5.3.4.4 Clase TurningBehaviour.....................................................................................................78
5.3.4.5 Clase LateralTranslationBehaviour ..................................................................................78
5.3.4.6 Clase FitToGameAreaBehaviour .....................................................................................78
5.3.4.7 Clases ActivatingBehaviour y MoveAfterActivatingBehaviour .................................78
5.3.4.8 Clase PursuitBehaviour ......................................................................................................79
5.3.4.9 Clase TiltingBehaviour........................................................................................................79
5.3.4.10 Clase DeceleratingBehaviour......................................................................................79
5.3.4.11 Clases ChangeFactionBehaviour y ColouredChangeFactionBehaviour ...........79
5.3.5 Juego.................................................................................................................... 79
5.3.5.1 Clase Game ........................................................................................................................79
5.3.5.2 Clase CollisionFaction .......................................................................................................80
5.3.5.3 Clase CollisionController ...................................................................................................80
5.3.5.4 Clases CollisionManager, ArcadeCollisionManager y AdventureCollisionManager....80
5.3.5.5 Clases GameHUD y ArcadeGameHUD .........................................................................80
5.3.6 Juego arcade y aventura ................................................................................. 81
5.3.6.1 Clases ArcadeGame y AdventureGame .....................................................................81
5.3.6.2 Clase EnemySpaceshipGenerator..................................................................................81
5.3.6.3 Clases ArcadeGameBackground, TerrainGenerator y FlyingCamera ....................81
5.3.7 Naves (modo arcade) ....................................................................................... 81
5.3.7.1 Clase Spaceship.................................................................................................................81
5.3.7.2 Clase PlayerSpaceship......................................................................................................81
5.3.7.3 Clases EnemySpaceship, PursuitEnemySpaceship, TurningEnemySpaceship y
LateralEnemySpaceship ...................................................................................................82
5.3.7.4 Clases Tail y EnemySpaceshipTail....................................................................................82
5.3.8 Armamento y disparos (modo arcade)........................................................... 82
5.3.8.1 Clase Weapons ..................................................................................................................82
5.3.8.2 Clases LinearCanon y LockingCanon ............................................................................82
5.3.8.3 Clases DartSingleCanon, DartDualCanon, DartTripleCanon y DartLockingCanon......83
5.3.8.4 Clases W01SingleCanon, W01DoubleCanon y W01TripleCanon..............................83
5.3.8.5 Clases Shot y PursuitShot ...................................................................................................83
vii
5.3.9 Items, explosiones (modo arcade) y portales (modo aventura).................. 83
5.3.9.1 Clase Item ...........................................................................................................................83
5.3.9.2 Clases ExtraShieldsItem, DualCanonItem y TripleCanonItem ....................................83
5.3.9.3 Clase ExplosionBillboard ...................................................................................................83
5.3.9.4 Clase PortalBillboard .........................................................................................................84
5.3.10 Gestión de eventos (modo arcade) ................................................................ 84
5.3.10.1 Clase ArcadeGameEventController..........................................................................84
5.3.10.2 Clase ArcadeGameEvent............................................................................................84
5.3.10.3 Clases ArcadeGameFireForgetEvent y ArcadeGameContinuousEvent ............84
5.3.10.4 Clase CreationArcadeGameEvent............................................................................84
5.3.10.5 Clase MissionCompletedArcadeGameEvent ..........................................................85
5.3.10.6 Clase RadioArcadeGameEvent .................................................................................85
5.3.11 Gestión del motor y de los eventos de la entrada y del GUI ........................ 85
5.3.11.1 Clases EngineController y MyEventReceiver ............................................................85
5.3.11.2 Clase EventController....................................................................................................85
5.3.11.3 Clase EventValue...........................................................................................................86
5.3.11.4 Clases InputEventValue y GUIEventValue ................................................................86
5.3.12 Personajes (modo aventura) ............................................................................. 86
5.3.12.1 Clase AdventureGuy.....................................................................................................86
5.3.12.2 Clases PlayerControlledGuy y TalkingGuy ................................................................86
5.3.13 Observer ............................................................................................................... 86
5.3.13.1 Clase Observable ..........................................................................................................86
5.3.13.2 Clases Observer y DeleteObserver.............................................................................87
5.3.14 Otras clases auxiliares ......................................................................................... 87
5.3.14.1 Clase MessageWindow ................................................................................................87
5.3.14.2 Clase LoadingScreen....................................................................................................87
5.3.14.3 Clase TimeController .....................................................................................................87
5.3.14.4 Clase GameUtils.............................................................................................................87
5.3.14.5 Clases SoundController y SoundFader.......................................................................87
5.3.14.6 Clase StoryTeller .............................................................................................................88
5.3.14.7 Clase GameParameters...............................................................................................88
5.3.14.8 Clase FilePaths................................................................................................................88
5.4 DISEÑO PRELIMINAR DEL MODO MULTIJUGADOR...................................................... 88
5.4.1 Limitaciones de LTE GE ....................................................................................... 88
5.4.2 Modo multijugador ............................................................................................. 89
6. CONSIDERACIONES SOBRE LA IMPLEMENTACIÓN .................................................... 101
6.1 INTRODUCCIÓN ............................................................................................................. 101

6.2 FLUJO DE EJECUCIÓN ................................................................................................... 101
6.3 MODO ARCADE ............................................................................................................. 102
6.3.1 Área de juego.................................................................................................... 102
6.3.2 Movimiento del jugador ................................................................................... 103
6.3.3 Escenario ............................................................................................................ 104
6.3.4 Gestor de eventos............................................................................................. 105
viii
6.3.5 Flujo de ejecución............................................................................................. 106
6.3.6 Gestor de colisiones.......................................................................................... 106
6.4 MODO AVENTURA..........................................................................................................107
6.4.1 Escenario............................................................................................................ 107
6.4.2 Flujo de ejecución............................................................................................. 108
6.4.3 Gestor de colisiones.......................................................................................... 108
7. PLAN DE PRUEBAS ......................................................................................................... 109
7.1 INTRODUCCIÓN..............................................................................................................109
7.2 OBJETIVOS .......................................................................................................................109
7.3 DEFINICIÓN DE LA ESTRATEGIA DE PRUEBA................................................................109
7.4 CRITERIOS DE ACEPTACIÓN .........................................................................................110
7.5 RESULTADOS ....................................................................................................................110
7.5.1 Primera fase ....................................................................................................... 110
7.5.2 Segunda fase .................................................................................................... 112
7.5.3 Tercera fase ....................................................................................................... 113
8. MANUAL DE USUARIO................................................................................................... 115
8.1 INTRODUCCIÓN..............................................................................................................115
8.2 REQUERIMIENTOS TÉCNICOS ........................................................................................115
8.3 INSTALACIÓN Y EJECUCIÓN.........................................................................................115
8.4 MENÚ PRINCIPAL ............................................................................................................115
8.4.1 Menú del modo individual............................................................................... 116
8.4.2 Menú del modo multijugador ......................................................................... 117
8.4.3 Menú de opciones............................................................................................ 118
8.4.3.1 Opciones de sonido ........................................................................................................118
8.4.3.2 Opciones de control........................................................................................................119
8.4.4 Menú de servicios en línea .............................................................................. 120
8.5 MODO INDIVIDUAL ........................................................................................................120
8.5.1 Historia ................................................................................................................ 120
8.5.2 Personajes .......................................................................................................... 122
8.5.3 Naves .................................................................................................................. 122
8.5.4 Ítems.................................................................................................................... 124
8.5.5 Nuevo juego ...................................................................................................... 126
8.5.5.1 Modo arcade ...................................................................................................................127
8.5.5.2 Modo aventura ................................................................................................................128
8.6 ERRORES CONOCIDOS .................................................................................................130
9. CONCLUSIONES ............................................................................................................ 131
10. GLOSARIO ..................................................................................................................... 133
11. BIBLIOGRAFÍA................................................................................................................ 137
12. AGRADECIMIENTOS...................................................................................................... 139
ix
Índice de figuras
FIGURA 2.1. ORGANIGRAMA PARA EL DESARROLLO DE UN VIDEOJUEGO. ................................................. 8
FIGURA 2.2. DIAGRAMA GANTT DE LAS FASES GENERALES DEL PROYECTO. .............................................. 14
FIGURA 3.1. VISTA FRONTAL Y POSTERIOR DE LA VIDEOCONSOLA PORTÁTIL PSP. ...................................... 17
FIGURA 3.2. SISTEMA DE COORDENADAS DE LTE GE (MANO IZQUIERDA). ............................................... 23
FIGURA 3.3. CONEXIÓN EN MODO AD-HOC.......................................................................................... 58
FIGURA 3.4. CONEXÍON EN MODO INFRAESTRUCTURA. ........................................................................... 58
FIGURA 5.1. DIAGRAMA DE ESTADOS GENERAL...................................................................................... 72
FIGURA 5.2. DIAGRAMA DE ESTADOS DEL ESTADO ADVENTUREGAME. .................................................... 73
FIGURA 5.3. DIAGRAMA DE ESTADOS DEL ESTADO ARCADEGAME.......................................................... 73
FIGURA 5.4. INTERCAMBIO DE MENSAJES DEL MODO MULTIJUGADOR. ..................................................... 89
FIGURA 5.5. DIAGRAMA DE CLASES: MODO MULTIJUGADOR. ................................................................. 90
FIGURA 5.6. DIAGRAMA DE CLASES: ESTADOS Y MÁQUINA DE ESTADOS................................................... 91
FIGURA 5.7. DIAGRAMA DE ESTADOS: ELEMENTOS DEL MENÚ. ................................................................. 92
FIGURA 5.8. DIAGRAMA DE CLASES: COMPORTAMIENTOS. ..................................................................... 93
FIGURA 5.9. DIAGRAMA DE CLASES: JUEGO. ......................................................................................... 94
FIGURA 5.10. DIAGRAMA DE CLASES: JUEGO ARCADE Y AVENTURA ........................................................ 95
FIGURA 5.11. DIAGRAMA DE CLASES: NAVES (MODO ARCADE). ............................................................ 96
FIGURA 5.12. DIAGRAMA DE ESTADOS: ARMAMENTO Y DISPAROS (MODO ARCADE). .............................. 97
FIGURA 5.13. DIAGRAMA DE CLASES: ÍTEMS, EXPLOSIONES (MODO ARCADE) Y PORTALES (MODO
AVETNTURA).................................................................................................................................. 98
FIGURA 5.14. DIAGRAMA DE CLASES: CLASES BASE ELEMENTALES............................................................ 98
FIGURA 5.15. DIAGRAMA DE CLASES: GESTIÓN DE EVENTOS (MODO ARCADE). ....................................... 99
FIGURA 5.16. DIAGRAMA DE CLASES: GESTIÓN DE EVENTOS DE LA ENTRADA Y DEL GUI. .......................... 99
FIGURA 5.17. DIAGRAMA DE CLASES: PERSONAJES (MODO AVENTURA) Y OBSERVER. ............................ 100
FIGURA 5.18. DIAGRAMA DE CLASES: OTRAS CLASES AUXILIARES........................................................... 100
FIGURA 6.1. BUCLE DE EJECUCIÓN DEL VIDEOJUEGO. .......................................................................... 101
FIGURA 6.2. DISPOSICIÓN DEL ESCENARIO, CÁMARA Y ÁREA DE JUEGO................................................ 102
FIGURA 6.3. UMBRAL DE CREACIÓN. ................................................................................................... 103
FIGURA 6.4. MOVIMIENTO DE LA NAVE DEL JUGADOR. ......................................................................... 103
FIGURA 6.5. EVOLUCIÓN DEL ESCENARIO Y LA CÁMARA....................................................................... 104
FIGURA 6.6. MAPAS DE ALTURAS. ........................................................................................................ 105
FIGURA 6.7. FLUJO DE EJECUCIÓN DEL MODO ARCADE........................................................................ 106
FIGURA 6.8. FLUJO DE EJECUCIÓN DEL MODO AVENTURA..................................................................... 108
FIGURA 8.1. MENÚ PRINCIPAL. ............................................................................................................ 116
FIGURA 8.2. MENÚ DEL MODO INDIVIDUAL. ......................................................................................... 116
FIGURA 8.3. MENÚ DEL MODO MULTIJUGADOR.................................................................................... 117
FIGURA 8.4. MENÚ DE OPCIONES........................................................................................................ 118
FIGURA 8.5. OPCIONES DE SONIDO..................................................................................................... 118
FIGURA 8.6. OPCIONES DE CONTROL. ................................................................................................. 119
FIGURA 8.7. MENÚ DE SERVICIOS EN LÍNEA........................................................................................... 120
FIGURA 8.8. VISTA EXTERIOR DEL W-01................................................................................................ 123
FIGURA 8.9. VISTA EXTERIOR DEL DARDO.............................................................................................. 123
FIGURA 8.10. VISTA EXTERIOR DEL DOBLE DARDO. ................................................................................ 123
x
FIGURA 8.11. VISTA EXTERIOR DEL DARDO AVANZADO. ........................................................................124
FIGURA 8.12. VISTA EXTERIOR DEL SEMBRADOR DE MUERTE....................................................................124
FIGURA 8.13. VISTA EXTERIOR DEL ÍTEM DE DISPARO DOBLE....................................................................125
FIGURA 8.14. VISTA EXTERIOR DEL ÍTEM DE DISPARO TRIPLE.....................................................................125
FIGURA 8.15. VISTA EXTERIOR DEL ÍTEM DE NIVEL DE ESCUDOS EXTRA......................................................125
FIGURA 8.16. IMAGEN INICIAL DE LA INTRODUCCIÓN DEL JUEGO. .........................................................126
FIGURA 8.17. PANTALLA DE SELECCIÓN DEL MODO DE JUEGO..............................................................126
FIGURA 8.18. PANTALLA DE CARGA DEL MODO ARCADE......................................................................127
FIGURA 8.19. TRANSMISIÓN DE RADIO DEL MODO ARCADE...................................................................127
FIGURA 8.20. ELEMENTOS DEL JUEGO DEL MODO ARCADE. ..................................................................128
FIGURA 8.21. PORTALES Y HUD DEL MODO AVENTURA.........................................................................129
FIGURA 8.22. PERSONAJES DEL MODO AVENTURA. ...............................................................................129
FIGURA 8.23. MENSAJE INTERACCIÓN DEL MODO AVENTURA. ..............................................................130
Índice de tablas
TABLA 2.1. ESTIMACIÓN GLOBAL DE CARGAS.........................................................................................12
TABLA 2.2. ESTIMACIÓN DETALLADA DE CARGAS ....................................................................................13
TABLA 2.3. REPARTO DE CARGAS POR PERFIL..........................................................................................14
TABLA 2.4. PLAN DE TRABAJO................................................................................................................15
TABLA 3.1. COMANDOS BÁSICOS DE PSPLINK. .....................................................................................38
TABLA 6.1. RELACIÓN DE FACCIONES Y COLISIONES DEL MODO ARCADE...............................................107
TABLA 7.1. RESULTADOS DE LAS PRUEBAS DE UNIDAD DE LA PRIMERA FASE. .............................................112
TABLA 7.2. RESULTADOS DE LAS PRUEBAS DE UNIDAD DE LA SEGUNDA FASE. ...........................................113
TABLA 7.3. RESULTADOS DE LAS PRUEBAS DE LA TERCERA FASE. ..............................................................114
Índice de código
CÓDIGO 3.1. EXTRACTO DE CÓDIGO DEL EJEMPLO 04.MOVEMENT. INVOCACIÓN DEL MÉTODO DROP()
DESPUÉS DE ASIGNAR EL OBJETO ELIMINADO A UN NODO DE ESCENA................................................24
CÓDIGO 3.2. EXTRACTO DE CÓDIGO DEL EJEMPLO 08.SPECIALFX. CÓMO AÑADIR UN EFECTO DE AGUA.
....................................................................................................................................................28
CÓDIGO 3.3. EXTRACTO DE CÓDIGO DEL EJEMPLO 08.SPECIALFX. CÓMO CREAR UN SISTEMA DE
PARTÍCULAS QUE SIMULA EL FUEGO. ................................................................................................29
CÓDIGO 3.4. EXTRACTO DE CÓDIGO DEL EJEMPLO 10.RENDERTOTEXTURE. CÓMO CREAR LA TEXTURA DE
RENDERIZADO................................................................................................................................30
CÓDIGO 3.5. EXTRACTO DE CÓDIGO DEL EJEMPLO 10.RENDERTOTEXTURE. CÓMO CAMBIAR EL OBJETIVO
DE RENDERIZADO...........................................................................................................................30
CÓDIGO 3.6. ASIGNACIÓN DE UN SELECTOR DE TRIÁNGULOS A UN NODO DE ESCENA.............................31
CODIGO 3.7. EXTRACTO DE CÓDIGO DEL EJEMPLO 09.TERRAINRENDERING. CÓMO CREAR UN TERRENO
IRREGULAR. ...................................................................................................................................32
CÓDIGO 3.8. EXTRACTO DE CÓDIGO DEL EJEMPLO 09.TERRAINRENDERING. CÓMO CREAR UNA SKYBOX.32
CÓDIGO 3.9. CONFIGURACIÓN DEL ARCHIVO PSPLINK.INI PARA HACER USO DE LA CONEXIÓN USB HOSTFS.
....................................................................................................................................................37
CÓDIGO 3.10. LÍNEA DE CÓDIGO EN EL BUILD.MAK QUE ELIMINA EL ARCHIVO ELF STRIPPED.....................38
CÓDIGO 3.11. CÓMO GENERAR MANUALMENTE EL ARCHIVO ELF STRIPPED............................................38
xi
CÓDIGO 3.12. CONTENIDO DE UN ARCHIVO MAKEFILE GENÉRICO PARA LTE GE.................................... 41
CÓDIGO 3.13. CONTENIDO DEL ARCHIVO CLEAN.BAT........................................................................... 43
CÓDIGO 3.14. CONTENIDO DEL ARCHIVO REBUILD.BAT. ........................................................................ 43
CÓDIGO 3.15. APLICACIÓN DE PRUEBA (BAREBONES) PARA UTILIZAR LTE GE......................................... 48
CÓDIGO 3.16. SOLUCIÓN AL CONFLICTO DE NOMBRES DENTRO DE WCHAR.H. ....................................... 49
CÓDIGO 3.17. ARCHIVO MD2.QC DE EJEMPLO. ................................................................................... 53
CÓDIGO 3.18. EXTRACTO DE UN ARCHIVO SMD DE EJEMPLO. .............................................................. 54
CÓDIGO 3.19. EXTRACTO DE CÓDIGO DEL EJEMPLO 02.QUAKE3MAP. CÓMO AÑADIR UN ARCHIVO .PK3
AL SISTEMA DE FICHEROS DE LTE GE............................................................................................... 57
CÓDIGO 3.20. ARGUMENTOS DE WAD2BMP......................................................................................... 57
xii
INTRODUCCIÓN
1. INTRODUCCIÓN
En este capítulo se ofrece una visión general del contenido de la presente memoria. Los
diferentes capítulos de los que ésta consta son:
1. Introducción. Descripción del contenido del resto de los capítulos.
2. Objetivos del proyecto. Se describen los diferentes objetivos del proyecto, su alcance,
las tareas a desarrollar para realizarlos y la planificación temporal.
3. Investigación tecnológica. Documento que presenta una elaboración teórica de las

diferentes tecnologías empleadas en el desarrollo del proyecto.
4. Especificación de requisitos del sistema. Describe los diferentes requisitos exigidos

para el desarrollo del proyecto.
5. Especificación del diseño. Recoge las diferentes vistas del diseño del Proyecto.
6. Consideraciones sobre la implementación. Recoge los diferentes aspectos a incluir

o resaltar sobre la implementación del sistema en desarrollo.
7. Plan de pruebas. Recoge las pruebas realizadas para garantizar la calidad del código
obtenido tras las fases de análisis y diseño.
8. Manual del usuario. Documento que explica cómo hacer uso de la aplicación
desarrollada a nivel de usuario.
9. Conclusiones. Análisis de los objetivos alcanzados y consideraciones adicionales.
Al final de la memoria se incluye la bibliografía y una serie de anexos, a saber: glosario y

agradecimientos.
1
OBJETIVOS DEL PROYECTO
2. OBJETIVOS DEL PROYECTO
2.1 NECESIDAD DE PARTIDA

La aparición de la videoconsola PSP en el mercado Europeo (Septiembre, 2005) supuso una
revolución para el sector del entretenimiento portátil. Sus características técnicas la hacían casi
equiparable a la exitosa PS2, algo no visto hasta entonces en ninguna otra videoconsola
portátil.
Muchos usuarios creativos comenzaron a preguntarse qué les podía ofrecer la PSP en
términos de desarrollo de software. Si bien existía un SDK oficial proporcionado por Sony, este
se encontraba reservado a las compañías privadas encargadas de la creación de contenidos
para la marca japonesa, y pronto la comunidad de usuarios comenzó a crear su propio SDK y
otras herramientas para poder programar sus aplicaciones.
Los videojuegos conforman sólo una parte de las múltiples aplicaciones que pueden ejecutarse
sobre una PSP, aunque frecuentemente son los más representativos en cuanto al empleo de
las diferentes tecnologías existentes (gráficos, sonido, comunicaciones…). La idea de este
proyecto surge del deseo de investigar y aprender acerca de la aplicación de dos tecnologías
concretas, como son gráficos 3D y WI-FI, al desarrollo de videojuegos, pero haciéndolo en un
entorno novedoso con posibilidades distintas a las que podría ofrecer, por ejemplo, un PC. A
esto hay que añadir la aspiración a aportar nuevos contenidos y conocimientos que puedan en
cierta manera ayudar a la creación de aplicaciones por parte de otros usuarios.
2.2 DEFINICIÓN DEL PROYECTO
2.2.1 Objetivos del proyecto
El objetivo fundamental del proyecto es el desarrollo de un videojuego funcional aprovechando

las tecnologías de gráficos 3D y WI-FI que la plataforma PSP tiene a disposición. No obstante,
como parte del proceso surgen dos objetivos secundarios: recopilar toda la información relativa
a la programación de aplicaciones en esta plataforma que pueda ser de utilidad para la
posterior implementación y documentar el proceso de creación del videojuego.
3
PROYECTO FIN DE CARRERA
2.2.2 Alcance del proyecto
A continuación se indican los diferentes aspectos que estarán presentes en el proyecto:
• Resumen de las características técnicas de la PSP, configuración y puesta a punto de

la videoconsola para poder ejecutar aplicaciones creadas por usuarios, y análisis de las
librerías y herramientas de desarrollo empleadas en la implementación.
• Diseño e implementación de un videojuego que haga uso de las tecnologías de

gráficos 3D y WI-FI. Otros aspectos relacionados como la Inteligencia Artificial o el
apartado sonoro, si bien estarán presentes, lo harán en un segundo plano.
Aunque la temática del videojuego aún está por concretar (trama, escenarios,
personajes, etc) como parte de las tareas de concepto y diseño preliminar, hay algunos
aspectos relativos al alcance que ya están definidos. El género escogido es el de los
videojuegos de acción, dado que es uno de los que mejor explota las tecnologías
planteadas anteriormente (gráficos 3D y WI-FI). Por un lado, permite disponer de un
entorno gráfico suficientemente elaborado con el que el jugador pueda interactuar y al
mismo tiempo no exige dedicar demasiado tiempo a otros elementos como pueden ser
el argumento o las reglas de juego. Por otro lado, permite introducir el apartado
multijugador de manera sencilla sobre el concepto inicial. El juego presentará por tanto
dos modos: el modo individual, que consistirá en uno o dos niveles por los que tendrá
que pasar el jugador para completar el juego, y el modo multijugador, donde se
aprovechará la capacidad WI-FI de la consola para que varios jugadores cooperen en
la resolución de los diferentes niveles.
Hay que comentar que otros aspectos del desarrollo como la música o los efectos
sonoros se limitarán a la búsqueda y utilización de material creado por terceros. Lo
mismo se aplica al modelado 3D de personajes y escenarios, pero teniendo en cuenta
que en este caso puede ser necesario crear nuevos contenidos que se adapten al
videojuego. De hecho, debido a la naturaleza académica del proyecto, el alcance es
mucho menor que el que pudiera tener un desarrollo comercial de las mismas
características.
• Creación de librerías que puedan ser de utilidad para posteriores desarrollos de

videojuegos.
En principio, no entra dentro del perímetro funcional del proyecto la programación de otro tipo
de aplicaciones para la PSP, como reproductores de contenidos multimedia o emuladores; a no
ser que sean factores determinantes para lograr el objetivo del proyecto. También hay que
aclarar que todo el trabajo de documentación se centra en el desarrollo de videojuegos y por
tanto, trata únicamente aquellos aspectos importantes en este tipo de aplicaciones.
4
2.3 PRODUCTO FINAL

A lo largo del desarrollo del videojuego se generarán los siguientes productos intermedios y
finales:
• Documentos de requisitos del sistema. Incluye la especificación formal de la

funcionalidad y características que debe presentar el videojuego, desde la idea o
concepto inicial hasta los diferentes detalles de jugabilidad y comportamiento.
• Diseño del sistema. Recoge en base al informe de requisitos las diferentes decisiones
de diseño tomadas para la realización del videojuego y que posteriormente guiarán su
implementación.
• Plan de pruebas del sistema. Especifica las diferentes actividades a realizar para
asegurar el correcto funcionamiento del videojuego una vez sea aprobado por el
director de proyecto.
• Videojuego. Es el producto central del proyecto y se basa esencialmente en la

utilización de tecnologías de gráficos 3D y WI-FI. Su funcionalidad depende totalmente
del diseño preliminar y del trabajo previo de investigación, por lo que no es posible
proporcionar en este documento un análisis detallado de sus características. Estas
serán incluidas en el documento de requisitos del sistema.
• Manual de usuario. Con toda la información relativa al manejo del videojuego

(controles, opciones, jugabilidad…) que pueda ser de interés para el usuario final.
• Guía de programación de videojuegos para la PSP. Es el resultado tanto de la

investigación inicial como de su posterior aplicación al diseño e implementación del
videojuego. Cubre aspectos relacionados con el proceso de programación sobre la
videoconsola portátil (configuración del dispositivo, lenguajes de programación,
herramientas, librerías…) y también aquellos que tengan que ver con la creación de un
videojuego (diseños, técnicas, matemáticas aplicadas…).
• Librerías de utilidad para el desarrollo de videojuegos. De manera opcional,

dependiendo del trabajo realizado en la creación del videojuego, y del estado y calidad
de la herramientas existentes.
2.4 DESCRIPCIÓN DE LA REALIZACIÓN
2.4.1 Método de desarrollo
El plan aplicado se basa en el método de desarrollo por fases, dividiendo la creación del
videojuego en dos etapas bien diferenciadas: diseño (preproducción) e implementación
(producción).
5
Una vez que el equipo de diseño haya determinado el guión del juego en cuanto a temática,
mecánica, interacción y objetivos, se continuará con la búsqueda en Internet de las
herramientas y librerías necesarias para comenzar el proceso de programación. Mientras el
departamento de programación se encarga de implementar la lógica que haga realidad el
diseño generado, los departamentos de gráficos y sonido trabajarán simultáneamente para
integrar finalmente los resultados de los 3 departamentos en lo que será la versión alfa del
videojuego, todo ello procurando cumplir con los plazos de tiempo y coste establecidos.
Por último, el departamento de pruebas se encargará de pulir fallos relacionados con la

jugabilidad, errores del sistema y demás aspectos no deseables, para dar lugar a la versión
final del videojuego.
2.4.2 Tareas principales
1. Organización y control.
a. Organización. Actividad mediante la que se define y prepara la planificación,

asignación de misiones, y el lanzamiento del proyecto y sus sucesivas fases.
b. Control. Seguimiento y control del desarrollo del proyecto, que permita la

rápida detección y solución de problemas que puedan dificultar su marcha.
2. Concepto. Actividad mediante la que se trata de definir el videojuego a realizar con

una sola frase. La idea se puede refinar y concretar, pero sin profundizar demasiado.
Es el momento para explorar alternativas buscando ante todo la esencia de lo que
merecería la pena hacer.
3. Preproducción. Se diseñan todos los aspectos que configuran el videojuego y que

dirigen su posterior implementación.
4. Diseño preliminar.
a. Argumento y personajes. Desarrollo de la temática e historia principal del

videojuego (guión). Definición de los personajes principales y secundarios
determinando aspectos tales de los personajes como apariencia física,
biografía, etc.
b. Escenarios. Descripción de los escenarios en los que se desarrollará el

videojuego.
c. Jugabilidad. Las reglas de juego. Definición inicial de lo que podrán hacer los
usuarios mientras juegan y lo que no podrán hacer.
d. Investigación tecnológica. Qué tipo de tecnologías hacen falta, evaluar

software existente para realizarlas y efectuar las primeras pruebas.
6
5. Diseño detallado. Diseño de los módulos necesarios para desarrollar el videojuego

(diagrama de clases, diagrama de estados, grafo de escena…).
6. Producción. Se pasa a construir la funcionalidad y contenidos específicos del juego

utilizando los diseños obtenidos en el paso anterior.
7. Desarrollo de los módulos fundamentales.
a. Motor gráfico. Utilización del motor gráfico escogido para crear los diferentes
módulos que facilitarán el trabajo con el entorno gráfico (sistema de cámaras,
generación de terrenos…).
b. Tecnologías de Inteligencias Artificial. Desarrollo de los módulos

encargados de gestionar la Inteligencia Artificial de los personajes del juego.
c. Interfaz de juego. Implementación de la interfaz de juego en forma de menús

y de los controles puestos a disposición del usuario.
d. Soporte de red. Configuración de los elementos necesarios para permitir la

interconexión en tiempo real de varios usuarios (partida multijugador).
e. Lógica de juego. Implementación de la estructura y del comportamiento del

mundo del juego a partir de los módulos generados.
8. Programación del contenido. Adición de contenido a la lógica para generar los

diferentes niveles de juego.
a. Diseño de gráficos.
i. Modelado de personajes. Modelado 3D de los personajes que

intervienen en el desarrollo del videojuego.
ii. Modelado de escenarios. Modelado 3D de los escenarios del juego

en los que se llevará a cabo la acción.
b. Desarrollo de sonido.
i. Efectos sonoros. Búsqueda, selección y desarrollo (en última

instancia) de los múltiples efectos y sonidos que ayudarán a dar más
realismo al juego.
ii. Doblaje. Grabación de las diferentes piezas de sonido habladas que

puedan ser utilizadas por los personajes del juego o en forma de voz
en off.
iii. Música. Búsqueda y selección de las melodías que sonarán en

diferentes instantes del juego.
7
c. Integración. Adición de los contenidos creados a la lógica del juego.
9. Depuración de errores.
a. Pruebas. Tarea con las que se trata detectar los errores que se puedan
encontrar en la versión beta del juego, tales como fallos de jugabilidad, sonido,
gráficos, etc.
b. Corrección. Supone la eliminación de todos aquellos errores detectados

durante las pruebas
2.5 ORGANIZACIÓN
En este punto se debe precisar que aunque se hable en términos de departamentos y
diferentes perfiles, esto se hace exclusivamente para dotar al proyecto de una organización
teórica. En la práctica, las diferentes tareas y roles descritos se reparten entre los dos
miembros de equipo (autores de la presente memoria), por lo que se trata en todo caso de una
organización lógica.
2.5.1 Esquema organizativo
La organización del proyecto viene dada por la siguiente figura.
DIRECCIÓN
DISEÑO PROGRAMACIÓN GRÁFICOS SONIDO PRUEBAS
Figura 2.1. Organigrama para el desarrollo de un videojuego.
• Dirección. Mantiene la visión del concepto, y dirige el equipo y el desarrollo. Se apoya

en jefes de departamento (diseño, programación…).
• Diseño. Crean y definen los elementos interactivos y narrativos del videojuego.
• Programación. Escriben el software que implementa la funcionalidad pedida por

diseño, la tecnología necesaria para mostrar los contenidos, y las herramientas para
construirlos.
• Gráficos. Construyen los elementos visuales, escenarios y personajes.
8
• Sonido. Diseñan el estilo y ambiente sonoro. Se encargan de la composición musical y

de los efectos sonoros.
• Pruebas. Verifican que el contenido y funcionalidad del juego son correctos y están
completos.
El avance y seguimiento del proyecto se basa en los siguientes elementos:
• Reuniones de seguimiento. Se llevarán a cabo dos veces al mes para analizar la

marcha del proyecto y detectar cualquier posible problema que pueda surgir,
planteando alternativas y soluciones. Para ello el director de proyecto se reunirá con
los diferentes jefes de departamento.
• Hitos de validación. El proyecto progresará en base a una serie de hitos situados en

distintos puntos de su recorrido. El equipo deberá esforzarse para cumplir los plazos
establecidos y proporcionar la funcionalidad solicitada llegados dichos hitos. La
dirección se encargará de su validación junto con los jefes de departamento y ajustará
la planificación en base al estado del proyecto.
• Recepción. Coincide con el último hito de validación y supone que el sistema

desarrollado funciona correctamente y se ajusta al informe de requisitos establecido.
2.5.2 Equipo de trabajo
El equipo de trabajo constará de los siguientes perfiles relacionados con las diferentes áreas de
competencias que se abordan:
• Director de proyecto. Cuya función es la de realizar las actividades de organización,

coordinación y seguimiento del proyecto.
• Diseñador. Crea el diseño conceptual del videojuego (“¿a qué se juega?”) y establece
las diferentes reglas y mecánicas por las que se rige el juego.
• Programador. Encargado del desarrollo y puesta a punto del aspecto software de la

aplicación (lógica de juego, sistema, tecnologías y herramientas), así como de la
integración de los diferentes recursos proporcionados por los departamentos de
gráficos y sonido.
• Diseñador gráfico. Responsable del diseño artístico, modelado, texturizado,

animación…
• Técnico de sonido. Especializado en la composición de temas musicales, y en la

grabación y edición de sonido.
• Tester. Comprueba que el videojuego hace lo que debe y que lo que hace es divertido.
9
2.6 CONDICIONES DE EJECUCIÓN
2.6.1 Entorno de trabajo
El calendario seguido por el equipo comienza el 1 de Junio y finaliza el 6 de Septiembre. Se

dedicarán dos horas diarias de lunes a sábado trabajando preferentemente entre las 18:00 y
las 20:00, aunque en función del progreso del proyecto no se descarta que sea necesario
dedicar horas extra.
Los medios que se dispondrán para el desarrollo del videojuego serán los siguientes:
• Hardware.
o Dos equipos informáticos con las prestaciones suficientes para soportar

labores de programación, modelado 3D, edición de sonido, etc.
o Conexión a Internet de banda ancha de alta velocidad para facilitar tanto la

comunicación entre los trabajadores como la búsqueda de información en
cuanto a las herramientas a utilizar por parte de los diferentes departamentos.
o Al menos dos videoconsolas PSP con todos los accesorios precisos para
probar el videojuego durante su desarrollo, así como el apartado multijugador.
• Software.
o Sistema operativo Windows XP Service Pack 2.
o Microsoft Visual C++ 2005 Express Edition.
o Librerías para el manejo de gráficos 3D, WI-FI y demás requisitos del juego en
la PSP (PSPSDK y LTE GE).
o Aplicaciones para el modelado de objetos 3D (MilkShape 3D y 3D Studio Max

6).
o Aplicaciones para la grabación, composición y edición de sonido (Sound Forge

9.0).
o Procesador de textos (Microsoft Office Word 2003).
2.6.2 Interlocución durante el proyecto
Existirá un director de proyecto que se encargará de tomar las decisiones que puedan afectar
al plazo de entrega de los productos o al coste del proyecto. También será el responsable de la
designación de los jefes de cada departamento, si bien se intentará que este proceso de
selección sea lo más natural posible. El director de proyecto supervisará semanalmente el
10
trabajo de cada departamento y actuará de intermediario ante cualquier situación conflictiva

que pueda darse entre ellos.
2.6.3 Recepción de los productos
Los jefes de departamento deberán elaborar informes semanales para poner en conocimiento
del director de proyecto cualquier incidencia ocurrida en su departamento, indicando además el
trabajo realizado. Igualmente, cualquier decisión tomada por algún jefe de departamento que
pueda modificar el plan de trabajo no podrá ser ejecutada sin la previa aprobación del director
de proyecto.
La recepción y aceptación final del videojuego dependerá tanto del resultado de las pruebas
realizadas por el equipo de pruebas, como de la correspondiente comprobación final realizada
por el director de proyecto junto al resto de los jefes de departamento sobre el documento de
requisitos inicial. Sólo cuando el director de proyecto considere que el sistema presenta la
funcionalidad acordada, será declarado terminado. Para ello dispondrá de un plazo de 3 días,
pasado el cual el producto será rechazado automáticamente, requiriendo la correspondiente
entrega a los jefes de departamento de un informe con las funciones pendientes de finalización.
2.6.4 Gestión de cambios, modificaciones e incidencias
Todas las peticiones tomadas por alguno de los departamentos durante la ejecución del
proyecto, que impliquen cambios en las especificaciones, diseños o desarrollos ya realizados,
serán objeto del siguiente procedimiento: [1]
1. Comunicación formal del jefe de departamento al director de proyecto.
2. Valoración, por el jefe de departamento y el director de proyecto, de la repercusión

técnica, económica y de plazo de ejecución.
3. Notificación, por parte del director de proyecto al jefe de departamento, de la

aprobación o no de la propuesta.
4. En caso afirmativo, modificación del plan de trabajo y del presupuesto.
2.7 PLANIFICACIÓN
2.7.1 Estimación de cargas de trabajo
La estimación de cargas previstas para las diferentes actividades está representada en la tabla
2.1. Cada carga corresponde a un día de 2 horas de trabajo.
Actividad Carga
A1 Organización y control 68
11
A2 Concepto 1
A3 Preproducción 14
A4 Producción 75
A5 Depuración de errores 8
TOTAL 166
Tabla 2.1. Estimación global de cargas.
A1 Organización y control 68
A1.1 Organización 3
A1.2 Control 65
A2 Concepto 1
A3 Preproducción 14
A3.1 Diseño preliminar 3
A3.1.1 Argumento y personajes 1
A3.1.2 Escenarios 1
A3.1.3 Jugabilidad 1
A3.2 Investigación tecnológica 5
A3.3 Diseño detallado 6
A4 Producción 75
A4.1 Desarrollo de los módulos fundamentales 34
A4.1.1 Motor gráfico 12
A4.1.2 Tecnologías de Inteligencia Artificial 5
12
A4.1.3 Interfaz de juego 5
A4.1.4 Soporte de red 12
A4.2 Implementación de la lógica de juego 19
A4.3 Programación del contenido 5
A4.4 Diseño de gráficos 11
A4.4.1 Modelado de personajes 6
A4.4.2 Modelado de escenarios 5
A4.5 Desarrollo de sonido 3
A4.5.1 Efectos sonoros 1
A4.5.2 Doblaje 1
A4.5.3 Música 1
A4.6 Integración 3
A5 Depuración de errores 8
A5.1 Pruebas 3
A5.2 Corrección 5
Tabla 2.2. Estimación detallada de cargas
2.7.2 Reparto de cargas por perfiles
La asignación de cargas correspondiente a los diferentes perfiles que componen el equipo es la

indicada en la tabla 2.3.
Perfil Carga
Director de proyecto 68
Diseñador 4
13
Programador 77
Diseñador gráfico 11
Técnico de sonido 3
Tester 3
TOTAL 166
Tabla 2.3. Reparto de cargas por perfil.
2.7.3 Plan de trabajo
A continuación se detalla el plan de trabajo estimado para la correcta realización del proyecto.
La figura 2.2 representa de manera aproximada el tiempo dedicado a las fases generales.
Cada una de estas (excepto la etapa de “Concepto”) se descompone en una serie de
subtareas. La tabla 2.4 recoge esta información de manera ordenada en lo que es el plan de
trabajo propiamente dicho.
Organización y control
Concepto
Preproducción
Producción
Depuración de errores
Figura 2.2. Diagrama Gantt de las fases generales del proyecto.
PLAN DE TRABAJO
Id. Persona Días H/P Fecha Fecha

Descripción Prerrequ.
Tarea asignada Estim. Estim. inicio fin
A1.1 Organización Comienzo Jon 3 6 01/06/07 03/06/07
A1.2 Control A1.1 Jon 65 6 05/06/07 17/08/07
A2 Concepto A1.1 Jon, Carlos 1 2 05/06/07 05/06/07
A3.1.1 Argumento y A2 Jon, Carlos 1 2 06/06/07 06/06/07
14
personajes
A3.1.2 Escenarios A3.1.1 Jon, Carlos 1 2 07/06/07 07/06/07
A3.1.3 Jugabilidad A3.1.2 Jon, Carlos 1 2 08/06/07 08/06/07
A3.2 Inv.Tecnológica A3.1.3 Jon, Carlos 5 10 09/06/07 14/06/07
A3.3 D.Detallado A3.2 Jon, Carlos 6 12 15/06/07 21/06/07
A4.1.1 Motor gráfico A3.3 Carlos 12 24 22/06/07 05/07/07
Tecnologías de
A4.1.2 A4.1.1 Carlos 5 10 06/07/07 11/07/07
IA
Interfaz de
A4.1.3 A3.3 Jon 5 10 22/06/07 27/06/07
juego
A4.1.4 Soporte de red A4.1.3 Jon 12 24 28/06/07 11/07/07
Implementación
A4.1.2
A4.2 de la lógica de Jon, Carlos 19 38 12/07/07 02/08/07
A4.1.4
juego
Programación
A4.3 A4.5.3 Jon 5 10 07/08/07 11/08/07
del contenido
Modelado de
A4.4.1 A4.2 Carlos 6 12 03/08/07 09/08/07
personajes
Modelado de
A4.4.2 A4.4.1 Carlos 5 10 10/08/07 15/08/07
escenarios
A4.5.1 Efectos sonoros A4.2 Jon 1 2 03/08/07 03/08/07
A4.5.2 Doblaje A4.5.1 Jon 1 2 04/08/07 04/08/07
A4.5.3 Música A4.5.2 Jon 1 2 06/08/07 06/08/07
Integración de A4.3
A4.6 Jon, Carlos 3 6 15/08/07 17/08/07
contenidos A4.4.2
A1.2
A5.1 Pruebas Jon, Carlos 3 6 18/08/07 21/08/07
A4.6
Corrección del
A5.2 A5.1 Jon, Carlos 5 10 21/08/07 25/08/07
código
Tabla 2.4. Plan de trabajo.
15
INVESTIGACIÓN TECNOLÓGICA
3. INVESTIGACIÓN TECNOLÓGICA
3.1 INTRODUCCIÓN
En el presente capítulo, se realizará una presentación de una serie de tecnologías y
herramientas que han sido investigadas para la realización del proyecto. Únicamente se
destacan aquellas que se han considerado fundamentales para el desarrollo de un videojuego
sobre la PSP. Además, se incluye una descripción de la videoconsola y de sus características
técnicas. También se analizan las aplicaciones y librerías que pueden ser de ayuda para el
programador en forma de tutoriales.
3.2 PSP
La PSP es una videoconsola portátil desarrollada y distribuida por Sony Computer
Entertainment. Su lanzamiento fue anunciado por primera vez en la feria del E3 en el 2003,
siendo presentada oficialmente el 11 del Mayo del 2004 en una conferencia para la prensa. El
sistema comenzó a comercializarse en Japón el 12 de Diciembre del 2004. El 24 de Marzo del
siguiente año lo haría en Estados Unidos y Canadá. A Europa y Australia no llegaría hasta el 1
de Septiembre del 2005.
Figura 3.1. Vista frontal y posterior de la videoconsola portátil PSP.
17
La principal ventaja de la PSP frente a otras videoconsolas portátiles es su elevada capacidad

de procesamiento, mostrando gráficos tridimensionales de gran calidad que la sitúan
tecnológicamente a medio camino entre la generación de videoconsolas de 32 y 128 bits. A
esto hay que añadir las nuevas posibilidades que ofrece la conexión WI-FI en cuanto a
jugabilidad se refiere. En conjunto se dispone de una plataforma de ocio electrónico que ofrece
variadas e innovadoras posibilidades para los diseñadores de videojuegos que sepan
aprovecharlas.
3.2.1 Características técnicas
Para programar un dispositivo hardware como la PSP y depurar el código en tiempo de

ejecución, es recomendable tener unos conocimientos técnicos básicos sobre la videoconsola.
Esta contiene una serie de componentes construidos en exclusiva por Sony dando lugar a un
sistema considerablemente sofisticado: [3]
• Controlador del sistema MIPS (ALLEGREX).
• Motor Multimedia (MIPS + VME + decodificador AVC).
• 32 MB de RAM para la memoria principal. Esta se encuentra dividida en 4 MB para el

núcleo, 4 MB de memoria volátil y 24 MB de espacio de usuario.
• 2 MB de DRAM embebida para ME.
• 2 MB de VRAM.
• Sistema de sonido de propósito general.
• Pantalla LCD ancha a color de 480 x 272 pixels (aproximadamente 1.8 : 1).
• 13 botones, control digital de 4 direcciones y mando analógico.
• Puerto para tarjetas de memoria Sony Memory Stick Duo.
Además cuenta con los siguientes elementos hardware adicionales, que si bien no son
imprescindibles para el desarrollo de un videojuego, pueden ser igualmente aprovechados:
• Dispositivo óptico propietario de Sony de 1.7 GB (UMD).
• Soporte USB 2.0.
• 802.11b Wireless Ethernet.
• Controlador DMA para la comunicación con periféricos (incluye un canal DMA de

propósito general para las aplicaciones de usuario).
18
ALLEGREX es el nombre de la CPU principal de la PSP. Entre sus características más

interesantes se encuentran:
• Núcleo MIPS32 personalizado.
• Unidad de gestión de memoria limitada (MMU).
• Frecuencia de reloj variable (entre 33 MHz y 333 MHz).
• FPU de precisión simple (32 bits) integrada.
• Coprocesador vectorial/matricial (VFPU) integrado. Potencia la capacidad de cálculo

tridimensional de la CPU principal. Dispone de 128 registros de 32 bits, con lo que se
pueden multiplicar matrices completas con una sola operación. Además, los registros
son configurables, permitiendo procesar valores individuales, filas, columnas, matrices
o sus transpuestas.
El motor gráfico (GE) es el elemento clave en le procesamiento gráfico de la PSP:
• Diseñado para ser manejado con un API sencillo, similar al de las librerías gráficas más
conocidas.
• Dibujado realizado mediante listas de visualización.
• 2 MB de VRAM para texturas, frame buffer y listas de visualización.
• Puede funcionar en un modo de bus maestro para recuperar texturas y listas de la

RAM principal. Los únicos datos que necesitan entonces estar almacenados en la
VRAM son los del frame buffer.
• Puede trabajar en modo 2D o 3D.
• Soporta múltiples formatos de texturas, compresión DXT, modo CLUT…
• Clipping 3D integrado y limitado.
• Spilines y superficies de Bézier.
• Morphing y skinning.
• Alpha blending y operadores lógicos.
• Buffers de iluminación y estarcido (stencil).
El núcleo de la PSP no sigue una arquitectura estrictamente monolítica, sino que está formado
por un conjunto de módulos separados. Las aplicaciones de usuario se consideran igualmente
módulos. Estos pueden cargarse en memoria (en posiciones fijas o variables) y ejecutarse sin
restricciones. Además pueden exportar e importar funciones de otros módulos. El núcleo de la
19
PSP no reconoce el concepto tradicional de proceso tal y como se entiende en otros sistemas
operativos.
La PSP utiliza el formato de los archivos ELF como base para sus módulos. El núcleo puede
cargar 3 tipos de ficheros de manera nativa:
• ELF. Formato ELF básico enlazado a una dirección de memoria concreta

(normalmente 0x8900000).
• PRX. Formato ELF modificado. Puede ser ubicado en cualquier dirección de memoria.
• ˜PSP. Formato envoltorio cifrado tanto para archivos ELF como PRX.
3.2.2 Escena
Se entiende por escena a todo aquello que está relacionado con la personalización de un
producto. En este caso, la escena de la PSP engloba tanto software desarrollado por usuarios,
como modificaciones realizadas sobre el hardware. En Mayo del 2005 se descubrió que una
PSP con la versión firmware 1.00 podía ejecutar código que no había sido digitalmente firmado
por Sony. Esto suponía que cualquiera podía crear sus propias aplicaciones “caseras” (el
término utilizado en inglés es homebrew) y ejecutarlas sobre la PSP.
Para conseguirlo se utiliza una modificación de GNU GCC y GNU Binutils que permite compilar
código adaptado a la PSP (basada en un procesador MIPS). El compilador fue desarrollado a
partir de experiencia obtenida en un proyecto similar realizado sobre la PS2 y admite código
escrito en los lenguajes de programación C y C++. Está pensado para funcionar sobre
sistemas *nix, por lo que su uso en Windows requiere de Cygwin o MingW (DevkitPRO).
Como resultado de posteriores trabajos de ingeniería inversa, se creó el PSPSDK. Se trata de

un kit de desarrollo de software libre que permite acceder a las librerías utilizadas en la PSP.
Incluye gran cantidad de librerías y herramientas para facilitar la labor del programador. Entre
estas cabe destacar una versión de libGU y libGUM (librerías gráficas), librerías empleadas
tanto por el usuario como por el núcleo con sus correspondientes archivos de cabecera,
herramientas para construir archivos ELF y convertir ejecutables en PRX, más de 60 ejemplos
sobre el uso del SDK en la PSP…
LibGU es fundamental para el desarrollo de gráficos acelerados por hardware para la PSP.
Permite controlar tanto el GE como el hardware de visualización. Además gestiona las listas de
visualización y el frame buffer. Por su parte, libGUM es una librería que permite la manipulación
de matrices y es utilizada directamente por libGU. Mantiene una pila de matrices similar a la de
otras librerías gráficas y proporciona la funcionalidad necesaria para calcular matrices de
proyección, rotar vectores, etc. LibGU y libGUM no son las únicas librerías creadas para la
visualización de gráficos en la PSP. Existen otros desarrollos importantes como:
• PSPGL. Una librería para el manejo de gráficos 3D acelerados por hardware que
mantiene una API con un estilo similar al de OpenGL.
20
• SDL. Diseñada para el manejo de gráficos 2D.
Aunque los principales lenguajes para el desarrollo de software en la PSP son C y C++, existen
otras alternativas como Python, Lua o Macromedia Flash. No obstante, mientras que C y C++
permiten trabajar con entornos 2D y 3D, la programación con Lua y Macromedia Flash se limita
al manejo de gráficos 2D.
La política de Sony no acepta en ningún momento la posibilidad de que los usuarios puedan
desarrollar sus propias aplicaciones, de manera que la empresa japonesa ha ido presentando
diferentes actualizaciones para el firmware de la PSP. Cada nueva versión mejora el
funcionamiento de la videoconsola portátil, añade diferentes capacidades y condiciona el
software oficial que puede ser ejecutado. Pero al mismo tiempo, también corrige los exploits
utilizados por los seguidores de la escena para poder ejecutar sus aplicaciones. Esto ha
llevado a una pequeña batalla entre los usuarios más avanzados y Sony, en la que cada nuevo
firmware va acompañado al poco tiempo de un nuevo exploit.
3.3 LTE GE
A primera vista, desarrollar un juego para la PSP puede parecer una tarea sencilla,
especialmente si se limita a mostrar gráficos 2D. Para ello no sólo existen lenguajes de
scripting intuitivos como Lua, sino también librerías de alto nivel como SDL que ya han
demostrado su potencial sobre el PC. En el momento en el que se introducen gráficos 3D el
trabajo de programador parece complicarse considerablemente. Las alternativas vistas hasta
ahora pasan por utilizar directamente las librerías libGU y libGUM, pero dado el bajo nivel de
implementación de las mismas, su manejo es extremadamente complejo a medida que el
proyecto crece. Algo parecido ocurre con PSPGL, si bien el hecho de usar una API similar a
OpenGL facilita el desarrollo del videojuego, todavía deja en manos del programador un gran
número de tareas básicas que exigen ingentes cantidades de código. Además estás librerías
sólo contemplan el apartado gráfico del juego, por lo que aspectos como el sonido o la
conexión WI-FI deben ser tratado mediante otras librerías especializadas.
LTE GE[2] soluciona la mayoría de los problemas comentados hasta ahora. Se trata de un
motor para la creación de juegos, de manera que no se centra exclusivamente en los gráficos,
sino que también añade funciones para reproducir sonido, leer y escribir en ficheros, crear
interfaces de usuario o gestionar conexiones WI-FI. Si bien toma como base la librería PSPGL,
construye sobre esta una API similar a la utilizada por Irrlicht, un popular motor gráfico para PC.
En realidad, LTE GE aprovecha que Irrlicht es una distribución de software libre para adaptarlo
a los requisitos de la PSP, y al mismo tiempo añade toda una serie de características
adicionales para convertirlo en un completo motor de desarrollo de videojuegos.
Sus principales características son:
• Combinación de gráficos 2D y 3D.
• Soporte nativo de sonido (WAV, MP3 y AT3).
21
• Soporte nativo de red (WI-FI).
• Sistema de animación de modelos.
• Efecto cel-shading.
• Sombras planares y volumétricas.
• Multi-texturizado.
• Environmental Mapping.
• Renderizado sobre texturas.
• Sistema de animación.
• Efectos de partículas.
• Billboards.
• Luces dinámicas.
• Soporte de 6 formatos de imágenes (.bmp, .png, .jpg, .pcx, .tga, .psd).
• Soporte de 9 formatos de mallas (.md2, .bsp, .x, .3ds, .obj, .dmf, .dae, .ms3d, .b3d).
• Soporte de fuentes.
• Detección de colisiones.
• Generación de terrenos.
3.3.1 Sistema de coordenadas
Un aspecto a tener en cuenta al trabajar con un entorno tridimensional es cuál es el sistema de

coordenadas empleado. Aunque el programador siempre puede interpretar los ejes como
desee estableciendo su propio sistema de coordenadas, normalmente resulta más cómodo
adaptarse al definido por el motor. En el caso de LTE GE se emplea un sistema de
coordenadas de mano izquierda, tal y como se aprecia en la figura 3.2.
22
Figura 3.2. Sistema de coordenadas de LTE GE (mano izquierda).
3.3.2 Estructura del motor
Está escrito en el lenguaje de programación C++ y se basa en el concepto de grafo de escena,

utilizado por muchas de las librerías gráficas que existen en la actualidad. Se estructura en una
serie de espacios de nombres que agrupan diferentes clases a disposición del programador. La
mayoría de estas están construidas como si fueran interfaces (clases con todos sus métodos
virtuales), intentando centralizar en la medida de lo posible la creación de los diferentes
objetos. El espacio de nombres principal se denomina engine y representa al motor completo,
de manera que los restantes espacios de nombres se encuentran dentro de él:
• Audio. Contiene clases para el manejo del controlador de sonido.
• Core. Clases básicas como vectores, matrices, planos, listas… También algunas
funciones y constantes de uso general.
• GUI. Presenta clases que permiten crear una interfaz gráfica de usuario de manera
sencilla. Se pueden añadir elementos como etiquetas de texto, cajas de selección
desplegables (combo box), botones de selección (check box)…
• IO. Proporciona interfaces para la entrada y salida de datos. Incluye clases para
escribir y leer archivos, así como documentos XML.
• Net. Contiene clases para acceder al controlador de red. La comunicación entre nodos
a través de la conexión WI-FI se realiza mediante unas clases diseñadas como
sockets.
23
• Scene. La gestión del grafo de escena se realiza dentro de este espacio de nombres.
Existen diferentes tipos de nodos (terrenos, mallas animadas, sistemas de partículas,
animadores…).
• Video. Presenta clases para manejar el controlador de vídeo, pudiendo configurar

aspectos propios del renderizado 2D y 3D.
El acceso a todos los objetos del motor parte de un único objeto representado por la clase
engineDevice. Por lo tanto, tras el código necesario para la puesta a punto de la PSP, lo normal
será que se disponga de una llamada a la función createDevice(). El primero de los parámetros
se utiliza para pasar al motor un gestor de eventos personalizado. Este será una clase que
herede de IEventReceiver. El segundo es de suma utilidad durante el desarrollo del videojuego
e indica si se va a visualizar (true) o no (false) el logo de Sony y de LTE GE. Si se utiliza el
valor false al cabo de 10 minutos la aplicación se cerrará, pero dado que los primeros pasos
irán encaminados a realizar un gran número de pruebas rápidas sobre el código, suele ser
tiempo suficiente.
Una vez se dispone del engineDevice, se pueden recuperar punteros a los diferentes
controladores del motor (audio, vídeo, red, GUI y escena), al sistema de ficheros, al cursor o al
temporizador, entre otros.
3.3.3 Clase IUnknown
Se trata de la clase base para la mayor parte de los objetos del motor. Proporciona un
mecanismo básico de contabilización de referencias mediante dos métodos: drop() y grab().
Cuando se crea un objeto invocando un método del motor que comienza por create se
devuelve un puntero al objeto creado. Es responsabilidad del programador eliminarlo cuando
ya no lo necesite más utilizando el método drop(). Esto destruirá el objeto siempre que en otra
parte del código no se haya invocado el método grab(). En caso contrario, sólo reducirá en uno
el contador de referencias de dicho objeto.
Suele ser habitual encontrarse con trozos de código en los que el método drop() se llama
inmediatamente después de asignar el objeto creado a un nodo.
scene::ISceneNode* node = smgr->addTestSceneNode();
scene::ISceneNodeAnimator* anim = smgr->createFlyCircleAnimator(

core::vector3df(0,0,30), 20.0f);
node->addAnimator(anim);
anim->drop();
Código 3.1. Extracto de código del ejemplo 04.Movement. Invocación del método drop()
después de asignar el objeto eliminado a un nodo de escena.
24
Esto es posible porque el controlador de la escena pasa a hacerse cargo del objeto. La
sentencia node->addAnimator(anim) internamente realiza una llamada a grab(), por lo que el
correspondiente drop() puede realizarse después o dejarlo para el final del programa.
3.3.4 Grafo de escena
Es una representación esquemática de la escena que contiene todos y cada uno de los
elementos que forman parte del mundo 3D que posteriormente se dibuja en la pantalla. Se
gestiona mediante un objeto de tipo ISceneManager. A través de este se pueden añadir todo
tipo de nodos a la escena. Son objetos que derivan de la clase ISceneNode y que van desde
los nodos que representan las cámaras hasta otros que contienen las mallas animadas.
El grafo de escena es un grafo jerárquico, de manera que se establecen relaciones padre-hijo

entre los diferentes nodos. Cada nodo tiene asociado una matriz de transformación, por lo que
las transformaciones realizadas sobre un nodo padre afectan a todos sus nodos hijos. Así
pues, si se utiliza un nodo para representar la carrocería de un coche y otro para cada rueda,
estos últimos se añadirán al grafo de escena como hijos del primero. Cuando la carrocería se
traslade, rote o escale, también lo harán las ruedas. La jerarquía se construye mediante el
método addChild(). De todas formas, es habitual que alguno de los parámetros de los métodos
del ISceneManager empleados para añadir nodos al grafo sea un puntero al padre.
3.3.5 Temporizador
Otro elemento fundamental en cualquier videojuego es el temporizador. Se usa para gestionar

el tiempo que transcurre en el juego en relación con el tiempo real. Así el comportamiento del
juego es el mismo independientemente de la frecuencia de reloj del procesador.
La clase ITimer permite recuperar tanto el tiempo real del sistema (getRealTime()) como el
tiempo virtual (getTime()) obtenido a partir de un contador software controlado por el propio
motor. El temporizador virtual puede ser manipulado por el programador pudiendo asignarle un
valor determinado, detenerlo, volver a ponerlo en marcha…
Al igual que el resto de gestores del motor, el temporizador se recupera a través de la

referencia al objeto engineDevice. Basta con invocar el método getTimer().
3.3.6 Animadores
Representan comportamientos predefinidos que pueden asignarse a los nodos de la escena

(addAnimator()).
• CollisionResponseAnimator. Detecta automáticamente colisiones a partir del objeto

ITriangeSelector pasado como parámetro en su creación. Al asignarse a un nodo hace
que este no pueda atravesar las superficies que conforman el modelo a partir del cual
se generó el ITriangleSelector. También permite aplicar un vector de gravedad sobre el
nodo. Resulta especialmente útil al ser añadido al nodo cameraSceneNodeFPS,
25
consiguiéndose entonces una gestión de colisiones del jugador con el escenario del
juego similar a la de los juegos de acción en primera persona.
• DeleteAnimator. Al cabo de cierto tiempo elimina el nodo al que ha sido asignado.
• FlyCircleAnimator. Hace que un nodo se desplace en círculos alrededor de un

determinado punto.
• FlyStraightAnimator. Mueve un nodo a lo largo de la línea definida por dos puntos.
• FollowSplineAnimator. Mueve un nodo a lo largo de la spline definida.
• RotationAnimator. Rota un nodo sobre sí mismo.
• TextureAnimator. Cambia periódicamente la textura del nodo objetivo a partir de una

lista de texturas.
3.3.7 Cámaras
Existen diferentes tipos de cámaras a disposición del programador, siendo además posible
crear varias, aunque en cada instante sólo puede haber una activa. Las cámaras son tratadas
como nodos y al igual que estos forman parte del grafo de escena. Pueden ser hijos de otros
nodos, en cuyo caso se verán afectados por las transformaciones realizadas sobre su padre.
Las cámaras que pueden añadirse mediante el ISceneManager son:
• CameraSceneNode. Cámara convencional definida por una posición en el espacio y el

punto al que mira.
• CameraSceneNodeFPS. Cámara especial que pueden controlarse como en la

mayoría de los juegos de acción en primera persona. A su vez se divide en 3 tipos de
cámaras en función de cómo se lleva a cabo el movimiento:
o moveStyle = 0. El mando analógico se usa para rotar la cámara, mientras que

el movimiento se lleva a cabo con los botones de dirección.
o moveStyle = 1. El mando analógico mueve la cámara. Se rota con los botones

de dirección.
o moveStyle = 2. Sólo utiliza el mando analógico. Moviéndolo a la derecha o

izquierda la cámara rota en la dirección indicada. Si se mueve hacia arriba o
hacia abajo, se traslada hacia delante o hacia atrás respectivamente.
• CameraSceneNodeMaya. Cámara que se controla de manera análoga a como se

hace con el ratón en la aplicación Alias Maya.
26
3.3.8 Octree
Es un tipo especial de nodo empleado para trabajar con mallas formadas por grandes
cantidades de geometría estática. Un octree permite dibujar aproximadamente sólo la parte de
la geometría que es visible en cada momento. Esto supone en la mayoría de las ocasiones una
mejora en el rendimiento del motor gráfico, aunque depende totalmente de la complejidad y el
tamaño de la geometría. Puede resultar especialmente útil para generar los escenarios o
mapas en los que tiene lugar la acción del juego.
3.3.9 Eventos
La gestión de eventos se realiza creando una clase que herede de IEvenReceiver. Esta interfaz
dispone de un método abstracto (OnEvent()) que hay que implementar en el nuevo gestor de
eventos. El motor del juego se encargará de invocarlo cada vez que tenga lugar algún evento y
sea necesario tratarlo (mecanismo de callback). Estos pueden ser de 4 tipos:
• GUIEvent. Eventos de la interfaz gráfica del usuario. Se activa al cambiar un elemento

de una lista de selección, marcar una caja de selección, seleccionar un archivo en un
cuadro de diálogo…
• MouseInput. Eventos del ratón (representado en la PSP por un cursor que se controla
con el mando analógico).
• KeyInput. Eventos de botón. Originados por la pulsación de alguno de los botones de

la PSP.
• LogEvent. Eventos del archivo de log.
• UserEvent. Eventos de usuario. Definidos por el usuario y lanzados explícitamente.
El gestor de eventos se asigna en el momento en el que se crea el objeto engineDevice, como

parámetro de la función createDevice().
El manejo de sockets con la conexión WI-FI supone otra serie de eventos que son controlados
mediante un gestor diferente. En este caso, la clase que se encarga de atender dichos eventos
debe heredar de la interfaz INetworkCallback, y se asigna al inicializar el controlador de red con
el método initialize().
3.3.10 Efectos especiales
LTE GE proporciona algunos efectos especiales que pueden ser añadidos en un videojuego.
Su número es bastante reducido, por lo que un uso extensivo de los mismos requiere que el
programador los elabore por cuenta propia.
• Efecto de agua. Mediante el método addWaterSurfaceSceneNode() del

ISceneManager se pueden añadir nodos a la escena que animan una determinada
27
malla como si se tratara de agua. Combinándolo con un material como

EMT_REFLECTION_2_LAYER se consigue un efecto muy realista. El siguiente
extracto de código describe el procedimiento a seguir. Aunque la superficie de partida
es un plano para generar colinas, se ha creado como una superficie completamente
plana. Igualmente podría haberse utilizado otro tipo de malla.
mesh = smgr->addHillPlaneMesh(“myHill”,
core::dimension2d<f32>(20,20),
core::dimension2d<s32>(40,40), 0, 0,
core::dimension2d<f32>(0,0),
core::dimension2d<f32>(10,10));
node = smgr->addWaterSurfaceSceneNode(mesh->getMesh(0),
3.0f, 300.0f, 30.0f);
node->setPosition(core::vector3df(0,7,0));
node->setMaterialTexture(0,
driver->getTexture(“ms0:/media/stones.jpg”));
node->setMaterialTexture(1,
driver->getTexture(“ms0:/media/water.jpg”));
node->setMaterialType(video::EMT_REFLECTION_2_LAYER);
Código 3.2. Extracto de código del ejemplo 08.SpecialFX. Cómo añadir un efecto
de agua.
• Sistema de partículas. Dada su flexibilidad y extensibilidad ofrece más posibilidades

para generar efectos especiales personalizados como explosiones, fuego o lluvia.
Existe un objeto IParticleSystemSceneNode que puede ser añadido a la escena para
posteriormente asignarle emisores de partículas y modificadores.
Los emisores de partículas disponen de un considerable número de parámetros que

permiten configurar desde el color de las partículas hasta la dirección que siguen. El
motor cuenta con algunos emisores ya preparados, como el PointEmitter y el
BoxEmitter. El primero genera partículas a partir de un punto determinado, mientras
que el segundo lo hace en cualquier punto que pertenezca a un cubo definido en el
espacio. También se pueden añadir nuevos emisores construyendo una clase que
herede de IParticleEmitter.
Los modificadores afectan a la trayectoria que siguen las partículas. Al añadirlos a un

sistema de partículas se pueden simular efectos como el viento o la gravedad. Al igual
que con los emisores, existen una serie de modificadores ya creados: GravityAffector y
FadeOutParticleAffector. Este último cambia el color de las partículas a medida que
28
pasa el tiempo. Si se quiere añadir un nuevo modificador, basta con implementar una
clase que herede de IParticleAffector.
scene::IParticleSystemSceneNode* ps = 0;
ps = smgr->addParticleSystemSceneNode(false);
ps->setPosition(core::vector3df(-70,60,40));
ps->setScale(core::vector3df(2,2,2));
ps->setParticleSize(core::dimension2d<f32>(20.0f, 20.0f));
scene::IParticleEmitter* em = ps->createBoxEmitter(
core::aabbox3d<f32>(-7,0,-7,7,1,7),
core::vector3df(0.0f,0.06f,0.0f),
80,100, video::SColor(0,255,255,255),
video::SColor(0,255,255,255), 800,2000);
ps->setEmitter(em);
em->drop();
scene::IParticleAffector* paf =
ps->createFadeOutParticleAffector();
ps->addAffector(paf);
paf->drop();
ps->setMaterialFlag(video::EMF_LIGHTING, false);
ps->setMaterialTexture(0,
driver->getTexture(“ms0:/media/fire.bmp”));
ps->setMaterialType(video::EMT_TRANSPARENT_VERTEX_ALPHA);
Código 3.3. Extracto de código del ejemplo 08.SpecialFX. Cómo crear un sistema
de partículas que simula el fuego.
• Renderizado sobre texturas. Es posible renderizar la escena contemplada desde una

determinada cámara sobre una textura en lugar de hacerlo en la pantalla. Este
mecanismo puede utilizarse, por ejemplo, para simular la reflexión del escenario sobre
un espejo. Para ello coloca una cámara en la posición del plano que representa al
espejo y se realiza el proceso de renderizado desde dicha cámara sobre una textura
asignada al espejo. Evidentemente la velocidad de procesamiento se ve
29
considerablemente afectada, dado que se pasa de renderizar una vez la escena por
cada ciclo a hacerlo dos veces.
video::ITexture* rt = driver->createRenderTargetTexture(
core::dimension2d<s32>(256,256));
scene::ISceneNode* test = smgr->addTestSceneNode(60);
test->setMaterialTexture(0, rt);
Código 3.4. Extracto de código del ejemplo 10.RenderToTexture. Cómo crear la

textura de renderizado.
driver->setRenderTarget(rt, true, true,

video::SColor(0,0,0,255));
test->setVisible(false);
smgr->setActiveCamera(fixedCam);
smgr->drawAll();
driver->setRenderTarget(0);
test->setVisible(true);
smgr->setActiveCamera(fpsCamera);
Código 3.5. Extracto de código del ejemplo 10.RenderToTexture. Cómo cambiar

el objetivo de renderizado.
3.3.11 Colisiones
La detección de colisiones puede llevarse a cabo con cualquiera de las siguientes técnicas:
• Detección de colisiones automática. Para moverse a través de mundos

tridimensionales. También permite subir o bajar escaleras. Para conseguirlo utiliza un
animador de tipo collisionResponseAnimator.
• Detección de colisiones manual. Se basa en los diferentes métodos disponibles en la

clase ISceneCollisionManager. Algunos de las alternativas más representativas son los
comentados a continuación:
o Sobre triángulos. Consiste en definir una línea y proyectarla sobre uno o

varios nodos. Se consigue el punto y el triángulo de colisión más cercanos al
origen de la recta.
30
o Sobre nodos. Se calcula sobre la bounding-box que todo nodo de escena

posee. Como en el caso anterior puede definirse una línea, pero también
existen métodos para usar el vector de la cámara o unas coordenadas
arbitrarias. Si existe colisión, siempre se obtiene un puntero al nodo.
Los dos primeros métodos emplean un objeto ITriangleSelector para restringir la detección de
colisiones a ciertos nodos. Hay diferentes tipos de ITriangleSelector en función del nodo sobre
el que se crean:
• TriangleSelector. Emplea un objeto de tipo IMesh. Aunque es válido para todo tipo de
malla, no es recomendable utilizarlo ni con grandes geometrías ni con modelos
animados por la carga de procesamiento que supone. Funciona correctamente con
sencillas mallas estáticas.
• TriangleSelectorFromBoundingBox. Toma como referencia una bounding-box

alineada con los ejes que contiene al nodo. Su procesamiento es muy rápido, pero se
pierde la precisión que se logra al tratar directamente los triángulos del nodo. Es
especialmente útil para nodos animados.
• TerrainTriangleSelector. En este caso se utiliza un objeto ITerrainSceneNode.
• OctTreeTriangleSelector. Optimizado para grandes y complejas geometrías.
• MetaTriangleSelector. En realidad se trata de una clase que agrupa a varios

selectores de triángulos, de manera que la detección de colisiones pueda realizarse
contra más de un ITriangleSelector.
Al crear un ITriangleSelector no se asigna directamente al nodo correspondiente, sino que hay

que hacerlo manualmente.
ITriangleSelector* ts = sceneManager->createTriangleSelector(mesh,
node);
node->setTriangleSelector(ts);
ts->drop();
Código 3.6. Asignación de un selector de triángulos a un nodo de escena.
3.3.12 Terreno irregular
Mediante el nodo de escena ITerrainSceneNode se pueden generar terrenos irregulares. Se

suele utilizar para representar escenarios abiertos con una lejana línea de visión. Para indicar
cómo se genera el terreno se utiliza una textura de escala de grises. El color blanco representa
la máxima elevación posible del terreno, mientras que el negro es una superficie
completamente plana. Los colores intermedios generan diferentes desniveles.
31
scene::ITerrainSceneNode* terrain = smgr->addTerrainSceneNode(

“ms0:/media/terrain-heightmap.bmp”);
terrain->setScale(core::vector3df(40, 4.4f, 40));
terrain->setMaterialFlag(video::EMF_LIGHTING, false);
terrain->setMaterialTexture(0,
driver->getTexture(“ms0:/media/terrain-texture.jpg”));
terrain->setMaterialTexture(1,
driver->getTexture(“ms0:/media/detailmap3.jpg”));
terrain->setMaterialType(video::EMT_DETAIL_MAP);
terrain->scaleTexture(1.0f, 20.0f);
Código 3.7. Extracto de código del ejemplo 09.TerrainRendering. Cómo crear un terreno
irregular.
3.3.13 Skybox
Una manera sencilla de recrear en el mundo virtual el cielo es mediante una caja con 6
texturas. La cámara y los demás elementos de la escena se encuentran siempre en su interior.
Cuando la cámara gira, el motor gráfico se encarga de suavizar la transición entre las
diferentes texturas, de forma que a ojos del jugador parece que sólo existe una imagen que lo
envuelve por completo.
driver->setTextureCreationFlag(video::ETCF_CREATE_MIP_MAPS,
false);
ISceneNode* skybox = smgr->addSkyBoxSceneNode(

driver->getTexture(“ms0:/media/skybox_up.jpg”),
driver->getTexture(“ms0:/media/skybox_dn.jpg”),
driver->getTexture(“ms0:/media/skybox_lf.jpg”),
driver->getTexture(“ms0:/media/skybox_rt.jpg”),
driver->getTexture(“ms0:/media/skybox_ft.jpg”),
driver->getTexture(“ms0:/media/skybox_bk.jpg”));
skybox->setMaterialFlag(video::EMF_CLIPPING, true);
Código 3.8. Extracto de código del ejemplo 09.TerrainRendering. Cómo crear una
skybox.
32
3.3.14 Sombras
LTE GE permite crear dos tipos de sombras a partir de los nodos de la escena.
• PlanarShadow. Se proyecta sobre un plano definido por el programador y se ve

afectada dinámicamente por la posición de las luces. Su sencillez hace que su
procesamiento no sea demasiado costoso, aunque también resta realismo cuando la
sombra debería proyectarse sobre más de un plano.
• ShadowVolume. Se proyecta sobre toda la escena y se ve afectada dinámicamente

por la posición de las luces. Requiere una mayor carga de procesamiento, aunque el
resultado conseguido es más realista.
3.4 HERRAMIENTAS Y TUTORIALES
3.4.1 Programación
Se recogen una serie de herramientas y tutoriales relacionados con la programación de

aplicaciones en la PSP.
3.4.1.1 Cómo ejecutar hombrew en la PSP
Para ejecutar las aplicaciones programadas por los usuarios en la PSP, se debe disponer de la
versión 1.5 del firmware, ya que es la única que permite este tipo de manipulaciones por parte
del usuario. Aunque la mayoría de las videoconsolas que se comercializan actualmente
presenta una versión del firmware superior, en muchos casos existe la posibilidad de reducir
dicho firmware a una versión anterior (proceso que se conoce como downgrade).
Para este proyecto se han empleado dos PSP: una con la versión de firmware oficial de Sony
2.01 y la otra directamente con el firmware 1.5. Al no existir un programa o método concreto
para reducir directamente de la versión 2.01 a la 1.5, se ha optado por actualizar la versión a la
2.60 y a partir de ahí, utilizar una herramienta (downgrader 2.50-2.60) que directamente (y de
forma automática) reduce finalmente la versión de firmware a la 1.5.
El firmware 2.60 se puede descargar automáticamente de la página oficial de PSP

(http://es.playstation.com/psp) aunque la mayoría de juegos oficiales suelen ofrecer la
posibilidad de actualizar el firmware antes de empezar a jugar, así que si se dispone de alguno
no es necesario descargarlo.
Los pasos para actualizar en primer lugar a la versión 2.60 son los siguientes:
• Para transferir los archivos necesarios se necesita un cable USB con conector tipo
Mini-B.
33
• Asegurarse de introducir en la PSP una Memory Stick Duo con suficiente memoria
libre.
• Conectar el sistema PSP al ordenador mediante un cable USB con conector tipo Mini-
B.
• Encender la PSP y acceder a la opción Ajustes → Conexión USB del menú principal y
a continuación, pulsar el botón (X) para activar el modo USB. Tras esto, el ordenador
debería reconocer el sistema PSP como una unidad externa.
• Abrir esta unidad en el ordenador y crear una carpeta para los datos de actualización.
A continuación, crear en la Memory Stick Duo una carpeta con el nombre PSP. Dentro
de la carpeta PSP, crear otra llamada GAME y dentro de esta, otra con el nombre
UPDATE.
• Cuando se solicite, guardar el archivo descargado de la página oficial de PSP en la

carpeta UPDATE de la Memory Stick Duo.
• Una vez descargado el archivo, desconectar la PSP del ordenador.
• Asegurarse de que el adaptador AC está enchufado al sistema PSP y pulsar el botón

(O), salir del modo USB, acceder al menú Juego → Memory Stick y seleccionar los
datos de la actualización.
• Seguir las instrucciones que aparecerán en la pantalla para finalizar el proceso de

instalación.
• A continuación, se pueden borrar los datos de la actualización de la Memory Stick Duo.
El siguiente paso es reducir la versión de firmware 2.60 a la 1.50.
• Para empezar, es necesario borrar todo el contenido de la carpeta PSP.
• Se debe descargar el downgrader con instalación automática y ejecutarlo desde un

ordenador con la PSP conectada vía USB. Lo primero que pedirá el programa será
especificar el disco (o unidad) que corresponde a la consola PSP.
Hay que decir que para realizar el downgrade de la versión 2.60 con este instalador es
necesario disponer del juego original GTA: Liberty City Stories de PSP. Esto se debe a
que el downgrader empleado aprovecha un exploit descubierto en el proceso de carga
de este juego para poder acceder al modo kernel.
• Una vez instalado el programa, se debe arrancar el UMD original de GTA: Liberty City
Stories como si se fuera a jugar y mientras se carga la partida el downgrader se
arrancará.
34
• Conectar la PSP a la corriente y elegir la opción downdater test que aparece en el

menú. La pantalla de la PSP permanece estática, pero la luz de la Memory Stick
comienza a parpadear (significa que se está instalando el firmware 1.5). Cuando la luz
deje de parpadear es necesario reiniciar la consola para completar el proceso de
reducción de firmware. Se puede comprobar que la nueva versión del firmware es la
1.5 desde Ajustes → Ajustes del sistema → Información del sistema → Software del
sistema.
A partir de este punto se puede optar por dejar el firmware 1.5 (suficiente para poder programar
y cargar aplicaciones homebrew en la PSP) o actualizarlo con algún Custom Firmware. En el
proyecto se ha optado por la segunda opción, ya que de esta manera se logra una mayor
compatibilidad con ciertas aplicaciones que se utilizan más adelante en el desarrollo del
videojuego. Para ello se ha empleado la versión del Custom Firmware desarrollado por
Dark~AleX (se puede descargar desde http://dark-alex.org). Esta versión en concreto es la 3.40
OE-A. Su instalación se realiza mediante el Firrmware 3.40 OE-A autoinstaller que es un
programa capaz de actualizar a esta versión de Custom Firmware desde la versión 1.5 (oficial
de Sony) o desde cualquier otra versión de Custom Firmware inferior.
Antes de comenzar con la actualización es necesario tener en cuenta algunas consideraciones

previas como tener al menos el 75% de la batería de la PSP cargada y 32 MB libres en la
Memory Stick Duo.
Los pasos para llevar a cabo la actualización al Custom Firmware 3.40 OE-A desde la versión
1.5 son los siguientes:
• Ejecutar el auto-instalador.
• Elegir la primera opción del auto-instalador.
• Esperar a la finalización del proceso.
• Desde el menú de la PSP acceder a Juegos → Memory Stick.
• Ejecutar el primer archivo de esta sección (tendrá el nombre de autoinstaller).
• Seguir los pasos que se presentan por pantalla hasta finalizar el proceso de
actualización.
• Para comprobar que la actualización se ha llevado a cabo correctamente, se puede

comprobar desde el menú de la PSP: Ajustes → Ajustes del sistema → Información
del sistema → Software del sistema.
35
3.4.1.2 PSPLINK
En un principio, programar una aplicación para la PSP no es una tarea grata. El proceso de
programación, compilación y prueba obliga a repetir una serie de acciones que terminan por
convertirse en un auténtico problema si el proyecto desea desarrollarse de una manera ágil y
fluida. Tras disponer del ejecutable generado por el compilador es necesario copiarlo a la
carpeta correspondiente de la PSP, de manera que se pueda ejecutar el código obtenido y
verificar su funcionamiento. La copia del archivo y la activación de la conexión USB entre la
PSP y el PC deben realizarse manualmente e inevitablemente consumen un tiempo
considerable. Realmente en los primeros pasos del proyecto el tiempo dedicado a probar el
código en ejecución es inferior al perdido en el proceso de preparación previo comentado.
La solución a este problema fundamentalmente logístico viene dada por una aplicación
conocida como PSPLINK[4] (la versión analizada es la 2.0), que como su nombre sugiere,
establece una conexión directa entre la PSP y el PC. Básicamente proporciona un intérprete de
comandos para el usuario construido sobre los 3 medios de comunicación de los que dispone
la PSP: SIO, USB y WI-FI. De esta forma, una vez establecida la conexión con el PC no es
necesario volver a trabajar desde la videoconsola portátil. PSPLINK funciona como un terminal
de texto, enviando comandos desde el PC que son interpretados por la PSP y evitando así
tener que acceder al XMB.
Como se ha comentado, es posible establecer una conexión SIO, USB o WI-FI. Cada una de
estas alternativas requiere su propio proceso de configuración y puede ser utilizada tanto en
sistemas Win32 o *nix. En este caso, se va a describir el proceso de acceso a través de USB.
Su principal ventaja es que permite crear un servidor de ficheros en el PC con una sencilla
aplicación (usbhostfs_pc). El terminal de texto no se conectará entonces directamente a la PSP
limitando el directorio activo al contenido de la videoconsola, sino que lo hará al servidor de
ficheros, el cual se encargará de transferir automáticamente los archivos que se quieran
ejecutar a la PSP. Así pues, desaparece el paso correspondiente a la copia del ejecutable,
pudiendo comprobar el funcionamiento de las aplicaciones con un solo comando.
Los pasos a seguir para la puesta a punto de PSPLINK con una conexión USB HostFS
(servidor de ficheros) sobre Windows son los siguientes:
• Descargar y descomprimir la aplicación en cuestión. Está disponible en la URL del

proyecto (http://ps2dev.org/psp/Tools/PspLink).
• Copiar el contenido de la carpeta v1.5_nocorrupt en el directorio ms0:\PSP\GAME150.
• Borrar el archivo psplink.ini ubicado en la carpeta __SCE__psplink de la PSP.
• Renombrar el archivo psplink.ini.usb a psplink.ini. Con esto se pasa a utilizar el archivo

de configuración preparado para establecer una conexión USB. También se puede
configurar manualmente el fichero original:
36
# usbhost=[0 1] Enable USB host file system. Set to 1 to

enable automatically
usbhost=1
# usbshell=[0 1] Specify whether to start up the usb shell
usbshell=1
Código 3.9. Configuración del archivo psplink.ini para hacer uso de la conexión
USB HostFS.
• Ejecutar PSPLINK en la PSP y conectarla al PC a través del cable USB.
• Windows detectará un nuevo dispositivo de tipo PSP Type B para el que necesita los
controladores. Estos se encuentran en la carpeta que se ha descomprimido al
comienzo, concretamente en la siguiente ruta: pc\windows\driver.
• Si no se dispone de los ejecutables usbhostfs_pc.exe y pcterm.exe, hay que generarlos

a partir de sus correspondientes ficheros makefile. Una vez obtenidos, ejecutar primero
usbhostfs_pc para crear el servidor de ficheros que se conectará a través del USB con
la PSP. Por su parte, pcterm es el terminal de texto empleado para controlar la
videoconsola. Se maneja igual que el intérprete de comandos de un sistema *nix,
aunque cuenta con un repertorio de comandos más limitado. Un detalle a tener en
cuenta es que el sistema de ficheros accesibles desde pcterm se construye tomando
como raíz el directorio en el que se ejecutó usbhostfs_pc, por lo que todas las carpetas
y archivos de los niveles superiores serán inaccesibles.
Se puede acceder a la lista completa de comandos que pueden ser utilizados escribiendo help.
En primer lugar muestra los diferentes módulos o categorías en los que se agrupan estos
comandos. Escribiendo help categoría se visualizan los comandos disponibles en cada
sección. Todavía se puede conseguir más información acerca de cada comando volviendo a
introducir help comando.
La siguiente tabla resume los comandos básicos:
Comando Descripción
Ejecuta en la PSP el módulo ELF programa.elf ubicado en el

./programa.elf
directorio actual.
Ejecuta en la PSP el archivo ejecutable PBP programa.pbp

./programa.pbp
ubicado en el directorio actual.
ls Muestra el contenido del directorio actual.
Finaliza la aplicación que se estaba ejecutando en la PSP y

reset
vuelve a la consola de PSPLINK. También se puede utilizar la
37
combinación de teclas ALT + R.
exit Finaliza PSPLINK volviendo al XMB.
Realiza una captura de pantalla que se guarda en el archivo

scrshot archivo.bmp
indicado.
Tabla 3.1. Comandos básicos de PSPLINK.
Si se compila una aplicación usando el makefile correspondiente, se generan una serie de

archivos entre los que se encuentra un módulo ELF. A este respecto hay que distinguir entre un
módulo ELF que no contiene símbolos de depuración (stripped) y otro que los tiene (not-
stripped). El generado al compilar la aplicación es de este segundo tipo (not-stripped) y si el
código utilizaba las librerías de LTE GE puede dar lugar a un error de ejecución al ser
arrancado con PSPLINK. Este consiste en que la PSP permanece cargando continuamente de
la tarjeta de memoria mientras la pantalla no muestra nada.
Existen tres soluciones posibles al problema comentado:
• Crear el módulo ELF stripped manualmente. El makefile de base suministrado por el

SDK lo añade al archivo PBP, pero después se encarga de eliminarlo. Para evitarlo se
puede eliminar la siguiente línea del archivo psp\sdk\lib\build.mak ubicado en el
directorio en el que se haya instalado el PSPSDK:
-rm -f strip_$(FINAL_TARGET)
Código 3.10. Línea de código en el build.mak que elimina el archivo ELF

stripped.
De esta manera ahora en el directorio aparecerá otro módulo ELF que responderá al
nombre strip_programa.elf y que será el que se debe ejecutar desde PSPLINK.
Si no se quiere modificar el makefile de base, también se puede usar la aplicación

psp-strpip.exe incluida dentro del SDK.
psp-strip not_strip_programa.elf -o strip_programa.elf
Código 3.11. Cómo generar manualmente el archivo ELF stripped.
• Ejecutar el archivo PBP en lugar del módulo ELF. Realmente, un archivo PBP contiene
entre otros ficheros un módulo ELF stripped.
• El problema común a las alternativas anteriores es que si se desea depurar la

aplicación ya no será posible, puesto que se han eliminado todos los símbolos de
depuración. Lo único que se puede hacer entonces es comentar todas las líneas de
código en las que se invoque el método que parece ser el causante del error: virtual
void engine::scene::ISceneManager::drawAll(). De esta manera la aplicación sigue
38
funcionando correctamente con la salvedad de que los elementos de la escena no se

visualizan en pantalla. En algunos casos puede ser suficiente para depurar el código.
En la práctica, el uso de sentencias fprintf(stderr, "mensaje_de_error")

estratégicamente colocadas puede llegar a ser suficiente para no tener que contar con
los símbolos de depuración, con lo que todo se limitaría a ejecutar el PBP en lugar del
ELF.
PSPLINK es una herramienta muy técnica que puede adaptarse fácilmente a las necesidades
del usuario. Sus posibilidades de configuración son muy variadas e introduce también
mecanismos para llevar a cabo procesos de depuración durante la ejecución (definición de
breakpoints, volcados de memoria y registros…). Todas y cada una de sus funcionalidades se
describen en mayor detalle en el manual que acompaña a la herramienta.
3.4.1.3 iR Shell
Como se ha comentado anteriormente, PSPLINK puede ocasionar algunos problemas a la hora

de ejecutar las aplicaciones creadas con LTE GE. Por ello, conviene disponer de una
alternativa que permita seguir aprovechando las ventajas proporcionadas por PSPLINK. Este
es el caso de iR Shell[4], que al igual que PSPLINK permite convertir nuestro PC en un servidor
de ficheros para poder ejecutar aplicaciones sin tener que guardarlas previamente en la PSP.
La principal diferencia respecto a PSPLINK es que no ejecuta módulos ELF, sino ficheros PBP.
Ambos archivos pueden ser generados en el proceso de compilación, por lo que al final el uso
de uno u otro es indistinto, permitiendo ejecutar aquellas aplicaciones que con PSPLINK no era
posible. Además, tampoco necesita de un terminal de texto para enviar los comandos a la PSP,
sino que todo se maneja desde la PSP mediante una intuitiva interfaz gráfica.
iR Shell establece su propia interfaz para acceder a los archivos almacenados en la PSP.
Incluye un amplio abanico de funcionalidades, siendo el uso del usbhostfs la principal ventaja
para el programador. Desde iR Shell se puede navegar fácilmente a través del sistema de
ficheros propio de la PSP hasta acceder al creado en el. Basta entonces con pulsar un solo
botón para ejecutar el PBP seleccionado.
El proceso de instalación depende de la versión del firmware de la PSP. Para la 3.40 Open
Edition de Dark~AleX los pasos a seguir son los siguientes:
• Descargar la última versión de iR Shell (http://www.irshell.com).
• Descomprimir su contenido y copiar la carpeta IRSHELL al directorio raíz de la PSP.
• Comprobar que el firmware está configurado para que los ejecutables de la versión
1.50 se guarden en la carpeta ms0:\PSP\GAME150,
• Copiar las carpetas irshell150 e irshell150% en el directorio ms0:\PSP\GAME150.
39
• Cargar iR Shell desde el XMB y en las opciones de configuración modificar el

homebrew path para que apunte a la carpeta ms0:\PSP\GAME150.
• Descargar usbhostfs y ejecutarlo. Como en el caso de PSPLINK, es preciso haber

instalado previamente los controladores del USB para que reconozca la PSP como un
dispositivo PSP Type B. Estos se encuentran en la carpeta drivers.
• Activar la opción Toggle USBHost. En la ventana de usbhostfs debería aparecer el

mensaje Connected to device.
• Ir a Directory View de iR Shell. ascender por el árbol de ficheros hasta localizar el

directorio usbhost0:/ y entrar en él. A continuación aparecerá el contenido del directorio
en el que se ejecutó usbhostfs_pc.exe. Desde ahí es posible ejecutar cualquier PBP
como si estuviera en la PSP.
Otra de las características de iR Shell que puede ser útil de cara a una posterior presentación
de la aplicación es que permite realizar capturas de pantalla de la PSP. Para ello basta con
pulsar el botón que contiene el dibujo de una nota musical. Las imágenes se guardan en la
carpeta ms0:\PSP\PHOTO\SNAPSHOT.
3.4.1.4 Cómo instalar LTE GE en sistemas Win32
Se parte de la premisa de que se va a trabajar en un sistema Win32 que no tiene instalado

Cygwin.
• Descargar pspdev para sistemas Win32 (http://xorloser.com) y LTE GE

(http://www.ltestudios.com).
• Es recomendable utilizar el directorio por defecto o en caso de modificarlo, asegurarse

de que la nueva ruta no incluya espacios en blanco.
• Marcar la opción correspondiente a configurar las variables de entorno, ya sea para el

usuario actual o para todos los usuarios.
• Una vez instalado, renombrar el archivo c:\pspdev\bin\mkdir.exe a

c:\pspdev\bin\mkdir2.exe. Editar el archivo c:\pspdev\psp\sdk\lib\build.mak y
reemplazar en el código todas las apariciones de mkdir por mkdir2.
• Descomprimir el motor en cualquier carpeta y copiar el contenido de los directorios

include y lib en c:\pspdev\psp\include y c:\pspdev\psp\lib respectivamente.
Esto es suficiente para instalar LTE GE. Se puede comprobar que el proceso se ha realizado
sin problemas compilando cualquiera de los ejemplos disponibles.
40
3.4.1.5 Cómo compilar una aplicación creada con LTE GE usando

Microsoft Visual C++ 2005 Express Edition
Para facilitar la labor de programación es recomendable usar alguno de los IDE disponibles,
como Microsoft Visual C++ 2005 Express Edition. Los pasos a seguir para configurarlo y poder
compilar el código de un proyecto cualquiera son los siguientes: [5]
• Crear un nuevo proyecto de tipo Makefile Project.
• No es necesario cambiar nada en la ventana del asistente, por lo que se puede pulsar
directamente sobre el botón Finish.
• Crear en el directorio del proyecto un fichero que se llame makefile con el siguiente
código:
TARGET = Ejemplo
OBJS = main.o
CFLAGS = -G0 -O2

#CFLAGS = -G0 -O2 -g
CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti
#CXXFLAGS = $(CFLAGS) –fexceptions –fno-rtti
ASFLAGS = $(CFLAGS)
LDFLAGS =
LIBDIR =
INCDIR =
LIBS = -lengine -lpspwlan -lglut -lGLU -lGL -lpspvfpu -lm -

lstdc++ -lpsppower -lpsprtc -lpspaudio
EXTRA_TARGETS = EBOOT.PBP
PSP_EBOOT_TITLE = Ejemplo LTE GE

#PSP_EBOOT_ICON = ICON0.PNG
#PSP_EBOOT_ICON1 = ICON1.PMF
#PSP_EBOOT_UNKPNG = PIC0.PNG
#PSP_EBOOT_PIC1 = PIC1.PNG
#PSP_EBOOT_SND0 = SND0.AT3
PSPSDK = $(shell psp-config --pspsdk-path)

include $(PSPSDK)/lib/build.mak
Código 3.12. Contenido de un archivo makefile genérico para LTE GE.
La función de los principales parámetros definidos es:
41
TARGET = Ejemplo
Asigna internamente un nombre a la aplicación. Este nombre se utiliza al crear la

carpeta en la que se guarda la aplicación en la PSP. También coincide con el nombre
del archivo ELF resultado de la compilación.
OBJS = main.o
Indica al compilador qué archivos tiene que compilar. En este caso, buscará el archivo
main.cpp en el mismo directorio en el que se encuentra el makefile y generará el
archivo objeto main.o. Si se tuvieran que compilar más archivos, estos se indicarían a
continuación de main.o separados por espacios en blanco.
INCDIR =
Si los ficheros de cabecera de la aplicación no se encuentran en el mismo directorio

que el makefile, es preciso indicar la ruta de los directorios correspondientes.
CFLAGS = -G0 -O2

#CFLAGS = -G0 -O2 -g
La línea que comienza con el carácter # está comentada y por tanto es ignorada al
ejecutar el makefile. La idea es que sólo una de estas líneas esté habilitada. La
diferencia entre ambas es que el parámetro -g compila la aplicación con símbolos de
depuración. La inclusión de estos símbolos permite que el depurador pueda
proporcionar información adicional, pero al mismo tiempo aumenta el tamaño de los
archivos generados.
CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti

#CXXFLAGS = $(CFLAGS) –fexceptions –fno-rtti
De nuevo se da a elegir entre cualquiera de estas dos líneas comentando aquella de la

que se quiera prescindir. La primera omite los bloques de código de tipo try-catch-
throw, mientras que la segunda trata las excepciones.
PSP_EBOOT_TITLE = Ejemplo LTE GE
El nombre especificado para este parámetro será el que posteriormente aparezca en el

XMB de la PSP.
#PSP_EBOOT_ICON = ICON0.PNG
#PSP_EBOOT_ICON1 = ICON1.PMF
#PSP_EBOOT_UNKPNG = PIC0.PNG
#PSP_EBOOT_PIC1 = PIC1.PNG
#PSP_EBOOT_SND0 = SND0.AT3
42
Aunque no es estrictamente necesario incluir las siguientes líneas, proporcionan a la

aplicación un acabado similar al de cualquier otro videojuego comercial (en lo que a su
visualización en el XMB se refiere). Definen una serie de archivos externos:
o ICON0.PNG. Es la imagen que aparece en el XMB cuando se muestra la lista

de aplicaciones disponibles en la tarjeta de memoria.
o ICON1.PMF. Es una animación que sustituye a la imagen anterior.
o PIC0.PNG. Es la imagen que suele ser empleada para describir el contenido de

la aplicación, por lo que incluye fundamentalmente texto. Tras seleccionar la
aplicación en el XMB se visualiza gradualmente sobre el fondo. Por ello, suele
presentar transparencias para no ocultar la siguiente imagen.
o PIC1.PNG. Es la imagen de fondo que llena la pantalla al seleccionar la

aplicación en el XMB.
o SND0.AT3. Se trata de un sonido que es reproducido repetidamente después

de seleccionar la aplicación.
Este archivo de texto debe ser guardado en formato Unix, por lo que es recomendable
usar un editor de texto como UltraEdit que dispone de esta opción. Para no tener que
crearlo desde cero también se puede editar alguno de los makefile que se incluyen en
los ejemplos de LTE GE.
• Crear un archivo clean.bat con el siguiente código:
del *.elf
del *.o
del *.pbp
del *.sfo
Código 3.13. Contenido del archivo clean.bat.
Es una manera sencilla de eliminar todos los archivos generados por el makefile para
poder volver a compilar la aplicación.
• Y otro más que se llame rebuild.bat:
del *.elf
del *.o
del *.pbp
del *.sfo
make
Código 3.14. Contenido del archivo rebuild.bat.
43
Realiza las mismas operaciones que clean.bat y además vuelve a compilar la

aplicación.
• Sólo queda configurar el proyecto desde el menú Project → Properties o simplemente

pulsando ALT + F7. Hay que seleccionar la pestaña NMake dentro de Configuration
Properties, y escribir make, rebuild y clean donde pone Build Command Line, Rebuild
All Command Line y Clean Command Line respectivamente. Además, en Include
Search Path se deben añadir los directorios que contienen los archivos de cabecera.
Como los de LTE GE ya han sido copiados al directorio del SDK, sólo hay que indicar
las carpetas c:\pspdev\psp\sdk\include y c:\pspdev\psp\include.
Una vez completado el proceso anterior ya se puede pulsar sobre Rebuild Solution o CTRL +
ALT + F7.
3.4.1.6 Cómo preparar una aplicación de prueba con LTE GE
A la hora de enfrentarse por primera vez a un motor para el desarrollo de juegos como es LTE
GE, es muy habitual realizar pequeñas aplicaciones que proporcionan al programador una
noción general de su funcionamiento. Con este propósito, resulta útil disponer de una
aplicación de prueba que pueda ser utilizada a modo de plantilla con los diferentes ejemplos.
Básicamente consiste en un proyecto con el mínimo código necesario para ponerlo en marcha.
Así, cuando se quiera comprobar la validez de un nuevo algoritmo o simplemente ver cuál sería
el resultado en ejecución de una sencilla operación, basta con transferir el código a la
aplicación de prueba que se ha creado.
En esta ocasión se van a presentar extractos de código en primer lugar para finalmente mostrar
el código completo. Como se va a usar el makefile creado previamente, todo el código descrito
a continuación corresponde al archivo main.cpp.
#include <engine.h>
El primer paso para utilizar LTE GE consiste en incluir el archivo de cabecera del motor para
poder acceder a sus diferentes clases y funciones.
#define PSP_ENABLE_DEBUG
#include “common.h”
A continuación hay que decidir si se va a compilar la aplicación en modo depuración. Hacerlo

así supone configurar la PSP para mostrar en pantalla información de depuración. Además, el
código generado será menos eficiente, pero también se compilará más rápido. La forma de
trabajar en este tipo de proyectos suele consistir en probar la mayor parte del código en modo
depuración y periódicamente compilar el código en modo final, para detectar cualquier error
que hubiera sido omitido en el otro modo. Así al terminar el proyecto y compilar el código
definitivo se habrán eliminado la mayor parte de los fallos que pudieran haberse acumulado en
este punto.
44
El archivo de cabecera common.h es empleado por los ejemplos que acompañan a LTE GE
recopilando algunas operaciones de bajo nivel comunes a todos ellos. Aunque podría
integrarse el código correspondiente en la propia aplicación, como se trata de un programa de
prueba se ha optado por aprovecharlo. En él se incluye la estructura condicional sobre el
símbolo PSP_ENABLE_DEBUG.
using namespace engine;

using namespace core;
using namespace scene;
using namespace video;
using namespace io;
using namespace gui;
using namespace audio;
using namespace net;
Se ha utilizado la sentencia using para todos los espacios de nombres. Así se evita teclear
continuamente el espacio de nombres al que se accede, pero también da pie a que puedan
aparecer ambigüedades. En un proyecto real es recomendable referirse de manera explícita a
cada espacio de nombres, aunque el tiempo invertido en ello en ocasiones puede ser excesivo
y muchos programadores terminan por optar por la primera opción.
engineDevice* device = NULL;

IVideoDriver* driver = NULL;
ISceneManager*smgr = NULL;
IGUIEnvironment *guienv = NULL;
Estas variables globales son punteros empleados para acceder a toda la funcionalidad que
proporciona el motor. El puntero fundamental entre los declarados es device. Una vez
inicializado permitirá obtener las referencias para los punteros restantes. Dado que se trata de
una pequeña aplicación de prueba, el uso de variables globales no supone mayor problema.
void ini()
{
}
void update()
{
}
void end()
{
}
Las 3 funciones implementadas todavía no contienen código propiamente dicho, dado que este
dependerá de cada aplicación concreta. La primera de ellas, ini(), está pensada para inicializar
45
todos los elementos de la escena (cargar modelos, texturas, precalcular valores…). Sólo será
invocada una vez, al comienzo de la ejecución del programa. Por su parte, update() se encarga
de actualizar la lógica de la escena (la posición de los modelos, el momento en el que deben
aparecer o desaparecer, actualizar el estado de los botones…). Se invocará repetidamente
dentro de un bucle hasta que la aplicación finaliza. En ese momento intervendrá la función
end() para garantizar que el programa puede terminar sin problemas.
int engineMain(unsigned int argc, void *argv)

{
El punto principal para comenzar a utilizar el motor es la función engineMain(). En versiones

anteriores de LTE GE se empleaba la función main(), pero desde que dispone de soporte para
establecer comunicaciones WI-FI hay que usar engineMain().
setupPSP();
El archivo common.h contiene la implementación de esta función. Se encarga de configurar la

PSP de manera que pueda ejecutar el código escrito con LTE GE.
device = createDevice(NULL, false);

driver = device->getVideoDriver();
smgr = device->getSceneManager();
guienv = device->getGUIEnvironment();
Se definen las variables globales. Estas sentencias podrían haberse incluido dentro de la
función ini(), pero al no variar de una aplicación a otra se han dejado en la función principal.
ini();
Después se invoca la función ini() para inicializar la escena con los elementos propio de cada
aplicación.
while(device->run())
{
update();
driver->beginScene(true, true, SColor(255, 14, 4, 31));

smgr->drawAll();
guienv->drawAll();
driver->endScene();
}
Este es el bucle principal del juego. La llamada a device->run() al comienzo del bucle es muy
importante. No sólo actualiza el temporizador interno del motor, sino que también detecta
nuevos eventos.
46
Por cada pasada se actualiza la lógica del juego (update()), el controlador gráfico limpia la
pantalla y el buffer de profundidad (driver->beginScene()), se dibuja el contenido de la escena
(smgr->drawAll()), los elementos del GUI (guienv->drawAll()) y finalmente se vuelca todo a la
pantalla (driver->endScene()). El bucle se repite mientras el juego esté funcionando y hasta que
el usuario indique explícitamente que desea salir o se dé algún error fatal.
end();
Con esta línea de código se finaliza la aplicación asegurándose de que no queda nada
pendiente.
device->drop();
Al llamar a createDevice() se creó una referencia que debe ser eliminada por el programador
mediante el método drop().
sceKernelExitGame();
return 0;
}
Este último paso pretende indicar a la PSP que la aplicación ha terminado. Se trata
prácticamente del único código de bajo nivel que es necesario escribir al programar con LTE
GE.
#include <engine.h>
#define PSP_ENABLE_DEBUG
#include “common.h”
using namespace engine;

using namespace core;
using namespace scene;
using namespace video;
using namespace io;
using namespace gui;
using namespace audio;
using namespace net;
engineDevice* device = NULL;

IVideoDriver* driver = NULL;
ISceneManager*smgr = NULL;
IGUIEnvironment *guienv = NULL;
void ini()
{
47
void update()
{
}
void end()
{
}
int engineMain(unsigned int argc, void *argv)

{
setupPSP();
device = createDevice(NULL, false);

driver = device->getVideoDriver();
smgr = device->getSceneManager();
guienv = device->getGUIEnvironment();
ini();
while(device->run())
{
update();
driver->beginScene(true, true, SColor(255, 14, 4, 31));
smgr->drawAll();
guienv->drawAll();
driver->endScene();
}
end();
device->drop();
sceKernelExitGame();
return 0;
}
Código 3.15. Aplicación de prueba (barebones) para utilizar LTE GE.
3.4.1.7 Resolución de problemas de programación
Existen algunos problemas conocidos de las librerías de LTE GE o del PSPSDK. Siempre que
ha sido posible se ha recogido la causa del problema y su solución, si bien hay casos en los
que debido a errores internos de las propias librerías ha sido necesario buscar otras
alternativas ante la imposibilidad de solventar el error.
48
• Error de compilación. Doble definición de mbstate_t en cwchar y wchar.h.
o Causa. Ocurre al incluir los archivos de cabecera string.h o iostream.h. El

archivo wchar.h del PSPSDK declara el tipo mbstate_t, pero posteriormente no
define el símbolo _GLIBCXX_HAVE_MBSTATE_T. Este símbolo es el que
determina dentro del fichero cwchar si se debe declarar o no la estructura
mbstate_t.
o Solución. Si bien una primera solución consiste en definir el símbolo

_GLIBCXX_HAVE_MBSTATE_T, en la práctica lo más cómodo es comentar la
línea en la que se declara el tipo mbstate_t dentro de wchar.h. También hay
que reemplazar todas las apariciones de mbstate_t por _mbstate_t.
#ifndef _MBSTATE_T
#define _MBSTATE_T
//typedef _mbstate_t mbstate_t;
#endif /* _MBSTATE_T */
Código 3.16. Solución al conflicto de nombres dentro de wchar.h.
• Error de ejecución al acceder a constantes estáticas de tipo string.
o Causa. Está motivado por la utilización de una constate estática de tipo string,
pero se desconoce si existe una causa real o es un problema circunstancial.
o Solución. Basta con declarar las constantes estáticas como char* en lugar de
string.
• Error de ejecución al cargar un modelo con extensión .ms3d.
o Causa. Ocurre al utilizar el método getMesh() del gestor de la escena para

cargar un modelo exportado con el formato propio de la aplicación MilkShape
3D.
o Solución. No existe una solución aparente y parece tratarse de un error en el

algoritmo que se encarga de procesar este tipo de archivos. Dado que el propio
MilkShape 3D permite exportar un modelo en una gran variedad de formatos,
es recomendable utilizar alguno de los que se ha comprobado que funcionan
correctamente. Por ejemplo, .md2 para modelos animados y .3ds para modelos
estáticos.
• Error de ejecución al cargar texturas o fuentes mediante el servidor de ficheros del

ordenador (haciendo uso de iR Shell).
49
o Causa. Ocurre al invocar los métodos getTexture() del gestor de escena o

getFont() del gestor del GUI para cargar recursos almacenados en el
ordenador (usbhost0:/).
o Solución. Es posible que pueda tratarse tanto de un error de LTE GE como de

algún problema de compilación. En ciertos casos con sólo cambiar la línea de
código problemática de lugar el error desaparece, aunque no se trata de una
solución práctica. Lo que proporciona unos mejores resultados es realizar
todas a las referencias a los recursos externos (modelos, sonidos, texturas…)
directamente desde la PSP (ms0:/ en lugar de usbhost0:/). Aunque esto
suponga almacenar en la videoconsola todos estos elementos, generalmente
no obstaculiza el proceso de programación, compilación y prueba que tanto
facilita iR Shell. La aplicación compilada puede seguir cargándose mediante la
conexión USB.
• Comportamiento incorrecto del CollisionResponseAnimator en un mapa BSP.
o Causa. Ocurre al asignar el animador CollisionResponseAnimator a la cámara

para que esta se desplace por un mapa BSP respondiendo a las colisiones con
los muros y paredes. Al cabo de un tiempo indeterminado la cámara atraviesa
las paredes o cae a través del suelo por efecto de la gravedad.
o Solución. No se ha encontrado una solución a nivel de programación, si bien

es posible evitar en gran medida este comportamiento duplicando las
superficies sólidas con las que la cámara puede colisionar. Por ejemplo, en
lugar de usar una sola primitiva para representar el suelo, apilar dos o más de
manera que cuando la cámara atraviese la primera, se vea frenada por la
segunda. Aunque se podría pensar que la cámara entonces atravesará
igualmente la segunda superficie, esto no sucede y para ciertas aplicaciones
puede ser suficiente.
• Error de ejecución al añadir un nodo de tipo ITerrainSceneNode a la escena.
o Causa. Se debe a una limitación no recogida en el manual de referencia de

LTE GE. Como máximo se pueden llegar a añadir 3 nodos ITerrainSceneNode.
Aunque se hayan eliminado mediante el método remove() correspondiente, al
intentar añadir un tercer nodo de este tipo la aplicación se bloquea.
o Solución. Al tratarse de un problema interno de la librería LTE GE, no ha si

posible hallar una solución.
3.4.2 Modelado
Se comentan herramientas y tutoriales relacionados con los procesos de modelado y

texturizado.
50
3.4.2.1 MilkShape 3D
Existen gran variedad de herramientas para modelar y animar objetos 3D, pero pocas con la
sencillez y posibilidad de editar tantos modelos de diferentes juegos comerciales. MilkShape
3D es un modelador de bajo número de polígonos inicialmente diseñado para Half-Life. Desde
entonces se han ido añadiendo nuevas funcionalidades y soporte para formatos de modelos de
otros videojuegos.
MilkShape 3D incluye operaciones básicas para seleccionar, mover, rotar, escalar, subdividir,
extrudir… Permite editar los modelos a bajo nivel, trabajando con los vértices o las caras de los
polígonos, y añadir primitivas básicas como esferas, cubos o cilindros. También dispone de un
animador de esqueletos con el que se pueden modificar las animaciones que ya tienen los
modelos o crear otras nuevas.
Se trata de una aplicación shareware con un periodo de prueba gratuito de 30 días. Pasado el
mismo es necesario comprar una clave de activación para seguir utilizando MilkShape 3D. En
cualquier caso, cuando se recurrió a esta aplicación, el precio a pagar para registrarla era de
25 € o 25 USD. Bastante asequible comparado con el de otras herramientas comerciales y
teniendo en cuenta además que se adapta perfectamente a unas necesidades muy
específicas.
MilkShape 3D ha sido de ayuda a la hora de desarrollar el videojuego al permitir incorporar

modelos de terceros a los escenarios creados. LTE GE sólo permite cargar modelos animados
con formato .ms3d, .x o .md2. El primero es el formato nativo de MilkShape 3D, el segundo de
DirectX y el último pertenece al videojuego Quake 2. Mientras para los dos primeros no existe
una comunidad reconocida de artistas 3D, en el caso de Quake 2 y otros muchos videojuegos
comerciales sí que la hay o la hubo durante unos cuantos años tras su lanzamiento. Uno de los
títulos que contó con una mayor contribución a este respecto fue Half-Life, y junto a Quake 2 se
ha considerado como la principal referencia a la hora de buscar modelos. No obstante, existe
un problema inherente a la utilización de los modelos del Half-Life con LTE GE y es que el
formato que emplean (.mdl) no está soportado.
A continuación se detalla el proceso a seguir en MilkShape 3D para exportar un modelo en

formato .mdl a .md2 conservando las texturas y animaciones incluidas en el original:
• Ejecutar MilkShape 3D y seleccionar en el menú desplegable Tools → Half-Life →

Decompile Normal HL MDL File…
• Seleccionar el modelo .mdl que se quiere exportar como .md2.
• Marcar todas las casillas dentro del cuadro de diálogo MDL Decompile y pulsar en Ok.
En el directorio en el que se encuentra el modelo se habrán creado una serie de
ficheros .smd. Cada uno de estos representa una animación diferente y generalmente
sólo uno de ellos contiene información acerca de la geometría. Este suele venir
identificado por el nombre del modelo original o yendo acompañado de la palabra
reference.
51
• Seleccionar File → Import → Half-Life SMD… y buscar el archivo .smd de referencia

comentado.
• Ir a la pestaña Groups en el panel de la derecha y comprobar si existe más de un

grupo. En el mejor de los casos sólo habrá un grupo y se puede saltar al paso
siguiente.
o Si el modelo tiene más de un grupo, cada uno de estos tiene su propia textura
asignada. Los modelos .md2 sólo pueden tener una imagen con todas las
texturas, por lo que es necesario recombinar cada imagen en una más grande
que las contenga. Para ello se puede usar cualquier herramienta de edición de
imágenes. Hay que respetar el tamaño original de las texturas, distribuirlas en
una sola imagen de la manera más compacta posible y guardarla como un
archivo BMP. Las dimensiones de la nueva imagen deben ser potencia de 2
para que MilkShape 3D no la deforme.
o En MilkShape 3D seleccionar todo el modelo, ir a la pestaña Materials y

eliminar todos los que aparezcan.
o Añadir un nuevo material pulsando en New y seleccionar la imagen BMP que

se ha creado previamente.
o Seleccionar todo el modelo y aplicar el material pulsando en Assign.
• Sin deseleccionar el modelo, dentro del menú desplegable ir a Window → Texture

Coordinate Editor. Las coordenadas de las texturas del modelo dependen de las
dimensiones del archivo que las contiene. Al haberlo hecho más grande para añadir
todas las texturas, las coordenadas han sido modificadas y ya no se corresponden con
las de la nueva imagen. Por tanto, es necesario ajustarlas manualmente empleando los
controles disponibles en la ventana.
• Para añadir animaciones al modelo hay que pulsar el botón Anim y pasar al siguiente
cuadro de animación. A partir de aquí se puede importar cualquiera de las animaciones
(archivos .smd) que se generaron en los primeros pasos.
• Finalmente hay que crear un archivo .qc que indica al exportador de MilkShape 3D qué
nombre se va a asignar a cada animación y de cuántos cuadros de animación consta.
En el directorio en el que se instaló MilkShape 3D existe un archivo .qc de ejemplo,
aunque se puede crear directamente con el siguiente contenido:
// Sample MD2 config, copy into export directory

$modelname model.md2
$origin 0.0 0.0 0.0
// skins
$skinwidth 128
52
$skinheight 128
$skin skin.bmp
// sequences
$sequence idle 1 129
$sequence walk 130 153
$sequence die 154 193
$sequence look 194 294
Código 3.17. Archivo md2.qc de ejemplo.
Es necesario colocarlo en el mismo directorio en el que se encuentra el archivo .mdl y

completarlo con los datos correspondientes. Como la textura es aplicada
posteriormente al modelo desde el código del videojuego, se puede prescindir del
apartado skins. El apartado sequences es el que describe las diferentes animaciones
indicando primero el nombre con el que se va a poder acceder a ella desde LTE GE y
después el cuadro de animación de inicio y finalización de la animación.
• El último paso consiste en exportar el modelo mediante la opción File → Export →

Quake2 MD2…
3.4.2.2 Cómo corregir la posición y el desplazamiento en los

archivos SMD
Al cargar en MilkShape 3D las animaciones de los modelos de Half-Life es habitual que se dé

alguno de los siguientes problemas: el modelo se encuentra hundido respecto al plano que
representa el suelo o el modelo se desplaza a medida que se reproduce la animación. En
cualquier caso, ambos comportamientos no son deseables, dado que se seguirán produciendo
al cargarlos con LTE GE.
Un archivo .smd contiene información que puede ser modificada con cualquier editor de texto.
Los datos almacenados pueden ir desde los vértices de los triángulos que definen el modelo,
hasta la posición de los nodos que forman el esqueleto (existe una descripción detallada sobre
el formato de los archivos SMD en http://developer.valvesoftware.com/wiki/Smd).
Para solucionar los problemas comentados hay que fijarse en los bloques de texto que
comienzan después de la palabra time. Cada uno de estos bloques define un cuadro de
animación del modelo. El primer número de cada línea es el identificativo de un nodo del
esqueleto previamente declarado. Los 3 siguientes son su posición (X, Y, Z). Generalmente el
nodo 0 representa el modelo completo, por lo que la corrección de la posición y el
desplazamiento sólo se realiza sobre la primera línea de cada bloque de tiempo. Como el
modelo de referencia suele cargarse en las coordenadas correctas, el valor de la coordenada Y
puede tomarse de su archivo SMD. Copiándolo en la primera línea de cada cuadro de
animación se evita el hundimiento del modelo situándolo a la altura correcta. Si además se
quiere evitar el desplazamiento, es preciso sustituir la primera línea de cada cuadro de
53
animación con la de time 0. De esta forma se consigue que la posición del modelo sea siempre
la misma en todos los cuadros de animación, mientras sus articulaciones se mueven
libremente.
time 0
0 0.235347 -0.235347 38.884376 0.000000 0.000000 -1.570874
1 0.679708 -0.015625 0.000000 -1.570795 -1.570796 0.000000
2 -0.000005 0.000007 3.713255 -0.055264 3.176510 -0.210053
time 1
0 0.239254 -0.239254 38.872657 0.000000 0.000000 -1.570874
1 0.671896 -0.015625 0.000000 -1.570795 -1.570796 0.000000
2 -0.000005 0.000007 3.713255 -0.055168 3.176605 -0.213162
Código 3.18. Extracto de un archivo SMD de ejemplo.
3.4.2.3 Q3Radiant
LTE GE permite cargar archivos BSP, el formato creado por IDSoftware para los escenarios de
su videojuego Quake 3 Arena. Este formato utiliza un espacio de particionado binario que
genera niveles rápidamente minimizando la cantidad de polígonos que deben ser dibujados en
pantalla. No obstante, este algoritmo sólo resulta eficiente con escenarios cerrados sin grandes
zonas abiertas.
Para poder crear un mapa BSP se necesita el editor de mapas Q3Radiant (se puede obtener
de manera gratuita en http://www.idsoftware.com/business/techdownloads). El videojuego
Quake 3 Arena no es imprescindible, aunque conviene disponer del mismo para aprovechar las
diferentes texturas que incluye. Tampoco se puede prescindir del mismo si se desea
comprobar el acabado del escenario creado en el PC en lugar de en la PSP, lo cual puede
resultar más rápido permitiendo que el proceso de edición sea más cómodo. Algo similar ocurre
con la herramienta Q3Build (http://q3build.sagnor.com), diseñada para compilar los archivos
.map que se vayan generando y obtener así los .bsp correspondientes. Estos pasos pueden
realizarse igualmente desde Q3Radiant, aunque Q3Build incluye otras opciones como ejecutar
el mapa directamente sobre Quake 3 Arena y una interfaz más completa.
A continuación se describe cómo construir una habitación sencilla, compilar el mapa y probarlo
en Quake 3 Arena: [6]
• Una vez se ha arrancado Q3Radiant ir al menú desplegable Textures y seleccionar

gothic_wall. La ruta desde la que se leen las texturas está especificada en la opción
File → Project Settings… → texturepath. Se pueden añadir nuevas texturas en el
directorio indicado y la próxima vez que se ejecute Q3Radiant aparecerán en el menú
Textures. También se puede cargar directamente mediante Textures → Load…
54
• La ventana principal de Q3Radiant muestra una vista del plano XY que corresponde a
la vista en planta. Se puede alternar entre los diferentes planos mediante View →
Layout o pulsando la combinación de teclas CTRL + TAB.
• El menú Brush indica cuál es la primitiva que se va a dibujar en el mapa. La que viene
asignada por defecto corresponde a una primitiva de 4 lados, por lo que no hay que
cambiar nada y basta con arrastrar el cursor sobre la vista del plano XY hasta crear
una habitación. Para especificar la altura de la misma es necesario cambiar a la vista
del plano XZ y arrastrar el lado superior del cuadrilátero.
• La cámara que determina la parte del mapa que se visualiza en la vista en perspectiva
se controla mediante las teclas de cursor. La tecla A y Z permiten rotar la cámara hacia
arriba y abajo respectivamente. D se emplea para mover la cámara hacia arriba y C
hacia abajo.
• Una vez se ha creado el bloque que representa la habitación, se debe hacer hueco de
manera que se genere un espacio limitado por 4 paredes. Para ello hay que usar el
botón Hollow de la barra de herramientas. Esta operación también se encuentra en el
menú desplegable Selection → CSG → Hollow.
• Si la textura no se ajusta a la superficie exactamente cómo se había previsto, es

posible modificar diferentes parámetros con la opción Textures → Surface inspector.
• Es posible seleccionar los elementos del mapa desde la vista en perspectiva

manteniendo pulsada la tecla Mayúsculas. Para deseleccionar cualquier elemento
basta con pulsar la tecla ESC.
• Existen una gran cantidad de entidades que se pueden añadir a un mapa de Quake 3
Arena, pero dado que no tienen ningún significado para LTE GE no resultan de utilidad.
En este caso, las únicas que se tienen en cuenta son aquellas que representan luces y
que se emplean para generar los mapas de iluminación. Se puede añadir una entidad
de tipo light en cualquier punto del mapa usando el menú contextual. Cada entidad
tiene una serie de propiedades que pueden ser modificadas para obtener diferentes
efectos. La lista completa de entidades con sus propiedades se encuentra en la
documentación de Q3Radiant. Para ir a la ventana de la entidad hay que pulsar la tecla
N. En este caso, por ejemplo, se puede cambiar el color de la luz a rojo añadiendo la
clave _color con el valor 1 0 0.
• Para probar el mapa en Quake 3 Arena hay que añadir otra entidad que indique la
posición en la que debe aparecer el jugador. Para ello se debe colocar en el interior de
la habitación una entidad de tipo info_player_start.
• Si bien sólo se han comentado las combinaciones de teclas que permiten acceder a los
comandos básicos del editor, hay una lista completa en Help → Command List.
55
• Los últimos pasos consisten en salvar el mapa y compilarlo para generar el archivo
BSP correspondiente. Es aquí donde se utiliza la herramienta Q3Build. Lo primero que
hay que hacer es configurar los parámetros para el proceso de compilación. A medida
que la complejidad de la geometría del mapa va aumentando, el tiempo de compilación
es cada vez mayor. Así pues, mientras no sea necesario comprobar el acabado final
del escenario es mejor utilizar los valores por defecto o eliminar determinados cálculos
mediante la opción Custom. Para generar el archivo BSP final es recomendable usar
los parámetros -fulldetail dentro de BSP y -extra dentro de LIGHT. VIS puede
mantenerse con Normal y VLIGHT con None. Si además se marca la casilla Run Q3
After Build, el mapa será ejecutado en Quake 3 Arena una vez haya sido compilado.
• Para que Q3Build funcione correctamente necesita los archivos en tiempo de ejecución
de Visual Basic 6.0. Se pueden descargar desde la página web de ayuda y soporte
técnico de Microsoft (http://support.microsoft.com/kb/192461).
Otro aspecto a considerar relacionado con Quake 3 Arena es que LTE GE puede leer archivos
PK3 con las ventajas que ello conlleva. PK3 es el formato comprimido empleado por Quake 3
Arena para todos los elementos del juego. Aunque no es obligatorio, los mapas y las texturas
deberían ser comprimidos en archivos .pk3 de manera que ocupen el menor espacio posible.
Cuando se quiere cargar un mapa creado con Q3Radiant en la PSP, hay que tener en cuenta
que todos los elementos a los que hace referencia el mapa deben ser incluidos también en la
PSP. Para crear un archivo .pk3 es necesario seguir los pasos siguientes:
• La estructura de directorios a es la misma que emplea Quake 3 Arena para organizar

los diferentes elementos del juego. Básicamente sólo se necesitan dos directorios:
maps y textures.
• En el directorio maps se tienen que incluir todos los archivos .bsp que se deseen
utilizar en la PSP. Por su parte, en la carpeta textures hay que añadir las texturas que
se utilizan en el mapa respetando los subdirectorios creados por Quake 3 Arena. Dado
que no se requieren todas las texturas disponibles, es importante llevar un listado de
las que se añaden al mapa. Mediante la opción Textures → Show In Use y Textures →
Surface Inspector se pueden obtener todos los datos necesarios.
• Emplear una aplicación de compresión de datos como WinZip o WinRAR para generar
un archivo .zip con la estructura de directorios anterior y cambiar la extensión de .zip a
.pk3.
• A continuación se recogen las instrucciones necesarias para añadir el archivo

comprimido map-test.pk3 al sistema de ficheros de LTE GE y cargar el mapa test.bsp.
Para añadirlo a la escena se emplea un nodo de tipo octree que mejora el rendimiento
general.
56
device->getFileSystem()->addZipFileArchive(
“ms0:/media/map-test.pk3”);
scene::IAnimatedMesh* mesh = smgr->getMesh(“test.bsp");
node = smgr->addOctTreeSceneNode(mesh->getMesh(0));
Código 3.19. Extracto de código del ejemplo 02.Quake3Map. Cómo añadir un

archivo .pk3 al sistema de ficheros de LTE GE.
3.4.2.4 WAD2BMP
Si bien es posible encontrar gran cantidad de texturas de diferentes fuentes, no todas ellas
pueden tener la calidad esperada o ajustarse a la temática de un juego concreto. En el caso
concreto de este videojuego, la estética militar, industrial y urbana son fundamentales para
lograr una buena ambientación. Un videojuego como Half-Life incluye suficientes texturas de
estos tipos y existen además varias modificaciones como Counter-Strike o Team Fortress a las
que se puede acceder de forma gratuita con el mismo propósito.
Estas texturas no se encuentran disponibles directamente para ser utilizadas, sino que forman
parte de archivos .wad (Where is All the Data) que agrupan mapas, gráficos y otros datos del
juego. La herramienta comentada, wad2bmp
(http://nemesis.thewavelength.net/files/files/wad2bmp201.zip), permite extraer todas las
texturas almacenadas en uno de estos archivos y guardarlas como imágenes .bmp. Después
pueden ser añadidas al directorio de texturas al que apunta Q3Radiant para usarlas en los
mapas creados con el editor.
No dispone de una interfaz gráfica y se maneja como una aplicación de línea de comandos con
la siguiente sintaxis:
wad2bmp.exe -p <package> [-d <directory>]
Código 3.20. Argumentos de wad2bmp.
3.4.3 Comunicaciones
La videoconsola PSP cuenta con un dispositivo 802.11b Wireless Ethernet (WI-FI) que permite
establecer conexiones inalámbricas para la transmisión de datos con otros dispositivos WI-FI.
La PSP soporta dos tipos de conexiones en función de la existencia de un punto de acceso:
• Ad-hoc. La PSP origen y destino se comunican directamente utilizando sus direcciones

MAC como identificadores. Ambas videoconsolas deben estar configuradas para usar
el mismo canal de transmisión. La conexión se inicia cuando la PSP que actúa de
servidor envía una serie de paquetes PDP en modo broadcast con su dirección MAC.
57
Los clientes que están escuchando en el mismo canal reciben los paquetes del
servidor, pudiendo enviar a su vez su dirección MAC para confirmar la conexión.
Figura 3.3. Conexión en modo ad-hoc.
• Infraestructura. La PSP origen y destino se comunican mediante un punto de acceso

intermedio. La conexión se establece mediante el protocolo IP, por lo que el primer
paso consiste en solicitar al punto de acceso una dirección IP. No es necesario que las
dos videoconsolas se conecten al mismo punto de acceso. Internet hace posible que
ambos dispositivos puedan comunicarse aunque se encuentren situados en
ubicaciones remotas.
Figura 3.4. Conexíon en modo infraestructura.
Aunque para explicar ambas conexiones se ha usado como origen y destino una PSP, en la
práctica, tanto el origen como el destino de la comunicación pueden ser cualquier dispositivo
que disponga de una tarjeta de red WI-FI.
El conjunto de librerías del PSPSDK proporciona las funciones necesarias para poder
establecer las conexiones comentadas. Su manejo obliga al programador a conocer diferentes
aspectos sobre el funcionamiento interno de la PSP, por lo que siempre es preferible buscar
alguna librería adicional que disponga de un grado de abstracción mayor.
58
3.4.3.1 Modo ad-hoc.
LTE GE no incluye clases para establecer este tipo de conexiones, pero un usuario conocido
como PSPet (http://changer.blog48.fc2.com) ha desarrollado una serie de librerías a partir del
PSPSDK que permiten establecer conexiones WI-FI. Están diseñadas de manera similar a
como se trabaja con sockets. Existe un ejemplo con todos los archivos necesarios que se
puede descargar desde http://www.gophinx.co.uk/BlackPhoenix/adhoc-examples.rar.
Para poder trabajar con las librerías de PSPet ha sido necesario usar la función adhocSend()
para el envío de paquetes y adhocRecvBlocked() para su recepción. Aunque en el ejemplo se
utilizan adhocSendRecvAck() y adhocRecvRecvAck() con el mismo propósito, durante la
ejecución las confirmaciones no llegan a los destinatiarios y la comunicación se bloquea.
La principal ventaja del modo ad-hoc frente al modo infraestructura es que la carga de
procesamiento es inferior (no se trabaja con datagramas IP), con lo que el tiempo de respuesta
se reduce considerablemente. Por otro lado, requiere que el emisor y el receptor se encuentren
dentro de un radio de acción muy limitado comparado con el conseguido con el modo
infraestructura.
3.4.3.2 Modo infraestructura.
El espacio de nombres Net de LTE GE incluye una serie de clases para el establecimiento de
conexiones en modo infraestructura. Como ocurría en el modo ad-hoc, su diseño es similar al
de los sockets, aunque requiere tener en cuenta ciertas consideraciones propias de LTE GE.
La gestión de los eventos del dispositivo WI-FI se realiza de forma similar a la de los eventos
de la entrada, asignando una función de callback que se encarga de su tratamiento a medida
que estos se generan. Esta función debe heredar de la interfaz INetworkCallback e
implementar las siguientes funciones que serán invocadas a medida que los eventos tengan
lugar:
• OnClose(). Se invoca cuando el socket se cierra.
• OnDataReceive(). Se invoca cuando se reciben datos.
• onConnect(). Se invoca cuando el socket se conecta con éxito a una dirección IP

destino.
• onError(). Se invoca cuando el socket no puede conectarse a la dirección IP destino.
• onWiFiStatusChange(). Se invoca cuando la conexión WI-FI se ha establecido con el

punto de acceso.
Para asignar la función de callback se llama al método initialize() del controlador de red.
Después se pueden crear sockets para una dirección IP destino determinada mediante el
59
método createSocket(). La interfaz ISocket obtenida dispone de todos los métodos para el
envío y recepción de datos.
60
ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA
4. ESPECIFICACIÓN DE REQUISITOS DEL

SISTEMA
4.1 INTRODUCCIÓN
Este capítulo tiene como objetivo presentar la aplicación que se desea desarrollar, los
requisitos que ha de satisfacer y el análisis realizado para cumplir dichos requisitos. Se trata de
una visión descriptiva del proyecto que no tiene en cuenta los aspectos técnicos. Estos son
desarrollados en las secciones correspondientes a la especificación del diseño y las
consideraciones sobre la implementación.
Toda la información recogida a continuación es el resultado de las tareas de concepto y diseño

preliminar. Si bien dentro de los objetivos del proyecto no se especificaban las características
concretas del videojuego, tras la finalización de estas dos tareas se dispone de una descripción
completa del mismo.
4.2 DESCRIPCIÓN GENERAL

El videojuego responde al nombre de Air Warriors y pertenece al género popularmente
conocido como “matamarcianos”. En este tipo de juegos el jugador debe enfrentarse a hordas
de enemigos controlando una nave que se desplaza sobre un escenario. Toda la acción se
desarrolla en un solo plano (desde un punto de vista cenital), dado que en esencia, este género
emplea fundamentalmente gráficos 2D. Sin embargo, Air Warriors trata de aprovechar las
ventajas proporcionados por los gráficos 3D para aportar un entorno físicamente más realista y
complejo, y visualmente más espectacular.
Aunque este tipo de juegos no se caracteriza especialmente por su profundidad argumental, Air
Warriors proporciona una mayor inmersión por parte del jugador incluyendo una historia que
combina diálogos entre diferentes personajes con la acción característica de los
“matamarcianos”. Con ello se fijan unas metas más elaboradas para el jugador, que pasa de
centrarse exclusivamente en avanzar de misión en misión para poner a prueba sus reflejos y
destreza, a desarrollar una trama que le envuelve y sorprende a lo largo del juego.
El juego está estructurado en una serie de misiones secuenciales que hay que completar para
llegar al final del juego. Antes de iniciar una misión, se permite que el jugador explore mediante
una vista en primera persona un mapa de una localización concreta (modo aventura). En estos
61
mapas existen diferentes personajes con los que el jugador puede conversar para obtener
información sobre el argumento del juego. Cada misión sigue el planteamiento introducido por
los “matamarcianos” y presenta diferentes objetivos para su terminación (modo arcade). Por
ejemplo, algunas misiones pueden requerir que el jugador destruya un número concreto de
naves en un tiempo limitado o simplemente que sobreviva con su nave durante un cierto
periodo de tiempo. Después de completar cada misión se presentan unas imágenes en pantalla
a modo de presentación que de manera narrativa desarrollan el guión del juego. En la versión
implementada para este proyecto se incluye una sola misión con los principales elementos del
juego a modo de demostración de la idea global que hay tras el videojuego.
También existe un modo multijugador que abandona el argumento original del videojuego para
proporcionar una acción directa en forma de misiones que se pueden jugar
independientemente con ayuda de otro compañero.
4.3 ELEMENTOS DEL SISTEMA
4.3.1 Opciones y modos de juego
Las tareas de concepto y diseño preliminar pusieron de relevancia un gran número de opciones
y modos de juego. Dado el periodo de desarrollo limitado, muchas de ellas no se incluyen en la
versión actual, aunque se describen a continuación como módulos constituyentes del
videojuego.
• Modo individual. Recoge las diferentes opciones correspondientes al juego individual.

Este modo sigue la campaña de misiones que desarrollan el argumento del juego, con
un principio y un final.
o Continuar. Sin implementar. Permite cargar la última partida salvada sin

necesidad de seleccionarla a través del menú de cargar partida. Para cualquier
jugador ocasional resulta mucho más cómodo usar este método que tener que
pasar por diferentes pantallas para poder empezar a jugar en el último punto
de control en el que se quedó.
o Nueva partida. Inicia una nueva partida. Primero se muestra una introducción
del argumento del videojuego mediante una serie de pantallas que combinan
texto e imágenes. A continuación se pasa a cargar la primera misión del juego,
indicando una breve descripción de los objetivos a cumplir.
o Cargar partida. Sin implementar. Está unida a la de guardar partida. Esta se

emplea para crear puntos de control a los que es posible volver en cualquier
momento mediante la opción de cargar partida. De esta manera, el jugador no
necesita jugar ininterrumpidamente para poder finalizar el videojuego y al
mismo tiempo, su extensión puede ser superior a la duración de la batería de la
PSP.
62
Para favorecer la inmersión del jugador y evitar que este pase a aplicar
exclusivamente una técnica de prueba y error, se restringe la opción de guardar
partida de manera que sólo está disponible después de completar una misión.
• Multijugador. Incluye una serie de opciones que permiten participar a 2 jugadores en

una misma partida. En este caso se abandona la trama desarrollada en el modo
individual y se vuelve a la acción directa del género. Los jugadores cooperan para
hacer frente a los enemigos que aparecen en pantalla, pero sin otro objetivo que lograr
una mayor puntuación o cumplir las condiciones de victoria del escenario.
o Ad-hoc. Sin implementar. La conexión entre las videoconsolas se realiza

directamente sin un punto de acceso intermedio. Una de las videoconsolas
realiza las funciones de servidor y cliente al mismo tiempo, mientras que la otra
se comporta como un cliente.
o Infraestructura. Sin implementar. La conexión entre las videoconsolas se

realiza a través de un punto de acceso intermedio. Las videoconsolas pueden
encontrarse en cualquier ubicación que tenga acceso a Internet, de forma que
se pueden conectar jugadores de diferentes países. Además, el proceso
servidor se puede situar en una tercera máquina para aumentar la velocidad
del intercambio de mensajes entre procesos y reducir la latencia.
o Opciones. Sin implementar. Permite definir el nombre con el que se identifica

al jugador en una partida multijugador. Cuando un jugador comparte una
partida con otro jugador, sus identidades son representadas mediante este
nombre.
• Opciones de juego. Son una serie de opciones que afectan al juego en general, tanto
en el modo individual como en el multijugador.
o Sonido. Permite modificar el volumen de la música y de los efectos especiales

(explosiones, impactos, disparos…).
o Controles. Esta opción se emplea para establecer la relación entre botones y

comandos que el jugador prefiere. La única limitación existente es que el
movimiento de la nave se controla siempre mediante el mando analógico.
Tampoco se puede utilizar la fila de botones que se encuentra debajo de la
pantalla de la PSP.
• Servicios en línea. Consiste en una serie de opciones con las que se trata de
proporcionar un servicio adicional al jugador que permita alargar la vida útil del
videojuego. Todos estos servicios se proporcionan mediante un servidor conectado a
Internet para que cualquier PSP pueda acceder fácilmente a ellos.
o Clasificación. Sin implementar. Se mantiene una lista con las máximas

puntuaciones alcanzadas por los jugadores en el modo multijugador. Tras
63
finalizar un escenario que no pertenezca al modo individual, el jugador puede

decidir enviar su puntuación al servidor de clasificaciones.
o Descargas. Sin implementar. Para acceder a contenido adicional, como

pueden ser nuevos modelos de naves o escenarios. Estos se encuentran
almacenados en un servidor desde el que son transferidos a la PSP.
o Opciones. Sin implementar. Dado que pueden existir varios servidores de

servicios, se dispone de una opción para poder definir la dirección IP del
servidor al que se desea conectar.
4.3.2 Modo aventura
El modo aventura precede a cada misión y permite que el jugador explore algunas de las
localizaciones comentadas en el argumento del videojuego.
4.3.2.1 Acciones del personaje del jugador
El jugador adopta el papel del protagonista del juego y se mueve por el escenario con una vista
en primera persona interactuando con diferentes elementos. Las acciones que puede llevar a
cabo son:
• Desplazarse. La dirección en la que mira el personaje se controla mediante el mando

analógico, mientras que el movimiento se lleva a cabo pulsando los botones de
dirección. En el escenario pueden haber escaleras o planos inclinados por los que el
jugador puede subir o bajar igualmente.
• Interactuar. Para poder interactuar con los elementos del escenario hay que
encontrarse dentro del radio de acción del objetivo. Después de pulsar el botón de
interactuar se mostrará un texto descriptivo con el resultado de la acción realizada por
el jugador.
4.3.2.2 Elementos del juego
Se consideran únicamente dos elementos. Todos ellos tienen un determinado radio de acción,
por lo que pueden ser activados desde una cierta distancia:
• Personajes. Soldados, mecánicos, civiles… Se encuentran situados en distintos

puntos del mapa y al interactuar con ellos entablan una conversación con el jugador.
• Portales. Representan los puntos de salida del mapa. Al caminar a través de ellos se
abandona el escenario y se pasa a otra zona. Son elementos indicativos para el
jugador que no forman parte del mapa.
64
4.3.2.3 HUD
El HUD está formado exclusivamente por un punto de mira que se encuentra en el centro de la
pantalla. Sirve de ayuda al jugador a la hora de seleccionar algún elemento del escenario con
el que desea interactuar.
4.3.2.4 Cámara
La cámara proporciona una vista en primera persona, de manera que al jugador se muestra
aquello que el personaje que está controlando ve desde su posición.
4.3.2.5 Colisiones
El jugador puede colisionar tanto con el escenario como con los personajes que haya en el
mismo. En ambos casos se debe impedir que el jugador atraviese dichos elementos, recreando
un entorno realista.
Los personajes, al no formar parte del escenario, colisionan exclusivamente con las superficies
del mapa.
4.3.3 Modo arcade
En este modo transcurre la acción del juego propiamente dicha. Consta de unos objetivos que
el jugador debe completar para avanzar a la siguiente misión.
4.3.3.1 Acciones de la nave del jugador
El jugador interactúa con el entorno mediante una nave espacial que lleva a cabo diferentes
acciones. Al igual que en el caso de los modos de juego, algunas de estas acciones no han
sido implementadas, pero se recogen igualmente en las siguientes líneas.
• Desplazarse. Mediante el mando analógico el jugador puede mover la nave por el área
de juego. El desplazamiento puede realizarse en cualquier dirección dentro del plano
que representa el área de juego. Si la nave abandona esta región, entonces se bloquea
el movimiento y la nave se detiene. Sólo se bloquea la componente del movimiento que
hace que la nave salga del área del juego, por lo que se permite que se deslice por los
bordes del área de juego.
La nave siempre está orientada hacia la dirección en la que avanza el área de juego.
Cualquier movimiento del mando analógico a la izquierda o derecha se traduce en un
desplazamiento lateral.
• Disparar. A medida que el jugador aprieta el botón de disparo, el armamento de la

nave lanza un proyectil. No basta con mantener pulsado el botón para lanzar varios
proyectiles seguidos, siendo necesario pulsar y soltar el botón repetidamente. Entre
65
cada disparo existe un tiempo de recarga, por lo que la cadencia de disparo no

depende exclusivamente de lo rápido que se pulse el botón.
• Disparo especial. Sin implementar. Además del disparo normal existe un disparo
especial que complementa al anterior. Según la situación en la que se encuentre el
jugador, puede ser conveniente usar uno u otro disparo.
• Siguiente y anterior ítem. Sin implementar. Algunos ítems no se activan en el

momento en el que la nave del jugador pasa sobre ellos. Estos ítems se pueden
guardar de manera que sean utilizados por el jugador cuando realmente los necesita.
Para pasar de un ítem a otro se emplean los controles de siguiente y anterior ítem.
• Usar ítem. Sin implementar. Una vez se ha seleccionado el ítem que se quiere activar,
pulsando el botón correspondiente a esta acción se hace uso del mismo.
• Maniobra evasiva a la derecha y a la izquierda. Sin implementar. Existen

determinadas situaciones en las que la nave del jugador puede verse acorralada por
las naves enemigas. Para esquivar tanto disparos como naves enemigas se pueden
usar maniobras evasivas, mediante las cuales la nave es invulnerable durante un corto
periodo de tiempo. Estas maniobras no pueden utilizarse continuamente, existiendo un
periodo de tiempo de recarga durante el cual permanecen desactivadas.
4.3.3.2 Atributos de las naves
La nave del jugador y las naves enemigas están definidas por una serie de atributos:
• Nivel de escudos. Representa el número de impactos de los diferentes tipos de

disparos que la nave puede recibir antes de ser destruida. Es un valor comprendido
entre 0 y 100. Cuando el nivel de escudos llega a 0 la nave explota y desaparece del
juego. Para el jugador esto representa el fracaso de la misión en juego. No obstante,
existen determinados ítems que recargan el nivel de escudos de la nave del jugador en
una cierta cantidad.
El nivel de escudos inicial de la nave del jugador es considerablemente superior al del

resto de naves enemigas.
• Armamento. Cada tipo de nave tiene un armamento predeterminado, excepto la nave

del jugador. Esta puede modificar su armamento mediante los ítems que van
apareciendo por el escenario. El armamento define el daño y la velocidad de los
proyectiles disparados.
• Velocidad de desplazamiento. Cómo de rápido se desplaza la nave por el área de

juego.
• Tiempo de recarga. Cuánto tiempo debe pasar después de realizar un disparo para
volver a disparar.
66
• Tiempo de bloqueo. Después de una colisión entre naves, cuánto tiempo permanece
la dirección bloqueada hasta que se recupera el control.
• Tiempo de no colisión. Después de una colisión, cuánto tiempo permanece la nave

inalterable por nuevas colisiones.
• Masa. Se emplea para calcular la velocidad con la que nave sale despedida después
de haber colisionado con otra nave. Es un valor comprendido entre 0 y 100, siendo 100
el valor máximo.
La nave del jugador dispone también los siguientes atributos:
• Aceleración de desplazamiento. Cuando la nave se detiene no lo hace bruscamente,

sino que se aplica una deceleración a partir de este valor.
• Ángulo de ladeo. Para dotar de un mayor dinamismo a la nave del jugador, esta se
ladea levemente al desplazarse lateralmente. El ángulo de ladeo indica el ángulo
máximo que puede llegar a alcanzar el ladeo de la nave. Cuando la nave deja de
moverse recupera lentamente su ángulo original.
• Velocidad de ladeo. Cómo de rápido se lleva a cabo el ladeo de la nave.
Por su parte, las naves enemigas también presentan otros atributos a tener en cuenta:
• Cadencia de disparo. Indica cuántos disparos realiza la nave en cada ráfaga. Las
naves enemigas no disparan de manera aleatoria en el tiempo, sino que lo hacen por
ráfagas de un número determinado de disparos.
• Tiempo de recarga total. Es el tiempo que define cada cuánto tiempo se lanza una
ráfaga de disparos.
4.3.3.3 Elementos del juego
A medida que avanza el juego aparecen diferentes elementos que tratan de impedir que el
jugador complete su misión. Otros, por el contrario, proporcionan diferentes ventajas a la nave
del jugador.
Los elementos hostiles al jugador son las naves enemigas y sus disparos. Existen cuatro tipos
de naves enemigas en función de los valores que toman sus atributos. Estos valores han sido
asignados de manera que las naves presenten una serie de fortalezas y debilidades. Así pues,
un tipo concreto de nave puede ser rápida y poco resistente, mientras otra será más lenta pero
contará con un nivel de escudos mayor. Los nombres asignados a las naves están
relacionados con su forma o comportamiento. Son a su vez una manera sencilla de identificar
los diferentes tipos de naves enemigas dentro del universo ficticio del juego:
• Dardo. Nave enemiga básica. Cuenta con un armamento de disparo individual, es

rápida y poco resistente.
67
• Doble dardo. Nave enemiga de mayor potencia de disparo. Cuenta con un armamento
de disparo doble, es lenta y muy resistente.
• Dardo avanzado. Nave enemiga básica mejorada. Dispone de un armamento de

disparo triple, es rápida y tiene un nivel de escudos medio.
• Sembrador de muerte. Nave enemiga especial. Dispone de un armamento de

disparos perseguidores, es rápida y poco resistente. A medida que avanza por el área
de juego suelta una serie de disparos que persiguen a la nave del jugador.
Cada una de estas puede mostrar cuatro comportamientos distintos:
• Avanzar. La nave avanza en línea recta en una determinada dirección.
• Avanzar y girar. La nave avanza en línea recta en una determinada dirección y al cabo
de cierto tiempo gira un número arbitrario de grados cambiando la trayectoria seguida.
Después sigue avanzando en línea recta.
• Avanzar y perseguir. La nave avanza en línea recta en una determinada dirección y al

cabo de cierto tiempo gira hasta que la nueva dirección de desplazamiento apunta
hacia la posición que ocupa la nave del jugador. Este proceso se repite de manera
cíclica.
• Avanzar y desplazarse lateralmente. La nave avanza en línea recta en una

determinada dirección y al cabo de cierto tiempo desvía su trayectoria hasta recorrer
una distancia especificada hacia su izquierda o derecha. Después vuelve a
desplazarse lateralmente en la dirección contraria. Este proceso se repite de manera
cíclica.
Las naves enemigas pueden aparecer desde cualquier borde del área de juego.
Los ítems, por su parte, son elementos que aparecen en el área de juego y pueden ser
activados por el jugador para lograr diferentes ventajas. Hay 3 tipos de ítems:
• Disparo doble. Al ser activado por el jugador modifica el armamento actual de la nave
por otro con un disparo doble de mayor daño. En lugar de lanzar un solo proyectil, se
pasa a disparar dos con trayectorias paralelas.
• Disparo triple. Al ser activado por el jugador modifica el armamento actual de la nave
por otro con un disparo triple. Este disparo triple consta de 3 proyectiles. Uno de ellos
es lanzado en línea recta de acuerdo a la dirección de visión de la nave del jugador.
Los otros dos son desviados un cierto ángulo respecto a la trayectoria del primer
disparo.
• Nivel de escudos extra. Aumenta el nivel de escudos de la nave del jugador en una
determinada cantidad. Mediante este aumento se puede llegar a superar el nivel
máximo de escudos.
68
Otro elemento del entorno es el escenario de fondo que representa dónde tiene lugar la acción.
4.3.3.4 HUD
Mientras el jugador controla la nave dispone de información actualizada en todo momento

sobre el nivel de escudos actual y el tipo de armamento con el que está equipada su nave.
Estos datos se muestran en la parte inferior de la pantalla. Junto a ellos existe una barra
horizontal empleada para visualizar mensajes en forma de texto. Su uso permite, por ejemplo,
crear transmisiones de radio entre los diferentes personajes que intervienen en la trama, con lo
que la propia acción del videojuego puede verse afectada por giros inesperados en el guión. Es
decir, la mecánica del juego no se reduce a pasar de una misión a otra para avanzar en el
argumento, sino que la propia historia acompaña al jugador durante la acción.
4.3.3.5 Cámara
La cámara no proporciona un punto de vista completamente cenital, sino que se desplaza

ligeramente respecto al centro del área de juego para colocarse detrás de la nave del jugador.
Así se logra una mayor sensación de profundidad. Se encuentra situada por encima de la
acción, a una distancia suficiente como para que abarque el área de juego completa y
proporcione una visión global del escenario y sus elementos. Avanza con velocidad constante
por el escenario en línea recta acompañando a la nave del jugador.
4.3.3.6 Colisiones
Se consideran durante el juego las siguientes colisiones:
• Disparos y naves. Los disparos de la nave del jugador sólo afectan a las naves
enemigas, y los de las naves enemigas a la nave del jugador. Cuando un disparo
colisiona con una nave, el disparo desaparece del área de juego y resta al nivel de
escudos de la nave alcanzada el daño que tenía asignado.
• Nave del jugador y naves enemigas. Sólo se consideran colisiones entre la nave del
jugador y las demás naves enemigas, por lo que si dos naves enemigas colisionan no
se ven afectadas de ninguna manera. Una colisión del primer tipo supone que la nave
del jugador y la nave enemiga sean proyectadas en una dirección previamente
calculada. La masa y el vector de velocidad de las naves son tenidos en cuenta para
ello. Después del impacto, ambas naves son invulnerables durante un corto periodo de
tiempo, con lo que no pueden colisionar con cualquier otro elemento del juego.
Además, durante un tiempo inferior al anterior, la dirección de las naves se bloquea,
por lo que estas se desplazan sin control obligatoriamente en la dirección resultante del
impacto sin que puedan siquiera disparar. Los impactos con las naves también reducen
el nivel de escudos.
• Nave del jugador e ítems. Cuando la nave del jugador colisiona con un ítem, este
desaparece y se activa automáticamente. Algunos ítems, como aquellos que cambian
69
el armamento, pueden anular el efecto de otros ítems activados previamente. Por

ejemplo, el jugador activa un ítem y consigue un disparo doble. Después activa otro
ítem que le proporciona un disparo triple, por lo que pierde el disparo doble.
70
ESPECIFICACIÓN DEL DISEÑO
5. ESPECIFICACIÓN DEL DISEÑO
5.1 INTRODUCCIÓN
Este capítulo tiene como objetivo describir la labor de diseño llevada a cabo para desarrollar el
proyecto. Se muestran el diagrama de estados y el diagrama de clases que han sido creados
para dar respuesta a la especificación de requisitos del sistema.
5.2 DIAGRAMA DE ESTADOS

El diseño de un videojuego puede afrontarse desde perspectivas muy diferentes. En este
proyecto se ha optado por hacer uso de una máquina de estados. Se trata de la alternativa más
habitual a la hora de desarrollar un videojuego con una complejidad considerable y una de sus
principales ventajas es que permite organizar el código de una manera intuitiva y ordenada.
Además, se vale de la conocida estrategia de programación de “divide y vencerás”,
distribuyendo la funcionalidad completa del videojuego en varios estados independientes y
fácilmente manejables.
La idea que subyace en el concepto de máquina de estados consiste en considerar la

aplicación como un conjunto de pequeñas aplicaciones. Cada estado es independiente de los
demás e incluye todos los elementos necesarios para proporcionar una funcionalidad concreta.
Por ejemplo, se podría usar un estado para mostrar la introducción del videojuego, otro para
presentar el menú principal y sus distintas opciones, y un último estado para la acción del juego
propiamente dicha. La máquina de estados almacena todos los estados y se encarga de pasar
de uno a otro cuando el programador lo solicita. Evidentemente, en cada instante sólo puede
haber un estado activo que se actualiza cíclicamente.
El diagrama de estados de la figura 5.1 recoge los diferentes estados que atraviesa el juego.
Algunos de ellos, como Multiplayer u OnLineServices no han sido desarrollados y su presencia
en el diagrama es simplemente descriptiva. Cada elemento circular corresponde a un estado,
existiendo un estado inicial y otro final. Las flechas indican qué estados son accesibles desde
cada uno de los estados recogidos.
71
Figura 5.1. Diagrama de estados general.
La descripción de la funcionalidad recogida en cada uno de los es la siguiente:
• MainIntro. Estado inicial. Dibuja en la pantalla una presentación con los nombres de
los desarrolladores del videojuego y el título del mismo.
• MainMenu. Presenta el menú principal con las diferentes opciones que están
disponibles.
• OnePlayer. Presenta otro menú con las opciones correspondientes al modo individual.
• StoryIntroduction. Se accede tras escoger la opción New Game dentro del estado
anterior. Presenta al jugador una serie de imágenes combinadas con texto que narran
la introducción del argumento del juego.
• DemoSelection. Permite seleccionar entre jugar el modo aventura o el modo arcade

del videojuego. Debido a los problemas encontrados durante la implementación, ha
sido necesario ofrecer ambos modos por separado.
• AdventureGame. Se trate de un estado con 2 subestados distintos.
72
Figura 5.2. Diagrama de estados del estado

AdventureGame.
o AdventureGameRunning. Subestado inicial y final. Carga todos los recursos

necesarios para iniciar el modo aventura que precede a la primera misión del
juego. También gestiona la lógica propia de este modo.
o AdventureGameTalking. Representa el establecimiento de una conversación

con otro personaje del modo aventura.
• ArcadeGame. Se trata de un estado con 4 subestados distintos.
Figura 5.3. Diagrama de estados del estado ArcadeGame.
o Mission1Loading. Subestado inicial. Carga todos los recursos (texturas,

fuentes, modelos…) necesarios para iniciar la primera misión del juego.
También es responsable de inicializar las estructuras de datos (eventos,
escenario, naves…) con toda la información relativa a la primer misión.
73
o ArcadeGameRunning. Gestiona la acción del modo arcade individual. Incluye

toda la lógica de este modo.
o ArcadePause. Detiene temporalmente la acción del juego.
o GameOver. Subestado final. Se accede cuando el modo arcade ha terminado,

ya sea porque el jugador ha fracasado en el cumplimiento de los objetivos de la
misión o porque ha tenido éxito. Supone el final del estado ArcadeGame.
• Multiplayer. Muestra las opciones del modo multijugador. Estas opciones no han sido
implementadas en la versión actual del videojuego, por lo que desde este estado sólo
es posible volver al anterior.
• GameOptions. Muestra las opciones comunes al modo individual y multijugador.
• ControlOptions. Permite modificar la asignación de botones a los diferentes controles

de la nave del jugador.
• SoundOptions. Permite modificar el nivel de volumen tanto de la música como de los

sonidos especiales.
• OnLineServices. Muestra las opciones de los servicios en línea. Estas opciones no

han sido implementadas en la versión actual del videojuego, por lo que desde este
estado sólo es posible volver al anterior.
• Quit. Estado final. Presenta una pantalla de confirmación para abandonar la aplicación.
5.3 DIAGRAMA DE CLASES

Un buen diseño para las clases que integran un videojuego resulta esencial teniendo en cuenta
el elevado número de elementos conceptuales que se manejan. Al final del capítulo se
presentan distintos diagramas de clases que en conjunto dan forma al diagrama de clases
global de la aplicación. En cada uno de ellos sólo se han incluido los atributos y métodos más
representativos, omitiendo además cualquier referencia a las clases de la librería LTE GE. En
algunos diagramas ciertas clases aparecen sombreadas. Con esto se quiere indica que dichas
clases son descritas en otro subapartado dentro de este mismo punto, pero su presencia en el
diagrama es importante para comprender las demás clases.
Existe una constante de diseño que se repite en todas las clases y que proporciona una
estructura común:
• Métodos setXXX(). Cada clase se concibe como un elemento con un número

determinado de parámetros. Todos estos parámetros se definen mediante métodos
setXXX() después de llamar al constructor de la clase.
• Método ini(). Una vez que se han especificado todos los parámetros que se van a
emplear, se invoca el método ini() de la clase. Este método inicializa el objeto
74
comprobando que se hayan asignado los parámetros mínimos necesarios, que sus
valores sean correctos y realizando otras operaciones adicionales.
• Método reini(). Dada que su utilización no es tan básica como en el caso del método
ini(), se omite en muchas de las clases desarrolladas. Se emplea en el caso de que un
objeto pueda experimentar varias inicializaciones a lo largo de su vida. Generalmente
se invoca después de haber llamado al método reend().
• Método update(). Actualiza la lógica del objeto. Este método se invoca en cada ciclo
de ejecución de la aplicación pasando como parámetro el tiempo transcurrido en
segundos respecto al ciclo anterior. Este tiempo es utilizado si la lógica del objeto
depende del tiempo transcurrido.
• Método reend(). Está directamente relacionado con el método reini(). Se usa cuando
un objeto puede tener varias finalizaciones.
• Método end(). Finaliza el objeto. Realiza unas operaciones similares a las que haría el
destructor de la clase. Como ocurre entre reini() y reend(), el método end() se invoca
después de haber inicializado con éxito el objeto. Libera la memoria reservada por el
objeto y lleva a cabo las operaciones necesarias para que la aplicación pueda seguir
funcionando correctamente una vez haya desaparecido.
5.3.1 Estados y máquina de estados
5.3.1.1 Clase State
Como se comentaba en la presentación del diagrama de estados, el funcionamiento de la

aplicación se basa en la actualización de una serie de estados. Cada estado incluye todas las
clases y estructuras de datos que necesita para proporcionar su funcionalidad, de manera que
son independientes entre si.
Los estados están representados mediante la clase State. Es una clase abstracta de la que
heredan las demás clases que representan cada uno de los estados que puede tener el
videojuego. Son estas clases las que incluyen el código concreto para los métodos ini(), reini(),
update(), render(), reend() y end(). Para mantener una mayor claridad en el diagrama de
clases, sólo se han indicado estos métodos para la clase MainIntroState, pero todas las demás
siguen la misma estructura.
Todos los estados tienen una referencia a la máquina de estados en la que están incluidos, por
lo que en cualquier instante pueden solicitar el cambio a un nuevo estado.
5.3.1.2 Clase StateMachine
La máquina de estados es la responsable de gestionar los diferentes estados. Al inicializarse

también inicializa los estados que contiene. Lo mismo ocurre al finalizar la máquina de estados,
momento en el que se finalizan todos sus estados. La lógica de la aplicación se actualiza
75
invocando el método update(), que se encarga a su vez de actualizar el estado en curso.

Cuando se cambia de estado, la máquina de estados invoca el método reend() del estado
actual y el método reini() del nuevo estado, que pasa a ser el nuevo estado actual.
Se puede representar un estado con varios subestados, como ocurre en el caso de

ArcadeGameState. Para ello, este estado dispone de su propia máquina de estados con la que
gestiona sus subestados.
5.3.2 Clases base elementales
5.3.2.1 Clase Object3D
La clase Object3D representa cualquier elemento que pueda formar parte del mundo y por
tanto visualizarse en la pantalla. Como se aprecia en el diagrama, todos los objetos que
aparecen en el mundo heredan de la clase Object3D. Es una clase abstracta que incluye los
métodos necesarios para realizar las operaciones básicas de manipulación de objetos 3D:
trasladar, rotar y escalar. También presenta un referencia al objeto padre, siempre que se haya
especificado alguno. De esta manera, las transformaciones realizadas sobre un determinado
objeto Object3D pueden propagarse a sus hijos.
Otro aspecto importante es la inclusión de una lista de Behaviours. Un objeto Object3D se

concibe como un elemento gráfico al que se le pueden aplicar diferentes comportamientos para
modificar su lógica. Esto proporciona una gran flexibilidad a la hora de introducir cambios a la
lógica de los objetos y al mismo tiempo permite reutilizar en mayor medida el código generado.
5.3.2.2 Clase GameObject3D
Mediante la clase GameObject3D se diferencian aquellos objetos que están ligados al área de
juego (naves, ítems, disparos…) de los que no intervienen en la acción propiamente dicha y
con los cuales el jugador no interactúa (elementos del menú, estelas de naves, cámaras…).
5.3.3 Elementos del menú
Los diferentes menús con los que se navega por las diferentes opciones de la aplicación son
generados a partir de una serie de clases. Estas pueden ser configuradas para añadir un
determinado número de opciones, así como los estados a los que dan lugar si son activadas
dichas opciones.
5.3.3.1 Clase SelectionBallMenu
Actúa como un contenedor que agrupa todos los elementos que conforman el menú: un
conjunto de objetos de tipo SelectionBall y una imagen de fondo. También se encarga de
gestionar los eventos generados por el usuario a medida que pulsa los botones de la
videoconsola para pasar de una opción a otra.
76
5.3.3.2 Clases SelectionBall y LightingSelectionBall
La clase SelectionBall representa una opción determinada dentro del menú. Va acompañada
del nombre del siguiente estado que debe ejecutarse en caso de seleccionarse dicha opción.
LightingSeleccionBall es una especialización de la clase SelectionBall. Incluye un objeto de tipo

LightingBillboard con una función básicamente decorativa, pero que además sirve de referencia
visual para indicar cuál es la opción seleccionada en cada instante.
5.3.3.3 Clases LightingBillboard y FlyCircleLightingBillboard
La clase LightingBillboard añade al mundo un objeto que representa una luz mediante un
billboard. Tiene asignada una luz dinámica que ilumina a otros objetos del mundo. Dispone de
una gran variedad de parámetros para definir tanto el tamaño como la apariencia del billboard.
FlyCircleLightingBillboard es una especialización de la clase LightingBillboard. No sólo añade

un objeto de tipo LightingBillboard al mundo, sino que además hace que rote alrededor de otro
objeto Object3D que se le indique.
5.3.3.4 Clase TexturedBox
Permite visualizar en la pantalla un plano con una textura. Se emplea para mostrar los títulos
de las diferentes opciones del menú.
5.3.4 Comportamientos
Una de las decisiones de diseño más importantes ha sido la inclusión de los comportamientos.
Cada comportamiento representa un fragmento de lógica que puede ser aplicado en principio a
cualquier objeto de tipo Object3D que disponga de los parámetros necesarios.
5.3.4.1 Clase Behaviour
Es la clase base para todos los demás comportamientos. El atributo priority indica la prioridad
del comportamiento y permite establecer relaciones de dependencia entre los
comportamientos. De esta manera, cuando un Object3D actualice sus comportamientos, los
que tengan un valor de prioridad más bajo se actualizarán antes que el resto de
comportamientos.
5.3.4.2 Clases ObjectBehaviour, GameBehaviour y

PlayerSpaceshipBehaviour
Cada comportamiento tiene un atributo target que referencia al objeto al que afecta. Como no
todos los comportamientos son aplicables a objetos de tipo Object3D, en función de la
naturaleza de este atributo target se presentan 3 clases abstractas derivadas de Behaviour:
• ObjectBehaviour para los comportamientos que afectan a objetos Object3D.
77
• GameBehaviour para los comportamientos que afectan a objetos GameObject3D.
• PlayerSpaceshipBehaviour para los comportamientos que afectan a objetos

PlayerSpaceship.
5.3.4.3 Clase NormalFireBehaviour
Gestiona el disparo de las naves enemigas. Se encarga de determinar cuándo debe disparar
una nave enemiga y controla el número de disparos que lanza.
5.3.4.4 Clase TurningBehaviour
Gira un objeto un número determinado de grados al cabo de cierto tiempo. El objeto no rota
sobre sí mismo, sino que modifica su dirección de desplazamiento a medida que gira, con lo
que describe una curva. Una vez ha girado el ángulo indicado, sigue avanzando en la nueva
dirección de movimiento.
5.3.4.5 Clase LateralTranslationBehaviour
Desplaza lateralmente un objeto cada cierto tiempo. La dirección del desplazamiento lateral se
calcula rotando el vector de dirección un determinado número de grados. El objeto se mueve
en la nueva dirección hasta cubrir una cierta distancia. Después vuelve a rotar el vector original
cambiando de sentido el giro del ángulo, con lo que vuelve al eje que seguía inicialmente. Este
proceso se repite de manera cíclica.
5.3.4.6 Clase FitToGameAreaBehaviour
Sólo permite que el objeto se desplace dentro del área de juego establecida. Si en algún
momento intenta abandonar este área, el objeto se detiene. Se emplea para que la nave del
jugador limite su movimiento al área de juego.
5.3.4.7 Clases ActivatingBehaviour y

MoveAfterActivatingBehaviour
La clase ActivatingBehaviour toma un conjunto de comportamientos y les aplica el siguiente

tratamiento. Primero los desactiva y espera un determinado periodo de tiempo. Transcurrido el
mismo, activa todos los comportamientos que previamente había desactivado.
La clase MoveAfterActivatingBehaviour es una especialización de la anterior. Además de

activar los comportamientos desactivados, restablece la dirección de desplazamiento original
del objeto. Se utiliza para bloquear temporalmente la dirección de las naves después de una
colisión.
78
5.3.4.8 Clase PursuitBehaviour
Hace que un objeto persiga a otro cada cierto tiempo. Para ello se modifica el vector de
dirección del objeto perseguidor hasta que apunte hacia la posición que ocupa el objetivo. Este
proceso se repite cíclicamente.
5.3.4.9 Clase TiltingBehaviour
Ladea un objeto a medida que se desplaza lateralmente. El ladeo es gradual, de manera que la
vertical del objeto rota en la dirección en la que se desplaza lateralmente hasta alcanzar un
ángulo máximo. Si el movimiento lateral desaparece, la vertical del objeto vuelve a tomar su
valor original. Se utiliza para lograr una reacción más dinámica de la nave del jugador.
5.3.4.10 Clase DeceleratingBehaviour
Si la velocidad del objeto es mayor que un valor de referencia dado, se aplica una aceleración
negativa al movimiento del objeto hasta que su velocidad alcanza dicho valor. Se emplea para
que la nave del jugador no se detenga bruscamente cuando se deja de mover el mando
analógico. La nave se desplaza suavemente una corta distancia hasta que alcanza su
velocidad mínima.
5.3.4.11 Clases ChangeFactionBehaviour y

ColouredChangeFactionBehaviour
La clase ChangeFactionBehaviour cambia la facción a la que pertenece un objeto

GameObjet3D después de un cierto tiempo. Cuando dos naves colisionan se cambia
temporalmente su facción a otra contra la que no se comprueban colisiones. Mediante este
comportamiento vuelven a su facción original al cabo de un número determinado de segundos
La clase ColouredChangeFactionBehaviour es una especialización de la anterior. Se comporta

como ChangeFactionBehaviour y además colorea el modelo asociado al GameObjetc3D al que
se aplica mientras transcurre el tiempo necesario para que se dé el cambio de facción.
5.3.5 Juego
Comprende las diferentes clases que proporcionan la funcionalidad básica para el modo arcade
y aventura.
5.3.5.1 Clase Game
La clase Game actualiza uno por uno todos los objetos del juego. Dispone de una lista de
objetos CollisionFaction que representa el mundo del juego. Se trata de una clase abstracta,
puesto que se considera que determinados modos de juego pueden necesitar una gestión
diferente, como ocurre con ArcadeGame y AdventureGame. Entre sus métodos cabe destacar
draw2D(), utilizado para dibujar el HUD en la pantalla después de haber dibujado todos los
elementos de la escena.
79
5.3.5.2 Clase CollisionFaction
El mundo está organizado en un conjunto de objetos CollisionFaction. Esta clasificación facilita

la labor del gestor de colisiones y permite evitar comprobaciones de colisiones innecesarias
mejorando el rendimiento de la aplicación. Un objeto CollisionFaction representa
conceptualmente una facción de objetos que no colisionan entre sí, pero que comparten las
mismas facciones contra las que pueden colisionar. Para ellos se mantienen dos listas de
objetos: los que forman parte de la facción y aquellos con los que se puede colisionar.
5.3.5.3 Clase CollisionController
El gestor de colisiones explora las diferentes facciones de objetos para comprobar si existen o
no colisiones entre ellos. Como tal, no incluye lógica alguna más que la correspondiente al
recorrido de las diferentes listas. Para cada par de objetos que puedan colisionar invoca al
método update() del CollisionManager que se le haya asignado.
5.3.5.4 Clases CollisionManager, ArcadeCollisionManager y

AdventureCollisionManager
La gestión real de las colisiones con la correspondiente detección y respuesta es llevada a

cabo por el ArcadeCollisionManager y el AdventureCollisionManager. Estas clases incluyen las
operaciones a llevar a cabo para cada posible colisión entre objetos de diferentes facciones.
ArcadeCollisionManager tiene como atributo una referencia al objeto ArcadeGame para señalar
el final del juego si como resultado de una colisión la nave del jugador es destruida.
En el caso de AdventureCollisionManager, dado que en el modo aventura la mayor parte de la

gestión de colisiones se deja en manos del propio motor (LTE GE), la lógica incluida se limita a
detectar cuándo el jugador ha llegado a un punto de salida del mapa.
5.3.5.5 Clases GameHUD y ArcadeGameHUD
La clase GameHUD es el HUD básico para los diferentes modos de juego que pueda tener la
aplicación. Está formado por una imagen que se superpone a la escena y una fuente para
poder escribir los datos correspondientes. El método draw() es el utilizado para dibujar todos
estos elementos en la pantalla.
ArcadeGameHUD es el HUD empleado en el modo arcade individual. Además de los

elementos del GameHUD incluye una referencia a la nave del jugador para poder visualizar su
nivel de escudos y armamento actual. También dispone de los métodos necesarios para que se
puedan dibujar las diferentes transmisiones de radio contenidas en los objetos
RadioArcadeGameEvent.
80
5.3.6 Juego arcade y aventura
5.3.6.1 Clases ArcadeGame y AdventureGame
ArcadeGame agrupa y actualiza todos los objetos necesarios para que el modo arcade
funcione de acuerdo a los requisitos: gestor de eventos del juego, escenario, HUD y gestor de
colisiones.
AdventureGame es la clase equivalente a ArcadeGame para el modo aventura. Contiene los

elementos precisos para que el juego se actualice correctamente: escenario, HUD y gestor de
colisiones.
5.3.6.2 Clase EnemySpaceshipGenerator
Clase factoría que permite crear objetos de diferentes tipos de naves enemigas invocando
cualquiera de sus métodos: generateEnemySpaceship(), generatePursuitEnemySpaceship(),
generateTurningEnemySpaceship() o generateLateralEnemySpaceship(). Cada uno de estos
incluye una serie de parámetros descriptivos para configurar las características básicas de las
naves sin tener que asignar dentro de lo posible valores numéricos.
5.3.6.3 Clases ArcadeGameBackground, TerrainGenerator y

FlyingCamera
La clase ArcadeGameBackground agrupa los diferentes elementos que constituyen el

escenario en el que tiene lugar la acción del modo arcade. Este consiste en un terreno irregular
por el que se desplaza la cámara a una velocidad constante. El terreno se genera mediante un
objeto de tipo TerrainGenerator, mientras que el la cámara y su movimiento se gestionan con
un objeto FlyingCamera.
5.3.7 Naves (modo arcade)
Todas las clases que representan los distintos tipos de naves del juego hacen un uso
exhaustivo de los comportamientos. En su inicialización, cada uno de estos objetos añade los
comportamientos que lo distinguen de los demás.
5.3.7.1 Clase Spaceship
Clase abstracta que contiene todos los atributos comunes tanto a las naves enemigas como a
la nave del jugador. Dispone de un gran número de parámetros que permiten configurar
diferentes tipos de naves.
5.3.7.2 Clase PlayerSpaceship
Representa la nave que controla el jugador. Al inicializarse crea y añade los siguientes
comportamientos a su lista de comportamientos: TiltingBehaviour, FitToGameAreaBehaviour,
PlayerControllerdSpaceshipBehaviour y DeceletaringBehaviour. También dispone de un objeto
81
de tipo de Observable, de forma que otros objetos puedan subscribirse a la nave del jugador y
recibir notificaciones de esta. Esto resulta necesario cuando la nave es destruida y otros
objetos que mantenían una referencia a ella no deben seguir utilizándola. Es el caso de las
naves o disparos que persiguen a la nave del jugador y del HUD que visualiza su nivel de
escudos y armamento.
5.3.7.3 Clases EnemySpaceship, PursuitEnemySpaceship,

TurningEnemySpaceship y LateralEnemySpaceship
Todas estas clases son diferentes tipos de naves enemigas. Se diferencian en los
comportamientos que incluyen al inicializarse. EnemySpaceship, de la que derivan las demás,
es una nave enemiga básica que dispone del comportamiento NormalFireBehaviour.
PursuitEnemySpaceship, TurningEnemySpaceship y LateralEnemySpaceship añaden además
respectivamente los comportamientos PursuitBehaviour, TurningBehaviour y
LateralTranslationBehaviour.
5.3.7.4 Clases Tail y EnemySpaceshipTail
Se emplean para gestionar las estelas que generan las naves al desplazarse. Estas son
creadas mediante un sistema de partículas. La clase EnemySpaceshipTail se crea para añadir
la estela a las naves enemigas. La diferencia con la clase Tail se encuentra en que esta al
finalizarse destruye el sistema de partículas haciendo que la estela no pueda volver a ser
utilizadas. EnemySpaceshipTail controla el número de instancias de su tipo que han sido
creadas y no finaliza la estela hasta la última instancia.
5.3.8 Armamento y disparos (modo arcade)
Las naves creadas en la aplicación necesitan de un armamento para que su inicialización sea
correcta. Esta jerarquía de clases es responsable de crear los objetos de tipo de Shot y
añadirlos al mundo en la posición correcta respecto a la nave que dispara.
5.3.8.1 Clase Weapons
Es la clase base de la que heredan las demás clases de armamentos. Entre sus parámetros se
encuentran la velocidad y el daño de los disparos. Estos valores se asignan a los objetos Shot
en el momento de su creación. También dispone de una referencia a la nave que tiene
asignado este armamento. De esta se obtiene la posición del mundo en la que deben colocarse
inicialmente los disparos. Este proceso es dependiente de la geometría de cada nave concreta
y de dónde tenga físicamente situados esta los cañones. Por ello se realiza dentro del método
abstracto fire() en las clases hojas.
5.3.8.2 Clases LinearCanon y LockingCanon
Ambas clases recogen operaciones comunes a diferentes tipos de armamentos. LinearCanon

es para los armamentos (xxxSingleCanon y xxxDualCanon) que lanzan proyectiles que siguen
82
siempre la dirección de visión que tenía la nave en el momento del disparo. LockingCanon es el
equivalente para los armamentos que lanzan proyectiles que persiguen un objetivo.
5.3.8.3 Clases DartSingleCanon, DartDualCanon,

DartTripleCanon y DartLockingCanon
Son las clases responsables de disparar los diferentes tipos de armamentos en las naves
enemigas. Al invocar el método fire() en cada una de ellas se crea un cierto número de
disparos del tipo correspondiente que se colocan en el mundo teniendo en cuenta la geometría
de la nave.
5.3.8.4 Clases W01SingleCanon, W01DoubleCanon y

W01TripleCanon
Son las clases responsables de disparar los diferentes tipos de armamentos en la nave del
jugador.
5.3.8.5 Clases Shot y PursuitShot
Representan los disparos que lanzan las naves. Son tratados como objetos independientes del
objeto Weapons que los crea. La clase PursuitShot además incluye un comportamiento
PursuitBehaviour para que el disparo persiga un determinado objetivo.
5.3.9 Items, explosiones (modo arcade) y portales (modo aventura)
Además de los disparos y naves, el área de juego incluye otros dos tipos elementos: ítems y
explosiones.
5.3.9.1 Clase Item
Es la clase base para los demás ítems del juego. Todos los ítems incluidos afectan
exclusivamente a la nave del jugador, por lo que la clase cuenta con una referencia a un objeto
de tipo PlayerSpaceship. El método abstracto activate() es el encargado de aplicar los efectos
del ítem a la nave del jugador.
5.3.9.2 Clases ExtraShieldsItem, DualCanonItem y

TripleCanonItem
Son las clases de los ítems disponibles en el modo arcade. ExtraShieldsItem incrementa el
nivel de escudos de la nave del jugador, mientras que DualCanonItem y TripleCanonItem
cambian el armamento actual de la nave.
5.3.9.3 Clase ExplosionBillboard
Es una clase factoría que crea objetos de tipo ExplosionBillboard. Consisten en una secuencia
de imágenes tratadas como un billboard animado, por lo que al ser reproducidas en el juego
83
simulan el efecto visual producido por una explosión. Las explosiones se crean mediante el
método estático createExplosionAt(), que permite definir además la posición inicial y las
dimensiones de la explosión.
5.3.9.4 Clase PortalBillboard
Es una clase factoría similar a ExplosionBillboard, pero empleada para simular el efecto visual
producido por un portal. Se utiliza en el modo aventura par aseñalar el punto del mapa por el
que el jugador puede abandonar el escenario.
5.3.10 Gestión de eventos (modo arcade)
Una vez el modo arcade ha comenzado, la acción se modifica mediante una serie de eventos
generados a medida que transcurre el tiempo. Cada evento puede ser de una naturaleza muy
variada, pero todos se conciben como un conjunto de operaciones que deben hacerse durante
un espacio de tiempo limitado. Estos eventos son gestionados mediante la jerarquía de clases
presentada en la figura 5.11.
5.3.10.1 Clase ArcadeGameEventController
Contiene todos los eventos que pueden afectar al juego y comprueba al actualizarse si algunos
de estos eventos deben ser disparados. Para ello se fija en el tiempo de disparo que cada
evento tiene asignado. También se encarga de dar el tratamiento adecuado a los diferentes
tipos de eventos. Para los ArcadeGameFireForgetEvent, dado que una vez disparados no
vuelven a ejecutarse, los finaliza. En el caso de los ArcadeGameContinuousEvent, sigue
actualizándolos una vez se han disparado hasta que el propio evento indique que puede ser
finalizado.
5.3.10.2 Clase ArcadeGameEvent
Es la clase base para los diferentes tipos de eventos del modo arcade. El atributo triggerTime
es la cantidad de segundos que tienen que pasar desde que el juego comienza para que el
evento pueda dispararse. También dispone de un identificador para diferenciar entre los
eventos que sólo se actualizan una vez y los eventos continuos.
5.3.10.3 Clases ArcadeGameFireForgetEvent y

ArcadeGameContinuousEvent
El gestor de eventos maneja dos tipos de eventos. Los eventos que sólo se actualizan una vez,
ArcadeGameFireForgetEvent, y los que se actualizan indefinidamente hasta que se indique lo
contrario, ArcadeGameContinuousEvent.
5.3.10.4 Clase CreationArcadeGameEvent
Este evento es el responsable de que las naves enemigas y los ítems vayan apareciendo en el
área de juego a medida que transcurre el tiempo. Presenta una lista objetos de tipo Object3D
84
que inicializa en el momento en el que se dispara el evento. Es entonces cuando cada uno de
estos objetos se añade al mundo y a la escena.
5.3.10.5 Clase MissionCompletedArcadeGameEvent
Este evento se encarga de indicar a la clase que gestiona el juego, ArcadeGame, cuándo se ha
completado la misión en curso. Se trata de un evento continuo dado que para la misión
presentada en la versión actual del juego, la condición de victoria consiste en que a partir del
instante en que se dispara el evento no existan naves enemigas en el mundo.
5.3.10.6 Clase RadioArcadeGameEvent
Las transmisiones de radio que pueden producirse mientras transcurre la acción se llevan a
cabo mediante la funcionalidad proporcionada por esta clase. Almacena de manera ordenada
tanto el texto que debe mostrarse en pantalla como la imagen que debe acompañarlo. También
el tiempo durante el cual cada fragmento de transmisión debe visualizarse. Las transmisiones
se realizan sobre el HUD definido para el juego, por lo que el evento mantiene una referencia a
un objeto ArcadeGameHUD. Una vez se ha visualizado la transmisión completa el evento se
marca como finalizado.
5.3.11 Gestión del motor y de los eventos de la entrada y del GUI
5.3.11.1 Clases EngineController y MyEventReceiver
La funcionalidad proporcionada por LTE GE es accedida mediante la clase EngineController.

Dado su uso exhaustivo por la mayoría de las clases, presenta referencias estáticas a todos los
elementos básicos del motor: controlador de vídeo, sistema de ficheros, gestor del GUI, gestor
de la escena, controlador del cursor y controlador de sonido entre otros.
MyEventReceiver es la clase que se pasa al motor cuando se inicializa para gestionar los
eventos que detecta tanto de la entrada como de los elementos del GUI que incorpora. En el
método OnEvent() se proporciona la respuesta correspondiente a cada evento posible. Si bien
es posible sustituir la clase MyEventReceiver por un gestor adecuado a cada estado del juego,
se ha optado por otra solución. MyEventReceiver registra en la clase EventController qué
eventos se han producido. Así, basta consultar este controlador de eventos dentro de cada
estado para saber si un determinado evento ha tenido lugar o no.
5.3.11.2 Clase EventController
Presenta un mapa de pares de de nombres de eventos y objetos EventValue. A partir del

nombre de un evento permite acceder a su información asociada, entre la que se indica si el
evento se ha producido o no.
El método restore() debe ser invocado al finalizar cada ciclo de la aplicación para marcar todos
los eventos como no producidos.
85
5.3.11.3 Clase EventValue
Es la información asociada a cada evento. El atributo value se utiliza generalmente para

consultar si un evento se ha producido (un valor distinto de cero) o no (cero). Además puede
emplearse para transmitir otra información, como en el caso de los eventos relativos a la
posición del cursor en la pantalla. Para estos, value indica cuáles son las coordenadas del
cursor en cada uno de los ejes XY.
5.3.11.4 Clases InputEventValue y GUIEventValue
La clase InputEventValue representa todos los eventos relacionados con la entrada de la

videoconsola. Es decir, la pulsación de los botones o el movimiento del mando analógico y del
cursor. GUIEventValue se emplea para guardar información relativa a los eventos de los
elementos del GUI que incluye LTE GE. Estos eventos son genéricos, como haber movido una
barra de desplazamiento o marcado un botón de selección. Para poder identificar el elemento
del GUI concreto con el que se ha interaccionado, la clase GUIEventValue dispone de un
atributo caller.
5.3.12 Personajes (modo aventura)
5.3.12.1 Clase AdventureGuy
AdventureGuy es la clase base de la que heredan PlayerControlledGuy y TalkingGuy. Tiene

una serie de atributos empleados por el gestor de colisiones de LTE GE.
5.3.12.2 Clases PlayerControlledGuy y TalkingGuy
La clase PlayerControlledGuy representa al personaje controlado por el jugador. Su método

update() se encarga de comprobar si se está interactuando con algún personaje del mapa y
solicita el cambio al estado AdventureGameTalkingState.
TalkingGuy se emplea para los personajes del mapa con los que el jugador puede interactuar y
que generan una conversación. El atributo message es el texto que se visualiza en pantalla
para representar la conversación.
5.3.13 Observer
También se ha implementado el conocido patrón observador para que cuando la nave del
jugador sea destruida, todos los objetos que la estuvieran referenciando sean notificados de
que esa referencia ha dejado de ser válida.
5.3.13.1 Clase Observable
El objeto al que se suscriben los observadores tendrá un objeto de este tipo. Mediante el
método notifyObservers() notifica a todos sus suscriptores que ha ocurrido un determinado
evento. Los observadores, por su parte, también mantendrán una referencia a este objeto
86
Observable para suscribirse y desuscribirse si fuera necesario. En el caso de las naves

enemigas que persiguen a la nave del jugador esto ocurrirá si son destruidas antes que la nave
del jugador.
5.3.13.2 Clases Observer y DeleteObserver
La clase Observer es una clase abstracta de la que deriva el objeto DeleteObserver. Se

pueden añadir observadores que lleven a cabo diferentes operaciones al recibir la notificación
correspondiente. En el caso de DeleteObserver es suficiente con señalar mediante el atributo
deleted que el objeto observado ha sido destruido.
5.3.14 Otras clases auxiliares
5.3.14.1 Clase MessageWindow
Se vale de los elementos del GUI proporcionados por LTE GE para mostrar una ventana
centrada en la pantalla con el texto indicado. Se utiliza fundamentalmente para mostrar
mensajes al usuario.
5.3.14.2 Clase LoadingScreen
Es la clase que se usa para mostrar la pantalla de carga mientras se inicia una misión del
juego. Está formada por una imagen de fondo y un texto que es modificado para indicar el
estado del proceso de carga. También hay que indicar un determinado periodo de tiempo, al
cabo del cual se completa la carga. Si entonces se invoca el método update(), se devuelve el
valor false. Si se hace durante la carga, devuelve true.
5.3.14.3 Clase TimeController
El tiempo interviene en la actualización de la mayor parte de los elementos del juego. La clase
TimeController se encarga de acceder al reloj interno de la PSP calcular el tiempo transcurrido
respecto al ciclo anterior. Este es devuelto cada vez que se invoca el método tick().
5.3.14.4 Clase GameUtils
Incluye una serie de métodos estáticos que pueden ser utilizados por diferentes clases. Uno de
los más útiles es el método logError(), que permite escribir en un fichero de texto una cadena
de caracteres. Una de las técnicas más prácticas para depurar errores de ejecución consiste en
realizar sucesivas invocaciones a logError() para conocer el estado de la aplicación en distintos
puntos del código.
5.3.14.5 Clases SoundController y SoundFader
Aunque LTE GE incluye su propia clase para gestionar el sonido, se ha creado una clase
SoundController que proporciona algunas características adicionales, como el fundido de
87
sonido. Para ello incluye la clase SoundFader, que o bien aumenta el volumen de un sonido
hasta alcanzar el nivel especificado, o lo decrementa hasta que sea nulo.
La clase SoundController también se encarga de la gestión de los sonidos, cargándolos en

memoria, reproduciéndolos y liberando la memoria cuando ya no se usan más.
5.3.14.6 Clase StoryTeller
Reproduce una presentación formada por una secuencia de imágenes que se van mostrando
en la pantalla de la PSP. El paso de una imagen a otra se lleva a cabo mediante un fundido de
pantalla. Además, la presentación puede ir acompañada por un determinado archivo de sonido
que es eliminado al final de la misma.
5.3.14.7 Clase GameParameters
Incluye todos los parámetros utilizados por el juego. Consta de un conjunto de atributos
estáticos que definen diferentes parámetros del juego, como el nivel de escudos de las naves
enemigas o la velocidad a la que se desplaza la cámara.
5.3.14.8 Clase FilePaths
Incluye las rutas a todos los recursos empleados en la aplicación: imágenes, modelos y
sonidos.
5.4 DISEÑO PRELIMINAR DEL MODO MULTIJUGADOR

La información recogida a continuación no ha sido utilizada en la implementación de la
aplicación. Como su correcto funcionamiento no ha sido verificado, se incluye en un apartado
separado del resto del diseño.
5.4.1 Limitaciones de LTE GE
LTE GE oculta al programador el proceso de creación del hilo de ejecución de la PSP. En su

lugar proporciona una función que puede ser tratada como la función main de cualquier
aplicación escrita en C++. El principal problema reside en que dicha función es cargada por
LTE GE en un hilo que trabaja en modo usuario. Para utilizar las funciones del PSPSDK que
permiten manejar el dispositivo WI-FI hay que cargar una serie de módulos, siendo
indispensable hacerlo en modo kernel.
Por tanto, resulta imposible añadir nuevas clases para establecer conexiones en modo ad-hoc
y el único modo disponible es el infraestructura. No obstante, la funcionalidad que las clases de
LTE GE ofrecen es también limitada. No se proporcionan métodos para crear sockets que
escuchen un puerto determinado de la PSP, por lo que no se pueden establecer conexiones
entre dos videoconsolas. Para que puedan comunicarse, se necesita un proceso servidor
externo que actúe de intermediario.
88
5.4.2 Modo multijugador
El modo multijugador diseñado permite que dos jugadores puedan participar cooperativamente
en el modo arcade. Cada jugador controla una nave y las acciones llevadas a cabo en una de
las videoconsolas se visualizan igualmente en la otra.
Existen distintas técnicas para llevar a la práctica esta idea. En este caso se analiza una de las
más sencillas y que tiene como requisito indispensable un tiempo de respuesta muy reducido
en el envío y recepción de paquetes. Esto se puede conseguir mediante una conexión ad-hoc o
si la comunicación entre las videoconsolas se realiza en una red local.
Uno de los jugadores actúa de servidor y marca en cada ciclo de juego cuál es el tiempo que
ha transcurrido. La otra PSP se comporta inicialmente como un cliente y asume como propio el
tiempo recibido desde el servidor. Además, cada jugador tiene que enviar al otro la dirección en
la que se mueve su nave y si ha disparado o no. De esta manera se logra la sincronización
entre ambas videoconsolas y las pantallas muestran en todo instante la misma acción.
Figura 5.4. Intercambio de mensajes del modo multijugador.
El diagrama de clases se modifica tal y como se muestra en la figura 5.5:
• MultiplayerServerState. Es el estado que se encarga de actualizar el objeto

ArcadeGame y con ello la lógica de juego. Antes de esto, envía a la otra PSP el tiempo
transcurrido respecto al ciclo anterior.
• MultiplayerClientState. Similar al estado anterior, pero no envía el tiempo

transcurrido, sino que lo recibe de la PSP servidora. Dicho tiempo es utilizado después
para actualizar la lógica de juego.
89
• DummySpaceship. Es la nave que representa al segundo jugador con el que se

comparte el juego. Añade a sus comportamientos uno de tipo
DummySpaceshipBehaviour.
• MultiplayerSpaceship. Es la nave que representa al jugador que interactúa

directamente con su PSP. Añade a sus comportamientos uno de tipo
MultiplayerControlledSpaceshipBehaviour.
• DummySpaceshipBehaviour. Recibe de la PSP remota el vector de velocidad y la

acción realizada por el segundo jugador. Esta información se utiliza para actualizar la
posición de la nave y dibujar los disparos correspondientes.
• MultiplayerControlledSpaceshipBehaviour. Envía a la PSP remota el vector de

velocidad y la acción realizada por la nave.
DummySpaceship
State
+ini() : bool
+end() : bool
MultiplayerServerState MultiplayerClientState
-arcadeGame : ArcadeGame -arcadeGame : ArcadeGame
Spaceship
DummySpaceshipBehaviour
+update() : bool
+ini() : bool
+end() : bool
PlayerControlledSpaceshipBehaviour
PlayerSpaceship
MultiplayerControlledSpaceshipBehaviour
MultiplayerSpaceship
+update() : bool
+ini() : bool +ini() : bool
+end() : bool +end() : bool
Figura 5.5. Diagrama de clases: modo multijugador.
90
Figura 5.6. Diagrama de clases: estados y máquina de estados.
91
SelectionBallMenu
Object3D -stateMachine : StateMachine
-nextOption() : void
-previousOption() : void
+update() : bool
+ini() : bool
+reini() : bool
+reend() : bool
+end() : bool
SelectionBall
-nextStateName : string
+ini() : bool
+reini() : bool
+reend() : bool
+end() : bool
1
LightingBillboard
1
+ini() : bool 1
+reini() : bool TexturedBox
+reend() : bool
+end() : bool
+update() : bool
+ini() : bool
+reini() : bool
+reend() : bool
+end() : bool
FlyCircleLightingBillboard LightingSelectionBall
1
+reini() : bool +ini() : bool
+reini() : bool
+reend() : bool
+end() : bool
Figura 5.7. Diagrama de estados: elementos del menú.
92
Figura 5.8. Diagrama de clases: comportamientos.
93
Figura 5.9. Diagrama de clases: juego.
94
AdventureGame
+update() : bool
+ini() : bool
+reini() : bool
+reend() : bool
+end() : bool
Game
ArcadeGame
-arcadeGameEventController : ArcadeGameEventController
-gameOver : bool
-missionCompleted : bool
+update() : bool
+ini() : bool
+reini() : bool
+reend() : bool
+end() : bool
1 1
1 1
ArcadeGameBackground «factory»
EnemySpaceshipGenerator
-playerSpaceship : PlayerSpaceship
+update() : bool -world : vector<CollisionFaction>
+ini() : bool
+end() : bool +ini() : bool
+end() : bool
1 1
1 1
TerrainGenerator FlyingCamera
+ini() : bool +update() : bool Object3D

+end() : bool +ini() : bool
+reini() : bool
+reend() : bool
+end() : bool
Figura 5.10. Diagrama de clases: juego arcade y aventura
95
Object3D GameObject3D
Spaceship
#weapons : Weapons
#reloadTime : float
#tiltingAngle : float
#shields : float
#mass : float
Tail #referenceTranslateSpeed : float
EnemySpaceshipTail #referenceTiltingSpeed : float
+ini() : bool #referenceTranslateAcceleration : float
1 #blockingDirectionTime : float
+ini() : bool +reini() : bool
1 +blockDirection() : void
+end() : bool +reend() : bool
+end() : bool +update() : bool
+ini() : bool
+reini() : bool
+reend() : bool
+end() : bool
PlayerSpaceship
EnemySpaceship
-observable : Observable
#fireRate : float
-minSpeed : float
#fullReloadTime : float
+blockDirection() : void
+blockDirection() : void
+ini() : bool
+ini() : bool
+end() : bool
PursuitEnemySpaceship
-object3DToLock : Object3D TurningEnemySpaceship LateralEnemySpaceship
-object3DToLockObservable : Observable -turningTime : float -lateralTranslationDistance : float
-deleteObserver : DeleteObserver -turningAngle : float -lateralTranslationTime : float
-lockingTime : float -turningSpeed : float -lateralTranslationAngle : float
-pursuitTolerance : float -loop : bool +ini() : bool
-pursuitSpeed : float +ini() : bool
+update() : bool
+ini() : bool
+end() : bool
Figura 5.11. Diagrama de clases: naves (modo arcade).
96
Figura 5.12. Diagrama de estados: armamento y disparos (modo arcade).
97
GameObject3D «factory»ExplosionBillboard
-world : vector<CollisionFaction>
+createExplosionAt() : bool
+update() : bool
+ini() : bool
+reini() : bool
+reend() : bool
+end() : bool
Item
-playerSpaceship : PlayerSpaceship
+activate() : bool
+ini() : bool «factory»PortalBillboard
+reini() : bool -world : vector<CollisionFaction>
+reend() : bool
+end() : bool +createPortalAt() : bool
+update() : bool
+ini() : bool
+reini() : bool
+reend() : bool
+end() : bool
ExtraShieldsItem DualCanonItem TripleCanonItem
+activate() : bool +activate() : bool +activate() : bool

+ini() : bool +ini() : bool +ini() : bool
+end() : bool +end() : bool +end() : bool
Figura 5.13. Diagrama de clases: ítems, explosiones (modo arcade) y

portales (modo avetntura).
LightingBillboard 1 1 -parent SelectionBallMenu
Object3D
#iAm : string
-behaviours : list<Behaviour>
FlyingCamera +undoLastTranslate() : void SelectionBall
+resetLastTranslate() : void
+translate() : void
+rotate() : void
+scale() : void
+update() : bool
Tail +ini() : bool TexturedBox
+reini() : bool
+reend() : bool
+end() : bool
GameObject3D
Spaceship Shot
#deleteMe : bool
#eraseMe : bool
#world : vector<CollisionFaction>
+update() : bool
+ini() : bool «factory»
Item +reini() : bool ExplosionBillboard
+reend() : bool
+end() : bool
AdventureGuy «factory»PortalBillboard
Figura 5.14. Diagrama de clases: clases base elementales.
98
ArcadeGameEventController
-gameTime : float
+update() : bool
+ini() : bool
+end() : bool
* 1 1
ArcadeGameEvent
-triggerTime : float
+update() : bool
+ini() : bool
+end() : bool
ArcadeGameFireForgetEvent ArcadeGameContinuousEvent
-finished : bool
+update() : bool +update() : bool
CreationArcadeGameEvent MissionCompletedArcadeGameEvent RadioArcadeGameEvent

-objectsToCreate : list<Object3D> -arcadeGame : ArcadeGame -arcadeGameHUD : ArcadeGameHUD
+update() : bool +update() : bool +update() : bool
+ini() : bool +ini() : bool +ini() : bool
+end() : bool +end() : bool +end() : bool
Figura 5.15. Diagrama de clases: gestión de eventos (modo

arcade).
MyEventReceiver
-mapLTEGEToName : map<int, string>
+OnEvent() : bool
1 EventValue
EventController
#name : string
«utility» #value : float
EngineController 1 +restore() : void 1 * +restore() : void
+ini() : bool 1
+end() : bool
InputEventValue
GUIEventValue
-inc : float
-changed : bool
+restore() : void
+restore() : void
Figura 5.16. Diagrama de clases: gestión de eventos de la entrada y del GUI.
99
TalkingGuy PlayerControlledGuy
-message : wchar_t
+update() : bool +update() : bool
Observable
Observer * 1
+registerObserver() : void
AdventureGuy +notify() : void +unregisterObserver() : void
+notifyObservers() : void
+update() : bool
+ini() : bool
+reini() : bool
+reend() : bool
+end() : bool
DeleteObserver
GameObject3D -deleted : bool

+notify() : void
Figura 5.17. Diagrama de clases: personajes (modo aventura) y observer.
MessageWindow «utility»
SoundController StoryTeller «utility»
-musicVolume : float GameParameters
+update() : bool -fxVolume : float
+ini() : bool +update() : bool
+fadeIn() : void +ini() : bool
+end() : bool +fadeOut() : void +end() : bool
+playFX() : void
+playMusic() : void
TimeController +stop() : void
+pause() : void LoadingScreen «utility»
+update() : bool FilePaths
+tick() : unsigned int +ini() : bool
+ini() : bool
+end() : bool
+update() : bool
«utility» +end() : bool
1
GameUtils
1
+fromCharToWChar() : wchar_t
+printDebug() : void SoundFader
+logError() : void
+radiansToDegrees() : float
+insideOfGameArea() : bool +update() : bool
+ini() : bool
+end() : bool
Figura 5.18. Diagrama de clases: otras clases auxiliares.
100
CONSIDERACIONES SOBRE LA IMPLEMENTACIÓN
6. CONSIDERACIONES SOBRE LA
IMPLEMENTACIÓN
6.1 INTRODUCCIÓN
Existen múltiples técnicas y diseños para implementar un juego de este tipo. Cada alternativa
presenta sus propias ventajas e inconvenientes. A continuación se describe cómo se han
conformado en el juego los diferentes elementos tratados en la especificación del diseño.
6.2 FLUJO DE EJECUCIÓN

El proyecto se basa en el bucle mostrado en la figura 6.1 para lograr la ejecución de la
aplicación.
(2) ACTUALIZAR
EL TIEMPO
(1) REINICIAR LA (3) ACTUALIZAR

ESCENA EL ESTADO
(4) DIBUJAR
Figura 6.1. Bucle de ejecución del videojuego.
En cada nuevo ciclo del bucle se reinicia la escena limpiando de la pantalla todos los
elementos dibujados. Después se actualiza el tiempo que ha transcurrido respecto a al ciclo
anterior y dicha información se emplea para actualizar el estado que actualmente se esté
tratando. Haciendo la lógica del estado dependiente del tiempo se consigue que el
comportamiento real del juego sea el mismo independientemente de la velocidad del
procesador. Finalmente, se dibuja en pantalla la escena resultante.
101
6.3 MODO ARCADE
6.3.1 Área de juego
Los elementos del juego (naves, ítems, disparos…) deben situarse en el espacio 3D generado
por el motor gráfico. Toda la acción tiene lugar siempre sobre un plano, de manera que el
movimiento del jugador y su interacción con el mundo quedan restringidos a dos coordenadas.
En este caso, la nave del jugador y los demás elementos del juego se sitúan sobre el plano XZ
(teniendo en cuenta la disposición de los ejes realizada por LTE GE). El área de juego es
rectangular y está definida por una determinada anchura y altura. Su centro se encuentra
inicialmente ligeramente desplazado respecto al vector que indica el objetivo de la cámara. No
obstante, el centro del área de juego se mueve con la velocidad de la cámara en línea recta en
el eje Z. Dado que el área de juego modifica su posición en el mundo, la ubicación de todos los
demás elementos del juego se establece de acuerdo a sus coordenadas en cada ciclo del
juego.
Figura 6.2. Disposición del escenario, cámara y área de

juego.
Para conseguir una perspectiva cenital la cámara se instala en el centro del área, pero con
valor positivo para la coordenada Y, de manera que se simula un efecto de zoom. Además, se
desplaza en el eje Z negativo para que la sensación de profundidad sea mayor.
Más allá del área de juego se establece una zona denominada umbral en la que los diferentes
elementos del juego se van creando. Dado que la cámara sólo abarca el ára de juego, la zona
umbral queda fuera de la percepción del jugador. Si no se utilizara esta zona, los objetos que
se deben presentar al jugador aparecerían repentinamente en el área de juego, perdiéndose la
sensación de estar volando a través del escenario. Una vez que un elemento volatil del mundo
abandona la zona umbral, es destruido.
102
Figura 6.3. Umbral de creación.
6.3.2 Movimiento del jugador
La nave controlada por el jugador puede moverse en cualquiera de las direcciones indicadas
en la figura 6.3, aunque nunca podrá abandonar el área de juego y verá interrumpido su
desplazamiento en el momento que intente atravesarla. Para lograr un recreación más realista
del movimiento, se ha aplicado una deceleración al vector de velocidades del objeto en el
momento en el que el jugador deja de moverse en alguna dirección. De esta manera, la nave
disminuye gradualmente su velocidad hasta detenerse. Otro detalle encaminado en la misma
línea es el efecto de ladeo que experimenta a medida que se desplaza lateralmente. La nave
rota ligeramente sobre el eje Z con lo que emula el movimiento de un avión en el aire.
La nave del jugador se desplaza siempre con una velocidad mínima en el eje Z positivo. Esta
velocidad viene dada por la velocidad mínima con la que la cámara se mueve por el escenario.
Por tanto, la nave del jugador nunca puede quedar fuera de la vista de la cámara.
Figura 6.4. Movimiento de la nave del jugador.
103
6.3.3 Escenario
El escenario está recreado mediante un terreno irregular generado con ayuda de LTE GE y un
mapa de alturas. Este mapa consiste en una textura con diferentes colores dentro de una
escala de grises. El color blanco representa la altura máxima del terreno, mientras que el negro
equivale a un plano. Los colores intermedios crean diferentes desniveles.
Dado que crear un único terreno irregular lo suficientemente grande para cada misión supone
una carga de procesamiento excesiva para el motor gráfico, se ha optado por usar dos terreno
que se encadenan uno detrás de otro. Inicialmente la cámara abarca el primer terreno y no se
necesita el segundo terreno que permanece oculto. Sin embargo, a medida que se desplaza
por el escenario y se acerca al límite del terreno hay que mostrar un segundo terreno para
garantizar la continuidad del escenario. Después, cuando el primer terreno abandone el campo
de visión de la cámara, se oculta. Este proceso se repite de manera cíclica, con lo que el
jugador tiene la sensación de estar explorando un escenario completo.
La figura 6.4 representa gráficamente este proceso. Los números

1, 2, 3, 4 y 5 son diferentes posiciones de la cámara, mientras que
los planos A, B y C son terrenos irregulares.
1. Inicialmente la cámara se desplaza a lo largo del eje

positivo. Su campo de visión se limita al terreno A, por lo
que el terreno B permanece oculto.
2. El campo de visión de la cámara alcanza el límite del

terreno A, por lo que hay que mostrar el terreno B que se
encadena con el A.
3. La cámara deja de mostrar el terreno A que se hace no

visible.
4. Como en el punto 2, el campo de visión de la cámara se
acerca al límite del terreno B. El terreno A se coloca a

Figura 6.5. Evolución continuación del B y se vuelve a hacer visible.
del escenario y la
cámara. 5. Como en el punto 3, la cámara deja de mostrar el terreno
B que se hace no visible.
Utilizar sólo un mapa de niveles para generar el terreno puede afectar negativamente a la
inmersión del jugador en la acción que se desarrolla. Podría percatarse fácilmente de que
realmente se está repitiendo el mismo terreno una y otra vez. Para mitigar este problema se
emplean dos mapas de niveles preparados para que el relieve entre ambos sea continuo.
104
Figura 6.6. Mapas de alturas.
6.3.4 Gestor de eventos
Los eventos hacen referencia a todos aquellos sucesos que acontecen en el transcurso del
juego y lo modifican. Se disparan en algún instante en el tiempo y su efecto depende
totalmente del tipo de evento, pudiendo ir desde la simple creación de un objeto hasta la
visualización de una transmisión de radio entre varios personajes. En el proyecto se han
definido dos tipos básicos de eventos:
• Eventos de un uso. Son eventos que sólo se aplican una vez.
o Creación de elementos del área de juego. Inicializa uno o varios elementos

del juego colocándolos en el área de juego.
• Eventos continuos. Son eventos que tienen efecto durante un periodo de tiempo
indefinido.
o Transmisión de radio. Muestra una conversación de radio entre varios

personajes mediante diferentes líneas de texto.
o Fin de misión dependiente de las naves enemigas. Finaliza la misión en

curso cuando no quedan más naves enemigas en el área de juego.
El gestor de eventos básicamente se encarga de comprobar si ha transcurrido el tiempo

necesario para que un evento pueda dispararse y en caso afirmativo ejecuta el código
establecido para su lanzamiento. La estructura de datos que contenía el evento de un uso es
eliminada inmediatamente después, no así su efecto. Para los eventos continuos, su
destrucción se posterga hasta que el evento indique que ha finalizado.
Como los diferentes eventos que tienen lugar se crean al comienzo del juego, su número
puede llegar a ser notoriamente elevado. Para facilitar su manejo, el gestor de eventos los
ordena en el tiempo al inicializarse de manera que si un determinado evento no puede
dispararse todavía, no seguirá comprobando los restantes, ya que son posteriores.
105
6.3.5 Flujo de ejecución
Cada estado requiere una gestión diferente dependiendo de su cometido. Si bien los estados
correspondientes a los menús no encierran una gran complejidad, no ocurre lo mismo con el
estado encargado de la ejecución del juego.
En este caso, la primera acción a realizar consiste en

ACTUALIZAR EL actualizar el escenario en el que transcurre la acción. Se
ESCENARIO gestionan los dos terrenos irregulares ocultando y
mostrando alguno de ellos si fuera preciso, y se desplaza la
cámara en función del tiempo transcurrido.
ACTUALIZAR EL
MUNDO Después se actualizan todos los objetos que existen
actualmente en el mundo (la nave del jugador, las naves
enemigas, los disparos…). Cada uno encierra a su vez su
ACTUALIZAR LOS
propio comportamiento. También se procede a eliminar
EVENTOS
aquellos elementos que hayan abandonado la zona umbral
y no deban ser actualizados nuevamente.
ACTUALIZAR LAS
COLISIONES Los dos últimos pasos consisten en gestionar los posibles
eventos que puedan ser necesarios lanzar y finalmente las
colisiones entre los objetos del mundo. Ambas operaciones
Figura 6.7. Flujo de ejecución
son analizadas en mayor detalle en los siguientes puntos
del modo arcade.
de este apartado.
6.3.6 Gestor de colisiones
Los diferentes objetos del mundo pueden colisionar entre si dando lugar a efectos
dependientes de su naturaleza. Así pues, si un disparo alienígena colisiona con una nave
aliada, disminuirá su nivel de escudos. Pero si la nave aliada colisiona con una nave enemiga,
además será proyectada en una dirección resultante del impacto.
El primer paso para gestionar las colisiones consiste en detectarlas. Para ello se ha seguido
una técnica conocida como bounding-box, que básicamente encierra cada modelo 3D en un
cubo lo más ajustado posible a su geometría. Después, las colisiones se calculan en función de
la posición de dichos cubos, lo cual simplifica sustancialmente los cálculos.
Debido al gran número de elementos que pueden estar presentes en el área de juego en un
momento determinado (disparos, naves, ítems…), la gestión de las colisiones entre estos
necesita ser tratada con especial cuidado para que el rendimiento del juego no se vea afectado
negativamente.
La solución por la que se ha optado consiste en crear facciones de objetos. Todos los objetos
pertenecientes a una determinada facción se consideran amigos, por lo que no es necesario
comprobar si colisionan entre ellos. Además, es posible indicar para una determinada facción
cuáles son las facciones con las que se deben comprobar las colisiones. Así por ejemplo, dado
106
que no existe interacción alguna entre los disparos de las naves aliadas y los de las enemigas,
no se especificará que sus facciones detecten colisiones entre ellas. También hace posible que
la comprobación sea unidireccional. Es decir, sólo se tendrá en cuenta que, por ejemplo, una
nave impacta con un disparo, pero no que un disparo impacta con una nave. De esta manera,
se consigue evitar una importante carga de trabajo frente a una solución basada en la fuerza
bruta (gestionar todo con todo).
Las facciones establecidas y las relaciones entre ellas son las recogidas en la tabla 6.1.
Facción Colisiona con…
Naves aliadas. Disparos alienígenas.
Disparos alienígenas
perseguidores.
Naves alienígenas.
Ítems.
Disparos aliados. Naves alienígenas.
Disparos alienígenas
perseguidores.
Naves alienígenas. -
Disparos alienígenas. -
Disparos alienígenas -
perseguidores.
Ítems. -
Sin colisión. -
Tabla 6.1. Relación de facciones y colisiones del modo arcade.
6.4 MODO AVENTURA
6.4.1 Escenario
El escenario empleado en el modo aventura ha sido creado utilizando el editor de mapas

Q3Radiant. El proceso completo de compilación de este tipo de mapas incluye el cálculo de las
sombras proyectadas por los elementos del escenario. La principal ventaja derivada de este
cálculo previo es que si las luces son estáticas, el mapa no tiene que ser iluminado en tiempo
de ejecución, puesto que las sombras ya han sido dibujadas al compilarse. Esto se traduce en
una mejora considerable del rendimiento de la aplicación. Mediante este método también se
consigue un mayor grado de detalle en la iluminación del escenario.
107
Debido a diversos problemas durante la compilación del mapa desarrollado, las sombras no
son proyectadas correctamente sobre algunas superficies del escenario, que permanecían
completamente oscuras. Para solucionarlo ha sido necesario iluminar dinámicamente el mapa,
por lo que el movimiento del jugador por el escenario no resulta tan fluido como se esperaba.
6.4.2 Flujo de ejecución
El flujo de ejecución del modo aventura es un subconjunto del comentado en el modo arcade,
por lo que sólo se muestra el diagrama correspondiente.
ACTUALIZAR EL
MUNDO
ACTUALIZAR LAS
COLISIONES
Figura 6.8. Flujo de ejecución

del modo aventura.
6.4.3 Gestor de colisiones
La mayor parte de la gestión de colisiones se delega en el gestor incluido en el propio motor,

LTE GE. Mediante la creación de animadores CollisionResponseAnimator se logra una gestión
de colisiones similar a la de los juegos de acción en primera persona. Básicamente consiste en
la definición de un elipsoide que posteriormente puede ser asignado a un nodo de la escena.
En cada ciclo de actualización se comprueba si el elipsoide ha intersecado con alguna
superficie del escenario, evitando así que el nodo atraviese el suelo o las paredes.
También se lleva a cabo una gestión de colisiones mediante facciones para poder determinar
cuándo el jugador llega a un punto de salida. Al contrario que en el modo arcade, esta
comprobación no se realiza mediante la técnica de boundig-box, sino calculando la distancia
entre las posiciones que ocupan el jugador y el portal.
Las facciones establecidas y las relaciones entre ellas son las recogidas en la tabla 6.2.
Facción Colisiona con…
Jugador. Portales.
Portales. -
Soldados. -
Tabla 6.2. Relación de facciones y colisiones del modo aventura.
108
PLAN DE PRUEBAS
7. PLAN DE PRUEBAS
7.1 INTRODUCCIÓN
Durante la realización del proyecto se han efectuado numerosas pruebas para asegurar el nivel
de calidad del código y tratar de minimizar en la medida de lo posible los fallos.
7.2 OBJETIVOS
Los objetivos perseguidos por el plan de pruebas son:
• Comprobar qué funciones requeridas por el proyecto incorpora LTE GE y verificar su

correcto funcionamiento.
• Garantizar que la aplicación funciona correctamente de acuerdo a la especificación de

requisitos del sistema.
• Lograr un nivel de jugabilidad adecuado al usuario objetivo.
7.3 DEFINICIÓN DE LA ESTRATEGIA DE PRUEBA

El plan de pruebas se divide en 3 fases cada una de las cuales dispone de su propia estrategia
de prueba.
• Primera fase. Se trata de determinar el grado de adecuación de LTE GE a los

requisitos del videojuego. Para ello se llevan a cabo diversas pruebas a partir de los
ejemplos incluidos con el motor y se recogen los resultados obtenidos.
• Segunda fase. Consta de sucesivas pruebas de unidad y del sistema para comprobar
el correcto funcionamiento de los módulos desarrollados. Tras implementar uno de los
elementos del videojuego se somete a una serie de pruebas de unidad para garantizar
la inexistencia de fallos. Después, a medida que se van implementando nuevos
módulos, se aplican las pruebas de integración correspondientes.
• Tercera fase. Se centra en asegurar la jugabilidad del videojuego. Se llevan a cabo

diversas pruebas junto a un usuario potencial para comprobar cómo interactúa con el
109
videojuego. Se recogen anotaciones sobre las apreciaciones realizadas por el usuario

durante y después de las pruebas. También se registra cualquier error de ejecución no
detectado en la segunda fase.
Estas 3 fases se desarrollan secuencialmente, de manera que hasta que no finalice el plan
de pruebas de la primera fase no se procede con la siguiente.
7.4 CRITERIOS DE ACEPTACIÓN

Los criterios de aceptación han tenido que ser modificados en algunas de las fases en base a
los resultados obtenidos de las pruebas y ante la imposibilidad de mejorarlos. A continuación
se indican los criterios de aceptación para cada una de las 3 fases:
• Primera fase. Termina cuando las pruebas sobre los aspectos de LTE GE
imprescindibles para el desarrollo de la aplicación tienen éxito.
• Segunda fase. Inicialmente se consideró que terminaría cuando todos los módulos
probados individualmente y posteriormente integrados en el sistema no tuvieran errores
de ejecución. Después, en base a los resultados obtenidos y a su relación con la
primera fase, se considera que la fase finaliza cuando las pruebas de unidad tienen
éxito y las del sistema permiten jugar de principio a fin por los menos una vez la misión
incluida en el juego.
• Tercera fase. Termina cuando el 80% de las opiniones recibidas acerca de la

jugabilidad del juego son positivas.
7.5 RESULTADOS
7.5.1 Primera fase
Los resultados de la primera fase cumplen los requisitos mínimos del videojuego, por lo que se
acepta el motor LTE GE como el conjunto de librerías a utilizar para el desarrollo de la
aplicación.
Prueba Resultado Observaciones
Aplicación “hola mundo” Positivo. -
Carga de mapas BSP Positivo. -
Carga de modelos MD2 Positivo. -
Carga de modelos 3DS Negativo. Algunas de las caras de los modelos no

se visualizan. Otros modelos creados por
terceros se cargan correctamente, pero
no se detecta la causa del problema. En
110
PLAN DE PRUEBAS
los foros de LTE GE se encuentran

usuarios con el mismo problema, pero no
se da ninguna solución.
Carga de modelos MS3D. Negativo. El modelo no se carga y la aplicación se

bloquea. En los foros de LTE GE se
encuentran usuarios con el mismo
problema, pero no se conoce ninguna
solución.
Manejo de animadores. Positivo. -
Interacción con el GUI. Positivo. -
Detección de eventos. Positivo. -
Dibujado de gráficos 2D. Positivo. -
Manejo de efectos Positivo. -

especiales y sistemas de
partículas.
Manejos de luces Positivo. Aunque entre las características de LTE

dinámicas y generación de GE se dice que soporta sombras
sombras. volumétricas, al utilizarlas en la aplicación
no se generan este tipo de sombras.
Generación de terreno Positivo. -

irregular.
Comunicaciones y WI-FI. Positivo. Sólo se soporta el modo infraestructura.

Eco del mensaje “hola La videoconsola que se comunica de esta
mundo” con un proceso manera debe encontrarse en la misma
servidor. red local que el proceso servidor, de otro
modo el tiempo entre el envío y la
recepción del mensaje es demasiado
elevado.
Comunicaciones y WIFI. Positivo. Usando la librería PSPSDK.

Eco del mensaje “hola
mundo” entre dos
videoconsolas con una
conexión ad-hoc.
Detección de colisiones en Negativo. La gestión de colisiones automática

un mapa BSP. proporcionada por LTE GE no funciona
correctamente con mapas BSP y en
ocasiones se atraviesa el suelo o las
paredes. Se contacta con uno de los
desarrolladores del motor, pero no se
111
haya ninguna solución.
Reproducción de sonido. Positivo. De los tres formatos soportados por LTE

GE sólo se consiguen reproducir archivos
MP3 y AT3. Los archivos WAV fallan al
reproducirse.
Tabla 7.1. Resultados de las pruebas de unidad de la primera fase.
7.5.2 Segunda fase
Aunque la mayor parte de los resultados mostrados en la tabla 7.2 no son negativos, todos
ellos son obtenidos a partir de pruebas de unidad. Al integrar los diferentes módulos y
comenzar las pruebas del sistema los resultados son variables. Aparecen fallos de ejecución al
cargar recursos externos como texturas, modelos o sonidos. También al liberar la memoria
reservada para estos.
Algunos de los problemas se resuelven cambiando de posición la línea de código conflictiva,

sin que exista una razón lógica para ello. No obstante, cualquier solución es temporal, y varias
ejecuciones de una misma aplicación pueden fallar en un mismo punto o ejecutarse sin
problemas. La variabilidad de los errores y el hecho de estar aparentemente motivados por la
librería LTE GE, por la carga del PBP en la memoria o por la versión del firmware, hace muy
difícil cumplir los criterios de validación iniciales de esta fase.
A pesar de que ciertas ejecuciones fallan, la mayoría de ellas permiten jugar completamente la
primera misión del juego. Sin embargo, si se intenta volver a jugar después de su finalización,
la aplicación se bloquea. Finalmente se decide continuar a pesar de los errores siempre que se
pueda mostrar la funcionalidad de la aplicación por lo menos una vez.
Cambio entre estados. Positivo. -
Gestor de eventos de la Positivo. Se encuentra un problema de ejecución al

entrada y del GUI. usar constantes estáticas de tipo string.
Navegación entre menús. Positivo. -
Generación del escenario. Positivo. -
Control de la nave del Positivo. Modo arcade. El mando analógico se

jugador. comporta como si siempre estuviera
pulsado hacia la izquierda. Se encuentra
el mismo problema en una segunda PSP
y en otros ejemplos, por lo que se deduce
que el problema debe ser del motor, LTE
GE.
Manejo de naves enemigas Positivo. Modo arcade.
112
PLAN DE PRUEBAS
y disparos.
Detección de colisiones. Positivo. Modo arcade.
Gestión de eventos de Positivo. Modo arcade.

juego.
Manejo de explosiones. Positivo. Modo arcade.
Reproducción de efectos Positivo. -

sonoros.
Carga de elementos de la Negativo. Modo arcade. La aplicación se bloquea al

primera misión. cargas las texturas de las naves
enemigas. El problema se resuelve
usando un único archivo con todas las
texturas y reduciendo sus dimensiones a
256 x 256 pixels.
Manejo de sistemas de Positivo. Modo arcade.

partículas para las estelas
de las naves.
Manejo de ítems. Positivo. Modo arcade.
Presentación del Positivo. -

argumento del juego.
Carga del mapa creado con Negativo. Modo aventura. La aplicación se bloquea
Q3Radiant. al cargar el mapa. Se vuelve a crear el
mapa realizando pruebas de manera
incremental. Finalmente se consigue una
versión estable.
Carga de los personajes. Negativo. Modo aventura. La aplicación se bloquea

al cargar las texturas del modelo. Se
soluciona reduciendo las dimensiones de
la textura a 256 x 256 pixels.
Manejo de portales. Positivo. Modo aventura.
Detección de colisiones. Positivo. Modo aventura.
Tabla 7.2. Resultados de las pruebas de unidad de la segunda fase.
7.5.3 Tercera fase
Algunas de las pruebas recogidas en la tabla 7.3 fueron realizadas por el mismo usuario. No
todas las observaciones terminaron por convertirse en modificaciones reales del juego. Las que
fueron obtenidas a partir de resultados positivos se evaluaron y consultaron con otros usuarios
para comprobar si se trataba de una apreciación exclusivamente personal.
113
Usuario 1. Negativo. Modo arcade. La frecuencia con la que las naves

enemigas aparecen en la pantalla es excesiva y hace
que la acción sea demasiado frenética. Además el
elevado número de elementos en pantalla da lugar a
ralentizaciones.
Usuario 2. Positivo. Modo arcade. A medida que aparecen las naves

enemigas, estas disparan a la vez. Una cierta
aleatoriedad mejoraría la percepción del usuario.
Usuario 3. Positivo. Modo arcade. La velocidad a la que la nave del jugador

se desplaza por el escenario es muy lenta, con lo que la
acción parece más pausada de lo que en realidad es.
Además, los ítems tardan demasiado tiempo en estar al
alcance de la nave del jugador.
Usuario 4. Positivo. Modo aventura. El tamaño de la letra con la que se

visualiza el texto tras interactuar con un personaje es
muy pequeño.
Usuario 5. Negativo. Modo arcade. El daño recibido por lo impactos con otras
naves es bajo. Unido al largo tiempo de invulnerabilidad
hace que la misión pueda completarse recibiendo
impactos continuamente.
Usuario 6. Positivo. -
Usuario 9. Positivo. Modo arcade. La textura usada para el escenario es

demasiado oscura y dificulta la visión de los elementos
del juego.
Tabla 7.3. Resultados de las pruebas de la tercera fase.
114
MANUAL DE USUARIO
8. MANUAL DE USUARIO
8.1 INTRODUCCIÓN
Este manual describe la instalación y uso del videojuego Air Warriors.
8.2 REQUERIMIENTOS TÉCNICOS

Para poder disfrutar de Air Warriors es indispensable disponer de una videoconsola PSP con
un firmware que permita ejecutar aplicaciones homebrew, ya sea la versión 1.5 del firmware
oficial de Sony o cualquiera de los firmwares personalizados no oficiales. También se necesita
una tarjeta de memoria con al menos 6 MB de espacio libre.
8.3 INSTALACIÓN Y EJECUCIÓN

El proceso concreto a seguir depende del firmware de la PSP, aunque de manera genérica los
pasos a seguir son los siguientes:
• Copiar las carpetas AirWarriors y AirWarriors% en la carpeta del sistema de ficheros

que la PSP usa para ejecutar aplicaciones homebrew (generalmente ms0:/GAME150).
• Copiar la carpeta AirWarriorsMedia en el directorio raíz de la PSP (ms0:/).
• Ejecutar Air Warriors desde el XMB de la PSP.
8.4 MENÚ PRINCIPAL

El usuario puede usar los botones de dirección (▲, ▼) para navegar por las distintas opciones
del menú. La opción seleccionada en cada instante está indicada mediante una esfera de color
azul con una pequeña luz que gira alrededor. Para activar la opción seleccionada se debe
pulsar el botón (X).
• One Player. Lleva al menú del modo individual.
• Multiplayer. Lleva al menú del modo multijugador. En la versión actual de Air Warriors
no existe ninguna opción multijugador disponible.
115
• Options. Lleva al menú de opciones.
• On-Line. Lleva al menú de servicios en línea. En la versión actual de Air Warriors no

existe ningún servicio en línea disponible.
• Quit. Muestra una ventana de confirmación antes de cerrar la aplicación. Pulsando el

botón (X) se abandona Air Warriors y se vuelve al XMB de la PSP. Con el botón (O) se
vuelve al menú principal.
Figura 8.1. Menú principal.
8.4.1 Menú del modo individual
Las opciones que no están disponibles aparecen ensombrecidas. Al pulsar el botón (X) sobre
ellas se muestra un mensaje informativo al respecto.
Figura 8.2. Menú del modo individual.
116
MANUAL DE USUARIO
• Continue. Carga la última partida guardada. No está disponible en la versión actual de

Air Warriors.
• New Game. Comienza una nueva partida y pasa a mostrar la introducción de la historia
del juego.
• Load Game. Carga la partida seleccionada. No está disponible en la versión actual de

Air Warriors.
• Back. Vuelve al menú anterior.
8.4.2 Menú del modo multijugador
Las opciones Ad-Hoc e Infrastructure requieren tener activado el dispositivo WI-FI de la PSP.
Figura 8.3. Menú del modo multijugador.
• Ad-Hoc. Comienza una nueva partida multijugador con otro jugador estableciendo una
conexión directa entre las videoconsolas. No está disponible en la versión actual de Air
Warriors.
• Infrastructure. Utiliza un punto de acceso para conectarse a través de Internet al

servidor de partidas de Air Warriors, donde se puede jugar con otros usuarios. No está
disponible en la versión actual de Air Warriors.
• Options. Lleva al menú de opciones del modo multijugador. No está disponible en la

versión actual de Air Warriors.
117
8.4.3 Menú de opciones
Figura 8.4. Menú de opciones.
• Sound. Lleva a la pantalla de opciones de sonido.
• Controls. Lleva a la pantalla de opciones de control.
8.4.3.1 Opciones de sonido
La interacción con los elementos de la ventana se lleva a cabo mediante el cursor. Se mueve
con el mando analógico, mientras que el botón (X) tiene el mismo efecto que si se pulsara el
botón izquierdo de un ratón.
Figura 8.5. Opciones de sonido.
118
MANUAL DE USUARIO
• FX Volume. Indica el nivel de volumen de los efectos de sonido especiales. El máximo

es 100 y equivale al volumen actual de la PSP. Cualquier valor inferior reduce el
volumen de manera gradual hasta llegar a 0.
• Music Volume. Indica el nivel de volumen de la música.
• Accept. Guarda los cambios y vuelve al menú anterior.
• Cancel. Cancela los cambios y vuelve al menú anterior.
8.4.3.2 Opciones de control
Se pueden redefinir los controles por defecto para que se adapten a las preferencias de cada
usuario. Si bien se muestra una lista de controles considerable, en la versión actual de Air
Warriors sólo se emplea la acción Normal Fire. El movimiento de la nave del jugador se
controla con el mando analógico.
Figura 8.6. Opciones de control.
• KEY_XXX. Al pulsar cualquiera de estos botones se borra el nombre del control

que tenía asignado. Después se puede volver a pulsar uno de estos botones sin
control asignado para asignar un botón de la PSP. Este botón no puede estar
asignado a otra acción.
• Accept. Guarda los cambios y vuelve al menú anterior. Es necesario que todos los
controles tengan un botón válido asignado.
• Cancel. Cancela los cambios y vuelve al menú anterior.
119
8.4.4 Menú de servicios en línea
Las opciones de Ranking y Downloads requieren tener el dispositivo WI-FI y una conexión a un
punto de acceso con Internet.
Figura 8.7. Menú de servicios en línea.
• Ranking. Descarga del servidor de servicios en línea una lista con las puntuaciones
conseguidas por los jugadores en los diferentes mapas del modo multijugador. No está
• Downloads. Descarga del servidor de servicios en línea contenido adicional para el

juego. No está disponible en la versión actual de Air Warriors.
• Options. Permite configurar la dirección IP del servidor de servicios en línea. No está

8.5 MODO INDIVIDUAL
8.5.1 Historia
Air Warriors cuenta con una compleja trama que combina un escenario apocalíptico con
conspiraciones políticas y militares, así como con la llegada de una enigmática raza alienígena.
A continuación se incluye la introducción del modo individual que plantea toda una serie de
nuevos interrogantes al jugador:
120
MANUAL DE USUARIO
En el año 2047 las peores pesadillas de la humanidad se han hecho realidad y han llevado
al planeta a la mayor crisis internacional conocida hasta el momento. Los recursos naturales
se agotan rápidamente y el cambio climático hace estragos en los países más pobres.
Fruto de su egoísmo, las principales potencias de la Tierra hicieron caso omiso de las
advertencias de la comunidad científica, y ahora que el deshielo de los polos se ha
completado, los políticos se afanan en discutir quiénes han sido los responsables de esta
situación.
Millones de ciudades costeras han desaparecido y el mapa terráqueo conocido hasta

entonces ha pasado a ser un recuerdo del pasado. En estas circunstancias, olas de
refugiados se mueven hacia el interior del continente y las ciudades más ricas ven como sus
calles se llenan de revueltas y disturbios que se extienden por todos los países.
Ningún gobierno se ve capaz de controlar la situación y por si fuera poco, la recién creada
Unión de Países Asiáticos (UPA) pone sus ojos sobre Oriente Medio como la única salida a
sus graves problemas de superpoblación y escasez de recursos.
Países como Japón o Corea del Sur intentan mantenerse al margen de la UPA, pero
cualquier signo de resistencia es considerado una amenaza y pronto son invadidos sin que
el resto de países del mundo pueda hacer algo más que preocuparse por sus propios
problemas.
Un falso conflicto militar con Irán creado por los servicios de inteligencia de la UPA es
aprovechado para iniciar la invasión de Oriente Medio y llegar hasta las fronteras de Irak,
ahora protectorado del gobierno americano. El avance asiático parece no tener fin y los
Estados Unidos recurren a la OTAN en busca de apoyo diplomático.
Sin embargo, el miedo a iniciar una 3ª Guerra Mundial provoca interminables negociaciones
en los despachos y al terminar el año, la UPA no sólo domina Oriente Medio, sino también
el 80% del continente africano, que paradójicamente atesora ahora más de la mitad de los
recursos naturales disponibles en el planeta.
Europa y los Estados Unidos declaran la guerra a la UPA y el escenario de combate se

convierte en poco tiempo en un verdadero cementerio nuclear. La guerra se recrudece
hasta límites insospechados, pero el gigante asiático avanza imparable y muchos países
Europeos, simpatizantes del régimen comunista de la UPA, deciden negociar su anexión
ante las terribles consecuencias de la guerra nuclear. La OTAN se rompe, pero algunos
países como Inglaterra, Francia o Alemania refuerzan su alianza con los Estados Unidos.
La balanza cae del lado asiático cuando las débiles defensas sudamericanas caen en Marzo
del 2049, abriendo las puertas a una invasión por tierra, mar y aire de los Estados Unidos.
Cuando el final de la 3ª Guerra Mundial parecía próximo, comienzan a llegar noticias sobre
la aparición de enormes cubos flotantes sobre los principales lugares sagrados del mundo
121
(La Meca, Jerusalén, Stonehenge, las pirámides de Egipto, el monte Fuji...). La atención de
la UPA se centra en estos misteriosos objetos alienígenas de los que surgen miles de naves
hostiles que arrasan cualquier forma de vida.
A pesar de que las fuerzas asiáticas parecen ser capaces de frenar las primeras oleadas,
pronto sucumben ante la superioridad numérica de su enemigo y el horror se propaga por
todo el planeta. Ningún país logra evitar el conflicto alienígena y el exterminio de la raza
humana pasa a convertirse en cuestión de minutos es una realidad. Los gobiernos
desaparecen y el orden es sustituido por el caos descontrolado.
5 años después…
Sólo algunas bases militares ocultas en montañas o bajo tierra han sobrevivido al ataque. Al
no poder comunicarse, cada núcleo de resistencia cree que es el último vestigio de la
humanidad y comienza a organizarse para analizar la situación en el exterior tras 5 años de
silencio.
El soldado Michael McBride es un piloto del escuadrón de naves W-01 de la base militar de
White Rock a punto de descubrir un mundo totalmente nuevo.
8.5.2 Personajes
La historia de Air Warriors evoluciona de la mano de diversos personajes con sus propias
características e intereses. Aquí se presentan sólo algunos de ellos:
• Michael McBride. Es el personaje controlado por el jugador y que

protagoniza la acción del juego. Se trata de un experimentado piloto
adiestrado en el manejo del nuevo prototipo de nave de combate conocido
como W-01.
• General George C. Marshall. Está al mando de la base subterránea de

White Rock. Es extremadamente disciplinado y duro con sus soldados, a
los que se considera hijos de una gran familia en la que él es el padre
indiscutible.
• Brad De Longs. Es el responsable de inteligencia para todas las misiones

llevadas a cabo por el escuadrón W-01. Aunque no vuela con los pilotos,
les acompaña desde el centro de mando de White Rock a través de un
complejo sistema de comunicaciones. Gracias a las cámaras incorporadas
en los W-01 puede monitorizar en todo instante el estado del escuadrón y
detectar cualquier tipo de amenaza.
8.5.3 Naves
La invasión alienígena puso en relevancia un hecho incuestionable: dominar el aire es ganar la

guerra. Los modernos aviones de combate del ejército americano resultaron completamente
122
MANUAL DE USUARIO
inútiles ante las naves enemigas. Tras 5 años de intenso trabajo por parte de los ingenieros de
White Rock, se creó el W-01. La primera nave de combate del ejército americano. Todavía se
trata de un prototipo, pero se ha convertido en la principal esperanza para los refugiados de
White Rock.
Figura 8.8. Vista exterior del W-01.
Las naves alienígenas se caracterizan especialmente por su forma de dardo, de ahí que hayan
pasado a ser conocidas comúnmente como dardos:
• Dardo. El dardo es la nave básica del ejército invasor. Rápida y maniobrable, pero con
un nivel de escudos bajo. Para paliar esta desventaja suelen atacar en grupos
numerosos.
Figura 8.9. Vista exterior del dardo.
• Doble dardo. Es una nave más resistente que el dardo básico, aunque también más
lenta. Lleva incorporados dos cañones con una potencia de disparo superior al dardo
básico.
Figura 8.10. Vista exterior del doble dardo.
123
• Dardo avanzado. Es la evolución del dardo básico. Todavía demasiado sofisticado

como para ser producido en masas, pero una auténtica amenaza para los intentos
aliados por equilibrar la balanza del poder aéreo. Su nivel de escudos es medio, pero
sigue siendo tan rápido como el dardo básico. Además incorpora tres cañones de
potencia limitada.
Figura 8.11. Vista exterior del dardo

avanzado.
• Sembrador de muerte. Se trata de una nave con un elevado poder destructivo. Si bien
su nivel es escudos es bastante reducido, a medida que avanza siembra el campo de
batalla con unos artefactos explosivos capaces de perseguir al jugador.
Figura 8.12. Vista exterior del

sembrador de muerte.
8.5.4 Ítems
Son elementos del juego que aparecen en forma de cajas con un cierto identificativo. Están al
alcance del jugador por un tiempo limitado, por lo que no debe dejarlos pasar si pueden serle
de utilidad.
Cuando el jugador entra en contacto con estas cajas, se activa alguna de las ventajas descritas
a continuación:
• Disparo doble. Cambia el armamento actual de la nave del jugador por otro con un
disparo doble. El nuevo armamento es más lento que el disparo individual y tiene una
124
MANUAL DE USUARIO
menor cadencia, pero realiza más daño. Resulta especialmente útil para hacer frente al
elevado nivel de escudos de los dobles dardos. Además, en determinadas ocasiones
puede destruir varios objetivos con una sola ráfaga.
Figura 8.13. Vista exterior del ítem de

disparo doble.
• Disparo triple. Cambia el armamento actual de la nave del jugador por un disparo
triple. El nuevo armamento es tan rápido como el disparo individual y abarca un ángulo
de fuego mayor, pero tiene un nivel de daño inferior. Cada ráfaga de disparos tiene
más posibilidades de alcanzar algún objetivo.
Figura 8.14. Vista exterior del ítem

de disparo triple.
• Nivel de escudos extra. Incrementa el nivel de escudos de la nave en un 10%. Se

puede llegar a superar el nivel máximo inicial.
Figura 8.15. Vista exterior del ítem

de nivel de escudos extra.
125
8.5.5 Nuevo juego
Tras escoger la opción New Game se presenta la introducción de la historia del juego. Se
suceden una serie de imágenes que narran los hechos más importantes acontecidos en la
trama. Las imágenes avanzan secuencialmente transcurrido un tiempo arbitrario, aunque el
propio usuario puede pasar de una a otra manualmente pulsando el botón (X). La presentación
puede ser omitida en cualquier momento pulsando el botón (START).
Figura 8.16. Imagen inicial de la introducción del juego.
Una vez terminada la introducción se presenta al jugador la posibilidad entre probar el

funcionamiento del modo arcade o del modo aventura. Estos modos no deberían ofrecerse por
separado al jugador en la versión fina del juego, sino que se irían sucediendo lógicamente a
medida que transcurre el juego.
Figura 8.17. Pantalla de selección del modo de juego..
126
MANUAL DE USUARIO
8.5.5.1 Modo arcade
Se comienza a cargar la primera misión del juego. Mientras tanto se visualiza el título de la
misión actual junto con una breve descripción de la misma. Cuando el texto sobre el estado de
la carga cambie a Done, al pulsar el botón (X) da comienzo la misión.
Figura 8.18. Pantalla de carga del modo arcade.
La acción se desarrolla en una pantalla similar a la mostrada en la siguiente imagen. Es posible

pausar la acción en cualquier momento pulsando el botón (START):
Figura 8.19. Transmisión de radio del modo arcade.
1. W01. Es la nave controlada por el jugador. Se representa mediante un cubo y al

moverse desprende una estela anaranjada. El usuario puede usar el botón de la PSP
asignado a la acción Normal Fire para disparar en cualquier momento.
2. HUD. El nivel de escudos se representa mediante un porcentaje. Si llegan al cero por

ciento la nave del jugador es destruida y la misión fracasa. Junto al nivel de escudos
también se indica cuál es el armamento con el que esta equipada la nave.
127
3. Transmisión de radio. En ocasiones el jugador puede recibir transmisiones de radio

con las que se avanza en la trama del juego. Junto al texto se muestra un pequeño
retrato que representa al personaje que está hablando en un instante dado.
Figura 8.20. Elementos del juego del modo arcade.
1. Disparos. Los disparos del jugador son de color rojo, mientras que los de las naves
enemigas son de color azul, como su estela. Cada impacto recibido de los disparos
enemigos reduce el nivel de escudos de la nave del jugador.
2. Ítems. Se activan al entrar en contacto con ellos y proporcionan distintas ventajas a la

nave del jugador.
3. Naves enemigas. Pueden ser de distintos tipos y mostrar variados comportamientos.

Su armamento también puede variar de unas naves a otras. El jugador puede
colisionar con ellas y perderá el control de la nave durante unos breves instantes. Sin
embargo, durante este periodo de tiempo será invulnerable tanto a los disparos como a
nuevas colisiones con otras naves.
8.5.5.2 Modo aventura
Utiliza su propio sistema de control que no puede ser redefinido en las opciones del juego. La
cámara adopta una vista en primera persona desde los ojos de McBride, el protagonista del
juego. Para girar la cabeza y observar los elementos que rodean al jugador se emplea el
mando analógico, mientras que el desplazamiento se consigue pulsando los botones de
dirección (▲, ▼, ►, ◄). Para subir por las escaleras es necesario mirar ligeramente hacia
arriba.
128
MANUAL DE USUARIO
Figura 8.21. Portales y HUD del modo aventura.
1. Portal. Representa un punto de salida del mapa actual. Cuando el jugador entra en él,
abandona el escenario y vuelve al menú del modo individual.
2. HUD. Es un pequeño punto rojo que siempre se muestra en el centro de la pantalla y

que el jugador utiliza para seleccionar los elementos del entorno con los que desea
interactuar.
Figura 8.22. Personajes del modo aventura.
El General de White Rock espera al jugador en la sala de operaciones del hangar. Es el

único elemento del escenario con el que se puede interactuar. Para ello basta con
colocarse dentro de su radio de acción y pulsar el botón (X).
129
Figura 8.23. Mensaje interacción del modo aventura.
Al interactuar con un elemento del escenario se muestra una ventana con un mensaje que
describe el resultado de la acción. En el caso del General, se visualiza la conversación que
mantiene con el jugador.
8.6 ERRORES CONOCIDOS

La versión alfa de Air Warriors presentada en este manual tiene algunos errores que se pasan
a describir a continuación:
• Tras finalizar la misión del modo arcade se debería volver a la pantalla del menú de
juego individual. Esto no siempre ocurre así, pero la PSP puede bloquearse en ese
momento.
• Tras finalizar cualquier de los modos de juego no se puede volver a iniciar ninguno de
estos, siendo necesario cerrar la aplicación y volver a iniciarla.
• De manera imprevista, el juego puede bloquearse al seleccionar las opciones de los

diferentes menús.
• Aunque no se pulse el mando analógico, cuando la aplicación requiere su utilización se

comporta como si estuviera siendo pulsado a la izquierda constantemente.
130
CONCLUSIONES
9.CONCLUSIONES
El proyecto fin de carrera como su nombre claramente indica es el último proyecto de una
carrera universitaria. Un proyecto que hemos asumido como el punto y final para una aventura
académica que comenzó hace ya 5 años y que marcará en gran medida nuestro camino en el
mundo laboral. ¿Por qué un videojuego para la plataforma PSP? Cada uno de nosotros tiene
sus propias motivaciones, pero ante todo subyace el deseo por trabajar en aquello con lo que
disfrutamos y qué mejor manera de hacerlo que asumiendo el reto que entraña una tecnología
relativamente nueva.
La labor de investigación llevada a cabo ha permitido profundizar nuestros conocimientos sobre

el manejo de gráficos 3D y su aplicación a la creación de videojuegos. También ha servido para
descubrir las posibilidades que una videoconsola como la PSP presenta de cara a la
programación de videojuegos, así como las ofrecidas por la conexión WI-FI para el desarrollo
de nuevas formas de jugabilidad.
El motor gráfico escogido (LTE GE) demuestra que actualmente es posible disponer de un
conjunto de librerías 3D no comerciales casi tan elaboradas y estables como las que hay
disponibles en un PC. Esto unido a las diferentes aplicaciones disponibles para la depuración
del código reafirma la excelente labor realizada por la comunidad de usuarios que pone todas
estas herramientas a disposición de aquellos interesados en desarrollar contenido
personalizado.
Aunque el diseño y posterior implementación del videojuego se han visto afectados por algunas
limitaciones inesperadas del motor gráfico, se ha conseguido completar con éxito el objetivo
planteado inicialmente: desarrollar un videojuego funcional para la plataforma PSP. La
arquitectura basada en una máquina de estados ha resultado ser una decisión de diseño
fundamental para estructurar el flujo de ejecución. Igualmente se ha planteado la base de un
sistema basado en comportamientos para los diferentes nodos del grafo de escena. Al aislar
los complejos comportamientos lógicos en unidades asignables más pequeñas se ha
conseguido un diseño más claro y flexible.
Finalmente este proyecto nos ha permitido asumir otros roles además de los ligados al
desarrollo. También hemos sido responsables de su planificación y organización. Sin duda, la
experiencia adquirida durante estos 3 meses será de inestimable ayuda en el futuro.
131
GLOSARIO
10. GLOSARIO
AT3 ATRAC3. Formato para archivos de sonido desarrollado por Sony.
AVC Advanced Video Coding. Un formato digital de compresión de vídeo.
API Application Programming Interface. Interfaz en código fuente proporcionada

por una librería para hacer uso de sus servicios.
Billboard Un elemento bidimensional que siempre mira a la cámara. Se usa

generalmente para representar explosiones, fuego o partículas.
CLUT Colour Look-Up Table. Dispositivo que convierte en colores físicos los
números lógicos de colores almacenados en cada píxel de la memoria de
vídeo. Así pueden ser visualizados en la pantalla de la PSP.
CPU Central Processing Unit. Componente que interpreta las instrucciones de un

programa y procesa datos.
Custom Firmware modificado ajeno a Sony que permite utilizar toda la funcionalidad
Firmware de un firmware oficial evitando sus restricciones.
DMA Direct Memory Access. Tecnología que permite que un dispositivo hardware
pueda acceder directamente a la memoria del sistema independientemente
de la CPU.
DRAM Dynamic Random Access Memory. Tipo de memoria RAM que almacena
cada bit en un capacitador dentro de un circuito integrado.
DXT Una familia de la implementación del algoritmo de compresión de texturas de

S3.
Downgrade Proceso consistente en sustituir una versión de firmware de la PSP por otra
más atrasada.
ELF Executable Linking Format. Formato de archivo especificado por el Tool

Interface Standards Committee usado por los objetos ejecutables de la PSP.
133
Exploit Código diseñado para aprovechar algún fallo, error o vulnerabilidad del
sistema y ganar control sobre la PSP.
Firmware Software embebido en la PSP que proporciona la funcionalidad básica de la

videoconsola. Se encuentra almacenado en la memoria flash y cualquier
modificación realizada sobre el mismo debe hacerse con mucho cuidado. Un
error durante la escritura en la memoria flash puede dejar inutilizable la PSP.
FPU Floating-point Unit. Componente hardware especializado en realizar

operaciones con números en coma flotante.
GCC GNU Compiler Collection. Conjunto de compiladores de lenguajes de

programación producidos por el proyecto GNU.
GE Graphics Engine. Librería diseñada para manejar el adaptador gráfico de un

computador.
GNU GNU’s Not Unix. Sistema operativo compuesto exclusivamente por software
libre. Su nombre viene dado porque su diseño se parece a Unix, aunque
difiere de este en que es software libre y además no contiene código de Unix.
GNU Binutils Un conjunto de herramientas de programación para la manipulación de

código objeto en varios formatos.
GUI Graphical User Interface. Tipo de interfaz de usuario que permite interactuar
con un computador mediante un entorno gráfico (iconos y etiquetas de texto).
Homebrew Aplicaciones desarrolladas sin usar el SDK oficial por los usuarios de la PSP.
HUD Head Up Display. Hace referencia al interfaz de un videojuego que muestra

información relevante para el jugador mientras se desarrolla la acción.
IDE Integrated Development Environment. Entorno de desarrollo integrado.
LCD Liquid Crystal Display. Pantalla fina y delgada.
LTE GE LTE Game Engine. Nombre del conjunto de librerías que conforman el motor
para el desarrollo de videojuegos creado por LTE Studios.
Lua Lenguaje de programación ligero, procedimental e imperativo, diseñado

como un lenguaje de scripting con una semántica extensible.
MIPS Microprocessor without Interlocked Pipeline Stages. Arquitectura RISC de

microprocesador empleada especialmente en sistemas embebidos.
MMU Memory Management Unit. Componente hardware responsable de gestionar
134
GLOSARIO
las peticiones de acceso a memoria realizadas por la CPU.
MP3 MPEG-1 Audio Layer 3. Formato de codificación de sonido.
PBP Playstation Bootable/Binary Protocol. Nombre de los ejecutables (realmente

ficheros comprimidos) de la PSP. Equivaldría aun archivo EXE de Windows.
PDP Packet Datagram Protocol. Protocolo de transferencia de paquetes usado por

la PSP en redes inalámbricas.
PFX Playstation Fixed eXecutable. Archivo ELF con un formato especial que lo
ubica en una posición de memoria predeterminada. El núcleo de la PSP
intentará cargarlo en la dirección especificada. Si no lo consigue, el proceso
de carga fallará.
PRX Playstation Relocatable eXecutable. Archivo ELF con un formato especial

que permite al núcleo de la PSP cambiar la posición del módulo en memoria
durante su carga.
PSP PlayStation Portable. Videoconsola portátil desarrollada por Sony.
PS2 PlayStation 2. Segunda videoconsola desarrollad por Sony.
RAM Random Access Memory. Tipo de almacenamiento de datos formado por un

conjunto de circuitos integrados que permite acceder a la información en
cualquier orden.
SDK Software Development Kit. Conjunto de herramientas de desarrollo

necesarias para construir aplicaciones para la PSP.
SDL Simple DirectMedia Layer. Librería de programación multimedia.
SIO Serial Input Output. Término utilizado para hacer referencia a la

comunicación con un dispositivo a través del puerto serie.
UMD Universal Media Disc. Tipo de disco óptico desarrollado por Sony para la
PSP. Puede almacenar hasta 1.7 GB.
USB Universal Serial Bus. Bus serie estándar para la comunicación entre
dispositivos.
VFPU Vector Floating-point Unit. Componente hardware diseñado para operar con
vectores y matrices.
VME Virtual Mobile Engine. Unidad de procesamiento adicional encargada de la

decodificación de audio y vídeo.
135
VRAM Video Random Access Memory. Tipo de memoria DRAM utilizada para
almacenar el mapa de bits (frame buffer) que posteriormente se dibuja en la
pantalla.
WAV Waveform Audio Format. Formato propietario de Microsoft e IBM para

archivos de sonido.
WI-FI Wireless Fidelity. Conjunto de estándares para redes inalámbricas basados

en las especificaciones 802.11. Creado para ser utilizado en redes locales
inalámbricas, es frecuente que en la actualidad también se utilice para
acceder a Internet.
XMB Cross Media Bar. Nombre que recibe el menú de la PSP.
136
BIBLIOGRAFÍA
11. BIBLIOGRAFÍA
[1] BARREDO, A. CASTILLO, C. (2006). Gestión y planificación de proyectos.
Universidad de Deusto.
[2] LTE STUDIOS. LTE Game Engine Documentation. http://www.ltestudios.com.

1/6/2007.
[3] TyRaNiD. The Naked PSP. http://www.ps2dev.org. 13/6/2007.
[4] ELOTROLADO. http://www.elotrolado.net. 1/6/2007.
[5] GEARDOME. Inicio Programación PSP. http://www.geardome.com/blog/tutorial-

psp. 5/6/2007.
[6] PROFESSORQ. Introduction to Quake III Level Editing.

http://professorq.planetquake.gamespy.com/wwwc/3DVG/q3tutorials/q3editing.htm.
19/7/2007.
137
AGRADECIMIENTOS
12. AGRADECIMIENTOS
Para terminar la documentación de este proyecto nos gustaría agradecer la ayuda recibida a
nivel personal y académico de diferentes personas.
En lo académico nuestro agradecimiento a Alejandro de Celis, nuestro director de proyecto, por

confiar en nosotros y aceptar nuestra propuesta.
Al equipo de LTE Studios, desarrolladores de la librería LTE GE que ha hecho posible la

implementación del proyecto. Y especialmente a SiberianSTAR, miembro del equipo y siempre
dispuesto a responder rápidamente ante los problemas encontrados.
Ya en el plano personal, debemos agradecer a nuestras familias su inestimable apoyo e

interés.
139

Air Warriors Documentation

Cargado por

Copyright:

Formatos disponibles

Air Warriors Documentation

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Air Warriors Documentation

Cargado por

Copyright:

Formatos disponibles

Proyecto fin de carrera

Desarrollo de un videojuego en la plataforma

Jon Alonso Masa

Director: Alejandro de Celis Solana

Bilbao, septiembre de 2007

Un videojuego es un programa informático creado fundamentalmente para divertir. Se basa en

El propósito de este proyecto es desarrollar un videojuego en una plataforma novedosa como

Programación 3D, WI-FI, videojuego, PSP, C++.

2. OBJETIVOS DEL PROYECTO .............................................................................................. 3

2.1 NECESIDAD DE PARTIDA....................................................................................................3

4. ESPECIFICACIÓN DE REQUISITOS DEL SISTEMA ............................................................ 61

4.1 INTRODUCCIÓN ............................................................................................................... 61

5. ESPECIFICACIÓN DEL DISEÑO........................................................................................ 71

5.1 INTRODUCCIÓN ............................................................................................................... 71

6. CONSIDERACIONES SOBRE LA IMPLEMENTACIÓN .................................................... 101

6.1 INTRODUCCIÓN ............................................................................................................. 101

7. PLAN DE PRUEBAS ......................................................................................................... 109

8. MANUAL DE USUARIO................................................................................................... 115

9. CONCLUSIONES ............................................................................................................ 131

10. GLOSARIO ..................................................................................................................... 133

11. BIBLIOGRAFÍA................................................................................................................ 137

12. AGRADECIMIENTOS...................................................................................................... 139

1. Introducción. Descripción del contenido del resto de los capítulos.

3. Investigación tecnológica. Documento que presenta una elaboración teórica de las

4. Especificación de requisitos del sistema. Describe los diferentes requisitos exigidos

6. Consideraciones sobre la implementación. Recoge los diferentes aspectos a incluir

9. Conclusiones. Análisis de los objetivos alcanzados y consideraciones adicionales.

Al final de la memoria se incluye la bibliografía y una serie de anexos, a saber: glosario y

2. OBJETIVOS DEL PROYECTO

2.1 NECESIDAD DE PARTIDA

2.2 DEFINICIÓN DEL PROYECTO

2.2.1 Objetivos del proyecto

El objetivo fundamental del proyecto es el desarrollo de un videojuego funcional aprovechando

2.2.2 Alcance del proyecto

A continuación se indican los diferentes aspectos que estarán presentes en el proyecto:

• Resumen de las características técnicas de la PSP, configuración y puesta a punto de

• Diseño e implementación de un videojuego que haga uso de las tecnologías de

• Creación de librerías que puedan ser de utilidad para posteriores desarrollos de

2.3 PRODUCTO FINAL

• Documentos de requisitos del sistema. Incluye la especificación formal de la

• Videojuego. Es el producto central del proyecto y se basa esencialmente en la

• Manual de usuario. Con toda la información relativa al manejo del videojuego

• Guía de programación de videojuegos para la PSP. Es el resultado tanto de la

• Librerías de utilidad para el desarrollo de videojuegos. De manera opcional,

2.4 DESCRIPCIÓN DE LA REALIZACIÓN

2.4.1 Método de desarrollo

Por último, el departamento de pruebas se encargará de pulir fallos relacionados con la

2.4.2 Tareas principales

a. Organización. Actividad mediante la que se define y prepara la planificación,

b. Control. Seguimiento y control del desarrollo del proyecto, que permita la

2. Concepto. Actividad mediante la que se trata de definir el videojuego a realizar con

3. Preproducción. Se diseñan todos los aspectos que configuran el videojuego y que

a. Argumento y personajes. Desarrollo de la temática e historia principal del

b. Escenarios. Descripción de los escenarios en los que se desarrollará el

d. Investigación tecnológica. Qué tipo de tecnologías hacen falta, evaluar

5. Diseño detallado. Diseño de los módulos necesarios para desarrollar el videojuego

6. Producción. Se pasa a construir la funcionalidad y contenidos específicos del juego

7. Desarrollo de los módulos fundamentales.

b. Tecnologías de Inteligencias Artificial. Desarrollo de los módulos

c. Interfaz de juego. Implementación de la interfaz de juego en forma de menús