Esta nota es continuación de su primera parte, la cual es conveniente leer, además de visitar y ver los avances en RealidadEmpoderada.com.
La aplicación Realidad Empoderada no tendrá como misión la simulación de personas indigentes (v-indigentes), sino la simulación de praxis social, con el fin de poder brindar a los usuarios una experiencia transformadora sobre el ejercicio de la solidaridad, el acompañamiento y la desconstrucción de premisas y modelos preestablecidos.
Cada v-indigente posee asociado un sistema de control o máquina virtual que provee capacidades de interacción con los usuarios, los objetos del mundo virtual y la posibilidad de reproducir comportamientos y simulaciones de tipo fisiológico. Esta máquina virtual puede cargar código externo a la plataforma, conteniendo los modelos descriptos, para luego darles latencia o, mejor dicho, poner en funcionamiento dichos mecanismos internos del v-indigente. De esta manera, investigadores y administradores zonales podrán definir la dinámica de cada indigente sin necesidad de desarrollar directamente dentro del sistema, en un contexto de rutinas complejas y recursos gráficos internos de la plataforma. Externamente se podrá conformar el comportamiento y las reacciones de cada v-indigente para que este se comporte como un ente autónomo y con historia.
Actualmente, el sistema cuenta con una matriz de comportamientos definibles externamente, pudiéndose definir cuáles rutinas y con qué parámetros se asignan a un v-indigente.
A su vez, la máquina virtual facilita la programación externa de primitivas o rutinas propias del v-indigente, pudiendo ser estas comunes a todos los v-indigentes o a determinados grupos. Estas primitivas también pueden operar con variables y objetos del mundo virtual de Realidad Empoderada, con la finalidad de que el v-indigente pueda tener percepciones del entorno e interactuar con el mismo. Estas funciones elementales pueden, a su vez, ejecutar comportamientos en forma condicional y secuencial.
Los comportamientos pueden gobernar la ejecución de ciertos movimientos del v-indigente en el medio virtual. Lo más grandioso es que brinda a los administradores la posibilidad de crear nuevas variantes de movimientos en función de clips de movimientos preexistentes o agregando nuevos. Todo ello en forma independiente de la plataforma, sin tener que programar o modificar el sistema, sino más bien definiendo dichas variantes desde mecanismos externos para que luego el sistema los incorpore como nuevos recursos.
Si bien el procesamiento es secuencial, la máquina virtual que posee cada v-indigente simula el procesamiento paralelo de procesos. Es decir, transforma el procesamiento secuencial en procesos con comportamientos simultáneos, dando vida a complejas redes de nodos, donde cada nodo posee entradas, unidades de cálculo y salidas. A su vez, estas redes pueden conformar autómatas o complejos sistemas de bloques de cálculo y accionamiento paralelo. Dicha capacidad hace posible recrear comportamientos de la misma manera en que se producen en el mundo real.
Esto conforma la base esencial para contextualizar los comportamientos según la cultura, las condiciones sociales de cada momento y grupo social, y demás particularidades propias de las complejidades del acompañamiento en sí mismo.
Cada avatar de v-indigente es una variable de instancia de la clase Indigente; esta clase, a su vez, posee un objeto instancia de la clase Ente. Esta clase Ente es la que define la máquina virtual. Asimismo, admite organizar la estructura en grupos de “Sistemas de Simulación” (SimulatedSystems). Cada Sistema de Simulación puede contener autómatas determinísticos y procesos definidos por bloques de funciones. Todo ello facilita la operatoria de variables locales y remotas de cada sistema.
Pueden definirse estados de determinadas variables de un Sistema de Simulación para que disparen la carga de otros Sistemas de Simulación. Además, cada Sistema de Simulación puede desactivar o eliminar otros módulos de simulación.
Todo este proceso de ejecución es ejercido por medio de la máquina virtual, que hace posible apilar los sistemas a ser ejecutados para luego ser activados según su jerarquía y permisos de simultaneidad. Esto evita que dos comportamientos o movimientos que no deben ser ejecutados simultáneamente puedan activarse al mismo tiempo.
Como ya he explicado, cada Sistema de Simulación puede ser definido de manera independiente por administradores o expertos locales, conformando complejas reglas de comportamiento y simulación de praxis.
De esta manera, los administradores e investigadores locales editarán comportamientos que, según las lógicas y funciones definidas, se ejecutarán a partir de los eventos internos del v-indigente y sus percepciones del mundo virtual.
Esquema simplificado del proceso de control y ejecución de comportamientos
Como todo sistema virtual que genera procesos ejecutables, se requiere de un mecanismo de recolección y eliminación de basura, de manera tal que los ciclos de copia, habilitación y deshabilitación de sistemas de simulación no vayan generando la acumulación de estructuras de datos en desuso. Cada elemento ejecutable en la Máquina Virtual del v-indigente posee un proceso de eliminación.
Manejo de percepciones y relaciones con objetos del mundo virtual en el v-indigente
Los autómatas y procesos que conforman un Sistema de Simulación tienen la posibilidad de evaluar redes de nodos de cálculo y funciones primitivas. Los tipos de nodos existentes pueden ser de distinta clase según el tipo de datos a usar en sus cómputos, y además según su capacidad de detectar parámetros y sensores que perciben el entorno. Un ejemplo sencillo sería la clase de nodos “MeetDadorEnter”, que detecta cuando un avatar de acompañante (usuario del sistema) está a una distancia menor a la de encuentro.
Código de ejemplo de un autómata para detectar la proximidad de un acompañante (usuario)
GroupSystem: Sensores
SimulatedSystem: Meet
AUTOMATA: Testeo
State Meet1
Asincronic
ThisisinitialState+
OUT true MeetDador
Trans MeetDadorEnter==true Meet2
End;
State Meet2
Asincronic
OUT false MeetDador
Trans MeetDadorExit==true Meet1
End;
TriggerVariables
MeetDador : 1
EndAutomata;
EndSimulatedSystem;
EndGroupSystem;
Se define el autómata de nombre “Testeo”, que posee dos estados: “Meet1” y “Meet2”. Ambos autómatas están seteados como asincrónicos, es decir que su cambio de estado depende de la modificación de las variables y sus condiciones en la función Trans (transición a otro estado si la condición es válida). Está indicado como estado inicial “Meet1”. Las funciones/comandos OUT son ejecutados al ingresar a cada estado. De esta manera, la variable “MeetDador” toma el valor “true” al ingresar el autómata al estado “Meet1” y “false” al cambiar a “Meet2”.
La sección “TriggerVariables” define que, si “MeetDador” toma el valor “true”, se disparen las tareas agrupadas bajo el nomenclador “1”.
El nodo “MeetDadorEnter” toma el valor “true” si el acompañante se acerca a una distancia de encuentro del v-indigente, y el nodo “MeetDadorExit” al alejarse. Por lo tanto, al acercarse el acompañante, el autómata transiciona al estado “Meet2” y la variable “MeetDador” toma el valor “true”; al alejarse, el autómata vuelve al estado “Meet1” y “MeetDador” pasa a “false”.
En esta secuencia, al cambiar la variable trigger “MeetDador” a “true”, el mecanismo podría disparar la carga de un Sistema de Simulación (SimulatedSystem) correspondiente a una reacción o comportamiento.
Por supuesto, es un ejemplo de código editable para definir un sistema de percepción dentro del indigente desde un archivo externo a la aplicación Realidad Empoderada. Estos códigos serán interpretados durante la carga del sistema o en tiempo de ejecución, permitiendo operar en tiempo real. Falta aún desarrollar una manera de guardar código compilado para ser cargado directamente por el v-indigente, sin requerir interpretación.
Esquema en bloques de la maquina virtual de simulación de praxis social para cada v-indigente
El diagrama de bloques anterior muestra los sistemas virtuales que generarán los comportamientos del indigente virtual y permitirán recrear la praxis social.
Los bloques 1 y 2 corresponden a la unidad de procesamiento que permite simular procesos y autómatas. La sección 1, en especial, detecta situaciones, lugares y otras sensibilidades que actúan como disparadores de tareas o comportamientos secuenciales (bloques núm. 3). Las tareas generadas se acumulan en una pila para ejecutarse según su categoría o prioridad. Este mecanismo también disgrega o descompone las tareas en subtareas de diferentes categorías para su ejecución.
Existe además una base de Patrones de Comportamiento (núm. 5), que contiene microinstrucciones para que la unidad de procesamiento determine las diferentes maneras de proceder del indigente virtual. Los Factores Personales (núm. 6) adaptan estos comportamientos a las particularidades de cada indigente virtual. Como los códigos fuente de las rutinas de micro-funciones están definidos en forma externa a Realidad Empoderada y se compilan [4] al ejecutarse (en runtime), otorgan flexibilidad al sistema.
Los bloques referenciados con el núm. 4 controlarán, por un lado, el procesamiento simultáneo de tareas según sus características y grados de libertad. Por último, todos los movimientos y clips de animaciones que deben reproducirse son procesados por el bloque de ejecución de movimientos.
Reflexión final
Siempre existirá en Realidad Empoderada una tensión en cuanto a qué cosas deben estar definidas en la aplicación y qué en las fuentes externas, con el fin de no complicar la edición de rutinas por parte de usuarios o administradores locales.
La implementación de Realidad Empoderada se convierte, en su complejidad, en una tecnología no colonizadora: combina partes predefinidas con edición externa de la dinámica (local o por expertos), sin depender de programadores especializados. De esta manera, la funcionalidad de la simulación podrá configurarse según las características del contexto regional, con intermediaciones mínimas respecto del núcleo técnico central.
Somos conscientes de que los desafíos a enfrentar en este proceso aún son muchos. No es posible, ni tampoco deseable, realizar una planificación acabada, dado que el propio sistema debe permanecer abierto; si cerramos o sellamos partes del mismo, estas no podrán adaptarse a los continuos replanteos y evaluaciones prácticas de los algoritmos que se van generando.
Desarrollar sobre el camino y desde una conciencia no colonizadora —es decir, no cerrada a lo diferente ni a otros contextos— constituye nuestra convicción de un desarrollo no opresor ni dominante.
Lecturas adicionales:
Sección de avances de Realidad Empoderada.
“Una nueva etapa en el desarrollo de Realidad Empoderada: las percepciones”, Realidad Empoderada
“Desarrollo y avances para la simulación de la praxis social solidaria”, Realidad Empoderada
“Poniéndole movimiento y capacidad de interacción a los avatares”, Realidad Empoderada
Sé el primero en comentar