desarrollo videojuegos 1 - arquitectura del motor de videojuegos.pdf

Click here to load reader

Post on 30-Nov-2015

74 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • ABCDEFEBDEEE

  • DDBBBABDDBBDABABCDEFEBDEEECDEF ! "" #$% &'ABCBDBEFBFFA(CDEF ! "" #$%" "FDBDF )*B+'AB(,*DBD-BD'FDFB( ABCDEFEDB.BEFBDBBA DB.BEFBDB

    /*DB0B12BBE,342DDE2EDB.BEFBDB5DB.DBED-,2BDED0DBE6BE.789)ED97E+52:2E:00-

    AAB ABA;*DB2D9D*DB1ED2B B*D 1ED2? 2BD BD B EBD- @- AB B1D- AB 2 D B*D 2D ?EB1D-&-5EB*DD-AB2DD9 DE0BD1DBEDDEB*DD2DDB*D-FE0BD1BEEC2DDDB11BE-BDDED* E ED&-$D

  • ABABACDEDCFBACAABBAADD EDCFBBACB A B!" #$ C%& DFDD'DC BABACD A DE(CA A )CBD *+, DFD FAADC A -.'AA A -BBDA -C DB "/ A -CDAD ,A%B/ ) ' CA'BADBAF%DA012"B'3DFDAACCDDA-BBDA%ACAAADF-'DCABAFBCB%'BD/

    CDEF 4 ,DDC )'CD-AD A EDCFBBACB A B!" #$ A 5CDEADC'A,DDCABF-CADABA)'AAEDCFB A B' *A "$ A B'CCABDD EDCFB0CEB5CDCFB6BAF 7-ACBD AA 8/ 'FAA 'BB BABDC BC A DCD 9BBBABAA D 6BAF'B!AA A *AACB,BCB%'BD/

  • Prefacio

    Este libro forma parte de una coleccin de cuatro volmenes dedi-cados al Desarrollo de Videojuegos. Con un perfil principalmente tcni-co, estos cuatro libros cubren los aspectos esenciales en programacinde videojuegos:

    1. Arquitectura del Motor. En este primer libro se estudian losaspectos esenciales del diseo de un motor de videojuegos, ascomo las tcnicas bsicas de programacin y patrones de diseo.

    2. Programacin Grfica. El segundo libro de la coleccin se centraen los algoritmos y tcnicas de representacin grfica y optimiza-ciones en sistemas de despliegue interactivo.

    3. Tcnicas Avanzadas. En este tercer volumen se recogen ciertosaspectos avanzados, como estructuras de datos especficas, tc-nicas de validacin y pruebas o simulacin fsica.

    4. Desarrollo de Componentes. El ltimo libro est dedicado aciertos componentes especficos del motor, como la InteligenciaArtificial, Networking, Sonido y Multimedia o tcnicas avanzadasde Interaccin.

    Sobre este libro...

    Este libro que tienes en tus manos es una ampliacin y revisinde los apuntes del Curso de Experto en Desarrollo de Videojuegos, im-partido en la Escuela Superior de Informtica de Ciudad Real de laUniversidad de Castilla-La Mancha. Puedes obtener ms informacinsobre el curso, as como los resultados de los trabajos creados por losalumnos en la web del mismo: http://www.esi.uclm.es/videojuegos.

    La versin electrnica de este manual (y del resto de libros de lacoleccin) puede descargarse desde la web anterior. El libro fsicopuede adquirirse desde la pgina web de la editorial online Bubok enhttp://www.bubok.es.

  • Requisitos previos

    Este libro tiene un pblico objetivo con un perfil principalmentetcnico. Al igual que el curso del que surgi, est orientado a la capac-itacin de profesionales de la programacin de videojuegos. De estaforma, este libro no est orientado para un pblico de perfil artstico(modeladores, animadores, msicos, etc) en el mbito de los videojue-gos.

    Se asume que el lector es capaz de desarrollar programas de nivelmedio en C y C++. Aunque se describen algunos aspectos clave de C++a modo de resumen, es recomendable refrescar los conceptos bsicoscon alguno de los libros recogidos en la bibliografa del curso. De igualmodo, se asume que el lector tiene conocimientos de estructuras dedatos y algoritmia. El libro est orientado principalmente para titula-dos o estudiantes de ltimos cursos de Ingeniera en Informtica.

    Programas y cdigo fuente

    El cdigo de los ejemplos del libro pueden descargarse en la si-guiente pgina web: http://www.esi.uclm.es/videojuegos. Salvo quese especifique explcitamente otra licencia, todos los ejemplos del librose distribuyen bajo GPLv3.

    Agradecimientos

    Los autores del libro quieren agradecer en primer lugar a los alum-nos de la primera edicin del Curso de Experto en Desarrollo de Video-juegos por su participacin en el mismo y el excelente ambiente en lasclases, las cuestiones planteadas y la pasin demostrada en el desa-rrollo de todos los trabajos.

    De igual modo, se quiere reflejar el agradecimiento especial al per-sonal de administracin y servicios de la Escuela Superior de Infor-mtica, por su soporte, predisposicin y ayuda en todos los capri-chosos requisitos que plantebamos a lo largo del curso.

    Por otra parte, este agradecimiento tambin se hace extensivo ala Escuela de Informatica de Ciudad Real y al Departamento de Tec-nologas y Sistema de Informacin de la Universidad de Castilla-LaMancha.

    Finalmente, los autores desean agradecer su participacin a loscolaboradores de esta primera edicin: Indra Software Labs, la aso-ciacin de desarrolladores de videojuegos Stratos y a Libro Virtual.

  • Resumen

    El objetivo de este mdulo, titulado Arquitectura del Motor dentrodel Curso de Experto en Desarrollo de Videojuegos, es introducir losconceptos bsicos relativos a las estructuras y principios de diseoy desarrollo comnmente empleados en la creacin de videojuegos.Para ello, uno de los principales objetivos es proporcionar una visingeneral de la arquitectura general de un motor de juegos.

    Dentro del contexto de esta arquitectura general se hace especialhincapi en aspectos como los subsistemas de bajo nivel, el bucle dejuego, la gestin bsica de recursos, como el sonido, y la gestin de laconcurrencia. Para llevar a cabo una discusin prctica de todos estoselementos se hace uso del motor de renderizado Ogre3D.

    Por otra parte, en este primer mdulo tambin se estudian los fun-damentos del lenguaje de programacin C++ como herramienta funda-mental para el desarrollo de videojuegos profesionales. Este estudio secomplementa con una discusin en profundidad de una gran variedadde patrones de diseo y de la biblioteca STL. Adems, tambin se rea-liza un recorrido por herramientas que son esenciales en el desarrollode proyectos software complejos, como por ejemplo los sistemas decontrol de versiones, o procesos como la compilacin o la depuracin.

    I

  • ndice general

    1. Introduccin 1

    1.1. El desarrollo de videojuegos . . . . . . . . . . . . . . . . . 1

    1.1.1. La industria del videojuego. Presente y futuro . . . 1

    1.1.2. Estructura tpica de un equipo de desarrollo . . . . 3

    1.1.3. El concepto de juego . . . . . . . . . . . . . . . . . . 6

    1.1.4. Motor de juego . . . . . . . . . . . . . . . . . . . . . 8

    1.1.5. Gneros de juegos . . . . . . . . . . . . . . . . . . . 9

    1.2. Arquitectura del motor. Visin general . . . . . . . . . . . 15

    1.2.1. Hardware, drivers y sistema operativo . . . . . . . 16

    1.2.2. SDKs y middlewares . . . . . . . . . . . . . . . . . . 17

    1.2.3. Capa independiente de la plataforma . . . . . . . . 18

    1.2.4. Subsistemas principales . . . . . . . . . . . . . . . 18

    1.2.5. Gestor de recursos . . . . . . . . . . . . . . . . . . . 19

    1.2.6. Motor de rendering . . . . . . . . . . . . . . . . . . . 20

    1.2.7. Herramientas de depuracin . . . . . . . . . . . . . 23

    1.2.8. Motor de fsica . . . . . . . . . . . . . . . . . . . . . 23

    1.2.9. Interfaces de usuario . . . . . . . . . . . . . . . . . 24

    1.2.10.Networking y multijugador . . . . . . . . . . . . . . 25

    1.2.11.Subsistema de juego . . . . . . . . . . . . . . . . . . 25

    1.2.12.Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 27

    1.2.13.Subsistemas especficos de juego . . . . . . . . . . 28

    2. Herramientas de Desarrollo 29

    III

  • 2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . 29

    2.2. Compilacin, enlazado y depuracin . . . . . . . . . . . . 30

    2.2.1. Conceptos bsicos . . . . . . . . . . . . . . . . . . . 31

    2.2.2. Compilando con GCC . . . . . . . . . . . . . . . . . 33

    2.2.3. Cmo funciona? . . . . . . . . . . . . . . . . . . . . 34

    2.2.4. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . 36

    2.2.5. Otras herramientas . . . . . . . . . . . . . . . . . . 42

    2.2.6. Depurando con GNU GDB . . . . . . . . . . . . . . 42

    2.2.7. Construccin automtica con GNU Make . . . . . . 49

    2.3. Gestin de proyectos y documentacin . . . . . . . . . . . 54

    2.3.1. Sistemas de control de versiones . . . . . . . . . . 55

    2.3.2. Documentacin . . . . . . . . . . . . . . . . . . . . . 60

    2.3.3. Forjas de desarrollo . . . . . . . . . . . . . . . . . . 63

    3. C++. Aspectos Esenciales 67

    3.1. Utilidades bsicas . . . . . . . . . . . . . . . . . . . . . . . 67

    3.1.1. Introduccin a C++ . . . . . . . . . . . . . . . . . . 67

    3.1.2. Hola Mundo! en C++ . . . . . . . . . . . . . . . . . 68

    3.1.3. Tipos, declaraciones y modificadores . . . . . . . . 69

    3.1.4. Punteros, arrays y estructuras . . . . . . . . . . . . 70

    3.1.5. Referencias y funciones . . . . . . . . . . . . . . . . 74

    3.2. Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

    3.2.1. Fundamentos bsicos . . . . . . . . . . . . . . . . . 78

    3.2.2. Aspectos especficos de las clases . . . . . . . . . . 80

    3.2.3. Sobrecarga de operadores . . . . . . . . . . . . . . . 85

    3.3. Herencia y polimorfismo . . . . . . . . . . . . . . . . . . . 88

    3.3.1. Herencia . . . . . . . . . . . . . . . . . . . . . . . . . 88

    3.3.2. Herencia mltiple . . . . . . . . . . . . . . . . . . . 91

    3.3.3. Funciones virtuales y polimorfismo . . . . . . . . . 95

    3.4. Plantillas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

    3.4.1. Caso de estudio. Listas . . . . . . . . . . . . . . . . 100

    3.4.2. Utilizando plantillas en C++ . . . . . . . . . . . . . 102

    3.4.3. Cundo utilizar plantillas? . . . . . . . . . . . . . 104

    3.5. Manejo de excepciones . . . . . . . . . . . . . . . . . . . . 105

    3.5.1. Alternativas existentes . . . . . . . . . . . . . . . . 105

  • 3.5.2. Excepciones en C++ . . . . . . . . . . . . . . . . . . 107

    3.5.3. Cmo manejar excepciones adecuadamente? . . . 110

    3.5.4. Cundo utilizar excepciones? . . . . . . . . . . . . 112

    4. Patrones de Diseo 115

    4.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . 116

    4.1.1. Estructura de un patrn de diseo . . . . . . . . . 116

    4.1.2. Tipos de patrones . . . . . . . . . . . . . . . . . . . 118

    4.2. Patrones de creacin . . . . . . . . . . . . . . . . . . . . . 118

    4.2.1. Singleton . . . . . . . . . . . . . . . . . . . . . . . . 118

    4.2.2. Abstract Factory . . . . . . . . . . . . . . . . . . . . 120

    4.2.3. Factory Method . . . . . . . . . . . . . . . . . . . . . 124

    4.2.4. Prototype . . . . . . . . . . . . . . . . . . . . . . . . 125

    4.3. Patrones estructurales . . . . . . . . . . . . . . . . . . . . 127

    4.3.1. Composite . . . . . . . . . . . . . . . . . . . . . . . . 127

    4.3.2. Decorator . . . . . . . . . . . . . . . . . . . . . . . . 128

    4.3.3. Facade . . . . . . . . . . . . . . . . . . . . . . . . . . 131

    4.3.4. MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

    4.3.5. Adapter . . . . . . . . . . . . . . . . . . . . . . . . . 134

    4.3.6. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

    4.4. Patrones de comportamiento . . . . . . . . . . . . . . . . . 138

    4.4.1. Observer . . . . . . . . . . . . . . . . . . . . . . . . . 138

    4.4.2. State . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

    4.4.3. Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . 142

    4.4.4. Template Method . . . . . . . . . . . . . . . . . . . . 144

    4.4.5. Strategy . . . . . . . . . . . . . . . . . . . . . . . . . 146

    4.4.6. Reactor . . . . . . . . . . . . . . . . . . . . . . . . . 147

    4.4.7. Visitor . . . . . . . . . . . . . . . . . . . . . . . . . . 149

    5. La Biblioteca STL 153

    5.1. Visin general de STL . . . . . . . . . . . . . . . . . . . . . 153

    5.2. STL y el desarrollo de videojuegos . . . . . . . . . . . . . . 157

    5.2.1. Reutilizacin de cdigo . . . . . . . . . . . . . . . . 157

    5.2.2. Rendimiento . . . . . . . . . . . . . . . . . . . . . . 158

    5.2.3. Inconvenientes . . . . . . . . . . . . . . . . . . . . . 159

    5.3. Secuencias . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

  • 5.3.1. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 160

    5.3.2. Deque . . . . . . . . . . . . . . . . . . . . . . . . . . 163

    5.3.3. List . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

    5.4. Contenedores asociativos . . . . . . . . . . . . . . . . . . . 168

    5.4.1. Set y multiset . . . . . . . . . . . . . . . . . . . . . . 169

    5.4.2. Map y multimap . . . . . . . . . . . . . . . . . . . . 172

    5.5. Adaptadores de secuencia . . . . . . . . . . . . . . . . . . 175

    5.5.1. Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

    5.5.2. Queue . . . . . . . . . . . . . . . . . . . . . . . . . . 177

    5.5.3. Cola de prioridad . . . . . . . . . . . . . . . . . . . . 177

    6. Sistemas del Motor de Bajo Nivel 179

    6.1. Subsistema de arranque y parada . . . . . . . . . . . . . . 180

    6.1.1. Aspectos fundamentales . . . . . . . . . . . . . . . 180

    6.1.2. Esquema tpico de arranque y parada . . . . . . . . 183

    6.1.3. Caso de estudio. Ogre 3D . . . . . . . . . . . . . . . 184

    6.1.4. Caso de estudio. Quake III . . . . . . . . . . . . . . 187

    6.2. Contenedores . . . . . . . . . . . . . . . . . . . . . . . . . . 190

    6.2.1. Iteradores . . . . . . . . . . . . . . . . . . . . . . . . 190

    6.2.2. Ms all de STL . . . . . . . . . . . . . . . . . . . . 192

    6.3. Subsistema de gestin de cadenas . . . . . . . . . . . . . 196

    6.3.1. Cuestiones especficas . . . . . . . . . . . . . . . . . 196

    6.3.2. Optimizando el tratamiento de cadenas . . . . . . . 198

    6.3.3. Hashing de cadenas . . . . . . . . . . . . . . . . . . 199

    6.4. Configuracin del motor . . . . . . . . . . . . . . . . . . . 200

    6.4.1. Esquemas tpicos de configuracin . . . . . . . . . 201

    6.4.2. Caso de estudio. Esquemas de definicin. . . . . . 202

    7. El Bucle de Juego 205

    7.1. El bucle de renderizado . . . . . . . . . . . . . . . . . . . . 205

    7.2. El bucle de juego . . . . . . . . . . . . . . . . . . . . . . . . 206

    7.3. Arquitecturas tpicas del bucle de juego . . . . . . . . . . 208

    7.3.1. Tratamiento de mensajes en Windows . . . . . . . 208

    7.3.2. Esquemas basados en retrollamadas . . . . . . . . 208

    7.3.3. Tratamiento de eventos . . . . . . . . . . . . . . . . 210

    7.3.4. Esquema basado en estados . . . . . . . . . . . . . 210

  • 7.4. Gestin de estados de juego con Ogre3D . . . . . . . . . . 211

    7.5. Definicin de estados concretos . . . . . . . . . . . . . . . 218

    8. Importador de Datos de Intercambio 221

    8.1. Formatos de intercambio . . . . . . . . . . . . . . . . . . . 222

    8.1.1. Archivos binarios . . . . . . . . . . . . . . . . . . . . 222

    8.1.2. Archivos en texto plano . . . . . . . . . . . . . . . . 223

    8.1.3. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

    8.2. Creacin de un importador . . . . . . . . . . . . . . . . . . 225

    8.2.1. Justificacin y estructura XML . . . . . . . . . . . . 225

    8.2.2. Lgica de dominio . . . . . . . . . . . . . . . . . . . 228

    8.2.3. La clase Importer . . . . . . . . . . . . . . . . . . . . 230

    9. Recursos y el sistema de archivos 233

    9.1. Gestin bsica de recursos . . . . . . . . . . . . . . . . . . 233

    9.2. Gestin de recursos con Ogre3D . . . . . . . . . . . . . . . 234

    9.3. Gestin bsica del sonido . . . . . . . . . . . . . . . . . . . 235

    9.3.1. Introduccin a SDL . . . . . . . . . . . . . . . . . . 235

    9.3.2. Reproduccin de msica . . . . . . . . . . . . . . . 238

    9.3.3. Soporte de efectos de sonido . . . . . . . . . . . . . 243

    9.3.4. Integrando msica y efectos . . . . . . . . . . . . . 244

    9.4. El sistema de archivos . . . . . . . . . . . . . . . . . . . . 246

    9.4.1. Gestin y tratamiento de archivos . . . . . . . . . . 247

    9.4.2. E/S bsica . . . . . . . . . . . . . . . . . . . . . . . 250

    9.4.3. E/S asncrona . . . . . . . . . . . . . . . . . . . . . 252

    9.4.4. Caso de estudio. La biblioteca Boost.Asio C++ . . . 254

    9.4.5. Consideraciones finales . . . . . . . . . . . . . . . . 260

    10.Hilos y Concurrencia 261

    10.1.Fundamentos bsicos . . . . . . . . . . . . . . . . . . . . . 262

    10.1.1.El concepto de hilo . . . . . . . . . . . . . . . . . . . 262

    10.1.2.El problema de la seccin crtica . . . . . . . . . . . 263

    10.2.La biblioteca de hilos de ICE . . . . . . . . . . . . . . . . . 264

    10.2.1.The Internet Communications Engine (ICE) . . . . . 264

    10.2.2.Manejo de hilos . . . . . . . . . . . . . . . . . . . . . 265

    10.2.3.Exclusin mutua bsica . . . . . . . . . . . . . . . . 269

  • 10.2.4.Flexibilizando el concepto de mutex . . . . . . . . . 272

    10.2.5.Introduciendo monitores . . . . . . . . . . . . . . . 273

    10.3.Multi-threading en Ogre3D . . . . . . . . . . . . . . . . . . 279

    10.4.Caso de estudio. Procesamiento en segundo plano me-diante hilos . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

  • Captulo1Introduccin

    David Vallejo Fernndez

    A ctualmente, la industria del videojuego goza de una muy bue-na salud a nivel mundial, rivalizando en presupuesto con lasindustrias cinematogrfica y musical. En este captulo se dis-cute, desde una perspectiva general, el desarrollo de videojuegos,haciendo especial hincapi en su evolucin y en los distintos elemen-tos involucrados en este complejo proceso de desarrollo. En la segundaparte del captulo se introduce el concepto de arquitectura del mo-tor, como eje fundamental para el diseo y desarrollo de videojuegoscomerciales.

    1.1. El desarrollo de videojuegos

    1.1.1. La industria del videojuego. Presente y futuro

    El primer videojuego

    El videojuego Pong se consi-dera como unos de los pri-meros videojuegos de la his-toria. Desarrollado por Atarien 1975, el juego iba inclui-do en la consola Atari Pong.Se calcula que se vendieronunas 50.000 unidades.

    Lejos han quedado los das desde el desarrollo de los primeros vi-deojuegos, caracterizados principalmente por su simplicidad y por elhecho de estar desarrollados completamente sobre hardware. Debidoa los distintos avances en el campo de la informtica, no slo a nivelde desarrollo software y capacidad hardware sino tambin en la apli-cacin de mtodos, tcnicas y algoritmos, la industria del videojuegoha evolucionado hasta llegar a cotas inimaginables, tanto a nivel dejugabilidad como de calidad grfica, tan slo hace unos aos.

    La evolucin de la industria de los videojuegos ha estado ligadaa una serie de hitos, determinados particularmente por juegos quehan marcado un antes y un despus, o por fenmenos sociales quehan afectado de manera directa a dicha industria. Juegos como Doom,

    1

  • [2] CAPTULO 1. INTRODUCCIN

    Quake, Final Fantasy, Zelda, Tekken, Gran Turismo, Metal Gear, TheSims o World of Warcraft, entre otros, han marcado tendencia y hancontribuido de manera significativa al desarrollo de videojuegos en dis-tintos gneros.

    Por otra parte, y de manera complementaria a la aparicin de estasobras de arte, la propia evolucin de la informtica ha posibilitadola vertiginosa evolucin del desarrollo de videojuegos. Algunos hitosclave son por ejemplo el uso de la tecnologa poligonal en 3D [1] en lasconsolas de sobremesa, el boom de los ordenadores personales comoplataforma multi-propsito, la expansin de Internet, los avances en eldesarrollo de microprocesadores, el uso de shaders programables [9],el desarrollo de motores de juegos o, ms recientemente, la eclosinde las redes sociales y el uso masivo de dispositivos mviles.

    Por todo ello, los videojuegos se pueden encontrar en ordenado-res personales, consolas de juego de sobremesa, consolas porttiles,dispositivos mviles como por ejemplo los smartphones, o incluso enlas redes sociales como medio de soporte para el entretenimiento decualquier tipo de usuario. Esta diversidad tambin est especialmenteligada a distintos tipos o gneros de videojuegos, como se introducirms adelante en esta misma seccin.

    La expansin del videojuego es tan relevante que actualmente setrata de una industria multimillonaria capaz de rivalizar con las in-dustrias cinematogrfica y musical. Un ejemplo representativo es elvalor total del mercado del videojuego en Europa, tanto a nivel hard-ware como software, el cual alcanz la nada desdeable cifra de casi11.000 millones de euros, con pases como Reino Unido, Francia oAlemania a la cabeza. En este contexto, Espaa representa el cuartoconsumidor a nivel europeo y tambin ocupa una posicin destacadadentro del ranking mundial.

    Figura 1.1: El desarrollo y lainnovacin en hardware tam-bin supone un pilar funda-mental en la industria del vi-deojuego.

    A pesar de la vertiginosa evolucin de la industria del videojuego,hoy en da existe un gran nmero de retos que el desarrollador devideojuegos ha de afrontar a la hora de producir un videojuego. Enrealidad, existen retos que perdurarn eternamente y que no estnligados a la propia evolucin del hardware que permite la ejecucinde los videojuegos. El ms evidente de ellos es la necesidad imperiosade ofrecer una experiencia de entretenimiento al usuario basada en ladiversin, ya sea a travs de nuevas formas de interaccin, como porejemplo la realidad aumentada o la tecnologa de visualizacin 3D, atravs de una mejora evidente en la calidad de los ttulos, o medianteinnovacin en aspectos vinculados a la jugabilidad.

    No obstante, actualmente la evolucin de los videojuegos est es-trechamente ligada a la evolucin del hardware que permite la eje-cucin de los mismos. Esta evolucin atiende, principalmente, a dosfactores: i) la potencia de dicho hardware y ii) las capacidades inter-activas del mismo. En el primer caso, una mayor potencia hardwa-re implica que el desarrollador disfrute de mayores posibilidades a lahora de, por ejemplo, mejorar la calidad grfica de un ttulo o de in-crementar la inteligencia artificial de los enemigos. Este factor estvinculado al multiprocesamiento. En el segundo caso, una mayor ri-queza en trminos de interactividad puede contribuir a que el usuario

  • 1.1. El desarrollo de videojuegos [3]

    de videojuegos viva una experiencia ms inmersiva (por ejemplo, me-diante realidad aumentada) o, simplemente, ms natural (por ejemplo,mediante la pantalla tctil de un smartphone).

    Finalmente, resulta especialmente importante destacar la existen-cia de motores de juego (game engines), como por ejemplo Quake1 oUnreal2, middlewares para el tratamiento de aspectos especficos deun juego, como por ejemplo la biblioteca Havok3 para el tratamientode la fsica, o motores de renderizado, como por ejemplo Ogre 3D [7].Este tipo de herramientas, junto con tcnicas especficas de desarro-llo y optimizacin, metodologas de desarrollo, o patrones de diseo,entre otros, conforman un aspecto esencial a la hora de desarrollarun videojuego. Al igual que ocurre en otros aspectos relacionados conla Ingeniera del Software, desde un punto de vista general resultaaconsejable el uso de todos estos elementos para agilizar el procesode desarrollo y reducir errores potenciales. En otras palabras, no esnecesario, ni productivo, reinventar la rueda cada vez que se afrontaun nuevo proyecto.

    1.1.2. Estructura tpica de un equipo de desarrollo

    Tiempo real

    En el mbito del desarrollode videojuegos, el conceptode tiempo real es muy impor-tante para dotar de realismoa los juegos, pero no es tanestricto como el concepto detiempo real manejado en lossistemas crticos.

    El desarrollo de videojuegos comerciales es un proceso complejo de-bido a los distintos requisitos que ha de satisfacer y a la integracin dedistintas disciplinas que intervienen en dicho proceso. Desde un puntode vista general, un videojuego es una aplicacin grfica en tiemporeal en la que existe una interaccin explcita mediante el usuario yel propio videojuego. En este contexto, el concepto de tiempo real serefiere a la necesidad de generar una determinada tasa de frames oimgenes por segundo, tpicamente 30 60, para que el usuario tengauna sensacin continua de realidad. Por otra parte, la interaccin serefiere a la forma de comunicacin existente entre el usuario y el vi-deojuego. Normalmente, esta interaccin se realiza mediante joystickso mandos, pero tambin es posible llevarla a cabo con otros disposi-tivos como por ejemplo teclados, ratones, cascos o incluso medianteel propio cuerpo a travs de tcnicas de visin por computador o deinteraccin tctil.

    A continuacin se describe la estructura tpica de un equipo dedesarrollo atendiendo a los distintos roles que juegan los componen-tes de dicho equipo [5]. En muchos casos, y en funcin del nmerode componentes del equipo, hay personas especializadas en diversasdisciplinas de manera simultnea.

    Los ingenieros son los responsables de disear e implementar elsoftware que permite la ejecucin del juego, as como las herramientasque dan soporte a dicha ejecucin. Normalmente, los ingenieros sesuelen clasificar en dos grandes grupos:

    1http://www.idsoftware.com/games/quake/quake/2http://www.unrealengine.com/3http://www.havok.com

  • [4] CAPTULO 1. INTRODUCCIN

    A

    BCDAEF

    CC

    CFC

    CC

    AA

    A

    AFA

    AACCA

    AA !ACECF !ACACA"

    #CAA $CAC!C%#CAA #C&ACC

    'AC!

    "

    ACA

    (C)

    !AA

    CC AFACC !ACC&A !AC!C%

    Figura 1.2: Visin conceptual de un equipo de desarrollo de videojuegos, considerando especialmente la parte de programa-cin.

    Los programadores del ncleo del juego, es decir, las personasresponsables de desarrollar tanto el motor de juego como el juegopropiamente dicho.

    Los programadores de herramientas, es decir, las personas res-ponsables de desarrollar las herramientas que permiten que elresto del equipo de desarrollo pueda trabajar de manera eficien-te.

    De manera independiente a los dos grupos mencionados, los in-genieros se pueden especializar en una o en varias disciplinas. Porejemplo, resulta bastante comn encontrar perfiles de ingenieros es-pecializados en programacin grfica o en scripting e Inteligencia Ar-tificial. Sin embargo, tal y como se sugiri anteriormente, el conceptode ingeniero transversal es bastante comn, particularmente en equi-pos de desarrollo que tienen un nmero reducido de componentes ocon un presupuesto que no les permite la contratacin de personasespecializadas en una nica disciplina.

    En el mundo del desarrollo de videojuegos, es bastante probableencontrar ingenieros senior responsables de supervisar el desarrollodesde un punto de vista tcnico, de manera independiente al diseoy generacin de cdigo. No obstante, este tipo de roles suelen estarasociados a la supervisin tcnica, la gestin del proyecto e incluso

  • 1.1. El desarrollo de videojuegos [5]

    a la toma de decisiones vinculadas a la direccin del proyecto. Asmismo, algunas compaas tambin pueden tener directores tcnicos,responsables de la supervisin de uno o varios proyectos, e inclusoun director ejecutivo, encargado de ser el director tcnico del estudiocompleto y de mantener, normalmente, un rol ejecutivo en la compaao empresa.

    Los artistas son los responsables de la creacin de todo el conte-nido audio-visual del videojuego, como por ejemplo los escenarios, lospersonajes, las animaciones de dichos personajes, etc. Al igual queocurre en el caso de los ingenieros, los artistas tambin se puedenespecializar en diversas cuestiones, destacando las siguientes:

    General VS Especfico

    En funcin del tamao deuna empresa de desarrollo devideojuegos, el nivel de espe-cializacin de sus empleadoses mayor o menor. Sin em-bargo, las ofertas de trabajosuelen incluir diversas disci-plinas de trabajo para facili-tar su integracin.

    Artistas de concepto, responsables de crear bocetos que permitanal resto del equipo hacerse una idea inicial del aspecto final delvideojuego. Su trabajo resulta especialmente importante en lasprimeras fases de un proyecto.

    Modeladores, responsables de generar el contenido 3D del video-juego, como por ejemplo los escenarios o los propios personajesque forman parte del mismo.

    Artistas de texturizado, responsables de crear las texturas o im-genes bidimensionales que formarn parte del contenido visualdel juego. Las texturas se aplican sobre la geometra de los mo-delos con el objetivo de dotarlos de mayor realismo.

    Artistas de iluminacin, responsables de gestionar las fuentes deluz del videojuego, as como sus principales propiedades, tantoestticas como dinmicas.

    Animadores, responsables de dotar de movimientos a los perso-najes y objetos dinmicos del videojuego. Un ejemplo tpico deanimacin podra ser el movimiento de brazos de un determina-do carcter.

    Actores de captura de movimiento, responsables de obtener datosde movimiento reales para que los animadores puedan integrar-los a la hora de animar los personajes.

    Diseadores de sonido, responsables de integrar los efectos desonido del videojuego.

    Otros actores, responsables de diversas tareas como por ejemplolos encargados de dotar de voz a los personajes.

    Al igual que suele ocurrir con los ingenieros, existe el rol de artistasenior cuyas responsabilidades tambin incluyen la supervisin de losnumerosos aspectos vinculados al componente artstico.

    Los diseadores de juego son los responsables de disear el con-tenido del juego, destacando la evolucin del mismo desde el principiohasta el final, la secuencia de captulos, las reglas del juego, los objeti-vos principales y secundarios, etc. Evidentemente, todos los aspectosde diseo estn estrechamente ligados al propio gnero del mismo. Por

  • [6] CAPTULO 1. INTRODUCCIN

    ejemplo, en un juego de conduccin es tarea de los diseadores defi-nir el comportamiento de los coches adversarios ante, por ejemplo, eladelantamiento de un rival.

    Los diseadores suelen trabajar directamente con los ingenierospara afrontar diversos retos, como por ejemplo el comportamiento delos enemigos en una aventura. De hecho, es bastante comn que lospropios diseadores programen, junto con los ingenieros, dichos as-pectos haciendo uso de lenguajes de scripting de alto nivel, como porejemplo LUA4 o Python5.

    Scripting e IA

    El uso de lenguajes de altonivel es bastante comn enel desarrollo de videojuegosy permite diferenciar clara-mente la lgica de la aplica-cin y la propia implementa-cin. Una parte significativade las desarrolladoras utilizasu propio lenguaje de scrip-ting, aunque existen lengua-jes ampliamente utilizados,como son LUA o Python.

    Como ocurre con las otras disciplinas previamente comentadas, enalgunos estudios los diseadores de juego tambin juegan roles degestin y supervisin tcnica.

    Finalmente, en el desarrollo de videojuegos tambin estn presen-tes roles vinculados a la produccin, especialmente en estudios de ma-yor capacidad, asociados a la planificacin del proyecto y a la gestinde recursos humanos. En algunas ocasiones, los productores tam-bin asumen roles relacionados con el diseo del juego. As mismo,los responsables de marketing, de administracin y de soporte jueganun papel relevante. Tambin resulta importante resaltar la figura depublicador como entidad responsable del marketing y distribucin delvideojuego desarrollado por un determinado estudio. Mientras algunosestudios tienen contratos permanentes con un determinado publica-dor, otros prefieren mantener una relacin temporal y asociarse con elpublicador que le ofrezca mejores condiciones para gestionar el lanza-miento de un ttulo.

    1.1.3. El concepto de juego

    Dentro del mundo del entretenimiento electrnico, un juego nor-malmente se suele asociar a la evolucin, entendida desde un puntode vista general, de uno o varios personajes principales o entidadesque pretenden alcanzar una serie de objetivos en un mundo acota-do, los cuales estn controlados por el propio usuario. As, entre es-tos elementos podemos encontrar desde superhroes hasta coches decompeticin pasando por equipos completos de ftbol. El mundo en elque conviven dichos personajes suele estar compuesto, normalmente,por una serie de escenarios virtuales recreados en tres dimensiones ytiene asociado una serie de reglas que determinan la interaccin conel mismo.

    De este modo, existe una interaccin explcita entre el jugador ousuario de videojuegos y el propio videojuego, el cual plantea una se-rie de retos al usuario con el objetivo final de garantizar la diversin yel entretenimiento. Adems de ofrecer este componente emocional, losvideojuegos tambin suelen tener un componente cognitivo asociado,obligando a los jugadores a aprender tcnicas y a dominar el compor-tamiento del personaje que manejan para resolver los retos o puzzlesque los videojuegos plantean.

    4http://www.lua.org5http://www.python.org

  • 1.1. El desarrollo de videojuegos [7]

    Desde una perspectiva ms formal, la mayora de videojuegos su-ponen un ejemplo representativo de lo que se define como aplicacionesgrficas o renderizado en tiempo real [1], las cuales se definen a suvez como la rama ms interactiva de la Informtica Grfica. Desde unpunto de vista abstracto, una aplicacin grfica en tiempo real se basaen un bucle donde en cada iteracin se realizan los siguientes pasos:

    El usuario visualiza una imagen renderizada por la aplicacin enla pantalla o dispositivo de visualizacin.

    El usuario acta en funcin de lo que haya visualizado, interac-tuando directamente con la aplicacin, por ejemplo mediante unteclado.

    En funcin de la accin realizada por el usuario, la aplicacingrfica genera una salida u otra, es decir, existe una retroalimen-tacin que afecta a la propia aplicacin.

    Cada de frames

    Si el ncleo de ejecucin deun juego no es capaz demantener los fps a un ni-vel constante, el juego sufri-r una cada de frames en unmomento determinado. Estehecho se denomina comn-mente como ralentizacin.

    En el caso de los videojuegos, este ciclo de visualizacin, actuaciny renderizado ha de ejecutarse con una frecuencia lo suficientementeelevada como para que el usuario se sienta inmerso en el videojuego,y no lo perciba simplemente como una sucesin de imgenes est-ticas. En este contexto, el frame rate se define como el nmero deimgenes por segundo, comnmente fps, que la aplicacin grfica escapaz de generar. A mayor frame rate, mayor sensacin de realismoen el videojuego. Actualmente, una tasa de 30 fps se considera msque aceptable para la mayora de juegos. No obstante, algunos juegosofrecen tasas que doblan dicha medida.

    Generalmente, el desarrollador de videojuegos ha de buscar uncompromiso entre los fps y el grado de realismo del videojue-go. Por ejemplo, el uso de modelos con una alta complejidadcomputacional, es decir, con un mayor nmero de polgonos, ola integracin de comportamientos inteligentes por parte de losenemigos en un juego (non-player characters o NPCs) disminui-r los fps.

    En otras palabras, los juegos son aplicaciones interactivas que es-tn marcadas por el tiempo, es decir, cada uno de los ciclos de ejecu-cin tiene un deadline que ha de cumplirse para no perder realismo.

    Aunque el componente grfico representa gran parte de la com-plejidad computacional de los videojuegos, no es el nico. En cadaciclo de ejecucin, el videojuego ha de tener en cuenta la evolucin delmundo en el que se desarrolla el mismo. Dicha evolucin dependerdel estado de dicho mundo en un momento determinado y de cmo lasdistintas entidades dinmicas interactan con l. Obviamente, recrearel mundo real con un nivel de exactitud elevado no resulta manejableni prctico, por lo que normalmente dicho mundo se aproxima y sesimplifica, utilizando modelos matemticos para tratar con su com-

  • [8] CAPTULO 1. INTRODUCCIN

    plejidad. En este contexto, destaca por ejemplo la simulacin fsica delos propios elementos que forman parte del mundo.

    Por otra parte, un juego tambin est ligado al comportamiento delpersonaje principal y del resto de entidades que existen dentro delmundo virtual. En el mbito acadmico, estas entidades se suelen de-finir como agentes (agents) y se encuadran dentro de la denominadasimulacin basada en agentes [8]. Bsicamente, este tipo de aproxi-maciones tiene como objetivo dotar a los NPCs con cierta inteligenciapara incrementar el grado de realismo de un juego estableciendo, in-cluso, mecanismos de cooperacin y coordinacin entre los mismos.Respecto al personaje principal, un videojuego ha de contemplar lasdistintas acciones realizadas por el mismo, considerando la posibilidadde decisiones impredecibles a priori y las consecuencias que podrandesencadenar.

    Figura 1.3: El motor de juegorepresenta el ncleo de un vi-deojuego y determina el com-portamiento de los distintosmdulos que lo componen.

    En resumen, y desde un punto de vista general, el desarrollo deun juego implica considerar un gran nmero de factores que, inevita-blemente, incrementan la complejidad del mismo y, al mismo tiempo,garantizar una tasa de fps adecuada para que la inmersin del usuariono se vea afectada.

    1.1.4. Motor de juego

    Al igual que ocurre en otras disciplinas en el campo de la inform-tica, el desarrollo de videojuegos se ha beneficiado de la aparicin deherramientas que facilitan dicho desarrollo, automatizando determi-nadas tareas y ocultando la complejidad inherente a muchos procesosde bajo nivel. Si, por ejemplo, los sistemas de gestin de bases de da-tos (SGBDs) han facilitado enormemente la gestin de persistencia deinnumerables aplicaciones informticas, los motores de juegos hacenla vida ms sencilla a los desarrolladores de videojuegos.

    Segn [5], el trmino motor de juego surgi a mediados de los aos90 con la aparicin del famossimo juego de accin en primera perso-na Doom, desarrollado por la compaa id Software bajo la direccinde John Carmack6. Esta afirmacin se sustenta sobre el hecho de queDoom fue diseado con una arquitectura orientada a la reutiliza-cin mediante una separacin adecuada en distintos mdulos de loscomponentes fundamentales, como por ejemplo el sistema de rende-rizado grfico, el sistema de deteccin de colisiones o el sistema deaudio, y los elementos ms artsticos, como por ejemplo los escenariosvirtuales o las reglas que gobernaban al propio juego.

    Figura 1.4: John Carmack,uno de los desarrolladores dejuegos ms importantes, enel Game Developer Conferen-ce del ao 2010.

    Este planteamiento facilitaba enormemente la reutilizacin de soft-ware y el concepto de motor de juego se hizo ms popular a medi-da que otros desarrolladores comenzaron a utilizar diversos mduloso juegos previamente licenciados para generar los suyos propios. Enotras palabras, era posible disear un juego del mismo tipo sin ape-nas modificar el ncleo o motor del juego, sino que el esfuerzo se podadirigir directamente a la parte artstica y a las reglas del mismo.

    6http://en.wikipedia.org/wiki/John_D._Carmack

  • 1.1. El desarrollo de videojuegos [9]

    Este enfoque ha ido evolucionando y se ha expandido, desde lageneracin de mods por desarrolladores independientes o amateurshasta la creacin de una gran variedad de herramientas, bibliotecase incluso lenguajes que facilitan el desarrollo de videojuegos. A da dehoy, una gran parte de compaas de desarrollo de videojuego utilizanmotores o herramientas pertenecientes a terceras partes, debido a queles resulta ms rentable econmicamente y obtienen, generalmente,resultados espectaculares. Por otra parte, esta evolucin tambin hapermitido que los desarrolladores de un juego se planteen licenciarparte de su propio motor de juego, decisin que tambin forma partede su poltica de trabajo.

    Obviamente, la separacin entre motor de juego y juego nunca estotal y, por una circunstancia u otra, siempre existen dependencias di-rectas que no permiten la reusabilidad completa del motor para crearotro juego. La dependencia ms evidente es el genero al que est vin-culado el motor de juego. Por ejemplo, un motor de juegos diseadopara construir juegos de accin en primera persona, conocidos tradi-cionalmente como shooters o shootem all, ser difcilmente reutilizablepara desarrollar un juego de conduccin.

    Una forma posible para diferenciar un motor de juego y el softwareque representa a un juego est asociada al concepto de arquitecturadirigida por datos (data-driven architecture). Bsicamente, cuando unjuego contiene parte de su lgica o funcionamiento en el propio cdigo(hard-coded logic), entonces no resulta prctico reutilizarla para otrojuego, ya que implicara modificar el cdigo fuente sustancialmente.Sin embargo, si dicha lgica o comportamiento no est definido a nivelde cdigo, sino por ejemplo mediante una serie de reglas definidas atravs de un lenguaje de script, entonces la reutilizacin s es posibley, por lo tanto, beneficiosa, ya que optimiza el tiempo de desarrollo.

    Game engine tuning

    Los motores de juegos sesuelen adaptar para cubrirlas necesidades especficasde un ttulo y para obtenerun mejor rendimiento.

    Como conclusin final, resulta relevante destacar la evolucin re-lativa a la generalidad de los motores de juego, ya que poco a pocoestn haciendo posible su utilizacin para diversos tipos de juegos.Sin embargo, el compromiso entre generalidad y optimalidad an estpresente. En otras palabras, a la hora de desarrollar un juego utilizan-do un determinado motor es bastante comn personalizar dicho motorpara adaptarlo a las necesidades concretas del juego a desarrollar.

    1.1.5. Gneros de juegos

    Los motores de juegos suelen estar, generalmente, ligados a un tipoo gnero particular de juegos. Por ejemplo, un motor de juegos dise-ado con la idea de desarrollar juegos de conduccin diferir en granparte con respecto a un motor orientado a juegos de accin en terce-ra persona. No obstante, y tal y como se discutir en la seccin 1.2,existen ciertos mdulos, sobre todo relativos al procesamiento de msbajo nivel, que son transversales a cualquier tipo de juego, es decir,que se pueden reutilizar en gran medida de manera independiente algnero al que pertenezca el motor. Un ejemplo representativo podraser el mdulo de tratamiento de eventos de usuario, es decir, el m-dulo responsable de recoger y gestionar la interaccin del usuario a

  • [10] CAPTULO 1. INTRODUCCIN

    travs de dispositivos como el teclado, el ratn, el joystick o la panta-lla tctil. Otros ejemplo podra ser el mdulo de tratamiento del audioo el mdulo de renderizado de texto.

    A continuacin, se realizar una descripcin de los distintos g-neros de juegos ms populares atendiendo a las caractersticas quediferencian unos de otros en base al motor que les da soporte. Estadescripcin resulta til para que el desarrollador identifique los aspec-tos crticos de cada juego y utilice las tcnicas de desarrollo adecuadaspara obtener un buen resultado.

    Mercado de shooters

    Los FPS gozan actualmentede un buen momento y, comoconsecuencia de ello, el n-mero de ttulos disponibleses muy elevado, ofreciandouna gran variedad al usuariofinal.

    Probablemente, el gnero de juegos ms popular ha sido y es el delos los denominados first-person shooters (FPS), abreviado tradicio-nalmente como shooters, representado por juegos como Quake, Half-Life, Call of Duty o Gears of War, entre muchos otros. En este gnero,el usuario normalmente controla a un personaje con una vista en pri-mera persona a lo largo de escenarios que tradicionalmente han sidointeriores, como los tpicos pasillos, pero que han ido evolucionando aescenarios exteriores de gran complejidad.

    Figura 1.5: Captura de pantalla del juego Tremulous R, licenciado bajo GPL y desarro-llado sobre el motor de Quake III.

    Los FPS representan juegos con un desarrollo complejo, ya queuno de los retos principales que han de afrontar es la inmersin delusuario en un mundo hiperrealista que ofrezca un alto nivel de detalle,al mismo tiempo que se garantice una alta reaccin de respuesta a lasacciones del usuario. Este gnero de juegos se centra en la aplicacinde las siguientes tecnologas [5]:

  • 1.1. El desarrollo de videojuegos [11]

    Renderizado eficiente de grandes escenarios virtuales 3D.

    Mecanismo de respuesta eficiente para controlar y apuntar conel personaje.

    Detalle de animacin elevado en relacin a las armas y los brazosdel personaje virtual.

    Uso de una gran variedad de arsenal.

    Sensacin de que el personaje flota sobre el escenario, debido almovimiento del mismo y al modelo de colisiones.

    NPCs con un nivel de inteligencia artificial considerable y dotadosde buenas animaciones.

    Inclusin de opciones multijugador a baja escala, tpicamente en-tre 32 y 64 jugadores.

    Normalmente, la tecnologa de renderizado de los FPS est especial-mente optimizada atendiendo, entre otros factores, al tipo de escenarioen el que se desarrolla el juego. Por ejemplo, es muy comn utilizarestructuras de datos auxiliares para disponer de ms informacin delentorno y, consecuentemente, optimizar el clculo de diversas tareas.Un ejemplo muy representativo en los escenarios interiores son losbinary space partitioning (BSP) trees (rboles de particin binaria delespacio ) [1], que se utilizan para realizar una divisin del espacio f-sico en dos partes, de manera recursiva, para optimizar, por ejemplo,aspectos como el clculo de la posicin de un jugador. Otro ejemplo re-presentativo en el caso de los escenarios exteriores es el denominadoocclusion culling [1], que se utiliza para optimizar el proceso de rende-rizado descartando aquellos objetos 3D que no se ven desde el puntode vista de la cmara, reduciendo as la carga computacional de dichoproceso.

    En el mbito comercial, la familia de motores Quake, creados porId Software, se ha utilizado para desarrollar un gran nmero de jue-gos, como la saga Medal of Honor, e incluso motores de juegos. Hoy esposible descargar el cdigo fuente de Quake, Quake II y Quake III 7 yestudiar su arquitectura para hacerse una idea bastante aproximadade cmo se construyen los motores de juegos actuales.

    Otra familia de motores ampliamente conocida es la de Unreal, jue-go desarrollado en 1998 por Epic Games. Actualmente, la tecnologaUnreal Engine se utiliza en multitud de juegos, algunos de ellos tanfamosos como Gears of War.

    Ms recientemente, la compaa Crytek ha permitido la descargadel CryENGINE 3 SDK (Software Development Kit)8 para propsitos nocomerciales, sino principalmente acadmicos y con el objetivo de crearuna comunidad de desarrollo. Este kit de desarrollo para aplicacionesgrficas en tiempo real es exactamente el mismo que el utilizado por la

    7http://www.idsoftware.com/business/techdownloads8http://mycryengine.com/

  • [12] CAPTULO 1. INTRODUCCIN

    propia compaa para desarrollar juegos comerciales, como por ejem-plo Crysis 2.

    Otro de los gneros ms relevantes son los denominados juegos entercera persona, donde el usuario tiene el control de un personajecuyas acciones se pueden apreciar por completo desde el punto devista de la cmara virtual. Aunque existe un gran parecido entre estegnero y el de los FPS, los juegos en tercera persona hacen especialhincapi en la animacin del personaje, destacando sus movimientosy habilidades, adems de prestar mucha atencin al detalle grfico dela totalidad de su cuerpo. Ejemplos representativos de este gnero sonResident Evil, Metal Gear, Gears of War o Uncharted, entre otros.

    Figura 1.6: Captura de pantalla del juego Turtlearena R, licenciado bajo GPL y desarro-llado sobre el motor de Quake III.

    Super Mario Bros

    El popular juego de Mario, di-seado en 1985 por ShigeruMiyamoto, ha vendido apro-ximadamente 40 millones dejuegos a nivel mundial. Se-gn el libro de los RecordGuinness, es una de los jue-gos ms vendidos junto a Te-tris y a la saga de Pokemon.

    Dentro de este gnero resulta importante destacar los juegos deplataformas, en los que el personaje principal ha de ir avanzado deun lugar a otro del escenario hasta alcanzar un objetivo. Ejemplos re-presentativos son las sagas de Super Mario, Sonic o Donkey Kong. Enel caso particular de los juegos de plataformas, el avatar del persona-je tiene normalmente un efecto de dibujo animado, es decir, no suelenecesitar un renderizado altamente realista y, por lo tanto, comple-jo. En cualquier caso, la parte dedicada a la animacin del personajeha de estar especialmente cuidada para incrementar la sensacin derealismo a la hora de controlarlo.

    En los juegos en tercera persona, los desarrolladores han de prestarespecial atencin a la aplicacin de las siguientes tecnologas [5]:

  • 1.1. El desarrollo de videojuegos [13]

    Uso de plataformas mviles, equipos de escalado, cuerdas y otrosmodos de movimiento avanzados.

    Inclusin de puzzles en el desarrollo del juego.

    Uso de cmaras de seguimiento en tercera persona centradas enel personaje y que posibiliten que el propio usuario las maneje asu antojo para facilitar el control del personaje virtual.

    Uso de un complejo sistema de colisiones asociado a la cmarapara garantizar que la visin no se vea dificultada por la geome-tra del entorno o los distintos objetos dinmicos que se muevenpor el mismo.

    Grficos 3D

    Virtua Fighter, lanzado en1993 por Sega y desarrolladopor Yu Suzuki, se consideracomo el primer juego de lu-cha arcade en soportar grfi-cos tridimensionales.

    Otro gnero importante est representado por los juegos de lucha,en los que, normalmente, dos jugadores compiten para ganar un de-terminado nmero de combatos minando la vida o stamina del jugadorcontrario. Ejemplos representativos de juegos de lucha son Virtua Figh-ter, Street Fighter, Tekken, o Soul Calibur, entre otros. Actualmente, losjuegos de lucha se desarrollan normalmente en escenarios tridimen-sionales donde los luchadores tienen una gran libertad de movimiento.Sin embargo, ltimamente se han desarrollado diversos juegos en losque tanto el escenario como los personajes son en 3D, pero donde elmovimiento de los mismos est limitado a dos dimensiones, enfoquecomnmente conocido como juegos de lucha de scroll lateral.

    Debido a que en los juegos de lucha la accin se centra general-mente en dos personajes, stos han de tener una gran calidad grficay han de contar con una gran variedad de movimientos y animacionespara dotar al juego del mayor realismo posible. As mismo, el escenariode lucha suele estar bastante acotado y, por lo tanto, es posible sim-plificar su tratamiento y, en general, no es necesario utilizar tcnicasde optimizacin como las comentadas en el gnero de los FPS. Por otraparte, el tratamiento de sonido no resulta tan complejo como lo puedeser en otros gneros de accin.

    Los juegos del gnero de la lucha han de prestar atencin a la de-teccin y gestin de colisiones entre los propios luchadores, o entre lasarmas que utilicen, para dar una sensacin de mayor realismo. Ade-ms, el mdulo responsable del tratamiento de la entrada al usuarioha de ser lo suficientemente sofisticado para gestionar de manera ade-cuada las distintas combinaciones de botones necesarias para realizarcomplejos movimientos. Por ejemplo, juegos como Street Fighter IV in-corporan un sistema de timing entre los distintos movimientos de uncombo. El objetivo perseguido consiste en que dominar completamentea un personaje no sea una tarea sencilla y requiera que el usuario devideojuegos dedique tiempo al entrenaiento del mismo.

    Los juegos de lucha, en general, han estado ligados a la evolucinde tcnicas complejas de sntesis de imagen aplicadas sobre los pro-pios personajes con el objetivo de mejorar al mximo su calidad y, deeste modo, incrementar su realismo. Un ejemplo representativo es eluso de shaders [9] sobre la armadura o la propia piel de los perso-najes que permitan implementar tcnicas como el bump mapping [1],planteada para dotar a estos elementos de un aspecto ms rugoso.

  • [14] CAPTULO 1. INTRODUCCIN

    Otro gnero representativo en el mundo de los videojuegos es laconduccin, en el que el usuario controla a un vehculo que nor-malmente rivaliza con ms adversarios virtuales o reales para llegara la meta en primera posicin. En este gnero se suele distinguir en-tre simuladores, como por ejemplo Gran Turismo, y arcade, como porejemplo Ridge Racer o Wipe Out.

    Simuladores F1

    Los simuladores de juegos deconduccin no slo se utili-zan para el entretenimientodomstico sino tambin pa-ra que, por ejemplo, los pi-lotos de Frmula-1 conozcantodos los entresijos de los cir-cuitos y puedan conocerlos aldetalle antes de embarcarseen los entrenamientos reales.

    Mientras los simuladores tienen como objetivo principal represen-tar de la manera ms fidedigna posible el comportamiento del vehculoy su interaccin con el escenario, los juegos arcade se centran ms enla jugabilidad para que cualquier tipo de usuario no tenga problemasde conduccin.

    Los juegos de conduccin se caracterizan por la necesidad de dedi-car un esfuerzo considerable en alcanzar una calidad grfica elevadaen aquellos elementos cercanos a la cmara, especialmente el propiovehculo. Adems, este tipo de juegos, aunque suelen ser muy lineales,mantienen una velocidad de desplazamiento muy elevada, directamen-te ligada a la del propio vehculo.

    Al igual que ocurre en el resto de gneros previamente comentados,existen diversas tcnicas que pueden contribuir a mejorar la eficienciade este tipo de juegos. Por ejemplo, suele ser bastante comn utilizarestructuras de datos auxiliares para dividir el escenario en distintostramos, con el objetivo de optimizar el proceso de renderizado o inclusofacilitar el clculo de rutas ptimas utilizando tcnicas de InteligenciaArtificial [10]. Tambin se suelen usar imgenes para renderizar ele-mentos lejanos, como por ejemplo rboles, vallas publicitarias u otrotipo de elementos.

    Figura 1.7: Captura de pan-talla del juego de conduccinTux Racing, licenciado bajoGPL por Jasmin Patry.

    Del mismo modo, y al igual que ocurre con los juegos en tercerapersona, la cmara tiene un papel relevante en el seguimiento del jue-go. En este contexto, el usuario normalmente tiene la posibilidad deelegir el tipo de cmara ms adecuado, como por ejemplo una cma-ra en primera persona, una en la que se visualicen los controles delpropio vehculo o una en tercera persona.

    Otro gnero tradicional son los juegos de estrategia, normalmenteclasificados en tiempo real (real-time strategy o RTS) y por turnos (turn-based strategy). Ejemplos representativos de este gnero sonWarcraft,Command & Conquer, Comandos, Age of Empires o Starcraft, entreotros. Este tipo de juegos se caracterizan por mantener una cmaracon una perspectiva isomtrica, normalmente fija, de manera que eljugador tiene una visin ms o menos completa del escenario, ya sea2D o 3D. As mismo, es bastante comn encontrar un gran nmerode unidades virtuales desplegadas en el mapa, siendo responsabilidaddel jugador su control, desplazamiento y accin.

    Figura 1.8: Captura de pan-talla del juego de estrategiaen tiempo real 0 A.D., licen-ciado bajo GPL por Wildfire-games.

    Teniendo en cuenta las caractersticas generales de este gnero, esposible plantear diversas optimizaciones. Por ejemplo, una de las apro-ximaciones ms comunes en este tipo de juegos consiste en dividir elescenario en una rejilla o grid, con el objetivo de facilitar no slo elemplazamiento de unidades o edificios, sino tambin la planificacinde movimiento de un lugar del mapa a otro. Por otra parte, las uni-dades se suelen renderizar con una resolucin baja, es decir, con un

  • 1.2. Arquitectura del motor. Visin general [15]

    bajo nmero de polgonos, con el objetivo de posibilitar el desplieguede un gran nmero de unidades de manera simultnea.

    Finalmente, en los ltimos aos ha aparecido un gnero de juegoscuya principal caracterstica es la posibilidad de jugar con un grannmero de jugadores reales al mismo tiempo, del orden de cientos oincluso miles de jugadores. Los juegos que se encuadran bajo este g-nero se denomina comnmente MMOG (Massively Multiplayer OnlineGame). El ejemplo ms representativo de este gnero es el juego Worldof Warcarft. Debido a la necesidad de soportar un gran nmero dejugadores en lnea, los desarrolladores de este tipo de juegos han derealizar un gran esfuerzo en la parte relativa al networking, ya que hande proporcionar un servicio de calidad sobre el que construir su mode-lo de negocio, el cual suele estar basado en suscripciones mensualeso anuales por parte de los usuarios.

    Al igual que ocurre en los juegos de estrategia, los MMOG suelenutilizar personajes virtuales en baja resolucin para permitir la apari-cin de un gran nmero de ellos en pantalla de manera simultnea.

    Adems de los distintos gneros mencionados en esta seccin, exis-ten algunos ms como por ejemplo los juegos deportivos, los juegos derol (RPG, role-playing games) o los juegos de puzzles.

    Antes de pasar a la siguiente seccin en la que se discutir la arqui-tectura general de un motor de juego, resulta interesante destacar laexistencia de algunas herramientas libres que se pueden utilizar pa-ra la construccin de un motor de juegos. Una de las ms populares,y que se utilizar en el presente curso, es OGRE 3D9. Bsicamente,OGRE es un motor de renderizado 3D bien estructurado y con unacurva de aprendizaje adecuada. Aunque OGRE no se puede definircomo un motor de juegos completo, s que proporciona un gran n-mero de mdulos que permiten integrar funcionalidades no triviales,como por ejemplo iluminacin avanzada o sistemas de animacin decaracteres.

    1.2. Arquitectura del motor. Visin general

    En esta seccin se plantea una visin general de la arquitecturade un motor de juegos [5], de manera independiente al gnero de losmismos, prestando especial importancia a los mdulos ms relevantesdesde el punto de vista del desarrollo de videojuegos.

    Como ocurre con la gran mayora de sistemas software que tienenuna complejidad elevada, los motores de juegos se basan en una ar-quitectura estructurada en capas. De este modo, las capas de nivelsuperior dependen de las capas de nivel inferior, pero no de mane-ra inversa. Este planteamiento permite ir aadiendo capas de maneraprogresiva y, lo que es ms importante, permite modificar determi-nados aspectos de una capa en concreto sin que el resto de capasinferiores se vean afectadas por dicho cambio.

    9http://www.ogre3d.org/

  • [16] CAPTULO 1. INTRODUCCIN

    A continuacin, se describen los principales mdulos que formanparte de la arquitectura que se expone en la figura 1.9.

    A

    BACDEFCF

    ECEEECFD

    BAACDAEA

    ACFEEAFA

    FCFE

    DCAEAFF

    FCFEA

    CAEAF

    CFBAACDEF

    F

    BAACDAEAFAEEF

    ABCDEFE!EEAAC

    Figura 1.9: Visin conceptual de la arquitectura general de un motor de juegos. Esque-ma adaptado de la arquitectura propuesta en [5].

    La arquitectura Cell

    En arquitecturas ms nove-dosas, como por ejemplo laarquitectura Cell usada enPlaystation 3 y desarrolladapor Sony, Toshiba e IBM,las optimizaciones aplicadassuelen ser ms dependientesde la plataforma final.

    1.2.1. Hardware, drivers y sistema operativo

    La capa relativa al hardware est vinculada a la plataforma en laque se ejecutar el motor de juego. Por ejemplo, un tipo de plataformaespecfica podra ser una consola de juegos de sobremesa. Muchos delos principios de diseo y desarrollo son comunes a cualquier video-juego, de manera independiente a la plataforma de despliegue final.Sin embargo, en la prctica los desarrolladores de videojuegos siem-pre llevan a cabo optimizaciones en el motor de juegos para mejorar la

  • 1.2. Arquitectura del motor. Visin general [17]

    eficiencia del mismo, considerando aquellas cuestiones que son espe-cficas de una determinada plataforma.

    La capa de drivers soporta aquellos componentes software de bajonivel que permiten la correcta gestin de determinados dispositivos,como por ejemplo las tarjetas de aceleracin grfica o las tarjetas desonido.

    La capa del sistema operativo representa la capa de comunicacinentre los procesos que se ejecutan en el mismo y los recursos hard-ware asociados a la plataforma en cuestin. Tradicionalmente, en elmundo de los videojuegos los sistemas operativos se compilan con elpropio juego para producir un ejecutable. Sin embargo, las consolas deltima generacin, como por ejemplo Sony Playstation 3 R o MicrosoftXBox 360 R, incluyen un sistema operativo capaz de controlar ciertosrecursos e incluso interrumpir a un juego en ejecucin, reduciendo laseparacin entre consolas de sobremesa y ordenadores personales.

    1.2.2. SDKs y middlewares

    Al igual que ocurre en otros proyectos software, el desarrollo de unmotor de juegos se suele apoyar en bibliotecas existentes y Softwa-re Development Kits (SDKs) para proporcionar una determinada fun-cionalidad. No obstante, y aunque generalmente este software estbastante optimizado, algunos desarrolladores prefieren personalizarlopara adaptarlo a sus necesidades particulares, especialmente en con-solas de sobremesa y porttiles.

    APIs grficas

    OpenGL y Direct3D son losdos ejemplos ms represen-tativos de APIs grficas quese utilizan en el mbito co-mercial. La principal diferen-cia entre ambas es la estan-darizacin, factor que tienesus ventajas y desventajas.

    Un ejemplo representativo de biblioteca para el manejo de estruc-turas de datos es STL (Standard Template Library)10. STL es una bi-blioteca de plantillas estndar para C++, el cual representa a su vez ellenguaje ms extendido actualmente para el desarrollo de videojuegos,debido principalmente a su portabilidad y eficiencia.

    En el mbito de los grficos 3D, existe un gran nmero de bi-bliotecas de desarrollo que solventan determinados aspectos que soncomunes a la mayora de los juegos, como por ejemplo el renderizadode modelos tridimensionales. Los ejemplos ms representativos en es-te contexto son las APIs grficas OpenGL11 y Direct3D, mantenidas porel grupo Khronos y Microsoft, respectivamente. Este tipo de bibliotecastienen como principal objetivo ocultar los diferentes aspectos de lastarjetas grficas, presentando una interfaz comn. Mientras OpenGLes multiplataforma, Direct3D est totalmente ligado a sistemas Win-dows.

    Otro ejemplo representativo de SDKs vinculados al desarrollo devideojuegos son aquellos que dan soporte a la deteccin y tratamientode colisiones y a la gestin de la fsica de los distintas entidades queforman parte de un videojuego. Por ejemplo, en el mbito comercial lacompaa Havok12 proporciona diversas herramientas, entre las quedestaca Havok Physics. Dicha herramienta representa la alternativa

    10http://www.sgi.com/tech/stl/11http://http://www.opengl.org/12http://www.havok.com

  • [18] CAPTULO 1. INTRODUCCIN

    comercial ms utilizada en el mbito de la deteccin de colisiones entiempo real y en las simulaciones fsicas. Segn sus autores, HavokPhysics se ha utilizado en el desarrollo de ms de 200 ttulos comer-ciales.

    Por otra parte, en el campo del Open Source, Open Dynamics Engine(ODE) 3D13 representa una de las alternativas ms populares parasimular dinmicas de cuerpo rgido [1].

    Recientemente, la rama de la Inteligencia Artificial en los video-juegos tambin se ha visto beneficiada con herramientas que posibi-litan la integracin directa de bloques de bajo nivel para tratar conproblemas clsicos como la bsqueda ptima de caminos entre dospuntos o la accin de evitar obstculos.

    1.2.3. Capa independiente de la plataforma

    Abstraccin funcional

    Aunque en teora las herra-mientas multiplataforma de-beran abstraer de los aspec-tos subyacentes a las mis-mas, como por ejemplo el sis-tema operativo, en la prcti-ca suele ser necesario reali-zar algunos ajustos en fun-cin de la plataforma exis-tente en capas de nivel infe-rior.

    Gran parte de los juegos se desarrollan teniendo en cuenta su po-tencial lanzamiento en diversas plataformas. Por ejemplo, un ttulo sepuede desarrollar para diversas consolas de sobremesa y para PC almismo tiempo. En este contexto, es bastante comn encontrar una ca-pa software que aisle al resto de capas superiores de cualquier aspectoque sea dependiente de la plataforma. Dicha capa se suele denominarcapa independiente de la plataforma.

    Aunque sera bastante lgico suponer que la capa inmediatamen-te inferior, es decir, la capa de SDKs y middleware, ya posibilita laindependencia respecto a las plataformas subyacentes debido al usode mdulos estandarizados, como por ejemplo bibliotecas asociadasa C/C++, la realidad es que existen diferencias incluso en bibliotecasestandarizadas para distintas plataformas.

    Algunos ejemplos representativos de mdulos incluidos en esta ca-pa son las bibliotecas de manejo de hijos o los wrappers o envolturassobre alguno de los mdulos de la capa superior, como el mdulo dedeteccin de colisiones o el responsable de la parte grfica.

    1.2.4. Subsistemas principales

    La capa de subsistemas principales est vinculada a todas aque-llas utilidades o bibliotecas de utilidades que dan soporte al motor dejuegos. Algunas de ellas son especficas del mbito de los videojue-gos pero otras son comunes a cualquier tipo de proyecto software quetenga una complejidad significativa.

    A continuacin se enumeran algunos de los subsistemas ms rele-vantes:

    Biblioteca matemtica, responsable de proporcionar al desarro-llador diversas utilidades que faciliten el tratamiento de opera-ciones relativas a vectores, matrices, cuaterniones u operaciones

    13http://www.ode.org

  • 1.2. Arquitectura del motor. Visin general [19]

    vinculadas a lneas, rayos, esferas y otras figuras geomtricas.Las bibliotecas matemticas son esenciales en el desarrollo deun motor de juegos, ya que stos tienen una naturaleza inheren-temente matemtica.

    Estructuras de datos y algoritmos, responsable de proporcio-nar una implementacin ms personalizada y optimizada de di-versas estructuras de datos, como por ejemplo listas enlazadas orboles binarios, y algoritmos, como por ejemplo bsqueda u or-denacin, que la encontrada en bibliotecas como STL. Este sub-sistema resulta especialmente importante cuando la memoria dela plataforma o plataformas sobre las que se ejecutar el motorest limitada (como suele ocurrir en consolas de sobremesa).

    Gestin de memoria, responsable de garantizar la asignacin yliberacin de memoria de una manera eficiente.

    Depuracin y logging, responsable de proporcionar herramien-tas para facilitar la depuracin y el volcado de logs para su pos-terior anlisis.

    1.2.5. Gestor de recursos

    Esta capa es la responsable de proporcionar una interfaz unifica-da para acceder a las distintas entidades software que conforman elmotor de juegos, como por ejemplo la escena o los propios objetos 3D.En este contexto, existen dos aproximaciones principales respecto adicho acceso: i) plantear el gestor de recursos mediante un enfoquecentralizado y consistente o ii) dejar en manos del programador dichainteraccin mediante el uso de archivos en disco.

    Ogre 3D

    El motor de rendering Ogre3D est escrito en C++ y per-mite que el desarrollador seabstraiga de un gran nmerode aspectos relativos al desa-rrollo de aplicaciones grfi-cas. Sin embargo, es nece-sario estudiar su funciona-miento y cmo utilizarlo demanera adecuada.

    A

    BACDEF

    BAA

    BACD

    BAA

    BAAD

    ABAD

    Figura 1.10: Visin conceptual del gestor de recursos y sus entidades asociadas. Es-quema adaptado de la arquitectura propuesta en [5].

    La figura 1.10 muestra una visin general de un gestor de recursos,representando una interfaz comn para la gestin de diversas entida-

  • [20] CAPTULO 1. INTRODUCCIN

    des como por ejemplo el mundo en el que se desarrolla el juego, losobjetos 3D, las texturas o los materiales.

    En el caso particular de Ogre 3D [7], el gestor de recursos estrepresentado por la clase Ogre::ResourceManager, tal y como se pue-de apreciar en la figura 1.11. Dicha clase mantiene diversas espe-cializaciones, las cuales estn ligadas a las distintas entidades quea su vez gestionan distintos aspectos en un juego, como por ejem-plo las texturas (clase Ogre::TextureManager), los modelos 3D (claseOgre::MeshManager) o las fuentes de texto (clase Ogre::FontManager).En el caso particular de Ogre 3D, la clase Ogre::ResourceManager he-reda de dos clases, ResourceAlloc y Ogre::ScriptLoader, con el objetivode unificar completamente las diversas gestiones. Por ejemplo, la cla-se Ogre::ScriptLoader posibilita la carga de algunos recursos, como losmateriales, mediante scripts y, por ello, Ogre::ResourceManager here-da de dicha clase.

    ABCDC

    EAFC

    AA BCDC

    EDBCDC

    BBCDC

    BCFCBCDC

    CBCDC

    DBCDC

    FBCDC

    Figura 1.11: Diagrama de clases asociado al gestor de recursos de Ogre 3D, represen-tado por la clase Ogre::ResourceManager.

    1.2.6. Motor de rendering

    Debido a que el componente grfico es una parte fundamental decualquier juego, junto con la necesidad de mejorarlo continuamente, elmotor de renderizado es una de las partes ms complejas de cualquiermotor de juego.

    Al igual que ocurre con la propia arquitectura de un motor de jue-gos, el enfoque ms utilizado para disear el motor de renderizado

  • 1.2. Arquitectura del motor. Visin general [21]

    consiste en utilizar una arquitectura multi-capa, como se puede apre-ciar en la figura 1.12.

    Shaders

    Un shader se puede definircomo un conjunto de ins-trucciones software que per-miten aplicar efectos de ren-derizado a primitivas geom-tricas. Al ejecutarse en lasunidades de procesamientogrfico (Graphic ProcessingUnits - GPUs), el rendimientode la aplicacin grfica mejo-ra considerablemente.

    A continuacin se describen los principales mdulos que formanparte de cada una de las capas de este componente.

    AABCADE

    ABCDDEAFA

    ADE

    F

    AAEDA

    AAE

    Figura 1.12: Visin conceptual de la arquitectura general de un motor de rendering.Esquema simplificado de la arquitectura discutida en [5].

    La capa de renderizado de bajo nivel aglutina las distintas uti-lidades de renderizado del motor, es decir, la funcionalidad asociadaa la representacin grfica de las distintas entidades que participanen un determinado entorno, como por ejemplo cmaras, primitivas derendering, materiales, texturas, etc. El objetivo principal de esta capareside precisamente en renderizar las distintas primitivas geomtricastan rpido como sea posible, sin tener en cuenta posibles optimizacio-nes ni considerar, por ejemplo, qu partes de las escenas son visiblesdesde el punto de vista de la cmara.

    Esta capa tambin es responsable de gestionar la interaccin conlas APIs de programacin grficas, como OpenGL o Direct3D, simple-mente para poder acceder a los distintos dispositivos grficos que es-tn disponibles. Tpicamente, este mdulo se denomina interfaz de dis-positivo grfico (graphics device interface).

    As mismo, en la capa de renderizado de bajo nivel existen otroscomponentes encargados de procesar el dibujado de distintas primiti-vas geomtricas, as como de la gestin de la cmara y los diferentesmodos de proyeccin. En otras palabras, esta capa proporciona unaserie de abstracciones para manejar tanto las primitivas geomtricascomo las cmaras virtuales y las propiedades vinculadas a las mismas.

  • [22] CAPTULO 1. INTRODUCCIN

    Por otra parte, dicha capa tambin gestiona el estado del hardwaregrfico y los shaders asociados. Bsicamente, cada primitiva recibidapor esta capa tiene asociado un material y se ve afectada por diversasfuentes de luz. As mismo, el material describe la textura o texturasutilizadas por la primitiva y otras cuestiones como por ejemplo qupixel y vertex shaders se utilizarn para renderizarla.

    Optimizacin

    Las optimizaciones son esen-ciales en el desarrollo de apli-caciones grficas, en general,y de videojuegos, en parti-cular, para mejorar el rendi-miento. Los desarrolladoressuelen hacer uso de estruc-turas de datos auxiliares pa-ra aprovecharse del mayorconocimiento disponible so-bre la propia aplicacin.

    La capa superior a la de renderizado de bajo nivel se denominascene graph/culling y optimizaciones y, desde un punto de vistageneral, es la responsable de seleccionar qu parte o partes de la esce-na se enviarn a la capa de rendering. Esta seleccin, u optimizacin,permite incrementar el rendimiento del motor de rendering, debido aque se limita el nmero de primitivas geomtricas enviadas a la capade nivel inferior.

    Aunque en la capa de rendering slo se dibujan las primitivas queestn dentro del campo de visin de la cmara, es decir, dentro delviewport, es posible aplicar ms optimizaciones que simplifiquen lacomplejidad de la escena a renderizar, obviando aquellas partes de lamisma que no son visibles desde la cmara. Este tipo de optimizacio-nes son crticas en juegos que tenga una complejidad significativa conel objetivo de obtener tasas de frames por segundo aceptables.

    Una de las optimizaciones tpicas consiste en hacer uso de estruc-turas de datos de subdivisin espacial para hacer ms eficiente el ren-derizado, gracias a que es posible determinar de una manera rpidael conjunto de objetos potencialmente visibles. Dichas estructuras dedatos suelen ser rboles, aunque tambin es posible utilizar otras al-ternativas. Tradicionalmente, las subdivisiones espaciales se conocencomo scene graph (grafo de escena), aunque en realidad representanun caso particular de estructura de datos.

    Por otra parte, en esta capa tambin es comn integrar mtodosde culling, como por ejemplo aquellos basados en utilizar informacinrelevante de las oclusiones para determinar qu objetos estn siendosolapados por otros, evitando que los primeros se tengan que enviar ala capa de rendering y optimizando as este proceso.

    Idealmente, esta capa debera ser independiente de la capa de ren-derizado, permitiendo as aplicar distintas optimizaciones y abstrayn-dose de la funcionalidad relativa al dibujado de primitivas. Un ejemplorepresentativo de esta independencia est representado por OGRE yel uso de la filosofa plug & play, de manera que el desarrollador pue-de elegir distintos diseos de grafos de escenas ya implementados yutilizarlos en su desarrollo.

    Filosofa Plug & Play

    Esta filosofa se basa en ha-cer uso de un componentefuncional, hardware o soft-ware, sin necesidad de confi-gurar ni de modificar el fun-cionamiento de otros compo-nentes asociados al primero.

    Sobre la capa relativa a las optimizaciones se sita la capa de efec-tos visuales, la cual proporciona soporte a distintos efectos que, pos-teriormente, se puedan integrar en los juegos desarrollados haciendouso del motor. Ejemplos representativos de mdulos que se incluyenen esta capa son aqullos responsables de gestionar los sistemas departculos (humo, agua, etc), los mapeados de entorno o las sombrasdinmicas.

    Finalmente, la capa de front-end suele estar vinculada a funcio-nalidad relativa a la superposicin de contenido 2D sobre el escenario

  • 1.2. Arquitectura del motor. Visin general [23]

    3D. Por ejemplo, es bastante comn utilizar algn tipo de mdulo quepermita visualizar el men de un juego o la interfaz grfica que permi-te conocer el estado del personaje principal del videojuego (inventario,armas, herramientas, etc). En esta capa tambin se incluyen compo-nentes para reproducir vdeos previamente grabados y para integrarsecuencias cinemticas, a veces interactivas, en el propio videojuego.Este ltimo componente se conoce como in-game cinematics (IGC) sys-tem.

    1.2.7. Herramientas de depuracin

    Versiones beta

    Adems del uso extensivo deherramientas de depuracin,las desarrolladoras de video-juegos suelen liberar versio-nes betas de los mismos paraque los propios usuarios con-tribuyan en la deteccin debugs.

    Debido a la naturaleza intrnseca de un videojuego, vinculada a lasaplicaciones grficas en tiempo real, resulta esencial contar con bue-nas herramientas que permitan depurar y optimizar el propio motorde juegos para obtener el mejor rendimiento posible. En este contex-to, existe un gran nmero de herramientas de este tipo. Algunas deellas son herramientas de propsito general que se pueden utilizar demanera externa al motor de juegos. Sin embargo, la prctica ms ha-bitual consiste en construir herramientas de profiling, vinculadas alanlisis del rendimiento, o depuracin que estn asociadas al propiomotor. Algunas de las ms relevantes se enumeran a continuacin [5]:

    Mecanismos para determinar el tiempo empleado en ejecutar unfragmento especfico de cdigo.

    Utilidades para mostrar de manera grfica el rendimiento del mo-tor mientras se ejecuta el juego.

    Utilidades para volcar logs en ficheros de texto o similares.

    Herramientas para determinar la cantidad de memoria utilizadapor el motor en general y cada subsistema en particular. Estetipo de herramientas suelen tener distintas vistas grficas paravisualizar la informacin obtenida.

    Herramientas de depuracin que gestin el nivel de informacingenerada.

    Utilidades para grabar eventos particulares del juego, permitien-do reproducirlos posteriormente para depurar bugs.

    1.2.8. Motor de fsica

    La deteccin de colisiones en un videojuego y su posterior tra-tamiento resultan esenciales para dotar de realismo al mismo. Sinun mecanismo de deteccin de colisiones, los objetos se traspasaranunos a otros y no sera posible interactuar con ellos. Un ejemplo t-pico de colisin est representado en los juegos de conduccin por elchoque entre dos o ms vehculos. Desde un punto de vista general, elsistema de deteccin de colisiones es responsable de llevar a cabo lassiguientes tareas [1]:

  • [24] CAPTULO 1. INTRODUCCIN

    1. La deteccin de colisiones, cuya salida es un valor lgico indi-cando si hay o no colisin.

    2. La determinacin de la colisin, cuya tarea consiste en calcularel punto de interseccin de la colisin.

    3. La respuesta a la colisin, que tiene como objetivo determinarlas acciones que se generarn como consecuencia de la misma.

    ED auxiliares

    Al igual que ocurre en pro-cesos como la obtencin dela posicin de un enemigo enel mapa, el uso extensivo deestructuras de datos auxilia-res permite obtener solucio-nes a problemas computacio-nalmente complejos. La ges-tin de colisiones es otro pro-ceso que se beneficia de estetipo de tcnicas.

    Debido a las restricciones impuestas por la naturaleza de tiem-po real de un videojuego, los mecanismos de gestin de colisiones sesuelen aproximar para simplificar la complejidad de los mismos y noreducir el rendimiento del motor. Por ejemplo, en algunas ocasioneslos objetos 3D se aproximan con una serie de lneas, utilizando tc-nicas de interseccin de lneas para determinar la existancia o no deuna colisin. Tambin es bastante comn hacer uso de rboles BSPpara representar el entorno y optimizar la deteccin de colisiones conrespecto a los propios objetos.

    Por otra parte, algunos juegos incluyen sistemas realistas o semi-realistas de simulacin dinmica. En el mbito de la industria del vi-deojuego, estos sistemas se suelen denominar sistema de fsica yestn directamente ligados al sistema de gestin de colisiones.

    Actualmente, la mayora de compaas utilizan motores de coli-sin/fsica desarrollados por terceras partes, integrando estos kits dedesarrollo en el propio motor. Los ms conocidos en el mbito comer-cial son Havok, el cual representa el estndar de facto en la industriadebido a su potencia y rendimiento, y PhysX, desarrollado por NVIDIAe integrado en motores como por ejemplo el del Unreal Engine 3.

    En el mbito del open source, uno de los ms utilizados es Open-Dynamics Engine (ODE). Sin embargo, en este curso se har uso delmotor de simulacin fsica Bullet14, el cual se utiliza actualmente enproyectos tan ambiciosos como la suite 3D Blender.

    1.2.9. Interfaces de usuario

    En cualquier tipo de juego es necesario desarrollar un mdulo queofrezca una abstraccin respecto a la interaccin del usuario, es de-cir, un mdulo que principalmente sea responsable de procesar loseventos de entrada del usuario. Tpicamente, dichos eventos estarnasociados a la pulsacin de una tecla, al movimiento del ratn o al usode un joystick, entre otros.

    Desde un punto de vista ms general, el mdulo de interfaces deusuario tambin es responsable del tratamiento de los eventos desalida, es decir, aquellos eventos que proporcionan una retroalimen-tacin al usuario. Dicha interaccin puede estar representada, porejemplo, por el sistema de vibracin del mando de una consola o porla fuerza ejercida por un volante que est siendo utilizado en un jue-go de conduccin. Debido a que este mdulo gestiona los eventos de

    14http://www.bulletphysics.com

  • 1.2. Arquitectura del motor. Visin general [25]

    entrada y de salida, se suele denominar comnmente componente deentrada/salida del jugador (player I/O component).

    El mdulo de interfaces de usuario acta como un puente entrelos detalles de bajo nivel del hardware utilizado para interactuar conel juego y el resto de controles de ms alto nivel. Este mdulo tam-bin es responsable de otras tareas importantes, como la asocacin deacciones o funciones lgicas al sistema de control del juego, es decir,permite asociar eventos de entrada a acciones lgicas de alto nivel.

    En la gestin de eventos se suelen utilizar patrones de diseo comoel patrn delegate [3], de manera que cuando se detecta un evento, s-te se traslada a la entidad adecuada para llevar a cabo su tratamiento.

    1.2.10. Networking y multijugador

    La mayora de juegos comerciales desarrollados en la actualidadincluyen modos de juegos multijugador, con el objetivo de incremen-tar la jugabilidad y duracin de los ttulos lanzados al mercado. Dehecho, algunas compaas basan el modelo de negocio de algunos desus juegos en el modo online, como por ejemplo World of Warcraft deBlizzard Entertainment, mientras algunos ttulos son ampliamente co-nocidos por su exitoso modo multijugador online, como por ejemplo lasaga Call of Duty de Activision.

    Lag

    El retraso que se producedesde que se enva un paque-te de datos por una entidadhasta que otra lo recibe seconoce como lag. En el m-bito de los videojuegos, el lagse suele medir en milsimasde segundo.

    Aunque el modo multijugador de un juego puede resultar muy pa-recido a su versin single-player, en la prctica incluir el soporte devarios jugadores, ya sea online o no, tiene un profundo impacto endiseo de ciertos componentes del motor de juego, como por ejemploel modelo de objetos del juego, el motor de renderizado, el mdulo deentrada/salida o el sistema de animacin de personajes, entre otros.De hecho, una de las filosofas ms utilizadas en el diseo y desarrollode motores de juegos actuales consiste en tratar el modo de un nicojugador como un caso particular del modo multijugador.

    Por otra parte, el mdulo de networking es el responsable de in-formar de la evolucin del juego a los distintos actores o usuariosinvolucrados en el mismo mediante el envo de paquetes de informa-cin. Tpicamente, dicha informacin se transmite utilizando sockets.Con el objetivo de reducir la latencia del modo multijugador, especial-mente a travs de Internet, slo se enva/recibe informacin relevantepara el correcto funcionamiento de un juego. Por ejemplo, en el casode los FPS, dicha informacin incluye tpicamente la posicin de losjugadores en cada momento, entre otros elementos.

    1.2.11. Subsistema de juego

    El subsistema de juego, conocido por su trmino en ingls game-play, integra todos aquellos mdulos relativos al funcionamiento in-terno del juego, es decir, aglutina tanto las propiedades del mundovirtual como la de los distintos personajes. Por una parte, este sub-sistema permite la definicin de las reglas que gobiernan el mundovirtual en el que se desarrolla el juego, como por ejemplo la necesi-

  • [26] CAPTULO 1. INTRODUCCIN

    dad de derrotar a un enemigo antes de enfrentarse a otro de mayornivel. Por otra parte, este subsistema tambin permite la definicin dela mecnica del personaje, as como sus objetivos durante el juego.

    ABCDAAEFB

    EBB

    FEFB

    EBCB

    FACCC

    DCB

    Figura 1.13: Visin conceptual de la arquitectura general del subsistema de juego.Esquema simplificado de la arquitectura discutida en [5].

    Diseando juegos

    Los diseadores de los ni-veles de un juego, e inclu-so del comportamiento de lospersonajes y los NPCs, sue-len dominar perfectamentelos lenguajes de script, yaque son su principal herra-mienta para llevar a cabo sutarea.

    Este subsistema sirve tambin como capa de aislamiento entre lascapas de ms bajo nivel, como por ejemplo la de rendering, y el propiofuncionamiento del juego. Es decir, uno de los principales objetivos dediseo que se persiguen consiste en independizar la lgica del juegode la implementacin subyacente. Por ello, en esta capa es bastantecomn encontrar algn tipo de sistema de scripting o lenguaje de altonivel para definir, por ejemplo, el comportamiento de los personajesque participan en el juego.

    La capa relativa al subsistema de juego maneja conceptos comoel mundo del juego, el cual se refiere a los distintos elementos queforman parte del mismo, ya sean estticos o dinmicos. Los tipos deobjetos que forman parte de ese mundo se suelen denominar modelode objetos del juego [5]. Este modelo proporciona una simulacin entiempo real de esta coleccin heterognea, incluyendo

    Elementos geomtricos relativos a fondos estticos, como por ejem-plo edificios o carreteras.

    Cuerpos rgidos dinmicos, como por ejemplo rocas o sillas.

    El propio personaje principal.

    Los personajes no controlados por el usuario (NPCs).

    Cmaras y luces virtuales.

    Armas, proyectiles, vehculos, etc.

  • 1.2. Arquitectura del motor. Visin general [27]

    El modelo de objetos del juego est intimamente ligado al modelo deobjetos software y se puede entender como el conjunto de propiedadesdel lenguaje, polticas y convenciones utilizadas para implementar c-digo utilizando una filosofa de orientacin a objetos. As mismo, estemodelo est vinculado a cuestiones como el lenguaje de programacinempleado o a la adopcin de una poltica basada en el uso de patronesde diseo, entre otras.

    En la capa de subsistema de juego se integra el sistema de even-tos, cuya principal responsabilidad es la de dar soporte a la comu-nicacin entre objetos, independientemente de su naturaleza y tipo.Un enfoque tpico en el mundo de los videojuegos consiste en utilizaruna arquitectura dirigida por eventos, en la que la principal entidades el evento. Dicho evento consiste en una estructura de datos quecontiene informacin relevante de manera que la comunicacin estprecisamente guiada por el contenido del evento, y no por el emisoro el receptor del mismo. Los objetos suelen implementar manejadoresde eventos (event handlers) para tratarlos y actuar en consecuencia.

    Por otra parte, el sistema de scripting permite modelar fcilmentela lgica del juego, como por ejemplo el comportamiento de los enemi-gos o NPCs, sin necesidad de volver a compilar para comprobar sidicho comportamiento es correcto o no. En algunos casos, los moto-res de juego pueden seguir en funcionamiento al mismo tiempo que secarga un nuevo script.

    Finalmente, en la capa del subsistema de juego es posible encontraralgn mdulo que proporcione funcionalidad aadida respecto al tra-tamiento de la Inteligencia Artificial (IA) (normalmente de los NPCs).Este tipo de mdulos, cuya funcionalidad se suele incluir en la propiacapa de software especfica del juego en lugar de integrarla en el propiomotor, son cada vez ms populares y permiten asignar comportamien-tos preestablecidos sin necesidad de programarlos. En este contexto,la simulacin basada en agentes [16] cobra especial relevancia.

    Este tipo de mdulos pueden incluir aspectos relativos a problemasclsicos de la IA, como por ejemplo la bsqueda de caminos ptimosentre dos puntos, conocida como pathfinding, y tpicamente vinculadaal uso de algoritmos A* [10]. As mismo, tambin es posible hacer usode informacin privilegiada para optimizar ciertas tareas, como porejemplo la localizacin de entidades de inters para agilizar el clculode aspectos como la deteccin de colisiones.

    Im all ears!

    El apartado sonoro de unjuego es especialmente im-portante para que el usuariose sienta inmerso en el mis-mo y es crtico para acompa-ar de manera adecuada eldesarrollo de dicho juego.

    1.2.12. Audio

    Tradicionalmente, el mundo del desarrollo de videojuegos siem-pre ha prestado ms atencin al componente grfico. Sin embargo,el apartado sonoro tambin tiene una gran importancia para conse-guir una inmersin total del usuario en el juego. Por ello, el motor deaudio ha ido cobrando ms y ms relevancia.

    As mismo, la aparicin de nuevos formatos de audio de alta defini-cin y la popularidad de los sistemas de cine en casa han contribuidoa esta evo