Arquitectura de Videojuegos



Descargar 2,22 Mb.
Fecha de conversión19.03.2017
Tamaño2,22 Mb.

Arquitectura de Videojuegos

  • Seminario de Técnologías Interactivas y Videojuegos
  • Rudi Lausarot, Manuel Martínez, Vosky Clavijo.
  • Edición 2008

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

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.

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.

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

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.

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

Third Party components

Third Party components (1/2)

  • Motor 3D
      • Quake
  • Motor Físico
    • Rigid body dynamics
      • Todos?
    • Soft body dynamics
      • Unreal Tournament III

Third Party components (2/2)

  • Librerías (sonido, IA, 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).

Del Análisis al Diseño

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

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

  • PONG

Del Análisis al Diseño (3/21)

  • Tokens jerarquicos de PONG

Del Análisis al Diseño (4/21)

  • Tokenizacion
    • Identificamos los tokens del juego
  • Interacciones (eventos)

Del Análisis al Diseño (5/21)

  • Matriz de interaccion de PONG

Del Análisis al Diseño (6/21)

  • Token Game world
      • Cadena de mensajes enviada cuando ocurre un gol

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

Del Análisis al Diseño (8/21)

  • Simplificacion de Tokenizacion de PAC-MAN

Del Análisis al Diseño (9/21)

  • Maquina de estados para los fantasmas

Del Análisis al Diseño (10/21)

  • Maquina de estados para el Pac-Man

Del Análisis al Diseño (11/21)

  • Balls! ?
  • Maquina de estado Hot Ball

Del Análisis al Diseño (12/21)

  • Maquina de estado SnowBall

Del Análisis al Diseño (13/21)

  • Propiedades
    • Caliente, templado, frio

Del Análisis al Diseño (14/21)

  • Propiedades
    • Caliente, templado, frio

Del Análisis al Diseño (15/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.

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

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

Del Análisis al Diseño (19/21)

  • Matriz interaccion Token/Property

Del Análisis al Diseño (20/21)

  • Matriz Property/Property

Diseño Jerárquico/OO

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

Descompocición Jerarquica (2/3)

  • Ene
  • Feb
  • Mar
  • Abr
  • May
  • Jun
  • Jul
  • Sep
  • Oct
  • Nov
  • Dic
  • Ago
  • 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”.

Descompocición Jerarquica (2/3)

  • Ejemplo

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

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.

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)‏

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

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.

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.

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.

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.

Ejemplo Práctico

Diseño orientado a Componentes

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.

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.

POC en video juegos

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

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

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.

Implementación

OJ (1/9)

  • Objeto de Juego.
  • Contiene:
    • Transformación, identificador único, conjunto de componentes.

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.

OCJ - base (3/9)

  • Objeto componente de juego base.
  • Interfaz común a todo OCJ.
  • Facilita manejo a OJ.

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.

Comunicación entre OCJ (5/9)

  • No es ideal.
  • Puede ser una necesidad.
  • Resulta práctico.

Plantillas OCJ (6/9)

  • Impráctico inicialización de OCJ por OJ.
  • Posible desperdicio de memoria.
  • POCJ inicializa OCJ y amacena datos comunes.

Plantillas OJ (7/9)

  • Las POCJ simplifican pero se puede hacer +.
  • Similar a POCJ pero para OJ.

Manejadores (8/9)

  • Tanto para OCJ como para OJ.
  • Centralizan manejo.

Data-Driven (9/9)

  • Los componentes refuerzan la creación de objetos utilizando archivos de datos.

De jerarquía OO a col. Comp.

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

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.

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.

Caso : Neversoft

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.

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.

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.

Tony Hawk

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.

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/

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



Compartir con tus amigos:


La base de datos está protegida por derechos de autor ©absta.info 2019
enviar mensaje

    Página principal