Arquitectura de videojuegos
Download
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

Third Party components


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