Mi primera tarea consistirá en traducir el modelo EEP, comentado en la entrada anterior de este blog, de Java a C#, para poder trabajar con él en el motor de juego (Game Engine) Unity3D. Para ello, primero es necesario comprender bien la arquitectura de EEP (que viene explicada en la tesis de Luis Peña, un profesor muy majo, y mi tutor de proyecto):
El modelo EEP (Emotional Elicitation Process) está
dividido en cuatro componentes:
- Diccionarios Conceptuales (Conceptual Dictionaries – CP): proporcionan las definiciones de los elementos generales necesitados por el motor para evaluar los eventos. Por ejemplo, el tipo de Acciones que el evento podría registrar. Estos diccionarios son distintos de los Diccionarios AGCBAR (Automatic Game Controllers Behaviors with Affect Responses) y están solo relacionados con los procesos internos del modelo EEP.
- Perfil del Personaje (Character Profile – CP): define los parámetros numéricos que representan la definición general de la personalidad del personaje y la identificación del estado de ánimo (Mood State µi), en el espacio del ánimo (mood space, M). También proporciona la cuantificación de los elementos registrados por los diccionarios conceptuales. Por ejemplo, el valor que le da un personaje a la acción de Dar-Dinero registrada en los diccionarios.
- Motor de proceso de provocación emocional (Emotional Elicitation Process Engine – EEPE): descompone, analiza y evalúa un evento. También analiza las emociones y sus niveles de intensidad como resultado de la evaluación de un evento Ei.
- Espacio de vector de ánimo (Mood Vector Space – MVS): representa el estado de ánimo del personaje actual, µi. El MVS es un espacio tridimensional derivado del modelo PAD. Aquí, las emociones percibidas por un personaje son convertidas por el EEPE en vectores en este espacio, y traducen el estado de ánimo del personaje de un punto a otro dentro de los límites del MVS. Por ejemplo, un punto en concreto en este espacio puede representar un estado de ánimo de un personaje en particular en un momento en particular.
Por lo tanto, fuera del
modelo, podemos implementar las interfaces que sintetizan los eventos
generados por el entorno (Motor de Juego [Game Engine] en el caso de
la Arquitectura de AGCBAR) para poder producir los ánimos indicados
por el Motor Emocional:
- Constructor de Eventos (Event Builder – EB): dados los eventos generados por el entorno, Ei, este componente se adapta a la estructura necesitada por el EEPE. Este componente puede ser definido como un envoltorio de los eventos entrantes. Cada evento entrante puede producir de 0 a N eventos internos de EEP {εj} ∈ ε, (por la relación causal entre los eventos y sus componentes).
- Etiquetador de Ánimo (Mood Tagger – MT): los ánimos son un conjunto discreto de valores finitos que tienen su significado en el contexto del Motor de Juego. Sin embargo, el Modelo EEP opera sobre una representación continua del Estado de Ánimo, el cual está basado en la representación MVS. Es la responsabilidad del MT proyectar el estado de ánimo continuo, µi ∈ M, a uno de los valores discretos, Ti ∈ T. Este espacio de estado es la representación básica de la cual extraemos el estado de ánimo, para luego traducirlo a las etiquetas de estado de ánimo Ti ∈ T a través de la interfaz de ánimo en la arquitectura de AGCBAR.
Esta estructura de
eventos es necesaria para el análisis balanceado de las emociones.
También proporciona los parámetros cruciales para la clasificación
y cuantificación de las emociones producidas por los eventos. Por
ejemplo, los eventos están asociados conforme a sus fuentes y
objetivos, y sus consecuencias causales son traducidas como eventos
emocionales.
Además de esto, una
representación continua del estado de ánimo permite al motor EEP
operar con transiciones de grano fino (indicadas por los eventos).
También permite la proyección del número discreto de etiquetas de
ánimo definida por la arquitectura AGCBAR.