Framework para desarrollo de juegos (II)

Hace una semana atrás les comentaba que estaba creano un pequeño framework para hacer juegos con HTML5 y Javascript.

La buena noticia es que ya es funcional; desde el manejo de las teclas hasta el mouse, pasando por una estructura de objetos bastante sólida. A pesar de que ya es posible usarlo, pienso seguir con la mejora, en especial en el concepto de plug-ins que me sugerían en el post anterior, así como optimizar el dibujado.

En todo caso, he creado algo similar a un juego (Un Galaga) para demostrar el funcionamiento de este framework. Si bien, los que lo descarguen, notarán que los enemigos no responden al ataque, deja las bases conceptuales para entender como crear juegos con este framework.

Si quieren descargar el framework y probar el juego, pueden hacerlo desde GitHub.

Todas las ideas de mejora son bienvenidas.

Anuncios

Framework para desarrollo de juegos

Lo primero que debo decir es que detesto los Frameworks. El grueso de las personas que usan diferentes frameworks para desarrollar aplicaciones tienden a usar una ínfima parte de los mismos, pero en muchos casos, estos frameworks son grandes y lentos, ya que están repletos de condiciones para asegurar que, aquel que usa más de una ínfima parte, pueda usarlo completo.

Leer el resto de esta entrada »


Ideas Creativas


 

 

 

 

 

Ideas Creativas, ponele efecto a tus apps, el primer show 
de Channel 9 de desarrollo y marketing de aplicaciones oficial
de Microsoft para developers de Argentina & Uruguay.

 
 

En el primer capítulo de Ideas Creativas correspondiente a la semanaWindows Phone, participaron del Show Gonzalo García, estudiante Uruguayo, quien nominó su aplicación Shooter .Game Pro y Marcelo Franceschini desarrollador cordobés con su  App Drop Upp.

 

Luego Pablo Panedas, perteneciente a la empresa INNICIA, relató como los desarrolladores de la aplicación oficial de Todo Noticias lograron tener éxito con su aplicación.

 
 
 

 
 

Si aún no te entrenaste en Windows Phone 8 para poder realizar tu aplicación y nominarla al show, mirá esta sección de capacitación de una hora de duración. Semana a semana iremos publicando cursos de cada vez más alto nivel para ayudarte a desarrollar e innovar en tus aplicaciones.

 

Te invitamos a ver la primer capacitación de Windows Phone 8.

¡No te olvides de postular tus Apps publicadas desde el 1 de julio!

 
 
 
 

 



Inyección de funcionalidad (I)

En el anterior post planteaba un ejemplo hipotético sobre algunas de las fallas más comunes en la inyección de dependencias. En especial cómo, al estar atados a tipos hace que la IDD se vea opacada. Además, claro, por su uso en lugares donde definitivamente no es necesario.

Aunque el anterior ejemplo haya tenido olor a poco probable, les puedo asegurar que es común, y la falla principal está, como comentaba, en que al final es necesario “depender” de algo en lenguajes tipados, sea en la estructura pre definida de una interfaz, sea en una clase abstracta, en definitiva, en alguna firma.

Por lo tanto, una de las principales cuestiones de las que es necesario romper relaciones, es con las firmas, o sea, permitir el libre flujo de funcionalidad independientemente de que se inyecte.

Pensemos que el objetivo final es (Para el post anterior) obtener un objeto con determinados datos, sin importar el valor de entrada. O sea, un output específico independientemente de los inputs.

En JavaScript, una aproximación sería la siguiente:

function IDD() {
    var self = this;
   
    this.dependency = {};
   
    this.getTheAccountForEntity = function(entity){
   
        if (entity.constructor == Company) {
            return {
                AccountName: entity.getName,
                Balance: self.dependency.CalculateBalance(entity)
            };
        } else {
            return {
                AccountName: entity.getName,
                Balance: self.dependency.ObtainLastMovements(entity)
            };
        }
    };

}

function Dependency1() {
    this.CalculateBalance = function (entity) {
        return 0;
    };
}

function Dependency2() {
    this.ObtainLastMovements = function (entity) {
        return 0;
    };
}

function Company() {
}

var company = new Company();
var idd = new IDD();
idd.dependency = new Dependency1();

var account = idd.getTheAccountForEntity(company);

El ejemplo anterior intenta replicar el comportamiento del código en C#, por lo que, posiblemente, no esté tan orientado a la manera de JavaScript. Así y todo es posible ver que no existe una innecesaria declaración de firmas, o que la dependencia inyectada no requiere crear nuevos elementos solo para cumplir con la firma, haciendo, al mismo tiempo, que la función que retorna la información, haga eso sin importar las entradas.


Una mentira–Inyección de dependencias

Como comentaba en el post anterior, en general tendemos a crear una gran cantidad de infraestructura de código para otorgarnos una, diriamos, posibilidad de flexibilidad a la hora del desarrollo de más código.

El problema radica cuando la infraestructura es más costosa que la solución que brinda, y en la actualidad, así como ha pasado en otras oportunidades, lo que está de moda se sobre usa, haciendo que sea un total despropósito.

De esta forma, los que tenemos varios años desarrollando hemos podido ver como el desarrollo de aplicaciones se ha visto absurdamente atiborrado de DataSets, de XML, de Web Services, de comunicaciones por HTTP, y por supuesto, de patrones de diseño desde los Singleton hasta todo tipo de Factories (Con nombres, sin nombres, con reflection, con singletons adentro, y un largo etc.), pasando por la joya actual, la inyección de dependencias. Al punto de que, como pasa en todos los casos, se inyectan dependencias hasta para crear un botón en una aplicación de escritorio.

Parte del problema se debe a que los malos programadores seguirán siendo malos programadores por más que apliquen todos los patrones del mundo, por otro por la moda (A quien no le preguntaron en una entrevista de trabajo si alguna vez usó Unity, pero al decir que uno había llegado a crear su propio contenedor dejando de lado Unity y cualquier otra implementación enlatada, y explicando el cómo, el interlocutor ponía cara de estar escuchando a alguien hablando Klingon) lo que lleva a que la IDD sea lo que hay que usar, así que usémoslo en todos lados.

Pero, su uso, en general, no soluciona absolutamente nada (Más allá del mal uso). En definitiva, el objetivo que generalmente se busca es el de poder asociar u obtener un objeto en base a su tipo y en base a una configuración externa a la aplicación. Y si bien aparenta ser un paso lógico, en muy pequeñas oportunidades se requerirá hacer un cambio “en caliente” de un conjunto de componentes pre establecidos, más si tenemos en cuenta que practicamente todas las aplicaciones requerirán un re inicio de la misma al intentar cambiar un ensamblado. O sea, en este caso, con una simple Factory se soluciona todo el problema.

Pero no es este el punto que quiero tocar. No nos vamos a poner a discutir el valor de la IDD. Lo que si es atendible es que todo, en lenguajes tipados, caen nuevamente en la necesidad de un tipo para poder funcionar. Ya que una de las búsquedas es lograr cierto desacoplamiento, solo agregamos una capa más para acoplarnos a una firma que se convierte en nuestra barrera restrictiva: “No vamos a poder obtener más que lo que esa firma nos diga que podemos obtener”.

C#

public class IDD
{
     [Some decoration based on the framework]
     public IDependency dependency { get; set; }

     public Account GetTheAccountForEntity<T>(T entity)
     {
          //Works
          dependency.GetName();

          if (typeof(T) == typeof(Company))
          {
               //Ha ha! Error ahead!
               dependency.CalculateBalance(entity);
          }
          else
          {
               dependency.ObtainLastMovements(entity);
          }
     }
}

public interface IDependency
{
     string GetName();
}

public class BasicUser : IDependency { … }

public class Company : IDependency { … }

El caso anterior es hipotético, y posiblemente algo rebuscado (O no) pero sirve para entender el problema. En este caso, si nosotros queremos crear una función que tenga la capacidad de retornarnos la contabilidad de diferentes “entidades”, sin importar que sean, o sea, desacoplar lo más posible los elementos entrantes, como los objetos que realizarán los cálculos para esas entidades, nos encontramos con que, debido a los tipos obligatorios, o tenemos que sobre escribir código, o crear ramificaciones a niveles más altos para que el código tome un camino diferente y pueda actuar en consecuencia. O sea, aquí no estamos inyectando realmente funcionalidad, ya que la inyección de esa funcionalidad seguirá atada a una ramificación anterior en el código, por lo que, a lo sumo, solo podríamos inyectar funcionalidad diferente para entidades similares. O, en su defecto, nos veremos obligados a elevar la complejidad del código para poder realizar esa simple transacción, o sea, obtener los datos de una función o de otra en base a su tipo.

En el siguiente post veremos como solucionamos esto desde JavaScript al poder estar desacoplados a los tipos.


JavaScript–Un juguete para adultos

JavaScript suele ser uno de los lenguajes de programación menos valorados desde el punto de vista “académico”, o de papeles a colgar en la pared, por decirlo de alguna forma. Para muchos, JavaScript es un juguete, es un lenguaje menor. Esto podemos verlo desde los memes informáticos hasta en entrevistas laborales, pasando por eventos o capacitaciones en las que este lenguaje se ve involucrado.

Leer el resto de esta entrada »


Nuevo post sobre desarrollo de videojuegos

He publicado un nuevo post sobre desarrollo de videojuegos con HTML5 y JavaScript en el blog de la empresa.

Pueden verlo aquí.