arquitectura de videojuegos

Click here to load reader

Post on 01-Feb-2016

43 views

Category:

Documents

2 download

Embed Size (px)

DESCRIPTION

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 - PowerPoint PPT Presentation

TRANSCRIPT

  • Arquitectura de VideojuegosSeminario de Tcnologas Interactivas y Videojuegos

    Rudi Lausarot, Manuel Martnez, Vosky Clavijo.Edicin 2008

    Facultad de Ingenieria - Computacion Grafica Avanzada - Aceleracion del Rendering

  • ContenidoIntroduccinHistoriaThirds PartiesDel Anlisis al DiseoDiseo Jerrquico/OODiseo orientado a ComponentesConclusinBibliografa

    Facultad de Ingenieria - Computacin Grfica Avanzada - Aceleracion del Rendering

  • Introduccin (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 computacin, sus interfaces y la comunicacin ente ellos.

    Motivacin en los Videojuegos Los Videojuegos son un software.Una buena arquitetura/diseo permite:ReusabilidadExtensibilidadManejable.

  • Introduccin (2/2)Motivacin en los videojuegos

    Acortar tiempos de produccin-Los recursos no son gratis -El tiempo tampco

    Cambios en los requerimientos.- Reusabilidad acorta el tiempo de cambio - Extensibilidad permite agregar requerimientos facilmente.

  • Historia (1/3)Desarrollo en el pasado

    Cdigo de maquina y Assembler-Requerimientos no complejos. (comparados a los actuales)-Hardware disponible muy limitado-Era comn la frase write to the metal.

  • Historia (2/3)CambioUso del lenguaje C-Doom casi completamente escrito en C .-Reaccin inmediata de la comunidad de programdores.-Esceptisismo.Preconceptos entre los programadores de VJ.Yo lo puedo hacer mejorNecesito saber como est hechoReinvencin de la rueda.

  • Historia (3/3)

    Ms en la actualidad.Productos hechos por terceros escencialesHalf Life:Modificacin del motor del quakeReutilizacin y cambios para satifacer nuevas necesidadesAhorro de 12 meses de produccin debido

  • Third Party components

  • Third Party components (1/2)Motor 3DQuakeMotor FsicoRigid body dynamicsTodos?Soft body dynamicsUnreal Tournament III

    Facultad de Ingenieria - Computacin Grfica Avanzada - Aceleracion del Rendering

  • Third Party components (2/2)Libreras (sonido, IA, etc.)OpenAL Doom 3, Jedi Knight II, Quake 4, Prey,Tremulous, etc.Manejadores de inputs (abstraccin de entrada de controles)lg3d-wii, sdl (windows, Mac OS, Linux, consolas)Motor de Juego (son casi todos los puntos anteriores juntos).

  • Del Anlisis al Diseo

  • Del Anlisis al Diseo (1/21)TOKENSElementos comunes en juegosTodos los juegos tienen elementos discretos en comn o directamente manipulados por el jugador. A estos elementos les llamaremos TOKENS.Para explicar como usar y en que pueden ayudarnos a disear juegos estos TOKENS, nos basaremos en dos casos de estudio. Pong y Pac-Man

  • Del Anlisis al Diseo (2/21) PONG

  • Del Anlisis al Diseo (3/21)Tokens jerarquicos de PONG

  • Del Anlisis al Diseo (4/21)TokenizacionIdentificamos los tokens del juegoInteracciones (eventos)Definimos las interacciones posibles entre los tokensMatriz de interacciones

  • Del Anlisis al Diseo (5/21)Matriz de interaccion de PONG

  • Del Anlisis al Diseo (6/21)Token Game worldCadena de mensajes enviada cuando ocurre un gol

  • Del Anlisis al Diseo (7/21)

  • Del Anlisis al Diseo (8/21)Simplificacion de Tokenizacion de PAC-MAN

  • Del Anlisis al Diseo (9/21)Maquina de estados para los fantasmas

  • Del Anlisis al Diseo (10/21)Maquina de estados para el Pac-Man

  • Del Anlisis al Diseo (11/21)Balls! ?Maquina de estado Hot Ball

  • Del Anlisis al Diseo (12/21)Maquina de estado SnowBall

  • Del Anlisis al Diseo (13/21)PropiedadesCaliente, templado, frio

  • Del Anlisis al Diseo (14/21)PropiedadesCaliente, templado, frio

  • Del Anlisis al Diseo (15/21)PropiedadesSe agrega la propiedad Luz

  • Del Anlisis al Diseo (16/21)Interacciones (eventos)Definimos las interacciones posibles entre los tokensHasta ahora tenemos:Matriz de interacciones, eventos, estados, propiedades.

  • Del Anlisis al Diseo (17/21)Definimos:Pac-Man:HambrientoFantasmas: Fuertes cazandoDebiles cazadosNinguno, cuando son comidosBolitas, Frutas, Pildora, : ComestibleParedes laberinto: SolidasBase: Solida, Hogar

  • Del Anlisis al Diseo (18/21)EventosA: Power-upB: ColisionC: Muere Pac-ManD: Incremento ScoreE: Fantasma es comidoF: Timer Reset

  • Del Anlisis al Diseo (19/21)Matriz interaccion Token/Property

  • Del Anlisis al Diseo (20/21)Matriz Property/Property

  • Diseo Jerrquico/OO

  • Descompocicin Jerarquica (1/3)Jerarquica basado en entidadesEs 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

  • Descompocicin Jerarquica (2/3)Jerarquico basado en entidadesProfunda Jerarqua de clases para representar entidades de juegoUna entidad es un objeto del juego que tiene distintas propiedadesEl acercamiento es organizar los objetos del juegon segn sus propiedades y crear una tpica jerarquia de objetos partiendo de un objeto abstracto o casi sin propiedades. Entity, Actor.EneFebMarAbrMayJunJulSepOctNovDicAgo

  • Descompocicin Jerarquica (2/3)Ejemplo

  • Data Driven (1/3)Modelo orientado por lo datosIndistinto del tipo de diseo usadoEn lo posible el estado del sistema determinado por datos y no por codigo.Por ejemplo un archivo de datos por Entity con sus propiedadesPara entidades con comportamiento dinamico se usa scripting (por ejemplo LUA).

  • Data Driven (2/3)Ventajas de Data DrivenTesteos durante desarrollo, rpidos y eficaces.Cambios en los requerimientos del juego ms faciles de implementarCambiar un auto porun robot gigante que lanze misilesDatos, (velocidad, apariencia, sonidos, relaciones,e tc)Cambios posibles de realizar teoricamente en cualquier momento.

  • Data Driven (3/3)Desventajas de Data DrivenSeguridadEl diseo 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-ControllerPatron de arquitectura que pretende separar la lgica de la aplicacin de su representacin ante el usuario y la comunciacin al modelo

  • Model-View-Controller (2/4)Aplicacin en videojuegosVista: Representacin de las entidades del juegoGrficos, Sonidos, eventos de interaccin con el usuariosLgica sobre estos.Modelo: Datos propios de las entidades, posicin, 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)Aplicacin en videojuegosEl modelo entonces mantiene la minima cantidad de informacin (datos) necesarios (maquina de estado).La vista se encarga de la lgica de representacin y de la representacin propiamente dichaEl controller se encargar de recibir las entradas de los usuarios y abstraerlas lgicamente para el modelo.

  • Model-View-Controller (4/4)Beneficio inmediato y prctico.Actualizacin de estado en juegos multiplayerCambio completos en la representacin sin tocar ningn otro modulo (abstraccin de motores).Cambios completos en el manejo de inputs sin afectar el resto.

  • FrameWorkFrameWorkUn diseo bsico reusable con funcionalidad de por s. ExtendibleMantenibleModificableFlexible/AcotadorEn VideoJuegosEstructura bsica con funcionalidad de la que facilmente se puede realizar un juego.

  • Ejemplo Prctico

  • Diseo orientado a Componentes

  • Introduccin (1/2)Qu es el diseo orientado a componentes?nfasis en divisin en componentes.qu es un componente? Objeto construido para una especificacin.Criterios: mltiples usos, sin contexto especfico, componible, encapsulado, independiente.

  • Introduccin (2/2)por qu si utilizar componentes?Reutilizable.Robustez.RapidezFcil de mantener.por qu no utilizar componentes?Difcil de comprender.

  • POC en video juegos

  • Objeto de Juego (1/3)Tambin llamado entidad u objeto de escena.Ej.:rbol, tanque, hroe, roca, secuencia de cmara, etc..Acciones:Anlisis sintctico, animar, tocar audio, seguir un camino, persistir, etc..

  • OJ como Jerarqua (2/3)Conjunto de objetos de juego representados mediante OO.Al agregar funcionalidades:Encapsular -> puede generar duplicacin de cdigo.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 jerarqua.Mas manejable y sencillo de mantener.

  • Implementacin

  • OJ (1/9)Objeto de Juego.Contiene:Transformacin, identificador nico, conjunto de componentes.

    +string getNombre()+setNombre(string nom)()+Transformacin getTransf()+setTransf(Transformacin tranf)()+clearComps()

    -nombre-Transformacin-Componentes

    OJ

  • OCJ (2/9)Objeto componente de juego.Especifica datos + comportamiento de funcionalidades especfica.Ej.:Salud, representacin grfica, manejos de fsica, 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 (3/9)Objeto componente de juego base.Interfaz comn a todo OCJ.Facilita manejo a OJ.

    +OJ getOJDueo()+setOJDueo(OJ obj)()+[virtual]update()+[virtual]string compID()+[virtual]string famID()

    -OJDueo

    OCJ

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

    ocjVisual

  • Manejo de OCJ en OJ (4/9)Necesitamos:Agregar, remover, obtener, limpiar.Ms de un GOC de cada familia.Muestra demasiada info.Aumenta dependencias.Entonces -> no mas de un GOC por familia.Solucin contenedor de comp.

    +string getNombre()+setNombre(string nom)()+Transformacin getTransf()+setTransf(Transformacin tranf)()+OCJ getComp(string idFamilia)()+setComp(OCJ)()+clearComps()

    -nombre-Transformacin-Componentes

    OJ

  • Comunicacin entre OCJ (5/9)No es ideal.Puede ser una necesidad.Resulta prctico.

  • Plantillas OCJ (6/9)Imprctico inicializacin 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 OJ (7/9)Las POCJ simplifican pero se puede hacer +.Similar a POCJ pero para OJ.

    +string getNombre()+setNombre(string nom)()+Transformacin getTransf()+setTransf(Transformacin tranf)()+OCJ getComp(string idFamilia)()+setComp(OCJ)()+clearComps()

    -nombre-Transformacin-Componentes

    OJ

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

    -nombre-comps

    POJ

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

    +OJ crearOJ(string nom)()

    -instancia

    MPOJ

    +OCJ crearOCJ(string nom)()

    -instancia

    MPOCJ

  • Data-Driven (9/9)Los componentes refuerzan la creacin de objetos utilizando archivos de datos.

  • De jerarqua 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 nocin de objeto de juego como objeto concreto.Es posible transicin a agregacin pura.Contra:Todava tenemos objeto raz.

  • Paso 3 (3/3)Entidad como una agregacin pura de componentes.Objeto es la suma de sus partes.Entidad es coleccin de componentes.

  • Caso : Neversoft

  • Tony Hawks Pro Skater (1/3)Contexto:3 aos de cdigo.Un juego de la saga por ao.Problema:Jerarqua objeto BLOB.Objetos sufren sobrepeso.Contienen informacin innecesaria.Duplicas de funcionalidad.Propuesta de solucin.Transformar la jerarqua a componentes.

  • Tony Hawks Pro Skater (2/3)Recepcin de la propuesta:Resistencia programadores.Difcil de explicar la idea a gerentes.Ejecucin de la propuesta:2 aos de reingeniera.Primero construccin de framework bsico para componentes genricos.Luego implementar aspectos del juego y mostrar a programadores.Resultados:Al comienzo poco visibles.Luego fcil implementacin de nuevos objetos.

  • Tony Hawks Pro Skater (3/3)Detalles de la implementacin:Overhead de funciones virtuales.Compensado por simplificacin de objetos.Necesidad de orden en lista de componentes.Necesidad de comunicacin de componentes.Conclusiones:Buena decisin.Cdigo mas limpio y fcil 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.Tokenizacin una buena forma de pasar de los requerimientos al diseo.Diseo Jerrquico modelo muy estandarizado y pulidoAbstraccin , modularizacin y Frameworks como principios bsicosDiseo de Componentes buena opcin para desarrollos muy grandes.

  • Referencias

    LibroGame Architecture and Design. A new Edition (Rollins)www.losersjuegos.com.ar/referencia/libros/descargas/curso_programacion.pdf 3D engineshttp://cg.cs.tu-berlin.de/~ki/engines.htmlhttp://www.quest3d.com/index.php?id=212&gclid=CIWG84ylx5UCFQM1gQod3m9cjghttp://www.ogre3d.org/http://www.codepixel.com/content/view/5135/34/Phisics engineshttp://www.tsnstudios.com/http://www.iearobotics.com/proyectos/cuadernos/ct9/ct9.htmlManejadores de eventoshttps://lg3d-wii.dev.java.net/

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

    Motor 3D: Un motor realtime 3D se encarga de varias cosas, por ej Renderizacion, iluminacion.. Etc.. Tamabien de mantener una descripcin de la escena, con los distintos entidades que la forman, su estado, y las relaciones entre distintas entidades.

    Es lo que se denomina scenegraph, y puede ser que tengamos incluso distintos scenegraphs para determinadas tareas. Al scenegraph se le piden "nodos" que podremos modificar, y despus el motor se encargara de pintar correctamente. Queremos destacar 2 cosas. Una primera es definir correctamente la descripcin de la escena, y para ello normalmente se utilizan exportadores y plugins para programas 3D comerciales, como 3dsmax, XSI, o maya. Estos programas nos van a dar una cantidad de informacin enorme: geometra, materiales, los huesos de la animacin, todo tipo de propiedades que deseemos agregar al objeto, etc. Nosotros tenemos que decidir que vamos a implementar, como vamos a permitir editarlo en el software 3d, y tendremos que pensar la mejor forma de exportar esa informacin a nuestra definicin de escena. Este captulo no es en s nada trivial. La segunda es que:Muchos de los grandes errores de un diseo del motor vienen de no pensar adecuadamente dnde almacenar los datos. Por eso lo ideal es que al principio diseemos una forma flexible de modificar este fichero. Una idea para conocer cual es la mejor forma de almacenar los datos es investigar varios programas de 3D (maya,XSI y 3dsmax al menos), y ver qu datos se almacenan en los objetos. Este tipo de investigaciones os van a servir de mucho posteriormente, ya que tendris claros los requisitos posteriores del motor.

    physics engine is a computer program that simulates Newtonian physics models, using variables such as mass, velocity, friction and wind resistance. It can simulate and predict effects under different conditions that would approximate what happens in real life or in a fantasy world. Its main uses are in scientific simulation and in video games.

    In physics, rigid body dynamics is the study of the motion of rigid bodies. Unlike particles, which move only in three degrees of freedom (translation in three directions), rigid bodies occupy space and have geometrical properties, such as a center of mass, moments of inertia, etc., that characterize motion in six degrees of freedom (translation in three directions plus rotation in three directions). Rigid bodies are also characterized as being non-deformable. As such, rigid body dynamics is used heavily in analyses and computer simulations of physical systems and machinery where rotational motion is important, but material deformation does not have a major effect on the motion of the system.

    Soft body dynamics is an area of physics simulation software that focuses on accurate simulation of a flexible object. That is, the object is deformable, meaning that the relative positions of points of the objects can change.There are many dynamic forces that have direct influence on an object's behavior (friction, gravity, collisions, springs, wind, etc.), and using soft body dynamics creates a believable illusion of the object. Soft bodies include: clothes, hair, and water.

    lg3d-wiiThe goal of this project is to create a (user-space) Linux event driver for the Nintendo Wiimote so that it can be used as a standard JInput device with Project Looking Glass and Project Wonderland. There is also a plan to write a Java library with bindings (using JNI) to a low-level C library that can talk to the Wiimote. The (user-space) Linux event driver is currently working. It is written using the libwiimote library. Much of this functionality was implemented by looking at the Cwiid and the WMD projects. The main functionality it adds if force-feedback and speaker (for system beep only) support.

    A game engine is a software system designed for the creation and development of computer and video games. Game engines play a role akin to a "Game Construction Set". There are many game engines that are designed to work on video game consoles and desktop operating systems such as Linux, Mac OS X, and Microsoft Windows. The core functionality typically provided by a game engine includes a rendering engine (renderer) for 2D or 3D graphics, a physics engine or collision detection (and collision response), sound, scripting, animation, artificial intelligence, networking, streaming, memory management, threading, and a scene graph. The process of game development is frequently economized by in large part reusing the same game engine to create different games.

    Usamos tokens y no objetos porque cuando pensamos en objetos como en C, tratamos de llevar todo a clases, hay un mapeo mental de objetos en clases, la tokenizacion es una etapa intermedia en el desarrollo de una arquitectura descendente.

    Pong tiene 2 jugadores una pelota y algunas paredes, cuales de estos elementos son tokens?Conceptualmente todos son tokens, cada jugador controla un bat y si conquista un gol mejorara su score. De esta manera podemos decir que el jugador tiene un bat y un score, estos son subtokens representando el jugador, la pelota es otro token. Las paredes son otro token, y previenen que la pelota se escape de la parte superior e inferior de la pantalla.Que pasa con las areas de gol?Cuando la pelota llega ahi, se conquista un gol, y el juego comienza de nuevo, por esto son tambien tokens aunque no tengan una representacion visual.

    Ahora que tenemos los tokens podemos definir las interacciones entre los mismos, para ello podemos usar como herramienta la matriz de interacciones.Esta muestra para cada par de tokens como estos interactuanLa matriz es simetrica porque el comportamiento es el mismo independietemente del orden de interaccion de los tokens.Esta matriz nos permite revisar visualmente las interacciones, podemos chequear que son lo que nosotros esperamos, y podemos ver si nos olvidamos de alguna o cometimos algun error.

    Podria llegar a ser necesario tener un token game word, que se entere de cuando por ejemplo ocurre un gol, esto evitaria que cada token en el juego tenga que estar conectado precisamente para manejar los eventos ocurridosEn juegos sencillos esto puede no ser necesario, pero ya en juegos mas complejos esto facilita mucho la tarea, quitando bastante complejidad y hace que sea mas facil agregar o quitar tokens. Otra razon es filtrar la informacion que un token necesita saber.Algunos eventos no fueron incluidos para hacer mas sencillo el diagrama, despues se van a ver algunas modificaciones. Por ejemplo, el mas importante de los eventos fue el de resurreccion, cuando un fantasma comido va a la base, este es resusitado. Una vez que resusita se queda ahi por un pequenio tiempo y sale de nuevo al laberinto. La puerta de la base es otro item que no incluimos, la cual permite entrar y salir a los fantasmas pero no al pacman. Debido a la complejidad que se generaria de considerar estos casos en la matriz de interacciones utilizamos otra. Esto lo podemos modelar con otro diagrama, una maquina finita de estados. Pacman esta en el limite de la utilidad de la matriz de interacciones.En el diagrama de estados solo se incluyen eventos entrantes, no disparados por los fantasmas. Ejemplo, si el fantasma es comido se dispara un evento score!Hay 3 cuadros indicando cazador, cazado y comido. Explicar esos estados

    Este diagrama es similar al anterior salvo que la cantidad de resurrecciones es limitadaMuchos de los eventos que ocurren en este diagrama son manejados por el GAME WORLD TOKEN

    Explicar diagramaExplicar diagrama y plantear el problema de que pasa si se dan 3 interacciones simultaneas.Manejar todas las ocurrencias requiere de considerar muchos casos especiales en el codigo y ordenarlos por prioridad. No es muy practico. No hay mucho problema si no se van a agregar nuevos tokens durante el disenio del juego. Pero por ejemplo supongamos que queremos agregar que cuando inteactua una hotball con una baloon bal se transforme en una bola amalgama???

    Ahora podemos por ejemplo definir una bola caliente como una de metal con la propiedad caliente, cuando es enfriada se transforma en una de metal, y cuando esta en la transicion se exhibe sin propiedad, indicada por ninguna.Por ejemplo se pueden agregar mas propiedades como por ejemplo Luz, entonces la bola tendra temperatura y luz, Esta tabla no se puede usar para tener una vista completa del juego pero permite tener una abstraccion muy buena del comportamiento gral.No se pueden usar las matrices aisladamente, deben usarse conjuntamente.Tienen que ser vistas como un camino hacia un disenio mas detallado.Tokenizacion y matrices son imprescindibles en el desarrollo de juegos, en el paso de los requerimientos al diseo.Hay que ir haciendo pasos incrementales y dividiendo el problema