martes, 8 de diciembre de 2009

Un Modelo básico: Integrando ecuaciones de movimiento con el método de Euler

En los anteriores posts, expliqué las razones para usar MVC y la estructura general de un programa simple usando este patrón de diseño. Ahora voy a explicar la versión mas básica de un modelo: un simulador de partículas. Bajo ninguna circunstancia este modelo es un modelo aplicable directamente para un juego, pero es una primer iteración para poder implementar algunas cosas básicas como Steering Behaviors (que voy a explicar en otro post).

Este modelo considera partículas puntuales que se mueven libremente o bajo la acción de una fuerza, en un espacio de 2 dimensiones. Con este modelo simple se pueden implementar muchos tipos de juegos 2D: Juegos de plataforma, Arcanoid, Galaga, juegos de carrera o los juegos que sugirió Juan Pablo: Choplifter, Desert strike y Cannon Fodder. Que el Modelo sea 2D no implica usar gráficos 2D (el View), incluso se pueden usar gráficos 3D. Ejemplos clásicos de esto es el Wolfenstein 3D, donde en realidad el mapa es 2D, no existe la altura en el modelo, y sin embargo la representación es 3D. Un juego como Diablo, también tiene gráficos 3D siendo el modelo 2D. Con esto quiero aclarar que tener un modelo 2D no implica para nada utilizar gráficos 2D.

Derivadas

Antes que nada voy a explicar muy básicamente lo que es una derivada. Se puede encontrar una definición mas avanzada en la Wikipedia.
La derivada de la posición respecto al tiempo es el cociente entre la variación de la posición y la variación de tiempo. Si un auto avanza 10 km en 1 hora, podemos aproximar la derivada como 10km/1h=10km/h.
Pero la derivada es más que eso, la derivada implica que la variación en el tiempo sea muy pequeña. En nuestro caso, tendríamos que ver cuanto avanzó el auto en, por ejemplo, un segundo. Si el auto avanzó 3 metros en un segundo, entonces la derivada de la posición respecto al tiempo es más precisamente 3 m/1s=3m/s=10.8 m/s.
Se puede refinar el experimento, midiendo el desplazamiento para intervalos de tiempo aun mas pequeños. La derivada es el valor que obtenemos cuando el intervalo de tiempo es infinitamente pequeño:







En esta ecuación el triángulo es una forma de escribir "La variación de". O sea que la ecuación puede ser leída como "La variación de la posición, dividido la variación del tiempo". Cuando la variación del tiempo es infinitamente pequeña, el cociente se llama derivada. El caso de la derivada de la posición respecto al tiempo,  es denominada "la velocidad". Pero uno puede derivar la velocidad, o sea, dividir un cambio de velocidad por el intervalo de tiempo en que ocurre este cambio. Esta última derivada se llama "aceleración".

Cuando derivamos dos veces, se suele decir que obtenemos "la derivada segunda". Entonces, la derivada segunda de la posición es la aceleración.

Una forma de escribir la derivada es poniendo un punto sobre la variable que se deriva. Y la derivada segunda se escribe con dos puntos sobre la variable que se deriva. Pero el significado es el mismo: el cociente entre la variación de una magnitud y la variación de tiempo durante el cual ocurre el cambio.

Ecuaciones de movimiento

Supongamos que tenemos un objeto que se mueve con una fuerza FX, FY aplicada. La ecuación de movimiento mas general que se puede escribir es:


Donde m es la masa del objeto. X e Y son las coordenadas de la partícula,  y los dos puntos sobre la variable X es la derivada segunda de la posición respecto al tiempo (o sea, derivar la posición dos veces respecto al tiempo). Como dijimos anteriormente, esta derivada segunda se conoce como aceleración. "Fuerza igual masa por aceleración" es la llamada segunda ley de Newton.

Esta fórmula debe ser resuelta para obtener ecuaciones de movimiento que podamos usar. En el caso de una fuerza constante, las ecuaciones pueden ser resueltas en forma exacta:
 
Para quien sepa derivadas, es fácil ver que si derivamos la expresión de X dos veces, obtenemos la segunda ley de Newton con una fuerza constante (a0 es la fuerza dividida la masa).

Estas ecuaciones consideran solo la coordenada X. En las ecuaciones, el tiempo aparece en forma explicita como t, y los subindices 0 en la posición, velocidad y aceleración indican que se trata de la posición, la velocidad y la aceleración iniciales. En esta ecuación, la aceleración es constante, por tratarse de una fuerza constante. La segunda ecuación es la velocidad en función del tiempo, que en algunas situaciones es útil.

Las ecuaciones para las coordenada en Y son idénticas, pero reemplazando X por Y y utilizando las velocidades en la dirección Y en lugar de usar las velocidades en X y la aceleración en Y en lugar de la aceleración en X.

Estas ecuaciones tienen la limitación de que solo son válidas mientras la fuerza se mantiene constante. De cambiar la fuerza, cambia la aceleración, y las ecuaciones dejan de ser válidas. Si en general la fuerza varía en forma complicada con el tiempo, se hace imposible resolver las ecuaciones de movimiento en forma exacta.

El caso de fuerza que varía con el tiempo debe ser resuelto para cada caso particular. Las ecuaciones que resultan son en general mas complicadas. En un juego, necesitamos utilizar algún método general para resolver las ecuaciones independientemente de como varíe la fuerza.

Para hacer esto, lo mas simple es usar el llamado Método de Euler. El método de Euler es un método numérico para resolver ecuaciones diferenciales de primer orden, o sea que solo tienen derivadas primeras. La primer ecuación que mostré es una ecuación de segundo orden, pero eso puede ser resuelto fácilmente introduciendo la velocidad. La velocidad, como dijimos, es la primer derivada de la posición:






Utilizando esta definición, es posible convertir nuestra ecuación de movimiento en varias ecuaciones de primer orden, ya que la aceleracion es la primer derivada de la velocidad:

Con estas cuatro ecuaciones, tenemos solo derivadas primeras, con lo cual podemos aplicar el método de Euler.
El método de Euler consiste simplemente en volver a la definición de la derivada, y "olvidarse" que la derivada requiere que la variación del tiempo sea infinitamente pequeña. En lugar de eso, se utiliza una variacion de tiempo finita.
Usando esa aproximación, las ecuaciones anteriores resultan ser:



La ventaja de estas ecuaciones es que podemos resolverlas algebraicamente para obtener la posición de la partícula en un tiempo t, un instante de  tiempo anterior t- Dt. Simplifiquemos un poco la notación, para que sea mas evidente como resolverlas:
  • Llamemos a la posición a tiempo t utilizando un subíndice: Xt es la posición a tiempo t.
  • Llamemos h a la variación del tiempo (también llamado paso de tiempo).
  • La variación de la posición no es mas que la diferencia entre dos posiciones. O sea:


  • Lo mismo puede decirse de la velocidad. La velocidad es la diferencia de la velocidad en dos tiempos distintos:

Teniendo eso en cuenta, resultan las siguientes ecuaciones (considerando solo las coordenadas en X):








Lo bueno de estas ecuaciones, es que solo requieren una multiplicación y una suma. Además, son absolutamente generales, pueden ser usadas para cualquier tipo de fuerza(aunque en algunas situaciones puede fallar).
La desventaja, es que es el método mas simple, y el mas impreciso. En general, la precisión de este método depende del tamaño de h (el intervalo de tiempo). Si usamos un h mas pequeño, el resultado va a ser mas preciso, pero van a ser necesarios mas cálculos para encontrar el valor de la posición.

El algoritmo en Python

Veamos como se traducen las ecuaciones anteriores para el caso de un modelo con una sola partícula, en Python.

class ParticulaSimple():
   def __init__(self, x0, y0, vx0, vy0, masa):
      self.x=x0
      self.y=y0
      self.vx=vx0
      self.vy=vy0 
      self.t=0
      self.masa=masa
      
   def get_force(self):
      '''
      Devuelve la fuerza a tiempo self.t.
      '''
      ...
      return force_x, force_y

   def update(self, h):
      t, x_prev, y_prev= self.t, self.x, self.y,
      vx_prev, vy_prev=self.vx, self.vy
      masa =  self.masa
      #Obtener la fuerza a tiempo t
      fuerza_x, fuerza_y=self.get_force()

      #Actualizar el tiempo, posición 
      #y velocidad usando el método de Euler.
      #Actualiza a tiempo t+h
      self.t = t+h
      self.x +=vx_prev*h
      self.y +=vy_prev*h
      self.vx += (fuerza_x*1.0/masa) *h
      self.vy += (fuerza_y*1.0/masa) *h


El código es bastante simple. En caso de ser más de una partícula, se debe iterar sobre todas las partículas. Usando librerías como numpy todo esto puede hacerse en una sola instrucción (multiplicando matrices por vectores). Pero eso no importa ahora.

Una parte clave del algoritmo es la función get_force, que devuelve las fuerzas en la dirección x e y. Esta función puede depender del tiempo, y en situaciones mas complejas puede depender de la velocidad (por ejemplo, la fricción es proporcional a la velocidad) o también puede depender de la posición (por ejemplo, la fuerza que hace un resorte depende linealmente del estiramiento del resorte).

Para ejemplificar muestro tres tipos de fuerzas:

Gravedad cerca de la tierra

Esta fuerza es la fuerza que experimentan todos los objetos cercanos a la superficie de la tierra. Es una fuerza constante, con dirección "hacia abajo".

...
   get_force(self):
      #La constante gravitatoria es un valor 
      #que depende solamente del planeta
      #donde se está parado. 
      #Para la tierra es g=9.8 m/s^2
      #Para la luna es g=1.6 m/s^2
      
      g=9.8
      return 0, -self.masa*g  #La fuerza es vertical
      #, apuntando hacia abajo(y<0 es abajo)

   ...

Fuerza gravitatoria general

Si el objeto en cuestión se encuentra alejado del planeta, la fuerza depende de la distancia al centro del planeta. La dirección de la fuerza es directamente apuntando al centro del planeta.

...
   get_force(self):
      #En este caso, la fuerza depende 
      #de la distancia al planeta y 
      #de la masa del mismo. 
      from math import sqrt
      #Un planeta en la coordenada (0,0)
      planetaX, planetaY= 0, 0 
      #Un planeta de la masa de la tierra
      k=3.98*10^14 

      distancia_X=planetaX-self.x
      distancia_Y=planetaY-self.y
      distancia_al_cuadrado=distancia_X*distancia_X\\
         +distancia_Y*distancia_Y

      F_magnitud=k*self.masa*1.0/distancia_al_cuadrado

      x_dir=distancia_X/sqrt(distancia_al_cuadrado)
      y_dir=distancia_Y/sqrt(distancia_al_cuadrado)

      return F_magnitud*x_dir, F_magnitud*Y_dir

   ...

Fricción de aire

Esta fuerza es una fuerza que depende de la velocidad. Para velocidades pequeñas la dependencia es lineal y puede programarse de la siguiente manera:

...
   get_force(self):
      #El coefficiente de fricción 
      #es un indice de cuanta fricción hay
      # si es 0 no hay ninguna fricción 
      #(la fuerza de fricción es siempre 0)

      fric_coef=0.1
      return -fric_coef*self.vx, -fric_coef*self.vy
   ...
Por razones que no voy a explicar ahora, esta fuerza no funciona muy bien con el método de Euler. Pero se puede usar si se mantiene el coeficiente de fricción muy chico o el paso de tiempo suficientemente pequeño. Lo mejor para un juego es probar distintos coeficientes hasta encontrar un valor que dé resultados plausibles.

Errores

Este método, como cualquier otro método de integración numérica, tiene errores. Para mostrar la diferencia entre el método exacto y el método aproximado voy a usar el ejemplo de la gravedad cercana a la tierra, que tiene solución exacta. Supongamos que un personaje de un juego de plataformas viene corriendo a 7 metros por segundo, y salta adquiriendo la misma velocidad.  La velocidad inicial es 7 m/s. vertical y 7 m/s horizontal La trayectoria del personaje va a estar dada en forma exacta por:








Comparemos la solución exacta con la solución numérica usando h=0.05



Comparación de resultados para una fuerza constante en dirección vertical.

Claramente hay un error. Generalmente, para juegos este tipo el resultado sea suficiente, ya que el movimiento es cualitativamente correcto y el algoritmo usado es rápido.
Si se usa un h mas chico, el error va a ser menor (pero van a ser necesarios más FPS del modelo). Existen otros algoritmos que resultan en valores mas precisos para iguales valores de h.
Aun más, en algunas aplicaciones el método de Euler no funciona adecuadamente. Para estas aplicaciones es necesario utilizar otros algoritmos como Verlet Velocidad.

Conclusiones

Quizá la matemática de estos algoritmos sea un poco complicada. Pero programarlos es casi trivial. Existen algunas aplicaciones en las cuales el paso de tiempo h necesario para tener un resultado adecuado es demasiado pequeño, con lo cual se deben utilizar otro tipo de métodos de integración.
En una aplicación normal, la fuerza y velocidad varían según las instrucciones del controlador. En cada paso de tiempo, se llama a la función update del modelo para actualizar las posiciones y al update de la vista para utilizar las posiciones para ubicar los sprites en pantalla. A pesar de que en el modelo utilizo unidades "reales" como metros, en la vista estas unidades se transforman en pixels de pantalla.
Por ahora, para explicar Steering Algorithms, es suficiente con este método de integración. En el próximo post voy a explicar como se crea un controller que utilize fuerzas para dirigir un vehiculo a su destino.

viernes, 4 de diciembre de 2009

MVC en la creación de videojuegos II - Esquema general

En el post anterior expliqué la razón que tuve para utilizar MVC en mi proyecto de inteligencia artificial. Pero si alguien leyó el post completo, seguramente el final fue anticlimático, por no explicarse nada concreto. En este post me encargo de dar una vista a ojo de pájaro de como implementé un sistema MVC. La idea me surgió gracias al tutorial de sjbrown para escribir juegos en pygame (en ingles), por lo que hay varias similitudes. Sin embargo esa guia es un tutorial básico de pygame, que no implementa mucho mas que lo mínimo y necesario para entender el sistema MVC con Mediador. Como expliqué en el anterior post, la idea es hacer un sistema para implementar algoritmos de inteligencia artificial (IA), pero siempre con la creación de videojuegos en mente.

La primer versión de mi programa se pude representar esquemáticamente de la siguiente manera:



Esquema MVC general para un sistema de videojuegos. (click para agrandar)

El Modelo
La parte mas importante de este programa es el modelo, por ser (junto a la IA) la razón de la existencia de todo el programa. Esencialmente es una simulación física. Dentro de lo que son las simulaciones físicas, este modelo es por el momento un simulador de dinámica molecular. Básicamente un conjunto de partículas puntuales que tienen posición, velocidad y fuerzas. Hay varias formas de implementar esto, y para muchas partículas es uno de los puntos críticos de eficiencia del sistema.
La función del modelo es actualizar las posiciones y velocidades de todas las partículas en cada frame. También permite acceder agregar, quitar y acceder a las partículas y aplicarle fuerzas.
Por el momento, el modelo es 2D. Pero puede ser fácilmente adaptado a 3D.
Con este modelo se pueden implementar juegos de varios tipos: Shooters, Tower Defense, Pacman, FPSs a la antigua como el Wolfenstein y sidescrollers. Pero en general va a ser necesaria una abstracción del concepto de "Mapa" y mas adelante de "cuerpo rígido" que incluya la posibilidad de colisiones para realizar juegos con física mas avanzada.

La Vista
La vista es una representación del modelo. Actualmente hay dos vistas, una vista gráfica y una vista que solamente almacena los valores del modelo en un archivo de texto. La primera es la pantalla gráfica que todos conocemos y la segunda es utilizada para hacer un análisis mas detallado del modelo y su correcto funcionamiento.
En cada cuadro, la representación gráfica se encarga de obtener directamente del modelo la información necesaria para actualizar la pantalla. Por una razón de eficiencia, la vista accede al modelo directamente.
La vista tiene también una "cámara" que abstrae las coordenadas del modelo de las coordenadas de la pantalla. La cámara es una simple transformación de rotación, translación y escala que convierte de las coordenadas del modelo a las coordenadas de la pantallas. La cámara puede ser manipulada en tiempo real para hacer zoom, rotaciones y translaciones.
La vista actual es 2D, implementada en pygame, por ser lo mas simple. Manteniendo la misma interfaz, se puede realizar una implementación en Java o incluso una implementación 2D+1 (2D isometrica con una tercer dimensión falsa) utilizando pygame mismo o mejor aun python-ogre u otra librería 3D para python.
Actualmente, debido a que pygame posee una implementación, la colisión entre objetos se calcula en la vista. En el futuro esta funcionalidad se va a pasar al modelo, agregando el concepto de "forma" al mismo. La colisión solo se usa por el momento para funciones del mouse y otros controladores. No hay colisiones estrictas (o sea, las partículas pueden superponerse).

El Procesador de Eventos
El procesador de eventos es una implementación del patrón de diseño Mediador. Este objeto es un mensajero que media en la comunicación entre todas las partes del sistema. Es muy importante para generar una aplicación modular y de comportamiento altamente configurable. Este patrón de diseño se suele utilizar por ejemplo para programar GUIs, donde uno crea widgets que generan eventos al ser activados.
Utilizando el procesador de eventos, se pueden registrar tipo de eventos, que son asociados a funciones que "escuchan" estos eventos. Durante la ejecución del programa, los distintos componentes del programa publican eventos en el procesador de eventos, el procesador de eventos se encarga de distribuir estos eventos a las distintas funciones registradas.
Por ejemplo, se puede asociar una función que termina el programa para que se ejecute cuando se publique un evento "Tecla escape apretada", durante la ejecución del programa; cuando el usuario presione la tecla escape, el controlador de teclado publicará el evento en el procesador de eventos y el programa terminará. La ventaja de este esquema es que el teclado no tiene que conocer ningún detalle del resto de los componentes, ni quién escucha el componente. Por otro lado, se puede cambiar el comportamiento del programa fácilmente sin afectar los componentes involucrados, simplemente cambiando qué objeto escucha qué tipo de eventos.
La implementación básica del procesador de eventos no distingue entre tipos de eventos (todos los componentes escuchan todos los eventos). Mi implementación agrega "tipos de eventos". En el futuro tengo planeado implementar el concepto de prioridad y orden de eventos (el orden en que se llama a las AI puede ser importante, como descubrí recientemente).

Los controladores
Los controladores son objetos que manipulan el modelo. En un diseño general del patrón MVC un controlador puede acceder a la vista y al modelo directamente. En la práctica depende del controlador. Yo intenté mantener los acoples directos entre MVC al mínimo necesario, utilizando el Procesador de Eventos donde fuera posible.

El mouse y el teclado
Los controladores obvios son el mouse y el teclado. El mouse es por el momento el único objeto que requiere acceder a la vista en forma directa. Mas allá de eso, ambos controladores son completamente basados en eventos. En la sección de Procesador de Eventos explico las funciones.
En cada update del mouse, el objeto lee la posición del mouse y el estado de los botones y de haber alguna actualización, envía un mensaje utilizando el Procesador de Eventos. El mouse recibe del sistema operativo, posiciones en coordenadas de la pantalla, por esta razón se necesita el View para convertir estas coordenadas a coordenadas del modelo.El mouse emite eventos cuando se presiona un botón, cuando se lo deja de presionar y cuando se mueve el mouse. Cada botón tiene un tipo de evento distinto, así hay eventos "BUTTON_1_DOWN", "BUTTON_1_UP", "BUTTON_2_DOWN", etc.
El teclado es puramente basado en eventos. Genera mensajes indicando si se ha presionado/soltado una tecla en particular del mouse. Se emiten mensajes cuando se presiona una tecla y cuando se la suelta. En el mismo mensaje se indica si hay teclas modificadoras (ctrl, shift, alt) presionadas. Cada combinación de teclas tiene un tipo de evento distinto.

La inteligencia artificial
Este objeto es una abstracción del "cerebro" de las entidades del modelo. No es obvia la razón por la que la IA es un controlador en lugar de ser parte del modelo. Se puede pensar que la IA es parte de las reglas del modelo. Así como en el modelo las fuerzas modifican en forma determinista las posiciones de las partículas, uno puede pensar que la inteligencia artificial es una regla más, que modifica el modelo en forma determinista. Esta forma de ver la IA es obvia en reglas simples como los Steering Algorithms (que voy a explicar en futuros posts). Pero a medida que uno usa técnicas de IA mas elaboradas (redes neuronales, partículas), esta forma de ver las cosas se torna menos obvia. Aun mas, separar la IA del modelo es atractivo por varias razones:
  1. Facilita simular el desconocimiento que tiene una IA del mundo, si la IA fuera parte del modelo sería muy tentador hacer IAs omniscientes. 
  2. La IA se maneja en escalas temporales distintas al modelo. Por un lado, es útil que el modelo se actualice con la mayor frecuencia posible, por ejemplo 60 cuadros por segundo. Es fácil darse cuenta que una persona no tiene reacciones inmediatas, si un enemigo aparece en el rango de visión, la persona tardará en reaccionar (por ejemplo dispararle). Es sumamente atractivo transladar esta limitación a las IA, para ponerlas en igualdad de condiciones. En lugar de llamar al update de las IA 30 veces por segundo se puede llamar 10 veces por segundo, simulando un retardo en las reacciones de la IA similar al de un humano.
  3. Una misma IA puede actuar con los mismos algoritmos sobre distintos modelos. Asi, si en el futuro hago un modelo 3D, las IA pueden permanecer (en muchos casos, pero no todos) sin cambio y aun ser útiles.
  4. La IA no es tan prioritaria como el modelo. Se pueden aplicar técnicas avanzadas sobre las IA para balanceo de carga del CPU. [1] Ya que la evaluación de las IA no es prioritaria en ciertos contextos.
Por una razón de eficiencia, la IA posee acceso directo al modelo.
Para explicar el esquema MVC mas fácilmente supuse que hay una sola IA en este post. En realidad hay muchos tipos de IA implementadas en mi proyecto (10 al momento de escribir esto), todas pertenecientes a la categoría "Steering Algorithms". En un post futuro voy a explicar en detalle eso.

El reloj de sistema
Este objeto es el "corazón" del programa. Es un objeto muy simple que solamente se encarga de generar eventos indicando un nuevo frame del programa. Es una abstracción ingeniosa del bucle principal del programa. En lugar de hacer un bucle infinito en el cual se llama a cada objeto del programa, se generan eventos a una frecuencia dada, que luego son distribuidos por el procesador de eventos entre los distintos componentes que requieren un update periódico. Para inicial el programa, se ejecuta el reloj de sistema. Para pausar el programa, se detiene el reloj.
En la implementación actual del programa el reloj de sistema emite un mensaje "TICK" en cada frame del programa, a un ritmo predefinido. En próximas implementaciones, el reloj de sistema va a tener distintos tipos de TICK para distintas frecuencias, permitiendo actualizar distintos componentes del sistema a distintas frecuencias. Así será posible actualizar, por ejemplo, el modelo a 40 FPS, el view a 30FPS y los controllers a 10FPS.

Conclusión
Como dije al principio, esta es una vista general del programa que estamos programando. El código se puede descargar del repositorio SVN público.
En próximos posts voy a explicar mas concretamente varios puntos que no necesariamente están relacionados con el esquema MVC. Voy a explicar las bases de una simulación física de dinámica molecular, incluyendo algunos algoritmos concretos, voy a explicar también qué es un Steering Algorithm. Volviendo al tema MVC también voy a explicar algunos problemas que encontré en las implementaciones iniciales y como fuí solucionandolos.


[1] "An Efficient AI Architecture Using Prioritized Task Categories" Alex W. McLean - AI Game Programming Wisdom 1. Capitulo 6-3 p290 [volver]

lunes, 30 de noviembre de 2009

MVC en la creación de videojuegos - Introducción

En el último tiempo, estuve muy interiorizado en la programación de aplicaciones web utilizando Frameworks como Ruby on Rails y Joomla Framework (me refiero al Framework PHP detrás del CMS). Ambos tienen una característica en común, que están diseñados siguiendo una filosofía Model-View-Controller (Modelo-Vista-Controlador).

Este tipo de arquitectura se basa en separar una aplicación en tres módulos independientes. El Modelo son los datos que se manejan en la aplicación, las Vistas son las distintas formas de presentar los datos al usuario, el Controlador es la forma que tiene el usuario de manipular los datos. También se suele agregar un Mediador que no es mas que un objeto que se encarga de coordinar la comunicación entre los componentes. De esta forma se evitan dependencias fuertes entre las interfases de cada componentes, y mas importante, se genera una reusabilidad sorprendente en las aplicaciones que programamos.

Hace poco, con un amigo decidimos empezar un pequeño proyecto para probar distintas técnicas de inteligencia artificial en tiempo real. La idea es comenzar con los clásicos Steering Behaviors de Craig Reynolds, extenderlo a Flocking y Squads y después implementar técnicas mas avanzadas (aunque tampoco totalmente novedosas) como Automatas Celulares, para simulación de fenómenos físicos como explosiones, y filtros de partículas para simular el conocimiento que tiene la AI del mundo que la rodea.  Todo esto, ejemplificado con pequeños juegos que muestren las técnicas. Voy a ir mostrando en este blog las distintas técnicas, ejemplificandolas con Applets cuando sea posible.

El primer problema que hace años que no programo en Java y no tenía ganas de empezar inmediatamente a refrescar esos conocimientos. En lugar de eso me propuse utilizar Python, un lenguaje que permite programar en forma veloz, generalmente para realizar prototipos de programas que luego pueden ser reimplementados en lenguajes "de gente seria" o, mi preferida, optimizados implementando solamente partes críticas en lenguajes de mejor rendimiento.

Otra ventaja que tiene Python, es la posibilidad de crear Applets Java mediante la utilización de Jython. Utilizando esta implementación de Python en Java, es posible compilar código Python puro (que no depende de bibliotecas externas) e incluso utilizar bibliotecas externas de Java (imprescindible si se quiere mostrar gráficos y acceder al mouse).

Mientras tanto, y hasta tener algo para mostrar en este blog, voy a utilizar Python para programar, Pygame para acceder al hardware (mouse, teclado, display y reloj del sistema) y numpy para los cálculos que requieran mayor eficiencia.

Viendo ese spaghetti de requerimientos, necesitábamos asegurarnos una buena separación de lo que es Pygame y Numpy (librerías externas que no pueden ser llevadas a Java) de lo que es código Python puro. Y a la vez, necesito que sea fácil introducir Java y sus bibliotecas cuando decidamos implementar Applets.

Elegir una arquitectura MVC pareció la solución mas atinada. De esta forma, el View principal y los Controllers del mouse y el teclados serían implementados usando Pygame, heredando de una clase abstracta general. En un futuro se puede reimplementar la misma clase abstracta en Java. El modelo y el mediador, por otro lado, no tendría ninguna dependencia de este tipo de librerías.

Veamos ahora la estructura mas concreta y los dilemas típicos que surgen al utilizar MVC para juegos. Voy a utilizar como ejemplo la aplicación que tengo desarrollada hasta el momento. Por supuesto que iré refactorizando en el futuro y cuando sea necesario explicaré los cambios en este blog. El código al día se puede descargar en el repositorio SVN, no soy ningún gurú de programación, con lo cual se aceptan sugerencias e ideas.

En el siguiente post voy a explicar a grandes rasgos como diseñé la primer versión de la aplicación (Casi un esqueleto con capacidades mínimas en el momento de escribir este post) utilizando MVC.

Ver siguiente post.

sábado, 7 de noviembre de 2009

Tarde pero seguro: Sidewiki para Google Chrome

Es raro esto de usar Google Chrome.

El navegador en sí es rápido, pero le faltan muchos de los agregados de Firefox. Seguramente ambas cosas estén relacionadas. Y encima uno se siente un ciudadano de segunda en el mismo mundo Google, ya que varias aplicaciones que google desarrolla tardan en estar disponibles en Chrome.

Ahora llegó Sidewiki para Google Chrome. No es lo mismo que en Firefox, donde el sidewiki es realmente un sidebar. Esta versión es un bookmarklet que se arrastra de la página de ayuda de Chrome hasta la barra de bookmarks (la barra se activa con ctrl-b en Chrome). Una vez puesto el bookmarklet en la barra, uno puede activar un "popupwiki" donde se tiene las misma funcionalidad que en el sidewiki... algo es algo.

Para ver mis, pocos, comentarios en sidewiki: http://www.google.com/profiles/ezequiel.pozzo#sidewiki

domingo, 27 de septiembre de 2009

Lo concreto y lo etereo

Acabo de leer una nota de Horacio Verbitsky y una de Eliseo Verón. Veo por un lado que hay una repetición de las mismas consideraciones entre los artículos de opinión que se oponen a la ley. Y por el otro, entre los que están a favor, siempre encuentro nuevos argumentos y puntos de vista, en particular encuentro que se focalizan en puntos concretos y los analizan.
La nota de Verbitsky tiene una primer parte que gira alrededor de los argumentos legales que se le hace a la ley. Y luego los refuta en forma concreta y documentada. Luego sigue con una consideración sobre la influencia de los medios en la sociedad y el punto de inflexión entre la relación Clarín-gobierno. Y termina con una pequeña reseña histórica sobre el proceso mediante el cual, parafraseando a los genios de marketing de TN "1800 cables y varios canales 'desaparecieron'". Esta ultima parte me hizo recordar de mi tan querido "Cablin" y me acordé que Morgado era conductor de ese canal.

La nota de Verón es mas académica. La cuestión de fondo es la que ya se ha dicho mil veces "los K son malos, autoritarios y están atacando al grupo Clarín". Pero en el caso de Verón es justificable que haga este análisis ya que Verón es un semiologo, con lo cual es natural que haga un analisis de los significados.

Es importante recalcar, que un análisis de significado es en mayor o menor medida subjetivo. Y mas alla del enfoque académico, y la prosa que recuerda a un libro de filosofía, el contenido concreto no es nada que no se haya dicho y escrito miles de veces en forma mas chapucera (ver Joaquín Morales Solá o Silvina Walger en un post anterior)

Algunos puntos para destacar:
  • [Darle el dinero a los pobres no ocurrió] y los 600 millones de pesos fueron usados para pagar a la AFA:
    • Este es el viejo argumento que esconde los supuestos de que el fútbol es un negocio que da perdida. Yo no tendré una prosa tan refinada como la del semiólogo, pero se notar cuando se esgrime un argumento pedorro que ya fue criticado. Veremos que pasa en unos años, cuál es el saldo del negocio del fútbol cuando se hayan vendido las licencias, publicidad y demás. Por ahora, es un simple golpe de efecto.
  •   a los componentes del tercio privado sin fines de lucro (comunidades, entidades no gubernamentales, sindicatos, etc.) difícilmente se los puede imaginar adoptando actitudes de crítica hacia un gobierno que les ha otorgado la explotación de ciertos medios, y la liberación de numerosas licencias permitirá colocar en el tercer tercio, comercial privado, a buen número de aliados actuales y potenciales del kirchnerismo.
    • Acá el semiólogo abandona toda pretensión de explicación y simplemente tira el cliché de "se van a quedar con los medios" sin mas. No trata de analizar la autoridad de aplicación, o considerar los mecanismos precisos mediante los cuales un gobierno corrupto podría coercionar a los licenciatarios. El postula "difícilmente se los puede imaginar" y "permitirá [beneficiar a muchos aliados] actuales y potenciales del NK" y deja el resto a la imaginación del lector. Seguramente un lector convencido pueda llenar los blancos de este razonamiento con mil fantasías y expectativas, pero uno esperaría que el rol de un analista es analizar, y no estimular la imaginación.
  • Todo discurso es sintomático y el de Cristina Kirchner no escapa a esta regla.
    • Supongo que el lector promedio del diario Perfil entiende perfectamente lo que esa frase significa.
  • Considerados en sí mismos, nadie puede estar en desacuerdo con estos principios, que son la base de las legislaciones que reglamentan el campo de los medios de comunicación en la mayoría de los países “centrales” y particularmente en los países de la Unión Europea, cuya legislación fue ampliamente utilizada por los redactores de la ley aprobada en la Cámara de Diputados. Pero es un grave error olvidar que las consecuencias de la aplicación de una ley no pueden ser evaluadas sin tomar en cuenta la cultura política del país en que se la discute y las metodologías que se ejercitan desde el Ejecutivo.
    • El problema de esta frase es doble. Primero por ser una falacia de ataque ad-hominem, luego de este párrafo se procede a explicar que el gobierno tiene malos motivos para impulsar la ley. Yo digo que si bien el fin no justifica los medios, los medios tampoco refutan el fin. Podemos atacar todo lo que se quiera los motivos ulteriores de la presidenta y como hace las cosas, pero eso en ningún momento es una refutación de la ley en si. (mas allá de algún punto concreto que se pueda llevar a la justicia o se pueda demostrar violatorio de las reglas de juego de la democracia)
    • El segundo problema de esta frase es que se centra, básicamente, en argumentar que no somos un pais Europeo. No explica específicamente las diferencias entre la cultura política de Argentina y un pais Europeo (también lo deja a la imaginación del lector), pero algo es claro: los problemas de la cultura política de este pais no van a terminar con este gobierno ni con el siguiente, con lo cual es poco constructivo utilizar ese argumento para refutar los puntos objetivos de una ley.  Porque se desprende de allí que para tratar esta ley tendríamos que tener un sistema de políticos probos e interesados por el bien común, un acceso libre a la información y una visión clara y no parcial sobre el asunto.  O sea, no podríamos sancionar la ley nunca.
  • Lo que hay que entender es que estas tres lecturas se adicionan, y que el proceso político en curso (como todo proceso político-social) es multidimensional. Focalizarse en los contenidos ideológicos del proyecto, descuidando las otras dimensiones (todas las intervenciones de la señora presidenta han estado destinadas a empujar en esa dirección) es precisamente caer en la trampa de la metodología kirchnerista. Ese parece ser el caso de los socialistas –si hacemos de su actitud la evaluación más benévola posible, a saber: que han sido políticamente ingenuos.
    • Acá el escritor parece olvidar que además de los contenidos ideológicos y los contenidos "de otras dimensiones" (o sea, consideraciones propias del escritor que apelan a millones de argumentos aledaneos), además de esos puntos, están los puntos concretos, objetivos y numéricos de la ley. El intelectual se pierde en sus propias consideraciones y llega a una conclusión que olvida lo fundamental en una acción: los resultados concretos y materiales que de ella se desprenden. Quizá sea esto una deformación profesional. No lo se.
    • Por lo tanto, hay una evaluación mas benévola que la que hace el escritor sobre el voto socialista. Esta evaluación es considerar que han incurrido en el pragmatismo de votar una ley que corresponde cuantitativamente (además de ideológicamente) con su propio parecer y con las leyes que ellos mismos han defendido en el pasado. Esto es todo lo contrario a ser ingenuo. Ser ingenuo sería, luego de varios intentos fallidos de promover una ley de la democracia, frenar el avance de esta ley argumentando que "algo huele mal". Algo siempre va a oler mal en este país lamentablemente.
En la oposición, todos se han vuelto un poco semiólogos con este gobierno. Tratando de analizar los significados detrás de cada discurso, acción o gesto de la presidenta y el ex presidente. Pero no olvidemos que mas allá de los motivos ulteriores, están los hechos concretos.
Y en ese juego, muchos fallan en explicar de que manera concreta esta ley puede llegar a ser usada por el  gobierno, para en el plazo de 2 años tomar las riendas de las telecomunicaciones argentinas y utilizarlas a su favor. Fallan en explicar como un gobierno con una reputación en descenso puede lograr en 2 años crear y aceitar una maquinaria que le llevó al grupo Clarín 30 años de construcción, para luego llevar a cabo su supuesto plan de ser reelectos en las próximas elecciones, sin encontrar en el camino ninguna oposición de parte de diputados, senadores, jueces, partidos políticos opositores. En todo este juego etéreo de argumentaciones, retórica e "hipnopedia" (gracias Verbitsky) se olvidan dar dos pasos al costado y analizar lo concreto y material.

lunes, 21 de septiembre de 2009

El espejo

Hoy leí un articulo en un blog que me dejó pensando

A mi me parece interesante el concepto de que las propuestas son generalmente universales, porque corresponden a lo que el político cree que los votantes piden. La campaña de un político en tiempo de elecciones es una épica creada por un asesor de marketing. El político en tiempo de elecciones es un espejo de las esperanzas del electorado.

Es así, que votar por "propuestas" puede ser un acto de vanidad: Una persona puede cometer el error de votar al candidato que mejor refleja sus expectativas, sin tener en consideración lo razonable de sus expectativas o qué tan probable es que sean satisfechas. Por esto es mas importante ver el desempeño de los candidatos en actos concretos fuera de campaña que la campaña en si.

Me parece que hay algo que está perdido (si es que alguna vez lo hubo) en el proceso democrático, y es el uso de la información. No parece haber en la población una necesidad de datos concretos. Los programas políticos actuales, por ejemplo, son mas bien una serie de entrevistas y encuestas. Las notas periodísticas se enfocan mas en el lado humano de los hecho, lo subjetivo, que en el contexto cuantitativo. En esta situación, no es extraño que un candidato apoye su campaña en lo general y ambiguo mas que en lo concreto.

Internet, y estoy consciente de que esto es un cliché, es una herramienta que puede mejorar notablemente el acceso a la información. Las redes sociales y los blogs permiten desenterrar en forma eficiente los cadáveres que cada político con trayectoria tiene en su haber. Uno podría soñar con un sitio utópico de internet que permita obtener un CV "no autorizado" de cada político, o una serie de links para adquirir un contexto sobre una determinada situación. Es en parte esa idea que me llevó a escribir este post.

Pero hay una ingenuidad en ese concepto. Porque lamentablemente, en cierto modo no es tan importante la posibilidad de acceder a la información si no hay voluntad de utilizar esa información. La vanidad es la excesiva confianza en la propia capacidad. Y una persona que es vana intelectualmente, no siente la necesidad de buscar la información fuera de su propia persona. A una persona vana le basta con su ser y un espejo para poder tomar todas las decisiones.


domingo, 20 de septiembre de 2009

2090

¿Que significa el consenso? Si yo no puedo ceder a mi enemigo sin que sea puesta en duda mi integridad y se me acuse de estar cooptado.

¿Que significa consensuar? Si no puedo otorgar sin que esto sea visto como un signo de debilidad, una marcha atras, un mero "juntar voto".

Por qué esa contradicción de gritar a cuatro vientos, y de forma espontánea, "Alguien tiene que ceder", salir a la calle a clamar "alguien tiene que ceder", pero nunca ceder.

Son épocas como estas en las que me siento desesperanzado. Veo como la opinión de personas que se supone que deben iluminar sobre la realidad se tiñe de una antiintelectualidad trágica, que tilda de "monos y progres" a quien da su voto sincero. Un párrafo después de vanagloriarse de la deshonestidad de discutir las personas antes que las ideas. Sin siquiera detenerse a explicar ningún tipo de afirmación, por mas increíble que sea, justamente porque la credibilidad es hoy en día una cuestión meramente subjetiva.

Estamos en una época donde las leyes ya no se discuten por sus artículos, si no que se discuten con nombre y apellido y esgrimiendo consideraciones y argumentos infalsables. Los artículos de opinión periodística son un trabajo de construcción Ptolomeica, que apelan a lo que sobreentiende (pero nunca se demuestra), a lo que no se define (pero se repite hasta el hartazgo) y a lo que no puede ser refutado (y sin embargo se lo considera intelectualmente honesto, por alguna magia de la retórica).

Mi teoría es que estamos gestando una neolengua. Donde dialogar significa "callar"y ceder significa "resistir". Donde la oposición solo puede oponerse, y el que acompaña solo puede ser cómplice. Donde la magnitud de la evidencia necesaria disminuye proporcionalmente a la magnitud de la afirmación esgrimida.

Un país donde no se admiten los principios, solamente las alineaciones.

domingo, 23 de agosto de 2009

La necesidad de OpenID

¿Cuantas veces uno llega a un sitio que podría resultar interesante, pero lo abandona en el momento de registrarse?

En algunos sitios, el proceso de registrarse surge como una manera de garantizar privacidad y permitir personalización. Sin embargo en otros sitios, se exigen datos privados (email, nombre, dirección) sin que haya una necesidad verdadera. Un ejemplo de sitios donde es necesario identificarse puede ser un webmail, para mantener la privacidad del correo. Un ejemplo de un sitio donde es innecesario es un diario online, donde no hay razón para exigir al usuario identificarse antes de leer una noticia.

Sea cual sea la razón, el proceso de registración implica varios puntos negativos para el usuario:
  1. Pérdida de tiempo en el proceso de registrarse.
  2. Entregar información privada a desconocidos.
  3. Encontrarse ante la situación de tener que manejar una cantidad cada vez mayor de nombres de usuario y contraseñas o...
  4. Tener que conformarse con recurrir a un numero reducido de contraseñas que son reutilizadas en distintos sitios.
El primer punto es solo una perdida inmediata, pero los siguientes tres puntos pueden llevar a una pérdida mayor de datos (hackeo de cuentas).

Esto hace que uno se plantee muchas veces evitar conocer nuevos sitios. Personalmente, me encontré en la situación de descubrir 5 redes sociales sobre un mismo tema pero finalmente entrar solo a un par, para evitar el problema de tener que registrarme 5 veces.

Es aquí donde entra OpenID. OpenID es una tecnología reciente, que permite a los usuarios obtener una identificación reutilizable. La idea es que uno registra su nombre de usuario y password en un sitio de confianza, y luego lo utiliza para ingresar en cualquier sitio que soporte esta forma de identificación.

Asi, por ejemplo, uno puede crear un OpenID en Google Accounts y luego utilizarlo para ingresar a Scribd, StackOverflow, StumbleAudio, o cualquier otro.

Es asi que cuando llego a uno de estos sitios, especifico que poseo un OpenID de Google, para luego ser redirigido a Google Accounts, donde verifico mi nombre de usuario y contraseña. Una vez que termina el proceso de identificación, Google me envía nuevamente al sitio inicial.

En forma efectiva, OpenID es una tecnología para delegar el proceso de registro e identificación de usuarios a una empresa en la que el usuario confíe.

Pero... ¿No es poner todos los huevos en una sola canasta?

Efectivamente, uno puede utilizar esta tecnología para tener un solo usuario/password. En caso de que alguien descubra estos datos, puede ingresar a cualquier sitio donde el usuario esté registrado.

Sin embargo, en la actualidad la situación no es mejor. Los métodos de recuperación de password mediante una cuenta de email presentan la misma vulnerabilidad. Un intruso que descubra el nombre de usuario y password de tu cuenta de email puede usarlo para "recuperar" la contraseña de cualquier sitio donde estés registrado con ese email. Mucha gente se preocupa en mantener distintos usuarios y contraseñas para miles de sitios, pero usa el mismo email en cada una de las cuentas, lo que implica que efectivamente solo tienen un password (el de la cuenta de email) mediante el cual se puede acceder a todas las otras cuentas.

La solución es... no poner todos los huevos en una sola canasta. Esto significa que uno puede crear distintos OpenIDs y utilizarlos en distintos contextos. Uno puede tener un OpenID para utilizar en sitios prescindibles, con un password fácil de recordar, y tener un OpenID para usar en sitios donde la seguridad es crítica.

OpenID es una herramienta destinada a simplificar la vida del usuario e incrementar la seguridad en muchos aspectos. Pero no es una solución invulnerable.

¿Cómo conseguir un OpenID?

Eso es fácil, probablemente ya tengas un OpenID sin saberlo:
  • Si tenés una cuenta de Google (gmail, google docs, analytics, etc) o Yahoo ya tenés un OpenID.
  • Si tenés un blog en blogger o Wordpress, tu OpenID es la dirección misma del blog (Por ejemplo, ezequielpozzo.blogspot.com es un OpenID válido)
Pero también hay muchos otros proveedores de OpenID, en particular hay empresas cuya única función es proveer OpenID de manera segura.

¿Cómo instalar OpenID en mi sitio?

Eso depende del sitio. Si uno tiene un blog en blogger, es posible activar OpenID para permitir a los lectores dejar comentarios identificándose con su OpenID.

Pero todos los sistemas gestores de contenido como Joomla o Drupal y Frameworks como Django o Ruby on Rails tienen agregados que permiten soportar OpenID.


En otros posts voy a explicar otros planteos frequentes contra OpenID y como OpenID es parte de una serie de tecnologías como Open Social que otorgan mas libertad al usuario sobre sus datos privados e información personal.

Licencia


Creative Commons License
Esta obra de Ezequiel Pozzo se encuentra bajo una licencia Creative Commons Atribución-No Comercial-Compartir Obras Derivadas Igual 2.5 Argentina License.
Se puede obtener permisos mas allá de los otorgados por esta licencia en ezequielpozzo.blogspot.com.