Desarrollo De Videojuegos 3 Tecnicas Avanzadas

Citation preview

A B C D FD CF A E C CF A C CE E A #$ C A A C %

ECF C ! C " C

C

AB

CDEF CDEF BA 9 "C 6 : C % A E ?;C ?:: C

EC EC & C '( F E A B C D ECF) FD CF A ) E C ) C CF ) A C CE E ! C) A " ) #$ C A )A C % C *+,-,.-/,/-012*-+ 3EC A BC B DB EF B F *+,-,.-/,/-012/-/ F DB DF 5 6 73 A B4 8 6 " 3 FDF E C& C D ECF B FD CF A FD CF A ; C " 8 (C< ; " EC B 8 ; " E B C " E : C

;

" EC E C= E

FD CF A >A ) 5 C EC ) > 7

FA4

B4

B C ;C B

A A B A BA' @ "CE C 6 C EC ; ) E " 6 B ;A6 C "C 6 )6 & E C C "C ' 0 C C" C6C C C E" EC 6 EC C C ;C B E ; C " C C E C D C D ; CEC " F C " 6 ; B C C C E 6 EC E D C ; CEC "C ) " : C C 6 EC E ; " EC C " 6 AD : F C ' "";'GG C " C G C C G6B- - EGE 1G

F 4 A B %F FB F #F F D 5 FB " A/ F B !+ F F 6... AB - 1 EB F B F C DF 'DEFB B F B A F FB F A F F 7 "B F B AB A A B+ 'D AD F ( F F F A% 5 D)F AF AB -D FAFB %/ F DA A8 5 F F9 F F AB5 ) D E F F ABD 5 F FB %B F )F F F9 F AF F E+ F F F A -/ FF F EFB+

AB CA B A FB F A "B F B # AD B F FB F C DF F B A F D % ADB BF '( AF F %F $F A ) ' F F + , AD F AF D A %B F A B ' AF $F FB % AB -D ) $F

A B

CDB EF

F ! F F !F

E BAF F $F B A &B AF *EFB A F A% B D A ,%F AF F ,D F A +

D EF F . A B %F FB B A FB F A ! F "B F B ,)D AF A B F E BAF F F C DF F B A F D $F ! F AFB BF BF F F EDA BF ) AF AB -D F F F + 'D AFBF F EB F F F F AB F AF F E AB F BF AF D- D ) BF F FAFB %/ F ) BAD F + C F0EFBA F /A F F BB % F ) F F %D 1F 22 ) ")A + - B F EB )F A FA FB F E 3DFAF F +

C F CA 66 FB F A %F FB DA B F9 CB $A + 'D &< = D0 BF F D F A +

%F FB

F B A ! AB - 1 A? BF F BF F E B AFBF F EB E F F 1DF% ) BF

F

C C C A B F %F FB( B A FB F A B ! F "B F B # AD B F FB F C DF 'DEFB B F B A F F D $F E BA F F F % ADB BF AFB 5 "FB EDA B ) ' AF *EFB A + 'D A F A% B F F AB F 5 ) E 5 F A/ F %F FB( F ' A? BF F BB F AF 8 F AFB 5 "FB EDA B ) F BB F AF F F F B %+

66 FB F F F %BDE F EB )F A BF ,BA ) $F

%F FB

F A%

5 B

,D F A

*BFA A

F

B A ! #F 5 % F BB &B : 5

+

F F CE . A B F %F FB( B A FB F A ! F AB A A B F E BAF F F F BF F AF %( ) B3D AF ADB F EDA BF + % ADB 3DF E BAF F F AB F F E F BF F F EDA BF D F0EFB F F AF F F F8 9 + 'D EB E F E F F A% 5 F AD BF F -B F F BF F A B AF %F AF ) AF F E AB +

F C F : F 1DF% F E A &< = D0 ) ' > @ B+

F BB B FEF F AF F B *' , B *' ; ? ) D B F ,A

Prefacio

Este libro forma parte de una colección de cuatro volúmenes dedicados al Desarrollo de Videojuegos. Con un perfil principalmente técnico, estos cuatro libros cubren los aspectos esenciales en programación de videojuegos: 1. Arquitectura del Motor. En este primer libro se estudian los aspectos esenciales del diseño de un motor de videojuegos, así como las técnicas básicas de programación y patrones de diseño. 2. Programación Gráfica. El segundo libro de la colección se centra en los algoritmos y técnicas de representación gráfica y optimizaciones en sistemas de despliegue interactivo. 3. Técnicas Avanzadas. En este tercer volumen se recogen ciertos aspectos avanzados, como estructuras de datos específicas, técnicas de validación y pruebas o simulación física. 4. Desarrollo de Componentes. El último libro está dedicado a ciertos componentes específicos del motor, como la Inteligencia Artificial, Networking, Sonido y Multimedia o técnicas avanzadas de Interacción.

Sobre este libro... Este libro que tienes en tus manos es una ampliación y revisión de los apuntes del Curso de Experto en Desarrollo de Videojuegos, impartido en la Escuela Superior de Informática de Ciudad Real de la Universidad de Castilla-La Mancha. Puedes obtener más información sobre el curso, así como los resultados de los trabajos creados por los alumnos en la web del mismo: http://www.esi.uclm.es/videojuegos. La versión electrónica de este manual (y del resto de libros de la colección) puede descargarse desde la web anterior. El libro «físico» puede adquirirse desde la página web de la editorial online Bubok en http://www.bubok.es.

Requisitos previos Este libro tiene un público objetivo con un perfil principalmente técnico. Al igual que el curso del que surgió, está orientado a la capacitación de profesionales de la programación de videojuegos. De esta forma, este libro no está orientado para un público de perfil artístico (modeladores, animadores, músicos, etc) en el ámbito de los videojuegos. Se asume que el lector es capaz de desarrollar programas de nivel medio en C y C++. Aunque se describen algunos aspectos clave de C++ a modo de resumen, es recomendable refrescar los conceptos básicos con alguno de los libros recogidos en la bibliografía del curso. De igual modo, se asume que el lector tiene conocimientos de estructuras de datos y algoritmia. El libro está orientado principalmente para titulados o estudiantes de últimos cursos de Ingeniería en Informática.

Programas y código fuente El código de los ejemplos del libro pueden descargarse en la siguiente página web: http://www.esi.uclm.es/videojuegos. Salvo que se especifique explícitamente otra licencia, todos los ejemplos del libro se distribuyen bajo GPLv3.

Agradecimientos Los autores del libro quieren agradecer en primer lugar a los alumnos de la primera edición del Curso de Experto en Desarrollo de Videojuegos por su participación en el mismo y el excelente ambiente en las clases, las cuestiones planteadas y la pasión demostrada en el desarrollo de todos los trabajos. De igual modo, se quiere reflejar el agradecimiento especial al personal de administración y servicios de la Escuela Superior de Informática, por su soporte, predisposición y ayuda en todos los caprichosos requisitos que planteábamos a lo largo del curso. Por otra parte, este agradecimiento también se hace extensivo a la Escuela de Informatica de Ciudad Real y al Departamento de Tecnologías y Sistema de Información de la Universidad de Castilla-La Mancha. Finalmente, los autores desean agradecer su participación a los colaboradores de esta primera edición: Indra Software Labs, la asociación de desarrolladores de videojuegos Stratos y a Libro Virtual.

Resumen

El objetivo de este módulo, titulado «Técnicas Avanzadas de Desarrollo» dentro del Curso de Experto en Desarrollo de Videojuegos, es profundizar es aspectos de desarrollo más avanzados que complementen el resto de contenidos de dicho curso y permitan explorar soluciones más eficientes en el contexto del desarrollo de videojuegos. En este módulo se introducen aspectos básicos de jugabilidad y se describen algunas metodologías de desarrollo de videojuegos. Así mismo, también se estudian los fundamentos básicos de la validación y pruebas en este proceso de desarrollo. Por otra parte, en este módulo también se estudia un aspecto esencial en el desarrollo de videojuegos: la simulación física. No obstante, uno de los componentes más importantes del presente módulo está relacionado con aspectos avanzados del lenguaje de programación C++, como por ejemplo el estudio en profundidad de la biblioteca SDL, y las optimizaciones. Finalmente, el presente módulo se complementa con el estudio de la gestión de widgets y el estudio de la plataforma de desarrollo de videojuegos Unity, especialmente ideada para el desarrollo de juegos en plataformas móviles.

I

Índice general

1. Aspectos de Jugabilidad y Metodologías de Desarrollo

1

1.1. Jugabilidad y Experiencia del Jugador . . . . . . . . . . .

1

1.1.1. Introducción . . . . . . . . . . . . . . . . . . . . . .

1

1.1.2. Caracterización de la Jugabilidad . . . . . . . . . .

3

1.1.3. Facetas de la Jugabilidad . . . . . . . . . . . . . . .

4

1.1.4. Calidad de un juego en base a la Jugabilidad . . .

8

1.2. Metodologías de Producción y de Desarrollo . . . . . . . .

11

1.2.1. Pre-Producción . . . . . . . . . . . . . . . . . . . . .

12

1.2.2. Producción . . . . . . . . . . . . . . . . . . . . . . .

15

1.2.3. Post-Producción . . . . . . . . . . . . . . . . . . . .

17

1.3. Metodologías Alternativas . . . . . . . . . . . . . . . . . . .

17

1.3.1. Proceso Unificado del Juego . . . . . . . . . . . . .

18

1.3.2. Desarrollo Incremental . . . . . . . . . . . . . . . .

18

1.3.3. Desarrollo Ágil y Scrum . . . . . . . . . . . . . . . .

19

1.3.4. Desarrollo Centrado en el Jugador

19

. . . . . . . . .

2. C++ Avanzado

23

2.1. Programación genérica . . . . . . . . . . . . . . . . . . . .

23

2.1.1. Algoritmos . . . . . . . . . . . . . . . . . . . . . . . .

24

2.1.2. Predicados

. . . . . . . . . . . . . . . . . . . . . . .

27

2.1.3. Functors . . . . . . . . . . . . . . . . . . . . . . . . .

28

2.1.4. Adaptadores

. . . . . . . . . . . . . . . . . . . . . .

30

2.1.5. Algoritmos idempotentes . . . . . . . . . . . . . . .

32

III

2.1.6. Algoritmos de transformación . . . . . . . . . . . .

35

2.1.7. Algoritmos de ordenación . . . . . . . . . . . . . . .

39

2.1.8. Algoritmos numéricos . . . . . . . . . . . . . . . . .

42

2.1.9. Ejemplo: inventario de armas . . . . . . . . . . . .

42

2.2. Aspectos avanzados de la STL . . . . . . . . . . . . . . . .

46

2.2.1. Eficiencia . . . . . . . . . . . . . . . . . . . . . . . .

46

2.2.2. Semántica de copia . . . . . . . . . . . . . . . . . .

50

2.2.3. Extendiendo la STL . . . . . . . . . . . . . . . . . .

52

2.2.4. Allocators . . . . . . . . . . . . . . . . . . . . . . . .

55

2.3. Estructuras de datos no lineales . . . . . . . . . . . . . . .

58

2.3.1. Árboles binarios . . . . . . . . . . . . . . . . . . . .

59

2.3.2. Recorrido de árboles . . . . . . . . . . . . . . . . . .

75

2.3.3. Quadtree y octree . . . . . . . . . . . . . . . . . . . .

78

2.4. Patrones de diseño avanzados . . . . . . . . . . . . . . . .

81

2.4.1. Forma canónica ortodoxa . . . . . . . . . . . . . . .

81

2.4.2. Smart pointers . . . . . . . . . . . . . . . . . . . . .

82

2.4.3. Handle-body . . . . . . . . . . . . . . . . . . . . . .

88

2.4.4. Command . . . . . . . . . . . . . . . . . . . . . . . .

91

2.4.5. Curiously recurring template pattern . . . . . . . .

95

2.4.6. Acceptor/Connector . . . . . . . . . . . . . . . . . . 100 2.5. C++11: Novedades del nuevo estándar . . . . . . . . . . . 104 2.5.1. Compilando con g++ . . . . . . . . . . . . . . . . . . 104 2.5.2. Cambios en el núcleo del lenguaje . . . . . . . . . . 105 2.5.3. Cambios en la biblioteca de C++ . . . . . . . . . . . 118 3. Técnicas específicas 3.1. Plugins

123

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

3.1.1. Entendiendo las bibliotecas dinámicas . . . . . . . 124 3.1.2. Plugins con libdl . . . . . . . . . . . . . . . . . . . 127 3.1.3. Plugins con Glib gmodule . . . . . . . . . . . . . . . 133 3.1.4. Carga dinámica desde Python . . . . . . . . . . . . 135 3.1.5. Plugins como objetos mediante el patrón Factory Method . . . . . . . . . . . . . . . . . . . . . . . . . . 135 3.1.6. Plugins multi-plataforma . . . . . . . . . . . . . . . 138 3.2. Serialización de objetos . . . . . . . . . . . . . . . . . . . . 140 3.2.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 140

3.2.2. Serialización y Dependencias entre objetos . . . . . 146 3.2.3. Serialización con Boost . . . . . . . . . . . . . . . . 155 3.3. C++ y scripting . . . . . . . . . . . . . . . . . . . . . . . . . 159 3.3.1. Consideraciones de diseño . . . . . . . . . . . . . . 160 3.3.2. Invocando Python desde C++ de forma nativa . . . 161 3.3.3. Librería boost . . . . . . . . . . . . . . . . . . . . . . 162 3.3.4. Herramienta SWIG . . . . . . . . . . . . . . . . . . . 168 3.3.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . 169 4. Optimización

171

4.1. Perfilado de programas . . . . . . . . . . . . . . . . . . . . 173 4.1.1. El perfilador de Linux perf . . . . . . . . . . . . . . 175 4.1.2. Obteniendo ayuda . . . . . . . . . . . . . . . . . . . 177 4.1.3. Estadísticas y registro de eventos . . . . . . . . . . 177 4.1.4. Multiplexación y escalado . . . . . . . . . . . . . . . 178 4.1.5. Métricas por hilo, por proceso o por CPU . . . . . . 180 4.1.6. Muestreo de eventos . . . . . . . . . . . . . . . . . . 180 4.1.7. Otras opciones de perf . . . . . . . . . . . . . . . . 185 4.1.8. Otros perfiladores . . . . . . . . . . . . . . . . . . . 185 4.2. Optimizaciones del compilador . . . . . . . . . . . . . . . . 187 4.2.1. Variables registro . . . . . . . . . . . . . . . . . . . . 188 4.2.2. Código estático y funciones inline . . . . . . . . . . 189 4.2.3. Eliminación de copias . . . . . . . . . . . . . . . . . 195 4.2.4. Volatile . . . . . . . . . . . . . . . . . . . . . . . . . . 196 4.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . 197 5. Validación y pruebas

199

5.1. Programación defensiva . . . . . . . . . . . . . . . . . . . . 199 5.1.1. Sobrecarga . . . . . . . . . . . . . . . . . . . . . . . 201 5.2. Desarrollo ágil . . . . . . . . . . . . . . . . . . . . . . . . . 202 5.3. TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 5.3.1. Las pruebas primero . . . . . . . . . . . . . . . . . . 203 5.3.2. rojo, verde, refactorizar . . . . . . . . . . . . . . . . 204 5.4. Tipos de pruebas . . . . . . . . . . . . . . . . . . . . . . . . 204 5.5. Pruebas unitarias con google-tests . . . . . . . . . . . . . 206 5.6. Dobles de prueba

. . . . . . . . . . . . . . . . . . . . . . . 208

5.7. Dobles de prueba con google-mock . . . . . . . . . . . . . 210 5.8. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 215 6. Simulación física

217

6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . 217 6.1.1. Algunos Motores de Simulación . . . . . . . . . . . 218 6.1.2. Aspectos destacables . . . . . . . . . . . . . . . . . 219 6.1.3. Conceptos Básicos . . . . . . . . . . . . . . . . . . . 221 6.2. Sistema de Detección de Colisiones . . . . . . . . . . . . . 222 6.2.1. Formas de Colisión

. . . . . . . . . . . . . . . . . . 222

6.2.2. Optimizaciones . . . . . . . . . . . . . . . . . . . . . 225 6.2.3. Preguntando al sistema... . . . . . . . . . . . . . . . 226 6.3. Dinámica del Cuerpo Rígido . . . . . . . . . . . . . . . . . 227 6.4. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . 228 6.5. Introducción a Bullet . . . . . . . . . . . . . . . . . . . . . 229 6.5.1. Pipeline de Físicas de Cuerpo Rígido . . . . . . . . 230 6.5.2. Hola Mundo en Bullet . . . . . . . . . . . . . . . . . 232 6.6. Integración manual en Ogre . . . . . . . . . . . . . . . . . 240 6.7. Hola Mundo en OgreBullet . . . . . . . . . . . . . . . . . . 243 6.8. RayQueries . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 6.9. TriangleMeshCollisionShape . . . . . . . . . . . . . . . . . 250 6.10.Detección de colisiones . . . . . . . . . . . . . . . . . . . . 251 6.11.Restricción de Vehículo . . . . . . . . . . . . . . . . . . . . 253 6.12.Determinismo

. . . . . . . . . . . . . . . . . . . . . . . . . 257

6.13.Escala de los Objetos . . . . . . . . . . . . . . . . . . . . . 259 6.14.Serialización . . . . . . . . . . . . . . . . . . . . . . . . . . 260 7. Gestión de Widgets

261

7.1. Interfaces de usuario en videojuegos . . . . . . . . . . . . 261 7.1.1. Menú . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 7.1.2. HUD . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 7.2. Introducción CEGUI . . . . . . . . . . . . . . . . . . . . . . 265 7.2.1. Inicialización . . . . . . . . . . . . . . . . . . . . . . 266 7.2.2. El Sistema de Dimensión Unificado . . . . . . . . . 268 7.2.3. Detección de eventos de entrada . . . . . . . . . . . 269 7.3. Primera aplicación . . . . . . . . . . . . . . . . . . . . . . . 271

7.4. Tipos de Widgets . . . . . . . . . . . . . . . . . . . . . . . . 274 7.5. Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 7.6. Ejemplo de interfaz . . . . . . . . . . . . . . . . . . . . . . 276 7.7. Editores de layouts gráficos . . . . . . . . . . . . . . . . . 279 7.8. Scripts en detalle . . . . . . . . . . . . . . . . . . . . . . . . 280 7.8.1. Scheme

. . . . . . . . . . . . . . . . . . . . . . . . . 280

7.8.2. Font . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 7.8.3. Imageset . . . . . . . . . . . . . . . . . . . . . . . . . 281 7.8.4. LookNFeel . . . . . . . . . . . . . . . . . . . . . . . . 282 7.9. Cámara de Ogre en un Window . . . . . . . . . . . . . . . 282 7.10.Formateo de texto . . . . . . . . . . . . . . . . . . . . . . . 285 7.10.1.Introducción . . . . . . . . . . . . . . . . . . . . . . 285 7.10.2.Color . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 7.10.3.Formato . . . . . . . . . . . . . . . . . . . . . . . . . 286 7.10.4.Insertar imágenes . . . . . . . . . . . . . . . . . . . 286 7.10.5.Alineamiento vertical

. . . . . . . . . . . . . . . . . 287

7.10.6.Padding . . . . . . . . . . . . . . . . . . . . . . . . . 287 7.10.7.Ejemplo de texto formateado . . . . . . . . . . . . . 288 7.11.Características avanzadas . . . . . . . . . . . . . . . . . . 289 8. Plataformas Móviles

291

8.1. Método de trabajo con un motor de videojuegos . . . . . . 291 8.1.1. Generación de contenido externo al motor . . . . . 291 8.1.2. Generación de contenido interno al motor . . . . . 292 8.2. Creación de escenas . . . . . . . . . . . . . . . . . . . . . . 292 8.3. Creación de prefabs . . . . . . . . . . . . . . . . . . . . . . 296 8.4. Programación de scripts

. . . . . . . . . . . . . . . . . . . 296

8.4.1. Algunos scripts básicos . . . . . . . . . . . . . . . . 298 8.4.2. Triggers . . . . . . . . . . . . . . . . . . . . . . . . . 299 8.4.3. Invocación de métodos retardada . . . . . . . . . . 299 8.4.4. Comunicación entre diferentes scripts . . . . . . . 299 8.4.5. Control del flujo general de la partida . . . . . . . . 301 8.4.6. Programación de enemigos . . . . . . . . . . . . . . 303 8.4.7. Programación del control del jugador . . . . . . . . 305 8.4.8. Programación del interface . . . . . . . . . . . . . . 307

8.5. Optimización . . . . . . . . . . . . . . . . . . . . . . . . . . 309 8.5.1. Light mapping . . . . . . . . . . . . . . . . . . . . . . 310 8.5.2. Occlusion culling . . . . . . . . . . . . . . . . . . . . 310 8.6. Resultado final . . . . . . . . . . . . . . . . . . . . . . . . . 311

Capítulo

1

Aspectos de Jugabilidad y Metodologías de Desarrollo Miguel Ángel Redondo Duque

E

n este capítulo se introducen aspectos básicos relativos al concepto de jugabilidad, como por ejemplo aquellos vinculados a su caractarización en el ámbito del desarrollo de videojuegos o las facetas más relevantes de los mismos, haciendo especial hincapié en la parte relativa a su calidad. Por otra parte, en este capítulo también se discuten los fundamentos de las metodologías de desarrollo para videojuegos, estableciendo las principales fases y las actividades desarrolladas en ellas.

1.1.

Jugabilidad y Experiencia del Jugador

1.1.1. Introducción En el desarrollo de sistemas interactivos es fundamental contar con la participación del usuario. Por ello, se plantea lo que vienen a denominarse métodos de Diseño Centrado en el Usuario que se aplican, al menos, al desarrollo software que soporta directamente la interacción con el usuario. En otras palabras, es fundamental contar con su participación para que tengamos la garantía de que se le va a proporcionar buenas experiencias de uso. El software para videojuegos se puede considerar como un caso particular de sistema interactivo 1

[2]

CAPÍTULO 1. ASPECTOS DE JUGABILIDAD Y METODOLOGÍAS DE DESARROLLO

por lo que requiere un planteamiento similar en este sentido aunque, en este ámbito, los términos y conceptos que se emplean para este propósito varían ligeramente. En el desarrollo de videojuegos es importante tener siempre presente que hay que lograr que el jugador sienta las mejores experiencias (entretenimiento, diversión, et.) posibles durante su utilización. El incremento de estas experiencias revierte directamente en el éxito del videojuego. Así pues, es conveniente conocer las propiedades que caracterizan dichas experiencias, poder medirlas durante el proceso de desarrollo y así asegurar su éxito y calidad. En adelante, nos referiremos a esto como Experiencia del Jugador. La Experiencia del Jugador suele medirse utilizándose el concepto de Jugabilidad como propiedad característica de un videojuego, aunque su caracterización y forma de medirla no es algo plenamente formalizado e implantado en la industria del desarrollo de videojuegos. Como paso previo para entender los conceptos de Jugabilidad y, por extensión, de Experiencia del Jugador, conviene repasar un concepto fundamental en el ámbito de los sistemas interactivos que es la Usabilidad. La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y ser satisfactorio para el usuario, en condiciones especificas de uso o la eficiencia y satisfacción con la que un producto permite alcanzar objetivos específicos a usuarios específicos en un contexto de uso especifico. Para entender y medir la Usabilidad, se han identificado una serie de propiedades como son: efectividad, eficiencia, satisfacción, aprendizaje y seguridad [4] [34] [27] [13]. Éstas son las propiedades que son objeto de medición y, a partir de ellas, se puede valorar el grado de Usabilidad de un sistema. El desarrollo de software usable redunda directamente en reducción de costes de producción, optimización del mantenimiento e incremento de la calidad final del producto. Además, las propiedades que caracterizan la Usabilidad influyen muy directamente en el uso que los usuarios hacen, contribuyendo incrementar su satisfacción, su productividad en la realización de tareas y reduciendo su nivel de estrés. En definitiva, la Usabilidad puede considerarse como un reflejo de la Experiencia del Usuario en un sistema interactivo que soporta la realización de una serie de tareas específicas para lograr un objetivo bien definido. Según Nielsen Norman Group se define la Experiencia del Usuario como la sensación, sentimiento, respuesta emocional, valoración y satisfacción del usuario respecto a un producto, resultado del proceso de interacción con el producto y de la interacción con su proveedor [28]. En este sentido, cabe destacar la importancia de juegan diversos conceptos como la utilidad, la usabilidad, la deseabilidad, la accesibilidad, facilidad de uso, lo valioso del producto y lo creíble que pueda ser para el usuario. La Experiencia de Usuario está estrechamente relacionado con el contexto de uso del sistema interactivo, el contenido manipulado y los usuarios que lo usan. Lo que significa que variando alguno de estos elementos, el resultado puede ser totalmente diferente e incluso opuesto.

1.1. Jugabilidad y Experiencia del Jugador

[3]

La relación que existe entre Experiencia de Usuario y Usabilidad puede considerarse equivalente a la que existe entre Experiencia del Jugador y Jugabilidad, aunque no se trata de una simple traslación del dominio de aplicación. Así lo vamos a considerar para explicar cómo se puede caracterizar la Jugabilidad y que en base a su medición se obtenga una valoración de la Experiencia del Jugador. Además, se apuntarán algunas ideas metodológicas orientadas a lograr mejores desarrollos de videojuegos, desde el punto de vista de la Jugabilidad.

1.1.2. Caracterización de la Jugabilidad La Jugabilidad extiende el concepto de usabilidad, pero no se reduce únicamente la idea de Usabilidad en el caso particular de los videojuegos. Tampoco sería correcto reducirla únicamente al grado de diversión de un juego. Para diferenciar claramente este concepto que es un tanto difuso, lo adecuado es representarlo por un conjunto de atributos o propiedades que lo caracterizan. Estos atributos podrán ser medidos y valorados, para así comparar y extraer conclusiones objetivas. Este trabajo fue realizado por [15] que define la Jugabilidad como el conjunto de propiedades que describen la experiencia del jugador ante un sistema de juego determinado, cuyo principal objetivo es divertir y entretener “de forma satisfactoria y creíble”, ya sea solo o en compañía. Es importante remarcar los conceptos de satisfacción y credibilidad. El primero es común a cualquier sistema interactivo. Sin embargo, la credibilidad dependerá del grado en el que se pueda lograr que los jugadores se impliquen en el juego. Hay que significar que los atributos y propiedades que se utilizan para caracterizar la Jugabilidad y la Experiencia del Jugador, en muchos casos ya se han utilizado para caracterizar la Usabilidad, pero en los videojuegos presentan matices distintos. Por ejemplo, el “Aprendizaje” en un videojuego puede ser elevado, lo que puede provocar que el jugador se vea satisfecho ante el reto que supone aprender a jugarlo y, posteriormente, desarrollar lo aprendido dentro del juego. Un ejemplo lo tenemos en el videojuego Prince of Persia, donde es difícil aprender a controlar nuestro personaje a través de un mundo virtual, lo que supone un reto en los primeros compases del juego. Sin embargo, en cualquier otro sistema interactivo podría suponer motivo suficiente de rechazo. Por otro lado, la “Efectividad” en un juego no busca la rapidez por completar una tarea, pues entra dentro de la naturaleza del videojuego que el usuario esté jugando el máximo tiempo posible y son muchos los ejemplos que podríamos citar.

[4]

CAPÍTULO 1. ASPECTOS DE JUGABILIDAD Y METODOLOGÍAS DE DESARROLLO

Los atributos a los que hacemos referencia para caracterizar la Jugabilidad son los siguientes: Satisfacción. Agrado o complacencia del jugador ante el videojuego y el proceso de jugarlo. Aprendizaje. Facilidad para comprender y dominar el sistema y la mecánica del videojuego. Más adelante se indica cómo estos conceptos se definen en lo que se denomina Gameplay y que se construye durante el proceso de desarrollo del juego. Efectividad. Tiempo y recursos necesarios para ofrecer diversión al jugador mientras éste logra los objetivos propuestos en el videojuego y alcanza su meta final. Inmersión. Capacidad para creerse lo que se juega e integrarse en el mundo virtual mostrado en el juego. Motivación. Característica del videojuego que mueve a la persona a realizar determinadas acciones y a persistir en ellas para su culminación. Emoción. Impulso involuntario originado como respuesta a los estímulos del videojuego, que induce sentimientos y que desencadena conductas de reacción automática. Socialización. Atributos que hacen apreciar el videojuego de distinta manera al jugarlo en compañía (multijugador), ya sea de manera competitiva, colaborativa o cooperativa. La figura 1.1 muestra como estos atributos y algunos otros más pueden estar relacionados con el concepto de Usabilidad tal y como se recoge en las normas ISO/IEC-9241. Hay algunos atributos que están relacionados con el videojuego (producto) y otros se vinculan al proceso de desarrollo del juego (desarrollo), algunos hacen referencia a su influencia sobre el jugador/es (usuarios o grupos de usuarios).

1.1.3. Facetas de la Jugabilidad Uno de los objetivos, una vez definida la Jugabilidad, es poder medirla o cuantificarla. Este proceso es costoso debido a la cantidad de objetivos no funcionales que afectan a la Experiencia del Jugador. Como plantea [15], una buena estrategia es la de considerar una representación de la Jugabilidad basada en facetas de la misma. La organización en facetas puede considerarse una subdivisión lógica de la Jugabilidad global en jugabilidades un poco más específicas. Cada una de estas facetas facilitará la identificación y medición de las propiedades introducidas anteriormente. Además, así será más fácil relacionar la Jugabilidad con los elementos particulares de un videojuego. A continuación se enumeran algunas facetas que podrían considerarse particulares. Sin embargo, esta lista no es una lista cerrada y, en algún juego particular, podría aparecer y proponerse alguna otra faceta que fuese objeto de consideración:

1.1. Jugabilidad y Experiencia del Jugador

[5]

Figura 1.1: Relación entre atributos de Usabilidad y de Jugabilidad Jugabilidad Intrínseca. Se trata de la Jugabilidad medida en la propia naturaleza del juego y cómo se proyecta al jugador. Está ligada al diseño del Gameplay que se describe más adelante. La forma de valorarla pasa por analizar cómo se representan las reglas, los objetivos, el ritmo y las mecánicas del videojuego. Jugabilidad Mecánica. Es la Jugabilidad asociada a la calidad del videojuego como sistema software. Está ligada a lo que sería el motor del juego, haciendo hincapié en características como la fluidez de las escenas cinemáticas, la correcta iluminación, el sonido, los movimientos gráficos y el comportamiento de los personajes del juego y del entorno, sin olvidar los sistemas de comunicación en videojuegos que incorporan un modo multijugador.

[6]

CAPÍTULO 1. ASPECTOS DE JUGABILIDAD Y METODOLOGÍAS DE DESARROLLO Jugabilidad Interactiva. Es la faceta asociada a todo lo relacionado con la interacción con el usuario, el diseño de la interfaz de usuario, los mecanismos de diálogo y los sistemas de control. Jugabilidad Artística. Está asociada a la calidad y adecuación artística y estética de todos los elementos del videojuego y a la naturaleza de éste. Entre ellos estarán la calidad gráfica y visual, los efectos sonoros, la banda sonora y las melodías del juego, la historia y la forma de narración de ésta, así como la ambientación realizada de todos estos elementos dentro del videojuego. Jugabilidad Intrapersonal (o Personal). Está relacionada con la percepción que tiene el propio usuario del videojuego y los sentimientos que le produce. Como tal, tiene un alto valor subjetivo. Jugabilidad Interpersonal (o de Grupo). Muestra las sensaciones o percepciones de los usuarios que aparecen cuando se juega en grupo, ya sea de forma competitiva, cooperativa o colaborativa. En relación a cualquier sistema interactivo con soporte para grupos, se relacionaría con lo que tiene que ver con percepción del grupo (o awareness de grupo).

Figura 1.2: Relaciones entre las Facetas de la Jugabilidad En [15] incluso se relacionan, a nivel interactivo, estas facetas para ilustrar cómo pueden ser la implicaciones e influencias que presentan. Esta relación se resume en la figura 1.2.

1.1. Jugabilidad y Experiencia del Jugador

[7]

Figura 1.3: Clasificación de las propiedades de la calidad del producto y del proceso en un videojuego

[8]

CAPÍTULO 1. ASPECTOS DE JUGABILIDAD Y METODOLOGÍAS DE DESARROLLO

1.1.4. Calidad de un juego en base a la Jugabilidad Como ha quedado patente, el análisis de la calidad de un videojuego únicamente a partir de la Usabilidad o de la calidad de uso es insuficiente. Por esta razón, la caracterización de la Experiencia del Jugador en base a la Jugabilidad mediante una serie de propiedades, atributos y facetas proporciona un instrumento adicional. Con esto se pueden obtener medidas de la calidad de las experiencias durante el juego e incluso pueden utilizarse para extender el estándar de calidad ISO 25010 al contexto de los videojuegos. Se puede destacar que hay una serie de propiedades de la Jugabilidad que influyen directamente en la Calidad del Producto y otras en la Calidad del Proceso de Uso y que, fundamentalmente tienen que ver con la habilidad del jugador para utilizarlo. La figura 1.3 ilustra cómo se clasifican estas propiedades. En definitiva queda claro que la Experiencia de Juego requiere de su evaluación y esto podría llevarse a cabo en base a la Jugabilidad. Se han presentado algunos instrumentos conceptuales para ello. Sin embargo, el proceso no es fácil y menos si no se dispone de alguna herramienta que facilite la recopilación de información y el proceso de medición. En este sentido, se desarrolló PHET como una herramienta que hace uso de técnicas de evaluación heurística para obtener y clasificar la información de una forma flexible y manejable. PHET está diseñada para facilitar la aplicación de los criterios de evaluación de la Jugabilidad anteriormente descritos, obtener resultados que permiten un análisis de la Experiencia del Jugador y de los elementos más relevantes de un videojuego en este sentido. El resultado final que proporciona es un informe de interpretación directa, visual y portable.

Figura 1.4: Ejemplo de creación de una cuestión de carácter heurístico

1.1. Jugabilidad y Experiencia del Jugador

[9]

Figura 1.5: Respuesta de jugadores a los tests y cuestionarios

Figura 1.6: Resultados según las Facetas de la Jugabilidad El procedimiento de uso de esta herramienta, básicamente, es la creación de heurísticas, cuestionarios y test (figura 1.4). Posteriormente la realización de estos tests por parte de los usuarios (figura 1.5) y visualización de los resultados. En este sentido, puede observarse como en la figura 1.6 se muestra una representación en base a las Facetas de la Jugabilidad y en la figura 1.7 se muestra el resultado en base a distintas propiedades. Como se apuntó anteriormente, toda esta información se utiliza para obtener una valoración global de la Jugabilidad tal y como se muestra en la figura 1.8. Todo esto tiene como interesante poder relacionarse con los elementos específicos del videojuego tal y como muestra la figura 1.8 que ilustra como la herramienta incorpora este soporte.

[10]

CAPÍTULO 1. ASPECTOS DE JUGABILIDAD Y METODOLOGÍAS DE DESARROLLO

Figura 1.7: Resultados según diversas propiedades

Figura 1.8: Valoración global de la Jugabilidad

1.2. Metodologías de Producción y de Desarrollo

1.2.

[11]

Metodologías de Producción y de Desarrollo

Como en el desarrollo de cualquier producto software, para el construcción de un videojuego se requiere tener presente los principios fundamentales de la Ingeniería del Software y, especialmente, la metodología de desarrollo adecuada para el producto que se pretende construir y el contexto en el que se llevará a cabo. Sin embargo, el diseño y desarrollo de un videojuego no sólo se reduce al desarrollo técnico de un producto software sino que supone una actividad multidisciplinar que abarca desde la idea y concepción inicial hasta su versión final. Además, hay que tener presente que el desarrollo suele ser un proyecto de gran envergadura en tiempo y en dinero. Por ejemplo, la producción de Half-Life 2 supuso más de cuatro años de trabajo y un presupuesto final que se situó alrededor de los cincuenta millones de dólares. En estas situaciones, hay aspectos clave que requieren de una minuciosa planificación y metodología, ya que desde que se concibe un proyecto hasta que se comercializa transcurren grandes periodos de tiempo lo que en el ámbito tecnológico puede ser la causa de presentar importantes desfases y, por lo tanto, desembocar en un estrepitoso fracaso. Así pues, se puede asegurar que la realización de un videojuego es una tarea delicada que requiere de una metodología específica. Sin embargo, las metodologías claramente establecidas para desarrollo de software no se adaptan a este proceso con garantías de calidad suficientes y no existe en este ámbito un claro planteamiento de cómo afrontar el trabajo. No obstante, son muchos expertos los que coinciden en que el ciclo de vida del desarrollo de videojuegos se debe aproximar al del desarrollo de una película de cine, estableciendo tres fases claramente diferencias que son Pre-Producción, Producción y Post-Producción. A su vez en cada una de estas fases se identifican diversas etapas significativas y el equipo de producción se distribuye para colaborar en cada una de ellas. El equipo de personas que suelen trabajan en un proyecto de desarrollo de un videojuego comercial de tamaño medio-alto oscina entre 40 y 140. Además, el tiempo que dura el proceso puede llegar a superar los tres años. Teniendo presente esto y, especialmente, su similitud con la producción de una película en [8] se propone una organización de referencia para el equipo de producción. Esta organización es la que aparece en la figura 1.9 y que ha sido traducida en [15]. La organización de las etapas del proceso de producción y la relación entre las mismas da lugar a un modelo de proceso que se asemeja al denominado Modelo en Cascada de Royce [31] en el que se establece la realización secuencial de una serie de etapas, impidiendo el comienzo de una nueva etapa sin la finalización de la anterior. Esta característica sacrifica de forma importante la posibilidad de paralelismo en el desarrollo de un videojuego y puede suponer una mala utilización de los recursos disponibles.

[12]

CAPÍTULO 1. ASPECTOS DE JUGABILIDAD Y METODOLOGÍAS DE DESARROLLO

Figura 1.9: Organización de referencia de un equipo de producción de videojuegos

La distribución de las distintas etapas entre las tres fases mencionadas anteriormente tampoco está ampliamente consensuado. Predomina la idea de que la fase de Producción agrupa todo aquello que conlleva la obtención de elementos tangibles y elaborados para el juego, mientras que la fase de Pre-Producción se asocia con los procesos de obtención de elementos poco tangibles o preliminares, la cual se puede denominar Diseño Conceptual del Juego. En cualquier caso, cabe destacar que la principal carga de trabajo se sitúa en lo que puede denominarse Diseño General del Juego y en el Diseño Técnico que es donde se aborda fundamentalmente el desarrollo del software del videojuego. Así pues, son estas etapas las que requieren mayor número de recursos y una mayor coordinación entre ellos. La figura 1.10 ilustra un posible planteamiento de organización de fases y etapas extraído de [8]. Describimos a continuación cada una de sus etapas de forma más detallada para comprender su objetivo de una forma más clara.

1.2.1. Pre-Producción En la fase de Pre-Producción se lleva a cabo la concepción de la idea del juego, identificando los elementos fundamentales que lo caracterizarán y finalizando, si es posible, en un diseño conceptual del mismo. Esta información se organiza para dar lugar a lo que puede considerarse una primera versión del documento de diseño del juego

1.2. Metodologías de Producción y de Desarrollo

[13]

Figura 1.10: Organización de fases y etapas en la producción de un videojuego

o más conocido como Game Design Document (GDD). En este GDD, que debe ser elaborado por el equipo creativo del diseño de videojuegos, se debe identificar y fijar todo lo relacionado con el Diseño del Videojuego que será necesario abordar posteriormente (normalmente en la fase de Producción). Como patrón de referencia y de acuerdo a lo establecido en [8], el GDD debe contener lo siguiente: Genero. Clasificación del juego según su naturaleza. La identificación del género al que pertenece el juego servirá para fijar una serie de características básicas para su posterior diseño. Jugadores. Modalidad de juego: individual o colectivo; multijugador o no; si los jugadores son personas o son máquinas; etc. Historia. Resumen de la historia del juego. Se realizará una primera aproximación de la trama o la historia a desarrollar durante el juego, destacando qué se quiere contar y cómo se pretende hacerlo. Esto se denomina storyline y storytelling respectivamente. Bocetos. Los bocetos son diseños preliminares, fundamentalmente, de los personajes y de los escenarios por los que se desarrollará la acción del juego.

[14]

CAPÍTULO 1. ASPECTOS DE JUGABILIDAD Y METODOLOGÍAS DE DESARROLLO Look and Feel. A partir de los bocetos se define el aspecto grafico y artístico del juego, colores, temas dominantes, musicalidad, técnicas de diseño 3D o 2D, posiciones de cámaras, etc. Interfaz de Usuario. Se apuntará la forma en la que el jugador interactuará con el juego y con qué mecanismos contará para ello: estilos de interacción, metáforas de interacción, paradigma de interacción, etc. Objetivos. Se fijan las metas del juego de acuerdo a la historia que se va a desarrollar. Reglas. Se establece qué acciones podrá desarrollar el jugador y cómo podrá hacerlo. Características. Se recogen las características principales de cada personaje del juego y de los elementos que intervienen durante su historia. Gameplay. Este es un concepto poco preciso y de muy amplio alcance, siendo ligeramente diferente su aplicación a cada tipo de juego. En esencia se trata de la naturaleza general del videojuego y de la interactividad que soportará. Es decir, los aspectos fundamentales que caracterizan la forma en la que se va a jugar, las cosas que el jugador va a poder hacer en el juego, la forma en la que el entorno del juego reaccionará a las acciones del jugador, mediadas por los correspondientes personajes, etc. Estos aspectos se describirán sin detallar en exceso a nivel de gráficos, sonido o de la propia historia. Diseño de Niveles. Se describen los niveles de dificultad que presentará el juego indicando cuántos será y cómo serán, así como los retos a los que el jugador se enfrentará en cada uno de ellos. En algunos casos, estos niveles también pueden estar asociados a etapas o fases del juego. Requerimientos técnicos. Se definen los requerimientos técnicos de máquina y dispositivos que requerirá el videojuego para su utilización. Marketing. Esta es una parte esencial en cualquier producto, pero especialmente en el caso de un videojuego todavía más. Muchos videojuegos con fuertes inversiones han sido prácticamente un fracaso por no abordar este aspecto desde las primeras faces de desarrollo. Por lo tanto, es necesario plantear, desde esta fase, la líneas maestras por las que se va a regir la generación de marketing y publicidad del producto. Presupuesto. Se realizará una primera aproximación al presupuesto que soportará el proyecto de desarrollo del videojuego.

Como se ha indicado anteriormente, esta primera versión del GDD será el punto de partida para iniciar la fase de Producción, pero cabe insistir sobre la importancia de uno de sus elementos: se trata del

1.2. Metodologías de Producción y de Desarrollo

[15]

Gameplay. Dado el carácter un tanto difuso de este concepto, consideremos como ejemplo el caso particular del conocido y clásico juego “Space Invaders”. En este juego indicaríamos que se debe poder mover una nave alrededor del cuadrante inferior de la pantalla y disparar a una serie de enemigos que aparecen por la parte superior de la pantalla y que desaparecen cuando son alcanzados por los disparos. Estos enemigos tratan de atacarnos con sus disparos y presionándonos mediante la reducción de nuestro espacio de movimientos e intentando chocar contra nuestra nave. El Gameplay tiene una implicación importantísima en la calidad final del juego y, por lo extensión, en la Jugabilidad del mismo. Luego los esfuerzos destinados a su análisis y planteamiento revertirán directamente en las propiedades que caracterizan la Juabilidad. No obstante y para profundizar en más detalle sobre este aspecto, se recomienda consultar los siguientes libros: “Rules of Play: Game Design Fundamentals” [32] y “Game Design: Theory and Practice” [30].

1.2.2. Producción La fase de Producción es la fase donde se concentra el trabajo principal, en volumen y en número de participantes, del proceso de desarrollo del videojuego, especialmente en lo que se denomina Diseño del Juego y Diseño Técnico. Hay que significar que este curso está orientado, fundamentalmente, a las tareas y técnicas relacionadas con el Diseño Técnico, pero no queremos dejar de situarlo en el contexto del proceso global que requiere llevarse a cabo para concebir y desarrollar un producto de estas características. Siguiendo lo presentado en la figura 1.10, las etapas principales que se identifican en esta fase son las siguientes: Diseño de Juego. Esta es una etapa fundamental en la que se describen con alto nivel de detalle todos los elementos que formarán parte del juego. Principalmente, lo que se hace es refinar lo contemplado en el GDD para obtener su versión definitiva, diseñando en profundidad todos sus aspectos anteriormente especificados. Así se obtiene lo que se denomina Documento Técnico de Diseño (DTD) junto con la Biblia de la Historia, la Biblia del Arte y la primera versión del Motor del Juego. Fundamentalmente, se debe trabajar en tres líneas de trabajo que vienen a caracterizar lo que se denomina diseño del juego y son las siguientes: • Diseño Artístico que incluye: ◦ La Biblia de la Historia donde se recogen todas las historias de los personajes y del mundo donde se desarrolla el juego así como el argumento completo del juego. ◦ Biblia del Arte que incluye:

[16]

CAPÍTULO 1. ASPECTOS DE JUGABILIDAD Y METODOLOGÍAS DE DESARROLLO ⋄ Elementos sonoros del juego, es decir, voces, efectos, música, ambiente, etc. Incluso se empieza a trabajar en lo que debe dar lugar al Motor de Sonido. ⋄ Visualización gráfica de los elementos con los que interactuarán los jugadores. ⋄ Elementos gráficos como los modelos en 3D, las cámaras, las luces, los sprites, los tiles, etc. De igual manera que en el caso del sonido, esto sirve de punto de partida para comenzar a trabajar en lo que se denomina Motor Gráfico. • Diseño de la Mecánica del Juego, en el que se trabaja en lo aspectos que se enumeran a continuación: ◦ Cómo se va a interactuar en el juego, cuáles son las reglas que lo rigen y cómo es la comunicación que tendrá lugar en caso de tratarse de un juego on-line. ◦ Se debe diseñar el comportamiento, habilidades y otros detalles significativos de los personajes y del mundo que les rodea. ◦ Se empieza a trabajar en el diseño del motor de Inteligencia Artificial (IA) que pueda requerir y en todo lo asociado con esto. ◦ Se diseña lo que se denomina el Motor Físico con el objetivo de generar los aspectos físicos del juego como explosiones, disparos, etc. • Motor del Juego que hace referencia a una serie de rutinas que permiten la representación de todos los elementos funcionales del juego. En síntesis puede decirse que agrupa todo lo relacionado con el Motor Gráfico, el Motor de Sonido, el Gestor de IA, el Motor Físico y todo el resto de gestores que pueden ser necesario para manejar el universo completo del videojuego. Diseño Técnico. Ésta se trata de la etapa que directamente está relacionada el desarrollo del software del juego y con lo se aborda en profundidad como contenido técnico esencial de este curso. Es aquí donde de describe cómo será implementado el juego. Para ello se hace uso de notaciones como UML y se plantea y decide la metodología de desarrollo software más apropiada según las características y, sobretodo, envergadura del producto software que se pretende implementar. Es importante tener una descripción conceptual y precisa que permita ver el funcionamiento del software desde puntos de vistas estructurales, dinámicos, de interacción y de despliegue. En definitiva, se trata de un proyecto de desarrollo de software completo que debe incluir también una planificación de tareas a realizar, una asignación a los miembros del equipo de desarrolladores. Esto incluye la identificación de hitos importantes, las fechas de entrega y el análisis de riesgos. Implementación. En esta etapa debe abordarse la implementación de los elementos software del proyecto que se describieron

1.3. Metodologías Alternativas

[17] en la etapa anterior, utilizando para ello métodos, técnicas y herramientas como las que se trabajan a lo largo de este curso. Es posible que se detecten algunos errores del diseño inicial y que se requieran revisiones. En muchos casos, esta etapa y la anterior son repetidas de forma iterativa o se someten a ciclos iterativos. Esto, en muchos casos viene determinado por la metodología de desarrollo software que se emplea y que, como se ha apuntado anteriormente, depende de muchos factores como la envergadura del proyecto, los recursos disponibles, etc. Generalmente, en este momento se suelen construir demos reducidas del juego que son objeto de publicación, contribuyendo así a materializar la campaña de marketing y publicidad que tan esenciar es para lograr el éxito comercial del producto. Pruebas Alpha. Estas pruebas se abordan cuando tenemos ya partes del producto software terminado. También se suelen denominan pruebas Code Complete. Mediante las mismas, el producto se somete a diversas pruebas que realizan pequeños equipos que han estado llevando a cabo el proceso de diseño y desarrollo del juego. El objetivo de las mismas es buscar pequeños errores y refinar algunos aspectos. Uno de los aspectos más importantes que se valoran en esta etapa es la Jugabilidad del juego a través de diversas propiedades y facetas como se describió anteriormente. Pruebas Beta. En las pruebas Beta o también denominadas Content Complete se finaliza todo lo relacionado con contenidos como el decorado de las misiones, los gráficos, los textos en diferentes idiomas, doblaje del sonido, etc. Además, se trabaja para asegurar que los contenidos incluidos en el juego se ajustan a las leyes vigentes y a la ética establecida en aquellos países donde se pretende comercializar el juego. Estas pruebas son llevadas a cabo por personas ajenas al equipo de desarrollo. Gold Master. Esta etapa aborda una prueba definitiva con el producto final que se publicará y que se producirá. Obviamente, incluye todo el contenido artísitico, técnico y documental (es decir, los manuales de usuario). En este momento, la publicidad debe ser la mayor posible, incluyéndose la realización de reportajes, artículos, etc.

1.2.3. Post-Producción La fase de Post-Producción, en la que no nos vamos a detener ya que se aleja bastante del contenido tratado en el curso, aborda fundamentalmente la explotación y el mantenimiento del juego como si de cualquier otro producto software se tratase.

1.3.

Metodologías Alternativas

El método descrito anteriormente prácticamente es un caso particular de aplicación del Modelo de Proceso en Cascada, que conlleva la

[18]

CAPÍTULO 1. ASPECTOS DE JUGABILIDAD Y METODOLOGÍAS DE DESARROLLO

finalización de una etapa antes de poder abordar la siguiente. En el caso del desarrollo de software, esto condiciona bastante lo relacionado con las etapas de pruebas, cuya realización se retrasa en exceso quedando situada casi al final del desarrollo. En ese momento, depurar y solucionar cualquier problema, si es que es posible, puede resultar excesivamente costoso en tiempo y, en consecuencia, en dinero. Precisamente, en el área del desarrollo de sistemas interactivos, está claramente establecido que las pruebas, sobretodo de Usabilidad, deben hacerse desde las primeras fases, incluso cuando los prototipos están únicamente a nivel de bocetos y en papel. Así pues, eso entra firmemente en contradicción con el hecho de que un videojuego se considere como un caso particular de sistema interactivo. Por otro lado, la necesidad de evaluar lo antes posible las propiedades relacionadas con la Jugabilidad y la Experiencia del Jugador requieren plantear variaciones a la metodología de producción y desarrollo anteriormente presentada. Por esta razón, se describen a continuación algunos otros métodos alternativos que se utilizan en la industria del desarrollo de software de videojuegos.

1.3.1. Proceso Unificado del Juego Tomando como punto de partida el Proceso Unificado de Desarrollo (o RUP) de IBM, en [14] se plantea la metodología denominada Proceso Unificado del Juego (o Game Unified Process, GUP). Este método se caracteriza por incentivar la comunicación entre los equipos de trabajo que abordan cada etapa del desarrollo, la documentación estricta de cada paso y por abordar el proceso de desarrollo de una forma iterativa y en ciclos muy cortos. Se puede considerar como una versión ágil de la metodología RUP particularizada para el desarrollo de software de videojuegos. Además, este método propone la utilización del paradigma de Programación Extrema [7] como instrumento para agilizar el desarrollo del software del videojuego. Por lo tanto, esto es especialmente aplicable a lo que serían las etapas de Diseño del Juego, Diseño Técnico, Implementación y Pruebas.

1.3.2. Desarrollo Incremental Otro método que puede ser adecuado, si se pretende potenciar la realización de pruebas en las fases tempranas y obtener realimentación, es el Desarrollo Incremental de Sikora [35]. Básicamente, se introduce la idea de disponer de un equipo de “jugadores” dentro del equipo de desarrolladores encargados de las pruebas. Estos “jugadores” siempre realizan una subetapa de pruebas en cada etapa antes de validar los resultados y asumir las tareas de la siguiente etapa.

1.3. Metodologías Alternativas

[19]

1.3.3. Desarrollo Ágil y Scrum Una de las metodologías que mejores resultados está produciendo recientemente en la industria del software de videojuegos es la propuesta por Clinton Keith dentro de su estudio de desarrollo High Moon [21]. Como ejemplo de caso de éxito en el que se ha aplicado esta metodología, cabe mencionar DarkWatch. Esta metodología plantea la utilización de procesos ágiles de desarrollo de software, unido a los pilares básico de la metodología de desarrollo de productos Scrum [37]. El objetivo principal del método de Keith es hacer un diseño centrado en el jugador y en los resultados del proceso de desarrollo en cada una de sus fases. Así, se resalta la importancia de obtener la opinión del usuario en cada momento, por lo que intenta involucrar al equipo de pruebas lo antes posible. De esta forma, se facilitará la posibilidad detectar y solucionar a tiempo todos los posibles errores y se podrá analizar la Juabilidad en cada momento para ir mejorándola continuamente, del mismo modo que se hace para el caso particular de la Usabilidad en un sistema interactivo. Esta metodología requiere de la realización de importantes esfuerzos iniciales para lograr obtener prototipos básicos pero jugables y, por lo tanto, evaluables. Con estos prototipos se inicia un proceso iterativo en el que el equipo de pruebas lo utiliza y proporciona realimentación orientada a la mejora, especialmente de la Jugabilidad pero también de otros detalles que pueden caracterizar el producto final. Información mucho más detallada de cómo aplicar esta metodología puede encontrarse en el libro “Agile Game Development with Scrum” de [22].

1.3.4. Desarrollo Centrado en el Jugador En esta subsección se va a describir la propuesta de [15] que está inspirada directamente en los principios fundamentales del Diseño Centrado en el Usuario (DCU) y de las metodologías de desarrollo software que se han derivado de los mismos. La idea fundamental del Diseño Centrado en el Usuario, como ya se ha apuntado anteriormente, es la involucrar al usuario y hacerlo al principio de cualquier proceso de desarrollo, ya que muchos de los problemas del software se deben a una carencia en las fases iniciales del desarrollo, concretamente en las fases de elicitación y de análisis de requisitos. Esto ya ha sido contemplado en diversos estándares que plantean ciclos de vida del proceso que incluyen modelos de madurez para la Usabilidad como pilar fundamental que garantizar el éxito del producto en cuanto a la Experiencia del Usuario. De la misma forma que el DCU es necesario para el desarrollo de aplicaciones que cubran los requisitos del usuario de forma adecuada, el Diseño Centrado en el Jugador es especialmente importante para considerar la diversidad y subjetividad de los perfiles de jugadores existentes. Además, esto contribuye directamente a la reducción de la proliferación de productos que requieren numerosos “parches” incluso

[20]

CAPÍTULO 1. ASPECTOS DE JUGABILIDAD Y METODOLOGÍAS DE DESARROLLO

Figura 1.11: Método de Diseño Centrado en el Jugador de [15]

desde los primeros meses de vida en el mercado. En este sentido, [15] propone un método inspirado en la metodología PPIu+a propuesta en [16] para Ingeniería de la Usabilidad y que se resume en la figura 1.11. Para facilitar su comprensión puede utilizarse la figura 1.12 en la que se relaciona y compara esta metodología. En las fuentes citadas pueden encontrar muchos más detalles sobre la fases más destacables que son las de análisis, diseño, desarrollo y evaluación de elementos jugables. Especialmente, se plantea un patrón a seguir para la obtención de requisitos de Jugabilidad con ejemplos de aplicación, se proponen una serie de guías de estilo para llevar a cabo un diseño que fomente la Jugabilidad, se muestra cómo aplicar Scrum y programación extrema para la construcción de prototipos jugables y se describe cómo evaluar la Jugabilidad de los prototipos para obtener conclusiones sobre la experiencia del jugador.

1.3. Metodologías Alternativas

[21]

Figura 1.12: Comparación entre el método de Diseño Centrado en el Jugador y el de Diseño Centrado en el Usuario de MPIu+a

Capítulo

2

C++ Avanzado Francisco Moya Fernández David Villa Alises Sergio Pérez Camacho

2.1.

Programación genérica

La programación genérica es un paradigma de programación que trata de conseguir un mayor grado de reutilización tanto de las estructuras de datos como de los algoritmos, evitando así la duplicidad de código. Para conseguirlo, los algoritmos deben escribirse evitando asociar los detalles a tipos de datos concretos. Por ejemplo, en un algoritmo de ordenación, la operación que compara dos elementos cualesquiera se delega a una entidad ajena al algoritmo: un operador de comparación. Hoy en día, prácticamente todos los lenguajes de programación importantes disponen o han adoptado características de programación genérica (tal como los llamados «genéricos» en Java o C#). Figura 2.1: Alexander Stepanov, padre de la programación genérica y la librería STL

El diseño de la librería STL pretende proporcionar herramientas básicas de programación genérica. No es casualidad que la creación de STL y las ideas tras el paradigma de la programación genérica fueran desarrolladas por los mismos autores, especialmente Alexander Stepanov y David Musser [26]. Y de ahí el interés por separar las estructuras de datos (los contenedores) de los algoritmos. Como veremos, los otros dos componentes de la STL (iteradores y functors) sirven también al mismo propósito: posibilitan la interacción entre contenedores y algoritmos, a la vez que permiten un acoplamiento mínimo.

23

[24]

CAPÍTULO 2. C++ AVANZADO

Es interesante indicar que la disociación entre los datos y los algoritmos que los manejan contradice en cierta medida los principios de la programación orientada a objetos. En la POO las operaciones relativas a un tipo de dato concreto se ofrecen como métodos de dicha clase. El polimorfismo por herencia1 permite en la práctica utilizar un algoritmo definido como un método de la superclase con instancias de sus subclases. Sin embargo, esto no se considera programación genérica pues la implementación del algoritmo normalmente depende al menos de la superclase de la jerarquía. En STL los algoritmos están implementados normalmente como funciones (no métodos) y por supuesto no tienen estado, algo que por definición es ajeno a la POO. A pesar de ello, en el diseño de la librería están muy presentes los principios de orientación a objetos.

2.1.1. Algoritmos Para conseguir estructuras de datos genéricas, los contenedores se implementan como plantillas —como ya se discutió en capítulos anteriores— de modo que el tipo de dato concreto que han de almacenar se especifica en el momento de la creación de la instancia. Aunque es posible implementar algoritmos sencillos del mismo modo —parametrizando el tipo de dato— STL utiliza un mecanismo mucho más potente: los iteradores. Los iteradores permiten desacoplar tanto el tipo de dato como el modo en que se organizan y almacenan los datos en el contenedor. Lógicamente, para que un algoritmo pueda hacer su trabajo tiene que asumir que tanto los elementos del contenedor como los iteradores tienen ciertas propiedades, o siendo más precisos, un conjunto de métodos con un comportamiento predecible. Por ejemplo, para poder comparar dos colecciones de elementos, deben ser comparables dos a dos para determinar su igualdad —sin entrar en qué significa eso realmente. Así pues, el algoritmo equal() espera que los elementos soporten en «modelo» EqualityComparable, que implica que tienen sobrecargado el método operator==(), además de cumplir éste ciertas condiciones como reflexibidad, simetría, transitividad, etc. algoritmos «escalares»

Escribiendo un algoritmo genérico El mejor modo de comprender en qué consiste la «genericidad» de un algoritmo es crear uno desde cero. Escribamos nuestra propia versión del algoritmo genérico count() (uno de los más sencillos). Este algoritmo sirve para contar el número de ocurrencias de un elemento en una secuencia. Como una primera aproximación veamos cómo hacerlo para un array de enteros. Podría ser algo como:

1 también llamado polimorfismo «de subclase» o «de inclusión», en contraposición con el «polimorfismo paramétrico»

Aunque la mayoría de los algoritmos de la STL manejan secuencias delimitadas por dos iteradores, también hay algunos que utilizan datos escalares, tales como min(), max(), power() o swap() que pueden resultar útiles para componer algoritmos más complejos.

2.1. Programación genérica

[25]

Listado 2.1: Escribiendo un algoritmo genérico: my_count() (1/4) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

int my_count1(const int* sequence, int size, int value) { int retval = 0; for (int i=0; i < size; ++i) if (sequence[i] == value) retval++; return retval; } void test_my_count1() { const int size = 5; const int value = 1; int numbers[] = {1, 2, 3, 1, 2}; assert(my_count1(numbers, size, value) == 2); }

Destacar el especificador const en el parámetro sequence (línea 1). Le indica al compilador que esta función no modificará el contenido del array. De ese modo es más general; se podrá aplicar a cualquier array (sea constante o no).

Recuerda, en las funciones, aquellos parámetros que no impliquen copia (puntero o referencia) deberían ser constantes si la función efectivamente no va a modificarlos.

En la siguiente versión vamos a cambiar la forma de iterar sobre el array. En lugar de emplear un índice vamos a utilizar un puntero que se desplaza a través del array. Esta versión mantiene el prototipo, es decir, se invoca de la misma forma. Listado 2.2: Escribiendo un algoritmo genérico: my_count() (2/4) 1 int my_count2(const int* first, int size, int value) { 2 int retval = 0; 3 for (const int* it=first; it < first + size; ++it) 4 if (*it == value) 5 retval++; 6 7 return retval; 8 }

Dos cuestiones a destacar: Utiliza aritmética de punteros. Es decir, la dirección del puntero it (linea 3) no se incrementa de uno en uno, sino que depende del tamaño del tipo int. El valor consultado en el array se obtiene de-referenciando el puntero (*it en la línea 4).

[26]

CAPÍTULO 2. C++ AVANZADO

A continuación la función cambia para imitar la signatura habitual de STL. En lugar de pasar un puntero al comienzo y un tamaño, se le pasan punteros al comienzo y al final-más-uno. Listado 2.3: Escribiendo un algoritmo genérico: my_count() (3/4) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

int my_count3(const int* first, const int* last, int value) { int retval = 0; for (const int* it=first; it < last; ++it) if (*it == value) retval++; return retval; } void test_my_count3() { const int size = 5; const int value = 1; int numbers[] = {1, 2, 3, 1, 2}; assert(my_count3(numbers, numbers+size, value) == 2); }

Se puede apreciar como el criterio del final-mas-uno simplifica la invocación, puesto que el valor correcto se consigue con numbers+size (línea 15) y la condición de parada es también más simple (itammo); } int less_powerful_than(Weapon* other) const { return power() < other->power(); } bool same_weapon_as(Weapon* other) { return typeid(*this) == typeid(*other); } };

Los métodos shoot(), is_empty() y get_ammo() son auto-explicativos. El método add_ammo() está sobrecargado. La primera versión (línea 23) añade al arma la cantidad especificada de balas respetando el límite. Para esto se utiliza el algoritmo min(). El método less_powerful_than() compara esta instancia de arma con otra para decidir cuál es la más potente, y por último, el método same_weapon_as() indica si el arma es del mismo tipo utilizando R TTI. El siguiente listado muestra tres especializaciones de la clase Weapon que únicamente especializan los métodos privados power() y max_ammo() para cada uno de los tipos Pistol, Shotgun y RPG.

[44]

CAPÍTULO 2. C++ AVANZADO

Listado 2.31: Especializaciones de Weapon 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

class Pistol : public Weapon { virtual int power(void) const { return 1; }; virtual int max_ammo(void) const { return 50; }; public: Pistol(int ammo=0) : Weapon(ammo) {} }; class Shotgun : public Weapon { virtual int power(void) const { return 10; }; virtual int max_ammo(void) const { return 100; }; public: Shotgun(int ammo=0) : Weapon(ammo) {} }; class RPG : public Weapon { virtual int power(void) const { return 100; }; virtual int max_ammo(void) const { return 5; }; public: RPG(int ammo=0) : Weapon(ammo) {} };

Veamos por último la clase Inventory que representaría la colección de armas que lleva el jugador. Listado 2.32: Inventario de armas: Clase Inventory 1 class Inventory : public vector { 2 public: 3 typedef typename Inventory::const_iterator WeaponIter; 4 typedef vector WeaponVector; 5 class WeaponNotFound {}; 6 ~Inventory(); 7 8 void add(Weapon* weapon) { 9 WeaponIter it = 10 find_if(begin(), end(), 11 bind2nd(mem_fun(&Weapon::same_weapon_as), weapon)); 12 13 if (it != end()) { 14 (*it)->add_ammo(weapon); 15 delete weapon; 16 return; 17 } 18 19 push_back(weapon); 20 } 21 22 WeaponVector weapons_with_ammo(void) { 23 WeaponVector retval; 24 25 remove_copy_if(begin(), end(), back_inserter(retval), 26 mem_fun(&Weapon::is_empty)); 27 28 if (retval.begin() == retval.end()) 29 throw Inventory::WeaponNotFound(); 30 31 return retval; 32 }

2.1. Programación genérica

[45]

33 34 35 36 37 38 39 40 41

Weapon* more_powerful_weapon(void) { WeaponVector weapons = weapons_with_ammo(); sort(weapons.begin(), weapons.end(), mem_fun(&Weapon::less_powerful_than)); return *(weapons.end()-1); }

Algunos detalles interesantes de esta clase: Inventory «es-un» contenedor de punteros a Weapon, concretamente un vector (vector) como se puede apreciar en la línea 1. La línea 3 define el tipo WeaponIter como alias del tipo del iterador para recorrer el contenedor. En la línea 4, la clase WeaponNotFound se utiliza como excepción en las búsquedas de armas, como veremos a continuación. El método add() se utiliza para añadir un nuevo arma al inventario, pero contempla específicamente el caso —habitual en los shotters— en el que coger un arma que ya tiene el jugador implica únicamente coger su munición y desechar el arma. Para ello, utiliza el algoritmo find_if() para recorrer el propio contenedor especificando como predicado el método Weapon::same_weapon_as(). Nótese el uso de los adaptadores mem_fun() (por tratarse de un método) y de bind2nd() para pasar a dicho método la instancia del arma a buscar. Si se encuentra un arma del mismo tipo (líneas 12–16) se añade su munición al arma existente usando el iterador devuelto por find_if() y se elimina (línea 14). En otro caso se añade la nueva arma al inventario (línea 18). Por otra parte, el método more_powerful_weapon() (líneas 34–41) implementa una funcionalidad también muy habitual en ese tipo de juegos: cambiar al arma más potente disponible. En este contexto, invoca weapons_with_ammo() (líneas 22–32) para obtener las armas con munición. Utiliza el algoritmo remove_copy_if() para crear un vector de punteros (mediante la función back_inserter()), evitando copiar las vacías (línea 26). Ordena el vector resultante usando sort() y utilizando como predicado el método less_powerful_than() que vimos antes. Por último, el método retorna un puntero al último arma (línea 40). Nótese que el ’*’ en esa línea es la de-referencia del iterador (que apunta a un puntero). Para acabar, se muestra el destructor de la clase, que se encarga de liberar los punteros que almacena:

[46]

CAPÍTULO 2. C++ AVANZADO

Listado 2.33: Inventario de armas: Destructor 1 template 2 T* deleter(T* x) { 3 delete x; 4 return 0; 5 } 6 sort(weapons.begin(), weapons.end(), 7 mem_fun(&Weapon::less_powerful_than)); 8 9 return *(weapons.end()-1); 10 }

Aquí se utiliza el functor (deleter) con el algoritmo transform() para liberar cada puntero. La razón de usar transform() en lugar de for_each() es eliminar las direcciones de los punteros que dejan de ser válidos en el contenedor. Después se borra todo el contenedor usando su método clear().

2.2.

Aspectos avanzados de la STL

En esta sección veremos cómo explotar el potencial de la librería STL más allá del mero uso de sus contenedores y algoritmos.

2.2.1. Eficiencia La eficiencia es sin duda alguna uno de los objetivos principales de la librería STL. Esto es así hasta el punto de que se obvian muchas comprobaciones que harían su uso más seguro y productivo. El principio de diseño aplicado aquí es: Es factible construir decoradores que añadan comprobaciones adicionales a la versión eficiente. Sin embargo no es posible construir una versión eficiente a partir de una segura que realiza dichas comprobaciones. Algunas de estas comprobaciones incluyen la dereferencia de iteradores nulos, invalidados o fuera de los límites del contenedor, como se muestra en el siguiente listado. Para subsanar esta situación el programador puede optar entre utilizar una implementación que incorpore medidas de seguridad —con la consiguiente reducción de eficiencia— o bien especializar los contenedores en clases propias y controlar específicamente las operaciones susceptibles de ocasionar problemas. En cualquier caso el programador debería tener muy presente que este tipo de decisiones ad hoc (eliminar comprobaciones) forman parte de la fase de optimización y sólo deberían considerarse cuando se detecten problemas de rendimiento. En general, tal como dice Ken Beck, «La optimización prematura es un lastre». Es costosa (en tiempo y recursos) y produce normalmente código más sucio, difícil de leer y mantener, y por tanto, de inferior calidad.

80/20 Estadísticamente el 80 % del tiempo de ejecución de un programa es debido únicamente al 20 % de su código. Eso significa que mejorando ese 20 % se pueden conseguir importantes mejoras. Por ese motivo, la optimización del programa (si se necesita) debería ocurrir únicamente cuando se haya identificado dicho código por medio de herramientas de perfilado y un adecuado análisis de los flujos de ejecución. Preocuparse por optimizar una función lenta que solo se invoca en el arranque de un servidor que se ejecuta durante días es perjudicial. Supone un gasto de recursos y tiempo que probablemente producirá código menos legible y mantenible.

2.2. Aspectos avanzados de la STL

[47]

Listado 2.34: Situaciones no controladas en el uso de iteradores 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

void test_lost_iterator() { vector::iterator it; int i = *it; // probably a SEGFAULT } void test_invalidated_iterator() { vector v1; v1.push_back(1); vector::iterator it = v1.begin(); v1.clear(); int i = *it; // probably a SEGFAULT } void test_outbound_iterator() { vector v1; vector::iterator it = v1.end(); int i = *it; // probably a SEGFAULT }

Sin embargo, existen otro tipo de decisiones que el programador puede tomar cuando utiliza la STL, que tienen un gran impacto en la eficiencia del resultado y que no afectan en absoluto a la legibilidad y mantenimiento del código. Estas decisiones tienen que ver con la elección del contenedor o algoritmo adecuado para cada problema concreto. Esto requiere conocer con cierto detalle el funcionamiento y diseño de los mismos. Elegir el contenedor adecuado A continuación se listan los aspectos más relevantes que se deberían tener en cuenta al elegir un contenedor, considerando las operaciones que se realizarán sobre él: Tamaño medio del contenedor. En general, la eficiencia –en cuanto a tiempo de acceso– solo es significativa para grandes cantidades de elementos. Para menos de 100 elementos (seguramente muchos más considerando las computadoras o consolas actuales) es muy probable que la diferencia entre un contenedor con tiempo de acceso lineal y uno logarítmico sea imperceptible. Si lo previsible es que el número de elementos sea relativamente pequeño o no se conoce bien a priori la opción más adecuada es vector. Inserción de elementos en los dos extremos de la secuencia. Si necesita añadir al comienzo con cierta frecuencia (>10 %) debería elegir un contenedor que implemente esta operación de forma eficiente como deque. Inserción y borrado en posiciones intermedias. El contenedor más adecuado en este caso es list. Al estar implementado como una lista doblemente enlazada, la operación de

[48]

CAPÍTULO 2. C++ AVANZADO inserción o borrado implica poco más que actualizar dos punteros. Contenedores ordenados. Algunos contenedores, como set y multiset, aceptan un operador de ordenación en el momento de su instanciación. Después de cualquier operación de inserción o borrado el contenedor quedará ordenado. Esto es órdenes de magnitud más rápido que utilizar un algoritmo de ordenación cuando se necesite ordenarlo.

Otro aspecto a tener en cuenta es la distinción entre contenedores basados en bloques (como vector, deque o string) y los basados en nodos (como list, set, map, etc.). Los contenedores basados en nodos almacenan cada elemento como unidades independientes y se relacionan con los demás a través de punteros. Esto tiene varias implicaciones interesantes: Si se obtiene un iterador a un nodo, sigue siendo válido durante toda la vida del elemento. Sin embargo, en los basados en bloque los iteradores pueden quedar invalidados si se realoja el contenedor. Ocupan más memoria por cada elemento almacenado, debido a que se requiere información adicional para mantener la estructura: árbol o lista enlazada. Elegir el algoritmo adecuado Aunque los algoritmos de STL están diseñados para ser eficientes (incluso el estándar determina la complejidad ciclomática máxima permitida) ciertas operaciones sobre grandes colecciones de elementos pueden implicar tiempos de cómputo muy considerables. Para reducir el número de operaciones a ejecutar es importante considerar los condicionantes específicos de cada problema. Uno de los detalles más simples a tener en cuenta es la forma en la que se especifica la entrada al algoritmo. En la mayoría de ellos la secuencia queda determinada por el iterador de inicio y el de fin. Lo interesante de esta interfaz es que darle al algoritmo parte del contenedor es tan sencillo como dárselo completo. Se pueden dar innumerables situaciones en las que es perfectamente válido aplicar cualquiera de los algoritmos genéricos que hemos visto a una pequeña parte del contenedor. Copiar, buscar, reemplazar o borrar en los n primeros o últimos elementos puede servir para lograr el objetivo ahorrando muchas operaciones innecesarias. Otra forma de ahorrar cómputo es utilizar algoritmos que hacen solo parte del trabajo (pero suficiente en muchos casos), en particular los de ordenación y búsqueda como partial_sort(), nth_element(), lower_bound(), etc. Por ejemplo, una mejora bastante evidente que se puede hacer a nuestro inventario de armas (ver listado 2.32) es cambiar el algoritmo sort() por max_element() en el método more_powerful_weapon().

2.2. Aspectos avanzados de la STL

[49]

Listado 2.35: Modificación del inventario de armas 1 2 3 4 5 6

Weapon* more_powerful_weapon(void) { WeaponVector weapons = weapons_with_ammo(); return *max_element(weapons.begin(), weapons.end(), mem_fun(&Weapon::less_powerful_than)); }

Aunque no es previsible que sea un contenedor con muchos elementos, buscar el máximo (que es la verdadera intención del método) es mucho más rápido que ordenar la colección y elegir el último. ¿Algoritmos versus métodos del contenedor? Utilizar los algoritmos genéricos de STL facilita –obviamente– escribir código (o nuevos algoritmos) que pueden operar sobre cualquier contenedor. Lamentablemente, como no podía ser menos, la generalidad suele ir en detrimento de la eficiencia. El algoritmo genérico desconoce intencionadamente los detalles de implementación de cada contenedor, y eso implica que no puede (ni debe) aprovecharlos para trabajar del modo más eficiente posible. Resumiendo, para el algoritmo genérico es más importante ser genérico que eficiente. En aquellos casos en los que la eficiencia sea más importante que la generalidad (y eso también hay que pensarlo con calma) puede ser más adecuado utilizar los métodos del contenedor en lugar de sus algoritmos funcionalmente equivalentes. Veamos el siguiente listado: Listado 2.36: Algoritmo genérico vs. método del contenedor 1 void test_algorithm_vs_method(void) { 2 int orig[] = {1, 2, 3, 4, 5}; 3 const int SIZE = sizeof(orig) / sizeof(int); 4 vector v1, v2; 5 6 copy(orig, orig + SIZE, back_inserter(v1)); 7 8 v2.insert(v2.begin(), orig, orig + SIZE); 9 10 assert(equal(v1.begin(), v1.end(), v2.begin())); 11 }

Las líneas 6 y 8 realizan la misma operación: añadir a un vector el contenido del array orig, creando elementos nuevos (los vectores están vacíos). Sin embargo, la versión con insert() (línea 8) es más eficiente que copy(), ya que realiza menos copias de los elementos. Del mismo modo, aunque parece más evidente, utilizar métodos en los que se pueden especificar rangos es siempre más eficiente que utilizar sus equivalentes en los que sólo se proporciona un elemento (muchos métodos están sobrecargados para soportar ambos casos). El libro «Effective STL» [25] de Scott Meyers explica muchas otras «reglas» concretas en las que el uso adecuado de STL puede aumentar notablemente la eficiencia del programa.

[50]

CAPÍTULO 2. C++ AVANZADO

2.2.2. Semántica de copia Una cuestión que a menudo confunde a los programadores novatos en la semántica de copia de STL. Significa que los contenedores almacenan copias de los elementos añadidos, y del mismo modo, devuelven copias cuando se extraen. El siguiente listado ilustra este hecho. Listado 2.37: Semántica de copia de la STL 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

class Counter { int value; public: Counter(void) : value(0) {} void inc(void) { ++value; } int get(void) { return value; } }; void test_copy_semantics(void) { vector counters; Counter c1; counters.push_back(c1); Counter c2 = counters[0]; counters[0].inc(); assert(c1.get() == 0); assert(counters[0].get() == 1); assert(c2.get() == 0); }

Esto tiene graves implicaciones en la eficiencia de las operaciones que se realizan sobre el contenedor. Todos los algoritmos que impliquen añadir, mover y eliminar elementos dentro de la secuencia (la práctica totalidad de ellos) realizan copias, al menos cuando se trata de contenedores basados en bloque. El siguiente listado es un «decorador» bastante rudimentario para string que imprime información cada vez que una instancia es creada, copiada o destruida. Listado 2.38: Semántica de copia de la STL 1 class String { 2 string value; 3 string desc; 4 public: 5 String(string init) : value(init), desc(init) { 6 cout parent = y; if (y == 0) root = z; else if (z->key < y->key) y->left = z; else y->right = z; }

Básicamente replica el procedimiento de búsqueda para encontrar el hueco donde debe insertar el elemento, manteniendo el padre del elemento actual para poder recuperar el punto adecuado al llegar a un nodo nulo. El procedimiento más complejo es el de borrado de un nodo. De acuerdo a [12] se identifican los cuatro casos que muestra la figura 2.3. Un caso no representado es el caso trivial en el que el nodo a borrar no tenga hijos. En ese caso basta con modificar el nodo padre para que el hijo correspondiente sea el objeto nulo. Los dos primeros casos de la figura corresponden al borrado de un nodo con un solo hijo, en cuyo caso el hijo pasa a ocupar el lugar del nodo a borrar. El tercer caso corresponde al caso en que el hijo derecho no tenga hijo izquierdo o el hijo izquierdo no tenga hijo derecho, en cuyo caso se puede realizar la misma operación que en los casos anteriores enlazando adecuadamente las dos ramas. El cuarto caso corresponde al caso general, con dos hijos no nulos. En ese caso buscamos un sucesor del subárbol izquierdo que no tenga hijo izquierdo, que pasa a reemplazar al nodo, reajustando el resto para mantener la condición de árbol de búsqueda binaria. Con el objetivo de facilitar el movimiento de subárboles definimos el método transplant(). El subárbol con raíz u se reemplaza con el subárbol con raíz v. Listado 2.55: Transplantado de subárboles en un árbol de búsqueda binaria 1 2 3 4 5 6 7 8 9 10

void transplant(NodeType* u, NodeType* v) { if (u->parent == 0) root = v; else if (u == u->parent->left) u->parent->left = v; else u->parent->right = v; if (v != 0) v->parent = u->parent; }

[64]

CAPÍTULO 2. C++ AVANZADO

(a)

q

q

z

r r

NIL

(b)

q

q

z

l

l

NIL

(c)

q

q

z

y y

l NIL

(d)

q

z

z r

l

q y

y r

NIL x

y NIL

x

q

l

x

l

r

l x

x

Figura 2.3: Casos posibles según [12] en el borrado de un nodo en un árbol de búsqueda binaria

Nótese que no alteramos el nodo padre de v ni los hijos de v. La responsabilidad de actualizarlos corresponde al que llama a transplant(). Empleando este procedimiento auxiliar es muy sencilla la implementación de remove().

2.3. Estructuras de datos no lineales

[65]

10 4

17

5

1 NIL

NIL

NIL

16 NIL

NIL

21 NIL

NIL

NIL

Figura 2.4: Ejemplo de árbol rojo-negro. Los nodos hoja no se representarán en el resto del texto.

Listado 2.56: Borrado en un árbol de búsqueda binaria 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

void remove(NodeType* z) { if (z->left == 0) transplant(z, z->right); else if (z->right == 0) transplant(z, z->left); else { NodeType* y = NodeType::minimum(z->right); if (y->parent != z) { transplant(y, y->right); y->right = z->right; y->right->parent = y; } transplant(z, y); y->left = z->left; y->left->parent = y; } }

Todos los procedimientos básicos (minimum(), maximum(), search(), predecesor(), successor(), insert() y remove()) se ejecutan en tiempo O(h) donde h es la altura del árbol. Si el árbol está equilibrado esto implica O(log n). Red-black trees La eficiencia de un árbol de búsqueda binaria depende enormemente del orden en que se introduzcan los elementos. Pueden ser muy eficientes o en el caso peor degenerar a una simple lista doblemente enlazada. Para resolver este problema se han propuesto multitud de esquemas que garantizan que el árbol siempre está equilibrado complicando ligeramente la inserción y borrado. Los árboles rojo-negro son un caso de estos árboles de búsqueda binaria balanceados. Cada nodo almacena un bit extra, el color, que puede ser rojo o negro. En cada camino simple desde el nodo raíz a una hoja se restringen los colores de manera que nunca pueda ser un camino más del doble de largo que otro cualquiera:

[66]

CAPÍTULO 2. C++ AVANZADO

1. Cada nodo es rojo o negro. 2. El nodo raíz es negro. 3. Las hojas del árbol (objetos nulos) son negras. 4. Los hijos de un nodo rojo son negros. 5. Los caminos desde un nodo a todas sus hojas descendientes contienen el mismo número de nodos negros. Podemos simplificar los algoritmos eliminando la necesidad de comprobar si es un nodo nulo antes de indexar un elemento sin más que utilizar un nodo especial que usamos como centinela. La estructura del nodo podría ser algo así: Listado 2.57: Definición de un nodo de un árbol rojo-negro. 1 template 2 struct Node { 3 typedef Node NodeType; 4 enum Color { Red = false, Black = true }; 5 6 KeyType key; 7 NodeType* parent; 8 NodeType* left; 9 NodeType* right; 10 Color color; 11 12 Node() { 13 left = right = parent = nil(); 14 } 15 16 static NodeType* nil() { 17 if (!_nil) 18 _nil = new Node(Black); 19 return &_nil; 20 }

Las operaciones maximum(), minimum(), search(), successor() y predecesor() son completamente análogas a las de los árboles de búsqueda binaria tradicionales, salvo que ahora está garantizado que se ejecutan en tiempo O(log n). Por ejemplo, la función maximum() sería: Listado 2.58: Búsqueda del mayor elemento en un árbol rojo-negro. 1 2 3 4

static NodeType* maximum(NodeType* x) { if (x->right != NodeType::nil()) return maximum(x->right); return x; }

Nótese que ya no es necesario comprobar si x es nulo antes de indexar su miembro right, puesto que para representar al nodo nulo usamos un centinela perfectamente válido.

2.3. Estructuras de datos no lineales

[67]

En cambio las operaciones de inserción y borrado deben ser modificadas para garantizar que se mantienen las propiedades de árbol rojo-negro. Para ello nos apoyaremos en dos funciones auxiliares: rotate_left() y rotate_right(): Listado 2.59: Rotación a la izquierda en un árbol de búsqueda binaria 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

void rotate_left(NodeType* x) { NodeType* y = x->right; x->right = y->left; if (y->left != NodeType::nil()) y->left->parent = x; y->parent = x->parent; if (x->parent == NodeType::nil()) root = y; else if (x == x->parent->left) x->parent->left = y; else x->parent->right = y; y->left = x; x->parent = y; }

rotate right

y x a

c

rotate left

x y

a

b

b

c

Figura 2.5: Operación de rotación a la derecha o a la izquierda en un árbol de búsqueda binaria

La operación dual rotate_right() puede implementarse simplemente intercambiando en el algoritmo anterior x por y, y left por right. La inserción puede ahora realizarse de una forma muy parecida al caso general asumiendo que el color del nodo a insertar es rojo y después arreglando el árbol con rotaciones y cambios de color. Listado 2.60: Inserción en un árbol rojo-negro 1 2 3 4 5 6 7 8 9 10 11 12 13

void insert(NodeType* z) { NodeType* y = NodeType::nil(); NodeType* x = root; while (x != NodeType::nil()) { y = x; if (z->key < x->key) x = x->left; else x = x->right; } z->parent = y; if (y == NodeType::nil()) root = z;

[68]

14 15 16 17 18 19 20 21 22

CAPÍTULO 2. C++ AVANZADO

else if (z->key < y->key) y->left = z; else y->right = z; z->left = NodeType::nil(); z->right = NodeType::nil(); z->color = Node::Color::Red; insert_fixup(z); }

Al asumir el color rojo podemos haber violado las reglas de los árboles rojo-negro. Por esta razón llamamos a la función insert_fixup() que garantiza el cumplimiento de las reglas tras la inserción: Listado 2.61: Reparación tras la inserción en árbol rojo-negro 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

void insert_fixup(NodeType* z) { while (z->parent->color == Node::Color::Red) { if (z->parent == z->parent->parent->left) { NodeType* y = z->parent->parent->right; if (y->color == Node::Color::Red) { z->parent->color = Node::Color::Black; y->color = Node::Color::Black; z->parent->parent->color = Node::Color::Red; z = z->parent->parent; } else { if (z == z->parent->right) { z = z->parent; rotate_left(z); } z->parent->color = Node::Color::Black; z->parent->parent->color = Node::Color::Red; rotate_right(z->parent->parent); } } else { NodeType* y = z->parent->parent->left; if (y->color == Node::Color::Red) { z->parent->color = Node::Color::Black; y->color = Node::Color::Black; z->parent->parent->color = Node::Color::Red; z = z->parent->parent; } else { if (z == z->parent->left) { z = z->parent; rotate_right(z); } z->parent->color = Node::Color::Black; z->parent->parent->color = Node::Color::Red; rotate_left(z->parent->parent); } } } root->color = Node::Color::Black; }

La inserción de un nodo rojo puede violar la regla 2 (el nodo raíz queda como rojo en el caso de un árbol vacío) o la regla 4 (el nodo insertado pasa a ser hijo de un nodo rojo). Este último caso es el que

2.3. Estructuras de datos no lineales

[69]

se contempla en el bucle de la función insert_fixup(). Cada una de las dos ramas del if sigue la estrategia dual, dependiendo de si el padre es un hijo derecho o izquierdo. Basta estudiar el funcionamiento de una rama, dado que la otra es idéntica pero intercambiando right y left. Básicamente se identifican tres casos. ✄ ✄ El primero corresponde a las líneas ✂6 ✁a ✂9 ✁. Es el caso en que el nodo a insertar pasa a ser hijo de un nodo rojo cuyo hermano también es rojo (e.g. figura 2.6.a). En este caso el nodo padre y el nodo tío se pasan a negro mientras que el abuelo se pasa a rojo (para mantener el número de nodos negros en todos los caminos). Al cambiar a rojo el nodo abuelo es posible que se haya vuelto a violar alguna regla, y por eso se vuelven a comprobar los casos. Otra posibilidad es que el nodo tío sea negro y además el nodo insertado sea hijo derecho (e.g. figura 2.6.b). En ese caso se realiza una rotación a la izquierda para reducirlo al caso siguiente y se aplica lo correspondiente al último caso. El último caso corresponde a que el nodo tío sea negro y el nodo insertado sea hijo izquierdo (e.g. figura 2.6.c). En ese caso se colorea el padre como negro, y el abuelo como rojo, y se rota a la derecha el abuelo. Este método deja un árbol correcto.

z

z

(a)

z

(b)

(c)

Figura 2.6: Casos contemplados en la función insert_fixup().

El borrado también se apoya en la función transplant() que es muy similar al caso de los árboles de búsqueda binaria. Listado 2.62: Transplantado de subárboles en árbol rojo-negro 1 2 3 4 5 6 7 8 9

void transplant(NodeType* u, NodeType* v) { if (u->parent == NodeType::nil()) root = v; else if (u == u->parent->left) u->parent->left = v; else u->parent->right = v; v->parent = u->parent; }

[70]

CAPÍTULO 2. C++ AVANZADO

Con este procedimiento auxiliar el borrado de un nodo queda relativamente similar al caso de árboles de búsqueda binaria. Listado 2.63: Borrado de un nodo en árboles rojo-negro 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

void remove(NodeType* z) { NodeType* y = z; NodeType* x; NodeType::Color y_orig_color = y->color; if (z->left == NodeType::nil()) { x = z->right; transplant(z, z->right); } else if (z->right == NodeType::nil()) { x = z->left; transplant(z, z->left); } else { y = Node::minimum(z->right); y_orig_color = y->color; x = y->right; if (y->parent == z) { x->parent = y; } else { transplant(y, y->right); y->right = z->right; y->right->parent = y; } transplant(z, y); y->left = z->left; y->left->parent = y; y->color = z->color; } if (y_orig_color == Node::Color::Black) rb_remove_fixup(x); }

El nodo y corresponde al nodo que va a eliminarse o moverse dentro del árbol. Será el propio z si tiene menos de dos hijos o el nodo y de los casos c y d en la figura 2.3. Mantenemos la variable y_orig_color con el color que tenía ese nodo que se ha eliminado o movido dentro del árbol. Solo si es negro puede plantear problemas de violación de reglas, porque el número de nodos negros por cada rama puede variar. Para arreglar los problemas potenciales se utiliza una función análoga a la utilizada en la inserción de nuevos nodos. Listado 2.64: Reparación tras borrar un nodo en árboles rojo-negro 1 2 3 4 5 6 7 8 9 10 11

void remove_fixup(NodeType* x) { while (x != root && x->color == Node::Color::Black) { if (x == x->parent->left) { NodeType* w = x->parent->right; if (w->color == Node::Color::Red) { w->color = Node::Color::Black; x->parent->color = Node::Color::Red; rotate_left(x->parent); w = x->parent->right; } if (w->left->color == Node::Color::Black

2.3. Estructuras de datos no lineales

12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59

[71]

&& w->right->color == Node::Color::Black) { w->color = Node::Color::Red; x = x->parent; } else { if (w->right->color == Node::Color::Black) { w->left->color = Node::Color::Black; w->color = Node::Color::Red; rotate_right(w); w = x->parent->right; } w->color = x->parent->color; x->parent->color = Node::Color::Black; w->right->color = Node::Color::Black; rotate_left(x->parent); x = root; } } else { NodeType* w = x->parent->left; if (w->color == Node::Color::Red) { w->color = Node::Color::Black; x->parent->color = Node::Color::Red; rotate_right(x->parent); w = x->parent->left; } if (w->right->color == Node::Color::Black && w->left->color == Node::Color::Black) { w->color = Node::Color::Red; x = x->parent; } else { if (w->left->color == Node::Color::Black) { w->right->color = Node::Color::Black; w->color = Node::Color::Red; rotate_left(w); w = x->parent->left; } w->color = x->parent->color; x->parent->color = Node::Color::Black; w->left->color = Node::Color::Black; rotate_right(x->parent); x = root; } } } x->color = Node::Color::Black; }

Nuevamente se trata de un código dual. En el if más exterior se distinguen los casos de borrar un hijo derecho o izquierdo. En ambas ramas se encuentra el mismo código intercambiando left por right. Por tanto basta analizar la primera de ellas. Se distinguen cuatro casos: El hermano w es rojo. En ese caso forzosamente los hijos de w deben ser negros. Por tanto se puede intercambiar los colores del hermano y del padre y hacer una rotación a la izquierda sin violar nuevas reglas. De esta forma el nuevo hermano será forzosamente negro, por lo que este caso se transforma en alguno de los posteriores.

[72]

CAPÍTULO 2. C++ AVANZADO El hermano w es negro y los dos hijos de w son negros. En ese caso cambiamos el color del hermano a rojo. De esta forma se equilibra el número de negros por cada rama, pero puede generar una violación de reglas en el nodo padre, que se tratará en la siguiente iteración del bucle. El hermano w es negro y el hijo izquierdo de w es rojo. En ese caso intercambiamos los colores de w y su hijo izquierdo y hacemos una rotación a la derecha. De esta forma hemos reducido este caso al siguiente. El hermano w es negro y el hijo derecho de w es rojo. En este caso cambiando colores en los nodos que muestra la figura 2.7.d y rotando a la izquierda se obtiene un árbol correcto que compensa el número de negros en cada rama.

AVL trees Los árboles AVL son otra forma de árbol balanceado en el que se utiliza la altura del árbol como criterio de balanceo. Solo puede haber una diferencia de 1 entre la altura de dos ramas. Es por tanto un criterio más estricto que los red-black trees, lo que lo hace menos eficiente en las inserciones y borrados pero más eficiente en las lecturas. Cada nodo tiene información adicional con la altura del árbol en ese punto. En realidad tan solo es necesario almacenar el factor de equilibrio que es simplemente la diferencia entre las alturas del subárbol izquierdo y el derecho. La ventaja de esta última alternativa es que es un número mucho más reducido (siempre comprendido en el rango -2 a +2) por lo que puede almacenarse en solo 3 bits. Para insertar elementos en un árbol AVL se utiliza un procedimiento similar a cualquier inserción en árboles de búsqueda binaria, con dos diferencias: La inserción debe computar el factor de equilibrio en los nodos afectados. Finalmente hay que equilibrar el árbol si es necesario. El equilibrado se realiza con rotaciones siguiendo el procedimiento representado en la figura 2.8. Es importante destacar que las propias funciones de rotación alteran los factores de equilibrio de los nodos involucrados (nodos x e y en la figura 2.5).

Las operaciones insert(), rotate_right(), rotate_left() y remove() sobre árboles AVL deben recalcular el factor de equilibrio en los nodos afectados. Además, en caso de dejar un árbol desequilibrado, las operaciones insert() y remove() deben equilibrar el árbol según el procedimiento descrito en la figura 2.8.

Árboles balanceados Los red-black trees son más eficientes en insert() y remove(), pero los AVL trees son más eficientes en search().

2.3. Estructuras de datos no lineales

[73]

(a) B

D

x A

D C

w E

B

x A

E

w C

(b) x B

B

x A

D w C

A

D C

E

E

(c) B

B

x A

D C

w

x A

C

E

w D E

(d) B

D

x A

D C

w E

B A

E C

Figura 2.7: Casos contemplados en la función remove_fixup() según [12].

[74]

CAPÍTULO 2. C++ AVANZADO

(a)

A

h+2

A

h

h

h+2

B

B C

C

rotate_left(B)

rotate_right(B)

A

A

(b) h+2

h

h

h+2

C

C

B

B

rotate_right(A)

rotate_left(A)

C

C

(c) h+1

h+1

h+1

h+1

B

A

B

A

Figura 2.8: Casos contemplados en la función de equilibrado de árboles AVL.

Radix tree Aún hay otro tipo de árboles binarios que vale la pena comentar por sus implicaciones con los videojuegos. Se trata de los árboles de prefijos, frecuentemente llamados tries9 . La figura 2.9 muestra un ejemplo de árbol de prefijos con un conjunto de enteros binarios. El árbol los representa en orden lexicográfico. Para cada secuencia binaria si empieza por 0 está en el subárbol izquierdo y si empieza por 1 en el subárbol derecho. Conforme se recorren las ramas del árbol se obtiene la secuencia de bits del número a buscar. Es decir, el tramo entre el nodo raíz y cualquier nodo intermedio define el prefijo por el que empieza el número a buscar. Por eso a este árbol se le llama prefix tree o radix tree. 9 El nombre en singular es trie, que deriva de retrieve. Por tanto la pronunciación correcta se asemeja a la de tree, aunque muchos autores la pronuncian como try.

2.3. Estructuras de datos no lineales

[75]

0

1

0

1

0 10

1

0

011

100

1 1 1011

Figura 2.9: Un ejemplo de trie extraido de [12]. Contiene los elementos 1011, 10, 011, 100 y 0.

Un árbol de prefijos (pero no binario) se utiliza frecuentemente en los diccionarios predictivos de los teléfonos móviles. Cada subárbol corresponde a una nueva letra de la palabra a buscar. También se puede utilizar un árbol de prefijos para indexar puntos en un segmento de longitud arbitraria. Todos los puntos en la mitad derecha del segmento están en el subárbol derecho, mientras que todos los puntos de la mitad izquierda están en el subárbol izquierdo. Cada subárbol tiene las mismas propiedades con respecto al subsegmento que representa. Es decir, el subárbol derecho es un árbol de prefijos que representa a medio segmento derecho, y así sucesivamente. El número de niveles del árbol es ajustable dependiendo de la precisión que requerimos en el posicionamiento de los puntos. En los árboles de prefijos la posición de los nodos está prefijada a priori por el valor de la clave. Estos árboles no realizan ninguna función de equilibrado por lo que su implementación es trivial. Sin embargo estarán razonablemente equilibrados si los nodos presentes están uniformemente repartidos por el espacio de claves.

2.3.2. Recorrido de árboles En multitud de ocasiones es necesario recorrer los elementos de un árbol en un orden determinado. Son frecuentes los recorridos en orden, en preorden, y en postorden. El recorrido en orden sigue el orden del campo clave. Es decir, para cualquier nodo primero se visitan los nodos del subárbol izquierdo, luego el nodo y finalmente los nodos del subárbol derecho. Listado 2.65: Recorrido en orden en un árbol de búsqueda binaria 1 2 3 4 5 6

template void inorder_tree_walk(Func f) { inorder_tree_walk(root, f); } template

[76]

7 8 9 10 11 12

CAPÍTULO 2. C++ AVANZADO

void inorder_tree_walk(NodeType* x, Func f) { if (x == 0) return; inorder_tree_walk(x->left, f); f(x); inorder_tree_walk(x->right, f); }

El recorrido en preorden visita el nodo antes de cualquiera de sus subárboles. Listado 2.66: Recorrido en preorden en un árbol de búsqueda binaria 1 2 3 4 5 6 7 8 9 10 11 12

template void preorder_tree_walk(Func f) { preorder_tree_walk(root, f); } template void preorder_tree_walk(NodeType* x, Func f) { if (x == 0) return; f(x); preorder_tree_walk(x->left, f); preorder_tree_walk(x->right, f); }

Finalmente el recorrido en postorden visita el nodo después de visitar ambos subárboles.

ria 1 2 3 4 5 6 7 8 9 10 11 12

Listado 2.67: Recorrido en postorden en un árbol de búsqueda binatemplate void postorder_tree_walk(Func f) { postorder_tree_walk(root, f); } template void postorder_tree_walk(NodeType* x, Func f) { if (x == 0) return; postorder_tree_walk(x->left, f); postorder_tree_walk(x->right, f); f(x); }

Pero para el recorrido de estructuras de datos con frecuencia es mucho mejor emplear el patrón iterador. En ese caso puede reutilizarse cualquier algoritmo de la STL. Incluir el orden de recorrido en el iterador implica almacenar el estado necesario. Las funciones de recorrido anteriormente descritas son recursivas, por lo que el estado se almacenaba en los sucesivos marcos de pila correspondientes a cada llamada anidada. Por tanto necesitamos un contenedor con la ruta completa desde la raíz hasta el nodo actual. También tendremos que almacenar el estado de recorrido de dicho nodo, puesto que el mismo nodo es visitado en tres ocasiones, una para el subárbol izquierdo, otra para el propio nodo, y otra para el subárbol derecho.

2.3. Estructuras de datos no lineales

[77]

Listado 2.68: Iterador en orden en un árbol de búsqueda binaria 1 class inorder_iterator : public std::iterator {

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

typedef Node NodeType; enum IteratorState { VisitingLeft, VisitingNode, VisitingRight }; std::vector _current; public: inorder_iterator(NodeType* x) { _current.push_back(std::make_pair(x,VisitingLeft)); goToNextNode(); } const NodeType& operator*() const { return *_current.back().first; } const NodeType* operator->() const { return _current.back().first; } bool equal(inorder_iterator const& rhs) const { return *this == rhs; } inorder_iterator& operator++() { goToNextNode(); } inorder_iterator operator++(int) { inorder_iterator ret(*this); goToNextNode(); return ret; } private: void goToNextNode(); }; template inline bool operator== (inorder_iterator const& lhs, inorder_iterator const& rhs) { return lhs.equal(rhs); }

En el caso del iterador en orden la función de recorrido sería similar a la siguiente: Listado 2.69: Función para obtener el siguiente nodo en un iterador en orden. 1 void 2 inorder_iterator::goToNextNode() 3 { 4 if (_current.empty()) return; 5

[78]

6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 }

CAPÍTULO 2. C++ AVANZADO

std::pair& last = _current.back(); if (last.second == VisitingLeft) { NodeType* l = last.first->left; if (l == 0) last.second = VisitingNode; else { _current.push_back(std::make_pair(l,VisitingLeft)); goToNextNode(); } } else if (last.second == VisitingNode) { NodeType* r = last.first->right; if (r == 0) _current.pop_back(); else { last.second = VisitingRight; _current.push_back(std::make_pair(r,VisitingLeft)); } goToNextNode(); } else if (last.second == VisitingRight) { _current.pop_back(); goToNextNode(); }

Se propone como ejercicio la definición de iteradores para el recorrido en preorden y postorden.

2.3.3. Quadtree y octree Los árboles binarios particionan de forma eficiente un espacio de claves de una sola dimensión. Pero con pequeñas extensiones es posible particionar espacios de dos y tres dimensiones. Es decir, pueden ser usados para indexar el espacio de forma eficiente.

Figura 2.10: Ejemplo de quadtree de puntos. Fuente: Wikipedia.

2.3. Estructuras de datos no lineales

[79]

Los quadtrees y los octrees son la extensión natural de los árboles binarios de prefijos (tries) para dos y tres dimensiones respectivamente. Un quadtree es un árbol cuyos nodos tienen cuatro subárboles correspondientes a los cuatro cuadrantes de un espacio bidimensional. Los nodos de los octrees tienen ocho subárboles correspondientes a los ocho octantes de un espacio tridimensional. La implementación y el funcionamiento es análogo al de un árbol prefijo utilizado para indexar los puntos de un segmento. Adicionalmente, también se emplean para indexar segmentos y polígonos. Cuando se utilizan para indexar segmentos o polígonos puede ocurrir que un mismo segmento cruce el límite de un cuadrante o un octante. En ese caso existen dos posibles soluciones: Hacer un recortado (clipping) del polígono dentro de los límites del cuadrante u octante. Poner el polígono en todos los cuadrantes u octantes con los que intersecta. En este último caso es preciso disponer de alguna bandera asociada a los polígonos para no recorrerlos más veces de las necesarias. Simon Perreault distribuye una implementación sencilla y eficiente de octrees en C++10 . Simplificando un poco esta implementación los nodos son representados de esta forma: Listado 2.70: Representación de nodos en un octree. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

enum NodeType { BranchNode, LeafNode }; class Node { public: NodeType type() const; private: NodeType type_ : 2; }; class Branch : public Node { public: Node*& child( int x, int y, int z ); Node*& child( int index ); private: Node* children[2][2][2]; }; class Leaf : public Node { public: Leaf( const T& v ); const T& value() const; T& value(); void setValue( const T& v );

10 En el momento de editar estas notas se distribuye bajo la GPL en http://nomis80. org/code/octree.html.

[80]

CAPÍTULO 2. C++ AVANZADO

28 private: 29 T value_; 30 };

Esta representación de árboles diferencia entre nodos hoja y nodos de ramificación. Los valores solo se almacenan en los nodos hoja y éstos no tienen la sobrecarga de los punteros a los ocho subárboles. Por contra, los nodos de ramificación no tienen sobrecarga de valores asociados, puesto que para la inserción de un elemento puede ser necesario añadir un número de nodos de ramificación sin valor alguno. El uso básico es muy sencillo. El contenido a incluir puede ser cualquier cosa, desde simples valores (color de un punto), pasando por un voxel (pixel 3D) hasta polígonos o poliedros. El tipo de contenido puede ser también una referencia a un objeto gráfico. De esta forma se podría incluir el mismo elemento (e.g. un polígono) en múltiples nodos hoja. En el capítulo siguiente veremos cómo la técnica de referencias con contador puede ayudar en casos como éste. Listado 2.71: Representación de nodos en un octree. 1 2 3 4 5 6 7 8

#include "octree.h" int main() { Octree o(4096); o(1,2,3) = 3.1416; o.erase(1,2,3); }

✄ La línea ✂5 ✁ construye un octree de 4096 puntos de ancho en cada dimensión. Esta implementación requiere que sea una potencia de dos, siendo posible indexar 4096 × 4096 × 4096 nodos.

La regularidad de los octree los hacen especialmente indicados para la paralelización con GPU y recientemente están teniendo cierto resurgimiento con su utilización en el renderizado de escenas con raycasting o incluso raytracing en una técnica denominada Sparse Voxel Octree.

La propia nVidia11 ha desarrollado una biblioteca que implementa esta técnica de sparse voxel octree sobre GPU con CUDA, y se distribuye bajo licencia Apache. Otra excelente fuente de información es la tesis de Cyril Crassin de INRIA12 que explica los fundamentos teóricos de GigaVoxels, también basada en octrees. 11 Ver

http://research.nvidia.com/publication/efficient-sparse-voxel-octrees en línea en http://maverick.inria.fr/Membres/Cyril.Crassin/ thesis/CCrassinThesis_EN_Web.pdf 12 Disponible

Figura 2.11: Ejemplo del motor de Sparse Voxel Octree de nVidia.

2.4. Patrones de diseño avanzados

2.4.

[81]

Patrones de diseño avanzados

En el módulo 1 ya se expusieron un buen número de patrones. En esta sección completaremos la colección con algunos patrones muy utilizados en todo tipo de aplicaciones.

2.4.1. Forma canónica ortodoxa Veamos un ejemplo de mal uso de C++ que se ve frecuentemente en programas reales: Listado 2.72: Ejemplo de uso incorrecto de C++. 1 2 3 4 5 6 7 8 9 10 11 12 13 14

#include struct A { A() : a(new char[3000]) {} ~A() { delete [] a; } char* a; }; int main() { A var; std::vector v; v.push_back(var); return 0; }

Si compilamos y ejecutamos este ejemplo nos llevaremos una desagradable sorpresa. $ g++ bad.cc -o bad $ ./bad *** glibc detected *** ./bad: double free or corruption (!prev): 0 x00000000025de010 *** ======= Backtrace: ========= ...

¿Qué es lo que ha pasado? ¿No estamos reservando memoria en el constructor y liberando en el destructor? ¿Cómo es posible que haya corrupción de memoria? La solución al enigma es lo que no se ve en el código. Si no lo define el usuario el compilador de C++ añade automáticamente un constructor de copia que implementa la estrategia más simple, copia de todos los miembros. En particular cuando llamamos a push_back() creamos una copia de var. Esa copia recibe a su vez una copia del miembro var.a que es un puntero a memoria ya reservada. Cuando se termina main() se llama al destructor de var y del vector. Al destruir el vector se destruyen todos los elementos. En particular se destruye la copia de var, que a su vez libera la memoria apuntada por su miembro a, que apunta a la misma memoria que ya había liberado el destructor de var. Antes de avanzar más en esta sección conviene formalizar un poco la estructura que debe tener una clase en C++ para no tener sorpresas.

[82]

CAPÍTULO 2. C++ AVANZADO

Básicamente se trata de especificar todo lo que debe implementar una clase para poder ser usada como un tipo cualquiera: Pasarlo como parámetro por valor o como resultado de una función. Crear arrays y contenedores de la STL. Usar algoritmos de la STL sobre estos contenedores. Para que no aparezcan sorpresas una clase no trivial debe tener como mínimo: 1. Constructor por defecto. Sin él sería imposible instanciar arrays y no funcionarían los contenedores de la STL. 2. Constructor de copia. Sin él no podríamos pasar argumentos por valor, ni devolverlo como resultado de una función. 3. Operador de asignación. Sin él no funcionaría la mayoría de los algoritmos sobre contenedores. 4. Destructor. Es necesario para liberar la memoria dinámica reservada. El destructor por defecto puede valer si no hay reserva explícita. A este conjunto de reglas se le llama normalmente forma canónica ortodoxa (orthodox canonical form). Además, si la clase tiene alguna función virtual, el destructor debe ser virtual. Esto es así porque si alguna función virtual es sobrecargada en clases derivadas podrían reservar memoria dinámica que habría que liberar en el destructor. Si el destructor no es virtual no se podría garantizar que se llama. Por ejemplo, porque la instancia está siendo usada a través de un puntero a la clase base.

2.4.2. Smart pointers Los punteros inteligentes (smart pointers) son tipos de datos que simplifican de alguna manera la gestión de la memoria dinámica. Facilitan la gestión del ciclo de vida de las variables dinámicas para evitar los problemas frecuentemente asociados a los punteros, especialmente la liberación de la memoria. La biblioteca estándar de C++ incorpora una plantilla denominada auto_ptr. Su objetivo es envolver un puntero normal de tal forma que la destrucción del puntero lleve consigo también la destrucción del objeto apuntado. Por lo demás, un auto_ptr se comporta como si se tratara del propio puntero.

2.4. Patrones de diseño avanzados

[83]

Por ejemplo, es frecuente encontrar código como el que sigue: Listado 2.73: Ejemplo de uso inseguro de punteros. 1 2 3 4 5

T* p = new T(); // cuerpo de la función delete p;

Este fragmento tiene dos problemas: Es relativamente fácil olvidar llamar a delete. Conforme evoluciona el código pueden aparecer puntos de retorno que no invocan al destructor. En esta secuencia no es posible garantizar que el flujo del programa será secuencial. Es perfectamente posible que en medio del código de la función se eleve una excepción. En ese caso no se ejecutará el delete. Por supuesto siempre es posible utilizar construcciones try/catch pero el código cada vez se haría menos legible. Bjarne Stroustrup inventó una técnica de aplicación general para resolver este tipo de problemas. Se llama resource acquisition is initialization (RAII) y básicamente consiste en encapsular las operaciones de adquisición de recursos y liberación de recursos en el constructor y destructor de una clase normal. Esto es precisamente lo que hace auto_ptr con respecto a la reserva de memoria dinámica. El mismo código del fragmento anterior puede reescribirse de forma segura así: Listado 2.74: Ejemplo de uso seguro de punteros. 1 2 3

auto_ptr p = new T(); // cuerpo de la función

No importa el camino que siga el programa, aunque se eleve una excepción. En el momento en que se abandone el bloque en el que se ha declarado el auto_ptr se invocará a su destructor, que a su vez invocará delete. Como puede verse hemos ligado el tiempo de vida del objeto construido en memoria dinámica al tiempo de vida del auto_ptr, que suele ser una variable automática o un miembro de clase. Se dice que el auto_ptr posee al objeto dinámico. Pero puede ceder su posesión simplemente con una asignación o una copia a otro auto_ptr.

[84]

CAPÍTULO 2. C++ AVANZADO

Listado 2.75: Cesión de la posesión del objeto dinámico. 1 2 3 4 5 6 7

auto_ptr q(p); auto_ptr r; p->f(); // error (NULL ref) q->f(); // ok r = q; q->f(); // error (NULL ref) r->f(); // ok

Es decir, auto_ptr garantiza que solo hay un objeto que posee el objeto dinámico. También permite desligar el objeto dinámico del auto_ptr para volver a gestionar la memoria de forma explícita. Listado 2.76: Recuperación de la propiedad del objeto dinámico. 1 2

T* s = r.release(); delete s;

Nunca se deben usar auto_ptr en contenedores estándar, porque los contenedores de la STL asumen una semántica de copia incompatible con la del auto_ptr. La copia de un auto_ptr no genera dos objetos equivalentes. Esta limitación, que no es detectada en tiempo de compilación, es una de las motivaciones de un completo rediseño de esta funcionalidad para el estándar C++ de 2011. Aún sigue soportando auto_ptr pero se desaconseja su uso en favor de unique_ptr. El nombre deriva de que, al igual que auto_ptr, garantiza que solo un unique_ptr puede estar apuntando a un mismo recurso. Sin embargo, a diferencia de auto_ptr no es posible copiarlos. Sin embargo existe la posibilidad de transferencia de propiedad entre unique_ptr utilizando la nueva semántica de movimiento del estándar C++11. Listado 2.77: Ejemplo de uso de unique_ptr. 1 2 3 4

unique_ptr p(new T()); unique_ptr q; q = p; // error (no copiable) q = std:move(p);

La plantilla unique_ptr no tiene un constructor de copia, pero sí cuenta con un constructor de movimiento. Este nuevo constructor se aplica cuando el parámetro es un rvalue, es decir, una expresión del tipo de las que aparecen en el lado derecho de una asignación (de ahí el nombre, right value) o un valor de retorno de función, o la copia temporal de un parámetro pasado por copia (ahora se puede pasar también por movimiento). Este tipo de expresiones se caracterizan en C++ porque generan un temporary, una variable temporal. La semántica de movimiento resuelve el problema de la generación inconsciente de multitud de variables temporales y la separación entre constructor de copia y constructor de movimiento permite detectar en tiempo de compilación los problemas semánticos. La copia siempre debería generar dos objetos equivalentes.

2.4. Patrones de diseño avanzados

[85]

Tanto auto_ptr como unique_ptr proporcionan un método sencillo para gestionar variables en memoria dinámica casi como si se tratara de variables automáticas. Por ejemplo: Listado 2.78: Función que reserva memoria dinámica y traspasa la propiedad al llamador. También funcionaría correctamente con auto_ptr. 1 unique_ptr f() { 2 unique_ptr p(new T()); 3 // ... 4 return p; 5 }

La función f() devuelve memoria dinámica. Con simples punteros eso implicaba que el llamante se hacía cargo de su destrucción, de controlar su ciclo de vida. Con esta construcción ya no es necesario. Si el llamante ignora el valor de retorno éste se libera automáticamente al destruir la variable temporal correspondiente al valor de retorno. Si en cambio el llamante asigna el valor de retorno a otra variable unique_ptr entonces está asumiendo la propiedad y se liberará automáticamente cuando el nuevo unique_ptr sea destruido.

Las nuevas características de la biblioteca estándar para la gestión del ciclo de vida de la memoria dinámica están ya disponibles en los compiladores libres GCC y clang. Tan solo hay que utilizar la opción de compilación -std¯ c++0x.

Tanto con auto_ptr como con unique_ptr se persigue que la gestión de memoria dinámica sea análoga a la de las variables automáticas con semántica de copia. Sin embargo no aprovechan la posibilidad de que el mismo contenido de memoria sea utilizado desde varias variables. Es decir, para que la semántica de copia sea la natural en los punteros, que se generen dos objetos equivalentes, pero sin copiar la memoria dinámica. Para ese caso el único soporte que ofrecía C++ hasta ahora eran los punteros y las referencias. Y ya sabemos que ese es un terreno pantanoso. La biblioteca estándar de C++11 incorpora dos nuevas plantillas para la gestión del ciclo de vida de la memoria dinámica que ya existían en la biblioteca Boost: shared_ptr y weak_ptr. Ambos cooperan para disponer de una gestión de memoria muy flexible. La plantilla shared_ptr implementa una técnica conocida como conteo de referencias. Cuando se asigna un puntero por primera vez a un shared_ptr se inicializa un contador interno a 1. Este contador se almacena en memoria dinámica y es compartido por todos los shared_ptr que apunten al mismo objeto. Cuando se asigna este shared_ptr a otro shared_ptr o se utiliza el constructor de copia, se incrementa el contador interno. Cuando se destruye un shared_ptr se decrementa el

[86]

CAPÍTULO 2. C++ AVANZADO

contador interno. Y finalmente cuando el contador interno llega a 0, se destruye automáticamente el objeto dinámico. Listado 2.79: Ejemplos de uso de shared_ptr. 1 2 3 4 5 6 7 8

shared_ptr p(new T()); shared_ptr q; { q = p; shared_ptr r(p); // ... } // ...

✄ En la línea ✂1 ✁se construye un shared_ptr que apunta a un objeto dinámico. Esto pone el contador interno de referencias a 1. En la línea ✄ ✂4 ✁ se asigna este shared_ptr a otro. No se copia el objeto dinámico, sino solo su dirección y la del contador de referencias, que además ✄ es automáticamente incrementado (pasa a valer 2). En la línea ✂5 ✁ se utiliza el constructor de copia de otro shared_ptr, que nuevamente copia solo el puntero y el puntero al contador de referencias, además ✄ de incrementar su valor (pasa a valer 3). En la línea ✂7 ✁se destruye automáticamente r, con lo que se decrementa el contador de referencias (vuelve a valer 2). Cuando acabe el bloque en el que se han declarado p y q se destruirán ambas variables, y con ello se decrementará dos veces el contador de referencias. Al llegar a 0 automáticamente se invocará el operador delete sobre el objeto dinámico. El conteo de referencias proporciona una poderosa herramienta para simplificar la programación de aplicaciones con objetos dinámicos. Los shared_ptr pueden copiarse o asignarse con total libertad y con una semántica intuitiva. Pueden emplearse en contenedores de la STL y pasarlos por valor libremente como parámetros a función o como valor de retorno de una función. Sin embargo no están totalmente exentos de problemas. Considera el caso en el que main() tiene un shared_ptr apuntando a una clase A y ésta a su vez contiene directa o indirectamente un shared_ptr que vuelve a apuntar a A. Tendríamos un ciclo de referencias y el contador de referencias con un balor de 2. En caso de que se destruyera el shared_ptr inicial seguiríamos teniendo una referencia a A, por lo que no se destruirá. Para romper los ciclos de referencias la biblioteca estándar incluye la plantilla weak_ptr. Un weak_ptr es otro smart pointer a un objeto que se utiliza en estas condiciones: 1. Solo se necesita acceso al objeto si existe. 2. Puede ser borrado por otros en cualquier momento. 3. Debe ser destruido tras su último uso. Bjarne Stroustrup 13 pone un ejemplo que tiene mucho que ver con la programación de videojuegos. Consideremos el caso del juego de los 13 Ver

http://www.research.att.com/~bs/C++0xFAQ.html#std-weak_ptr.

Figura 2.12: El propio creador de C++ pone como ejemplo el videojuego asteroids para explicar las extensiones a la biblioteca estándar.

2.4. Patrones de diseño avanzados

[87]

asteroides. Todos los asteroides son poseídos por “el juego” pero cada asteroide tiene que seguir los movimientos de los asteroides vecinos para detectar colisiones. Una colisión lleva a la destrucción de uno o más asteroides. Cada asteroide debe almacenar una lista de los asteroides vecinos. Pero el hecho de pertenecer a esa lista no mantiene al asteroide vivo. Por tanto el uso de shared_ptr sería inapropiado. Por otro lado un asteroide no debe ser destruido mientras otro asteroide lo examina (para calcular los efectos de una colisión, por ejemplo), pero debe llamarse al destructor en algún momento para liberar los recursos asociados. Necesitamos una lista de asteroides que podrían estar vivos y una forma de sujetarlos por un tiempo. Eso es justo lo que hace weak_ptr. Listado 2.80: Esquema de funcionamiento del propietario de los asteroides. Usa shared_ptr para representar propiedad. 1 2 3 4 5 6 7

vector va(100); for (int i=0; iPrivate_Method(); pimpl_->private_var_

= 3;

}

La semántica de copia y de asignación no corresponde propiamente al patrón Pimpl, pero la implementación más sencilla correspondería a igualar los tiempos de vida del handle y de la implementación: Listado 2.85: Ejemplo del patrón Pimpl (constructor de copia y operador de asignación). 1 2 3 4 5 6 7 8 9 10 11

MyClass::MyClass( const MyClass &rhs ) : pimpl_(new MyClassImp(*rhs.pimpl_)) { } MyClass& MyClass::operator=(const MyClass& rhs ) { delete pimpl_; pimpl_ = new MyClassImp(*rhs.pimpl_); return *this; }

Sin embargo esto puede implicar hacer muchas operaciones con el heap incluso en casos en los que no se hace nada con los objetos. Una optimización sencilla consiste en retrasar la construcción del objeto implementación hasta el momento en que se vaya a acceder. Un buen compromiso entre automatización de la gestión de memoria y flexibilidad en la implementación de este patrón es la plantilla auto_ptr (o unique_ptr para C++11) de la biblioteca estándar de C++. La implementación del patrón Pimpl puede simplificarse aún más como recomienda Herb Sutter16 :

16 Por ejemplo, effectively.htm.

en

http://www.gotw.ca/publications/using_auto_ptr_

2.4. Patrones de diseño avanzados

[91]

Listado 2.86: Ejemplo mejorado del patrón Pimpl (archivo de cabecera). 1 2 3 4 5 6 7 8

class C { public: C(); /*...*/ private: class CImpl; auto_ptr pimpl_; };

La diferencia clave es la declaración ✄ del puntero a la implementación como un auto_ptr en la línea ✂7 ✁. La declaración anticipada de la clase implementación se ha metido también en la parte privada del handle para mejorar la ocultación. Listado 2.87: Ejemplo mejorado del patrón Pimpl (archivo de implementación). 1 class C::CImpl { /*...*/ }; 2 3 C::C() : pimpl_( new CImpl ) { }

Ahora no es necesario incluir un destructor explícitamente porque el destructor por defecto llamará a los destructores de los miembros, en particular de pimpl_. Y el destructor de un auto_ptr llama automáticamente al operador delete con el puntero interno. Consideraciones Este patrón puede reducir drásticamente los tiempos de compilación cuando la cantidad de código es abundante. TrollTech utiliza extensivamente una variante de este patrón (d-pointer) en su biblioteca Qt. La indirección adicional implica una pequeña pérdida de rendimiento.

2.4.4. Command El patrón command (se traduciría como orden en castellano) se utiliza frecuentemente en interfaces gráficas para el manejo de las órdenes del usuario. Consiste en encapsular las peticiones en objetos que permiten desacoplar la emisión de la orden de la recepción, tanto desde el punto de vista lógico como temporal. Problema Existe un gran número de situaciones en las que la sincronía inherente a la invocación directa a métodos resulta poco conveniente:

[92]

CAPÍTULO 2. C++ AVANZADO La invocación directa solamente involucra a emisor y receptor de la orden, por lo que resulta complicado trazar la actividad del sistema en otros componentes (barras de progreso, capacidad de deshacer las órdenes ejecutadas, ayuda contextual, etc.). En algunas ocasiones es necesario un modelo de ejecución transaccional, o con limitaciones de orden. Así, por ejemplo si se ejecuta una acción también deben ejecutarse todas las acciones relacionadas. Y si no se ejecuta una acción deben deshacerse todas las relacionadas. Las acciones sobre un mundo virtual (e.g. un MMORPG) deben garantizar la ejecución en orden causal para todos los jugadores (la causa precede al efecto). En ocasiones conviene grabar y reproducir una secuencia de órdenes (e.g para la implementación de macros o simplemente para la prueba del juego). Muchas acciones conllevan la interacción con el usuario en forma de wizards o cuadros de diálogo para configurar la acción. El patrón command permite que el objeto orden sea creado en el momento de mostrar el wizard, que el usuario configure el objeto mediante la interacción con el wizard, y finalmente, al cerrar el wizard se desencadena el proceso de emisión del mensaje. De esta forma la orden no necesita nada de código de interfaz de usuario. La mayoría de los juegos actuales son programas multi-hilo. Las órdenes pueden ser generadas desde multitud de hilos, y el procesamiento de éstas puede corresponder a otro conjunto de hilos diferente. El patrón command proporciona un método sencillo para desacoplar productores y consumidores de órdenes. En los juegos en red necesitamos ejecutar órdenes en todos los ordenadores participantes. El patrón command facilita la serialización de las órdenes sin más que serializar los objetos que las representan. Muchos juegos añaden algún tipo de consola para interactuar directamente con el motor empleando un intérprete de órdenes. El patrón command permite sintetizar órdenes en el juego como si se hubieran producido en el propio juego, lo que facilita enormemente la prueba y depuración.

Solución La figura 2.13 muestra un diagrama de clases con las entidades involucradas. El cliente es el que crea los objeto command concretos y los asocia con el receptor de la acción. Posteriormente, y de forma totalmente desacoplada, un invocador llamará al método execute() de cada objeto orden creado. Los objetos command concretos implementan el método execute(), normalmente delegando total o parcialmente sobre el receptor de la acción.

Figura 2.14: Las acciones de los personajes de un juego son perfectas para el patrón command.

2.4. Patrones de diseño avanzados

[93]

Figura 2.13: Estructura del patrón command.

Un ejemplo de aplicación en un videojuego podría ser el que se muestra en la figura 2.15.

Figura 2.15: Ejemplo de aplicación del patrón command.

El interfaz de usuario crea las órdenes a realizar por el personaje o los personajes que están siendo controlados, así como la asociación con su personaje. Estas acciones se van procesando por el motor del juego, posiblemente en paralelo. Implementación En términos generales el patrón command permite descargar más o menos inteligencia sobre el objeto ConcreteCommand. Se juega entre los dos posibles extremos. El objeto ConcreteCommand no realiza ninguna función por sí mismo, sino que delega todas las acciones en el objeto Receiver. A este tipo de órdenes se les llama forwarding commands. El objeto ConcreteCommand implementa absolutamente todo, sin delegar nada en absoluto al objeto Receiver.

[94]

CAPÍTULO 2. C++ AVANZADO

Entre estos dos extremos se encuentran las órdenes que realizan algunas funciones pero delegan otras en el receptor. En general a todo este tipo de órdenes se les denomina active commands. Desde el punto de vista de la implementación hay poco que podamos añadir a una orden activa. Tienen código de aplicación específico que hay que añadir en el método execute(). Sin embargo, los forwarding commands actúan en cierta forma como si se tratara de punteros a función. El Invoker invoca el método execute() del objeto orden y éste a su vez ejecuta un método del objeto Receiver al que está asociado. En [6] se describe una técnica interesante para este fin, los generalized functors o adaptadores polimórficos para objetos función. Se trata de una plantilla que encapsula cualquier objeto, cualquier método de ese objeto, y cualquier conjunto de argumentos para dicho método. Su ejecución se traduce en la invocación del método sobre el objeto con los argumentos almacenados. Este tipo de functors permiten reducir sensiblemente el trabajo que implicaría una jerarquía de órdenes concretas. Boost implementa una técnica similar en la plantilla function, que ha sido incorporada al nuevo estándar de C++ (en la cabecera functional). Por ejemplo: Listado 2.88: Ejemplo de uso de generalized functors. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

#include using namespace std; int f1(const char* s) { return 0; } struct f2 { int operator() (const char* s) { return 0; } }; struct A { int fa(const char* s) { return 0; } }; int main() { function f; f = f1; f("test1"); f = f2(); f("test2"); A a; auto f3 = bind1st(mem_fun(&A::fa), &a); f = f3; f("test3"); }

La plantilla function se instancia simplemente indicando la signatura de las llamadas que encapsula. A partir de ahí se puede asignar cualquier tipo de objeto que cumpla la signatura, incluyendo funciones normales, métodos o functors de la STL, functors implementados a mano, etc.

2.4. Patrones de diseño avanzados

[95]

Consideraciones El patrón command desacopla el objeto que invoca la operación del objeto que sabe cómo se realiza. Al contrario que la invocación directa, las órdenes son objetos normales. Pueden ser manipulados y extendidos como cualquier otro objeto. Las órdenes pueden ser agregadas utilizando el patrón composite. Las órdenes pueden incluir transacciones para garantizar la consistencia sin ningún tipo de precaución adicional por parte del cliente. Es el objeto Invoker el que debe reintentar la ejecución de órdenes que han abortado por un interbloqueo. Si las órdenes a realizar consisten en invocar directamente un método o una función se puede utilizar la técnica de generalized functors para reducir el código necesario sin necesidad de implementar una jerarquía de órdenes.

2.4.5. Curiously recurring template pattern Este patrón fue inicialmente descrito y bautizado por James O. Coplien en [11]. Se trata de un patrón que ya se utilizaba años antes, desde los primeros tiempos de las plantillas de C++. Problema El patrón CRT pretende extraer funcionalidad común a varias clases, pero que requieren especialización parcial para cada una de ellas. Solución La solución pasa por una interesante recurrencia. Listado 2.89: Estructura básica del patrón CRT. 1 template class Base; 2 3 class Derived: public Base { 4 // ... 5 };

La clase derivada hereda de una plantilla instanciada para ella misma. La clase base cuenta en su implementación con un tipo que deriva de ella misma. Por tanto la propia clase base puede llamar a funciones especializadas en la clase derivada.

[96]

CAPÍTULO 2. C++ AVANZADO

Implementación Se han propuesto multitud de casos donde puede aplicarse este patrón. Nosotros destacaremos en primer lugar su uso para implementar visitantes alternativos a los ya vistos en el módulo 1.

Figura 2.16: Diagrama de clases del patrón Visitor

Recordaremos brevemente la estructura del patrón visitante tal y como se contó en el módulo 1. Examinando la figura 2.16 podemos ver que: La clase base Visitor (y por tanto todas sus clases derivadas) es tremendamente dependiente de la jerarquía de objetos visitables de la izquierda. Si se implementa un nuevo tipo de elemento ElementC (una nueva subclase de Element) tendremos que añadir un nuevo método visitElementB() en la clase Visitor y con ello tendremos que reescribir todos y cada uno de las subclases de Visitor. Cada clase visitable tiene un método específico de visita. La jerarquía de elementos visitables no puede ser una estructura arbitraria, debe estar compuesta por subclases de la clase Element e implementar el método accept(). Si se requiere cambiar la estrategia de visita. Por ejemplo, unificar el método de visita de dos tipos de elementos, es preciso cambiar la jerarquía de objetos visitables. El orden de visita de los elementos agregados está marcado por la implementación concreta de las funciones accept() o visitX(). O bien se introduce el orden de recorrido en los métodos accept() de forma que no es fácil cambiarlo, o bien se programa a medida en los métodos visitX() concretos. No es fácil definir un orden de recorrido de elementos (en orden, en preorden, en postorden) común para todos las subclases de Visitor. En general, se considera que el patrón visitor introduce un excesivo acoplamiento en el código y resulta tremendamente invasivo. Sin embargo, el patrón CRT permite aliviar gran parte de los problemas.

2.4. Patrones de diseño avanzados

[97]

La jerarquía de visitables implementa el método accept() exclusivamente para que puedan elegir el método visit() correcto de la clase derivada de Visitor. Por eso se le llama también despachado doble. El despachado de la función virtual accept() selecciona la subclase de Element concreta y a su vez ese elemento concreto desencadena el despachado de visitX() que selecciona la subclase de Visitor concreta. El segundo despachado es esencial para cualquier recorrido. Sin embargo el primer despachado no siempre es necesario si conocemos de alguna manera el tipo a visitar. Por ejemplo, en el ejemplo del patrón visitor mostrado en el módulo 1 el tipo de objetos es completamente fijo. Sabemos que hay un objeto Scene que contiene un número variable de objetos ObjectScene. Otra forma de realizar este primer despachado podría ser utilizando RTTI u otro mecanismo de introspección. En este caso en que no sea necesario el primer despachado virtual se puede lograr de una manera mucho más eficiente sin ni siquiera usar funciones virtuales, gracias al patrón CRT. Por ejemplo, el mismo ejemplo del módulo 1 quedaría así: Listado 2.90: Visitante genérico usando el patrón CRT. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

struct ObjectScene { string name; Point position; int weight; }; struct Scene { template friend class Visitor; string name; vector objects; }; template class Visitor { public: void traverseObject(ObjectScene* o) { getDerived().visitObject(o); } void traverseScene(Scene* s) { getDerived().visitScene(s); for (auto o : s->objects) traverseObject(o); } void visitObject(ObjectScene* o) {} void visitScene(Scene* s) {} private: Derived& getDerived() { return *static_cast(this); } }; class NameVisitor : public Visitor { vector _names; public: void visitObject(ObjectScene* o) { _names.push_back(o->name); } void visitScene(Scene* s) { cout & o2) 15 { 16 17 }

return !(o1 == o2);

Y con ello podemos definir todos los operadores de golpe sin más que definir operator /proc/sys/kernel/perf_event_paranoid"

Ahora ya como usuarios normales podemos perfilar cualquier ejecutable, e incluso procesos en ejecución. Tal vez la primera tarea que se debe realizar para perfilar con perf es obtener la lista de eventos que puede contabilizar. Esta lista es dependiente de la arquitectura del procesador y de las opciones de compilación del kernel. $ perf list List of pre-defined events (to be used in -e): cpu-cycles OR cycles stalled-cycles-frontend OR idle-cycles-frontend stalled-cycles-backend OR idle-cycles-backend instructions cache-references cache-misses branch-instructions OR branches branch-misses bus-cycles cpu-clock task-clock page-faults OR faults minor-faults major-faults context-switches OR cs cpu-migrations OR migrations alignment-faults emulation-faults L1-dcache-loads L1-dcache-load-misses L1-dcache-stores L1-dcache-store-misses L1-dcache-prefetches

[Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware

event] event] event] event] event] event] event] event] event]

[Software [Software [Software [Software [Software [Software [Software [Software [Software

event] event] event] event] event] event] event] event] event]

[Hardware [Hardware [Hardware [Hardware [Hardware

cache cache cache cache cache

event] event] event] event] event]

[176]

L1-dcache-prefetch-misses L1-icache-loads L1-icache-load-misses L1-icache-prefetches L1-icache-prefetch-misses LLC-loads LLC-load-misses LLC-stores LLC-store-misses LLC-prefetches LLC-prefetch-misses dTLB-loads dTLB-load-misses dTLB-stores dTLB-store-misses dTLB-prefetches dTLB-prefetch-misses iTLB-loads iTLB-load-misses branch-loads branch-load-misses node-loads node-load-misses node-stores node-store-misses node-prefetches node-prefetch-misses rNNN (...) mem:[:access] i915:i915_gem_object_create i915:i915_gem_object_bind i915:i915_gem_object_unbind ... sched:sched_wakeup sched:sched_wakeup_new sched:sched_switch ...

CAPÍTULO 4. OPTIMIZACIÓN

[Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware [Hardware

cache cache cache cache cache cache cache cache cache cache cache cache cache cache cache cache cache cache cache cache cache cache cache cache cache cache cache

event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event] event]

[Raw hardware event descriptor] [Hardware breakpoint] [Tracepoint event] [Tracepoint event] [Tracepoint event] [Tracepoint event] [Tracepoint event] [Tracepoint event]

En la lista de eventos podemos apreciar seis tipos diferentes. Software event. Son simples contadores del kernel. Entre otros permite contar cambios de contexto o fallos de página. Hardware event. Se refiere a los contadores incluidos en las PMU (Performance Monitoring Units) de los procesadores modernos. Permite contar ciclos, intrucciones ejecutadas, fallos de caché. Algunos de estos contadores se ofrecen de forma unificada como contadores de 64 bits, de tal forma que oculta los detalles de la PMU subyacente. Pero en general su número y tipo dependerá del modelo de rocesador donde se ejecuta. Hardware cache event. Dentro del subsistema de memoria las PMU modernas2 permiten extraer estadísticas detalladas de las 2 Los eventos de las PMU se documentan en los manuales de los fabricantes. Por ejemplo, los contadores de la arquitectura Intel 64 e IA32 se documentan en el apéndice A de [17] disponible en http://www.intel.com/Assets/PDF/manual/253669.pdf y los de los procesadores AMD64 en [5] disponible en http://support.amd.com/us/ Processor_TechDocs/31116.pdf

4.1. Perfilado de programas

[177] memorias caché de primer nivel de último nivel o del TLB. Nuevamente se trata de contadores que dependen fuertemente del modelo de procesador sobre el que se ejecuta. Hardware breakpoint. Los puntos de ruptura hardware permiten detener la ejecución del programa cuando el procesador intenta leer, escribir o ejecutar el contenido de una determinada posición de memoria. Esto nos permite monitorizar detalladamente objetos de interés, o trazar la ejecución de instrucciones concretas. Tracepoint event. En este caso se trata de trazas registradas con la infraestructura ftrace de Linux. Se trata de una infraestructura extremadamente flexible para trazar todo tipo de eventos en el kernel o en cualquier módulo del kernel. Esto incluye eventos de la GPU, de los sistemas de archivos o del propio scheduler. Raw hardware event. En el caso de que perf no incluya todavía un nombre simbólico para un contador concreto de una PMU actual se puede emplear el código hexadecimal correspondiente, de acuerdo al manual del fabricante.

4.1.2. Obteniendo ayuda La primera suborden de perf que debe dominarse es help, que se emplea para obtener ayuda. La ejecución de perf help sin más nos muestra todas las órdenes disponibles. Las más utilizadas son perf stat, perf record, perf report y perf annotate. Cada una de estas órdenes tienen ayuda específica que puede obtenerse con perf help suborden.

4.1.3. Estadísticas y registro de eventos La operación más sencilla que se puede hacer con perf es contar eventos. Eso puede realizarse con la suborden perf stat: $ perf stat glxgears Performance counter stats for ’glxgears’: 80,416861 task-clock 171 context-switches 71 CPU-migrations 10732 page-faults 109061681 cycles [86,41 %] 75057377 stalled-cycles-frontend [85,21 %] 58498153 stalled-cycles-backend [62,34 %] 68356682 instructions 14463080 branches [86,78 %] 391522 branch-misses [80,19 %]

# # # # #

0,069 0,002 0,001 0,133 1,356

CPUs utilized M/sec M/sec M/sec GHz

#

68,82 % frontend cycles idle

#

53,64 % backend

cycles idle

# #

0,63 insns per cycle 1,10 stalled cycles per insn [80,66 %] # 179,851 M/sec #

2,71 % of all branches

[178]

CAPÍTULO 4. OPTIMIZACIÓN

1,158777481 seconds time elapsed

Basta indicar el ejecutable a continuación de perf stat. Por defecto muestra un conjunto de métricas comunes, que incluye eventos hardware (como los ciclos o las instrucciones), eventos software (como los cambios de contexto), y métricas derivadas a la derecha (como el número de instrucciones por ciclo). Puede utilizarse perf para medir un tipo de eventos concreto empleando la opción -e: $ perf stat -e cycles,instructions precompute_landscape Performance counter stats for ’precompute_landscape’: 4473759 cycles 3847463 instructions

# #

0,000 GHz 0,86 insns per cycle

0,004595748 seconds time elapsed

Y podemos dividir entre los eventos que ocurren en espacio de usuario y los que ocurren en espacio del kernel. $ perf stat -e cycles:u,cycles:k precompute_landscape Performance counter stats for ’precompute_landscape’: 1827737 cycles:u 2612202 cycles:k

# #

0,000 GHz 0,000 GHz

0,005022949 seconds time elapsed

Todos los eventos hardware aceptan los modificadores u para filtrar solo los que ocurren en espacio de usuario, k para filtrar los que ocurren en espacio del kernel y uk para contabilizar ambos de forma explícita. Hay otros modificadores disponibles, incluso alguno dependiente del procesador en el que se ejecuta.

4.1.4. Multiplexación y escalado Las PMU tienen dos tipos de contadores: los contadores fijos, que cuentan un único tipo de evento, y los contadores genéricos, que pueden configurarse para contar cualquier evento hardware. Cuando el usuario solicita más eventos de los que físicamente se pueden contar con los contadores implementados el sistema de perfilado multiplexa los contadores disponibles. Esto hace que parte del tiempo se estén contando unos eventos y parte del tiempo se están contando otros eventos distintos. Posteriormente el propio sistema escala los valores calculados en proporción al tiempo que se ha contado el evento respecto al tiempo total. Es muy fácil de ver el efecto con un ejemplo. El computador sobre el que se escriben estas líneas dispone de un procesador Intel Core i5. Estos procesadores tienen 4 contadores genéricos3 . 3 Lo

más normal es disponer de dos o cuatro contadores genéricos y otros tantos es-

4.1. Perfilado de programas

[179] Vamos a ver qué pasa cuando se piden 4 eventos idénticos: $ perf stat -e cycles,cycles,cycles,cycles render_frame Performance counter stats for ’render_frame’: 803261796 803261796 803261796 803261799

cycles cycles cycles cycles

# # # #

0,000 0,000 0,000 0,000

GHz GHz GHz GHz

0,306640126 seconds time elapsed

Puede verse que la precisión es absoluta, los cuatro contadores han contado prácticamente la misma cantidad de ciclos. En cambio, veamos qué pasa cuando se solicitan 5 eventos idénticos: $ perf stat -e cycles,cycles,cycles,cycles,cycles render_frame Performance counter stats for ’render_frame’: 801863997 801685466 792515645 792876560 793921257

cycles cycles cycles cycles cycles

# # # # #

0,000 0,000 0,000 0,000 0,000

GHz GHz GHz GHz GHz

[79,06 %] [80,14 %] [80,37 %] [80,37 %] [80,08 %]

0,306024538 seconds time elapsed

Los valores son significativamente diferentes, pero los porcentajes entre corchetes nos previenen de que se ha realizado un escalado. Por ejemplo, el primer contador ha estado contabilizando ciclos durante el 79,06 % del tiempo. El valor obtenido en el contador se ha escalado dividiendo por 0,7906 para obtener el valor mostrado. En este caso los contadores nos dan una aproximación, no un valor completamente fiable. Nos vale para evaluar mejoras en porcentajes significativos, pero no mejoras de un 1 %, porque como vemos el escalado ya introduce un error de esa magnitud. Además en algunas mediciones el resultado dependerá del momento concreto en que se evalúen o de la carga del sistema en el momento de la medida. Para suavizar todos estos efectos estadísticos se puede ejecutar varias veces empleando la opción -r. $ perf stat -r 10 -e cycles,cycles,cycles,cycles,cycles render_frame Performance counter stats for ’render_frame’’ (10 runs): 803926738 804290331 802303057 797518018 799832288

cycles cycles cycles cycles cycles

# # # # #

0,000 0,000 0,000 0,000 0,000

GHz GHz GHz GHz GHz

( ( ( ( (

+++++-

0,310143008 seconds time elapsed ( +-

0,15 % 0,14 % 0,17 % 0,11 % 0,19 %

) ) ) ) )

[79,42 %] [79,66 %] [80,21 %] [80,59 %] [80,15 %]

0,39 % )

Entre paréntesis se muestra la variación entre ejecuciones. pecíficos. Realiza la misma prueba en tu ordenador para comprobar cuántos contadores genéricos tiene.

[180]

CAPÍTULO 4. OPTIMIZACIÓN

4.1.5. Métricas por hilo, por proceso o por CPU Es posible contabilizar los eventos solo en un hilo, o en todos los hilos de un proceso, o en todos los procesos de una CPU, o de un conjunto de ellas. Por defecto perf contabiliza eventos del hilo principal incluyendo todos los subprocesos, creados con fork(), o hilos, creados con pthread_create(), lanzados durante la ejecución. Este comportamiento se implementa con un mecanismo de herencia de contadores que puede desactivarse con la opción -i de perf stat. Alternativamente se puede recolectar datos de un conjunto de procesadores en lugar de un proceso concreto. Este modo se activa con la opción -a y opcionalmente complementado con la opción -C. Al utilizar la opción -a se activa la recolección de datos por CPU, pero por defecto se agregan todos los contadores de todas las CPU (recolección de datos a nivel de sistema). Con la opción -C podemos seleccionar la CPU o conjunto de CPUs de los que se recaban estadísticas. Por ejemplo, para recolectar el número de fallos de página en espacio de usuario de las CPUs 0 y 2 durante 5 segundos: $ perf stat -a -e faults -C 0,2 sleep 5 Performance counter stats for ’sleep 5’: 233 faults 5,001227158 seconds time elapsed

Nótese que utilizamos la orden sleep para no consumir ciclos y de esta forma no influir en la medida.

4.1.6. Muestreo de eventos Además de contar eventos, perf puede realizar un muestreo similar a otros profilers. En este caso perf record recolecta datos en un archivo llamado perf.data que posteriormente puede analizarse con perf report o perf annotate. El periodo de muestreo se especifica en número de eventos. Si el evento que se utiliza para el muestreo es cycles (es así por defecto) entonces el periodo tiene relación directa con el tiempo, pero en el caso general no tiene por qué. Incluso en el caso por defecto la relación con el tiempo no es lineal, en caso de que el procesador tenga activos modos de escalado de frecuencia. Por defecto perf record registra 1000 muestras por segundo y ajusta dinámicamente el periodo para que mantenga esta tasa. El usuario puede establecer una frecuencia de muestreo utilizando la opción -F o puede establecer un periodo fijo con la opción -c. A diferencia de otros profilers, perf record puede recoger estadísticas a nivel del sistema completo o de un conjunto de CPUs concreto empleando las opciones -a y -C que ya hemos visto al explicar perf stat.

4.1. Perfilado de programas

[181] Es especialmente interesante el muestreo de la traza de llamada empleando la opción -g, aunque para que esta característica muestre resultados fiables es necesario mantener el convenio de marcos de llamada y no compilar con la opción -fomit-frame-pointer. Para mostrar los resultados almacenados en perf.data puede emplearse perf report. Por ejemplo, a continuación recolectaremos datos de la actividad del sistema durante 5 segundos y mostraremos el resultado del perfilado. $ perf record -a sleep 10 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.426 MB perf.data (~18612 samples) ] $ perf report

Figura 4.1: Interfaz textual de perf report.

El muestreo permite analizar qué funciones se llevan la mayor parte del tiempo de ejecución y, en caso de muestrear también la traza de llamada permite identificar de forma rápida los cuellos de botella. No se trata de encontrar la función que más tiempo se lleva, sino de identificar funciones que merezca la pena optimizar. No tiene sentido optimizar una función que se lleva el 0,01 % del tiempo de ejecución, porque simplemente no se notaría.

[182]

CAPÍTULO 4. OPTIMIZACIÓN

Una vez identificada la función o las funciones susceptibles de mejora podemos analizarlas en mayor detalle, incluso a nivel del código ensamblador empleando perf annotate símbolo. También desde la interfaz de texto es posible examinar el código anotado seleccionando ✄ el símbolo y pulsando la tecla ✂ a ✁.

Para poder utilizar las características de anotación del código de los perfiladores es necesario compilar el programa con información de depuración.

Para ilustrar la mecánica veremos un caso real. Ingo Molnar, uno de los principales desarrolladores de la infraestructura de perfilado de Linux, tiene multitud de mensajes en diversos foros sobre optimizaciones concretas que fueron primero identificadas mediante el uso de perf. Uno de ellos4 describe una optimización significativa de git, el sistema de control de versiones. En primer lugar realiza una fase de análisis de una operación concreta que revela un dato intranquilizador. Al utilizar la operación de compactación git gc descubre un número elevado de ciclos de estancamiento (stalled cycles5 ): $ perf record -e stalled-cycles -F 10000 ./git gc $ perf report --stdio # Events: 26K stalled-cycles # # Overhead Command Shared Object # ........ .......... ..................... # 26.07 % git git 10.22 % git libz.so.1.2.5 7.08 % git libz.so.1.2.5 6.63 % git git 5.37 % git [kernel.kallsyms] 4.03 % git git 3.09 % git libc-2.13.90.so 2.81 % git libc-2.13.90.so

Symbol ....................... [.] [.] [.] [.] [k] [.] [.] [.]

lookup_object 0xc43a inflate find_pack_entry_one do_raw_spin_lock lookup_blob __strlen_sse42 __memcpy_ssse3_back

Ingo descubre que la función find_pack_entry_one() se lleva un porcentaje significativo de los ciclos de estancamiento. Por tanto examina el contenido de esa función con perf annotate. Para poder extraer todo el beneficio de esta orden es interesante compilar el programa con información de depuración. $ perf annotate find_pack_entry_one Percent | Source code & Disassembly of git --------------------------------------------: 4 http://thread.gmane.org/gmane.comp.version-control.git/172286 5 En las versiones actuales de perf habría que usar stalled-cycles-frontend en lugar de stalled-cycles pero mantenemos el texto del caso de uso original para no confundir al lector.

4.1. Perfilado de programas

[183]

... 0.90 0.45 2.86 53.34 14.37 5.78 1.52

: : : : : : : :

4b9264: 4b9266: 4b926a: 4b926d: 4b926f: 4b9272: 4b9276:

int cmp = hashcmp(index + mi * stride, sha1); 89 ee mov %ebp, %esi 41 0f af f2 imul %r10d, %esi 4c 01 de add %r11, %rsi f3 a6 repz cmpsb %es:( %rdi), %ds:( %rsi) 0f 92 c0 setb %al 41 0f 97 c4 seta %r12b 41 28 c4 sub %al, %r12b

La mayoría de la sobrecarga está en la función hashcmp() que usa memcmp(), pero esta última se expande como instrucciones ensamblador por el propio compilador. Ingo Molnar estudia el caso concreto. La función hashcmp() compara hashes, y por eso se utiliza memcmp(), pero si no coinciden el primer byte diferirá en el 99 % de los casos. Por tanto modifica el programa para escribir la comparación manualmente, evitando entrar en la comparación para la mayor parte de los casos. El resultado es realmente sorprendente. Antes de la optimización obtuvo estos números: $ perf stat --sync --repeat 10 ./git gc Performance counter stats for ’./git gc’ (10 runs): 2771.119892 task-clock 0.16 % ) 1,813 context-switches 3.06 % ) 167 CPU-migrations 2.92 % ) 39,210 page-faults 0.26 % ) 8,828,405,654 cycles 0.13 % ) 2,102,083,909 stalled-cycles 0.52 % ) 8,821,931,740 instructions

#

0.863 CPUs utilized

( +-

#

0.001 M/sec

( +-

#

0.000 M/sec

( +-

#

0.014 M/sec

( +-

#

3.186 GHz

( +-

1,750,408,175 branches 0.04 % ) 74,612,120 branch-misses 0.07 % )

#

3.211098537

# # #

#

seconds time elapsed

23.81 % of all cycles are idle

( +-

1.00 insns per cycle 0.24 stalled cycles per insn ( +0.04 % ) 631.661 M/sec ( +4.26 % of all branches ( +-

( +-

1.52 % )

La opción -sync hace que se ejecute una llamada sync() (vuelca los buffers pendientes de escritura de los sistemas de archivos) antes de cada ejecución para reducir el ruido en el tiempo transcurrido. Después de la optimización el resultado es: $ perf stat --sync --repeat 10 ./git gc Performance counter stats for ’./git gc’ (10 runs): 2349.498022 task-clock # +- 0.15 % ) 1,842 context-switches # +- 2.50 % )

0.807 CPUs utilized

(

0.001 M/sec

(

[184]

CAPÍTULO 4. OPTIMIZACIÓN

164 CPU-migrations +- 3.67 % ) 39,350 page-faults +- 0.06 % ) 7,484,317,230 cycles +- 0.15 % ) 1,577,673,341 stalled-cycles +- 0.67 % ) 11,067,826,786 instructions 2,489,157,909 branches +- 0.02 % ) 59,384,019 branch-misses +- 0.22 % ) 2.910829134

#

0.000 M/sec

(

#

0.017 M/sec

(

#

3.185 GHz

(

#

21.08 % of all cycles are idle

(

# #

1.48 insns per cycle 0.14 stalled cycles per insn ( +- 0.02 % ) # 1059.442 M/sec ( #

2.39 % of all branches

seconds time elapsed

( +-

(

1.39 % )

La misma operación se aceleró en un 18 %. Se han eliminado el 33 % de los ciclos de estancamiento y la mayoría de ellos se han traducido en ahorro efectivo de ciclos totales y con ello en mejoras de velocidad. Este ejemplo deja claro que las instrucciones ensamblador que emite el compilador para optimizar memcmp() no son óptimas para comparaciones pequeñas. La instrucción repz cmpsb requiere un tiempo de setup considerable durante el cual la CPU no hace nada más. Otro efecto interesante que observa Ingo Molnar sobre esta optimización es que también mejora la predcción de saltos. Midiendo el evento branch-misses obtiene los siguientes resultados: Antes Después

branch-misses 74,612,120 59,384,019

% del total 4.26 % ( ± 0.07 % ) 2.39 % ( ± 0.22 % )

Tabla 4.1: Mejora en predicción de saltos.

Por alguna razón el bucle abierto es más sencillo de predecir por parte de la CPU por lo que produce menos errores de predicción. No obstante es importante entender que estas optimizaciones corresponden a problemas en otros puntos (compilador que genera código subóptimo, y arquitectura que privilegia un estilo frente a otro). Por tanto se trata de optimizaciones con fecha de caducidad. Cuando se utilice una versión más reciente de GCC u otro compilador más agresivo en las optimizaciones esta optimización no tendrá sentido. Un caso célebre similar fue la optimización del recorrido de listas en el kernel Linux6 . Las listas son estructuras muy poco adecuadas para la memoria caché. Al no tener los elementos contiguos generan innumerables fallos de caché. Mientras se produce un fallo de caché el procesador está parcialmente parado puesto que necesita el dato de la memoria para operar. Por esta razón en Linux se empleó una optimización denominada prefetching. Antes de operar con un elemento se accede al siguiente. De esta forma mientras está operando con el 6 https://lwn.net/Articles/444336/

4.1. Perfilado de programas

[185] elemento es posible ir transfiriendo los datos de la memoria a la caché. Desgraciadamente los procesadores modernos incorporan sus propias unidades de prefetch que realizan un trabajo mucho mejor que el manual, puesto que no interfiere con el TLB. El propio Ingo Molnar reporta que esta optimización estaba realmente causando un impacto de 0,5 %. La lección que debemos aprender es que nunca se debe optimizar sin medir, que las optimizaciones dependen del entorno de ejecución, y que si el entorno de ejecución varía las optimizaciones deben reevaluarse.

4.1.7. Otras opciones de perf Puede resultar útil también la posibilidad de contabilizar procesos o hilos que ya están en ejecución (opciones -p y -t respectivamente). A pesar de usar cualquiera de estas opciones se puede especificar una orden para limitar el tiempo de medición. En caso contrario mediría el proceso o hilo hasta su terminación. También es posible generar gráficos de líneas temporales. Para ello es necesario utilizar la suborden perf timechart record para registrar los eventos de forma similar a como se hacía con perf record y posteriormente emplear perf timechart para generar el archivo output.svg. Este archivo puede editarse o convertirse a PDF con inkscape. El problema es que el tiempo de captura debe ser reducido o de lo contrario el archivo SVG se volverá inmanejable. No obstante es muy útil para detectar problemas de bloqueo excesivo. Por ejemplo, los datos de la figura 4.2 se grabaron con perf timechart record -a sleep 1. Por último conviene citar la suborden perf top que permite monitorizar en tiempo real el sistema para analizar quién está generando más eventos.

4.1.8. Otros perfiladores La tabla 4.2 muestra una colección de herramientas de perfilado disponibles en entornos GNU y GNU/Linux. La mayoría de los perfiladores requieren compilar el programa de una manera especial. El más extendido y portable es GNU Profiler, incluido dentro de binutils, que es directamente soportado por el compilador de GNU. Si se compilan y se montan los programas con la opción -pg el programa quedará instrumentado para perfilado.

[186]

CAPÍTULO 4. OPTIMIZACIÓN

Paquete Valgrind Callgrind7

Herramienta kCacheGrind

Google Performance Tools8

google-pprof

GNU Profiler9

gprof

nVidia Visual Profiler AMD APP Profiler

nvvp sprofile

Descripción Excelentes capacidades de representación gráfica. Permite perfilado de CPU y de memoria dinámica. Permite salida en formato callgrind para poder analizar con kCacheGrind. Es una herramienta estándar pero ha ido perdiendo su utilidad conforme fueron surgiendo los perfiladores basados en PMU. Es específico para GPUs nVidia. Es específico para GPUs AMD/ATI Radeon.

Tabla 4.2: Herramientas de perfilado en GNU/Linux.

Todas las ejecuciones del programa generan un archivo gmon.out con la información recolectada, que puede examinarse con gprof. GNU Profiler utiliza muestreo estadístico sin ayuda de PMU. Esto lo hace muy portable pero notablemente impreciso. Google Performance Tools aporta un conjunto de bibliotecas para perfilado de memoria dinámica o del procesador con apoyo de PMU. Por ejemplo, el perfilado de programas puede realizarse con la biblioteca libprofiler.so. Esta biblioteca puede ser cargada utilizando la variable de entorno LD_PRELOAD y activada mediante la definición de la variable de entorno CPUPROFILE. Por ejemplo: $ LD_PRELOAD=/usr/lib/libprofiler.so.0 CPUPROFILE=prof.data \ ./light-model-test

Esto genera el archivo prof.data con los datos de perfilado, que luego pueden examinarse con google-pprof. Entre otras capacidades permite representación gráfica del grafo de llamadas o compatibilidad con el formato de kcachegrind. Una característica interesante de Google Performance Tools es la capacidad de realizar el perfilado solo para una sección concreta del código. Para ello, en lugar de definir la variable CPUPROFILE basta incluir en el código llamadas a las funciones ProfilerStart() y ProfilerStop(). Para un desarrollador de videojuegos es destacable la aparición de perfiladores específicos para GPUs. Las propias GPUs tienen una PMU (Performance Monitoring Unit) que permite recabar información de contadores específicos. De momento en el mundo del software libre han emergido nVidia Visual Profiler, AMD APP Profiler y extensiones de Intel a perf para utilizar los contadores de la GPU (perf gpu). Probablemente en un futuro cercano veremos estas extensiones incorporadas en la distribución oficial de linux-tools.

GPU Profilers De momento solo nVidia proporciona un profiler con capacidades gráficas sobre GNU/Linux. AMD APP Profiler funciona en GNU/Linux pero no con interfaz gráfica.

4.2. Optimizaciones del compilador

[187]

Figura 4.2: Ejemplo de perf timechart.

4.2.

Optimizaciones del compilador

Los compiladores modernos implementan un enorme abanico de optimizaciones. Con frecuencia son tan eficientes como el código ensamblador manualmente programado. Por esta razón es cada vez más raro encontrar fragmentos de código ensamblador en programas bien optimizados. El lenguaje C++, y su ancestro C son considerados como lenguajes de programación de sistemas. Esto se debe a que permiten acceso a características de muy bajo nivel, hasta el punto de que algunos autores lo consideran un ensamblador portable. Los punteros no dejan de ser una forma de expresar direccionamiento indirecto, así como el operador de indexación no deja de ser una expresión de los modos de direccionamiento relativo. C fue diseñado con el objetivo inicial de programar un sistema operativo. Por este motivo, desde las primeras versiones incorpora carac-

[188]

CAPÍTULO 4. OPTIMIZACIÓN

Figura 4.3: Aspecto de la interfaz de nVidia Visual Profiler.

terísticas de muy bajo nivel que permite dirigir al compilador para generar código más eficiente. Variables registro, funciones en línea, paso por referencia, o plantillas son algunas de las características que nos permiten indicar al compilador cuándo debe esforzarse en buscar la opción más rápida. Sin embargo, la mayoría de las construcciones son simplemente indicaciones o sugerencias, que el compilador puede ignorar libremente si encuentra una solución mejor. En la actualidad tenemos compiladores libres maduros con capacidades comparables a los mejores compiladores comerciales, por lo que frecuentemente las indicaciones del programador son ignoradas.

4.2.1. Variables registro Los más viejos del lugar recordarán un modificador opcional para las variables denominado register. Este modificador indica al compilador que se trata de una variable especialmente crítica, por lo que sugiere almacenarla en un registro del procesador. Era frecuente ver código como éste: Listado 4.1: Utilización arcaica de register para sumar los 1000 primeros números naturales. 1 register unsigned i, sum = 0; 2 for (i=1; iaddRigidBody(fallRigidBody);

2 http://code.google.com/p/bullet/

6.5. Introducción a Bullet

[233]

35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 }

Altura: Altura: Altura: Altura: Altura: Altura: Altura: Altura: Altura: Altura: Altura: Altura: Altura: Altura: Altura: ...

49.9972 49.9917 49.9833 49.9722 49.9583 49.9417 49.9222 49.9 49.875 49.8472 49.8167 49.7833 49.7472 49.7083 49.6667

Figura 6.21: Salida por pantalla de la ejecución del Hola Mundo en Bullet.

Figura 6.22: Representación de los valores obtenidos en el Hola Mundo.

// Bucle principal de la simulacion ---------------------------for (int i=0 ; istepSimulation(1/60.f,10); btTransform trans; fallRigidBody->getMotionState()->getWorldTransform(trans); std::cout removeRigidBody(gRigidBody); delete gRigidBody->getMotionState(); delete gRigidBody; delete fallShape; delete groundShape; delete dynamicsWorld; delete solver; delete collisionConfiguration; delete dispatcher; delete broadphase; return 0;

El ejemplo anterior podría compilarse con un sencillo makefile como se muestra a continuación: Listado 6.2: Makefile para hello world. 1 2 3 4 5 6 7

CXXFLAGS := ‘pkg-config --cflags bullet‘ LDLIBS := ‘pkg-config --libs-only-l bullet‘ all: HelloWorldBullet clean: rm HelloWorldBullet *~

Una vez compilado el programa de ejemplo, al ejecutarlo obtenemos un resultado puramente textual, como el mostrado en la Figura 6.21. Como hemos comentado anteriormente, los Bullet está diseñado para permitir un uso modular. En este primer ejemplo no se ha hecho uso de ninguna biblioteca para la representación gráfica de la escena. Si representamos los 300 valores de la altura de la esfera, obtenemos una gráfica como muestra la Figura 6.22. Como vemos, cuando la esfera (de 1 metro de radio) llega a un metro del suelo (medido desde el centro), rebota levemente y a partir del frame 230 aproximadamente se estabiliza. ✄ El primer include definido en la línea ✂2 ✁del programa anterior se encarga de incluir todos los archivos de cabecera necesarios para crear una aplicación que haga uso del módulo de dinámicas (cuerpo rígido, restricciones, etc...). Necesitaremos instanciar un mundo sobre el que realizar la simulación. En nuestro caso crearemos un mundo discreto, que es el adecuado salvo que tengamos objetos de movimiento muy rápido sobre el que tengamos que hacer una detección de su movimiento (en cuyo caso podríamos utilizar la clase aún experimental btContinuousDynamicsWorld).

[234]

CAPÍTULO 6. SIMULACIÓN FÍSICA

FAE FACA B ACA AD

A

B AEA AD

A

D

AB ACCEE A A

A

D

AB ACCEE A A

A

D

Figura 6.23: Aplicación del Teorema de los Ejes Separados y uso con cajas AABB. a) La proyección de las formas convexas de los objetos A y B están separadas en el eje X, pero no en el eje Y. Como podemos encontrar un eje sobre el que ambas proyecciones no intersecan, podemos asegurar que las formas no colisionan. b) El mismo principio aplicados sobre cajas AABB definidas en objetos cóncavos, que no intersecan. c) La proyección de las cajas AABB se solapa en todos los ejes. Hay un posible caso de colisión entre formas.

Creación del mundo Como vimos en la sección 6.2.2, los motores de simulación física utilizan varias capas para detectar las colisiones entre los objetos del mundo. Bullet permite utilizar algoritmos en una primera etapa (broadphase) que utilizan las cajas límite de los objetos del mundo para obtener una lista de pares de cajas que pueden estar en colisión. Esta lista es una lista exhaustiva de todas las cajas límite que intersecan en alguno de los ejes (aunque, en etapas posteriores lleguen a descartarse porque en realidad no colisionan). Muchos sistemas de simulación física se basan en el Teorema de los Ejes Separados. Este teorema dice que si existe un eje sobre el que la proyección de dos formas convexas no se solapan, entonces podemos asegurar que las dos formas no colisionan. Si no existe dicho eje y las dos formas son convexas, podemos asegurar que las formas colisionan. Si las formas son cóncavas, podría ocurrir que no colisionaran (dependiendo de la suerte que tengamos con la forma de los objetos). Este teorema se puede visualizar fácilmente en 2 dimensiones, como se muestra en la Figura 6.23.a. El mismo teorema puede aplicarse para cajas AABB. Además, el hecho de que las cajas AABB estén perfectamente alineadas con los ejes del sistema de referencia, hace que el cálculo de la proyección de estas cajas sea muy rápida (simplemente podemos utilizar las coordenadas mínimas y máximas que definen las cajas). La Figura 6.23 representa la aplicación de este teorema sobre cajas AABB. En el caso c) de dicha figura puede comprobarse que la proyección de las cajas se solapa en todos los ejes, por lo que tendríamos un caso potencial de colisión. En realidad, como vemos en la figura las formas que contienen dichas cajas AABB no colisionan, pero este caso deberá ser resuelto por algoritmos de detección de colisión de menor granularidad. ✄ En la línea ✂5 ✁creamos un objeto que implementa un algoritmo de optimización en una primera etapa broadphase. En posteriores etapas

6.5. Introducción a Bullet

[235] Bullet calculará las colisiones exactas. Existen dos algoritmos básicos que implementa Bullet para mejorar al aproximación a ciegas de complejidad O(n2 ) que comprobaría toda la lista de pares. Estos algoritmos añaden nuevas parejas de cajas que en realidad no colisionan, aunque en general mejoran el tiempo de ejecución. Árbol AABB Dinámico. Este algoritmo está implementado en la clase btDbvtBroadphase. Se construye un árbol AABB de propósito general que se utiliza tanto en la primera etapa de optimización broadphase como en la detección de colisiones entre softbodies. Este tipo de arbol se adapta automáticamente a las dimensiones del mundo, y la inserción y eliminación de objetos es más rápido que en SAP. Barrido y Poda (SAP). La implementación de Sweep and Prune de Bullet requiere que el tamaño del mundo sea conocido de previamente. Este método es el que tiene mejor comportamiento en mundos dinámicos donde la mayoría de los objetos tienen poco movimiento. Se implementa en el conjunto de clases AxisSweep (con versiones de diverso nivel de precisión).

Figura 6.24: El objeto solver se encargará de resolver la interacción entre objetos.

Reutiliza!! Es buena práctica reutilizar formas de colisión. Si varios objetos de la escena pueden compartir la misma forma de colisión (por ejemplo, todos los enemigos pueden gestionarse con una misma esfera de un determinado radio), es buena práctica compartir esa forma de colisión entre todos ellos.

Tras esta primera poda, hemos eliminado gran ✄ cantidad de objetos que no colisionan. A continuación, en las líneas ✂6-8 ✁se crea un objeto de configuración de la colisión, que nos permitirá adaptar los parámetros de los algoritmos utilizados en posteriores fases para comprobar la colisión. El btCollisionDispatcher es una clase que permite añadir funciones de callback para ciertos tipos de eventos (como por ejemplo, cuando los objetos se encuentren cerca). ✄ El objeto solver (línea ✂9 ✁) se encarga de que los objetos interactúen adecuadamente, teniendo en cuenta la gravedad, las fuerzas, colisiones y restricciones. En este ejemplo se ha utilizado la versión secuencial (que implementa el método de Gauss Seidel proyectado (PGS), para resolver problemas lineales), aunque existen versiones que hacen uso de paralelismo empleando hilos. ✄ En la línea ✂10 ✁ se instancia el mundo. Este objeto nos permitirá añadir los objetos del mundo, aplicar gravedad, y avanzar el paso de ✄ la simulación. En concreto, en la línea ✂12 ✁ se establece una de las propiedades del mundo, la gravedad, asignando un valor de 10m/s en el eje Y, por lo que se aplicará sobre ese eje la fuerza de gravedad. Al finalizar, Bullet requiere que el usuario libere la memoria ✄ que ha utilizado explícitamente. De esta forma, a partir de la línea ✂42 ✁se eliminan todos los elementos que han sido creados a lo largo de la simulación. Hasta aquí hemos definido lo que puede ser el esqueleto básico de una aplicación mínima de Bullet. Vamos a definir a continuación los objetos que forman nuestra escena y el bucle de simulación.

[236]

CAPÍTULO 6. SIMULACIÓN FÍSICA

Formas de Colisión Como hemos comentado al inicio de la sección, crearemos un objeto plano que servirá como suelo sobre el que dejaremos caer una esfera. Cada uno de estos cuerpos necesita una forma de colisión, que internamente únicamente se utiliza para calcular la colisión (no tiene propiedades de masa, inercia, etc...). Las formas de colisión no tienen una posición en el mundo; se adjuntan a los cuerpos rígidos. La elección de la forma de colisión adecuada, además de mejorar el rendimiento de la simulación, ayuda a conseguir una simulación de calidad. Bullet permite el uso de primitivas (que implementan algoritmos de detección de colisiones muy optimizados) o mallas poligonales. Las primitivas soportadas por Bullet son: btSphereShape. Esfera; la primitiva más simple y rápida. btBoxShape. La caja puede tener cualquier relación de aspecto. btCylinderShape. Cilindro con cualquier relación de aspecto. btCapsuleShape. Cápsula con cualquier relación de aspecto. btConeShape. Los conos se definen con el vértice en el (0,0,0). btMultiSphereShape. Forma convexa especial definida como combinación de esferas. btCompoundShape. No es una primitiva básica en sí, sino que permite combinar formas de cualquier tipo (tanto primitivas como formas de colisión de tipo malla que veremos a continuación). Permite obtener formas compuestas, como la que se estudió en la Figura 6.14. Las formas de colisión de tipo malla soportadas son: btConvexHull. Este es el tipo de forma de tipo malla más rápido. Se define como una nube de vértices que forman la forma convexa más pequeña posible. El número de vértices debe ser pequeño para que la forma funcione adecuadamente. El número de vértices puede reducirse empleando la utilidad proporcionada por la clase btShapeHull. Existe una versión similar a este tipo llamado btConvexTriangleMeshShape, que está formado por caras triangulares, aunque es deseable utilizar btConvexHull porque es mucho más eficiente. btBvhTriangleMeshShape. Malla triangular estática. Puede tener un número considerable de polígonos, ya que utiliza una jerarquía interna para calcular la colisión. Como la construcción de esta estructura de datos puede llevar tiempo, se recomienda serializar el árbol para cargarlo rápidamente. Bullet incorpora utilidades para la serialización y carga del árbol BVH.

6.5. Introducción a Bullet

[237] btHeightfieldTerrainShape. Malla poligonal estática optimizada descrita por un mapa de alturas. btStaticPlaneShape. Plano infinito estático. Se especifica mediante un vector de dirección y una distancia respecto del origen del sistema de coordenadas.

Algunos consejos sobre el uso de formas de colisión en Bullet: Trata de utilizar las formas de colisión más eficientes: esferas, cajas, cilindros y ConvexHull. Los objetos dinámicos deben tener una forma cerrada y definida por un volumen finito. Algunas formas de colisión como los planos o las triangleMesh no tienen un volumen finito, por lo que únicamente pueden ser usados como cuerpos estáticos. Reutiliza siempre que sea posible las formas de colisión.

✄ En la línea ✂16-17 ✁ creamos una forma de colisión de tipo plano, pasando como parámetro el vector normal del plano (vector unitario en Y), y una distancia respecto del origen. Así, el plano de colisión queda definido por la ecuación y = 1. De igual modo, la forma de colisión del cuerpo que✄ dejaremos caer sobre el suelo será una esfera de radio 1 metro (línea ✂18 ✁). Una vez definidas las formas de colisión, las posicionaremos asociándolas a instancias de cuerpos rígidos. En la siguiente subsección añadiremos los cuerpos rígidos al mundo. Cuerpos Rígidos Para añadir cuerpos rígidos, necesitamos primero definir el concepto de MotionState en Bullet. Un MotionState es una abstracción proporcionada por Bullet para actualizar la posición de los objetos que serán dibujados en el game loop. Empleando MotionStates, Bullet se encargará de actualizar los objetos que serán representados por el motor gráfico. En la siguiente sección estudiaremos cómo trabajar con MotionStates en Ogre. MotionState propio Para implementar nuestro propio MotionState basta con heredar de btMotionState y sobreescribir los métodos getWorldTransform y setWorldTransform.

Gracias al uso de MotionStates, únicamente se actualiza la posición de los objetos que se han movido. Bullet se encarga además de la interpolación de movimientos, aislando al programador de esta tarea. Cuando se consulte la posición de un objeto, por defecto se devolverá la correspondiente al último paso de simulación calculado. Sin embargo, cada vez que el motor gráfico necesite redibujar la escena, Bullet se encargará de devolver la transformación interpolada. Los MotionStates deben utilizarse en dos situaciones:

[238]

CAPÍTULO 6. SIMULACIÓN FÍSICA

1. Cuando se crea un cuerpo. Bullet determina la posición inicial del cuerpo en el momento de su creación, y requiere una llamada al MotionState. 2. Cuando se quiera actualizar la posición del objeto. Bullet proporciona un MotionState por defecto que✄ podemos utilizar para instanciar cuerpos rígidos. Así, en la línea ✂21 ✁ se utiliza el MotionState por defecto especificando como rotación la identidad, y trasladando el origen -1 unidad en Y 3 . ✄ En las líneas ✂22-23 ✁ se emplea la estructura btRigidBodyConstructionInfo para establecer la información para crear un cuerpo rígido.

Los componentes de la estructura btRigidBodyConstructionInfo se copian a la información del cuerpo cuando se llama al constructor. Si queremos crear un grupo de objetos con las mismas propiedades, puede crearse una única estructura de este tipo y pasarla al constructor de todos los cuerpos.

El primer parámetro es la masa del objeto. Estableciendo una masa igual a cero (primer parámetro), se crea un objeto estático (equivale a establecer una masa infinita, de modo que el objeto no se puede mover). El último parámetro es la inercia del suelo (que se establece igualmente a 0, por ser un objeto estático). ✄ En la línea ✂24 ✁ creamos el objeto rígido a partir de la información almacenada en la estructura anterior, y lo añadimos al mundo en la ✄ línea ✂25 ✁. La ✄creación de la esfera sigue un patrón de código similar. En la línea ✂27 ✁se crea el MotionState para ✄ el objeto que dejaremos caer, situado a 50 metros del suelo (línea ✂28 ✁). ✄ En las líneas ✂29-31 ✁ se establecen las propieades del cuerpo; una masa de 1Kg y se llama a un método de btCollisionShape que nos calcula la inercia de una esfera a partir de su masa. Bucle Principal ✄ Para finalizar, el bucle principal se ejecuta en las líneas ✂36-41 ✁. El bucle se ejecuta 300 veces, llamando al paso de simulación con un intervalo de 60hz. En cada paso de la simulación se imprime la altura de la esfera sobre el suelo. Como puede verse, la posición y la orientación del objeto dinámico se encapsulan en un objeto de tipo btTransform. Como se comentó anteriormente, esta información puede obtenerse a partir del MotionS3 Esta traslación se realiza a modo de ejemplo para compensar la traslación de 1 unidad cuando se creó la forma de colisión del plano. El resultado sería el mismo si en ambos parámetros se hubiera puesto 0.

6.5. Introducción a Bullet

Tiempos! Cuidado, ya que las funciones de cálculo de tiempo habitualmente devuelven los resultados en milisegundos. Bullet trabaja en segundos, por lo que ésta es una fuente habitual de errores.

[239] tate asociado al btRigidBody a través de la estructura de inicialización btRigidBodyConstructInfo. ✄ El método para avanzar un paso en la simulación (línea ✂38 ✁) requiere dos parámetros. El primero describe la cantidad de tiempo que queremos avanzar la simulación. Bullet tiene un reloj interno que permite mantener constante esta actualización, de forma que sea independiente de la tasa de frames de la aplicación. El segundo parámetro es el número de subpasos que debe realizar bullet cada vez que se llama stepSimulation. Los tiempos se miden en segundos. El primer parámetro debe ser siempre menor que el número de subpasos multiplicado por el tiempo fijo de cada paso tStep < maxSubStep× tF ixedStep .

Supongamos que queremos un tiempo fijo de simulación en cada paso de 60hz. En el mejor de los casos, nuestro videojuego tendrá una tasa de 120fps (120hz), y en el peor de los casos de 12fps. Así, tStep en el primer caso será 1/120 = 0,0083, y en el segundo tStep = 1/12 = 0,083. Por su parte, el tiempo del paso fijo para la simulación sería 1/60 = 0,017. Para que la expresión anterior se cumpla, en el primer caso el número de subpasos basta con 1 0,0083 < 1 × 0,017. En el peor de los casos, necesitaremos que el número de pasos sea al menos de 5 para que se cumpla la expresión 0,083 < 5 × 0,017. Con estas condiciones tendríamos que establecer el número de subpasos a 5 para no perder tiempo de simulación

No olvides... Cuando cambies el valor de los tiempos de simulación, recuerda calcular el número de subpasos de simulación para que la ecuación siga siendo correcta.

Decrementando el tamaño de cada paso de simulación se está aumentado la resolución de la simulación física. De este modo, si en el juego hay objetos que “atraviesan” objetos (como paredes), es posible decrementar el fixedTimeStep para aumentar la resolución. Obviamente, cuando se aumenta la resolución al doble, se necesitará aumentar el número de maxSubSteps al doble, lo que requerirá aproximadamente el doble de tiempo de CPU para el mismo tiempo de simulación física. Cuando se especifica un valor de maxSubSteps > 1, Bullet interpolará el movimiento (y evitará al programador tener que realizar los cálculos). Si maxSubSteps == 1, no realizará interpolación.

[240]

6.6.

CAPÍTULO 6. SIMULACIÓN FÍSICA

Integración manual en Ogre

Como se ha estudiado en la sección anterior, los MotionStates se definen en Bullet para abstraer la representación de los rigidBody en el motor de dibujado. A continuación definiremos manualmente una clase MyMotionState que se encargará de la actualización de las entidades en Ogre. La implementación de un MotionState propio debe heredar de la clase btMotionState de bullet, y sobreescribir los métodos getWorldTransform y setWorldTransform (por lo que se definen como virtuales). Ambos métodos toman como parámetro un objeto de la clase btTransform, que se utiliza para la representación interna de transformaciones de cuerpo rígido. El siguiente listado muestra la declaración de la clase, que tiene dos variables miembro; el nodo asociado a ese MotionState (que tendremos que actualizar en setWorldTransform), y la ✄propia transformación que devolveremos en getWorldTransform (línea ✂7 ✁). Listado 6.3: MyMotionState.h 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

#include #include class MyMotionState : public btMotionState { protected: Ogre::SceneNode* _visibleobj; btTransform _pos; public: MyMotionState(const btTransform &initialpos, Ogre::SceneNode* node); virtual ~MyMotionState(); void setNode(Ogre::SceneNode* node); virtual void getWorldTransform(btTransform &worldTr) const; virtual void setWorldTransform(const btTransform &worldTr); };

La definición de la clase es directa. El siguiente listado muestra los métodos más importantes en su implementación (el destructor no tiene que eliminar el nodo; se encargará Ogre al liberar los recursos). ✄ En las líneas ✂15-19 ✁se define el método principal, que actualiza la posición y rotación del SceneNode en Ogre. Dado que Bullet y Ogre definen clases distintas para trabajar con Vectores y Cuaternios, es necesario obtener la rotación y posición del objeto por separado y asignarlo ✄ al✄nodo mediante las llamadas a setOrientation y setPosition (líneas ✂17 ✁ y ✂19 ✁). ✄ La llamada a setWorldTransform puede retornar en la línea ✂15 ✁ si no se ha establecido nodo en el constructor. Se habilita un método específico para establecer el nodo más adelante. Esto es interesante si se quieren añadir objetos a la simulación que no tengan representación gráfica.

btTransform Las transformaciones de cuerpo rígido están formadas únicamente por traslaciones y rotaciones (sin escalado). Así, esta clase utiliza internamente un btVector3 para la traslación y una matriz 3x3 para almacenar la rotación.

6.6. Integración manual en Ogre

[241]

Listado 6.4: MyMotionState.cpp 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#include "MyMotionState.h" MyMotionState::MyMotionState(const btTransform &initialpos, Ogre::SceneNode *node) { _visibleobj = node; _pos = initialpos; } void MyMotionState::setNode(Ogre::SceneNode *node) { _visibleobj = node; } void MyMotionState::getWorldTransform (btTransform &worldTr) const { worldTr = _pos; } void MyMotionState::setWorldTransform(const btTransform &worldTr){ if(NULL == _visibleobj) return; // Si no hay nodo, return btQuaternion rot = worldTr.getRotation(); _visibleobj->setOrientation(rot.w(), rot.x(), rot.y(), rot.z()); btVector3 pos = worldTr.getOrigin(); _visibleobj->setPosition(pos.x(), pos.y(), pos.z()); }

Una vez creada la clase que utilizaremos para definir el MotionState, la utilizaremos en el “Hola Mundo” construido en la sección anterior para representar la simulación con el plano y la esfera. El resultado que tendremos se muestra en la Figura 6.25. Para la construcción del ejemplo emplearemos como esqueleto base el FrameListener del Módulo 2 del curso. Figura 6.25: Fragmento del resultado de integración del “Hola Mundo” de Bullet en Ogre, empleando la clase de MyMotionState definida anteriormente.

Listado 6.5: MyFrameListener.cpp 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

#include "MyFrameListener.h" #include "MyMotionState.h" MyFrameListener::MyFrameListener(RenderWindow* win, Camera* cam, OverlayManager *om, SceneManager *sm) { // .... Omitida parte de la inicializacion _broadphase = new btDbvtBroadphase(); _collisionConf = new btDefaultCollisionConfiguration(); _dispatcher = new btCollisionDispatcher(_collisionConf); _solver = new btSequentialImpulseConstraintSolver; _world = new btDiscreteDynamicsWorld(_dispatcher,_broadphase, _solver,_collisionConf); _world->setGravity(btVector3(0,-10,0)); CreateInitialWorld(); } MyFrameListener::~MyFrameListener() { _world->removeRigidBody(_fallRigidBody); delete _fallRigidBody->getMotionState(); delete _fallRigidBody; // ... Omitida la eliminacion de los objetos } void MyFrameListener::CreateInitialWorld() { // Creacion de la entidad y del SceneNode ----------------------Plane plane1(Vector3::Vector3(0,1,0), 0); MeshManager::getSingleton().createPlane("p1", ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME, plane1, 200, 200, 1, 1, true, 1, 20, 20, Vector3::UNIT_Z); SceneNode* node = _sceneManager->createSceneNode("ground"); Entity* groundEnt = _sceneManager->createEntity("planeEnt","p1");

[242]

groundEnt->setMaterialName("Ground"); node->attachObject(groundEnt); _sceneManager->getRootSceneNode()->addChild(node);

32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86

CAPÍTULO 6. SIMULACIÓN FÍSICA

// Creamos las formas de colision ------------------------------_groundShape = new btStaticPlaneShape(btVector3(0,1,0),1); _fallShape = new btSphereShape(1); // Creamos el plano --------------------------------------------MyMotionState* groundMotionState = new MyMotionState( btTransform(btQuaternion(0,0,0,1),btVector3(0,-1,0)), node); btRigidBody::btRigidBodyConstructionInfo groundRigidBodyCI (0,groundMotionState,_groundShape,btVector3(0,0,0)); _groundRigidBody = new btRigidBody(groundRigidBodyCI); _world->addRigidBody(_groundRigidBody); // Creamos la esfera -------------------------------------------Entity *entity2= _sceneManager->createEntity("ball","ball.mesh"); SceneNode *node2= _sceneManager->getRootSceneNode()-> createChildSceneNode(); node2->attachObject(entity2); MyMotionState* fallMotionState = new MyMotionState( btTransform(btQuaternion(0,0,0,1),btVector3(0,50,0)), node2); btScalar mass = 1; btVector3 fallInertia(0,0,0); _fallShape->calculateLocalInertia(mass,fallInertia); btRigidBody::btRigidBodyConstructionInfo fallRigidBodyCI( mass,fallMotionState,_fallShape,fallInertia); _fallRigidBody = new btRigidBody(fallRigidBodyCI); _world->addRigidBody(_fallRigidBody); } bool MyFrameListener::frameStarted(const Ogre::FrameEvent& evt) { Real deltaT = evt.timeSinceLastFrame; int fps = 1.0 / deltaT; _world->stepSimulation(deltaT, 5);

// Actualizar fisica

_keyboard->capture(); if (_keyboard->isKeyDown(OIS::KC_ESCAPE)) return false; btVector3 impulse; if (_keyboard->isKeyDown(OIS::KC_I)) impulse=btVector3(0,0,-.1); if (_keyboard->isKeyDown(OIS::KC_J)) impulse=btVector3(-.1,0,0); if (_keyboard->isKeyDown(OIS::KC_K)) impulse=btVector3(0,0,.1); if (_keyboard->isKeyDown(OIS::KC_L)) impulse=btVector3(.1,0,0); _fallRigidBody->applyCentralImpulse(impulse); // Omitida parte del codigo fuente (manejo del raton, etc...) return true; } bool MyFrameListener::frameEnded(const Ogre::FrameEvent& evt) { Real deltaT = evt.timeSinceLastFrame; _world->stepSimulation(deltaT, 5); // Actualizar fisica return true; }

En la implementación del FrameListener es necesario mantener como variables miembro el conjunto de objetos necesarios en la ✄ simulación de Bullet. Así, la implementación del constructor (líneas ✂4-15 ✁define los ✄objetos necesarios para crear el mundo de simulación de Bullet (línea ✂11-12✄✁). Estos objetos serán liberados en el destructor de la clase (ver líneas ✂17-22 ✁). De igual modo, los dos cuerpos rígidos que intervie-

6.7. Hola Mundo en OgreBullet

Variables miembro Mantener los objetos como variables miembro de la clase no deja de ser una mala decisión de diseño. En la sección 6.7 veremos cómo se gestionan listas dinámicas con los objetos y las formas de colisión.

Actualización del mundo En el ejemplo anterior, se actualiza el paso de simulación igualmente en el método frameEnded. Bullet se encarga de interpolar las posiciones de dibujado de los objetos. Si se elimina la llamada a stepSimulation, el resultado de la simulación es mucho más brusco.

[243]

nen en la simulación y sus formas asociadas son variables miembro de la clase. ✄ El método CreateInitialWorld (definido en las líneas ✂24-60 ✁) se realiza como último paso en el constructor. En este método se añaden a la escena de Ogre y al mundo de Bullet los elementos que intervendrán en la simulación (en este caso la esfera y el plano). La creación de ✄ las entidades y los nodos para el plano y la esfera ✄ (líneas ✂26-34 ✁ y ✂49-51 ✁ respectivamente) ya han sido estudiadas en el Módulo✄ 2 del curso. La creación de las formas para el plano y la esfera (líneas ✂37-38 ✁) fueron descritas en el código de la sección ✄ anterior. Cabe destacar que la malla exportada en ball.mesh (línea ✂49 ✁) debe tener un radio de 1 unidad, para que la forma de colisión definida en la línea ✄ 38 se ✂ ✁ adapte bien a su representación gráfica. Cada objeto tendrá asociado un MotionState de la clase definida anteriormente, que recibirá la rotación y traslación inicial, y el puntero al nodo que guarda ✄la entidad a representar. En el caso del plano, se ✄ define en las líneas ✂41-42 ✁, y la esfera en ✂52-53 ✁. Por último, tendremos que añadir código específico en los métodos de retrollamada de actualización del frame.✄ En el listado anterior ✄ se muestra el código de frameStarted (líneas ✂62-86 ✁). En la línea ✂66 ✁ se actualiza el paso de simulación de Bullet, empleando el tiempo transcurrido✄desde Además, si el usuario pulsa las ✄ la ✄última✄ actualización. ✄ teclas ✂I ✁, ✂J ✁, ✂K ✁ o ✂L ✁ (líneas ✂71-76 ✁), se aplicará una fuerza sobre la esfera. Veremos más detalles sobre la aplicación de impulsos a los objetos en el ejemplo de la sección 6.8. Para finalizar, se muestran los flags del Makefile necesarios para integrar Bullet en los ejemplos anteriores. Listado 6.6: Fragmento de Makefile 1 # Flags de compilacion ------------------------------------------2 CXXFLAGS := -I $(DIRHEA) -Wall ‘pkg-config --cflags OGRE‘ ‘pkg-

config

--cflags bullet‘

3 4 # Flags del linker ----------------------------------------------5 LDFLAGS := ‘pkg-config --libs-only-L OGRE‘ ‘pkg-config --libs-only-

l

bullet‘

6 LDLIBS := ‘pkg-config --libs-only-l OGRE‘ ‘pkg-config --libs-only-l

bullet‘ -lOIS -lGL -lstdc++

6.7.

Hola Mundo en OgreBullet

El desarrollo de un wrapper completo del motor Bullet puede ser una tarea costosa. Afortunadamente existen algunas alternativas que facilitan la integración del motor en Ogre, como el proyecto OgreBullet. OgreBullet se distribuye bajo una licencia MIT libre, y es multiplataforma. Según el autor, OgreBullet puede ser considerado un wrapper en versión estable. La notificación de bugs, petición de nuevos requisitos

[244]

CAPÍTULO 6. SIMULACIÓN FÍSICA

y ejemplos se mantiene en un apartado específico de los foros de Ogre 4 . Uno de los principales problemas relativos al uso de este wrapper es la falta de documentación, por lo que en algunos casos la única alternativa es la consulta de los archivos de cabecera de la distribución.

OgreBullet puede descargarse de la página de complementos oficial de Ogre en: http://ogreaddons.svn.sourceforge.net/viewvc/ogreaddons/trunk/ogrebullet/?view=tar

En el siguiente ejemplo crearemos una escena donde se añadirán de forma dinámica cuerpos rígidos. Además de un puntero al DynamicsWorld (variable miembro _world), el FrameListener mantiene un ✄ puntero a un objeto _debugDrawer (línea ✂7 ✁), que nos permite representar cierta información visual que facilita el depurado de la aplicación. En este primer ejemplo se activa el dibujado de las formas de ✄ colisión (línea ✂8 ✁), tal y como se muestra en la Figura 6.26. Este objeto permite añadir otros elementos que faciliten la depuración, como líneas, puntos de contacto, cajas AABBs, etc. Los métodos relativos a la representación de texto 3D en modo depuración están previstos pero aún no se encuentran desarrollados. Este objeto de depuración debe ser añadido igualmente al grafo de escena de Ogre ✄ (líneas ✂9-11 ✁del siguiente listado). La definición del mundo en OgreBullet✄ requiere que se especifiquen los límites de simulación. En las líneas ✂14-15 ✁se crea una caja AABB descrita por los vértices de sus esquinas que define el volumen en el que se realizará la simulación física. Este límite, ✄ junto con el vector de gravedad, permitirán crear el mundo (líneas ✂18-19 ✁). Listado 6.7: Constructor 1 MyFrameListener::MyFrameListener(RenderWindow* win, 2 Camera* cam, OverlayManager *om, SceneManager *sm) { 3 _numEntities = 0; // Numero de Formas instanciadas 4 _timeLastObject = 0; // Tiempo desde ultimo objeto anadido 5 6 // Creacion del modulo de debug visual de Bullet --------------7 _debugDrawer = new OgreBulletCollisions::DebugDrawer(); 8 _debugDrawer->setDrawWireframe(true); 9 SceneNode *node = _sceneManager->getRootSceneNode()-> 10 createChildSceneNode("debugNode", Vector3::ZERO); 11 node->attachObject(static_cast(_debugDrawer)); 12 // Creacion del mundo (definicion de los limites y la gravedad) 13 AxisAlignedBox worldBounds = AxisAlignedBox 14 (Vector3(-10000,-10000,-10000), Vector3(10000,10000,10000)); 15 Vector3 gravity = Vector3(0, -9.8, 0); 16 _world = new OgreBulletDynamics::DynamicsWorld(_sceneManager, 17 worldBounds, gravity); 18 _world->setDebugDrawer (_debugDrawer); 19 _world->setShowDebugShapes (true); // Muestra formas debug 20 CreateInitialWorld(); // Inicializa el mundo 21 } 4 Foros

OgreBullet: http://www.ogre3d.org/addonforums/viewforum.php?f=12

Figura 6.26: Salida del primer ejemplo con OgreBullet. El objeto _debugDrawer muestra las formas de colisión asociadas a las entidades de Ogre.

6.7. Hola Mundo en OgreBullet

[245]

El FrameListener mantiene dos colas de doble fin (deque) de punteros a los RigidBody (_bodies) y a las CollisionShape (_shapes), que facilitan la inserción y borrado de elementos de un modo más rápido que los vectores. Así, cuando se añadan objetos de forma dinámica a la escena, será necesario añadirlos a estas estructuras para su posterior liberación en el destructor de la clase. El siguiente listado muestra la implementación del destructor del FrameListener. De igual modo es necesario liberar los recursos asociados al mundo ✄ dinámico y al debugDrawer creado en el constructor (ver líneas ✂16-17 ✁). Listado 6.8: Destructor 1 MyFrameListener::~MyFrameListener() { 2 // Eliminar cuerpos rigidos -----------------------------------3 std::deque ::iterator 4 itBody = _bodies.begin(); 5 while (_bodies.end() != itBody) { 6 delete *itBody; ++itBody; 7 } 8 // Eliminar formas de colision --------------------------------9 std::deque::iterator 10 itShape = _shapes.begin(); 11 while (_shapes.end() != itShape) { 12 delete *itShape; ++itShape; 13 } 14 _bodies.clear(); _shapes.clear(); 15 // Eliminar mundo dinamico y debugDrawer ----------------------16 delete _world->getDebugDrawer(); _world->setDebugDrawer(0); 17 delete _world; 18 }

Para añadir un objeto de simulación de OgreBullet debemos ✄ crear dos elementos básicos; por un lado la CollisionShape (líneas ✂14-16 ✁), y ✄ por otro lado el RigidBody (líneas ✂17-18 ✁). La asociación del nodo de dibujado con el cuerpo rígido se establece en la misma llamada en la que se asocia la forma de colisión al RigidBody. En la clase OgreBulletDynamics::RigidBody existen dos métodos que permiten asociar una forma de colisión a un RigidBody; setShape y setStaticShape. La segunda cuenta con varias versiones; una de ellas no requiere✄ especificar el SceneNode, y se corresponde con la utilizada en la línea ✂21 ✁para añadir la forma de colisión al plano. Añadir a las colas Una vez añadido el objeto, deben añadirse las referencias a la forma de colisión y al cuerpo rígido en las colas de la clase (línea 24).

Listado 6.9: CreateInitialWorld 1 void MyFrameListener::CreateInitialWorld() { 2 // Creacion de la entidad y del SceneNode ----------------------3 Plane plane1(Vector3::Vector3(0,1,0), 0); 4 MeshManager::getSingleton().createPlane("p1", 5 ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME, plane1, 6 200, 200, 1, 1, true, 1, 20, 20, Vector3::UNIT_Z); 7 SceneNode* node= _sceneManager->createSceneNode("ground"); 8 Entity* groundEnt= _sceneManager->createEntity("planeEnt", "p1"); 9 groundEnt->setMaterialName("Ground"); 10 node->attachObject(groundEnt); 11 _sceneManager->getRootSceneNode()->addChild(node); 12 13 // Creamos forma de colision para el plano ----------------------

[246]

14 15 16 17 18 19 20 21 22 23 24 25 }

CAPÍTULO 6. SIMULACIÓN FÍSICA

OgreBulletCollisions::CollisionShape *Shape; Shape = new OgreBulletCollisions::StaticPlaneCollisionShape (Ogre::Vector3(0,1,0), 0); // Vector normal y distancia OgreBulletDynamics::RigidBody *rigidBodyPlane = new OgreBulletDynamics::RigidBody("rigidBodyPlane", _world); // Creamos la forma estatica (forma, Restitucion, Friccion) ---rigidBodyPlane->setStaticShape(Shape, 0.1, 0.8); // Anadimos los objetos Shape y RigidBody ---------------------_shapes.push_back(Shape); _bodies.push_back(rigidBodyPlane);

La actualización del mundo se realiza de forma similar a la estudiada anteriormente. La aplicación de ejemplo ✄ además,✄ permite añadir objetos dinámicos cuando se pulse la tecla ✂B ✁ (línea ✂9 ✁). A continuación veremos el código para añadir cuerpos dinámicos. Listado 6.10: FrameStarted 1 bool MyFrameListener::frameStarted(const Ogre::FrameEvent& evt) { 2 Ogre::Real deltaT = evt.timeSinceLastFrame; 3 _world->stepSimulation(deltaT); // Actualizar simulacion Bullet 4 _timeLastObject -= deltaT; 5 6 _keyboard->capture(); 7 if (_keyboard->isKeyDown(OIS::KC_ESCAPE)) return false; 8 if ((_keyboard->isKeyDown(OIS::KC_B)) && (_timeLastObject getDerivedPosition() 6 + _camera->getDerivedDirection().normalisedCopy() * 10); 7 8 // Creamos la entidad y el nodo de la escena ------------------9 Entity *entity = _sceneManager->createEntity("Box" + 10 StringConverter::toString(_numEntities), "cube.mesh"); 11 entity->setMaterialName("cube"); 12 SceneNode *node = _sceneManager->getRootSceneNode()-> 13 createChildSceneNode(); 14 node->attachObject(entity); 15 16 // Obtenemos la bounding box de la entidad creada -------------17 AxisAlignedBox boundingB = entity->getBoundingBox(); 18 size = boundingB.getSize(); 19 size /= 2.0f; // Tamano en Bullet desde el centro (la mitad)

stepSimulation La llamada a stepSimulation en OgreBullet acepta dos parámetros opcionales, el número de subpasos de simulación (por defecto a 1), y el fixedTimeStep (por defecto 1/60).

6.8. RayQueries

[247]

20 21 22 23 24 25 26 27 28 29 30 31 32 33 }

OgreBulletCollisions::BoxCollisionShape *boxShape = new OgreBulletCollisions::BoxCollisionShape(size); OgreBulletDynamics::RigidBody *rigidBox = new OgreBulletDynamics::RigidBody("rigidBox" + StringConverter::toString(_numEntities), _world); rigidBox->setShape(node, boxShape, /* Restitucion, Friccion, Masa */ 0.6, 0.6, 5.0, /* Pos. y Orient. */ position , Quaternion::IDENTITY); rigidBox->setLinearVelocity( _camera->getDerivedDirection().normalisedCopy() * 7.0); _numEntities++; // Anadimos los objetos a las deques --------------------------_shapes.push_back(boxShape); _bodies.push_back(rigidBox);

En el listado anterior, el nodo asociado a cada caja se añade en ✄ la llamada a setShape (líneas ✂25-27 ✁). Pese a que Bullet soporta multitud de propiedades en la estructura btRigidBodyConstructionInfo, el wrapper se centra exclusivamente en la definición de la masa, y los coeficientes de fricción y restitución. La posición inicial y el cuaternio se indican igualmente en la llamada al método, que nos abstrae de la necesidad de definir el MotionState. Las cajas se añaden a la escena con una velocidad lineal relativa a ✄ la rotación de la cámara (ver líneas ✂28-29 ✁).

6.8.

RayQueries

Al inicio del capítulo estudiamos algunos tipos de preguntas que podían realizarse al motor de simulación física. Uno de ellos eran los RayQueries que permitían obtener las formas de colisión que intersecaban con un determinado rayo. Ogre? Bullet? Recordemos que los objetos de simulación física no son conocidos por Ogre. Aunque en el módulo 2 del curso estudiamos los RayQueries en Ogre, es necesario realizar la pregunta en Bullet para obtener las referencias a los RigidBody.

Utilizaremos esta funcionalidad del SDC para aplicar un determinado impulso al primer objeto que sea tocado por el puntero del ratón. De igual forma, en este ejemplo se añadirán objetos definiendo una forma de colisión convexa. El resultado de la simulación (activando la representación de las formas de colisión) se muestra en la Figura 6.27. La llamada al método AddDynamicObject recibe como parámetro un tipo enumerado, que indica si queremos añadir una oveja o una caja. La forma de colisión de la caja se calcula automáticamente em✄ pleando la clase StaticMeshToShapeConverter (línea ✂17 ✁).

Reutiliza las formas de colisión! Tanto en el ejemplo de la sección anterior como en este código, no se reutilizan las formas de colisión. Queda como ejercicio propuesto para el lector mantener referencias a las formas de colisión (para las ovejas y para las cajas), y comprobar la diferencia de rendimiento en frames por segundo cuando el número de objetos de la escena crece.

[248]

CAPÍTULO 6. SIMULACIÓN FÍSICA

Listado 6.12: AddDynamicObject 1 void MyFrameListener::AddDynamicObject(TEDynamicObject tObject) { 2 // Omitido codigo anterior del metodo --------------------------3 Entity *entity = NULL; 4 switch (tObject) { 5 case sheep: 6 entity = _sceneManager->createEntity("Sheep" + 7 StringConverter::toString(_numEntities), "sheep.mesh"); 8 break; 9 case box: default: 10 // (Omitido) Analogamente se carga el modelo de la caja... 11 } 12 13 SceneNode *node = _sceneManager->getRootSceneNode()-> 14 createChildSceneNode(); 15 node->attachObject(entity); 16 17 OgreBulletCollisions::StaticMeshToShapeConverter * 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 }

trimeshConverter = NULL; OgreBulletCollisions::CollisionShape *bodyShape = NULL; OgreBulletDynamics::RigidBody *rigidBody = NULL; switch (tObject) { case sheep: trimeshConverter = new OgreBulletCollisions::StaticMeshToShapeConverter(entity); bodyShape = trimeshConverter->createConvex(); delete trimeshConverter; break; case box: default: // (Omitido) Crear bodyShape como en el ejemplo anterior... } rigidBody = new OgreBulletDynamics::RigidBody("rigidBody" + StringConverter::toString(_numEntities), _world); // Omitido resto de codigo del metodo ---------------------------

El objeto de la clase StaticMeshToShapeConverter recibe como parámetro una Entity de Ogre en el constructor. Esta entidad puede ser convertida a multitud de formas de colisión. En el momento de la creación, la clase reduce el número de vértices de la forma de colisión. Cuando se pincha con el botón derecho o izquierdo del ratón sobre algún objeto de la simulación, se✄ aplicará un impulso con diferente fuerza (definida en F , ver línea ✂18 ✁ del siguiente código). El método pickBody se encarga de obtener el primer cuerpo que colisiona con el rayo definido por la posición de la cámara y el puntero del ratón. Este método devuelve igualmente en los dos primeros parámetros el punto de colisión en el objeto y el rayo utilizado para construir el RayQuery. El método pickBody primero obtiene el rayo utilizando la funcionalidad de ✄ Ogre, empleando las coordenadas de pantalla normalizadas (líneas ✂20-21 ✁). Hecho esto, se crea una Query que requiere como tercer parámetro la distancia máxima a la que se calculará la colisión,✄ en la dirección del rayo, teniendo en cuenta su posición inicial (línea ✂4 ✁). ✄ Si el rayo colisiona en algún ✄ cuerpo (línea ✂6 ✁), se devuelve el cuerpo y el punto de colisión (líneas ✂7-11 ✁).

Figura 6.27: Resultado de la simulación del ejemplo.

Conversor a Shape Además de la llamada a createConvex, el conversor estudiado en el código anterior puede generar otras formas de colisión con createSphere, createBox, createTrimesh, createCylinder y createConvexDecomposition entre otras.

6.8. RayQueries

[249]

Listado 6.13: RayQuery en Bullet 1 RigidBody* MyFrameListener::pickBody (Vector3 &p, Ray &r, float x,

float y) { 2 r = _camera->getCameraToViewportRay (x, y); 3 CollisionClosestRayResultCallback cQuery = 4 CollisionClosestRayResultCallback (r, _world, 10000); 5 _world->launchRay(cQuery); 6 if (cQuery.doesCollide()) { 7 RigidBody* body = static_cast 8 (cQuery.getCollidedObject()); 9 p = cQuery.getCollisionPoint(); 10 return body; 11 } 12 return NULL; 13 } 14 15 bool MyFrameListener::frameStarted(const Ogre::FrameEvent& evt) { 16 // Omitido codigo anterior del metodo --------------------------17 if (mbleft || mbright) { // Con botones del raton, impulso -----18 float F = 10; if (mbright) F = 100; 19 RigidBody* body; Vector3 p; Ray r; 20 float x = posx/float(_win->getWidth()); // Pos x normalizada 21 float y = posy/float(_win->getHeight()); // Pos y normalizada 22 body = pickBody (p, r, x, y); 23 24 if (body) { 25 if (!body->isStaticObject()) { 26 body->enableActiveState (); 27 Vector3 relPos(p - body->getCenterOfMassPosition()); 28 Vector3 impulse (r.getDirection ()); 29 body->applyImpulse (impulse * F, relPos); 30 } 31 } 32 } 33 // Omitido resto de codigo del metodo --------------------------34 }

Para✄ finalizar, si hubo colisión con algún cuerpo que no sea estático (líneas ✂24-25 ✁), se aplicará un impulso. La llamada a enableActiveState permite activar un cuerpo. Por defecto, Bullet automáticamente desactiva objetos dinámicos cuando la velocidad es menor que un determinado umbral.

Impulso El impulso puedeR definirse R como F dt = (dp/dt)dt, siendo p el momento.

Los cuerpos desactivados en realidad están se encuentran en un estado de dormidos, y no consumen tiempo de ejecución salvo por la etapa de detección de colisión broadphase. Esta etapa automáticamente despierta a los objetos que estuvieran dormidos si se encuentra colisión con otros elementos de la escena. ✄ En las líneas ✂27-29 ✁ se aplica un impulso sobre el objeto en la dirección del rayo que se calculó desde la cámara, con una fuerza proporcional a F . El impulso es una fuerza que actúa en un cuerpo en un determinado intervalo de tiempo. El impulso implica un cambio en el momento, siendo la Fuerza definida como el cambio en el momento. Así, el impulso aplicado sobre un objeto puede ser definido como la integral de la fuerza con respecto del tiempo. El wrapper de OgreBullet permite definir un pequeño subconjunto de propiedades de los RigidBody de las soportadas en Bullet. Algunas de las principales propiedades son la Velocidad Lineal, Impulsos y

[250]

CAPÍTULO 6. SIMULACIÓN FÍSICA

Figura 6.29: Configuración de la malla estática utilizada en el ejemplo. Es importante aplicar la escala y rotación a los objetos antes de su exportación, así como las dimensiones del objeto “ball” para aplicar los mismos límites a la collision shape.

Fuerzas. Si se requieren otras propiedades, será necesario acceder al objeto de la clase btRigidBody (mediante la llamada a getBulletRigidBody) y especificar manualmente las propiedades de simulación.

6.9.

TriangleMeshCollisionShape

En este ejemplo se cargan dos objetos como mallas triangulares estáticas. El resultado de la ejecución puede verse en la Figura 6.28. Al igual que en el ejemplo anterior, se utiliza la funcionalidad proporcionada por el conversor ✄ de mallas, pero generando una TriangleMeshCollisionShape (línea ✂11-12 ✁). Listado 6.14: Static Mesh 1 void MyFrameListener::CreateInitialWorld() { 2 // Creacion del track -----------------------------------------3 Entity *entity = _sceneManager->createEntity("track.mesh"); 4 SceneNode *node = _sceneManager->createSceneNode("track"); 5 node->attachObject(entity); 6 7 _sceneManager->getRootSceneNode()->addChild(node); 8 OgreBulletCollisions::StaticMeshToShapeConverter * 9 10 11 12 13 14 15 16 17 18 19 20 21 }

trimeshConverter = new OgreBulletCollisions::StaticMeshToShapeConverter(entity); OgreBulletCollisions::TriangleMeshCollisionShape *trackTrimesh = trimeshConverter->createTrimesh(); OgreBulletDynamics::RigidBody *rigidTrack = new OgreBulletDynamics::RigidBody("track", _world); rigidTrack->setShape(node, trackTrimesh, 0.8, 0.95, 0, Vector3::ZERO, Quaternion::IDENTITY); delete trimeshConverter; // (Omitido) Creacion del sumidero de forma similar ------------

Figura 6.28: Resultado de la ejecución del ejemplo de carga de mallas triangulares.

6.10. Detección de colisiones

[251] Es importante consultar en la posición de los generadores de objetos en el espacio 3D (ver Figura 6.29), así como las dimensiones de los objetos que van a intervenir en la simulación. Por ejemplo, las esferas se creaban con una forma de colisión de tipo SphereCollisionShape de 0.02 unidades de radio porque su dimensión en el espacio 3D es de 0.04 unidades (ver Figura 6.29). De igual modo, una de las posiciones de generación es Vector3(-0.14, 1.07, -0.07) situada en el interior de una de las cajas.

6.10.

Detección de colisiones

Una de las formas más sencillas de detectar colisiones entre objetos del mundo es iterar sobre los colectores de contactos (contact manifold). Los contact manifold son en realidad caches que contienen los puntos de contacto entre parejas de objetos de colisión. El siguiente listado muestra una forma de iterar sobre los pares de objetos en el mundo dinámico. Listado 6.15: DetectCollisionDrain. 1 void MyFrameListener::DetectCollisionDrain() { 2 btCollisionWorld *bulletWorld=_world->getBulletCollisionWorld(); 3 int numManifolds=bulletWorld->getDispatcher()->getNumManifolds(); 4 5 for (int i=0;igetDispatcher()->getManifoldByIndexInternal(i); 8 btCollisionObject* obA = 9 static_cast(contactManifold->getBody0()); 10 btCollisionObject* obB = 11 static_cast(contactManifold->getBody1()); 12 13 Ogre::SceneNode* drain = _sceneManager->getSceneNode("drain"); 14 15 OgreBulletCollisions::Object *obDrain = 16 _world->findObject(drain); 17 OgreBulletCollisions::Object *obOB_A = _world->findObject(obA); 18 OgreBulletCollisions::Object *obOB_B = _world->findObject(obB); 19 20 if ((obOB_A == obDrain) || (obOB_B == obDrain)) { 21 Ogre::SceneNode* node = NULL; 22 if ((obOB_A != obDrain) && (obOB_A)) { 23 node = obOB_A->getRootNode(); delete obOB_A; 24 } 25 else if ((obOB_B != obDrain) && (obOB_B)) { 26 node = obOB_B->getRootNode(); delete obOB_B; 27 } 28 if (node) { 29 std::cout getName() getRootSceneNode()-> 31 removeAndDestroyChild (node->getName()); 32 } 33 } 34 } 35 }

[252]

CAPÍTULO 6. SIMULACIÓN FÍSICA

Figura 6.30: Ejemplo de detección de colisiones empleando colectores de contactos.

✄ En la línea ✂2 ✁se obtiene el puntero directamente a la clase btCollisionWorld, que se encuentra oculta en la implementación de OgreBullet. Con este puntero se accederá directamente a la funcionalidad de Bullet sin emplear la clase de recubrimieneto de OgreBullet. La clase btCollisionWorld sirve a la vez como interfaz y como contenedor de las funcionalidades relativas a la detección de colisiones. ✄ Mediante la llamada a getDispatcher (línea ✂3 ✁) se obtiene un puntero a la clase btDispather, que se utiliza en la fase de colisión broadphase para la gestión de pares de colisión. Esta clase nos permite obtener el número de✄ colectores que hay activos en cada instante. El bucle de ✄ las líneas ✂5-34 ✁se encarga de iterar sobre los colectores. En la línea ✂6-7 ✁se obtiene un puntero a un objeto de la clase btPersistentManifold. Esta clase es una implementación de una caché persistente mientras los objetos colisionen en la etapa de colisión broadphase.

OgreBullet... El listado anterior muestra además cómo acceder al objeto del mundo de bullet, que permite utilizar gran cantidad de métodos que no están implementados en OgreBullet.

6.11. Restricción de Vehículo

[253]

Los puntos de contacto se crean en la etapa de detección de colisiones fina (narrow phase). La cache de btPersistentManifold puede estar vacía o contener hasta un máximo de 4 puntos de colisión. Los algoritmos de detección de la colisión añaden y eliminan puntos de esta caché empleando ciertas heurísticas que limitan el máximo de puntos a 4. Es posible obtener el número de puntos de contacto asociados a la cache en cada instante mediante el método getNumContacts().

La cache de colisión mantiene punteros a los dos objetos que están colisionando. Estos ✄objetos pueden obtenerse mediante la llamada a métodos get (líneas ✂8-11 ✁). La clase CollisionsWorld de OgreBullet proporciona un método findObject que permite obtener un puntero a objeto ✄ genérico a partir de un SceneNode o un btCollisionObject (ver líneas ✂15-18 ✁). ✄ La última parte del código (líneas ✂20-32 ✁) comprueba si alguno de los dos objetos de la colisión son el sumidero. En ese caso, se obtiene el puntero al otro objeto (que se corresponderá con un objeto de tipo esfera creado dinámicamente), y se elimina de la escena. Así, los objetos en esta segunda versión del ejemplo no llegan a añadirse en la caja de la parte inferior del circuito.

Otros mecanismos de colisión. En la documentación de Bullet se comentan brevemente otros mecanismos que pueden utilizarse para la detección de colisiones, como los objetos de la clase btGhostObject. Los objetos de esta clase pueden tener asociadas llamadas de callback de modo que se invoquen automáticamente cuando los objetos se solapen en la etapa de detección de colisiones mediante el test de cajas AABB.

6.11.

Restricción de Vehículo

En esta sección estudiaremos cómo utilizar un tipo de restricción específica para la definición de vehículos. OgreBullet cuenta con abstracciones de alto nivel que trabajan internamente con llamadas a las clases derivadas btRaycastVehicle, que permiten convertir un cuerpo rígido en un vehículo. A continuación estudiaremos algunos fragmentos de código empleados en el siguiente ejemplo para la construcción del vehículo. Queda como ejercicio propuesto añadir obstáculos y elementos de interacción en la escena empleando mallas triangulares estáticas.

[254]

CAPÍTULO 6. SIMULACIÓN FÍSICA

Figura 6.31: Ejemplo de definición de un vehículo en OgreBullet.

Listado 6.16: Fragmento de MyFrameListener.h 1 2 3 4 5 6 7 8

OgreBulletDynamics::WheeledRigidBody OgreBulletDynamics::VehicleTuning OgreBulletDynamics::VehicleRayCaster OgreBulletDynamics::RaycastVehicle Ogre::Entity *mChassis; Ogre::Entity *mWheels[4]; Ogre::SceneNode *mWheelNodes[4]; float mSteering;

*mCarChassis; *mTuning; *mVehicleRayCaster; *mVehicle;

En el anterior archivo de cabecera se definen ciertas variables miembro de la clase que se utilizarán en la definición del vehículo. mCarChassis es un puntero a una clase que ofrece OgreBullet para la construcción de vehículos con ruedas. La clase VehicleTuning es una clase de cobertura sobre la clase btVehicleTuning de Bullet que permite especificar ciertas propiedades del vehículo (como la compresión, suspensión, deslizamiento, etc). VehicleRayCaster es una clase que ofrece un interfaz entre la simulación del vehículo y el RayCasting (usado para localizar el punto de contacto entre el vehículo y el suelo). La clase RaycastVehicle es una clase de ✄ cobertura sobre la clase base de Bullet btRaycastVehicle. Las líneas ✂5-7 ✁ definen los nodos y entidades necesarias para el chasis✄y las ruedas del vehículo. Finalmente, la varible Steering de la línea ✂8 ✁ define la dirección del vehículo. A continuación estudiaremos la definición del ✄ vehículo en el método CreateInitialWorld del FrameListener. La línea ✂1 ✁ del siguiente listado

6.11. Restricción de Vehículo

[255]

define el vector de altura del chasis (elevación✄ sobre el suelo), y la altura de conexión de las ruedas en él (línea ✂2 ✁) que será utilizado más adelante. En la construcción inicial del vehículo se establece la ✄ dirección del vehículo como 0.0 (línea ✂3 ✁). ✄ La líneas ✂5-9 ✁crean la entidad del chasis y el nodo que la contendrá. ✄ La línea ✂10 ✁utiliza el vector de altura del chasis para posicionar el nodo del chasis. Listado 6.17: Fragmento de CreateInitialWorld (I). 1 2 3 4 5 6

const Ogre::Vector3 chassisShift(0, 1.0, 0); float connectionHeight = 0.7f; mSteering = 0.0; mChassis = _sceneManager->createEntity("chassis", "chassis.mesh"); SceneNode *node = _sceneManager->getRootSceneNode()-> createChildSceneNode ();

7 8 SceneNode *chassisnode = node->createChildSceneNode(); 9 chassisnode->attachObject (mChassis); 10 chassisnode->setPosition (chassisShift);

✄ El chasis tendrá asociada una forma de colisión de tipo caja (línea ✂1 ✁). Esta caja formará ✄ parte de una forma de colisión compuesta, que se define en la línea ✂2 ✁, y a la que se ✄ añade la caja anterior desplazada según el vector chassisShift (línea ✂3 ✁). ✄ al que se asocia En la línea ✂4 ✁se define el cuerpo rígido del vehículo, ✄ ✄ la forma de colisión creada anteriormente (línea ✂6 ✁). En la línea ✂9 ✁se establecen los valores de suspensión ✄ del vehículo, y se evita que el vehículo pueda desactivarse (línea ✂8 ✁), de modo que el objeto no se «dormirá» incluso si se detiene durante un tiempo continuado. Listado 6.18: Fragmento de CreateInitialWorld (II). 1 BoxCollisionShape* chassisShape = new BoxCollisionShape(Ogre::

Vector3(1.f,0.75f,2.1f)); CompoundCollisionShape* compound = new CompoundCollisionShape(); compound->addChildShape(chassisShape, chassisShift); mCarChassis = new WheeledRigidBody("carChassis", _world); Vector3 CarPosition = Vector3(0, 0, -15); mCarChassis->setShape (node, compound, 0.6, 0.6, 800, CarPosition, Quaternion::IDENTITY); 7 mCarChassis->setDamping(0.2, 0.2); 8 mCarChassis->disableDeactivation(); 2 3 4 5 6

En el siguiente fragmento se comienza definiendo algunos paráme✄ tros de tuning del vehículo (línea ✂1 ✁). Estos parámetros son la rigidez, compresión y amortiguación de la suspensión y la fricción de desli✄ zamiento. La línea ✂5 ✁ establece el sistema de coordenadas local del vehículo mediante los índices derecho, superior y adelante. ✄ ✄ Las líneas ✂7 ✁y ✂8 ✁definen los ejes que se utilizarán como dirección del vehículo y en la definición de las ruedas. ✄ El bucle de las líneas ✂10-16 ✁ construye los nodos de las ruedas, cargando 4 instancias de la malla «wheel.mesh».

[256]

CAPÍTULO 6. SIMULACIÓN FÍSICA

El ejemplo desarrollado en esta sección trabaja únicamente con las dos ruedas delanteras (índices 0 y 1) como ruedas motrices. Además, ambas ruedas giran de forma simétrica según la variable de dirección mSteering. Queda propuesto como ejercicio modificar el código de esta sección para que la dirección se pueda realizar igualmente con las ruedas traseras, así como incorporar otras opciones de motricidad (ver Listado de FrameStarted).

Listado 6.19: Fragmento de CreateInitialWorld (III). 1 mTuning = new VehicleTuning(20.2, 4.4, 2.3, 500.0, 10.5); 2 mVehicleRayCaster = new VehicleRayCaster(_world); 3 mVehicle = new RaycastVehicle(mCarChassis, mTuning,

mVehicleRayCaster); 4 5 6 7 8 9 10 11 12 13 14

mVehicle->setCoordinateSystem(0, 1, 2); Ogre::Vector3 wheelDirectionCS0(0,-1,0); Ogre::Vector3 wheelAxleCS(-1,0,0); for (size_t i = 0; i < 4; i++) { mWheels[i] = _sceneManager->createEntity("wheel"+i,"wheel.mesh"); mWheels[i]->setCastShadows(true);

15 16 }

mWheelNodes[i] = _sceneManager->getRootSceneNode()-> createChildSceneNode(); mWheelNodes[i]->attachObject (mWheels[i]);

El siguiente fragmento de listado se repite para cada rueda, calculando el punto de conexión en función del ancho de cada rueda y la altura de conexión. Este punto es pasado al método addWheel, junto con información relativa a ciertas ✄propiedades físicas de cada rueda. La variable isFrontWheel (ver línea ✂3 ✁) indica si la rueda añadida forma parte del conjunto de ruedas delanteras (en este caso, únicamente las dos primeras ruedas tendrán esta variable a true en el momento de creación. Listado 6.20: Fragmento de CreateInitialWorld (IV). 1 Ogre::Vector3 connectionPointCS0 (1-(0.3*gWheelWidth),

connectionHeight, 2-gWheelRadius); 2 3 mVehicle->addWheel(mWheelNodes[0], connectionPointCS0,

wheelDirectionCS0, wheelAxleCS, gSuspensionRestLength, gWheelRadius, isFrontWheel, gWheelFriction, gRollInfluence);

6.12. Determinismo

[257] Finalmente el método de callback del FrameStarted se encarga de modificar la fuerza que se aplica sobre el motor del vehículo cuando se utilizan los cursores superior e inferior del teclado. De igual modo, empleando los cursores izquierdo✄ y derecho del teclado se modifica la dirección del vehículo (ver líneas ✂11-15 ✁). Listado 6.21: Fragmento de FrameStarted. 1 bool MyFrameListener::frameStarted(const Ogre::FrameEvent& evt) { 2 // Omitido el codigo anterior... 3 mVehicle->applyEngineForce (0,0); 4 mVehicle->applyEngineForce (0,1); 5 6 if (_keyboard->isKeyDown(OIS::KC_UP)) { 7 mVehicle->applyEngineForce (gEngineForce, 0); 8 mVehicle->applyEngineForce (gEngineForce, 1); 9 } 10 11 if (_keyboard->isKeyDown(OIS::KC_LEFT)) { 12 if (mSteering < 0.8) mSteering+=0.01; 13 mVehicle->setSteeringValue (mSteering, 0); 14 mVehicle->setSteeringValue (mSteering, 1); 15 } 16 17 // Omitido el resto del codigo... 18 }

6.12.

Determinismo

El determinismo en el ámbito de la simulación física puede definirse de forma intuitiva como la posibilidad de «repetición» de un mismo comportamiento. En el caso de videojuegos esto puede ser interesante en la repetición de una misma jugada en un videojuego deportivo, o en la ejecución de una misma simulación física en los diferentes ordenadores de un videojuego multijugador. Incluso aunque el videojuego siga un enfoque con cálculos de simulación centrados en el servidor, habitualmente es necesario realizar ciertas interpolaciones del lado del cliente para mitigar los efectos de la latencia, por lo que resulta imprescindible tratar con enfoques deterministas. Para lograr determinismo es necesario lograr que la simulación se realice exactamente con los mismos datos de entrada. Debido a la precisión en aritmética en punto flotante, es posible que v × 2 × dt no de el mismo resultado que v × dt + v × dt. Así, es necesario emplear el mismo valor de dt en todas las simulaciones. Por otro lado, utilizar un dt fijo hace que no podamos representar la simulación de forma independiente de las capacidades de la máquina o la carga de representación gráfica concreta en cada momento. Así, nos interesa tener lo mejor de ambas aproximaciones; por un lado un tiempo fijo para conseguir el determinismo en la simulación, y por otro lado la gestión con diferentes tiempos asociados al framerate para lograr independencia de la máquina.

[258]

CAPÍTULO 6. SIMULACIÓN FÍSICA

Figura 6.32: La gestión del determinismo puede ser un aspecto crítico en muchos videojuegos. El error de determinismo rápidamente se propaga haciendo que la simulación obtenga diferentes resultados.

Una posible manera de realizar la simulación sería la siguiente: el motor de simulación física se ejecuta por adelantado en intervalos de tiempo discretos dt, de modo que se mantengan los incrementos del motor gráfico con un intervalo adecuado. Por ejemplo, si queremos tener 50fps y la simulación física se ejecuta a 100fps, entonces tendríamos que ejecutar dos veces la simulación física por cada despliegue gráfico. Esto es correcto con esos cálculos sencillos, pero ¿qué ocurre si queremos dibujar a 200fps?. En ese caso tendríamso que ejecutar la mitad de veces el simulador físico, pero no podemos calcular por adelantado un valos de dt. Además, podría ocurrir que no existiera un múltiplo cómodo para sincronizar el motor de simulación física y el motor de despliegue gráfico. La forma de resolver el problema pasa por cambiar el modo de pensar en él. Podemos pensar que el motor de render produce tiempo, y el motor de simulación física tiene que consumirlo en bloques discretos de un tamaño determinado.

Puede ayudar pensar que el motor de render produce chunks de tiempo discreto, mientras que el motor de simulación física los consume.

A continuación se muestra un sencillo game loop que puede emplearse para conseguir determinismo de una forma sencilla. Los tiempos mostrados en este pseudocódigo se especifican en milisegundos, y se obtienen a partir de una hipotética función getMillisecons(). ✄ La línea ✂1 ✁define TickMs, una variable que nos define la velocidad del reloj interno de nuestro juego (por ejemplo, 32ms). Esta variable no tiene que ver con el reloj de Bullet. Las variables relativas al reloj de

6.13. Escala de los Objetos

[259] simulación física describen el comportamiento independiente y asín✄ crono ✄del reloj interno de Bullet (línea ✂2 ✁) y el reloj del motor de juego (línea ✂3 ✁). Listado 6.22: Pseudocódigo física determinista. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

const unsigned int TickMs 32 unsigned long time_physics_prev, time_physics_curr; unsigned long time_gameclock; // Inicialmente reseteamos los temporizadores time_physics_prev = time_physics_curr = getMilliseconds(); time_gameclock = getMilliseconds(); while (1) { video->renderOneFrame(); time_physics_curr = getMilliseconds(); mWorld->stepSimulation(((float)(time_physics_curr time_physics_prev))/1000.0, 10); time_physics_prev = time_physics_curr; long long dt = getMilliseconds() - time_gameclock; while(dt >= TickMs) { dt -= TickMs; time_gameclock += TickMs; input->do_all_your_input_processing(); } }

✄ Como se indica en las líneas ✂6-7 ✁, inicialmente se resetean los temporizadores. El ✄ pseudocódigo del bucle principal del juego se resume en las líneas ✂9-21 ✁. Tras representar un frame, se obtiene el tiempo ✄ transcurrido desde la última simulación física (línea ✂11 ✁), y se avanza un paso de simulación en segundos (como la llamada al sistema lo obtiene en milisegundos y Bullet lo requiere en segundos, hay que dividir por 1000). Por último, se actualiza la parte relativa al reloj de juego. Se calcula en dt la diferencia entre los milisegundos que pasaron desde la última vez que se acualizó el✄ reloj de juego, y se dejan pasar (en el bucle definido en las líneas ✂17-21 ✁) empleando ticks discretos. En cada tick consumido se procesan los eventos de entrada.

6.13.

Escala de los Objetos

Como se ha comentado en secciones anteriores, Bullet asume que las unidades de espacio se definen en metros y el tiempo en segundos. El movimieneto de los objetos se define entre 0.05 y 10 unidades. Así, la escala habitual para definir los pasos de simulación suelen ser 1/60 segundos. Si los objetos son muy grandes, y se trabaja con la gravedad por defecto (9,8m/s2 ), los objetos parecerán que se mueven a cámara lenta. Si esto ocurre, muy probablemente tengamos un problema relativo a la escala de los mismos. Una posible solución puede pasar por aplicar una escala al mundo de la simulación. Esto esquivale a utilizar un conjunto diferente de

[260]

CAPÍTULO 6. SIMULACIÓN FÍSICA

unidades, como centímetros en lugar de metros. Si se seleccionan con cuidado, esto puede permitir realizar simulaciones más realistas. Por ejemplo, si queremos diseñar un videojuego de billar, escalamos el mundo en un factor de 100, de modo que 4 unidades equivaldrán a 4cm (diámetro de las bolas de billar).

6.14.

Serialización

La serialización de objetos en Bullet es una característica propia de la biblioteca que no requiere de ningún plugin o soporte adicional. La serialización de objetos presenta grandes ventajas relativas al precálculo de formas de colisión complejas. Para guardar un mundo dinámico en un archivo .bullet, puede utilizarse el siguiente fragmento de código de ejemplo: Listado 6.23: Ejemplo de Serialización. 1 2 3 4 5

btDefaultSerializer* serializer = new btDefaultSerializer(); dynamicsWorld->serialize(serializer);

FILE* file = fopen("testFile.bullet","wb"); fwrite(serializer->getBufferPointer(),serializer-> getCurrentBufferSize(),1, file); 6 fclose(file);

Aunque lo más sencillo es serializar un mundo completo, es igualmente posible serializar únicamente algunas partes del mismo. El foramto de los archivos .bullet soporta la serialización parcial de elementos empleando chunks independientes. En la posterior carga de los archivos .bullet, se debe utilizar la cabecera de BulletWorldImporter, creando un objeto de esa clase. El constructor de esa clase requiere que se le especifique el mundo dinámico sobre el que creará los objetos que fueron serializados. El uso del importador puede resumirse en el siguiente fragmento de código: Listado 6.24: Importación de datos serializados. 1 #include "btBulletWorldImporter.h" 2 btBulletWorldImporter* f = new btBulletWorldImporter(_dynWorld); 3 f->loadFile("testFile.bullet");

Capítulo

7

Gestión de Widgets César Mora Castro

C

omo se ha visto a lo largo del curso, el desarrollo de un videojuego requiere tener en cuenta una gran variedad de disciplinas y aspectos: gráficos 3D o 2D, música, simulación física, efectos de sonido, jugabilidad, eficiencia, etc. Uno de los aspectos a los que se les suele dar menos importancia, pero que juegan un papel fundamental a la hora de que un juego tenga éxito o fracase, es la interfaz de usuario. Sin embargo, el mayor inconveniente es que la mayoría de los motores gráficos no dan soporte para la gestión de Widgets, y realizarlos desde cero es un trabajo más costoso de lo que pueda parecer. En este capítulo se describe de forma general la estructura y las guías que hay que tener en cuenta a la hora de diseñar y desarrollar una interfaz de usuario. Además, se explicará el uso de CEGUI, una biblioteca de gestión de Widgets para integrarlos en motores gráficos. Eficiencia y diseño Para desarrollar un videojuego, tan importante es cuidar la eficiencia y optimizarlo, como que tenga un diseño visualmente atractivo.

7.1.

Interfaces de usuario en videojuegos

Las interfaces de usuario específicas de los videojuegos deben tener el objetivo de crear una sensación positiva, que consiga la mayor inmersión del usuario posible. Estas interfaces deben tener lo que se denomina flow. El flow[19] es la capacidad de atraer la atención del usuario, manteniendo su concentración, la inmersión dentro de la trama del videojuego, y que consiga producir una experiencia satisfactoria. Cada vez se realizan estudios más serios sobre cómo desarrollar interfaces que tengan flow, y sean capaces de brindar una mejor experiencia al usuario. La principal diferencia con las interfaces de usuario 261

[262]

CAPÍTULO 7. GESTIÓN DE WIDGETS

de aplicaciones no orientadas al ocio, es que estas centran su diseño en la usabilidad y la eficiencia, no en el impacto sensorial. Si un videojuego no consigue atraer y provocar sensaciones positivas al usuario, este posiblemente no triunfará, por muy eficiente que sea, o por muy original o interesante que sea su trama. A continuación se detalla una lista de aspectos a tener en cuenta que son recomendables para aumentar el flow de un videojuego, aunque tradicionalmente se han considerado perjudiciales a la hora de diseñar interfaces tradicionales según las reglas de interacción persona-computador: Mostrar la menor cantidad de información posible: durante el transcurso del juego, es mejor no sobrecargar la interfaz con una gran cantidad de información. En la gran mayoría de videojuegos, toda esta configuración se establece antes de comenzar el juego (por ejemplo, en el Menú), por lo que la interfaz queda menos sobrecargada y distrae menos al usuario. Incluso el usuario puede tener la opción de mostrar menos información aún si lo desea. Inconsistencia de acciones: en algunos casos, es posible que se den inconsistencias en las acciones dependiendo del contexto del personaje. Por ejemplo, el botón de saltar cuando el personaje está en tierra puede ser el de nadar si de repente salta al agua. Es importante mantener un número reducido de teclas (tanto si es por limitaciones de la plataforma, como una videoconsola, como para hacer la usabilidad más sencilla al usuario). Por lo tanto, hay que conseguir agrupar las acciones en los botones según su naturaleza. Por ejemplo, un botón lleva a cabo acciones con objetos y peronajes (hablar, abrir una puerta), y otro movimientos de desplazamiento (saltar, escalar). Esto aumentará la intuitividad y la usabilidad del videojuego, y por lo tanto, su flow. Dificultar los objetivos al usuario: una de las reglas de oro de la interacción persona-computador es prevenir al usuario de cometer errores. Sin embargo, en los videojuegos esta regla puede volverse contradictoria, pues en la mayoría de los casos el usuario busca en los videojuegos un sentimiento de satisfacción que se logra por medio de la superación de obstáculos y desafíos. Por lo tanto, es también de vital importancia conseguir un equilibrio en la dificultad del juego, que no sea tan difícil como para frustrar al usuario, pero no tan fácil como para que resulte aburrido. En este aspecto la interfaz juega un papel de mucho peso. Se ha visto cómo el caso particular de las interfaces de los videojuegos puede contradecir reglas que se aplican en el diseño de interfaces de usuario clásicas en el campo de la interacción persona-computador. Sin embargo, existen muchas recomendaciones que son aplicables a ambos tipos de interfaces. A continuación se explican algunas: Mantener una organización intuitiva: es importante que el diseño de los menús sean intuitivos. En muchos casos, esta falta de organización crea confusión innecesaria al usuario.

7.1. Interfaces de usuario en videojuegos

[263]

Ofrecer una legibilidad adecuada: en algunos casos, darle demasiada importancia a la estética puede implicar que la legibilidad del texto de las opciones o botones se vea drásticamente reducida. Es importante mantener la funcionalidad básica. Esperas innecesarias: en multitud de videojuegos, el usuario se ve forzado a esperar a que una determinada película o animación se reproduzca de forma completa, sin poder omitirla. Incluso en el caso en que pueda omitirse, el usuario ha debido esperar previamente a la carga del clip de vídeo para después poder omitirla. Este tipo de inconvenientes reduce notablemente el flow de la aplicación. Existen multitud de formas en las que el usuario realiza esperas innecesarias, y que aumenta su frustración. Por ejemplo, si quiere volver a repetir una acción, tiene que volver a confirmar uno por uno todos los parámetros, aunque estos no cambien. Este es el caso de los juegos de carreras, en el que para volver a repetir una carrera es necesario presionar multitud botones e incluso esperar varios minutos. Ayuda en línea: muchas veces el usuario necesita consultar el manual durante el juego para entender alguna característica de él. Sin embargo, este manual es documentación extensa que no rompe con la inmersión del videojuego. Es conveniente que se proporcione una versión suave, acorde con la estética y que muestre la información estrictamente necesaria. En general, es importante tener en cuenta cuatro puntos importantes: 1. Intuitividad: cuán fácil es aprender a usar una interfaz de un videojuego. 2. Eficiencia: cuán rápido se puede realizar una tarea, sobretodo si es muy repetitiva. 3. Simplicidad: mantener los controles y la información lo más minimalista posible. 4. Estética: cuán sensorialmente atractiva es la interfaz. Una vez vistas algunas guías para desarrollar interfaces de usuario de videojuegos atractivas y con flow, se va a describir la estructura básica que deben tener. Existe una estructura básica que un videojuego debe seguir. No es buena práctica comenzar el juego directamente en el “terreno de juego” o “campo de batalla”. La estructura típica que debe seguir la interfaz de un videojuego es la siguiente: En primer lugar, es buena práctica mostrar una splash screen. Este tipo de pantallas se muestran al ejecutar el juego, o mientras se carga algún recurso que puede durar un tiempo considerable, y pueden ser

[264]

CAPÍTULO 7. GESTIÓN DE WIDGETS

Figura 7.2: Extracto del menú de configuración de Nexuiz (izquierda), e interfaz de ScummVM (derecha).

usadas para mostrar información sobre el juego o sobre sus desarrolladores. Suelen mostrarse a pantalla completa, o de menor tamaño pero centradas. La Figura 7.1 muestra la splash screen del juego free orion. Las otros dos elementos de la esctructura de un videojuego son el Menú y el HUD. Suponen una parte muy importante de la interfaz de un juego, y es muy común utilizar Widgets en ellos. A continuacion se analizarán más en detalle y se mostrarán algunos ejemplos.

7.1.1. Menú Todos los videojuegos deben tener un Menú desde el cual poder elegir los modos de juego, configurar opciones, mostrar información adicional y otras características. Dentro de estos menús, es muy frecuente el uso de Widgets como botones, barras deslizantes (por ejemplo, para configurar la resolución de pantalla), listas desplegables (para elegir idioma), o check buttons (para activar o desactivar opciones). Por eso es importante disponer de un buen repertorio de Widgets, y que sea altamente personalizable para poder adaptarlos al estilo visual del videojuego. En la Figura 7.2 se puede apreciar ejemplos de interfaces de dos conocidos juegos open-source. La interfaz de la izquierda, correspondiente al juego Nexuiz, muestra un trozo de su dialogo de configuración, mientras que la de la derecha corresponde a la interfaz de ScummVM. En estos pequeños ejemplos se muestra un número considerable de Widgets, cuyo uso es muy común: Pestañas: para dividir las opciones por categorías. Barras de desplazamiento: para configurar opciones que pueden tomar valores muy numerosos. Radio buttons: parámetros que pueden tomar valores excluyentes entre ellos. Check buttons: activan o desactivan una opción.

Figura 7.1: Ejemplo de Splash Screen durante la carga del juego FreeOrion.

7.2. Introducción CEGUI

[265]

Figura 7.3: Screenshot del HUD del juego FreeOrion.

7.1.2. HUD En relación a las interfaces de los videojuegos, concretamente se denomina HUD (del inglés, Head-Up Display), a la información y elementos de interacción mostrados durante el propio transcurso de la partida. La información que suelen proporcionar son la vida de los personajes, mapas, velocidad de los vehículos, etc. En la Figura 7.3 se muestra una parte de la interfaz del juego de estrategia ambientada en el espacio FreeOrion. La interfaz utiliza elementos para mostrar los parámetros del juego, y también utiliza Widgets para interactuar con él. Como se puede intuir, el uso de estos Widgets es muy común en cualquier videojuego, independientemente de su complejidad. Sin embargo, crear desde cero un conjunto medianamente funcional de estos es una tarea nada trivial, y que roba mucho tiempo de la línea principal de trabajo, que es el desarrollo del propio videojuego. Una vez que se ha dado unas guías de estilo y la estructura básicas para cualquier videojuego, y se ha mostrado la importancia de los Widgets en ejemplos reales, se va a estudiar el uso de una potente biblioteca que proporciona estos mismos elementos para distintos motores gráficos, para que el desarrollo de Widgets para videojuegos sea lo menos problemático posible. CEGUI’s mission Como dice en su página web, “CEGUI está dirigido a desarrolladores de videojuegos que deben invertir su tiempo en desarrollar buenos juegos, no creando subsistemas de interfaces de usuario”.

7.2.

Introducción CEGUI

CEGUI[2] (Crazy Eddie’s GUI) es una biblioteca open source multiplataforma que proporciona entorno de ventanas y Widgets para motores gráficos, en los cuales no se da soporte nativo, o es muy deficiente. Es orientada a objetos y está escrita en C++.

[266]

CAPÍTULO 7. GESTIÓN DE WIDGETS

CEGUI es una biblioteca muy potente en pleno desarrollo, por lo que está sujeta a continuos cambios. Todas las características y ejemplos descritos a lo largo de este capítulo se han creado utilizando la versión actualmente estable, la 0.7.x. No se asegura el correcto funcionamiento en versiones anteriores o posteriores.

CEGUI es muy potente y flexible. Es compatible con los motores gráficos OpenGL, Direct3D, Irrlicht y Ogre3D. De la misma forma que Ogre3D es únicamente un motor de rendering, CEGUI es sólo un motor de de gestión de Widgets, por lo que el renderizado y la gestión de eventos de entrada deben ser realizadas por bibliotecas externas. En sucesivas secciones se explicará cómo integrar CEGUI con las aplicaciones de este curso que hacen uso de Ogre3D y OIS. Además se mostrarán ejemplos prácticos de las características más importantes que ofrece.

7.2.1. Inicialización La arquitectura de CEGUI es muy parecida a la de Ogre3D, por lo que su uso es similar. Está muy orientado al uso de scripts, y hace uso del patrón Singleton para implementar los diferentes subsistemas. Los más importantes son: CEGUI::System: gestiona los parámetros y componentes más importantes de la biblioteca. CEGUI::WindowManager: se encarga de la creación y gestión de las windows de CEGUI. CEGUI::SchemeManager: gestiona los diferentes esquemas que utilizará la interfaz gráfica. CEGUI::FontManager: gestiona los distintos tipos de fuentes de la interfaz. Estos subsistemas ofrecen funciones para poder gestionar los diferentes recursos que utiliza CEGUI. A continuación se listan estos tipos de recursos: Schemes: tienen la extensión .scheme. Definen el repertorio (o esquema) de Widgets que se utilizarán. También indica qué scripts utilizará de otros tipos, como por ejemplo el ImageSet, las Fonts o el LookNFeel.

CEGUI y Ogre3D A lo largo de estos capítulos, se utilizará la fórmula CEGUI/Ogre3D/OIS para proveer interfaz gráfica, motor de rendering y gestión de eventos a los videojuegos, aunque también es posible utilizarlo con otras bibliotecas (ver documentación de CEGUI).

7.2. Introducción CEGUI

[267] Imageset: tienen la extensión .imageset. Define cuáles serán la imágenes de los elementos de la interfaz (punteros, barras, botones, etc). LookNFeel: tienen la extensión .looknfeel. Define el comportamiento visual de cada uno de los Widgets para distintas acciones, por ejemplo, cómo se muestran cuando se pasa el puntero del ratón o cuando se presionan, Fonts: tienen la extensión .font. Cada uno de los scripts define un tipo de fuente junto con propiedades específicas como su tamaño. Layouts: tienen la extensión .layout. Cada script define clases de ventanas concretas, con cada uno de sus elementos. Por ejemplo, una ventana de chat o una consola. Según se avance en el capítulo se irá estudiando más en profundidad cuál es el funcionamiento y la estructura de estos recursos. En el siguiente código se muestran los primeros pasos para poder integrar CEGUI con Ogre3D, y de qué forma se inicializa. Listado 7.1: Inicializacón de CEGUI para su uso con Ogre3D. 1 #include 2 #include 3 4 CEGUI::OgreRenderer* renderer = &CEGUI::OgreRenderer::

bootstrapSystem(); 5 6 7 8 9 10

CEGUI::Scheme::setDefaultResourceGroup("Schemes"); CEGUI::Imageset::setDefaultResourceGroup("Imagesets"); CEGUI::Font::setDefaultResourceGroup("Fonts"); CEGUI::WindowManager::setDefaultResourceGroup("Layouts"); CEGUI::WidgetLookManager::setDefaultResourceGroup("LookNFeel");

Este método de inicializar el renderer utilizando el bootstrapSystem fue introducido a partir de la versión 0.7.1. Para inicializar CEGUI en versiones anteriores, es necesario referirse a su documentacion.

En las líneas 1 y 2 se insertan las cabeceras necesarias. La primera incluye la biblioteca general, y en la segunda se indica de forma concreta que se va a utilizar el motor gráfico Ogre3D. En la línea 4 se inicializa CEGUI para ser utilizado con Ogre3D. Además es necesario indicar dónde estarán los recursos que utilizará la interfaz gráfica, tanto los scripts que utiliza, como las fuentes o las imágenes. Dependiendo de la distribución que se utilice, estos recursos pueden venir con el paquete del repositorio o no. En este ejemplo vamos a considerar que debemos descargarlos aparte. Se pueden conseguir directamente descargando el código fuente de CEGUI desde su

[268]

CAPÍTULO 7. GESTIÓN DE WIDGETS

página[2]. Las distribuciones que los proporcionan, suelen situarlos en /usr/share/CEGUI/ o /usr/local/share/CEGUI/ Para que CEGUI pueda encontrar los recursos, es necesario añadir estos grupos al fichero resources.cfg de Ogre. Listado 7.2: Contenido del fichero resources.cfg. 1 2 3 4 5 6 7 8 9 10 11 12

[General] FileSystem=media [Schemes] FileSystem=media/schemes [Imagesets] FileSystem=media/imagesets [Fonts] FileSystem=media/fonts [Layouts] FileSystem=media/layouts [LookNFeel] FileSystem=media/looknfeel

Y las opciones que hay que añadir al Makefile para compilar son: Listado 7.3: Flags de compilación y de enlazado de CEGUI. 1 2 3 4 5 6

#Flags de compilado CXXFLAGS += ‘pkg-config --cflags CEGUI-OGRE‘ #Flags de enlazado LDFLAGS += ‘pkg-config --libs-only-L CEGUI-OGRE‘ LDLIBS += ‘pkg-config --libs-only-l CEGUI-OGRE‘

Es importante incluir los flags de compilado, en la línea 2, para que encuentre las cabeceras según se han indicado en el ejemplo de inicialización. Esto es sólo el código que inicializa la biblioteca en la aplicación para que pueda comenzar a utilizar CEGUI como interfaz gráfica, todavía no tiene ninguna funcionalidad. Pero antes de empezar a añadir Widgets, es necesario conocer otros conceptos primordiales.

7.2.2. El Sistema de Dimensión Unificado El posicionamiento y tamaño de los distintos Widgets no es tan trivial como indicar los valores absolutos. Puede ser deseable que un Widget se reposicione y redimensione si el Widget al que pertenece se redimensiona, por ejemplo. CEGUI utiliza lo que denomina el Sistema de Dimensión Unificado (Unified Dimension System). El elemento principal de este sistema es: CEGUI::UDim(scale, offset)

7.2. Introducción CEGUI

[269]

A

A

BCCDEF

E Figura 7.4: Ejemplo del funcionamiento de UDim.

Indica la posición en una dimensión. El primer parámetro indica la posición relativa, que toma un valor entre 0 y 1, mientras que el segundo indica un desplazamiento absoluto en píxeles.

A

BCDE F

A

Figura 7.5: Área rectangular definida por URect.

Por ejemplo, supongamos que posicionamos un Widget con UDim 0.5,20 en la dimensión x. Si el ancho de la pantalla fuese 640, la posición sería 0.5*640+20 = 340, mientras que si el ancho fuese 800, la posición seriá 0.5*800+20 = 420. En la Figura 7.4 se aprecian los dos ejemplos de forma gráfica. De esta forma, si la resolución de la pantalla cambia, por ejemplo, el Widget se reposicionará y se redimensionará de forma automática. Teniendo en cuenta cómo expresar el posicionamiento en una única dimensión utilizando UDim, se definen dos elementoss más. Para definir un punto o el tamaño de un Widget se usa: CEGUI::UVector2(UDim x, UDim y) que está compuesto por dos UDim, uno para la coordenada x, y otro para la y, o para el ancho y el alto, dependiendo de su uso. El segundo elemento, se utiliza para definir un área rectangular: CEGUI::URect(UDim left, UDim top, UDim right, UDIM bottom) Como muestra la Figura 7.5, los dos primeros definen la esquina superior izquierda, y los dos últimos la esquina inferior derecha.

7.2.3. Detección de eventos de entrada Puesto que CEGUI es únicamente un motor de gestión de Widgets, tampoco incorpora la detección de eventos de entrada, por lo que es necesario inyectárselos desde otra biblioteca. En este caso, se aprovechará la que ya se ha estudiado: OIS.

[270]

CAPÍTULO 7. GESTIÓN DE WIDGETS

Considerando que se utiliza OIS mediante callbacks (en modo buffered), hay que añadir las siguientes líneas para enviar a CEGUI la pulsación y liberación de teclas y de los botones del ratón. Listado 7.4: Inyección de eventos de pulsación y liberación de teclas a CEGUI. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

bool MyFrameListener::keyPressed(const OIS::KeyEvent& evt) { CEGUI::System::getSingleton().injectKeyDown(evt.key); CEGUI::System::getSingleton().injectChar(evt.text); return true; } bool MyFrameListener::keyReleased(const OIS::KeyEvent& evt) { CEGUI::System::getSingleton().injectKeyUp(evt.key); return true; } bool MyFrameListener::mousePressed(const OIS::MouseEvent& evt, OIS ::MouseButtonID id) { CEGUI::System::getSingleton().injectMouseButtonDown( convertMouseButton(id)); return true; }

19 20 21 22 bool MyFrameListener::mouseReleased(const OIS::MouseEvent& evt, OIS

::MouseButtonID id) 23 { 24 CEGUI::System::getSingleton().injectMouseButtonUp(

convertMouseButton(id)); 25 return true; 26 }

Además, es necesario convertir la forma en que identifica OIS los botones del ratón, a la que utiliza CEGUI, puesto que no es la misma, al contrario que sucede con las teclas del teclado. Para ello se ha escrito la función convertMouseButton(): Listado 7.5: Función de conversión entre identificador de botones de ratón de OIS y CEGUI. 1 CEGUI::MouseButton MyFrameListener::convertMouseButton(OIS::

MouseButtonID id) 2 { 3 CEGUI::MouseButton ceguiId; 4 switch(id) 5 { 6 case OIS::MB_Left: 7 ceguiId = CEGUI::LeftButton; 8 break; 9 case OIS::MB_Right: 10 ceguiId = CEGUI::RightButton; 11 break; 12 case OIS::MB_Middle: 13 ceguiId = CEGUI::MiddleButton; 14 break;

7.3. Primera aplicación

[271]

15 default: 16 ceguiId = CEGUI::LeftButton; 17 } 18 return ceguiId; 19 }

Por otro lado, también es necesario decir a CEGUI cuánto tiempo ha pasado desde la detección del último evento, por lo que hay que añadir la siguiente línea a la función frameStarted(): Listado 7.6: Orden que indica a CEGUI el tiempo transcurrido entre eventos. 1 CEGUI::System::getSingleton().injectTimePulse(evt.

timeSinceLastFrame)

Hasta ahora se ha visto el funcionamiento básico de CEGUI, los tipos básicos de scripts que define, la inicialización, el sistema de posicionamiento y dimensionado que utiliza e incluso como enviarle eventos de entrada. Una vez adquiridos estos conocimientos, es momento de crear la primera aplicación de Ogre que muestre un Widget con funcionalidad, como se describirá en la siguiente sección.

7.3.

Primera aplicación

En esta sección se van a poner en práctica los primeros conceptos descritos para crear una primera aplicación. Esta aplicación tendrá toda la funcionalidad de Ogre (mostrando a Sinbad), y sobre él un botón para salir de la aplicación.

Es importante tener en cuenta que en CEGUI, todos los elementos son Windows. Cada uno de los Windows puede contener a su vez otros Windows. De este modo, pueden darse situaciones raras como que un botón contenga a otro botón, pero que en la práctica no suceden.

Listado 7.7: Código de la función createGUI() 1 void MyApp::createGUI() 2 { 3 renderer = &CEGUI::OgreRenderer::bootstrapSystem(); 4 CEGUI::Scheme::setDefaultResourceGroup("Schemes"); 5 CEGUI::Imageset::setDefaultResourceGroup("Imagesets"); 6 CEGUI::Font::setDefaultResourceGroup("Fonts"); 7 CEGUI::WindowManager::setDefaultResourceGroup("Layouts"); 8 CEGUI::WidgetLookManager::setDefaultResourceGroup("LookNFeel"); 9 10 CEGUI::SchemeManager::getSingleton().create("TaharezLook.scheme") 11

; CEGUI::System::getSingleton().setDefaultFont("DejaVuSans-10");

[272]

12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 }

CAPÍTULO 7. GESTIÓN DE WIDGETS

CEGUI::System::getSingleton().setDefaultMouseCursor("TaharezLook" ,"MouseArrow"); //Creating GUI Sheet CEGUI::Window* sheet = CEGUI::WindowManager::getSingleton(). createWindow("DefaultWindow","Ex1/Sheet"); //Creating quit button CEGUI::Window* quitButton = CEGUI::WindowManager::getSingleton(). createWindow("TaharezLook/Button","Ex1/QuitButton"); quitButton->setText("Quit"); quitButton->setSize(CEGUI::UVector2(CEGUI::UDim(0.15,0),CEGUI:: UDim(0.05,0))); quitButton->setPosition(CEGUI::UVector2(CEGUI::UDim(0.5-0.15/2,0) ,CEGUI::UDim(0.2,0))); quitButton->subscribeEvent(CEGUI::PushButton::EventClicked, CEGUI::Event::Subscriber(&MyFrameListener::quit, _framelistener)); sheet->addChildWindow(quitButton); CEGUI::System::getSingleton().setGUISheet(sheet);

La función createGUI() se encarga de la inicialización de la interfaz gráfica y de la creación de los elementos que contendrá. Como se explicó en la Sección 7.2.1, de las líneas 3-8 se indica que se quiere utilizar Ogre3D como motor de rendering, y se indica a CEGUI dónde están los distintos recursos. En la línea 10 se crea el esquema que se va a utilizar. Se recuerda que un esquema definía el conjunto de Widgets que se podrán utilizar en la aplicación, junto a los tipos de letras, apariencia o comportamiento visual. Es como la elección del tema de la interfaz. El fichero de script TaharezLook.scheme debe de encontrarse en algún lugar del que CEGUI tenga constancia. Como se ha definido en el fichero resources.cfg, los esquemas (Schemes) deben estar en media/schemes. Desde su página web se pueden descargar otros ejemplos, como el esquema Vanilla. Más adelante se analizará brevemente el contenido de estos scripts, para poder ajustar la interfaz gráfica a la estética del videojuego. En las líneas 11 y 12 se definen algunos parámetros por defecto. En el primer caso, el tipo de letra predeterminada, y en el segundo el cursor, ambos elementos definidos en TaharezLook.scheme. Los Widgets de la interfaz gráfica se organizan de forma jerárquica, de forma análoga al grafo de escena Ogre. Cada Widget (o Window) debe pertenecer a otro que lo contenga. De este modo, debe de haber un Widget “padre” o “raíz”. Este Widget se conoce en CEGUI como Sheet (del inglés, hoja, refiriéndose a la hoja en blanco que contiene todos los elementos). Esta se crea en la línea 15. El primer parámetro indica el tipo del Window, que será un tipo genérico, DefaultWindow. El segundo es el nombre que se le da a ese elemento. Con Ex1 se hace referencia a que es el primer ejemplo (Example1), y el segundo es el nombre del elemento.

7.3. Primera aplicación

[273] El siguiente paso es crear el botón. En la línea 18 se llama al WindowManager para crear un Window (hay que recordar que en CEGUI todo es un Window). El primer parámetro indica el tipo, definido en el esquema escogido, en este caso un botón. El segundo es el nombre del elemento, para el cual se sigue el mismo convenio de nombrado que para el Sheet.

Convenio de nombrado CEGUI no exige que se siga ningún convenio de nombrado para sus elementos. Sin embargo, es altamente recomendable utilizar un convenio jerárquico, utilizando la barra “/” como separador.

Después se indican algunos parámetros del botón. En la línea 19 se indica el texto del botón, utilizando la fuente predeterminada del sistema que se indicó en la inicialización. En la línea 20 se indica el tamaño. Como se explicó en la Sección 7.2.2, para el tamaño se utiliza un UVector2, que contiene dos valores, ancho y alto. Por lo tanto, el ancho de este botón siempre será 0.15 del ancho del Sheet, y el alto será 0.05. Para indicar la posición del Widget, se opta por centrarlo horizontalmente. Como se puede ver en la línea 21, para la posición en la dimensión x se indica la mitad del ancho del Sheet, 0.5, menos la mitad del ancho del Widget, es decir, 0.15/2 (el tamaño se acaba de indicar en la línea 20). Esto se debe a que el posicionamiento toma como punto de referencia la esquina superior izquierda del Widget. Para la posición en el eje y se ha optado por un 0.2 del alto del Sheet. Hasta el momento se ha creado el Sheet que contendrá todo el conjunto de Widgets, un botón con el texto “Quit”, y con un tamaño y apariencia determinado. Ahora se le va a asociar un comportamiento para cuando se pulse. Para asociar comportamientos, es necesario suscribir las funciones que implementan el comportamiento a los elementos. En la línea 22 se asocia ese comportamiento. El primer parámetro indica a qué tipo de acción se asocia el comportamiento, y en el segundo qué función se ejecuta. Existen una extensa lista de acciones a las que se pueden asociar comportamientos, como por ejemplo: MouseClicked MouseEnters MouseLeaves

Figura 7.6: Screenshot de la primera aplicación de ejemplo.

EventActivated EventTextChanged EventAlphaChanged EventSized Como se ha estudiado anteriormente, al igual que pasa con el grafo de escena de Ogre3D, cada Window de CEGUI debe tener un padre. En la línea 25 se asocia el botón al Sheet, y por último, en la línea 26 se indica a CEGUI cuál es el Sheet que debe mostrar.

[274]

CAPÍTULO 7. GESTIÓN DE WIDGETS

A continuación se muestra la definición de la función que implementa el comportamiento. Como se puede apreciar, simplemente cambia el valor de una variable booleana que controla la salida de la aplicación. Es importante tener en cuenta que no todas las funciones pueden ser utilizadas para implementar el comportamiento de los elementos. En su signatura, deben de tener como valor de retorno bool, y aceptar un único parámetro del tipo const CEGUI::EventArgs& e Listado 7.8: Función que implementa el comportamiento del botón al ser pulsado. 1 bool MyFrameListener::quit(const CEGUI::EventArgs &e) 2 { 3 _quit = true; 4 return true; 5 }

En la Figura 7.6 se puede ver una captura de esta primera aplicación. Ya que se ha visto cómo inicializar CEGUI y cuál es su funcionamiento básico, es momento de comenzar a crear interfaces más complejas, útiles, y atractivas.

7.4.

Tipos de Widgets

Para comenzar a desarrollar una interfaz gráfica con CEGUI para un videojuego, primero es necesario saber cuál es exactamente el repertorio de Widgets disponible. Como se ha estudiado en secciones anteriores, el repertorio como tal está definido en el esquema escogido. Para los sucesivos ejemplos, vamos a utilizar el esquema TaharezLook, utilizado también en la primera aplicación de inicialización. CEGUI proporciona otros esquemas que ofrecen otros repertorios de Widgets, aunque los más comunes suelen estar implementados en todos ellos. Otros esquemas que proporciona CEGUI son OgreTray, VanillaSkin y WindowsLook. El script del esquema define además la apariencia y el comportamiento visual de los Widgets. Para cambiar la apariencia visual, no es necesario crear un fichero esquema desde cero (lo que sería una ardua tarea). Basta con cambiar el script de los ImageSet y de los Fonts. Esto se estudiará con más profundidad en la Sección 7.8. A continuación se muestra una pequeña lista de los Widgets más importantes definidos en el esquema TaharezLook: Button Check Box Combo Box Frame Window

7.5. Layouts

[275] List Box Progress Bar Slider Static Text etc El siguiente paso en el aprendizaje de CEGUI es crear una interfaz que bien podría servir para un juego, aprovechando las ventajas que proporcionan los scripts.

7.5. Layouts Los scripts de layouts especifican qué Widgets habrá y su organización para una ventana específica. Por ejemplo, un layout llamado chatBox.layout puede contener la estructura de una ventana con un editBox para insertar texto, un textBox para mostrar la conversación, y un button para enviar el mensaje. De cada layout se pueden crear tantas instancias como se desee. No hay que olvidar que estos ficheros son xml, por lo que deben seguir su estructura. La siguiente es la organización genérica de un recurso layout: Listado 7.9: Estructura de un script layout. 1 2 3

4

5

6











Figura 7.7: Resultado de la ventana de configuración del ejemplo.

7.6. Ejemplo de interfaz

[277]

32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

















Y el siguiente listado muestra cada una de las cadenas que se han utilizado, junto a las etiquetas:

7.11. Características avanzadas

[289]

Listado 7.17: Código con los tags de formateo. 1 "Este color es [colour=’FFFF0000’] AZUL, mientras que [colour=’

FF00FF00’] este es ROJO [colour=’FF0000FF’] y este VERDE!" 2 3 "El tipo de letra puede [font=’Batang-26’]cambiar de un momento a

otro, [font=’fkp-16’]y sin previo aviso!" 4 5 "Si pulsas aqui [image-size=’w:40 h:55’][image=’set:TaharezLook

image:CloseButtonNormal’] no pasara nada :(" 6 7 "[font=’Batang-26’] Soy GRANDE,

[font=’DejaVuSans-10’][vertalignment=’top’] puedo ir arriba, [vert-alignment=’bottom’]o abajo, [vert-alignment=’centre’]al centro..."

8 9 "En un lugar de la [padding=’l:20 t:15 r:20 b:15’]Mancha[padding=’l

:0 t:0 r:0 b:0’], de cuyo nombre no quiero acordarme, no ha mucho..."

La primera cadena (línea 1) utiliza las etiquetas del tipo colour para cambiar el color del texto escrito a partir de ella. Se utilizan los colores rojo, verde y azul, en ese orden. La segunda (línea 3) muestra cómo se pueden utilizar las etiquetas para cambiar totalmente el tipo de fuente, siempre y cuando estén definidos los recursos .font y estos estén reflejados dentro el .scheme. La tercera (línea 5) muestra una imagen insertada en medio del texto, y además redimensionada. Para ello se utiliza la etiqueta de redimensionado para cambiar el tamaño a 40x55, y después inserta la imagen “CloseButtonNormal”, del conjunto “TaharezLook” La cuarta (línea 7) muestra una cadena con un texto (“Soy GRANDE”) de un tipo de fuente con un tamaño 30, y el resto con un tamaño 10. Para el resto del texto, sobra espacio vertical, por lo que se utiliza la etiqueta vertical-alignment para indicar dónde posicionarlo. Por último, la quinta cadena (línea 9), utiliza padding para la palabra “Mancha”. A esta palabra se le reserva un margen izquierdo y derecho de 20 píxeles, y un superior e inferior de 15.

7.11.

Características avanzadas

CEGUI es una biblioteca muy potente y flexible que puede ser utilizada junto a muchas otras para crear efectos visualmente muy impactantes. Algunas características avanzadas que se han implementado son efectos de ventanas, como transparencia y aspecto gelatinoso, o incluso incrustar un navegador dentro de una ventana. Para aprender estas características y más, en su página existen muchos manuales, y dispone de una muy buena documentación [2].

Capítulo

8

Plataformas Móviles Miguel García Corchero

Motores de videojuego Existen otros motores de videojuegos más utilizados en la industria como CryEngine o Unreal Engine y tienen más funcionalidades que Unity3D pero también es más complejo trabajar con ellos.

U

n motor de videojuegos es un termino que hace referencia a una serie de herramientas que permiten el diseño, la creación y la representación de un videojuego. La funcionalidad básica de un motor es proveer al videojuego renderización, gestión de físicas, colisiones, scripting, animación, administración de memoria o gestión del sonidos entre otras cosas. En este capítulo se trata el caso específico del motor de videojuegos Unity3D y se realizará un repaso superficial por la forma de trabajar con un motor de videojuegos mientras se realiza un videjuego de ejemplo para dispositivos móviles con el sistema operativo iOS o Android. El videojuego será un shoot’em up de aviones con vista cenital.

8.1.

Método de trabajo con un motor de videojuegos

8.1.1. Generación de contenido externo al motor Diseño del videojuego: Esta fase suele hacerse con papel y boli. En ella definiremos las mecánicas necesarias a implementar, haremos bocetos de los personajes o situaciones implicadas y creamos listas de tareas a realizar asignando diferentes prioridades. Figura 8.1: Visualización del modelo 3D del jugador.

Generación del material gráfico: El videojuego necesitará gráficos, texturas, fuentes, animaciones o sonidos. Este material se conoce como assets. Podemos utilizar diferentes programas de 291

[292]

CAPÍTULO 8. PLATAFORMAS MÓVILES

modelado y texturizado 3D o 2D para esta tarea, ya que todos los assets son exportados a un formato de entrada de los que reconoce el motor gráfico.

8.1.2. Generación de contenido interno al motor Escritura de scripts: La escritura de scripts se realiza con un editor de texto externo a las herramientas del motor gráfico pero se considera contenido íntimamente relacionado del motor de videojuego. Escritura de shaders: Los shaders también se escriben con un editor externo. Importación de assets: Uno de los pasos iniciales dentro del entorno integrado de Unity3D es añadir al proyecto todo el material generado anteriormente y ajustar sus atributos; como formatos, tamaños de textura, ajuste de propiedades, calculo de normales, etc.

Scripts Los scripts que utilizamos se pueden escribir en los lenguajes C#, Javascript o BOO.

Creación de escenas: Crearemos una escena por cada nivel o conjunto de menús del videojuego. En la escena estableceremos relaciones entre objetos y crearemos instancias de ellos. Creación de prefabs: Los prefabs son agrupaciones de objetos que se salvan como un objeto con entidad propia. Optimización de la escena: Uno de los pasos fundamentales se lleva a cabo al final del desarrollo de la escena y es la optimización. Para ello emplearemos técnicas de lightmapping y occlusion culling con las herramientas del entorno.

Con Unity3D no tenemos que preocuparnos de la gestión de las físicas, colisiones, renderización o controles a bajo nivel. Nos dedicamos únicamente a la programación de scripts y shaders.

8.2.

Creación de escenas

Una escena está constituida por instancias de objetos de nuestros assets y las relaciones entre ellos. Podemos considerar una escena como la serialización de el objeto escena. Este objeto contiene jerárquicamente otros objetos que son almacenados cuando se produce esa serialización, para posteriormente cargar la escena con todas esas instancias que contendrán los mismos valores que cuando fueron almacenados. Hay dos enfoques diferentes a la hora de crear escenas:

Figura 8.2: Visualización de un shader de normal mapping.

8.2. Creación de escenas

[293]

Figura 8.3: En nuestro ejemplo se han utilizado capturas de pantalla de google map para obtener texturas de terreno y se han mapeado sobre un plano en Blender. Posteriormente se ha utilizado el modo scuplt para dar relieve al terreno y generar un escenario tridimensional.

[294]

CAPÍTULO 8. PLATAFORMAS MÓVILES

Figura 8.4: Interface de Unity3D. Dividida en las vistas más utilizadas: Jerarquía de escena, Assets del proyecto, Vista del videojuego, Vista de escena y Vista de propiedades del asset seleccionado.

8.2. Creación de escenas

[295]

Figura 8.6: Para la escena de nuestro ejemplo hemos añadido el modelo 3D del escenario, los enemigos, el jugador y hemos establecido las relaciones de jerarquía necesarias entre estos elementos.

1. Una escena por cada nivel del juego: Utilizaremos este enfoque cuando cada nivel tenga elementos diferentes. Podrán repetirse elementos de otros niveles, pero trataremos que estos elementos sean prefabs para que si los modificamos en alguna escena, el cambio se produzca en todas. 2. Una única escena con elementos modificados dinámicamente: Puede que en nuestro videojuego todos los niveles tengan el mismo tipo de elementos pero lo diferente sea la dificultad o el número de enemigos, en este caso podemos crear una única escena pero variar sus condiciones dinámicamente en función de en que nivel estemos. Figura 8.5: Visualización de la jerarquía de assets de nuestro proyecto.

Como las escenas pueden cargarse desde otra escena. Podemos realizar un cambio de escena cuando se ha llegado al final de un determinado nivel por ejemplo. Este cambio de escena mantendrá en memoria los elementos comunes como texturas o modelos 3D o soni-

[296]

CAPÍTULO 8. PLATAFORMAS MÓVILES

Figura 8.7: El nodo Camera contiene otros nodos de manera jerárquica.

dos que pertenezcan a los dos escenas, la escena que se descarga y la escena que se carga, por lo que dependiendo del caso esta carga suele ser bastante rápida. También podemos realizar los menús en una escena y desde ahí cargar la escena del primer nivel del juego.

8.3.

Creación de prefabs

Como se ha descrito en el apartado anterior, cada escena contiene instancias de objetos de nuestros Assets. Cada uno de los objetos de nuestra escena es un nodo, y cada nodo puede contener jerárquicamente a otros nodos. Podemos agrupar esa jerarquía y darle un nombre propio para después serializarla e instanciarla en el futuro. A ese concepto se le conoce con el nombre de prefab. Podemos crear tantos prefabs como queramos a partir de jerarquías de objetos de una escena y son una parte fundamental para entender el método de trabajo con un motor. En nuestra escena hemos creado prefabs para cada uno de los tipos de enemigos, y también hemos creado prefabs para el disparo, una explosión y un efecto de partículas de llamas.

8.4.

Uso de prefabs Cuando un elemento se repita en los diferentes niveles o en la misma escena debe de ser un prefab. De esta forma sólo se tiene una referencia de ese objeto y es óptimo en rendimiento y organización de assets.

Programación de scripts

Una script es un fichero de código que contiene instrucciones sobre el comportamiento de un determinado actor de nuestra escena. Podemos añadir uno o varios scipts a cada uno de los elementos de nuestra escena y además los scripts tienen la posibilidad de hacer referencia a estos objetos o scripts de otros objetos. En los scripts podemos utilizar las clases y API’s que nos proporciona el motor de videojuegos. Algunas de estas clases son:

Documentación Podemos consultar la documentación de cada una de las API’s para los tres lenguajes de scripting desde la página oficial de Unity3D

8.4. Programación de scripts

[297]

Figura 8.8: Prefabs de nuestro videojuego de ejemplo.

GameObject: Esta clase tiene información sobre el objeto. Todos los nodos de una escena son GameObjects. Transform: Esta clase representa la posición, rotación y escala de un elemento en el espacio tridimensional. AudioSource: Esta clase almacena un sonido y permite gestionar su reproducción. Texture 2D: Esta clase contiene una textura bidimensional. Los scripts tienen algunos métodos especiales que podemos implementar como: Figura 8.9: En nuestro modelo del helicóptero se ha separado la hélice del resto del modelo para poder añadirle este script de movimiento.

Update: Este método es invocado por el motor gráfico cada vez que el objeto va a ser renderizado. Start: Este método es invocado por el motor gráfico cuando se instancia el objeto que contiene a este script.

[298]

CAPÍTULO 8. PLATAFORMAS MÓVILES

8.4.1. Algunos scripts básicos Algunos de nuestros enemigos son helicópteros. Podemos añadir el siguiente script a el objeto de las hélices para que realice una rotación sobre su eje perpendicular.

Listado 8.1: HeliceHelicoptero.js 1 2 3 4 5 6 7 8

#pragma strict public var delta = 4.0; function Update () { //Rotar la helice en el eje y transform.Rotate(0,Time.deltaTime * delta,0); }

En nuestro escenario se han añadido nubes modeladas mediante planos y con una textura de una nube con transparencias. Para darle mayor realismo a este elemento se va a programar un script para mover las coordenadas u,v del mapeado de este plano provocando que la textura se mueve sobre el plano y simulando un movimiento de nubes.

Listado 8.2: Nube.js 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

#pragma strict public var delta = 0.1; public var moveFromLeftToRight : boolean = false; private var offset : float = 0.0; function Update () { //Mover la coordenada u o v de la textura de el material del objeto que contiene este script if (!moveFromLeftToRight) { renderer.material.SetTextureOffset ("_MainTex", Vector2( offset,0)); } else { renderer.material.SetTextureOffset ("_MainTex", Vector2(0, offset)); } offset+=Time.deltaTime * delta; if (offset>1.0) { offset-=1.0; } }

En los scripts se utiliza el valor de Time.deltaTime para interpolar el valor de otros elementos con respecto al tiempo que ha pasado desde el último frame renderizado. De esta forma el videojuego va igual de rápido en todas las máquinas, pero se visualizará de manera más fluida en máquinas más rápidas debido a que al renderizar mayor numero de frames por segundo se producirán más posiciones intermedias de cada uno de los valores que dependen de Time.deltaTime.

Figura 8.10: Visualización de las nubes.

8.4. Programación de scripts

[299]

8.4.2. Triggers Un trigger es una porción del espacio definida por un objeto geométrico como una caja o una esfera que utilizaremos para colocar sobre la escena y de esta forma saber cuando un determinado objeto entra o sale de una zona concreta. De esta forma podremos invocar diferentes comportamientos en ese momento. En nuestra escena utilizaremos un trigger para determinar cuando hemos llegado al enemigo final. Figura 8.11: Trigger de la zona final.

Listado 8.3: TriggerFinal.js 1 #pragma strict 2 3 function OnTriggerEnter (other : Collider) { 4 if (other.tag=="Player"){ 5 //Si entra un objeto dentro de el trigger y el objeto es el

jugador, pasarle el mensaje a ControlJuego de que hemos llegado a la parte final var ControlJuegoPointer : Transform = (GameObject. FindWithTag("ControlJuego")).transform; var ControlJuegoStatic : ControlJuego = ( ControlJuegoPointer.GetComponent("ControlJuego") as ControlJuego); ControlJuegoStatic.EntrarEnZonaFinal();

6 7

8 9 10 }

}

8.4.3. Invocación de métodos retardada A veces necesitaremos programar un evento para que pase trascurrido un determinado tiempo. En nuestro ejemplo esto ocurre con la explosión, que invocaremos su destrucción 5 segundos después de haberse instanciado. Variables públicas Las variables públicas nos permitirán modificar esos parámetros desde el interface de Unity3D cuando tengamos el objeto que contiene el script seleccionado.

Listado 8.4: DestruirPasadoUnTiempo.js 1 public var timeOut = 1.0; 2 3 function Start(){ 4 //Realizar una llamada al método destruir pasados los segundos

de timeOUT 5 Invoke ("Destruir", timeOut); 6 } 7 8 function Destruir(){ 9 //Destruir el objeto que contiene este script 10 DestroyObject (gameObject); 11 }

8.4.4. Comunicación entre diferentes scripts La mayoría de los scripts se comunicarán con otros scripts más complejos. Para ello hay que crear un puntero al objeto que contiene

[300]

CAPÍTULO 8. PLATAFORMAS MÓVILES

el script y utilizarlo para a su vez crear un puntero a la instancia de el script de ese objeto. Después, sobre el puntero de esa instancia de script, podremos invocar los métodos definidos en el mismo. En el siguiente script que controla el disparo se utiliza este procedimiento de comunicación para invocar un método de el script Sonidos, encargado de la reproducción de los sonidos y músicas. Sonido 3D Listado 8.5: Disparo.js 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

public var delta = 8.0; public var timeOut = 5.0; public var enemigo : boolean; function Start() { //Invocar PlaySonidoDisparo del script Sonidos del objeto Sonidos var SonidosPointer : Transform = (GameObject.FindWithTag(" Sonidos")).transform; var SonidosStatic : Sonidos = (SonidosPointer.GetComponent(" Sonidos") as Sonidos); SonidosStatic.PlaySonidoDisparo(); Invoke ("Destruir", timeOut); } function Update () { //Actualizar la posición del disparo if (enemigo){ transform.position.z-=Time.deltaTime * delta*0.85; } else { transform.position.z+=Time.deltaTime * delta; } } function OnCollisionEnter(collision : Collision) { Destruir(); } function Destruir() { DestroyObject (gameObject); }

Listado 8.6: Sonidos.js 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#pragma strict var var var var var var

SonidoDisparo : AudioSource; SonidoExplosionAire : AudioSource; SonidoExplosionSuelo : AudioSource; SonidoVuelo : AudioSource; MusicaJuego : AudioSource; MusicaFinal : AudioSource;

//Realizamos una fachada para que los demás objetos invoquen la reproducción de sonidos o música function PlaySonidoExplosionSuelo(){ SonidoExplosionSuelo.Play(); } function PlaySonidoExplosionAire(){ SonidoExplosionAire.Play(); }

Es posible reproducir sonido en una posición del espacio para que el motor de juego calcule la atenuación, reberberación o efecto doppler del mismo.

8.4. Programación de scripts

[301]

19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

function PlaySonidoDisparo(){ SonidoDisparo.Play(); } function PlayMusicaJuego(){ MusicaJuego.Play(); } function StopMusicaJuego(){ MusicaJuego.Stop(); } function PlayMusicaFinal(){ MusicaFinal.Play(); } function StopMusicaFinal(){ MusicaFinal.Stop(); } function PlaySonidoVuelo(){ SonidoVuelo.Play(); }

Autómatas finitos La gran mayoría de comportamientos de los actores de un videojuego pueden ser modelados como un autómata finito determinista.

8.4.5. Control del flujo general de la partida Normalmente se suele utilizar un script que controla el flujo general de la partida. Este script se utiliza como nexo de unión entre el resto de los scripts y se le pasarán mensajes por ejemplo cuando ha terminado la partida. Podemos modelar el comportamiento de este script como si de un autómata se tratara.

Límite de FPS En dispositivos móviles el limite de frames por segundo está ajustado por defecto a 30 FPS pero podemos cambiarlo modificando el atributo Application.targetFrameRate.

Listado 8.7: ControlJuego.js 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

#pragma strict public public public public public

var var var var var

velocidadCamara :float = 2.0; enZonaFinal : boolean = false; Camara : Transform; ScoreGUI : GUIText; LifeGUI : GUIText;

public var BotonIZ : GUITexture; public var BotonDE : GUITexture; public var BotonDISPARO : GUITexture; public var FondoFinal : GUITexture; public var TexturaFinalBien : Texture2D; public var TexturaFinalMal : Texture2D; private var SonidosStatic : Sonidos; private var Score : int; function Awake(){ //Hacemos que el juego corra a 60 FPS como máximo Application.targetFrameRate = 60; } function Start(){

[302]

CAPÍTULO 8. PLATAFORMAS MÓVILES

//Obtenemos el puntero a Sonidos y ajustamos algunos valores iniciales var SonidosPointer : Transform = (GameObject.FindWithTag(" Sonidos")).transform; SonidosStatic = (SonidosPointer.GetComponent("Sonidos") as Sonidos); SonidosStatic.PlayMusicaJuego(); SonidosStatic.PlaySonidoVuelo(); ScoreGUI.text="Score : "+Score;

26 27 28

29 30 31 32 } 33 34 function Update () { 35 if (enZonaFinal && velocidadCamara>0.0){ 36 //Si estamos en la zona final paramos el movimiento de 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68

manera gradual velocidadCamara*=0.95; if (velocidadCamara0.0){ //Movemos la cámara en su componente z para hacer scroll Camara.position.z+=Time.deltaTime * velocidadCamara; } } function EntrarEnZonaFinal(){ //Se ha entrado en el trigger de la zona final enZonaFinal=true; SonidosStatic.StopMusicaJuego(); SonidosStatic.PlayMusicaFinal(); } function FinDeJuegoGanando(){ //Fin de partida cuando hemos completado la misión FondoFinal.texture = TexturaFinalBien; Restart(); } function FinDeJuegoPerdiendo(){ //Fin de partida cuando hemos fallado la misión FondoFinal.texture = TexturaFinalMal; Restart(); }

function AddScore(valor : int){ //Añadimos puntos, por lo que hay que hacer la suma y actualizar el texto 69 Score+=valor; 70 ScoreGUI.text="Score : "+Score; 71 } 72 73 function Restart(){ 74 //Ocultamos los textos y botones 75 LifeGUI.enabled=false; 76 ScoreGUI.enabled=false; 77 BotonDISPARO.enabled=false; 78 BotonIZ.enabled=false; 79 BotonDE.enabled=false; 80 FondoFinal.enabled=true; 81 82 //Esperamos 5 segundos y hacemos un reload de la escena 83 yield WaitForSeconds (5); 84 Application.LoadLevel(Application.loadedLevel); 85 }

8.4. Programación de scripts

[303]

Figura 8.12: Diagrama de control de juego.

Retardos Utilizaremos la instrucción WaitForSeconds para introducir retardos en los scripts.

8.4.6. Programación de enemigos Vamos a tener un único script para definir el comportamiento de todos los enemigos, incluidos el enemigo final. En este script vamos a definir una serie de atributos públicos que después ajustaremos con unos valores específicos para cada uno de los prefabs de enemigos. Cada enemigo vendrá determinado un rango de disparo y un tiempo de recarga, y modificando estos parámetros crearemos enemigos más peligrosos que otros. Estos valores influirán en el calculo de puntuación que proporciona ese enemigo concreto al ser destruido.

Detección de colisiones Cuando un objeto tridimensional tiene añadidos los elementos collider y rigidbody permite detectar colisiones mediante el método OnCollisionEnter.

Listado 8.8: Enemigo.js 1 2 3 4 5 6 7 8 9 10

#pragma strict public public public public public public public

var var var var var var var

explosionPrefab : Transform; llamasPrefab : Transform; disparoPrefab : Transform; player : Transform; rangoDisparo : float; tiempoRecarga = 0.5; jefeFinal : boolean = false;

[304]

11 12 13 14 15 16 17 18 19 20

21 22 23 24 25 26 27 28

CAPÍTULO 8. PLATAFORMAS MÓVILES

private var siguienteTiempoDisparo = 0.0; private var enRangoDisparo : boolean=true; private var llamasInstancia : Transform; private var cantidadRotationCaida : Vector3 = Vector3(0,0,0); function Update () { if (transform.gameObject.rigidbody.useGravity){ //Si el enemigo está callendo, el avión rota sobre sus ejes porque entra en barrena transform.Rotate(Time.deltaTime * cantidadRotationCaida.x, Time.deltaTime * cantidadRotationCaida.y,Time.deltaTime * cantidadRotationCaida.z); } else { if (player!=null){ var distancia : float = transform.position.z-player. position.z; if (distancia0) { //Si estamos en rango de disparo el avión dispara al frente if (Time.time > siguienteTiempoDisparo){ siguienteTiempoDisparo = Time.time + tiempoRecarga; Instantiate(disparoPrefab, transform.position, Quaternion.identity); } } } } }

29 30 31 32 33 34 35 function OnCollisionEnter(collision : Collision) { 36 //Determinar posición y rotación del punto de contacto de la 37 38 39 40 41 42 43 44 45 46 47

48 49 50 51 52 53 54 55 56 57 58

colisión var contact : ContactPoint = collision.contacts[0]; var rot : Quaternion = Quaternion.FromToRotation(Vector3.up, contact.normal); var pos : Vector3 = contact.point; var SonidosPointer : Transform = (GameObject.FindWithTag(" Sonidos")).transform; var SonidosStatic : Sonidos = (SonidosPointer.GetComponent(" Sonidos") as Sonidos); if (transform.gameObject.rigidbody.useGravity || collision. collider.tag=="Player"){ //Si estamos callendo y hemos vuelto a colisionar entonces explota var ControlJuegoPointer : Transform = (GameObject. FindWithTag("ControlJuego")).transform; var ControlJuegoStatic : ControlJuego = ( ControlJuegoPointer.GetComponent("ControlJuego") as ControlJuego); SonidosStatic.PlaySonidoExplosionSuelo(); //Instanciamos la explosión final en la posición del impacto Instantiate(explosionPrefab, pos, rot); if (llamasInstancia!=null){ Destroy (llamasInstancia.gameObject); } if (jefeFinal) { ControlJuegoStatic.AddScore(500);

8.4. Programación de scripts

[305]

ControlJuegoStatic.FinDeJuegoGanando(); } else { var cantidadScore : float = (rangoDisparo * (1.0/ tiempoRecarga))*5; ControlJuegoStatic.AddScore(cantidadScore); }

59 60 61 62 63 64 65 66 67 68

//Eliminamos el objeto enemigo Destroy (transform.gameObject); } else if (collision.collider.tag=="Disparo"){ //Si no estamos callendo y hemos sido tocados por un disparo, empezamos a caer y a arder SonidosStatic.PlaySonidoExplosionAire();

69 70 71

//Instanciamos llamas para la posición del impacto y las añadimos jerárquicamente al enemigo llamasInstancia=Instantiate(llamasPrefab, transform. position, Quaternion.identity); llamasInstancia.parent = transform;

72 73 74 75 76 77 78

//Activamos la gravedad del rigidBody del objeto transform.gameObject.rigidbody.useGravity=true;

79 80 81 82 83 }

//Calculamos la cantidad de movimiento en caída para los ejes de manera aleatoria cantidadRotationCaida.x=Random.Range(0, 20.0); cantidadRotationCaida.y=Random.Range(0, 20.0); cantidadRotationCaida.z=Random.Range(0, 20.0); }

8.4.7. Programación del control del jugador El jugador controlará su avión con los botones: izquierda, derecha y disparo. Además hay que tener en cuenta que cuando el jugador colisiona con un disparo enemigo o un enemigo debe reducir su vida, y cuando esta llega a cero explotar. Teclas de control Aunque el juego final se controle mediante botones virtuales dibujados sobre la pantalla táctil del dispositivo, también permitiremos su control con un teclado para cuando probemos el juego en el emulador integrado en Unity3D.

Listado 8.9: Player.js 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#pragma strict public public public public public public public public public public public private private private private private

var var var var var var var var var var var

explosionPrefab : Transform; disparoPrefab : Transform; posicionDisparoIZ : Transform; posicionDisparoDE : Transform; tiempoRecarga = 0.5; cantidadMovimiento = 0.1; camara : Transform; vida : int = 5; LifeGUI : GUIText; topeIZ : Transform; topeDE : Transform;

var var var var var

siguienteTiempoDisparo = 0.0; anteriorDisparoIZ : boolean = false; botonIzquierda : boolean = false; botonDerecha : boolean = false; botonDisparo : boolean = false;

[306]

CAPÍTULO 8. PLATAFORMAS MÓVILES

21 function Start(){ 22 //Inicializamos el marcador de vida con el valor de vida

inicial 23 LifeGUI.text="Life : "+vida; 24 } 25 26 function Update() { 27 if ((botonDisparo || Input.GetButton("Fire1")) && Time.time >

siguienteTiempoDisparo){ //Si hay que disparar, instanciamos prefabs de disparo en las posiciones alternativamente izquierda y derecha de el avión del jugador siguienteTiempoDisparo = Time.time + tiempoRecarga; if (anteriorDisparoIZ){ Instantiate(disparoPrefab, posicionDisparoDE.position, posicionDisparoDE.rotation); } else { Instantiate(disparoPrefab, posicionDisparoIZ.position, posicionDisparoIZ.rotation); } anteriorDisparoIZ=!anteriorDisparoIZ;

28

29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

} if (botonIzquierda || Input.GetButton("Left")){ //Si hay moverse a la izquierda se actualiza la posición del jugador //También se mueve un poco la cámara para simular un poco de efecto parallax if (transform.position.x>topeIZ.position.x) { transform.position.x-= Time.deltaTime * cantidadMovimiento; camara.position.x-= Time.deltaTime * cantidadMovimiento /2; } } else if (botonDerecha || Input.GetButton("Right")) { //Si hay moverse a la derecha se actualiza la posición del jugador //También se mueve un poco la cámara para simular un poco de efecto parallax if (transform.position.x