Desarrollo de Videojuegos 2ª Edicion. Arquitectura del Motor de Videojuegos.pdf

www.FreeLibros.me

David Vallejo FernndezCleto Martn Angelina

1

www.FreeLibros.me

Ttulo: Desarrollo de Videojuegos: Arquitectura del MotorEdicin: Segunda, Julio 2013Autores: David Vallejo Fernndez y Cleto Martn AngelinaISBN: 978-84-686-4028-0 (de la Edicin Fsica, a la venta en www.bubok.es)Publica: Bubok (Edicin Fsica) LibroVirtual.org (Edicin electrnica)Edita: David Vallejo Fernndez y Carlos Gonzlez MorcilloDiseo: Carlos Gonzlez Morcillo

Este libro fue compuesto con LaTeX a partir de una plantilla de Carlos Gonzlez Morcillo, Sergio Garca Mondaray y David Villa Alises. La portada y las entradillas fueron diseadas con GIMP, Blender, InkScape y OpenOffice.

Creative Commons License: Usted es libre de copiar, distribuir y comunicar pblicamente la obra, bajo las condiciones siguientes: 1. Reconocimiento. Debe reconocer los crditos de la obra de la manera especicada por el autor o el licenciador. 2. No comercial. No puede utilizar esta obra para nes comerciales. 3. Sin obras derivadas. No se puede alterar, transformar o generar una obra derivada a partir de esta obra. Ms informacin en: http://creativecommons.org/licenses/by-nc-nd/3.0/

www.FreeLibros.me

Cleto Martn (2011, Ingeniero Informtica y Mster de Investigacin en Tecnologas Informticas Avanzadas, Universidad de Castilla-La Mancha) trabaja como Software Developer en Digital TV Labs (Bristol, UK) y como mantenedor de paquetes de aplicaciones para Canonical Ltd. y el proyecto Debian. Es un gran entusiasta de los sistemas basados en GNU/Linux, as como el desarrollo de aplicaciones basadas en redes de computadores y sistemas distribuidos.

David Vallejo (2009, Doctor Europeo en Informtica, Universidad de Castilla-La Mancha) es Profesor Ayudante Doctor e imparte docencia en la Escuela de Informtica de Ciudad Real (UCLM) en asignaturas relacionadas con Informtica Grfica, Programacin y Sistemas Operativos desde 2007. Actualmente, su actividad investigadora gira en torno a la Vigilancia Inteligente, los Sistemas Multi-Agente y el Rendering Distribuido.

www.FreeLibros.me

www.FreeLibros.me

Prefacio

Con ms de 40.000 descargas y 4TB servidos desde Junio de 2012,el material docente y el cdigo fuente de los ejemplos del Curso de Ex-perto en Desarrollo de Videojuegos, impartido en la Escuela Superiorde Informtica de Ciudad Real de la Universidad de Castilla-La Man-cha, se ha convertido en un referente internacional en la formacin dedesarrolladores de videojuegos.

Puedes obtener ms informacin sobre el curso, as como los resul-tados de los trabajos creados por los alumnos de la 1a y la 2a edicin,en la web del mismo: http://www.cedv.es. La versin electrnica deeste libro (y del resto de libros de la coleccin) puede descargarse des-de la web anterior. El libro fsico puede adquirirse desde la pginaweb de la editorial online Bubok en http://www.bubok.es.

Sobre este libro...

Este libro forma parte de una coleccin de 4 volmenes, con unperfil principalmente tcnico, dedicados al Desarrollo de 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 algoritmos y tcnicas de representacin grfica, as como enoptimizaciones y simulacin fsica.

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

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.

www.FreeLibros.me

Requisitos previos

Este libro tiene un pblico objetivo con un perfil principalmentetcnico. Al igual que el curso, est orientado a la capacitacin de pro-fesionales de la programacin de videojuegos. De esta forma, este librono est orientado para un pblico de perfil artstico (modeladores, ani-madores, msicos, etc.) en el mbito de los videojuegos.

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 puede descargarse en la siguiente pginaweb: http://www.cedv.es. Salvo que se especifique explcitamente otralicencia, todos los ejemplos del libro se distribuyen bajo GPLv3.

Agradecimientos

Los autores del libro quieren agradecer en primer lugar a los alum-nos de la 1a y 2a edicin del Curso de Experto en Desarrollo de Vi-deojuegos por su participacin en el mismo y el excelente ambienteen las clases, las cuestiones planteadas y la pasin demostrada en eldesarrollo de todos los trabajos.

Los autores tambin agradecen el soporte del personal de adminis-tracin y servicios de la Escuela Superior de Informtica de CiudadReal, a la propia Escuela y el Departamento de Tecnologas y Sistemade Informacin de la Universidad de Castilla-La Mancha.

De igual modo, se quiere reflejar especialmente el agradecimientoa las 8 empresas que ofertarn prcticas en la 3a edicin del cur-so: Devilish Games (Alicante), Dolores Entertainment (Barcelona), fromthe bench (Alicante), Iberlynx Mobile Solutions (Ciudad Real), Kitma-ker (Palma), playspace (Palma), totemcat - Materia Works (Madrid) yZuinqstudio (Sevilla). Este agradecimiento se extiende a los portalesy blogs del mundo de los videojuegos que han facilitado la difusinde este material, destacando a Meristation, Eurogamer, Genbeta Dev,Vidaextra y HardGame2.

Finalmente, los autores desean agradecer su participacin a loscolaboradores del curso: Indra Software Labs, DocPath, la asociacinde desarrolladores de videojuegos Stratos y Libro Virtual.

www.FreeLibros.me

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

www.FreeLibros.me

www.FreeLibros.me

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

www.FreeLibros.me

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

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

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

2.2.2. Compilando con GCC . . . . . . . . . . . . . . . . . 34

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

2.2.4. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . 37

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

2.2.6. Depurando con GDB . . . . . . . . . . . . . . . . . . 43

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

2.3. Gestin de proyectos y documentacin . . . . . . . . . . . 55

2.3.1. Sistemas de control de versiones . . . . . . . . . . 56

2.3.2. Documentacin . . . . . . . . . . . . . . . . . . . . . 61

2.3.3. Forjas de desarrollo . . . . . . . . . . . . . . . . . . 65

3. C++. Aspectos Esenciales 69

3.1. Utilidades bsicas . . . . . . . . . . . . . . . . . . . . . . . 69

3.1.1. Introduccin a C++ . . . . . . . . . . . . . . . . . . 69

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

3.1.3. Tipos, declaraciones y modificadores . . . . . . . . 71

3.1.4. Punteros, arrays y estructuras . . . . . . . . . . . . 72

3.1.5. Referencias y funciones . . . . . . . . . . . . . . . . 76

3.2. Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.2.1. Fundamentos bsicos . . . . . . . . . . . . . . . . . 80

3.2.2. Aspectos especficos de las clases . . . . . . . . . . 82

3.2.3. Sobrecarga de operadores . . . . . . . . . . . . . . . 87

3.3. Herencia y polimorfismo . . . . . . . . . . . . . . . . . . . 90

3.3.1. Herencia . . . . . . . . . . . . . . . . . . . . . . . . . 90

3.3.2. Herencia mltiple . . . . . . . . . . . . . . . . . . . 93

3.3.3. Funciones virtuales y polimorfismo . . . . . . . . . 97

3.4. Plantillas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.4.1. Caso de estudio. Listas . . . . . . . . . . . . . . . . 102

3.4.2. Utilizando plantillas en C++ . . . . . . . . . . . . . 104

3.4.3. Cundo utilizar plantillas? . . . . . . . . . . . . . 106

3.5. Manejo de excepciones . . . . . . . . . . . . . . . . . . . . 107

3.5.1. Alternativas existentes . . . . . . . . . . . . . . . . 107

www.FreeLibros.me

3.5.2. Excepciones en C++ . . . . . . . . . . . . . . . . . . 109

3.5.3. Cmo manejar excepciones adecuadamente? . . . 112

3.5.4. Cundo utilizar excepciones? . . . . . . . . . . . . 114

4. Patrones de Diseo 117

4.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . 118

4.1.1. Estructura de un patrn de diseo . . . . . . . . . 119

4.1.2. Tipos de patrones . . . . . . . . . . . . . . . . . . . 120

4.2. Patrones de creacin . . . . . . . . . . . . . . . . . . . . . 121

4.2.1. Singleton . . . . . . . . . . . . . . . . . . . . . . . . 121

4.2.2. Abstract Factory . . . . . . . . . . . . . . . . . . . . 123

4.2.3. Factory Method . . . . . . . . . . . . . . . . . . . . . 126

4.2.4. Prototype . . . . . . . . . . . . . . . . . . . . . . . . 128

4.3. Patrones estructurales . . . . . . . . . . . . . . . . . . . . 129

4.3.1. Composite . . . . . . . . . . . . . . . . . . . . . . . . 129

4.3.2. Decorator . . . . . . . . . . . . . . . . . . . . . . . . 130

4.3.3. Facade . . . . . . . . . . . . . . . . . . . . . . . . . . 133

4.3.4. MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

4.3.5. Adapter . . . . . . . . . . . . . . . . . . . . . . . . . 137

4.3.6. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

4.4. Patrones de comportamiento . . . . . . . . . . . . . . . . . 141

4.4.1. Observer . . . . . . . . . . . . . . . . . . . . . . . . . 141

4.4.2. State . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

4.4.3. Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . 144

4.4.4. Template Method . . . . . . . . . . . . . . . . . . . . 147

4.4.5. Strategy . . . . . . . . . . . . . . . . . . . . . . . . . 149

4.4.6. Reactor . . . . . . . . . . . . . . . . . . . . . . . . . 150

4.4.7. Visitor . . . . . . . . . . . . . . . . . . . . . . . . . . 152

4.5. Programming Idioms . . . . . . . . . . . . . . . . . . . . . . 156

4.5.1. Orthodox Canonical Form . . . . . . . . . . . . . . 156

4.5.2. Interface Class . . . . . . . . . . . . . . . . . . . . . 158

4.5.3. Final Class . . . . . . . . . . . . . . . . . . . . . . . 159

4.5.4. pImpl . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

5. La Biblioteca STL 163

5.1. Visin general de STL . . . . . . . . . . . . . . . . . . . . . 163

www.FreeLibros.me

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

5.2.1. Reutilizacin de cdigo . . . . . . . . . . . . . . . . 167

5.2.2. Rendimiento . . . . . . . . . . . . . . . . . . . . . . 168

5.2.3. Inconvenientes . . . . . . . . . . . . . . . . . . . . . 169

5.3. Secuencias . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

5.3.1. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 170

5.3.2. Deque . . . . . . . . . . . . . . . . . . . . . . . . . . 173

5.3.3. List . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

5.4. Contenedores asociativos . . . . . . . . . . . . . . . . . . . 178

5.4.1. Set y multiset . . . . . . . . . . . . . . . . . . . . . . 179

5.4.2. Map y multimap . . . . . . . . . . . . . . . . . . . . 182

5.5. Adaptadores de secuencia . . . . . . . . . . . . . . . . . . 185

5.5.1. Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

5.5.2. Queue . . . . . . . . . . . . . . . . . . . . . . . . . . 187

5.5.3. Cola de prioridad . . . . . . . . . . . . . . . . . . . . 187

6. Gestin de Recursos 189

6.1. El bucle de juego . . . . . . . . . . . . . . . . . . . . . . . . 189

6.1.1. El bucle de renderizado . . . . . . . . . . . . . . . . 189

6.1.2. Visin general del bucle de juego . . . . . . . . . . 190

6.1.3. Arquitecturas tpicas del bucle de juego . . . . . . 192

6.1.4. Gestin de estados de juego con Ogre3D . . . . . . 195

6.1.5. Definicin de estados concretos . . . . . . . . . . . 201

6.2. Gestin bsica de recursos . . . . . . . . . . . . . . . . . . 203

6.2.1. Gestin de recursos con Ogre3D . . . . . . . . . . . 204

6.2.2. Gestin bsica del sonido . . . . . . . . . . . . . . . 205

6.3. El sistema de archivos . . . . . . . . . . . . . . . . . . . . 217

6.3.1. Gestin y tratamiento de archivos . . . . . . . . . . 217

6.3.2. E/S bsica . . . . . . . . . . . . . . . . . . . . . . . 220

6.3.3. E/S asncrona . . . . . . . . . . . . . . . . . . . . . 223

6.3.4. Caso de estudio. La biblioteca Boost.Asio C++ . . . 225

6.3.5. Consideraciones finales . . . . . . . . . . . . . . . . 229

6.4. Importador de datos de intercambio . . . . . . . . . . . . 230

6.4.1. Formatos de intercambio . . . . . . . . . . . . . . . 231

6.4.2. Creacin de un importador . . . . . . . . . . . . . . 234

www.FreeLibros.me

7. Bajo Nivel y Concurrencia 243

7.1. Subsistema de arranque y parada . . . . . . . . . . . . . . 244

7.1.1. Aspectos fundamentales . . . . . . . . . . . . . . . 244

7.1.2. Esquema tpico de arranque y parada . . . . . . . . 247

7.1.3. Caso de estudio. Ogre 3D . . . . . . . . . . . . . . . 249

7.1.4. Caso de estudio. Quake III . . . . . . . . . . . . . . 251

7.2. Contenedores . . . . . . . . . . . . . . . . . . . . . . . . . . 254

7.2.1. Iteradores . . . . . . . . . . . . . . . . . . . . . . . . 255

7.2.2. Ms all de STL . . . . . . . . . . . . . . . . . . . . . 257

7.3. Subsistema de gestin de cadenas . . . . . . . . . . . . . 261

7.3.1. Cuestiones especficas . . . . . . . . . . . . . . . . . 261

7.3.2. Optimizando el tratamiento de cadenas . . . . . . . 262

7.3.3. Hashing de cadenas . . . . . . . . . . . . . . . . . . 264

7.4. Configuracin del motor . . . . . . . . . . . . . . . . . . . 265

7.4.1. Esquemas tpicos de configuracin . . . . . . . . . 266

7.4.2. Caso de estudio. Esquemas de definicin. . . . . . 267

7.5. Fundamentos bsicos de concurrencia . . . . . . . . . . . 269

7.5.1. El concepto de hilo . . . . . . . . . . . . . . . . . . . 269

7.5.2. El problema de la seccin crtica . . . . . . . . . . . 270

7.6. La biblioteca de hilos de ICE . . . . . . . . . . . . . . . . . 271

7.6.1. Internet Communication Engine . . . . . . . . . . . 271

7.6.2. Manejo de hilos . . . . . . . . . . . . . . . . . . . . . 272

7.6.3. Exclusin mutua bsica . . . . . . . . . . . . . . . . 275

7.6.4. Flexibilizando el concepto de mutex . . . . . . . . . 279

7.6.5. Introduciendo monitores . . . . . . . . . . . . . . . 280

7.7. Multi-threading en Ogre3D . . . . . . . . . . . . . . . . . . 286

7.8. Caso de estudio. Procesamiento en segundo plano me-diante hilos . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

www.FreeLibros.me

www.FreeLibros.me

Listado de acrnimos

API Application Program Interface

ARM Advanced RISC Machine

BSD Berkeley Software Distribution

BSP Binary Space Partitioning

CORBA Common Object Request Broker Architecture

CPU Central Processing Unit

CVS Concurrent Versions System

DOD Diamond Of Death

DOM Document Object Model

DVD Digital Video Disc

E/S Entrada/Salida

EASTL Electronic Arts Standard Template Library

EA Electronic Arts

FIFO First In, First Out

FPS First Person Shooter

GCC GNU Compiler Collection

GDB GNU Debugger

GIMP GNU Image Manipulation Program

GLUT OpenGL Utility Toolkit

GNU GNU is Not Unix

GPL General Public License

GPU Graphic Processing Unit

GTK GIMP ToolKit

GUI Graphical User Interface

HTML HyperText Markup Language

I/O Input/Output

IA Inteligencia Artificial

IX

www.FreeLibros.me

IBM International Business Machines

IGC In-Game Cinematics

ICE Internet Communication Engine

KISS Keep it simple, Stupid!

LIFO Last In, First Out

MMOG Massively Multiplayer Online Game

MVC Model View Controller

NPC Non-Player Character

ODE Open Dynamics Engine

ODT OpenDocument Text

OGRE Object-Oriented Graphics Rendering Engine

PDA Personal Digital Assistant

PDF Portable Document Format

PHP Personal Home Page

POO Programacin Orientada a Objetos

POSIX Portable Operating System Interface X

PPC PowerPC

RPG Role-Playing Games

RST reStructuredText

RTS Real-Time Strategy

SAX Simple API for XML

SDK Software Development Kit

SDL Simple Directmedia Layer

SGBD Sistema de Gestin de Base de Datos

STL Standard Template Library

TCP Transport Control Protocol

VCS Version Control System

XML eXtensible Markup Language

YAML YAML Aint Markup Language

www.FreeLibros.me

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

www.FreeLibros.me

[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 [10],el desarrollo de motores de juegos o, ms recientemente, la eclosin delas 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 estre-chamente ligada a la evolucin del hardware que permite la ejecucinde los mismos. Esta evolucin atiende, principalmente, a dos factores:i) la potencia de dicho hardware y ii) las capacidades interactivas delmismo. En el primer caso, una mayor potencia hardware implica queel desarrollador disfrute de mayores posibilidades a la hora de, porejemplo, mejorar la calidad grfica de un ttulo o de incrementar laIA (Inteligencia Artificial) de los enemigos. Este factor est vinculadoal multiprocesamiento. En el segundo caso, una mayor riqueza entrminos de interactividad puede contribuir a que el usuario de vi-

www.FreeLibros.me

1.1. El desarrollo de videojuegos [3]

deojuegos viva una experiencia ms inmersiva (por ejemplo, medianterealidad aumentada) o, simplemente, ms natural (por ejemplo, me-diante 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

www.FreeLibros.me


Artistatcnico

Networking

Herramientas

Inteligencia Art.

Interfaces

Fsica

Motor

Audio

Programador

Productor ejecutivo

Productor Equipo de marketingEquipo creativo e innovacin

Director tcnico Gestor de pruebasDirector artstico Diseador jefe

Conceptual

Animacin

Modelado

Texturas

Equipo artstico

Artista jefe Programador jefe Equipo de diseo Equipo de pruebas

Figura 1.2: Visin conceptual de un equipo de desarrollo de videojuegos, considerandoespecialmente la parte de programacin.

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 IA. Sin embargo,tal y como se sugiri anteriormente, el concepto de ingeniero transver-sal es bastante comn, particularmente en equipos de desarrollo quetienen un nmero reducido de componentes o con un presupuestoque no les permite la contratacin de personas especializadas en unanica 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

www.FreeLibros.me


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

www.FreeLibros.me


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

www.FreeLibros.me


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, o NPC (Non-Player Character), 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-

www.FreeLibros.me


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 [9]. Bsicamente, este tipo de aproxima-ciones tiene como objetivo dotar a los NPC con cierta inteligencia paraincrementar el grado de realismo de un juego estableciendo, incluso,mecanismos de cooperacin y coordinacin entre los mismos. Respec-to al personaje principal, un videojuego ha de contemplar las distintasacciones realizadas por el mismo, considerando la posibilidad de deci-siones impredecibles a priori y las consecuencias que podran desen-cadenar.

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 SGBD han facilitado enormementela gestin de persistencia de innumerables aplicaciones informticas,los motores de juegos hacen la vida ms sencilla a los desarrolladoresde 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

www.FreeLibros.me


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

www.FreeLibros.me


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 (First Person Shoo-ter) gozan actualmente de unbuen momento y, como con-secuencia de ello, el nmerode ttulos disponibles es muyelevado, ofreciando una granvariedad al usuario final.

Probablemente, el gnero de juegos ms popular ha sido y es el delos los denominados FPS, abreviado tradicionalmente como shooters,representado por juegos como Quake, Half-Life, Call of Duty o Gearsof War, entre muchos otros. En este gnero, el usuario normalmentecontrola a un personaje con una vista en primera persona a lo largo deescenarios que tradicionalmente han sido interiores, como los tpicospasillos, pero que han ido evolucionando a escenarios exteriores degran 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 que unode los retos principales que han de afrontar es la inmersin del usua-rio en un mundo hiperrealista que ofrezca un alto nivel de detalle, almismo 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]:

www.FreeLibros.me


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.

NPC con un nivel de IA considerable y dotados de buenas anima-ciones.

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 losrboles BSP (Binary Space Partitioning) (rboles de particin binariadel espacio) [1], que se utilizan para realizar una divisin del espaciofsico 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/

www.FreeLibros.me


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]:

www.FreeLibros.me


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 [10] 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.

www.FreeLibros.me


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 con fidelidad el comportamiento del vehculo y su interaccin conel escenario, los juegos arcade se centran ms en la jugabilidad paraque cualquier tipo de usuario no tenga problemas de 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 inclu-so facilitar el clculo de rutas ptimas utilizando tcnicas de IA [11].Tambin se suelen usar imgenes para renderizar elementos lejanos,como por ejemplo rboles, vallas publicitarias u otro tipo 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, normalmen-te clasificados en tiempo real o RTS (Real-Time Strategy)) y por tur-nos (turn-based strategy). Ejemplos representativos de este gnero sonWarcraft, Command & Conquer, Comandos, Age of Empires o Starcraft,entre otros. Este tipo de juegos se caracterizan por mantener una c-mara con una perspectiva isomtrica, normalmente fija, de maneraque el jugador tiene una visin ms o menos completa del escenario,ya sea 2D o 3D. As mismo, es bastante comn encontrar un grannmero de unidades virtuales desplegadas en el mapa, siendo respon-sabilidad del 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 unbajo nmero de polgonos, con el objetivo de posibilitar el desplieguede un gran nmero de unidades de manera simultnea.

www.FreeLibros.me

1.2. Arquitectura del motor. Visin general [15]

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 o 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 definir co-mo un motor de juegos completo, s que proporciona un gran nmerode mdulos que permiten integrar funcionalidades no triviales, comoiluminacin avanzada o sistemas de animacin de caracteres.

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.

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

9http://www.ogre3d.org/

www.FreeLibros.me


Hardware

Drivers

Sistema operativo

Capa independiente de la plataforma

Subsistemas principales

Gestor de recursos

Motor derendering

Herramientasde desarrollo

Motorde fsica

Interfacesde usuario

NetworkingSubsistema

de juegoAudio

Subsistemas especficos de juego

Software development kits (SDKs) y middlewares

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

1.2.1. Hardware, drivers y sistema operativo

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.

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 laeficiencia del mismo, considerando aquellas cuestiones que son espe-cficas de una determinada plataforma.

www.FreeLibros.me


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 SDK paraproporcionar una determinada funcionalidad. No obstante, y aunquegeneralmente este software est bastante optimizado, algunos desa-rrolladores prefieren personalizarlo para adaptarlo a sus necesidadesparticulares, especialmente en consolas de sobremesa y porttiles.

APIs grficas

OpenGL y Direct3D son losdos ejemplos ms represen-tativos de API (ApplicationProgram Interface)s grficasque se utilizan en el mbitocomercial. La principal dife-rencia entre ambas es la es-tandarizacin, factor que tie-ne sus ventajas y desventa-jas.

Un ejemplo representativo de biblioteca para el manejo de estruc-turas de datos es STL (Standard Template Library) 10. STL es unabiblioteca de plantillas estndar para C++, el cual representa a su vezel lenguaje ms extendido actualmente para el desarrollo de videojue-gos, 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 el renderizado de modelostridimensionales. Los ejemplos ms representativos en este contextoson las APIs grficas OpenGL11 y Direct3D, mantenidas por el grupoKhronos y Microsoft, respectivamente. Este tipo de bibliotecas tienencomo principal objetivo ocultar los diferentes aspectos de las tarjetasgrficas, presentando una interfaz comn. Mientras OpenGL es mul-tiplataforma, Direct3D est totalmente ligado a sistemas Windows.

Otro ejemplo representativo de SDKs vinculados al desarrollo de vi-deojuegos 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 alternativacomercial 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.

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

www.FreeLibros.me


Por otra parte, en el campo del Open Source, ODE (Open DynamicsEngine) 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 operacionesvinculadas 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.

13http://www.ode.org

www.FreeLibros.me


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.

Gestor de recursos

Recursomodelo 3D

Recursofuente

Recursomaterial

Recursotextura

Recursoesqueleto

EtcMundoRecursocolisin

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-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-

www.FreeLibros.me


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.

Ogre::ResourceManager

Ogre::ScriptLoader

ResourceAlloc Ogre::TextureManager

Ogre::SkeletonManager

Ogre::MeshManager

Ogre::MaterialManager

Ogre::GPUProgramManager

Ogre::FontManager

Ogre::CompositeManager

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

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.

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 renderizadoconsiste en utilizar una arquitectura multi-capa, como se puede apre-ciar en la figura 1.12.

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

www.FreeLibros.me


Renderizado de bajo nivel

Scene graph/culling y optimizaciones

Efectos visuales

Front end

Interfaz con eldispositivo grfico

Motor de rendering

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.

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.

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.

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 texturas

www.FreeLibros.me


utilizadas por la primitiva y otras cuestiones como por ejemplo qupixel y vertex shaders se utilizarn para renderizarla.

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 abstra-yndose de la funcionalidad relativa al dibujado de primitivas. Unejemplo representativo de esta independencia est representado porOGRE (Object-Oriented Graphics Rendering Engine) y el uso de la filo-sofa plug & play, de manera que el desarrollador puede elegir distin-tos diseos de grafos de escenas ya implementados y utilizarlos en sudesarrollo.

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 escenario3D. 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,

www.FreeLibros.me


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 IGC (In-Game Cinematics)system.

1.2.7. Herramientas de depuracin

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]:

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.

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

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.

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]:

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

www.FreeLibros.me


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.

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 ODE.Sin embargo, en este curso se har uso del motor de simulacin fsicaBullet14, el cual se utiliza actualmente en proyectos tan ambiciososcomo 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 deentrada y de salida, se suele denominar comnmente componente deentrada/salida del jugador (player I/O component).

14http://www.bulletphysics.com

www.FreeLibros.me


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-dad de derrotar a un enemigo antes de enfrentarse a otro de mayornivel. Por otra parte, este subsistema tambin permite la definicin de

www.FreeLibros.me


la mecnica del personaje, as como sus objetivos durante el juego.

Sistema de scripting

Sistema de alto nivel del juego

Objetos estticos

Subsistema de juego

Objetos dinmicos

Simulacinbasada en agentes

Sistema deeventos

Figura 1.13: Visin conceptual de la arquitectura general del subsistema de juego.Esquema simplificado de la arquit

Desarrollo de Videojuegos 2ª Edicion. Arquitectura del Motor de Videojuegos.pdf

Documents

Transcript of Desarrollo de Videojuegos 2ª Edicion. Arquitectura del Motor de Videojuegos.pdf