t2: patrones y videojuegos 3. patrones y videojuegos

Introducción a la Programación de Videojuegos y Gráficos

GRADO EN INGENIERÍA INFORMÁTICA

CURSO 2012/2013

T2: ARQUITECTURA Y LÓGICA DE VIDEOJUEGO

2.1. Ingeniería del software aplicada a videojuegos

(paradigmas y patrones)

2.2. Modelos y Programa principal de un videojuego

2.3. Motores lógicos. Arquitectura del motor

2.4. Lenguajes de scripting


2.1. Ingeniería del software aplicada a videojuegos (paradigmas y

patrones)

1. Definición y concepto de patrón de diseño

2. Estructura y tipos de patrones

3. Patrones y videojuegos

T2: Patrones y videojuegos


• El diseño y desarrollo de un programa informático como un

videojuego, es demasiado complejo para que pueda ser abordado por

completo por una única persona.

• El proceso de diseño de cualquier aplicación sw suele ser iterativo y en

diferentes etapas de forma que se vaya refinando con el tiempo

(existen infinidad de modelos de desarrollo sw que pueden aplicarse)

• La etapa de diseño es una tarea crítica en el ciclo de vida del software

(gran impacto sobre el producto final y el futuro del mismo



• La experiencia previa en el diseño de sistemas similares en útil

para crear buenos diseños, pero no suficiente.

• Al construir aplicaciones similares se presentan situaciones

recurrentes y que se asemejan a situaciones pasadas.

• Un patrón de diseño almacena conocimiento experimental de

diseño procedente del estudio de aplicaciones y de los éxitos y

fracasos de casos reales



Un patrón de diseño es una descripción de la comunicación

entre objetos y clases personalizadas para solucionar un

problema genérico de diseño bajo un contexto determinado

Design Patterns. Elements of Reusable Object-Oriented Software

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (GoF-

Gang of Four), 2008



• Los patrones de diseño son la base para la búsqueda de soluciones

a problemas comunes en el desarrollo de software y otros ámbitos

referentes al diseño de interacción o interfaces.

• Un patrón de diseño resulta ser una solución a un problema de

diseño.

• Para que una solución sea considerada un patrón debe poseer

ciertas características:

• debe haberse comprobado su efectividad resolviendo

problemas similares en ocasiones anteriores

• debe ser reutilizable (aplicable a diferentes problemas de

diseño en distintas circunstancias)

http://es.wikipedia.org/wiki/Patrón_de_diseño



• Objetivos de los patrones:

• Los patrones de diseño pretenden:

• Proporcionar catálogos de elementos reusables en el diseño de sistemas

software.

• Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y

solucionados anteriormente.

• Formalizar un vocabulario común entre diseñadores.

• Estandarizar el modo en que se realiza el diseño.

• Facilitar el aprendizaje de las nuevas generaciones de diseñadores

condensando conocimiento ya existente.

• Asimismo, no pretenden:

• Imponer ciertas alternativas de diseño frente a otras.

• Eliminar la creatividad inherente al proceso de diseño.



• Estructura de un patrón de diseño. Para definir un patrón de diseño es

necesario describir, como mínimo, cuatro componentes fundamentales:

• Nombre del patrón, problema y contexto, solución y

ventajas/desventajas

• Otros componentes habituales son:

• Clasificación del patrón, aplicabilidad, estructura, participantes,

colaboraciones, implementación, código ejemplo, patrones

relacionados,…



• Componentes fundamentales:

1. Nombre del patrón. Nombre corto y autodefinido (vocabulario común y

alias del patrón)

2. Problema y contexto. Problema concreto que resuelve el patrón, contexto

donde tiene sentido aplicarlo (listado de precondiciones que deben ser

cumplidas para poder aplicar el patrón)

3. Solución. La solución que proporciona un patrón se describe

genéricamente y nunca ligada a ninguna implementación (normalmente, se

utiliza los conceptos y nomenclatura de la programación orientada objetos)

4. Ventajas y desventajas. Beneficios que aporta y sus posibles

inconvenientes



• Existen multitud de criterios para clasificarlos (patrones de

arquitectura, de diseño, dialectos, interacciones,…)

• Uno de los más aceptados es el ámbito de diseño donde tienen

aplicación

• Pueden definirse tres categorías fundamentales:

1. Patrones de creación

2. Patrones estructurales

3. Patrones de comportamiento



1. Patrones de creación

• Proporcionan una solución relacionada con la construcción de

clases, objetos y otras estructuras de datos.

• Ejemplos: Abstract Factory, Builder ofrecen mecanismos de

creación de instancias de objetos y estructuras escalables

dependiendo de las necesidades



1. Patrones estructurales

• Tratan sobre la forma de organizar las jerarquías de clases, las

relaciones y las diferentes composiciones entre objetos para

obtener un buen diseño bajo un determinado contexto.

• Ejemplos: Patrones como Adapter, Facade o Flyweight son

ejemplos de patrones estructurales



1. Patrones de comportamiento

• Las soluciones de diseño que proporcionan los patrones de

comportamiento están orientadas al envío de mensajes entre

objetos y cómo organizar ejecuciones de diferentes métodos

para conseguir realizar algún tipo de tarea de forma más

conveniente.

• Ejemplos: Visitor, Iterator y Observer


2. Estructura y tipos de patrones. Patrones de creación

• Object Pool (no pertenece a los patrones especificados por GoF): se

obtienen objetos nuevos a través de la clonación. Utilizado cuando el costo

de crear una clase es mayor que el de clonarla. Especialmente con objetos

muy complejos. Se especifica un tipo de objeto a crear y se utiliza una

interfaz del prototipo para crear un nuevo objeto por clonación. El proceso

de clonación se inicia instanciando un tipo de objeto de la clase que

queremos clonar.

• Abstract Factory (fábrica abstracta): permite trabajar con objetos de

distintas familias de manera que las familias no se mezclen entre sí y

haciendo transparente el tipo de familia concreta que se esté usando.



• Builder (constructor virtual): abstrae el proceso de creación de un objeto

complejo, centralizando dicho proceso en un único punto.

• Factory Method (método de fabricación): centraliza en una clase

constructora la creación de objetos de un subtipo de un tipo determinado,

ocultando al usuario la casuística para elegir el subtipo que crear.

• Prototype (prototipo): crea nuevos objetos clonándolos de una instancia

ya existente.

• Singleton (instancia única): garantiza la existencia de una única instancia

para una clase y la creación de un mecanismo de acceso global a dicha

instancia.



Diagrama de clases del patrón Singleton

Diagrama de clases del patrón Abstract Factory

Diagrama de clases del patrón Factory Method


2. Estructura y tipos de patrones. Patrones estructurales

• Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada

por una clase que de otro modo no podría utilizarla.

• Bridge (Puente): Desacopla una abstracción de su implementación.

• Composite (Objeto compuesto): Permite tratar objetos compuestos como

si de uno simple se tratase.

• Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente.

• Facade (Fachada): Provee de una interfaz unificada simple para acceder a

una interfaz o grupo de interfaces de un subsistema.



• Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de

objetos que poseen idéntica información.

• Proxy: Mantiene un representante de un objeto.

• Módulo: Agrupa varios elementos relacionados, como clases, singletons,

y métodos, utilizados globalmente, en una entidad única.

• Modelo Vista Controlador (Model-View-Controller: MVC) separa los

datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres

componentes distintos.



Estructura del patrón MVC

Diagrama de clases del patrón Facade

Diagrama de clases del patrón Adapter

Diagrama de clases del patrón Proxy


2. Estructura y tipos de patrones. Patrones de comportamiento

• Chain of Responsibility (Cadena de responsabilidad): Permite

establecer la línea que deben llevar los mensajes para que los objetos

realicen la tarea indicada.

• Command (Orden): Encapsula una operación en un objeto, permitiendo

ejecutar dicha operación sin necesidad de conocer el contenido de la misma.

• Interpreter (Intérprete): Dado un lenguaje, define una gramática para

dicho lenguaje, así como las herramientas necesarias para interpretarlo.

• Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos

independientemente de la implementación de estos.

• Mediator (Mediador): Define un objeto que coordine la comunicación

entre objetos de distintas clases, pero que funcionan como un conjunto.

• Memento (Recuerdo): Permite volver a estados anteriores del sistema.



• Observer (Observador): Define una dependencia de uno-a-muchos entre

objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen

automáticamente todos los objetos que dependen de él.

• State (Estado): Permite que un objeto modifique su comportamiento cada vez

que cambie su estado interno.

• Strategy (Estrategia): Permite disponer de varios métodos para resolver un

problema y elegir cuál utilizar en tiempo de ejecución.

• Template Method (Método plantilla): Define en una operación el esqueleto de

un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que

las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.

• Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de

clases sin modificar las clases sobre las que opera.



Diagrama de clases del patrón Observer

Diagrama de clases del patrón State

Diagrama de clases del patrón Strategy



Diagrama de clases del patrón Iterator Diagrama de clases del patrón Template Method

Diagrama de clases del patrón Reactor Diagrama de clases del patrón Visitor



• El paradigma de diseño y desarrollo basado en patrones es

ampliamente utilizado actualmente

• Especialmente en software de gran complejidad

• La utilización de este paradigma se aplica en el diseño de los

motores de juego



• Ejemplos de aplicación de patrones de diseño a diversos

módulos o elementos de un videojuego:

• Patrones:

• Creación: Singleton, Abstract Factory, Factory Method,

Prototype

• Estructurales: Composite, Decorator, Facade, MVC,

Adapter, Proxy

• Comportamiento: Observer, State, Iterator, Template

Method, Strategy



• Ejemplo Patrón Abstract Factory

Ejemplo: jerarquía de clases en un FPS

Aplicación del patrón Abstract Factory



• Ejemplo Patrón Abstract Factory



• Ejemplo Patrón Factory Method

Aplicación del patrón Factory Method



• Ejemplo Patrón Prototype

Aplicación del patrón Prototype



• Ejemplo Patrón Composite

Aplicación del patrón Composite



• Ejemplo Patrón Decorator

Aplicación del patrón Decorator



• Ejemplo Patrón Proxy

Aplicación del patrón Proxy



• Ejemplo Patrón Observer

Diagrama de clases del patrón Observer



• Ejemplo Patrón Observer

Diagrama de secuencia de ejemplo utilizando un Observer



• Ejemplo Patrón State

Aplicación del patrón State



• Ejemplo Patrón Template Method

Aplicación del patrón Template Method



• Ejemplo Patrón Strategy

Aplicación del patrón Strategy


2.1. Ingeniería del software aplicada a videojuegos

(paradigmas y patrones)


2.3. Motores lógicos. Arquitectura del motor

2.4. Lenguajes de scripting



1. Modelo y estructura de un videojuego

2. El bucle de renderizado (render loop)

3. El bucle del juego (game loop)

4. Arquitecturas de game loop

T2: Estructura y programa principal


• Desde un punto de vista puramente software el elemento central en

cualquier videojuego, es el bucle de juego (game loop)

• El bucle de juego permite que el juego funcione sin problemas,

independientemente de la entrada del usuario o posibles retardos en

el hw/sw

• Los programas sw tradicionales sólo responden a las entradas del

usuario (en caso contrario no hace nada), por ejemplo cualquier

programa ofimático (e.g. procesadores de texto)



• Un juego por otro lado debe estar continuamente realizando

acciones independientemente de la entrada del usuairo

• El bucle de juego permite precisamente realizar estas acciones de

maner simple e intuitiva

• El bucle de juego representa la estructura de control principal de

cualquier juego y gobierna su funcionamiento y la transición entre

los distintos estados del mismo



• En un motor de juegos existe una gran variedad de subsistemas o

componentes con distintas necesidades:

• motor de renderizado

• el sistema de detección y gestión de colisiones

• subsistema de juego

• subsistema de soporte a la Inteligencia Artificial

• La mayoría de estos componentes han de actualizarse

periódicamente mientras el juego se encuentra en ejecución



• El sistema de animación, de manera sincronizada con respecto al

motor de renderizado, ha de actualizarse con una frecuencia de 30 ó

60 Hz con el objetivo de obtener una tasa de frames por segundo lo

suficientemente elevada para garantizar una sensación de realismo

adecuada

• No es necesario mantener este nivel de exigencia para todos los

componentes (e.g. Inteligencia Artificial)



• Aunque existe diferentes formas (arquitecturas) de implementar un

game loop, una muy simplificada consiste en tener varios bucles

cada uno de ellos encargados de realizar las correspondientes

acciones

• Game loop: bucle general

• Bucle de renderizado: encargado de la parte visual

• Bucles de IA, Multimedia, interacciones, etc…


2. Bucle de renderizado

• Encargado de todas las funciones de visualización y renderizado del

juego

• Cuando aún el desarrollo de videojuegos 2D era el estándar en la

industria, los principales objetivos de diseño eran:

• minimizar el número de píxeles a dibujar por el pipeline de

renderizado

• maximizar la tasa de fps del juego



• Si en cada una de las iteraciones del bucle de renderizado el número

de píxeles que cambia es mínimo el juego se ejecutará a

mayor velocidad

• Sólo se redibujan las partes de la pantalla que cambian, denominada

habitualmente Rectangle invalidation

• La técnica es similar a la planteada en el desarrollo de GUIs



• En el desarrollo de videojuegos 3D, se mantiene idea de dibujar el

mínimo número de primitivas necesarias en cada iteración del bucle

de renderizado

• Sin embargo la filosofía es radicalmente diferente, aunque la cámara

virtual se mueva, el contenido audiovisual cambia continuamente



Esquema general de un bucle de renderizado

http://wiki.wxwidgets.org/Making_a_render_loop


3. El bucle del juego

• Principal función: actualizar el estado de los distintos componentes

del motor tanto:

• Internos: coordinación entre subsistemas

• Externo: tratamiento de eventos de teclado o ratón

bool game_is_running = true; while( game_is_running ) { update_game(); display_game(); }



• Un game loop (extremadamente simplificado) en pseudocódigo

podría tener este aspecto:

while( user doesn't exit )

check for user input run AI move enemies resolve collisions draw graphics play sounds

end while

Bucle de renderizado

T2: Estructura y programa principal 3. El bucle del juego

Esquema general de un bucle de juego



• Los bucles de juego dependen directamente de la plataforma sobre

la que se construyen

• Los juegos escritos en DOS y en diversas consolas se diseñan para

explotar al máximo los recursos de proceso disponible

• Los juegos para PCs modernos (con SSOO gráficos como Windows

o Linux) tienen como restricciones al propio scheduler del SSOO

• Otros juegos se ejecutan sobre múltiples hilos (threads). Supone una

pequeña sobrecarga, pero pueden ejecutarse (con mayor eficiencia)

en arquitecturas multicore



• Existe una amplia variedad de arquitecturas o diseños posibles para

un game loop

• La mayoría de ellas tienen en común el uso de uno o varios bucles

de control que gobiernan la actualización e interacción con los

distintos componentes del motor de juegos

• Se describirán brevemente las de Windows, las basadas en

retrollamadas, las basadas en eventos y las basadas en estados



• Tratamiento de mensajes en Windows

• Los juegos han de atender los mensajes recibidos por el propio sistema

operativo y dar soporte a los distintos componentes del propio motor de

juego (plataformas Windows)

• En estas plataformas se implementan los denominados message pumps

• En este esquema se atienden los mensajes del SSOO y del motor de

juego de forma iterativa

Esquema gráfico de una arquitectura basada

en message pumps



• Tratamiento de mensajes en Windows

• Si existe conflicto, los mensajes del SSOO se ejecutan

• Si no existen mensajes, se ejecuta una iteración del game loop

• Los mensajes del SSOO tienen prioridad respecto a aspectos críticos

como el bucle de renderizado

• Efecto: si la ventana en la que se está ejecutando el juego se arrastra o su

tamaño cambia, entonces el juego se congelará a la espera de finalizar el

tratamiento de eventos recibidos por el propio sistema operativo

Esquema gráfico de una arquitectura basada

en message pumps



• Esquemas basados en retrollamadas

• Concepto de retrollamada o callback: asociar una porción de código

para atender un determinado evento o situación

• Se puede asociar a una función concreta o a un objeto (callback object)

• Ejemplo: uso de funciones de retrollamada planteado en la biblioteca

GLUT (ligada a la biblioteca GL)

T2: Estructura y programa principal 4. Arquitecturas de game loop

• Esquemas basados en retrollamadas (GLUT)



• Esquemas basados en retrollamadas

• Las funciones de retrollamada se suelen utilizar como mecanismo para

rellenar el código fuente necesario para tratar un determinado tipo de

evento

• Este esquema está directamente ligado al concepto de framework

• framework : aplicación construida parcialmente y que el desarrollador

ha de completar para proporcionar una funcionalidad específica



• Tratamiento de eventos

• Un evento representa un cambio en el estado del propio juego o en el

entorno (área de los videojuegos)

• Pueden clasificarse como externos o internos

• Externos: producidos por las interacciones

• Ejemplo muy común, el jugador cuando pulsa un botón del joystick




• Internos: interacciones de la lógica del juego

• Ejemplo: reaparición o respawn de un NPC en el juego

• Gran parte de los motores de juegos incluyen un subsistema específico

para el tratamiento de eventos

• El resto de componentes del motor, o incluso a entidades específicas,

pueden registrarse como partes interesadas en un determinado tipo de

eventos




• Este planteamiento está muy estrechamente relacionado con el patrón

Observer

• Canales de eventos: Con el objetivo de independizar los publicadores y

los suscriptores de eventos, se suele utilizar el concepto de canal de

eventos como mecanismo de abstracción



• Esquema basado en estados

• Desde un punto de vista general, los juegos se pueden dividir en una

serie de etapas o estados que se caracterizan no sólo por su

funcionamiento sino también por la interacción con el usuario o jugador

• En la mayor parte de los juegos es posible diferenciar los siguientes

estados:

• Introducción, Menú principal, Juego, Finalización




• Introducción o presentación: se muestra al usuario aspectos generales

del juego (e.g. la temática del mismo o incluso cómo jugar)

• Menú principal: el usuario ya puede elegir entre los distintos modos de

juegos y que, normalmente, consiste en una serie de entradas textuales

identificando las opciones posibles

• Juego: donde ya es posible interactuar con la propia aplicación e ir

completando los objetivos marcados

• Finalización o game over: donde se puede mostrar información sobre la

partida previamente jugada




• Existe una relación entre cada uno de estos estados que se manifiesta en

forma de transiciones entre los mismos

• Este planteamiento basado en estados también debería poder manejar

varios estados de manera simultánea para, por ejemplo, contemplar

situaciones en las que sea necesario ofrecer algún tipo de menú sobre el

propio juego en cuestión




Visión general de una máquina de estados finita que representa los estados más comunes en cualquier juego

t2: patrones y videojuegos 3. patrones y videojuegos

Documents