1 / 73

Arquitectura de Videojuegos

Arquitectura de Videojuegos. Seminario de Técnologías Interactivas y Videojuegos. Edición 2008. Rudi Lausarot, Manuel Martínez, Vosky Clavijo. Contenido. Introducción Historia Third’s Parties Del Análisis al Diseño Diseño Jerárquico/OO

nikkos
Download Presentation

Arquitectura de Videojuegos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Contenido • 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. Introducción (1/2)‏ • ¿Qué es la Arquitectura de un SW? • 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. Introducció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 facilmente. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  5. Historia (1/3)‏ • Desarrollo en el pasado • Código de maquina y Assembler -Requerimientos no complejos. (comparados a 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. Historia (2/3)‏ • Cambio • Uso del lenguaje “C” -Doom casi completamente escrito en C . -Reacción inmediata de la comunidad de programdores. -Esceptisismo. • Preconceptos entre los programadores de VJ. • “Yo lo puedo hacer mejor” • “Necesito saber como está hecho” • Reinvención de la rueda. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  7. Historia (3/3)‏ • Más 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 debido 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. 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

  11. Del Análisis al Diseño

  12. 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 Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  13. Del Análisis al Diseño (2/21) PONG Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  14. Del Análisis al Diseño (3/21) • Tokens jerarquicos de PONG Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  15. Del Análisis al Diseño (4/21) • Tokenizacion • Identificamos los tokens del juego • Interacciones (eventos) • Definimos las interacciones posibles entre los tokens • Matriz de interacciones Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  16. Del Análisis al Diseño (5/21) • Matriz de interaccion de PONG Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  17. Del Análisis al Diseño (6/21) • Token Game world • Cadena de mensajes enviada cuando ocurre un gol Facultad De Ingeniería – SVTI – Arquitectura y Diseño

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

  19. Del Análisis al Diseño (8/21) • Simplificacion de Tokenizacion de PAC-MAN Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  20. Del Análisis al Diseño (9/21) • Maquina de estados para los fantasmas Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  21. Del Análisis al Diseño (10/21) • Maquina de estados para el Pac-Man Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  22. Del Análisis al Diseño (11/21) • Balls! ? • Maquina de estado Hot Ball Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  23. Del Análisis al Diseño (12/21) • Maquina de estado SnowBall Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  24. Del Análisis al Diseño (13/21) • Propiedades • Caliente, templado, frio Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  25. Del Análisis al Diseño (14/21) • Propiedades • Caliente, templado, frio Facultad De Ingeniería – SVTI – Arquitectura y Diseño

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

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

  28. Del Análisis al Diseño (17/21) • Definimos: • Pac-Man:Hambriento • Fantasmas: • Fuertes cazando • Debiles cazados • Ninguno, cuando son comidos • Bolitas, Frutas, Pildora, : Comestible • Paredes laberinto: Solidas • Base: Solida, Hogar Facultad De Ingeniería – SVTI – Arquitectura y Diseño

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

  30. Del Análisis al Diseño (19/21) • Matriz interaccion Token/Property Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  31. Del Análisis al Diseño (20/21) • Matriz Property/Property Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  32. Diseño Jerárquico/OO

  33. Descompocición Jerarquica(1/3) • Jerarquica basado en entidades • Es posible trabajar de esta forma en todo el marco de trabajo. • Es normal que solo se toman como entidades aquellas que pueden ser actualizadas (depende del juego, tipo de juego). • De esta forma se logran otras ventajas: • Solo se salva el estado de estas. • En las actualizacione tienen prioridad Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  34. Descompocición Jerarquica (2/3) • Jerarquico 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 juegon según sus propiedades y crear una típica jerarquia 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

  35. Descompocición Jerarquica(2/3) • Ejemplo Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  36. Data 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 codigo. • Por ejemplo un archivo de datos por “Entity” con sus propiedades • Para entidades con comportamiento dinamico se usa scripting (por ejemplo LUA). Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  37. Data Driven (2/3) • Ventajas de Data Driven • Testeos durante desarrollo, rápidos y eficaces. • Cambios en los requerimientos del juego más faciles de implementar • Cambiar un auto porun robot gigante que lanze misiles • Datos, (velocidad, apariencia, sonidos, relaciones,e tc)‏ • Cambios posibles de realizar teoricamente en cualquier momento. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  38. Data 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, solo para actualizaciones no constantes (bajo rate)‏ Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  39. Model-View-Controller (1/4) • Model-View-Controller • Patron 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

  40. 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 estos. • Modelo: Datos propios de las entidades, posición, velocidad, atributo x. Logica sobre estos. • Controller: Entradas que modifican el modelo. • Inputs de usuarios, actualizaciones de estado del server. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  41. Model-View-Controller (3/4) • Aplicación en videojuegos • El modelo entonces mantiene la minima cantidad de información (datos) necesarios (maquina 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

  42. 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 modulo (abstracción de motores). • Cambios completos en el manejo de inputs sin afectar el resto. Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  43. FrameWork • 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

  44. Ejemplo Práctico Facultad De Ingeniería – SVTI – Arquitectura y Diseño

  45. Diseño orientado a Componentes

  46. Introducció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

  47. Introducció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

  48. POC en video juegos

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

  50. OJ 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

More Related