arquitectura de videojuegos
Download
Skip this Video
Download Presentation
Arquitectura de Videojuegos

Loading in 2 Seconds...

play fullscreen
1 / 73

Arquitectura de Videojuegos - PowerPoint PPT Presentation


  • 116 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Arquitectura de Videojuegos' - nikkos


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
arquitectura de videojuegos
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

contenido
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

introducci n 1 2
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

introducci n 2 2
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

historia 1 3
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

historia 2 3
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

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

third party components 1 2
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

third party components 2 2
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

del an lisis al dise o 1 21
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

del an lisis al dise o 2 21
Del Análisis al Diseño (2/21)

PONG

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

del an lisis al dise o 3 21
Del Análisis al Diseño (3/21)
  • Tokens jerarquicos de PONG

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

del an lisis al dise o 4 21
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

del an lisis al dise o 5 21
Del Análisis al Diseño (5/21)
  • Matriz de interaccion de PONG

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

del an lisis al dise o 6 21
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

del an lisis al dise o 7 21
Del Análisis al Diseño (7/21)

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

del an lisis al dise o 8 21
Del Análisis al Diseño (8/21)
  • Simplificacion de Tokenizacion de PAC-MAN

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

del an lisis al dise o 9 21
Del Análisis al Diseño (9/21)
  • Maquina de estados para los fantasmas

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

del an lisis al dise o 10 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

del an lisis al dise o 11 21
Del Análisis al Diseño (11/21)
  • Balls! ?
  • Maquina de estado Hot Ball

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

del an lisis al dise o 12 21
Del Análisis al Diseño (12/21)
  • Maquina de estado SnowBall

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

del an lisis al dise o 13 21
Del Análisis al Diseño (13/21)
  • Propiedades
    • Caliente, templado, frio

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

del an lisis al dise o 14 21
Del Análisis al Diseño (14/21)
  • Propiedades
    • Caliente, templado, frio

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

del an lisis al dise o 15 21
Del Análisis al Diseño (15/21)
  • Propiedades
    • Se agrega la propiedad Luz

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

del an lisis al dise o 16 21
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

del an lisis al dise o 17 21
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

del an lisis al dise o 18 21
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

del an lisis al dise o 19 21
Del Análisis al Diseño (19/21)
  • Matriz interaccion Token/Property

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

del an lisis al dise o 20 21
Del Análisis al Diseño (20/21)
  • Matriz Property/Property

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

descompocici n jerarquica 1 3
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

descompocici n jerarquica 2 3
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

descompocici n jerarquica 2 31
Descompocición Jerarquica(2/3)
  • Ejemplo

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

data driven 1 3
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

data driven 2 3
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

data driven 3 3
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

model view controller 1 4
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

model view controller 2 4
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

model view controller 3 4
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

model view controller 4 4
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

framework
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

ejemplo pr ctico
Ejemplo Práctico

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

introducci n 1 21
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

introducci n 2 21
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

objeto de juego 1 3
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

oj como jerarqu a 2 3
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

oj como col de comp 3 3
OJ como Col. de Comp. (3/3)
  • Otra forma de representar un objeto de juego.
  • Mueven funcionalidades del objeto a componentes.
  • Puede parecer mas complejo que jerarquía.
  • Mas manejable y sencillo de mantener.

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

oj 1 9
OJ (1/9)
  • Objeto de Juego.
  • Contiene:
    • Transformación, identificador único, conjunto de componentes.

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

ocj 2 9
OCJ (2/9)
  • Objeto componente de juego.
  • Especifica datos + comportamiento de funcionalidades específica.
  • Ej.:
    • Salud, representación gráfica, manejos de física, funciones IA, etc..
  • Organizados en familias.

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

ocj base 3 9
OCJ - 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

manejo de ocj en oj 4 9
Manejo de OCJ en OJ (4/9)
  • Necesitamos:
    • Agregar, remover, obtener, limpiar.
  • Más de un GOC de cada familia.
    • Muestra demasiada info.
    • Aumenta dependencias.
  • Entonces -> no mas de un GOC por familia.
  • Solución contenedor de comp.

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

comunicaci n entre ocj 5 9
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

plantillas ocj 6 9
Plantillas 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

plantillas oj 7 9
Plantillas 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

manejadores 8 9
Manejadores (8/9)
  • Tanto para OCJ como para OJ.
  • Centralizan manejo.

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

data driven 9 9
Data-Driven(9/9)
  • Los componentes refuerzan la creación de objetos utilizando archivos de datos.

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

paso 1 1 3
Paso 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

paso 2 2 3
Paso 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

paso 3 3 3
Paso 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

tony hawk s pro skater 1 3
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

tony hawk s pro skater 2 3
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

tony hawk s pro skater 3 3
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 mas limpio y fácil de mantener.

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

tony hawk
Tony Hawk

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

conclusiones
Conclusiones.
  • 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.

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

referencias
Referencias
  • Libro
    • Game Architecture and Design. A new Edition (Rollins)
    • www.losersjuegos.com.ar/referencia/libros/descargas/curso_programacion.pdf
  • 3D engines
    • http://cg.cs.tu-berlin.de/~ki/engines.html
    • http://www.quest3d.com/index.php?id=212&gclid=CIWG84ylx5UCFQM1gQod3m9cjg
    • http://www.ogre3d.org/
    • http://www.codepixel.com/content/view/5135/34/
  • Phisics engines
    • http://www.tsnstudios.com/
    • http://www.iearobotics.com/proyectos/cuadernos/ct9/ct9.html
  • Manejadores de eventos
    • https://lg3d-wii.dev.java.net/

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

referencias1
Referencias
  • Programación
    • Game Programming Gems 6 -"Game Object Component System" - Chris Stoy
    • http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ - Mick West
    • http://www.gamearchitect.net/Articles/GameObjects1.html - Inheritance vs. Aggregation - Kyle Wilson
    • http://www.drizzle.com/~scottb/gdc/game-objects_files/frame.htm - A Data-Driven Game Object System - Scott Bilas
    • http://garage.gaspowered.com/?q=su_301 - Introduction to Dungeon Siege Architecture
    • http://www.gamedev.net/community/forums/mod/journal/journal.asp?jn=443615&cmonth=9&cyear=2008&cday=4 - Componente-based design resources

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

ad