1 Arquitectura de VideojuegosSeminario de Técnologías Interactivas y Videojuegos Edición 2008 Arquitectura de Videojuegos Rudi Lausarot, Manuel Martínez, Vosky Clavijo. Facultad de Ingenieria - Computacion Grafica Avanzada - Aceleracion del Rendering

2 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoContenido Introducción Historia Third’s Parties Del Análisis al Diseño Diseño Jerárquico/OO Diseño orientado a Componentes Conclusión Bibliografía Facultad De Ingeniería – SVTI – Arquitectura y Diseño

3 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoIntroducción (1/2)‏ ¿Qué es la Arquitectura de un software? La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación ente ellos. Motivación en los videojuegos Los videojuegos son un software. Una buena arquitetura/diseño permite: Reusabilidad Extensibilidad Manejable Facultad De Ingeniería – SVTI – Arquitectura y Diseño

4 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoIntroducción (2/2)‏ Motivación en los videojuegos Acortar tiempos de producción -Los recursos no son gratis -El tiempo tampóco Cambios en los requerimientos. - Reusabilidad acorta el tiempo de cambio - Extensibilidad permite agregar requerimientos fácilmente. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

5 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoHistoria (1/3)‏ Desarrollo en el pasado Código de máquina y Assembler -Requerimientos no complejos. (comparados con los actuales)‏ -Hardware disponible muy limitado -Era común la frase “write to the metal”. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

6 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoHistoria (2/3)‏ Cambio Uso del lenguaje “C” -Doom casi completamente escrito en C . -Reacción inmediata de la comunidad de programdores. -Escepticismo. Preconceptos entre los programadores de videojuegos “Yo lo puedo hacer mejor” “Necesito saber cómo está hecho” Reinvención de la rueda. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

7 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoHistoria (3/3)‏ Pero en la actualidad Productos hechos por terceros escenciales Half Life: Modificación del motor del quake Reutilización y cambios para satifacer nuevas necesidades Ahorro de 12 meses de producción Facultad De Ingeniería – SVTI – Arquitectura y Diseño

8 Third Party components

9 Third Party components (1/2)Motor 3D Quake Motor Físico Rigid body dynamics ¿Todos? Soft body dynamics Unreal Tournament III Facultad De Ingeniería – SVTI – Arquitectura y Diseño

10 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoNotas Motor 3D: Un motor realtime 3D se encarga de varias cosas, por ejemplo: Renderización, iluminación, etcétera. También de mantener una descripción de la escena, con los distintos entidades que la forman, su estado, y las relaciones entre distintas entidades. Es lo que se denomina scenegraph, y puede ser que tengamos incluso distintos scenegraphs para determinadas tareas. Al scenegraph se le piden "nodos" que podremos modificar, y después el motor se encargara de pintar correctamente. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

11 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoNotas Queremos destacar 2 cosas. Una primera es definir correctamente la descripción de la escena, y para ello normalmente se utilizan exportadores y plugins para programas 3D comerciales, como 3dsmax, XSI, o maya. Estos programas nos van a dar una cantidad de información enorme: geometría, materiales, los huesos de la animación, todo tipo de propiedades que deseemos agregar al objeto, etc. Nosotros tenemos que decidir qué vamos a implementar, como vamos a permitir editarlo en el software 3d, y tendremos que pensar la mejor forma de exportar esa información a nuestra definición de escena. Este capítulo no es en sí nada trivial. La segunda es que: Muchos de los grandes errores de un diseño del motor vienen de no pensar adecuadamente dónde almacenar los datos. Por eso lo ideal es que al principio diseñemos una forma flexible de modificar este fichero. Una idea para conocer cual es la mejor forma de almacenar los datos es investigar varios programas de 3D (maya,XSI y 3dsmax al menos), y ver qué datos se almacenan en los objetos. Este tipo de investigaciones nos van a servir de mucho posteriormente, ya que tendremos claros los requisitos posteriores del motor. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

12 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoNotas physics engine is a computer program that simulates Newtonian physics models, using variables such as mass, velocity, friction and wind resistance. It can simulate and predict effects under different conditions that would approximate what happens in real life or in a fantasy world. Its main uses are in scientific simulation and in video games. In physics, rigid body dynamics is the study of the motion of rigid bodies. Unlike particles, which move only in three degrees of freedom (translation in three directions), rigid bodies occupy space and have geometrical properties, such as a center of mass, moments of inertia, etc., that characterize motion in six degrees of freedom (translation in three directions plus rotation in three directions). Rigid bodies are also characterized as being non-deformable. As such, rigid body dynamics is used heavily in analyses and computer simulations of physical systems and machinery where rotational motion is important, but material deformation does not have a major effect on the motion of the system. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

13 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoNotas Soft body dynamics is an area of physics simulation software that focuses on accurate simulation of a flexible object. That is, the object is deformable, meaning that the relative positions of points of the objects can change. There are many dynamic forces that have direct influence on an object's behavior (friction, gravity, collisions, springs, wind, etc.), and using soft body dynamics creates a believable illusion of the object. Soft bodies include: clothes, hair, and water. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

14 Third Party components (2/2)Librerías (sonido, IA, etc.) OpenAL Doom 3, Jedi Knight II, Quake 4, Prey, Tremulous, etc. Manejadores de inputs (abstracción de entrada de controles) lg3d-wii, sdl (windows, Mac OS, Linux, consolas) Motor de Juego (son “casi” todos los puntos anteriores juntos). Facultad De Ingeniería – SVTI – Arquitectura y Diseño

15 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoNotas lg3d-wii The goal of this project is to create a (user-space) Linux event driver for the Nintendo Wiimote so that it can be used as a standard JInput device with Project Looking Glass and Project Wonderland. There is also a plan to write a Java library with bindings (using JNI) to a low-level C library that can talk to the Wiimote. The (user-space) Linux event driver is currently working. It is written using the libwiimote library. Much of this functionality was implemented by looking at the Cwiid and the WMD projects. The main functionality it adds if force-feedback and speaker (for system beep only) support. A game engine is a software system designed for the creation and development of computer and video games. Game engines play a role akin to a "Game Construction Set". There are many game engines that are designed to work on video game consoles and desktop operating systems such as Linux, Mac OS X, and Microsoft Windows. The core functionality typically provided by a game engine includes a rendering engine (“renderer”) for 2D or 3D graphics, a physics engine or collision detection (and collision response), sound, scripting, animation, artificial intelligence, networking, streaming, memory management, threading, and a scene graph. The process of game development is frequently economized by in large part reusing the same game engine to create different games. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

16 Del Análisis al Diseño

17 Del Análisis al Diseño (1/21)TOKENS* Elementos comunes en juegos Todos los juegos tienen elementos discretos en común o directamente manipulados por el jugador. A estos elementos les llamaremos TOKENS. Para explicar como usar y en que pueden ayudarnos a diseñar juegos estos TOKENS, nos basaremos en dos casos de estudio. Pong y Pac-Man *Usamos tokens y no objetos porque cuando pensamos en objetos como en C, tratamos de llevar todo a clases, hay un mapeo mental de objetos en clases, la tokenizacion es una etapa intermedia en el desarrollo de una arquitectura descendente. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

18 Del Análisis al Diseño (2/21)PONG Pong tiene 2 jugadores una pelota y algunas paredes, ¿cuáles de estos elementos son tokens? Conceptualmente todos son tokens, cada jugador controla un bat y si conquista un gol mejorará su score. De esta manera, podemos decir que el jugador tiene un bat y un score, éstos son subtokens representando el jugador, la pelota es otro token. Las paredes son otro token, y previenen que la pelota se escape de la parte superior e inferior de la pantalla. ¿Qué pasa con las áreas de gol? Cuando la pelota llega ahí, se conquista un gol, y el juego comienza de nuevo, por esto son también tokens aunque no tengan una representación visual. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

19 Del Análisis al Diseño (3/21)Tokens jerárquicos de PONG Facultad De Ingeniería – SVTI – Arquitectura y Diseño

20 Del Análisis al Diseño (4/21)Tokenización Identificamos los tokens del juego Interacciones (eventos) Definimos las interacciones posibles entre los tokens Matriz de interacciones Ahora que tenemos los tokens, podemos definir las interacciones entre los mismos, para ello podemos usar como herramienta la matriz de interacciones. Esta muestra para cada par de tokens como interactúan. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

21 Del Análisis al Diseño (5/21)Matriz de interaccion de PONG La matriz es simétrica porque el comportamiento es el mismo independientemente del orden de interacción de los tokens. Esta matriz nos permite revisar visualmente las interacciones, podemos chequear que son lo que nosotros esperamos, y podemos ver si nos olvidamos de alguna o cometimos algún error. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

22 Del Análisis al Diseño (6/21)Token Game world Cadena de mensajes enviada cuando ocurre un gol Podría llegar a ser necesario tener un token game word, que se entere de cuando por ejemplo ocurre un gol, esto evitaría que cada token en el juego tenga que estar conectado precisamente para manejar los eventos ocurridos. En juegos sencillos esto puede no ser necesario, pero ya en juegos más complejos esto facilita mucho la tarea, quitando bastante complejidad y hace que sea más fácil agregar o quitar tokens. Otra razón, es filtrar la información que un token necesita saber. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

23 Del Análisis al Diseño (7/21)Facultad De Ingeniería – SVTI – Arquitectura y Diseño

24 Del Análisis al Diseño (8/21)Simplificacion de Tokenización de PACMAN Algunos eventos no fueron incluidos para hacer más sencillo el diagrama, después se van a ver algunas modificaciones. Por ejemplo, el más importante de los eventos fue el de resurreccion, cuando un fantasma comido va a la base, éste es resucitado. Una vez que resucita se queda ahí por un pequeño tiempo y sale de nuevo al laberinto. La puerta de la base es otro ítem que no incluimos, la cual permite entrar y salir a los fantasmas pero no al pacman. Debido a la complejidad que se generaría de considerar estos casos en la matriz de interacciones utilizamos otra. Esto lo podemos modelar con otro diagrama, una máquina finita de estados. Pacman está en el limite de la utilidad de la matriz de interacciones. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

25 Del Análisis al Diseño (9/21)Máquina de estados para los fantasmas En el diagrama de estados sólo se incluyen eventos entrantes, no disparados por los fantasmas. Ejemplo, si el fantasma es comido se dispara un evento score. Hay 3 cuadros indicando: cazador, cazado y comido. Explicar esos estados. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

26 Del Análisis al Diseño (10/21)Máquina de estados para el PacMan Este diagrama es similar al anterior, salvo que la cantidad de resurrecciones es limitada Muchos de los eventos que ocurren en este diagrama son manejados por el TOKEN GAME WORLD Facultad De Ingeniería – SVTI – Arquitectura y Diseño

27 Del Análisis al Diseño (11/21)¿¡Balls!? Máquina de estado Hot Ball Explicar diagrama Facultad De Ingeniería – SVTI – Arquitectura y Diseño

28 Del Análisis al Diseño (12/21)Máquina de estado SnowBall Explicar diagrama y plantear el problema de que pasa si se dan 3 interacciones simultaneas. Manejar todas las ocurrencias requiere de considerar muchos casos especiales en el codigo y ordenarlos por prioridad. No es muy practico. No hay mucho problema si no se van a agregar nuevos tokens durante el disenio del juego. Pero por ejemplo supongamos que queremos agregar que cuando inteactua una hotball con una baloon bal se transforme en una bola amalgama??? Facultad De Ingeniería – SVTI – Arquitectura y Diseño

29 Del Análisis al Diseño (13/21)Ahora podemos, por ejemplo, definir una bola caliente como una de metal con la propiedad caliente, cuando es enfriada se transforma en una de metal, y cuando está en la transición se exhibe sin propiedad, indicada por ninguna. Propiedades Caliente, templado, frío Facultad De Ingeniería – SVTI – Arquitectura y Diseño

30 Del Análisis al Diseño (14/21)Por ejemplo, se pueden agregar más propiedades como por ejemplo luz, entonces la bola tendrá temperatura y luz. Propiedades Caliente, templado, frío Facultad De Ingeniería – SVTI – Arquitectura y Diseño

31 Del Análisis al Diseño (15/21)Propiedades Se agrega la propiedad Luz Facultad De Ingeniería – SVTI – Arquitectura y Diseño

32 Del Análisis al Diseño (16/21)Interacciones (eventos) Definimos las interacciones posibles entre los tokens Hasta ahora tenemos: Matriz de interacciones, eventos, estados, propiedades. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

33 Del Análisis al Diseño (17/21)Definimos: PacMan: Hambriento Fantasmas: Fuertes cazando Débiles cazados Ninguno, cuando son comidos Bolitas, Frutas, Pildora: Comestible Paredes laberinto: Sólidas Base: Sólida, Hogar Facultad De Ingeniería – SVTI – Arquitectura y Diseño

34 Del Análisis al Diseño (18/21)Eventos A: Power-up B: Collision C: Muere Pac-Man D: Incremento Score E: Fantasma es comido F: Timer Reset Facultad De Ingeniería – SVTI – Arquitectura y Diseño

35 Del Análisis al Diseño (19/21)Matriz interacción Token/Property Esta tabla no se puede usar para tener una vista completa del juego pero permite tener una abstracción muy buena del comportamiento general. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

36 Del Análisis al Diseño (20/21)Matriz Property/Property No se pueden usar las matrices aisladamente, deben usarse conjuntamente. Tienen que ser vistas como un camino hacia un diseño más detallado. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

37 Diseño Jerárquico/OO

38 Descompocición Jerarquica (1/3)Jerárquica basado en entidades Es posible trabajar de esta forma en todo el marco de trabajo. Es normal que sólo se toman como entidades aquéllas que pueden ser actualizadas (depende del juego, tipo de juego). De esta forma se logran otras ventajas: Sólo se salva el estado de éstas. En las actualizaciones tienen prioridad Facultad De Ingeniería – SVTI – Arquitectura y Diseño

39 Descompocición Jerarquica (2/3)Jerárquico basado en entidades Profunda jerarquía de clases para representar entidades de juego Una entidad es un objeto del juego que tiene distintas propiedades El acercamiento es organizar los objetos del juego según sus propiedades y crear una típica jerarquía de objetos partiendo de un objeto abstracto o casi sin propiedades. “Entity”, “Actor”. Ene Feb Mar Abr May Jun Jul Ago Sep Oct Nov Dic Facultad De Ingeniería – SVTI – Arquitectura y Diseño

40 Descompocición Jerárquica (2/3)Ejemplo Facultad De Ingeniería – SVTI – Arquitectura y Diseño

41 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoData Driven (1/3) Modelo orientado por lo datos Indistinto del tipo de diseño usado En lo posible el estado del sistema determinado por datos y no por código. Por ejemplo un archivo de datos por “Entity” con sus propiedades Para entidades con comportamiento dinámico se usa scripting (por ejemplo LUA). Facultad De Ingeniería – SVTI – Arquitectura y Diseño

42 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoData Driven (2/3) Ventajas de Data Driven Testeos durante desarrollo, rápidos y eficaces. Cambios en los requerimientos del juego más fáciles de implementar Cambiar un auto porun robot gigante que lanza misiles Datos, (velocidad, apariencia, sonidos, relaciones, etcétera)‏ Cambios posibles de realizar teóricamente en cualquier momento. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

43 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoData Driven (3/3) Desventajas de Data Driven Seguridad El diseño debe contemplarlo (hay que pensarlo)‏ En el caso del scripting no debe ser usado para tareas de alta demanda, sólo para actualizaciones no constantes (bajo rate)‏ Facultad De Ingeniería – SVTI – Arquitectura y Diseño

44 Model-View-Controller (1/4)Patrón de arquitectura que pretende separar la lógica de la aplicación de su representación ante el usuario y la comunciación al modelo. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

45 Model-View-Controller (2/4)Aplicación en videojuegos Vista: Representación de las entidades del juego Gráficos, sonidos, eventos de interacción con el usuarios Lógica sobre éstos. Modelo: Datos propios de las entidades, posición, velocidad, atributo x. Lógica sobre éstos. Controller: Entradas que modifican el modelo. Inputs de usuarios, actualizaciones de estado del server. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

46 Model-View-Controller (3/4)Aplicación en videojuegos El modelo entonces mantiene la mínima cantidad de información (datos) necesarios (máquina de estado). La vista se encarga de la lógica de representación y de la representación propiamente dicha El controller se encargará de recibir las entradas de los usuarios y abstraerlas lógicamente para el modelo. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

47 Model-View-Controller (4/4)Beneficio inmediato y práctico. Actualización de estado en juegos multiplayer Cambio completos en la representación sin tocar ningún otro módulo (abstracción de motores). Cambios completos en el manejo de inputs sin afectar el resto. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

48 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoFrameWork FrameWork Un diseño básico reusable con funcionalidad de por sí. Extendible Mantenible Modificable Flexible/Acotador En Videojuegos Estructura básica con funcionalidad de la que facilmente se puede realizar un juego. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

49 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoEjemplo Práctico Facultad De Ingeniería – SVTI – Arquitectura y Diseño

50 Diseño orientado a Componentes

51 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoIntroducción (1/2) ¿Qué es el diseño orientado a componentes? Énfasis en división en componentes. ¿Qué es un componente? Objeto construido para una especificación. Criterios: múltiples usos, sin contexto específico, componible, encapsulado, independiente. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

52 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoIntroducción (2/2) ¿Por qué si utilizar componentes? Reutilizable Robustez Rapidez Fácil de mantener ¿Por qué no utilizar componentes? Difícil de comprender Facultad De Ingeniería – SVTI – Arquitectura y Diseño

53 POC en videojuegos

54 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoObjeto de Juego (1/3) También llamado entidad u objeto de escena. Ejemplo: Árbol, tanque, héroe, roca, secuencia de cámara, etc.. Acciones: Análisis sintáctico, animar, tocar audio, seguir un camino, persistir, etcétera. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

55 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoOJ como Jerarquía (2/3) Conjunto de objetos de juego representados mediante OO. Al agregar funcionalidades: Encapsular -> puede generar duplicación de código. Derivar -> puede incrementar peso en hojas. Objetos “BLOB”. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

56 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoOJ como Col. de Comp. (3/3) Otra forma de representar un objeto de juego. Mueven funcionalidades del objeto a componentes. Puede parecer más complejo que jerarquía. Más manejable y sencillo de mantener. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

57 Implementación

58 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoOJ (1/9) Objeto de Juego. Contiene: Transformación, identificador único, conjunto de componentes. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

59 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoOCJ (2/9) Objeto componente de juego. Especifica datos + comportamiento de funcionalidades específica. Ejemplo: Salud, representación gráfica, manejos de física, funciones IA, etcétera. Organizados en familias. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

60 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoOCJ - base (3/9) Objeto componente de juego base. Interfaz común a todo OCJ. Facilita manejo a OJ. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

61 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoManejo de OCJ en OJ (4/9) Necesitamos: Agregar, remover, obtener, limpiar. Más de un GOC de cada familia. Muestra demasiada información. Aumenta dependencias. Entonces -> no más de un GOC por familia. Solución contenedor de componente. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

62 Comunicación entre OCJ (5/9)No es ideal. Puede ser una necesidad. Resulta práctico. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

63 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoPlantillas OCJ (6/9) Impráctico inicialización de OCJ por OJ. Posible desperdicio de memoria. POCJ inicializa OCJ y amacena datos comunes. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

64 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoPlantillas OJ (7/9) Las POCJ simplifican pero se puede hacer +. Similar a POCJ pero para OJ. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

65 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoManejadores (8/9) Tanto para OCJ como para OJ. Centralizan manejo. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

66 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoData-Driven (9/9) Los componentes refuerzan la creación de objetos utilizando archivos de datos. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

67 De jerarquía OO a col. Comp.

68 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoPaso 1 (1/3) Entidad como objeto “BLOB” organizado. Dividir funcionalidades en subobjetos. Referenciar desde el padre a los subobjetos. Pro: Razonablemente poca funcionalidad. Poco tiempo. Contra: Sigue siendo “BLOB”. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

69 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoPaso 2 (2/3) Entidad como contenedor de componentes. Factorizar componentes para que compartan misma clase base. Pro: Necesidad de noción de objeto de juego como objeto concreto. Es posible transición a agregación pura. Contra: Todavía tenemos objeto raíz. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

70 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoPaso 3 (3/3) Entidad como una agregación pura de componentes. Objeto es la suma de sus partes. Entidad es colección de componentes. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

71 Caso : Neversoft

72 Tony Hawk’s Pro Skater (1/3)Contexto: 3 años de código. Un juego de la saga por año. Problema: Jerarquía objeto “BLOB”. Objetos sufren sobrepeso. Contienen información innecesaria. Duplicas de funcionalidad. Propuesta de solución. Transformar la jerarquía a componentes. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

73 Tony Hawk’s Pro Skater (2/3)Recepción de la propuesta: Resistencia programadores. Difícil de explicar la idea a gerentes. Ejecución de la propuesta: 2 años de reingeniería. Primero construcción de framework básico para componentes genéricos. Luego implementar aspectos del juego y mostrar a programadores. Resultados: Al comienzo poco visibles. Luego fácil implementación de nuevos objetos. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

74 Tony Hawk’s Pro Skater (3/3)Detalles de la implementación: Overhead de funciones virtuales. Compensado por simplificación de objetos. Necesidad de orden en lista de componentes. Necesidad de comunicación de componentes. Conclusiones: Buena decisión. Código más limpio y fácil de mantener. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

75 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoTony Hawk Facultad De Ingeniería – SVTI – Arquitectura y Diseño

76 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoConclusiones En el pasado poca importancia de la arquitectura debido bajos requerimientos. Con el incremento de los requerimientos la arquitectura comenzó a tomar mayor importancia. 3rd Parties imprescindibles el desarrollo actual AAA. Tokenización una buena forma de pasar de los requerimientos al diseño. Diseño Jerárquico modelo muy estandarizado y pulido Abstracción, modularización y Frameworks como principios básicos Diseño de componentes buena opción para desarrollos muy grandes. Tokenización y matrices son imprescindibles en el desarrollo de juegos, en el paso de los requerimientos al diseño. Hay que ir haciendo pasos incrementales y dividiendo el problema Facultad De Ingeniería – SVTI – Arquitectura y Diseño

77 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoReferencias Libro Game Architecture and Design. A new Edition (Rollins) 3D engines Phisics engines Manejadores de eventos https://lg3d-wii.dev.java.net/ Facultad De Ingeniería – SVTI – Arquitectura y Diseño

78 Facultad De Ingeniería – SVTI – Arquitectura y DiseñoReferencias Programación Game Programming Gems 6 -"Game Object Component System" - Chris Stoy - Mick West - Inheritance vs. Aggregation - Kyle Wilson - A Data-Driven Game Object System - Scott Bilas - Introduction to Dungeon Siege Architecture - Component based design resources Facultad De Ingeniería – SVTI – Arquitectura y Diseño