arquitectura de videojuegos

Facultad de Ingenieria - Computacion Grafica Avanzada - Aceleracion del Rendering

1

Arquitectura de VideojuegosArquitectura de Videojuegos

Seminario de Técnologías Interactivas y Videojuegos

Rudi Lausarot, Manuel Martínez, Vosky Clavijo.

Edición 2008

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

ContenidoContenido

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 Introducción (1/2)(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 Introducción (2/2)(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 Historia (1/3)(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”.



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.



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

ThirdThird Party Party componentscomponents


ThirdThird Party Party componentscomponents (1/2)(1/2)

Motor 3DQuake

Motor Físico– Rigid body dynamics

Todos?

– Soft body dynamicsUnreal Tournament III


ThirdThird Party Party components components (2/2)(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).

Del Análisis al DiseñoDel Análisis al Diseño


Del Análisis al Diseño Del Análisis al Diseño (1/21)(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



PONG



Tokens jerarquicos de PONG



Tokenizacion– Identificamos los tokens del juego

Interacciones (eventos)– Definimos las interacciones posibles entre los

tokens• Matriz de interacciones



Matriz de interaccion de PONG



Token Game worldCadena de mensajes enviada cuando ocurre un gol



Simplificacion de Tokenizacion de PAC-MAN



Maquina de estados para los fantasmas



Maquina de estados para el Pac-Man



Balls! ? Maquina de estado Hot Ball



Maquina de estado SnowBall



Propiedades– Caliente, templado, frio



Propiedades– Se agrega la propiedad Luz



Interacciones (eventos)– Definimos las interacciones posibles

entre los tokens

Hasta ahora tenemos:• Matriz de interacciones, eventos,

estados, propiedades.



Definimos:– Pac-Man:Hambriento– Fantasmas:

• Fuertes cazando• Debiles cazados• Ninguno, cuando son comidos

– Bolitas, Frutas, Pildora, : Comestible– Paredes laberinto: Solidas– Base: Solida, Hogar



Eventos– A: Power-up– B: Colision– C: Muere Pac-Man– D: Incremento Score– E: Fantasma es comido– F: Timer Reset



Matriz interaccion Token/Property



Matriz Property/Property

Diseño Jerárquico/OODiseño Jerárquico/OO


Descompocición JerarquicaDescompocición Jerarquica (1/3)(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 Descompocición Jerarquica (2/3)(2/3)

Ene Feb Mar Abr May Jun Jul Sep Oct Nov DicAgo

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 JerarquicaDescompocición Jerarquica (2/3)(2/3)

Ejemplo


Data Driven Data Driven (1/3)(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).



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.



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



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.



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.



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.


FrameWorkFrameWork

FrameWork– Un diseño básico reusable con funcionalidad de por Un diseño básico reusable con funcionalidad de por

sí. sí. – ExtendibleExtendible– MantenibleMantenible– ModificableModificable– Flexible/AcotadorFlexible/Acotador

En VideoJuegosEn VideoJuegos– Estructura básica con funcionalidad de la que Estructura básica con funcionalidad de la que

facilmente se puede realizar un juego.facilmente se puede realizar un juego.


Ejemplo PrácticoEjemplo Práctico

Diseño orientado a ComponentesDiseño orientado a Componentes


IntroducciónIntroducción (1/2)(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ónIntroducción ((22/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 juegosPOC en video juegos


Objeto de Juego Objeto de Juego (1/3)(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 OJ como Jerarquía (2/3)(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. OJ como Col. de Comp. (3/3)(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ónImplementación


OJ OJ (1/9)(1/9)

Objeto de Juego. Contiene:

– Transformación, identificador único, conjunto de componentes. +string getNombre()

+setNombre(string nom)()+Transformación getTransf()+setTransf(Transformación tranf)()+clearComps()

-nombre-Transformación-Componentes

OJ


OCJ OCJ (2/9)(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.

+string famID()+[virtual]update()+[virtual]string compID()+[virtual]render()

ocjVisual

+string compID()+update()+render()+float getRadio()+setRadio(float r)()

-radio

ocjVisualEsfera

+string compID()+update()+render()+float getLargo()+setLargo(float l)()

-largo

ocjVisualCubo


OCJ - base OCJ - base (3/9)(3/9)

Objeto componente de juego base.

Interfaz común a todo OCJ.

Facilita manejo a OJ.

+OJ getOJDueño()+setOJDueño(OJ obj)()+[virtual]update()+[virtual]string compID()+[virtual]string famID()

-OJDueño

OCJ

+string famID()+[virtual]update()+[virtual]string compID()+[virtual]render()

ocjVisual


Manejo de OCJ en OJ Manejo de OCJ en OJ (4/9)(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.

+string getNombre()+setNombre(string nom)()+Transformación getTransf()+setTransf(Transformación tranf)()+OCJ getComp(string idFamilia)()+setComp(OCJ)()+clearComps()


OJ


Comunicación entre OCJComunicación entre OCJ (5/9)(5/9)

No es ideal. Puede ser una

necesidad. Resulta práctico.


Plantillas OCJPlantillas OCJ (6/9)(6/9)

Impráctico inicialización de OCJ por OJ.

Posible desperdicio de memoria.

POCJ inicializa OCJ y amacena datos comunes.

+[virtual]string famID()+[virtual]string compID()+[virtual]constComp(OJ obj)()

POCJ

+string famID()+string compID()+OCJ constComp(OJ obj)()+int getSaludInicialDe(ParteCuerpo p)()+setSaludInicial(int[] sp)()

-saludInicial

pocjSalud

+ocjSalud(pocjSalud pocjs)()+int getSaludDe(ParteCuerpo p)()+setSaludDe(ParteCuerpo p, int s)()+bool estaHerido()

-salud

ocjSalud


Plantillas OJPlantillas OJ (7/9)(7/9)

Las POCJ simplifican pero se puede hacer +.

Similar a POCJ pero para OJ.

+string getNombre()+setNombre(string nom)()+Transformación getTransf()+setTransf(Transformación tranf)()+OCJ getComp(string idFamilia)()+setComp(OCJ)()+clearComps()


OJ

+string getNombre()+setNombre(string nom)()+lista<POCJ> componentes()+addPOCJ(POCJ)()+POCJ getPOCJ(string id)()

-nombre-comps

POJ


Manejadores Manejadores (8/9)(8/9)

Tanto para OCJ como para OJ.

Centralizan manejo.+OJ crearOJ(string nom)()

-instancia

MPOJ

+OCJ crearOCJ(string nom)()

-instancia

MPOCJ


Data-DrivenData-Driven (9/9)(9/9)

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

De jerarquía OO a col. Comp.De jerarquía OO a col. Comp.


Paso 1 Paso 1 (1/3)(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 Paso 2 (2/3)(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 Paso 3 (3/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 : NeversoftCaso : Neversoft


Tony Hawk’s Pro Skater Tony Hawk’s Pro Skater (1/3)(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 Tony Hawk’s Pro Skater ((22/3)/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 Tony Hawk’s Pro Skater (3/3)(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 HawkTony Hawk


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.


ReferenciasReferencias

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/


ReferenciasReferencias

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

arquitectura de videojuegos

Documents