Jad Engine Blog

MVP otro año más

Vicente — Mon, 06 Jul 2009 14:30:34 GMT

Hace unos días recibí una noticia que la verdad me hacía mucha ilusión recibir: he sido renovado como MVP de DirectX/XNA :) Este es mi segundo año como MVP y estoy encantado de poder seguir participando en esta tecnología que personalmente creo que tiene mucho futuro (aunque los principios siempre sean difíciles).

Además este año (que yo sepa) se nos unen como MVPs de DirectX/XNA dos personas que admiro muchísimo: Iñaki Ayucar (¡otro español!) y Promit Roy. ¡Enhorabuena a ambos!

El patrón Singleton en C#

Vicente — Wed, 20 May 2009 15:21:00 GMT

Una de las cosas que creo es importante cuando usas un lenguaje es entender como funciona por dentro. Por ejemplo es cierto que C# se parece mucho a Java pero a bajo nivel presentan muchas diferencias de filosofía y diseño que creo son importantes de entender para hacer un uso eficaz del mismo. Algo similar ocurre cuando alguien que está acostumbrado a C++ se pasa a C#, muchas veces piensa que es un C++ “fácil” (sin punteros, sin gestión de memoria) y luego se queja de que su rendimiento es mucho peor, que va lento,… cuando a veces todo esto es porque está usando C# como si fuera C++ y las cosas no funcionan así.

Un ejemplo de libro de esta situación es la implementación del patrón Singleton en C#. Si buscáis un poco, en muchas páginas webs para implementar un Singleton lazy y thread-safe en Java/C++ se recomienda la siguiente implementación:

public sealed class Singleton
{
    static Singleton instance = null;
    static readonly object padlock = new object();
    Singleton()
    {
    }
    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                lock (padlock)
                {
                    if (instance == null)
                    {
                        instance = new Singleton();
                    }
                }
            }
            return instance;
        }
    }
}

La sintaxis es de C#, pero lo importante es la idea del if/lock/if. A esto se le llama double-checked-locking y por motivos bastante sutiles esa implementación no es totalmente thread-safe (más detalles en este paper). El problema de thread-safe se puede solucionar haciendo la variable instance volatile (a partir de la JDK 5.0 y Visual C++ 2005, ni idea en otros compiladores de C++).

El problema es que como mucha gente de Java/C++ se ha acostumbrado a implementar el Singleton de esa manera, cuando llegan a C# hacen lo mismo. Pero resulta que en C# la implementación correcta es la siguiente:

public sealed class Singleton
{
    static readonly Singleton instance = new Singleton();
    static Singleton()
    {
    }
    Singleton()
    {
    }
    public static Singleton Instance
    {
        get
        {
            return instance;
        }
    }
}

Visto así por encima, esa implementación no parece ni lazy, ni thread-safe, ni nada de nada. Pero si nos cogemos el gran CLR via C# (libro totalmente recomendado) podemos entender como es que tan poco código hace tantas cosas. Toda la implementación gira en torno a los constructores estáticos y como funcionan dentro de .NET. Lo primero es entender que esto:

public sealed class Singleton
{
    static int a = 5;
}

En IL se traduce a esto:

public sealed class Singleton
{
    static int a;
    static Singleton()
    {
        a = 5;
    }
}

Y que por ejemplo esto otro:

public sealed class Singleton
{ 
    static int a = 5;
    static int b;
    static Singleton() 
    {
        b = 10; 
    } 
}

En IL queda así:

public sealed class Singleton
{ 
    static int a;
    static int b;
    static Singleton() 
    {
        a = 5;
        b = 10; 
    } 
}

Vamos, que las inicializaciones de variables estáticas una vez compilada la clase se incluyen dentro de un constructor estático (si el constructor existe se añaden al principio en el orden que son declaradas, si no existe se genera un constructor y se añaden).

En C#, cuando el compilador JIT (el que pasa de IL a código máquina) encuentra un constructor estático, mira si ese constructor ya se ha ejecutado o no:

Si no se ha ejecutado, emite un lock, el código de ejecución y un unlock.
Si se ha ejecutado, no emite nada.

Es decir, el JIT se asegura que el constructor estático solo se ejecute una vez aunque haya varios hilos, por eso en C# no hace falta poner el lock, ya que la línea new Singleton() se ejecuta dentro del constructor estático y el propio JIT ya se ha encargado que ese constructor solo sea llamado una vez. Con esto ya tenemos cubierto el tema de thread-safe, pero ¿y lo de que sea lazy?

Primero, tengo que reconocer que os he mentido un poco antes. Esta clase:

public sealed class Singleton
{ 
    static int a = 5;
}

Y esta otra clase:

public sealed class Singleton

{ 
    static int a;
    static Singleton() 
    {
        a = 5;
    } 
}

No generan exactamente el mismo IL: la primera está marcada con un atributo que se llama BeforeFieldInit y la segunda no. Cuando una clase está marcada como BeforeFieldInit el runtime del framework puede decidir ejecutar su inicializador de tipo (constructor estático) cuando se haga la primera referencia a ese tipo o antes, según le parezca. Pero si no está marcada con BeforeFieldInit (porque hemos puesto un constructor estático explícito) entonces el inicializador del tipo solo puede ejecutarse en el momento que se haga uso de ese tipo.

Es decir, como mi implementación del Singleton tiene un constructor estático, esta clase no está marcada como BeforeFieldInit y lo que haya dentro del constructor estático (new Singleton()) se ejecutará justo cuando haga Singleton.Instance. Pero si no tuviera un constructor estático la línea new Singleton() se podría ejecutar una hora antes de llamar a Singleton.Instance (por ejemplo), según decida el runtime. Y esto puede ser un problema porque no tenemos ni idea de cuando se va a ejecutar ese constructor y si tiene código muy pesado puede ralentizar el resto del programa en algún punto que no sea adecuado, o incluso ejecutarse y que luego resulte que nunca se utiliza en el programa.

Podéis encontrar una discusión mucho más en profundidad del tema en este artículo y este otro (cuentan lo mismo pero de forma mucho más técnica).

Actualización: Reed Copsey ha publicado un artículo sobre este mismo tema llamado "Just keep repeating: C# is not Java. C# is not C++" que contiene más ejemplos y resulta bastante interesante.

Emprendedores

Vicente — Wed, 08 Apr 2009 05:21:00 GMT

Hay un tipo de personas a las que ~~envidio~~ admiro de sobremanera: los emprendedores. Yo siempre he tenido ideas que he pensado que podrían ser un buen producto, o al menos suficentemente decente para funcionar. Cuando empecé con esto de los videojuegos tenía la idea del juego definitivo, normalmente un refrito de los tres o cuatro juegos de moda del momento, y junto con algunos amigos y algún colaborador nos lanzábamos a lo loco a intentar realizarlos - seguro que al igual que muchos de los que leéis estas líneas.

Todo empezaba genial, con la gente muy animada dedicando buena parte de su tiempo libre y de repente, un día:

Pepito ha ligado el finde anterior y ya no tiene tiempo para seguir en el proyecto.
Juanito lleva 5 días sin dormir enganchado al Call of Duty 6. Pero es para intentar conseguir nuevas ideas, ya sabéis, hay que jugar a todas las obras maestras - aunque tu juego sea un clon del pong.
Luisito está más pelao que las ratas y se ha buscado un trabajo, así que cuando termina su jornada solo le apetece tumbarse en el sofá y ver la tele.
Jaimito viendo que los demás no hacen ni el huevo, obviamente se contagia del espíritu reinante y tampoco hace nada.

Total, que al cabo de dos meses el resultado es un proyecto cancelado y lo mismo hasta alguna bronca o discusión entre los integrantes del equipo. Después de un tiempo, y ya siendo más “maduros”, este proceso se vuelve a repetir con idénticos resultados y así N veces hasta que uno tras otro nos vamos dando cuenta que mejor dedicarnos a otra cosa.

Pero hay gente que es capaz de salir de este círculo y llevar sus ideas adelante. Cuando te pones a analizarlo el resultado es sorprendente:

¡han convertido su proyecto en su trabajo!

Traduciendo: de lunes a viernes dedican entre las 9 y las 19 a su idea (cuando las cosas van bien, cuando hay que apretar parecen un 7 Eleven). Y eso que también tienen novias y les encanta viciarse al Call of Duty 6. Además, ¡la de riesgos a los que se exponen frente a un trabajo tradicional! Que si no encuentras clientes, los proveedores te la lían, no consigues financiación,…

Y esa es la forma de pensar que hace que uno no emprenda. O al menos es la que hace que yo no me atreva a emprender y admire a la gente que tiene los cojones de arriesgarse, y más en este país donde el fracaso está tan mal considerado – demasiado en mi opinión.

Así que este post va dedicado a toda esa gente que da ese salto, que pone todo su esfuerzo en perseguir sus ideas, en confiar en ellas, y en no dejarse achantar por todos los posibles problemas que puedan cruzarse en su camino.

Por suerte para mi, porque considero una fortuna poder hablar con este tipo de personas, conozco a bastante gente que ha emprendido y me gustaría dedicarles unas líneas:

A Iñaki Ayucar que posiblemente sea el tío que más sabe de gráficos y código manejado de España, y que lleva años apostando por su empresa Simax, un simulador de conducción que es sencillamente impresionante.
A mis compañeros de facultad que fundaron Vaelsys, una empresa especializada en visión artificial. Nunca se me olvidarán momentos como cuando Jorge hizo su parte de una práctica de Criptografía en Latín, o cuando Edu se vino a mi casa con su compañera a hacer prácticas de POO y el cabrón terminó comiendo palomitas mientras yo hacía el trabajo. Y encima al cabo de unas semanas vino quejándose de que solo había sacado un notable. Está claro que se le da bien ser jefe (y que yo soy un pringao).
A la gente de Signum Software y en particular a Olmo del Corral, que se han lanzado a la aventura de lanzar un ORM open source en .NET con ideas bastante novedosas en algunos aspectos.
A Cokidoo, empresa fundada por yens y Loover (entre otros), dos conocidos de Stratos-AD. Están poniendo toda la carne en el asador con una red social enfocada a estudiantes de movilidad (erasmus,…) que tiene un acabado impecable. Ahora mismo están participando en el concurso BBVA Open Talent así que pasaros por aquí y votadles.
A ethernet, otro Stratero al que tuve la oportunidad de conocer en el Congreso de Desrrolladores de Videojuegos 08. Javi ha creado un producto llamado Agroguía que es un sistema de guiado GPS para tractores. Un curioso nicho de mercado, todo sea dicho :p
A SiPoX, un habitual de las Kdds madrileñas de Stratos-AD que ha fundado Undead Code, otra empresa orientada hacia el tema de aplicaciones web y web 2.0. También participan en el BBVA Open Talent con Somflee, una mezcla entre red social y herramienta de gestión de contenidos digitales. Podéis votarles aquí.

Para todos ellos, lo mejor. A ver si un día de tanto hablar con vosotros se me contagia algo y me lanzo yo también a la aventura :) (¡acordaos de mi cuando seáis ricos!)

Árboles de Expresiones

Vicente — Tue, 31 Mar 2009 19:00:00 GMT

Ahora que ya hemos visto que es una expresión lambda podemos ver otra nueva característica mucho más “rara” de C# 3.0: los árboles de expresiones. En algunos lenguajes, como Lisp, se permite manejar el código como si fueran datos y los datos como si fueran código (hace un par de días leyendo el blog del gran Eric Lippert descubrí que a esto se le llama homoiconic). Los árboles de expresión son la forma que tiene C# de implementar esta funcionalidad (de forma algo limitada).

Por ejemplo, en el artículo anterior teníamos la expresión lambda:

num => num < 5

Que devolvía si un número era menor que cinco o no. Expresado en forma de un delegado del tipo Func, el código sería:

Func<int, bool> f = num => num < 5;

Y la forma de poner lo mismo usando un árbol de expresiones es:

System.Linq.Expressions.Expression<Func<int, bool>> e = num => num < 5;

La diferencia entre Func y Expression es que f es una función que se puede ejecutar:

bool result = f(10);

Pero para ejecutar e tenemos que hacer lo siguiente:

bool result = e.Compile()(10);

Es decir: para ejecutar un árbol de expresiones primero tenemos que compilarlo (porque son datos que representan código, no código en sí) y una vez compilado ya podemos utilizar el resultado como si fuera un método normal.

De forma gráfica, e internamente está representado por el siguiente árbol:

Pero lo interesante de los árboles de expresiones es que en vez de dejar que el compilador los genere automáticamente, podemos construirlos nosotros a mano. Una vez tenemos una idea de como se representan internamente generarlos por código es bastante fácil (aunque algo tedioso):

ParameterExpression param = Expression.Parameter(typeof(int), "num");

ConstantExpression five = Expression.Constant(5, typeof(int));

BinaryExpression lessThan = Expression.LessThan(param, five);

Expression<Func<int, bool>> e = Expression.Lambda<Func<int, bool>> (lessThan, new ParameterExpression[] { param });

Si hacemos un poco de memoria, en el mini motor de RPGs una parte bastante importante del código se encargaba de trabajar con las expresiones matemáticas que definen los valores de las variables de los objetos (los puntos de vida, el bonificador de ataque,…). Lo que hacíamos era definir el modificador en algún sitio (un fichero, una BD, …) como una expresión infijo, es decir, como esto:

(a) Attack = 3 * Level + 4 / 7 ^ 34 - 345

Se aplicaba el algoritmo de Shunting-Yard para transformarla en una expresión postfijo:

(b) Attack = 3 Level * 4 7 34 ^ / + 345 -

Y una vez teníamos (b) en forma postfijo se utilizaba un algoritmo para evaluar la expresión que lo que hace es construir un árbol con la siguiente pinta:

Y sinceramente, este árbol se parece un montón al árbol del ejemplo anterior :) Así que el cambio realizado en la librería de RPGs va a utilizar árboles de expresiones para permitirnos pasar de esto:

string strExp = "3 * Level + 4 / 7 ^ 34 - 345";

A esto:

Func<Evaluator, double> func = (evaluator) => 3 * evaluator.Chain(Level) + 4 / 7 ^ 34 - 345;

¡Hemos transformado una cadena de texto en una función en C#! Esta función recibe un objeto del tipo Evaluator (que se utiliza para calcular el valor de las variables como Level, Dexterity,… de forma recursiva) y devuelve un double (el valor de la fórmula).

El código que realiza esto es bastante sencillo (es una modificación del algoritmo de evaluación):

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using SLE = System.Linq.Expressions;

namespace GravityAge.Rpg

    public static class Experiments

        #region Methods

        public static SLE.Expression<Func<Evaluator, double>> ToExpressionTree(this Expression expression)

            Stack<SLE.Expression> operands;

            SLE.Expression op1, op2;

            SLE.ParameterExpression parameter = SLE.Expression.Parameter(typeof(Evaluator), "evaluator");

            operands = new Stack<SLE.Expression>();

            for (int i = 0; i < expression.Terms.Count; i++)

                switch (expression.Terms[i].TermType)

                    case TermType.Number:

                            operands.Push(SLE.Expression.Constant(expression.Terms[i].Value, typeof(double)));

                            break;

                    case TermType.Variable:

                            operands.Push(SLE.Expression.Call(parameter, "Chain", new Type[] { }, SLE.Expression.Constant(expression.Terms[i].Text)));

                            break;

                    case TermType.Operator:

                            op2 = operands.Pop();

                            op1 = operands.Pop();

                            switch (expression.Terms[i].TermOperator)

                                case TermOperator.Add:

                                        operands.Push(SLE.Expression.Add(op1, op2));

                                        break;

                                case TermOperator.Subtract:

                                        operands.Push(SLE.Expression.Subtract(op1, op2));

                                        break;

                                case TermOperator.Multiply:

                                        operands.Push(SLE.Expression.Multiply(op1, op2));

                                        break;

                                case TermOperator.Divide:

                                        operands.Push(SLE.Expression.Divide(op1, op2));

                                        break;

                                case TermOperator.Power:

                                        operands.Push(SLE.Expression.Power(op1, op2));

                                        break;

                            break;

                    default:

                            throw new ArgumentException("An undefined token (" + expression.Terms[i].Text + ") appeared while calculating an expression.");

            if (operands.Count == 1)

                return SLE.Expression.Lambda<Func<Evaluator, double>>(operands.Pop(), parameter);

            else

                return null;

        #endregion

Como podréis ver el código se encuentra dentro de una clase llamada Experiments, ya que no tenía muy claro si iba a ser capaz de hacer esto o no cuando empecé :p Así que estos días me dedicaré a refactorizar y pulir algunas cosas y en breve subiré una nueva versión de la librería a Kartones por si a alguien le interesa.

Características de C# 3.0 – Expresiones Lambda

Vicente — Sun, 15 Mar 2009 01:06:00 GMT

En el artículo anterior comenté el diseño de una pequeña librería para implementar las reglas de un RPG. Desde ese día he realizado pequeños cambios en el código con el objetivo de simplificarlo y aumentar el rendimiento. En este artículo (y el próximo) voy a hablar de algunas características nuevas de C# 3.0 que permiten que nuestra librería sea mucho más flexible.

En C# 3.0 la gente de Microsoft añadió muchas mejoras en el lenguaje, la mayoría inspirada en los lenguajes funcionales como Lisp, OCaml,… En particular hay dos que van de la mano: las expresiones lambda y los árboles de expresiones. Este primer artículo va a tratar de las expresiones lambda, así que recordemos que era un delegado y poco a poco veremos el porqué se añadieron todas estas nuevas características a C#.

Por ejemplo, queremos filtrar una lista de elementos T en base a un criterio pero queremos que el criterio sea modificable. Este “criterio” es una función que recibirá un T y devolverá un booleano indicando si el elemento cumple el criterio o no. En código tradicional de C# esto sería un delegado y sería algo como lo que sigue:

delegate bool Criteria<T>(T element);
 
class Program
{
    static List<T> FilterList<T>(List<T> list, Criteria<T> criteria)
    {
        List<T> newList = new List<T>();
        foreach (T element in list)
            if (criteria(element))
                newList.Add(element);
 
        return newList;
    }
 
    static bool CriteriaLessThan5(int intValue)
    {
        return intValue < 5;
    }
 
    static bool CriteriaBiggerThan5(int intValue)
    {
        return intValue > 5;
    }
 
    static void Main(string[] args)
    {
        List<int> numbers = new List<int>() { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
        List<int> numbers2;
 
        numbers2 = FilterList(numbers, CriteriaLessThan5);
        foreach (int number in numbers2)
            Console.WriteLine(number);
 
        numbers2 = FilterList(numbers, CriteriaBiggerThan5);
        foreach (int number in numbers2)
            Console.WriteLine(number);
 
        Console.ReadKey();
    }
}

Si os fijáis he declarado un delegado (Criteria) que recibe un elemento T y devuelve bool. Luego he añadido una función FilterList que recibe una lista y un criterio y devuelve la lista filtrada y por último en el main he usado dos funciones diferentes para filtrar una misma lista de números.

A partir de C# 2.0 se añadió al lenguaje la capacidad de declarar delegados anónimos (al vuelo). Usando delegados anónimos el código anterior tendría la siguiente pinta:

delegate bool Criteria<T>(T element);
 
class Program2
{
    static List<T> FilterList<T>(List<T> list, Criteria<T> criteria)
    {
        List<T> newList = new List<T>();
        foreach (T element in list)
            if (criteria(element))
                newList.Add(element);
 
        return newList;
    }
 
    static void Main(string[] args)
    {
        List<int> numbers = new List<int>() { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
        List<int> numbers2;
 
        numbers2 = FilterList(numbers, delegate(int e) { return e < 5; });
        foreach (int number in numbers2)
            Console.WriteLine(number);
 
        numbers2 = FilterList(numbers, delegate(int e) { return e > 5; });
        foreach (int number in numbers2)
            Console.WriteLine(number);
 
        Console.ReadKey();
    }
}

Ahora los delegados están metidos directamente en la llamada al método FilterList. En C# 3.0 se añaden las expresiones lambda que es una forma más “bonita” de escribir lo mismo. Además se añaden los delegados genéricos Action y Func que nos ahorran tener que declarar delegados propios. Con lo que en C# 3.0 nuestro código quedaría así:

class Program3
{
    static List<T> FilterList<T>(List<T> list, Func<T, bool> criteria)
    {
        List<T> newList = new List<T>();
        foreach (T element in list)
            if (criteria(element))
                newList.Add(element);
 
        return newList;
    }
 
    static void Main(string[] args)
    {
        List<int> numbers = new List<int>() { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
        List<int> numbers2;
 
        numbers2 = FilterList(numbers, e => e < 5);
        foreach (int number in numbers2)
            Console.WriteLine(number);
 
        numbers2 = FilterList(numbers, e => e > 5);
        foreach (int number in numbers2)
            Console.WriteLine(number);
 
        Console.ReadKey();
    }
}

Fijaos cómo ahora ya no se declara ningún delegado “Criteria” porque FilterList recibe un Func<T, bool>, es decir, un delegado genérico que tiene un parámetro T y devuelve un bool. Y además hemos sustituido en la llamada a FilterList lo de “delegate(int e)…” por una expresión lambda (=>) que recibe un “e” y devuelve si ese “e” es menor o mayor que 5 (el compilador automáticamente infiere que “e” tiene que ser de tipo int).

En el próximo artículo veremos como se relacionan las expresiones lambda con los árboles de expresiones, que nos permiten generar y modificar código de forma dinámica dentro del propio programa (código como datos, algo bastante común en los lenguajes funcionales) y la utilidad que tiene esto en una librería para implementar RPGs.

Implementando el reglamento de un RPG

Vicente — Mon, 09 Feb 2009 07:52:00 GMT

Aviso: este artículo es bastante largo, aunque no demasiado técnico, así que debería ser fácil de seguir.

Desde hace bastantes años siempre he tenido la idea de portar las reglas del Dungeons and Dragons (o algo similar) al ordenador, pero siempre he terminado fracasando por varios motivos:

Son sistemas muy complicados.
Están llenos de excepciones.
Tienen que ser muy extensibles porque seguramente aparecerán nuevas reglas con el paso del tiempo.

Estos días he tenido bastante tiempo libre y he decido intentar por n-esima vez hacer un “mini-framework” que me permita implementar algo parecido a una simplificacón del sistema d20 para mis propios proyectos. El resto de este artículo va a tratar de los problemas que he encontrado para realizar esta implementación básica (aún le faltan muchas cosas). Al final de todo hay un link con el código fuente para él que le quiera echar un vistazo.

El primer problema que me he encontrado siempre al intentar hacer este tipo de sistemas es que los objetos tienen muchísimas propiedades. Por ejemplo un personaje tiene atributos, habilidades, dotes, conjuros, equipo, clases,… A pesar de agrupar en clases y usar todas las herramientas que proporciona la programación orientada a objetos siempre he terminado teniendo en cada clase un ejército de propiedades que se vuelve inmanejable.

Así que decidí atacar el problema de otra forma: cada clase tiene una tabla hash que representa sus propiedades. De esta forma cada clase puede tener “infinitas” propiedades y además las puedo definir cuando quiera. Si quiero una propiedad hago:

objeto.Set("Propiedad", valor);

Y si quiero obtener el valor hago:

object resultado = objeto.Get("Propiedad");

La verdad que casi cualquiera que vea esto pensará que esta aproximación tiene muchos problemas:

Se usan strings para los nombres de las propiedades y es muy fácil equivocarse al escribirlos (confundir una mayúscula, una letra,…) y que el programa de un error o devuelva un valor erróneo. Depurar esto es un jaleo bastante serio.
Hay que calcular hashes de strings todo el rato (una operación bastante lenta).
No es tipada: tenemos objects por todos los lados que tenemos que castear al tipo correcto (lento y propenso a errores).

La verdad que yo mismo no estaba muy convencido de que esto fuera una buena idea hasta que me encontré este artículo de Steve Yegge donde habla del patrón prototype y de la programación basada en prototipos en vez de orientada a objetos.

El artículo, aún siendo largo, es bastante interesante y explica bastante bien que es y como se usan los prototipos. Resumiendo mucho: un prototipo es una tabla hash que contiene todas las propiedades y operaciones de un objeto (en vez de ser entidades independientes como en la programación orientada a objetos).

Dado que yo programo en C# y que este lenguaje no da soporte para prototipos (como por ejemplo IO), implementé las ideas del post de Steve en la clase Prototype. Esta clase contiene:

Un campo parent que es el prototipo del que se “hereda”.
Un campo properties que es el diccionario de propiedades.
Una propiedad IsReadOnly que permite hacer al prototipo de solo lectura.
Cuatro métodos (Get, Set, Contains y Remove) que permiten modificar la información del prototipo.
Y un método Clone que permite crear un nuevo prototipo que herede del actual.

Lo único interesante de esta clase es que los métodos Get y Contains permiten buscar valores en el padre del prototipo. Es decir, parent cumple la función de la superclase en la programación orientada a objetos. Como podéis ver, esta implementación no es nada complicada y permite hacer cosas como:

Prototype guardia = new Prototype();
guardia.Set("Ataque", 10);
guardia.Set("Vida", 5);
Prototype alitar = guardia.Clone();
alitar.Set("Nombre", "Alitar");
alitar.Set("TieneMiedoALosDragones", true);

Como se puede ver, he definido un guardia prototipo y luego un guardia especial que he llamado Alitar y que tiene miedo a los dragones. Alitar se comportará como cualquier otro guardia, pero cuando vea un dragón huirá en vez de luchar (¿quizás también tendría que ponerle más inteligencia? :p).

Una vez resuelto el problema fácil, queda el difícil (y bastante más interesante): calcular lo que vale una variable en un RPG. Por ejemplo: ¿cuanto vale el bonificador de ataque cuerpo a cuerpo de un personaje? En el d20 este número depende de muchísimas cosas:

La fuerza del personaje (o la destreza según que arma esté usando y si tiene las dotes adecuadas).
El nivel de cada clase del personaje.
Sus dotes.
Conjuros.
Otras habilidades o modificadores circunstanciales.

Básicamente calcular ciertos valores en un RPG es un lío increíble. Hace tiempo descubrí una herramienta llamada PCGen que es un generador de personajes para el sistema d20. Esta herramienta tiene un lenguaje de definición de reglas muy potente, por ejemplo:

BONUS:COMBAT|AC|Level / 2|TYPE=NaturalArmor.REPLACE

Esta línea significa un bonificador de combate a la armadura (AC) igual al nivel del personaje dividido entre dos, del tipo armadura natural que reemplaza a cualquier bonificador existente del mismo tipo. Este ejemplo es bastante básico, pero hay verdaderas virguerías definidas con él.

Así que realmente el segundo problema son dos subproblemas:

Como definir modificadores y expresiones matemáticas (Level / 2).
Como saber que modificadores afectan a una variable y como evaluar el valor de la misma.

El primer subproblema es “sencillo” de resolver si uno no se complica mucho la vida. En mi caso decidí imponer a las expresiones la restricción de que las diferentes partes que la forman deberían estar separadas por un espacio. Esto me permite partir la expresión con una sola llamada a String.Split. Luego un simple parser recorre los pedazos de la expresión y los clasifica en cuatro tipos:

Números: 3, 5.7, 23434,…
Operadores: +, –, *, /, ^
Símbolos: (, )
Variables: cualquier otra cosa

Esto debería ser suficiente para definir cualquier tipo de operación matemática que pueda ser de utilidad. En el fichero ExpressionParser.cs se puede ver el código de este pequeño parser. Una cosa “curiosa” del código es que al final del parseo se ejecuta una función llamada ShuntingYard. Esta función implementa el algoritmo de Shunting-Yard inventado por Djikstra que permite pasar expresiones en formato infijo (2 + 3) a formato postfijo o notación polaca inversa (2 3 +).

¿Y por qué hacer semejante cosa? Porque la notación postfijo tiene una gran ventaja: es muy fácil de evaluar. Estoy seguro que hacerse un evaluador de expresiones en formato infijo no es demasiado difícil, pero en formato postfijo es trivial y el coste de transformar la expresión es muy bajo (y solo hay que pagarlo una vez).

Y por último hay que ver como buscar los modificadores que afectan a una variable y como calcular su valor. Imaginemos que tenemos un objeto Espada definido de esta forma:

Prototype arma = new Prototype();
arma.Set("Nombre", "Espada");
arma.Set("Dureza", 5);

Para obtener su dureza basta con escribir:

int dureza = arma.Get<int>("Dureza");

Ahora imaginemos que cojo a la Espada y la modifico añadiéndole otro prototypo que representa que está hecha de Mithril, lo que le da una dureza extra.

Para calcular su dureza ahora hay que buscar en sus modificadores pero también en los del objeto Mithril. En el siguiente diagrama se puede ver un ejemplo un poco más complicado:

Se puede ver que se ha formado una estructura en forma de árbol, así que para buscar los modificadores decidí utilizar una búsqueda en anchura: primero la raiz, luego los hijos, luego los hijos de los hijos,…

Pero ahora imaginemos que esa espada está en manos de un personaje que es de la clase bárbaro, y que los bárbaros hacen que todos los objetos en sus manos sean menos duros (porque tienden a romperlos).

Como se puede ver la dureza del arma ha sido modificada por un valor que no está en sus hijos, si no que está en otra parte del árbol. Así que hay que modificar un poco la búsqueda en anchura:

Se busca la verdadera raíz del árbol a partir del nodo al que se le pidió el valor.
Se inicia la búsqueda en anchura desde este nodo.

Pero sigamos imaginando: ahora el personaje también tiene una Armadura y esta a su vez es de Adamantio.

Está claro que si pregunto por la dureza de la Espada no debería influir para nada los modificadores a la dureza de la Armadura o del Adamantio. Para resolver este nuevo problema hay que añadir una nueva propiedad a los modificadores: visibilidad (global o local). Y hay que volver a cambiar la búsqueda en anchura:

Se guarda el nodo que inició la búsqueda (la Espada).
Se comienza la búsqueda desde la raíz (el Personaje).
Si el modificador está en un nodo fuera del subárbol definido por el nodo que inició la búsqueda, solo se aplicarán los modificadores globales. Si el modificador está definido en un nodo perteneciente al subárbol se aplicarán todos los tipos de modificadores.

La búsqueda se inició en el objeto Espada, así que fuera del subárbol que define (marcado en rojo) solo se aplican los modificadores marcados como global. Así conseguimos que se aplique el modificador de Bárbaro pero no el de Armadura o Adamantio.

Esta forma de buscar modificadores cubre todos los casos que se me han ocurrido. Seguro que hay situaciones que no resuelvo, pero no me pienso complicar más la vida (de momento y sin una buena razón).

Ya está la búsqueda de modificadores, ahora queda ver como calcular el valor de una variable. El valor de una variable es modificado por los objetos de tipo Modifier que a su vez contienen expresiones matemáticas en forma de objetos Expression. Estas expresiones pueden ser simples como hemos visto hasta ahora o depender de otras variables, por ejemplo:

Ahora la dureza de la Espada depende de su peso también. Para resolver esto la evaluación de variables se ejecutará de la siguiente manera:

Cuando se comienza a evaluar una variable se apunta en una tabla de variables calculadas con el valor de menos infinito.
Si esta variable tiene un modificador que contiene una variable, se consulta a la tabla de variables ya calculadas.
- Si el valor de la variable es menos infinito hay una referencia circular (variable = variable) y el valor no se puede resolver. Excepción.
- Si es otra cosa se devuelve el valor y se continúa evaluando la variable actual.
Si la variable no se encuentra en la tabla de variables ya calculadas se inicia una nueva evaluación para esa variable (vuelta al principio de este proceso).
Cuando se termina de calcular el valor de una variable se actualiza en la tabla.

La clase Evaluator es la que se encarga de la búsqueda de modificadores y evaluación de variables.

El código fuente de todo este jaleo se puede descargar desde este link (está bajo licencia MIT así que se puede hacer cualquier cosa con él). El zip contiene una solución de Visual Studio 2008 (C#) que está compuesta de dos proyectos:

GravityAge.Statecraft.Core: el código de los prototipos y la evaluación de variables. Está bastante comentado así que debería ser fácil de comprender si se ha entendido este artículo.
GravityAge.Statecraft.Tests: unas cuantas pruebas unitarias para comprobar que todo está más o menos bien (debería hacer más, pero de momento con estas me basta). Hay una prueba que no se pasa (comprobar que una expresión infijo está bien formada) pero no sé como hacer que el parser se de cuenta de eso sin complicarme la vida demasiado, así que dejo el test roto para que no se me olvide que algún día debería solucionarlo.

Desarrollando un juego para Surface

Vicente — Thu, 15 Jan 2009 05:46:00 GMT

Este finde antes de irme de viaje he podido participar en otro “12 Meses 12 Proyectos”. 12m12p es una idea que se nos ocurrió a un grupo de amigos de Madrid de juntarnos de vez en cuando e intentar hacer un juego completo en un fin de semana. Normalmente no terminamos nada, pero nos lo pasamos muy bien :)

Esta vez se decidió hacer un juego de Air Hockey para Surface, ya que teníamos acceso a los SDKs de la mesita (aunque no teníamos una para probar, una lástima). Y sorprendentemente, conseguimos terminarlo y dejarlo bastante pulido :)

En este 12m12p participamos Luis, Riqui, Antón, Pedro, Olmo y un servidor y en el blog de Luis podéis encontrar varias imágenes y un vídeo de ejemplo. El juego está desarrollado en C#+WPF y nos agenciamos un HP TouchSmart para hacer las pruebas, pero a pesar de que soporta multitouch no reconoce cada toque como un ratón diferente así que acabamos poniendo varios ratones a un portatil normal para jugar.

La verdad que voy a echar bastante de menos 12m12p estos meses que voy a estar fuera, ya que son una oportunidad muy buena para vivir un proyecto (aunque sea pequeño) de principio a fin, donde lo que importa es terminar como sea la aplicación (si la gente viera algunas partes del código iban a llorar :p).

DevCamp 08 – ¡Ira XNA!

Vicente — Sat, 15 Nov 2008 15:50:54 GMT

Con esta frase terminé mi conferencia de XNA en la DevCamp 08 de Microsoft, para quien no conozca a que película hicimos un guiño entre Pedro, Riqui y yo que vea este link :) La verdad que como siempre la organización del evento fue de 10, 90 frikis en el Trip de Guadalajara a cuerpo de rey.

Y sin enrollarme mucho más, aquí dejo las transparencias de mi presentación, por si alguien les quiere dar un vistazo.

XNA – Cómo facilitar el desarrollo de videojuegos

Meme de desarrollo de software

Vicente — Mon, 21 Jul 2008 22:19:57 GMT

Hace unas semanas ethernet publicó este meme en su blog y me puso en la lista, así que aquí van las respuestas :)

Cuántos años tenías cuando empezate a programar

Unos 14-15 años.

Cómo empezaste a programar

Como me pasaba todo el día pegado al PC de un amigo (un 386) mis padres me apuntaron a una academia de informática donde me ~~enseñaron~~ hicieron copiar programas de Basic. Como no aprendía nada de nada me cambiaron a otra donde sí que aprendí Basic y un poco de C (y Wordperfect O_o).

Cual fue el primer lenguaje que usaste

Basic y unos meses después C. Y el último año de bachillerato mucho Div Games Studio :)

Cual fue el primer programa real que programaste

Un curso de aprender C en C :p (mi proyecto de fin de academia). Luego matamarcianos y cosas así con Div.

Cual fue tu primera experiencia profesional

Pues fue bastante tardía la verdad: las prácticas de empresa en HP. Hice algunas cosas antes con la Fundación de Ayuda contra la Drogadicción y Juvenalia pero tuvieron muy poco de programación.

Si tú hubieras sabido lo que sabes ahora cuando empezaste a programar, ¿hubieras empezado a hacerlo?

Sí. Me encanta desarrollar software, me parece un reto muy entretenido y la verdad que no me arrepiento de la ruta que tome para mi vida en este aspecto.

Si tuvieras que decir una sola cosa de las que has aprendido a lo largo de los años a un nuevo programador, qué le dirías

No reinventes la rueda por favoooooor.

Qué es lo más divertido que has programado?

La librería de IA de Jad Engine. En particular la parte de algoritmos genéticos a la que di muchas vueltas y que creo que ha quedado bastante bien (aunque su utilidad para juegos sea muy discutible :p).

A quién le pasas el meme

A todos los demás coders que hay en Kartones.net (en particular a Kartones, flipper y Pedrito que les conozco más, pero vamos, va para todos ;)).

Migrando a VS 2008

Vicente — Sun, 13 Jul 2008 10:54:00 GMT

Hace un par de semanas por fin migramos Jade y Pluto de VS2005 a VS2008. Llevábamos bastante tiempo queriendo hacerlo pero muchas de las características del Framework 3.5 aún no estaban soportadas en Mono así que no nos decidíamos. Pero coincidiendo con el movimiento de Codeplex a Assembla y viendo que Mono 1.9 ya sí que soporta casi todo lo nuevo (excepto LINQ to SQL que no creo que usemos en la vida) decidimos migrar las soluciones a VS2008.

El migrarnos a 2008 tiene varias ventajas:

El VS2008 funciona mucho mejor en Windows Vista que el VS2005.
Podemos aprovechar las nuevas características del lenguaje (propiedades automáticas, métodos extensionales, expresiones lambda, LINQ to Objects,...) y las nuevas clases que se han añadido al Framework (HashSet,...).
Con el SP1 tendremos un nuevo compilador que optimiza mejor los tipos por valor.

Las dos primeras ventajas son interesantes pero no son de vida o muerte. En cambio la tercera si que se merece unas líneas extra. Actualmente el compilador del Framework es incapaz de optimizar funciones que tengan en su firma un tipo por valor. Por ejemplo, si Vector3 es una estructura, no se podría optimizar esta función:

        1: public static Vector3 operator +(Vector3 left, Vector3 right)

       2: {

       3:     return new Vector3(left.X + right.X, left.Y + right.Y, left.Z + right.Z);

       4: }

No poder optimizar significa:

No se puede hacer un inline de la función.
Como hay que realizar la llamada, y los tipos son por valor, hay que copiarlos.

Esto es lentísimo y la función sumar vectores (o cualquier otra operación matemática) es imprescindible para un motor 3D. Hasta ahora para solucionar este problema había que hacerse una función como esta (en XNA existe este mismo problema y se utiliza esta misma solución):

       1: public static void Add(ref Vector3 value1, ref Vector3 value2, out Vector3 value)

       2: {

       3:     value.X = value1.X + value2.X;

       4:     value.Y = value1.Y + value2.Y;

       5:     value.Z = value1.Z + value2.Z;

       6: }

Donde los valores y el resultado van todos por referencia, con lo cual hay que pagar el coste de llamar a la función pero al menos no hay que copiar las estructuras. Pero el problema de funciones de este estilo es que escribir código matemático es horrendo. Por ejemplo:

       1: public override Vector3 Calculate()

       2: {

       3:     Vector3 result = Vector3.Zero;

       4:  

       5:     foreach (IMovableEntity target in _targets)

       6:     {

       7:         Vector3 targetPos = target.Position;

       8:         Vector3 ownPos = Owner.Position;

       9:         Vector3 direction = Vector3.Subtract(ref ownPos, ref targetPos);

      10:  

      11:         Vector3 desiredSpeed = Vector3.Multiply(ref direction, Owner.MaximumSpeed);

      12:  

      13:         Vector3 ownVel = Owner.Velocity;

      14:         Vector3 difference = Vector3.Subtract(ref desiredSpeed, ref ownVel);

      15:  

      16:         result = Vector3.Add(ref result, ref difference);

      17:     }

      18:  

      19:     return result;

      20: }

Ese código deberían ser 4 operaciones encadenadas, pero como no podemos usar los operadores +,-,*,... hace falta utilizar un montón de valores temporales (y además es feo de leer de narices).

Hace poco Reed hizo benchmarks con el nuevo compilador del Framework 3.5 SP1 Beta usando los operadores y las llamadas se optimizan correctamente, con lo que ahora usar +,-,... es más rápido (porque se hace el inline) y además el código es mucho más cómodo de leer. Así que ahora iremos cambiando el código de Jade para que utilice los operadores matemáticos.