Este proceso automatizado, en principio no supone ningún problema, puesto que por lo general es una gestión imperceptible para el usuario final, pero hay ciertos casos donde puede ser útil tener más control de la memoria. Como por ejemplo, en aplicaciones donde se usen algunos objetos que son muy costosos de instanciar, o en el desarrollo de videojuegos donde se destruyen y creen constantemente actores, objetos de calculo, etcétera, provocando caídas en los FPS (frames por segundo) cuando el Garbage Collector trabaja.

El patrón de diseño Object Pool puede sernos de utilidad en estos casos, ya que nos permite "cierto" control de la memoria evitando que los objetos se destruyan, y por lo tanto evitando darle trabajo al Garbage Collector.

Básicamente, un Object Pool no es otra cosa que una lista de "instancias" de un mismo objeto, el cual nos permite reciclar continuamente estas instancias. La manera de hacer esto es sencilla, cuando necesitamos una instancia de nuestro objeto, se la pedimos al Pool, el cual, cogería la primera de su lista si tuviera, o crearía una nueva instacia si no tuviera ninguna almacenada, una vez entregada, elimina la referencia de su lista. Cuando nuestra aplicación ha terminado con esta intancia, no la destruimos, sino que la devolvemos al Pool, de manera que esta podrá ser reutilizada la próxima vez que se pida una nueva instancia.

Hay muchas formas de crear y gestionar un Object Pool, pero me gustaría compartir un pequeño modulo que ya hace todo el trabajo para nosotros.

Si estamos usando Node.js, Browserify, o Webpack podemos instalarlo desde NPM:

npm install --save obj-pool

Y requerirlo así:

var ObjPool = require('obj-pool');

También podemos añadir directamente el script en nuestro HTML, haciendo que ObjPool sea añadido a window:

if(ObjPool)console.log('todo ok!');

Su uso es bastante simple, tan solo debemos de instanciar nuestro Pool pasandole el constructor del objeto que queremos almacenar:

var myPool = new ObjPool( MyObject );

De esta forma, el pool creará las instancias según las demandemos con el método .alloc():

var myInstance = myPool.alloc(); 
//Hago lo que quiera con myInstance

Y una vez hemos terminado con la instancia en cuestión, la devolvemos al Pool con .free() y eliminamos la referencia de nuestro código:

myPool.free(myInstance);
myInstance = null;

//Si el scope es local, no haría falta eliminar la referencia

Simple ¿verdad?, ahora pongamos el caso de que no quieres que las instancias se creen bajo demanda, puesto que pueden ser muchas y muy costosas de instanciar, y prefieres controlar el momento de su creación, para esto podemos pasarle como segundo parámetro a ObjPool { amount: N }, de esta forma se crearán N instancias de nuestro objeto al crear el Pool:

//Crea un pool con 100 instancias de MyObject
var myPool = new ObjPool( MyObject, { amount: 100});

De esta forma tendremos 100 instancias a nuestra disposición al crear el pool, y en caso de que todas se usen, se empezarían a crear nuevas bajo demanda. Si por el contrario, no queremos que se instancien de golpe en la creación del pool, y preferimos otro momento, podemos usar el método .generate( amount ) para gestionarlo:

var myPool = new ObjPool( MyObject );
//Hago cosas
myPool.generate(100); // Genero 100 nuevas instancias que se almacenan en el pool

Pongamos ahora que queremos crear un Pool de un objeto al que necesitamos pasarle parámetros al instanciarlo, para ello podemos indicarle como segundo parámetro al ObjPool { args : [params...]}, usemos por ejemplo la clase Audio( src ):

//Creamos un pool de Audios con './assets/audio.mp3' como src
var myPool = new ObjPool( Audio, {args: ['./assets/audio.mp3')]});

Podemos pasarle todos los parámetros que queramos a nuestro objeto separando estos con comas (,) dentro del array de args.

Además podremos comprobar en todo momento cuantas instancias tiene el pool mediante .length:

if(myPool.length === 0)console.log('vacío');

Y cuando terminemos, podremos eliminar la lista de instancias con .clear(), dandole así nuevamente trabajo al Garbage Collector. En el caso de un juego, podríamos aprovechar cargas entre niveles, o momentos similares para limpiar los pools si fuera necesario, momentos donde algún que otro parón no sea molesto para el usuario.

También en algún momento podríamos necesitar de realizar acciones cuando el pool nos entrega la instancia y cuando la devolvemos de vuelta al pool, acciones como inicializar y resetear el objeto por ejemplo. Para estos casos, el pool buscará los métodos .init() y .reset() del objeto que hemos usado, y los ejecutará si estos existieran:

function MyEntity(){
}

MyEntity.prototype.constructor = MyEntity;

MyEntity.prototype.init = function(){
    //Hacemos cualquier acción al salir del pool
}

MyEntity.prototype.reset = function(){
  //Hacemos cualquier acción al volver al pool
}

var pool = new ObjPool(MyEntity);
var entity = pool.alloc(); //Ejecutará .init();
pool.free(entity); //Ejecutará .reset();

Para terminar os dejo el enlace al modulo den Github, donde podréis consultar la documentación, mejorarlo, etcétera. Espero que os sea de utilidad!

ObjPool en Github: https://github.com/Nazariglez/obj-pool

La opción más común es utilizar directamente los eventos keydown y keyup de window, controlando nosotros directamente el estado de las teclas, comprobación de códigos de tecla, etcétera.

Es aquí donde podría ser útil tener un manager que nos de todo el "trabajo" hecho, y nos permita hacer cosillas más complejas con el fin de agilizar el desarrollo de nuestro juego.

Para ellos vamos a utilizar pixi-keyboard, un módulo que extiende PIXI dotandolo de las caracteristicas necesarías para gestionar el teclado.

Instalación:

Dependiendo de nuestro sistema de trabajo, tenemos dos opciones para "instalar" el módulo.

1- Usando Browserify o Webpack tan solo tenemos que instalar el módulo desde NPM con:

npm install --save-dev pixi-keyboard

Y una vez instalado lo importamos en nuestro script, siempre despúes de haber importado PIXI, nunca antes:

var keyboard = require('keyboard');
//o en es6
import keyboard from 'pixi-keyboard';

Como pixi-keyboard es un modulo preempaquetado, es posible que tengas que añadirlo al parametro noparse de browserify o webpack para evitar errores a la hora de interpretar los requireen el momento que compiles tu paquete.
Si quieres una base de código usando pixi.js con webpack y ES6 lista para trabajar, puedes usar la que he dejado en este post.

2- Si no usas ningún gestor de dependencias y añades tus dependencias directamente desde el código HTML, tan solo tienes que bajar el archivo pixi-keyboard.js del directorio build del repositiorio, y añadirlo justo despúes del script de pixi.js.

El plugin añadirá varias clases al namespace PIXI, como PIXI.KeyboardManager, PIXI.HotKey y PIXI.Key. Además instanciará la clase PIXI.KeyboardManager en PIXI.keyboard, de manera que

El siguiente paso será ejecutar el método update desde el loop de animación que estemos usando en pixi:

//PIXI renderer
var renderer = new PIXI.autoDetectRenderer(800,600);
document.body.appendChild(renderer.view);
var stage = new PIXI.Container();

function animate(){
    window.requestAnimationFrame(animate);
    renderer.render(stage);

    //Añadimos el metodo update de PIXI.keyboard 
    PIXI.keyboard.update();
}
animate();

Y ya hemos terminado, esto es todo lo que necesitamos para utilizar correctamente el plugin.

En PIXI.Key tenemos una lista de alias de diferentes KeyCodes, por ejemplo PIXI.Key.ENTER = 13, así resulta más sencillo de recordar.

El estado de las teclas se divide en tres formas, down que nos indica si una tecla está siendo pulsada, devuelve true siempre que la tecla siga pulsada, pressed que nos indica si una tecla ha sido pulsada, pero solo en el momento de hacerlo, si luego seguimos pulsando la tecla indicará false, y released que nos indica si una tecla ha sido liberada.
Tenemos varias formas para comprobar estos estados, que dependiendo de la situación podremos usar uno u otro método dependiendo de lo que nos convenga.

Comprobando directamente el estado:

Podemos comprobar directamente el estado de una tecla usando los métodos isPressed, isDown e isReleased del objeto PIXI.keyboard. Útil por ejemplo si queremos comprobar el estado dentro de algún metodo step/update de algún actor, para disparar, saltar, etcétera. Veamos un ejemplo:

var myTank = new PIXI.Sprite(texture);

//PIXI no provee de método update por defecto, debes implementarlo tu si es que lo necesitas.
myTank.update = function(delta){
    //Dispara continuamente si espacio está pulsado
    if(PIXI.keyboard.isDown(PIXI.Key.SPACE)){
        console.log('fire fire fire!!!');
    }

    if(PIXI.keyboard.isPressed(PIXI.Key.Z)){
        console.log('Acelerar');
    }else if(PIXI.keyboard.isReleased(PIXI.Key.Z)){
        console.log('Desacelerar');
    }

}

Comprobación mediante eventos:

Una forma más global, sería escuchar los eventos y ejecutar un callback una vez se disparen. Útil en situaciones donde no dependamos directamente de un actor, simulando que escribimos en pantalla, etcétera. Veamos un ejemplo con eventos:

PIXI.keyboard.on('pressed', function(key){
    if(key === PIXI.Key.ESCAPE){
        console.log('cierra la aplicación');
    }
});

PIXI.keyboard.on('down', function(key){
    if(key === PIXI.Key.UP){
        console.log('aumenta el volumen del audio');
    }else if(key === PIXI.Key.DOWN){
        console.log('disminuye el volumen del audio');
    }
});

PIXI.keyboard.on('released', function(key){
    console.log('haz algo impresionante con la tecla ' + key);
});

Usando HotKeys:

Los HotKeys nos permiten crear accesos rápidos a las teclas que nos interesan, para comprobar el estado de manera separada y sencilla. Imagina que uno de tus actores necesita saber el estado de tan solo 4 teclas, como pueden ser W, A, S y D, podríamos crear 4 HotKeys para ello:

var keyA = PIXI.keyboard.getHotKey(PIXI.Key.A);
var keyW = PIXI.keyboard.getHotKey(PIXI.Key.W);
var keyS = PIXI.keyboard.getHotkey(PIXI.Key.S);
var keyD = PIXI.keyboard.getHotKey(PIXI.Key.D);

if(keyW.isDown)console.log('arriba');
if(keyS.isDown)console.log('abajo');

//o comprobanco combinaciones
if(keyA.isDown && keyW.isDown)console.log('diagonal');

Además de los típicos isDown, isPressed e isReleased, también podemos comprobar si las teclas CTRL, SHIFT y ALT están en el estado down directamente desde cualquier HotKey:

if(keyW.isDown && keyW.ctrl){
    console.log('Haz Zoom!');
}else if(keyW.isDown){
    console.log('arriba');
}

var ctrl = keyW.ctrl;
var shift = keyW.shift;
var alt = keyW.alt;

PreventDefault:

Puede ser útil en algunas situaciones prevenir el comportamiento por defecto de ciertas teclas, por ejemplo, en una pagina con scroll puede que no queramos que este suceda al usar las teclas UP y DOWN si estás teclas ya tienen funcionalidades dentro de nuestra aplicación. Podemos prevenirlo así:

PIXI.keyboard.setPreventDefault(PIXI.Key.UP);
PIXI.keyboard.setPreventDefault(PIXI.Key.DOWN);

//Si queremos cancelarlo pasamos false como segundo parametro
PIXI.keyboard.setPreventDefault(PIXI.Key.Up, false);

Como ves la gestión del teclado en desarrollos con pixi.js resulta sencillo con este módulo, y las posibilidades de uso son amplias, espero que os sea de utilidad.

Plugin: https://github.com/Nazariglez/pixi-keyboard

Precisamente por esto, lo veo como una opción perfecta para usarlo en los desarrollos con Pixi.js. Normalmente cuando pienso en programar un juego, divido mentalmente todo en objetos, ya sean objetos que se van a renderizar o no, lo ideal para mí es tenerlos bien definidos y separados por ficheros, de manera que me resulte relativamente sencillo mantener el juego, ampliarlo, modificarlo, etcétera.

Hasta el momento organizaba mi código con gestores de tareas como pueden ser Gulp.js o Grunt junto con Browserify, y programaba orientado a objetos de la manera típica:

function Batman(){
    this.name = "Batman";
}

Hero.prototype.constructor = Hero;

Hero.prototype.sayHello = function(){
    console.log("I'm " + this.name + "!");
}

var batman = new Batman();

Pero esto es mucho más sencillo con ES6:

class Batman(){
    constructor(){
        this.name = "Batman";
    }

    sayHello(){
        console.log(`I'm ${this.name}!`);
    }
}

let batman = new Batman();

Por supuesto, esto no es todo, las ventajas de ES6 son muchísimas, quizás más adelante me anime a hacer un post sobre el tema, pero de momento tienes toda la información sobre ES6 aquí, y si buscas en google hay muchísimos sitios ofreciendo pequeñas introducciones y guías sobre el estándar.

El porqué seguimos usando ES5 ahora mismo es simple, porque todo estándar debe ser implementado, actualmente los navegadores y Node.js están poco a poco implementando características de ES6, pero aún estamos lejos de tener soporte completo en todas las plataformas.

Aquí es donde entra en juego Babel. Babel es básicamente un transpilador que usa código Javascript en ES6 como entrada, y devuelve a la salida el mismo código en ES5, de manera que puedes programar usando el nuevo estándar, y conseguir que el código resultante sea ejecutable en todas las plataformas actuales.

Usando Babel y Webpack he montado un boilerplate para poder usar Pixi.js usando ES6 en pocos pasos. El único requisito es tener instalado Webpack en global, para ello (si no lo tienes ya) hacemos:

npm install webpack -g

Ahora clonamos el repositorio del boilerplate:

git clone https://github.com/Nazariglez/es6-pixi-bolierplate.git

Y lo instalamos:

npm install

Y listo, en el directorio src tenemos todo el código en ES6 y en el directorio build tendremos el bundle de nuestra aplicación. Como podrás ver ya hay un pequeño ejemplo creado que puedes usar como punto de partida.

Para generar el bundle minificado tan solo debemos ejecutar npm run build, y si queremos que el bundle se genere automáticamente cada vez que cambiamos algo en algún modulo, o cuando añadimos alguno nuevo, debemos usar npm start o npm run dev.

Como ya te imaginarás puedes usar cualquier modulo que se encuentre en NPM, es la magia de Webpack y Browserify, por ejemplo, queremos añadir lodash a nuestra app:

npm install --save-dev lodash

Y lo importamos desde cualquier modulo de nuestra aplicación:

import _ from 'lodash';

Y eso es todo, espero que os sea útil y os animéis a usar Pixi.js con ES6.

Repositorio: https://github.com/Nazariglez/es6-pixi-bolierplate

Durante mucho tiempo setInterval fue la opción más usada, definíamos el tiempo que debía durar el frame y listo, pero no era lo más optimo, así que los navegadores empezaron a incorporar requestAnimationFrame, su función es similar al setInterval, salvo que aquí no podemos controlar el tiempo entre frames, sino que es el propio navegador el que se encarga de ejecutar el loop de la forma más óptima pudiendo ser esta diferente dependiendo del dispositivo que se esté usando.

Veamos un ejemplo con setInterval:

var myActor = new Actor();
var frameTime = 1000/60; //60fps
var interval = setInterval(animate, frameTime);

function animate(){
    //loop de animación
    myActor.x += 1; //Movemos el actor 1px a la derecha a cada frame
}

Mismo ejemplo usando requestAnimationFrame:

var myActor = new Actor();

function animate(){
    requestAnimationFrame(animate); //Ejecutamos RAF dentro del loop
    myActor.x += 1;
}

animate(); //Iniciamos el loop

Ambos ejemplos hacen lo mismo, mueven un actor hacia la derecha 1px en cada frame, la diferencia reside en la forma en la que se gestiona el loop, mientras que el loop con setInterval se va a ejecutar 60 veces por segundo, de manera obligatoria, tal y como hemos declarado, el segundo loop puede variar la velocidad de ejecución en base a muchos otros factores.

Centremonos entonces, en requestAnimationFrame, que es, actualmente (salvo exepciones) el que se debe usar para crear animaciones.

Teniendo en cuenta que el RAF (requestAnimationFrame) puede que no se ejecute a velocidades constantes, y nuestro actor se mueve 1px a cada frame, tenemos un problema. Imagina ejecutar nuestro ejemplo en dos dispositivos diferentes, a la misma vez, veremos que la posición de nuestro actor empieza siendo la misma en ambos, pero a medida que transcurre el tiempo muy posibilemente varien, y uno de los actores se encuentre por delante del otro. Esto se debe a que quizás uno de los dispositivos ha ejecutado el loop a 55fps y el otro a 60, lo que a 1px por fps equivale a una diferencia de 5px entre ambos actores. Es un ejemplo un poco pobre, pero creo que se entiende el problema.

La solución pasa por calcular el delta time, que es basicamente el tiempo que ha pasado desde la última ejecucción del loop. Y cambiar el enfoque de nuestro movimiento de 1px por frame a 1px por segundo (1px o 100, o los que sean). De esta forma será más preciso el movimiento, y ambos actores avanzarán de forma identica independientemente de la velocidad del loop.

Veamos un ejemplo del calculo del delta time:

var myActor = new Actor();
var time = 0; //tiempo total
var lastTime = 0; //tiempo total en el último update
var last = 0; //Date.now() en el ultimo update
var delta = 0; //tiempo delta

function animate(){
    requestAnimationFrame(animate); //Ejecutamos RAF dentro del loop

    var now = Date.now();
    time += (now-last)/1000;
    delta = time-lastTime;
    lastTime = time;
    last = now;

    myActor += 1*delta;

    console.log(delta, time);
}

last = Date.now(); //Indicamos el tiempo actual antes de ejecutar el primer fps
animate();

Gracias a este simple calculo el movimiento de nuestro actor será mucho más preciso que al principio, y este pequeño snippet nos sirve de manera universal tanto si usamos el elemento canvas directamente, o si usamos cualquier otro renderer como pueden ser three.js o pixi.js.

Concretamente para pixi.js (renderer que suelo usar asiduamente), he creado un pequeño modulo que hará estos calculos y algunas cosillas más, como parar el loop y recuperarlo si la pestaña del navegador pierde el foco, limitar el tiempo máximo del frame por si el dispositivo de congela y de esta manera evitar saltos bruscos en la animación, etc...

El modulo se llama pixi-animationloop y se encuentra publicado en Github.

Hay varias formas de usarlo; la de toda la vida, bajar el script del directorio build/pixi-animationloop.js y añadirlo en tu index.html justo debajo del script de PIXI. O si usas browserify o Webpack, tan solo tienes que hacer:

npm install pixi-animationloop

El modulo añadirá una nueva clase a pixi, y solo tenemos crear la instancia pasandole el renderer de pixi, y ejecutar el metodo start:

var renderer = new PIXI.autoDetectRenderer(800,600);
document.body.appendChild(renderer.view);

var animationLoop = new PIXI.AnimationLoop(renderer);
animationLoop.start();

Tan fácil como eso, y ya tenemos nuestro loop funcionando, con todos los calculos de tiempo accesibles desde la variable animationLoop. Por ejemplo: .time nos indicaría el tiempo total que ha pasado "dentro" de la animación desde el primer frame, .realTime nos indicaría el tiempo real (sin contar posibles paradas, etc...), .speed nos permitiría alterar la velocidad a la que pasa el tiempo, útil para efectos de tiempo bala o similares, en .delta tendríamos el calculo del delta time en segundo y .deltaMS sería el mismo valor pero en milisegundos.

Si conoces pixi.js, te habrás fijado en que no he creado un contenedor para usarlo como Stage, esto es porque el modulo ya lo crea internamente, pero si quieres puedes pasarle tu propio PIXI.Container como segundo parametro y quedaría referido en animtionLoop.stage.

Además, el modulo emite diferentes eventos que puedes escuchar para ejecutar tus propias instrucciones, como start, stop, prerender, postrender y visibilitychange. Muy útil por ejemplo para añadir un método step/update usando prerender o postrender:

function update(){
    //Metodo update, this es animationLoop.
    myActor += 1 * this.delta;
}

animationLoop.on('prerender', update);

Si quieres saber más sobre la gestión de eventos te recomiendo ir a la documentación de node.js sobre estos: https://nodejs.org/api/events.html

Para terminar dejo el link al modulo en github. Te recomiendo que eches una vistazo rápido a la documentación para entender todo lo que puedes hacer, como parar el loop, eventos, velocidad máxima, etcetera.

Link a pixi-animationloop: https://github.com/Nazariglez/pixi-animationloop

Creo que Ghost cumple con todo lo que necesito, una plataforma enfocada 100% en blogs, que me permite añadir paginas estaticas y temas, ademá es ligero, rápido de configurar, y un largo etcétera.

Por supuesto tiene puntos malos, como no permitir programar la fecha del post, o cosas como que no permite menús dinámicos de momento, pero es algo que no me preocupa, siempre se pueden añadir los enlaces mediante html en la plantilla. Aún así, el desarrollo de la plataforma no para, y dia a dia avanzan y añaden features nuevas.

He aprovechado también para cambiar el estilo del blog, buscando un tema centrado totalmente en el contenido, y ya que estaba metido en faena he migrado de servicio de hosting, de iFastNet a DigitalOcean.

Ya usaba DigitalOcean para pequeños proyectos y estaba bastante contento, así que me pareció una tontería pagar dos servicios de hosting por separado, mejor tenerlo todo en el mismo sitio.

Tenía pensado escribir una entrada tipo "Migra tu blog de Wordpress a Ghost", pero lo cierto es que ya hay muchos y muy buenos post que lo explican, y aunque hay diferentes formas de hacerlo, y los problemas que te puedes encontrar pueden ser diferentes también, la esencia es la misma. Yo os recomiendo el que usé de guia, aunque no hice todo lo que pone tal y como lo pone, pero tiene explicado todo lo necesario para hacer la migración: http://mviera.io/blog/migrando-de-wordpress-a-ghost/.

Aún quedan bastante flecos que corregir después de la migración, como links que no funcionan, etiquetas repetidas, o post mal maquetados, intentaré esta semana poco a poco ponier todo en orden.

¿Que os parece ghost?, ¿Lo veis una buena alternativa para vuestros blogs?

Browserify es básicamente una herramienta que nos permite gestionar dependencias en forma de módulos del lado del cliente (en el navegador). A grandes rasgos podemos decir que lo que nos permite es crear y requerir módulos tal y como hacemos con Node.js; y digo a grandes rasgos porque no es exactamente así, ya que con browserify no tendremos en el build final varios ficheros javascript, sino que crearemos un bundle con la herramienta y tan solo tendremos un fichero javascript.

Pero vayamos por partes, primero que nada deberás de tener instalada la herramienta de manera global con npm:

npm install -g browserify

Una vez hecho esto, podremos ejecutar directamente browserify desde nuestra terminal, es importante que la instalación haya sido global, o en caso contrario no funcionará, puedes hacer la prueba pidiendo la versión del paquete:

browserify -v

Si te ha devuelto un numero (en mi caso 8.1.3) es que todo está correcto.

Vamos a crear ahora nuestro primer modulo, que, para no perder las buenas costumbres será el típico “hello world”. Lo llamaremos hello.js:

var str = "hello world"; 
module.exports = function(name){ 
    console.log(str + ' ' + name); 
};

Ahora creamos otro modulo en el mismo directorio llamado index.js, y hacemos require al modulo hello.js:

var hello = require('./hello.js'); 
hello('Juan'); //hello world Juan

Todo listo para crear nuestro archivo final, ahora simplemente debemos de ir a nuestro terminal y ejecutar browserify indicandole el archivo de entrada, que es el script desde donde tiene que empezar a “seguir” todas las dependencias, y el nombre del fichero final que debe generar, así:

browserify index.js > bundle.js

Esto nos generará un script llamado bundle.js (o el nombre que tu quieras) que es el que debemos incluir en nuestro fichero HTML como cualquier otro script. Como podrás ver, el proceso de gestión de módulos es automático, browserify se encarga de seguir todas las dependencias e incluirlas dentro del archivo final, fácil y rápido.

¿Que pasa si hacemos require dos veces al mismos script?

Si lo que te preocupa es que se incluya un modulo varias veces, puedes estar tranquilo, browserify incluirá el modulo solo una vez en el bundle final, y luego tu podrás usarlo las veces que quieras.

Hagamos una prueba, volvamos a nuestro modulo hello.js y añadamosle algunos logs:

var str = "hello world"; 
console.log('Soy el modulo hello.js'); 
module.exports = function(name){ 
    console.log(str + ' ' + name); 
};

Y en el index.js hacemos require de hello.js en dos ocaciones:

var hello = require('./hello.js'); //Soy el modulo hello.js
hello('Juan'); //hello world Juan 
var helloAgain = require('./hello.js');

Genera nuevamente el bundle y carga tu html, comprobarás que la frase “Soy el modulo hello.js” solo se ha visto una vez en la consola, no dos. De esta forma tu puedes usar el mismo modulo tantas veces como quieras, cargando por ejemplo hello.js en varios módulos diferentes, sin tener que preocuparte de que se ejecute cada vez las rutinas del modulo hello.js, o de que el peso del archivo final sea excesivamente grande.

¿Que pasa con el ámbito de las variables?

Otra de las ventajas de browserify es que cada modulo será totalmente independiente, quedando todo lo que hagas encapsulado y exponiendo hacia el exterior solo lo que tu quieras que sea expuesto mediante module.exports.

Si quieres, puedes hacer una prueba muy sencilla con lo que ya tenemos hecho, si te fijas en hello.js se ha declarado la variable str, no se encuentra dentro de ninguna función, pero solo tiene validez dentro de ese modulo. Para comprobarlo vamos a añadir a index.js lo siguiente:

var hello = require('./hello.js'); //Soy el modulo hello.js
hello('Juan'); //hello world Juan 

//Comprobando el scope 
if(str){ 
    console.log('Esto no se ejecutará nunca');
}else{ 
    console.log('la variable str no existe en este módulo, porque pertenece al módulo hello.js'); 
}

Como dice el ejemplo, la frase “Esto no se ejecutará nunca” no la verás nunca en la consola. De esta forma, cualquier variable que declares, o función que definas tendrá validez solamente dentro del scope del propio módulo, por lo que puedes declarar lo que tu quieras fuera de funciones o closures sin miedo a contaminar el objeto window.

Usando modulos de npm

Otra de las grandes ventajas de usar browserify es que puedes usar módulos instalados desde npm en el navegador. Por ejemplo jQuery, vamos a instalarlo mediante npm:

npm install jquery

Ahora simplemente debemos hacerle require sin indicar path, y lo tendremos incluido en nuestro bundle.

var $ = require('jquery'); 
$(function(){ 
    console.log('jQuery'); 
});

Si usamos npm para gestionar todos los módulos que podamos, nos facilitaremos la vida a nosotros mismos, porque no deberemos de preocuparnos por nada más que no sea hacer un npm install o un npm update para mantener en orden y funcionando nuestras aplicaciones.

Vigilando los cambios con Watchify

Watchify es otra herramienta que nos hará la vida más fácil cuando trabajemos con browserify. Este paquete se encarga de vigilar todos los cambios que ocurren en nuestro código y generar el bundle cada vez que exista una modificación. Para instalarlo, volveremos a recurrir a npm:

npm install -g watchify

En este caso la instalación ha de ser también usando -g para que este disponible globalmente. Y la forma de usarlo es casi identica a como usamos browserify:

watchify index.js -o bundle.js

Con esta ultima sentencia le estamos indicando que use como punto de entrada index.js vigilando todos los cambios en este script y en todos los referenciados mediante require de todo el árbol de dependencias, si alguno de estos se modifica, se generaría nuevamente el bundle.js sin que tengamos que intervenir.

Usando Gulp y Browserify

Aunque trabajar con browserify y watchifiy es bastante sencillo, aún podríamos facilitarlo más relegando todo el trabajo a un gestor de tareas como Gulp, si no lo conoces te recomiendo leer este post.

Primero que nada vamos a instalar los 4 módulos que usaremos como dependencias de desarrollo (asegurate de tener el package.json de tu proyecto).

npm install gulp browserify watchify vinyl-source-stream --save-dev

Y creamos nuestro gulpfile.js en la raíz del proyecto:

var gulp = require('gulp'), 
    browserify = require('browserify'), 
    watchify = require('watchify'), 
    source = require('vinyl-source-stream');

Ahora pasaremos a iniciar browserify y watchify, pero según la documentación de watchifiy al crear la instancia de browserify debemos de pasarle un objeto con 3 propiedades de manera obligada, estas propiedades son, cache, packageCache, y fullPaths, aunque la manera más sencilla es pasarle directamente el objeto args de watchify, que es justo lo que haremos:

var entry = './index.js'; //Script de entrada 
var args = watchify.args; 
args.debug = true; //Genera el sourcemap para debuguear
args.fullPaths = false; //Evita el uso de paths absolutos 
var bundler = watchify(browserify(entry, args));

Una vez creada la instancia con los parámetros que queremos, pasamos a gestionar el bundle y las tareas:

function createBundle(){ 
    console.log('Now building...'); 
    return bundler.bundle() 
        .pipe(source('bundle.js')) //Nombre del bundle final
        .pipe(gulp.dest('./build')); //Directorio de destino
} 

gulp.task('dev', createBundle); 
bundler.on('update', createBundle); //A cada modificación generamos un nuevo bundle 

//Proporcionamos algo de información al generar el bundle
bundler.on('time', function(time){ 
    console.log('Done at ' + (time/1000)); 
});

Y listo, a estas alturas el archivo gulpfile.js tendría que verse más o menos así:

var gulp = require('gulp'), 
    browserify = require('browserify'), 
    watchify = require('watchify'), 
    source = require('vinyl-source-stream'); 

var entry = './index.js'; //Script de entrada 
var args = watchify.args; 
args.debug = true; //Genera el sourcemap para debuguear
args.fullPaths = false; //Evita el uso de paths absolutos 

var bundler = watchify(browserify(entry, args)); 

function createBundle(){ 
    console.log('Now building...'); 
    return bundler.bundle() 
        .pipe(source('bundle.js')) //Nombre del bundle final
        .pipe(gulp.dest('./build')); //Directorio de destino
} 

gulp.task('dev', createBundle); 
bundler.on('update', createBundle); //A cada modificación generamos un nuevo bundle 

//Proporcionamos algo de información al generar el bundle
bundler.on('time', function(time){ 
    console.log('Done at ' + (time/1000)); 
});

Ahora cuando trabajemos en nuestro proyecto solo deberemos de ejecutar gulp dev en la terminal, y olvidarnos de todo, que gulp y browserify se encargarán de hacer todo el trabajo repetitivo, y nosotros solo tendremos que centrarnos en generar buen código ;)

Si te interesa el tema, te animo a que busques más información en google, porque esto que ves aquí es solo una de las pocas formas que existen de trabajar con browserify, sobre todo no te pierdas “Browserify Handbook“.

Anímate y comenta que opinas de browserify, si lo has usado o planeas usar, si lo usas con algunos módulos, o cualquier otra cosa relacionada, cualquier comentario es bienvenido.

El juego en cuestión es Bee Quest (Android || iOS). Se trata de un Match3 muy entretenido y desafiante, con un aspecto visual precioso (magia de Zigor) en el que se respira variedad en todas y cada una de sus mecánicas. En el tomamos el rol de Thoven, una abeja que deberá jugar con las flores para ayudar a su colmena.

A medida que vas jugando y pasando niveles van entrando en escena diferentes mecánicas que te harán estrujarte la cabeza, como por ejemplo los cambios de modos de juegos, siendo estos el ya clásico intercambio de fichas, la selección de flores por cercanía arrastrando tu dedo por encima de estás, o el modo de toque, donde tocar una flor con flores similares alrededor hacen que exploten.

Otro factor a tener en cuenta es el cambio del viento, que altera el movimiento de las flores del tablero, pudiendo estas ir en cualquier dirección, ya sea hacia arriba, abajo, o hacia cualquiera de los laterales.

Hay mucho más por supuesto, desde arañas que con su tela bloquearán tus fichas, a movimientos especiales, enredaderas que se comerán el espacio que es para tus flores, teletransportadores que te pondrán todo patas arriba, y un largo etcétera que será mejor que descubras por ti mismo!

Sobre la parte técnica del juego no quiero hablar mucho en este blog, porque no es el sitio que le corresponde, ya que su sitio es el blog de ludei, pero como habrás imaginado al ser un trabajo de ludei, es un juego desarrollado en HTML5, javascript, y Cocoon, más concretamente en WebGL corriendo sobre Canvas+.

Sin más espero que todo el que “caiga” por aquí le de una oportunidad, lo pruebe, y si quiere dejar un comentario sobre que le parece, o mejor aún, quiere dejar una review en la store, pues se le agradecería mucho!

Google Play: https://play.google.com/store/apps/details?id=com.ludei.beequest
App Store: https://itunes.apple.com/us/app/bee-quest/id933854005

En un principio, y dado el estado primitivo de HTML5, los juegos eran básicamente en 2D, usando SVG, la api del contexto 2d de canvas, o combinaciones de DOM con CSS y Javascript. Con el tiempo y a medida que el estándar ha ido avanzando, la api de canvas ha ganado importancia siendo hoy por hoy la forma más extendida de realizar juegos en html5.

Poco después llega el 3d a los juegos de navegador de la mano del maravilloso WebGL, el cual permitió expandir aún más el poder de los juegos de navegador dando acceso a recursos que antes no se podía (como la gpu), permitiendo hacer juegos bastante más complejos y con un mejor rendimiento gracias a la aceleración por hadware.

El ultimo gran paso que se ha dado en este campo, es la creación de emscripten/asm.js, una herramienta que nos permite compilar código c/c++ a javascript y ejecutarlo dentro de un navegador, y en el caso que nos interesa, usar juegos que fueron principalmente diseñador en c/c++ para otros entornos, bajo webgl en el navegador. Esta herramienta ha sido básicamente la culpable de que empresas con motores de juegos consolidados hayan decidido incluir exportadores a html5 de los juegos creados bajo su producto. (Video de Unreal Engine 3 en Mozilla Firefox).

Ahora, desde mi punto de vista, hay que diferenciar bien que es lo que buscamos, como he dicho en otras ocasiones cada motor es un mundo, y puede que prefiramos un motor u otro dependiendo del tipo de desarrollo que tenemos entre manos. Si usamos motores javascript, un contexto 2d nos va a permitir hacer juegos 2d sin aceleración por hadware, un contexto webgl nos va a permitir crear tanto juegos 2d como juegos 3d acelerados por hadware, pero bajo apis diferentes (lo que quiere decir que tendrás que aprender dos formas de trabajar diferentes), y un desarrollo basado en emscripten/asm.js nos va a permitir lo mismo que en webgl pero usando otro tipo de herramientas u otro tipo de lenguajes, a cambio posiblemente sacrificaremos algo de rendimiento en dispositivos “más” antiguos al existir una capa intermedia (ojo, aunque no será lo mismo que trabajar directamente en javascript, el rendimiento puede ser muy bueno).

Llegado a este punto, dirás que esto es un rollo, que estás peor que al principio y que tu solo quieres desarrollar juegos sin preocuparte de nada más, en ese caso, estás de suerte porque existe muchísima variedad en cuanto a motores se refieren, algunos se encargarán ellos mismos de aplicar el contexto adecuado sin que el developer se tenga que preocupar de aprender nada externo a la api propia del motor, y otros usaran emscripten/asm.js dándole al programador un fichero html que subir, y listo.

He recopilado unos cuantos motores que de una forma u otra te permitirán crear juegos para navegadores, y la he organizado en 3 categorías para ayudarte a elegir, estas son: javascript/2d, javascript/webgl, y por ultimo emscripten/asm.js.

Javascript / 2d

1. CutJS

Precio: Gratuito
Open Source: Si
Web: http://cutjs.org/

2. ImpactJS

Precio: 99$
Open Source: No
Web: http://impactjs.com/

3. Wade

Precio: Gratuito bajo ciertas condiciones http://www.clockworkchilli.com/index.php/main/policy/wade_eula
Open Source: No
Web: http://www.clockworkchilli.com/index.php/developers

4. FrozenJS

Precio: Gratuito
Open Source: Si
Web: http://frozenjs.com/docs/

5. Quintus

Precio: Gratuito
Open Source: Si
Web: http://html5quintus.com/

6. FabricJS

Precio: Gratuito
Open Source: Si
Web: http://fabricjs.com/

7. MelonJS

Precio: Gratuito
Open Source: Si
Web: http://melonjs.org/index.html

8. LimeJS

Precio: Gratuito
Open Source: Si
Web: http://www.limejs.com/

9. Booty5

Precio: Gratuito
Open Source: Si
Web: https://github.com/mrmop/Booty5

Javascript / WebGL

10. PixiJS

Precio: Gratuito
Open Source: Si
Web: http://www.pixijs.com/

*No es realmente un motor o famework de juegos, más bien es un renderer

11. Phaser

Precio: Gratuito
Open Source: Si
Web: http://phaser.io/

12. PandaJS

Precio: Gratuito
Open Source: Si
Web: http://www.pandajs.net/

13. Construct2

Precio: Dispone de diferentes planes de precios.
Open Source: No
Web: https://www.scirra.com/

14. BabylonJS

Precio: Gratuito
Open Source: Si
Web: http://www.babylonjs.com/

15. Trubulenz

Precio: Gratuito
Open Source: Si
Web: http://biz.turbulenz.com/

16. SpellJS

Precio: Dispone de planes de precios
Open Source: No
Web: http://spelljs.com/

17. ThreeJS

Precio: Gratuito
Open Source: Si
Web: http://threejs.org/

18. KiwiJS

Precio: Gratuito
Open Source: Si
Web: http://www.kiwijs.org/

19. CAAT

Precio: Gratuito
Open Source: Si
Web: https://github.com/hyperandroid/caat

20. CraftyJS

Precio: Gratuito
Open Source: Si
Web: http://craftyjs.com/

21. VoxelJS

Precio: Gratuito
Open Source: Si
Web: http://voxeljs.com/

22. PlayCanvas

Precio: Dispone de planes de precios
Open Source: Si
Web: https://playcanvas.com/

23. Cocos2d-JS

Precio: Gratuito
Open Source: Si
Web: http://www.cocos2d-x.org/wiki/Cocos2d-JS

24. LycheeJS

Precio: Gratuito
Open Source: Si
Web: http://lycheejs.org/index.html

25. EnchantJS

Precio: Gratuito
Open Source: Si
Web: http://enchantjs.com/es/

26. Haxor

Precio: Gratuito
Open Source: Si
Web: http://haxor.thelaborat.org/

Emscripten / asm.js

27. GameSalad

Precio: Dispone de planes de precios
Open Source: No
Web: http://gamesalad.com/

28. Game Maker Studio HTML5

Precio: 199.98$ (GMS Pro 99.99$ + HTML5 Module 99.99$)
Open Source: No
Web: https://www.yoyogames.com/

29. Unity 5

Precio: Dispone de planes de precios
Open Source: No
Web: https://unity3d.com/es/5

30. UnrealEngine 4

*No he podido encontrar mucha más información acerca del exportador html5 de UnrealEngine4

Precio: ???
Open Source: ???
Web: https://docs.unrealengine.com/latest/INT/Platforms/HTML5/GettingStarted/index.html

Comentario final

Me hubiera gustado añadir algunos comentarios sobre cada uno de los motores para tratar de ayudar a decidir a los indecisos, pero no me pareció adecuado, ya que no he probado todos los motores aquí listados y no podría ofrecer un “juicio” real de ellos.

Lo que si puedo hacer para futuros post es comentar un poco los que si he usado, mi opinión y experiencia con ellos. Igualmente si has usado cualquiera de estos motores, y quieres añadir o compartir información al respecto me agradaría leerla en los comentarios, y si conoces algún otro motor que no esté aquí listado, y que consideres que puede interesar a otras personas, me gustaría que lo compartieras también en los comentarios.

Conseguir que un desarrollo se vea perfectamente, o de manera similar en todos los dispositivos posibles es todo una odisea, teniendo en cuenta que hacer un desarrollo para cada dispositivo no suele ser una opción debido a la perdida de tiempo y esfuerzo, duplicidades, y un largo etcétera.

Personalmente el lidiar con este tema se me hace bastante pesado, sobre todo cuando nuestro juego ha de verse correctamente en las gamas bajas y altas de android, los diferentes iphone y los nuevos ipad (retina); vamos lo que vendría a ser lo ideal, que se vea bien en todo.

Para que te hagas una idea, un Samsung Galaxy s4 tiene un aspect ratio de 16:9, mientras que un Ipad Air tiene un aspect ratio de 4:3, como te podrás imaginar, tu juego no se va a ver perfecto en ambos tan fácilmente, si todo fuera tan fácil la vida sería aburrida :P.

Tenemos diferentes formas de afrontar este tema, y cada maestrillo tiene su librillo, como en todo, pero hay 3 formas que suelen ser las más usadas, el escalado, el cropping, y el letterboxing o pillarboxing.

El Escalado

Imagina que has diseñado tu juego pensando en un Aspect Ratio de 16:9, existen muchos modelos de móviles que comparten este aspect ratio y tu decides tomar la opción más sencilla para que se adapte a todas las pantallas, que es escalar toda la capa visible de nuestro juego para que ocupe todo el espacio de la pantalla que lo muestra, pero esto implica que cuando la pantalla no comparta el mismo aspect ratio que para el que fue diseñado, la imagen se verá deformada, ya que escalara el Eje X y el Eje Y por separado. Si la diferencia de ratios no es mucha, como, quizás un 16:10, podría pasar inadvertido (que ningún diseñador me apuñale por favor!), pero si es algo más extrema, por ejemplo un ipad, en ese caso si notaremos el cambio. Esto hace que la opción más sencilla quizás no sea la más adecuada en la mayoría de los casos.

El Cropping

Sigue manteniendo en tu imaginación que has diseñado tu juego para nuestro (mi) aspect ratio favorito, 16:9, y que has probado el sistema de escalado pero no te ha terminado de convencer debido a la deformación que puede provocar al cambiar de dispositivo.  Así que decides optar por el sistema de cropping.

Cropping no es otra cosa que recortar la escena manteniendo el foco en lo que nos importa. Por ejemplo, si nuestro juego es landscape (apaisado), podemos usar la altura de nuestra escena como referencia, esta escalaría hasta adaptarse a la pantalla (manteniendo siempre la proporción del aspect ratio), y de esta forma nuestra escena no se vería deformada, ya que el espacio sobrante están situados fuera de la pantalla.

El principal problema de este sistema, es que nuestra GUI (interfaz de usuario) y el contenido de nuestra escena ha de ser bastante flexible, de manera que permita recolocar los elementos que necesitamos a nuestro antojo dependiendo de la pantalla a la que nos adaptamos para no dejar fuera de la vista nada importante, y esto tampoco es posible en todos los tipos de juegos.

Letterboxing o pillarboxing

En este punto ya hemos probado los sistemas anteriores, pero no terminan de encajar con la forma en la que hemos diseñado/pensado ese juego que nos hará retirarnos al caribe, así que buscamos más opciones.

El letterboxing y el pillarboxing básicamente son lo mismo, simplemente debemos de mantener inamovible nuestro aspect ratio y adaptar uno de nuestros tamaños (ancho o alto) a el tamaño de la pantalla. De esta manera dejamos dos franjas negras en los bordes, si ajustamos a lo alto quedarán dos franjas negras por los laterales (pillarboxing) y si ajustamos a lo ancho nos quedarán dos franjas negras por arriba y por debajo de nuestra escena (letterboxing).

Seguro que esto lo has visto mucho en el cine, y también en algunos juegos, principalmente en los juegos de PC; pero en los juegos móviles normalmente se intenta evitar esto, ya que da la impresión de que se está desaprovechando esa gran pantalla por la que el usuario ha pagado una pasta, así que en vez de dos franjas negras se suelen mostrar adornos de algún tipo, de manera que se entienda que son una parte más de la escena.

Un ejemplo de juego que recurre al pillarboxing puede ser el juego The Sandbox:

Si nos fijamos podemos ver como la escena de juego, donde transcurre la acción, se ha adaptado a la pantalla usando el alto como referencia a seguir, y al ser la pantalla de un aspect ratio con un ancho mayor a como fue diseñado el juego, se ha optado mostrar dos pilares de piedra a los laterales. De esta forma todo el espacio de la pantalla queda cubierta y tu mantienes la proporción de tu juego intacta y no te complicas alterando la escena sobre la marcha ni nada por estilo.

Como ejemplo de letterboxing podemos mirar el juego Jetpack Joyride:

Al contrario que en The Sandbox, el Jetpack Joyride se adapta a la pantalla usando el ancho como referencia, en este caso cuando el aspect ratio no es el mismo que con el que el juego fue diseñado se muestran dos franjas en la parte superior e inferior del juego, que serían las que están afuera de las lineas rojas.

Hay que resaltar en este caso, que la integración visual es tan buena que he tenido que marcar con lineas rojas lo que no pertenece al núcleo del juego para que se pueda apreciar correctamente.

Extra

En Ludei he aprendido otro método para gestionar la forma en la que los juegos se han de adaptar a las pantallas, principalmente gracias a motores como CAAT que permiten gestionar los objetos como contenedores de otros trasmitiendoles posiciones y escalas a sus hijos de manera transparente para el programador. Básicamente es una combinación de los métodos anteriormente nombrados. Se utiliza un background sencillo que se adapta al tamaño total de la pantalla, y de manera separada se sitúa encima de este un contenedor que contiene todos los elementos del juego; mientras que el background se adapta (escalado), el contenedor junto a todos sus hijos mantiene siempre el aspecto y la proporción con la que fueron diseñados (letterboxing o pillarboxing), de esta forma ocupamos toda la pantalla, no alteramos el diseño original, y el mismo desarrollo sirve para todos los tipos de pantallas.

Conclusión

La única conclusión que puedo sacar de todos estos métodos es que no hay ninguno perfecto, como ya he mencionado cada desarrollo requerirá que uses uno u otro, con mejor o peor suerte en tu elección, pero sin duda es un aspecto que hay que tener pensado y solucionado antes de empezar con la lógica del juego si quieres evitar dolores de cabeza. También hay que pensar que el motor con el que desarrollemos es un condicionante importante en muchos sentidos, y que la forma en la que podemos adaptar el juego a los diferentes dispositivos puede estar entonces condicionada también, cada motor es un mundo.

En lo personal creo que la técnica que nunca usaré por si sola es la del escalado, no me gusta nada que un juego se vea “encogido”, “estirado” o simplemente deformado al cambiar de dispositivo.

Te animas a contarnos que problemas te has encontrado al portar a diferentes dispositivos, y ¿como lo has solucionado?

—
PD: La imagen de ejemplo con el paisaje la saqué de aquí, he intentado buscar de donde proviene pero no he encontrado nada.

GulpJS nos permite gestionar fácilmente las tareas que debemos realizar a la hora de pasar nuestro proyecto del estado de desarrollo al estado de producción, como por ejemplo minificación de css, renombrado de ficheros, compresión de javascript, e incluso nos permite hacer watching (monitorizar) los archivos o directorios que le indiquemos para que al cambiar algo de estos ejecute las tareas que le asignamos de manera automática. Pero esto no es todo, hay muchos módulos que proveen a gulp de funcionalidades realmente útiles, seguro que encuentras alguna que haga exactamente lo que buscas, y sino es así, siempre podrás hacerla tu!.

Por ejemplo, yo actualmente lo estoy usando en el proyecto de una webapp, donde monitoriza la carpeta donde tengo mis módulos javascript y mis ficheros LESS, si detecta un cambio en alguno de los ficheros javascript ejecuta la tarea de comprimir todos los módulos en un solo fichero y moverlo al directorio del proyecto donde está la versión de producción, igual pasa con los ficheros less, si cambio alguno automaticamente compila todos mis ficheros a un solo fichero css y lo mueve a producción; lo mejor de todo esto es que ocurre realmente rápido, casi imperceptible, hago un cambio, refresco la web y el cambio ya está ahí. Entonces… ¿Empezamos?.

Instalando Gulp

Dando por hecho que tienes instalado en tu sistema node y npm vamos a abrir un terminal y instalar gulp:

sudo npm install -g gulp

A continuación vamos a crear el fichero package.json de tu proyecto, para ellos disponemos de dos formas, la primera y más sencilla es poner en la terminal desde el directorio de tu proyecto:

npm init

El programa te irá haciendo una serie de preguntas, las cuales mayormente podrás dejar en blanco o poner lo que el mismo terminal te sugiere, la otra opción es creando tu mismo el fichero a mano, que ha de contener algo como esto:

{
    "name" : "nombre-de-mi-proyecto",
    "version": "0.0.0"
}

Una vez que lo tengamos creado instalamos gulp como dependencia de desarrollo de nuestro proyecto:

npm install --save-dev gulp

Si ahora miras el contenido de tu package.json verás que se ha añadido algo como esto:

"devDependencies": {
    "gulp": "^3.8.6"
}

Básicamente no solo hemos instalado gulp en el proyecto sino que se ha quedado registrado para que la próxima vez que tengas que hacer una instalación del proyecto baste con un simple:

npm install

Eso instalará nuestro proyecto con todas sus devDependencies en el futuro.

Creando nuestras tareas

Ha llegado el momento de crear nuestras primeras tareas basadas en gulp, para ello creamos un fichero en el directorio de nuestro proyecto llamado gulpfile.js. Este script será quien contenga todas las instrucciones de las tareas que queremos ejecutar en nuestro proyecto. Pero antes deberemos de instalar los modulos que nos hacen falta.

Por ejemplo, queremos unificar y comprimir dos ficheros javascript, para este caso podríamos usar el modulo gulp-uglifyjs:

npm install --save-dev gulp-uglifyjs

Ahora vamos a editar el fichero gulpfile.js, primero que nada, llamamos a los modulos gulp y gulp-uglifiyjs:

var gulp = require('gulp'), 
uglify = require('gulp-uglify');

Ahora, definimos una tarea:

gulp.task('scripts', function(){ 
    console.log('it works!'); 
});

Guardamos el script y nos dirigimos nuevamente a la terminal para poner:

gulp scripts

Que nos mostrará algo como esto:

[15:45:14] Using gulpfile ~/demo/gulpfile.js
[15:45:14] Starting 'scripts'...
it's works!
[15:45:14] Finished 'scripts' after 78 μs

Fácil ¿verdad?, vamos entonces a hacer algo productivo con el modulo uglifyjs que hemos instalado, volvemos a la definición de nuestra tarea a indicarle que ficheros ha de usar, para ello usaremos gulp.src(), al cual le podemos pasar un string o un array con varios strings en su interior, en nuestro caso vamos a pasarle un string simple con un directorio:

var myScripts = 'src/**/*.js'; //Directorio que contiene nuestros scripts 
gulp.task('scripts', function(){ 
    return gulp.src(myScripts); 
});

Pero esto por si solo no hace nada, debemos encadenarle las acciones que ha de realizar con estos ficheros:

var myScripts = 'src/**/*.js'; 
gulp.task('scripts', function(){ 
    return gulp.src(myScripts) 
        .pipe(uglify('main.min.js')) //comprime a main.min.js
        .pipe(gulp.dest('./dist')); //Destino del nuevo fichero en el directorio ./dist 
});

Con esto le estamos indicando a gulp que coja cualquier fichero javascript que se encuentre bajo el directorio src y lo comprima en un solo fichero llamado main.min.js en el directorio ./dist de nuestra aplicación.

Pero, ¿que pasa si necesitamos comprimirlos en orden?, puede darse el caso de que debamos incluir nuestros módulos javascript en cierto orden debido a las dependencias que tienen, para ese caso simplemente tenemos que cambiar en gulp.src() el string que contiene el directorio, a un array con todos los scripts ordenados:

var myScripts = [ 'src/uno.js', 'src/dos.js' ];

Volvemos a la terminal, ejecutamos gulp scripts y aparecerá nuestro script listo para producción en el directorio ./dist.

Muy bien, con esto tenemos definida una tarea simple, pero se nos puede hacer pesado estar ejecutando gulp scripts a cada cambio que realizamos, así que vamos a crear una tarea que monitorize nuestras scripts y automáticamente ejecute la tarea scripts.

Creamos una nueva tarea llamada watch (o como quieras llamarla), le pasamos los ficheros o directorio que ha de monitorizar, y un array con las tareas que ha de llevar a cabo cuando ocurra algún cambio:

gulp.task('watch', function(){ 
    gulp.watch(myScripts, ['scripts']); 
});

Ahora desde terminal, en vez de ejecutar gulp scripts, ejecutaríamos gulp watch, y así cada vez que hiciéramos una modificación a uno de nuestros ficheros javascript se ejecutaría de manera transparente para nosotros la tarea scripts. Si tuvieras más tareas definidas que quisieras ejecutar cuando se detecta un cambio simplemente tendrías que añadirlas al array que le pasamos como segundo parámetros a gulp.watch en el orden que quieras que se ejecuten. También puede darse el caso de que quieras hacer watch de diferentes directorios y que ejecuten diferentes tareas, entonces simplemente añade otro gulp.watch a la tarea:

gulp.task('watch', function(){ 
    gulp.watch(myScripts, ['scripts']);
    gulp.watch('miOtroDirectorio',['miOtraTarea']); 
});

Como ya dije hay muchos módulos de diversas funcionalidades, cualquier cosa que se pueda automatizar seguro que tiene su modulo correspondiente, pero normalmente los módulos o librerías de gulp suelen ser bastante específicos en su función, esto quiere decir que un modulo que comprime quizás no haga renombrado de ficheros, y en ese caso tendrás que encadenar diferentes módulos dentro de la misma tarea, pongamos como ejemplo un compilador LESS, cumple su función compilando, pero no nos permite cambiar el nombre al css resultante, así que vamos a instalar en esta ocasión dos dependencias para hacer esta tarea, gulp-less y gulp-rename:

npm install --save-dev gulp-less gulp-rename

Como de costumbre los añadimos a nuestro fichero gulpfile:

var gulp = require('gulp'), 
    uglify = require('gulp-uglifyjs'), 
    less = require('gulp-less'), 
    rename = require('gulp-rename');

Y creamos la tarea correspondiente, encadenando una detrás de otras las acciones que ha de hacer nuestra tarea:

gulp.task('css', function(){ 
    return gulp.src('src/main.less') 
        .pipe(less()) //Compilamos 
        .pipe(rename('compiled-style.css')) //Renombramos
        .pipe(gulp.dest('./dist')); //Indicamos destino 
});

Imaginando que tenemos un archivo llamado main.less en el directorio ./src, al ejecutar en la terminal gulp css compilaría este less a css, lo renombraría a compiled-style.css y lo ubicaría en ./dist, si elimináramos la linea que incluye el rename el fichero resultante se llamaría main.css. Como ves puedes encadenar todas las acciones que te hagan falta, por ejemplo en este caso podríamos añadir también una modulo que minificara el fichero resultante, pero a estas alturas seguro que ya sabrás hacerlo tu mismo.

Todo esto está muy bien, pero se hace algo pesado ir ejecutando las tareas una a una mediante gulp nombreTarea, así que lo vamos a definir dentro de una tarea llamada default, así tan solo debemos ejecutar gulp en la terminal y se ejecutarán todas las tareas y si una de las tareas es watch pues se quedará observando:

gulp.task('default', ['scripts', 'css', 'watch']);

Con esto hacemos que al poner simplemente gulp en la terminal se ejecute primero la tarea scripts, luego css y por ultimo watch, y de esta forma nos despreocupemos por estar ejecutando nosotros todo por separado.

Espero que esta pequeña introducción sea de utilidad, he dejado disponible el código en Github por si alguien quiere echarle un ojo. Investigad en la pagina de plugins que funcionalidades existen, seguro que alguna os sorprende, y si queréis dejar en los comentarios que usos le das tu a gulp o cualquier duda o sugerencia, será bien recibida!.

Aún así, para mi sorpresa la gente sigue visitando el blog, no como cuando publicaba casi a diario, pero eso tiene remedio :).

El ultimo año para mi ha sido realmente intenso, he aprendido muchísimas cosas nuevas, y he vivido muchísimos cambios, uno de los más grandes ha sido dejar un trabajo en el que llevaba muchos años y me sentía estancado, para entrar a trabajar en Ludei como Javascript/Game Developer, donde en pocos meses he aprendido más que en toda mi vida, el estar rodeado de tanta buena gente y tanto crack es simplemente impresionante, os podéis hacer una idea leyendo este post de mi amigo Carlos -> http://nogg-aholic.es/como-es-trabajar-rodeado-de-programadores-con-talento/.

Mi idea es coger un ritmo adecuado de publicación en el blog, a diario… no. A diario requiere demasiada dedicación y te deja poco tiempo para side projects o simplemente experimentar, por lo que de momento no lo volveré a hacer. También añadiré videotutoriales que seguro son un buen complemento para entender algunos post, o directamente el video, sin el post, depende del tema.

Sin más, tengo una larga lista de cosas de las que quiero hablar, ahora solo me queda encontrar algo de tiempo, las ganas, y retomar esta sana costumbre.

Llevaba tiempo queriendo presentarme a una Ludum Dare, todo el mundo comentaba lo maravilloso que era participar y yo no podía hacer que otra cosa que no fuera verlo desde fuera.

Al principio no me presentaba porque no me veía capaz/preparado para afrontar el desarrollo de un juego en tan solo 48 horas, y cuando me empezaba a ver “algo” capacitado no tenía tiempo, pero por fin en ésta última ocasión me vi capaz y motivado, y por suerte la fecha era un fin de semana en el que no tenía ningún compromiso, llegó el momento.

Unas horas antes de la Ludum Dare hablé con mi amigo Rubén Del Castillo para ver si quería participar, y no dudo ni un instante en unirse, quedamos a las dos de la mañana para ver que tema salía elegido y así los hicimos, a las dos estábamos despiertos y mirando como dos tontos en blanco el tema “You Only Get One”, pero que demonios…

Divagamos entre muchas ideas, tratando de ajustarnos todo lo posible al tema, estuvimos dando palos de ciegos al menos hasta las 4 o 5 de la mañana, donde desistimos y decidimos ir a dormir, dejándolo pendiente para la mañana de ese mismo día, cuando estuviéramos más despejados. Curiosamente mientras dormía se me ocurrieron unas mecánicas que cuadraban con el tema, y al contárselo a Rubén se le ocurrió una temática para el juego que también encajaba, un espermatozoide que debe llegar al óvulo, toma ya, toda una absurda genialidad ajajaja.

Esa misma mañana nos pusimos manos a la obra, el a diseñar y dibujar y yo a programar. Desde un comienzo tenía claro que el juego debía de ser html5, ya que, cuantas más facilidades tengan los usuarios para jugar más votos puedes conseguir, no es lo mismo entrar en un enlace y jugar que tener que descargar un archivo, instalar un plugin, o similares.

Como motor usé Game Maker Studio, llevaba ya unos meses usandolo y sabía que me permitiría programar rápidamente sin pararme demasiado en cosas como los assets, gestionar sprites, etcétera. Por lo general no uso sus herramientas “drag&drop”, no me gustan, prefiero programar directamente, en este caso en GML un lenguaje propio del motor, pero he de reconocer que la interfaz y la forma en la que está diseñado el motor te permite prototipar y desarrollar muy rápido. No tuve problemas significativos durante el desarrollo exceptuando las colisiones con los límites de la escena, que no funcionaban como debían, y de hecho no lo hacen, perdí mucho tiempo con este tema, ya que “los controles” del personaje y el sistema de colisiones no eran del todo compatibles, así que hice un apaño que funciona pero que no quedó bonito porque genera un efecto de “rebote” del personaje al tocar un limite, pero bueno, el tiempo corría y no podía pararme demasiado a probar.

Durante el desarrollo lo que más nos costó desde mi punto de vista fue comunicarnos correctamente. Al trabajar separados y ser la primera vez que trabajamos juntos se hacía complicado hacer entender al otro el concepto que teníamos en la cabeza, en ambos sentidos, tanto de arte como de diseño y mecánicas, algunas veces cuando veíamos algo hecho se oía la frase “pensé que decías…, te había entendido…”. Al final todo cuadraba como debía y creo que hemos aprendido a comunicarnos de manera más eficiente, estoy seguro de que en el futuro seremos capaces de desarrollar juntos juegos más trabajados y gestionado el tiempo de manera más eficiente.

Durante el desarrollo probamos y debatimos varios modos de controlar al personaje, y curiosamente elegimos el “peor”. Una vez terminamos el juego parece que a la gente le gustó bastante, pero la mayoría se quejan de los controles que elegimos, en un principio son “complicados de coger” pero una vez que te acostumbras te olvidas, y creo que ese fue nuestro problema, nos acostumbramos a usarlo así y no luego no volvimos a pensar en ellos, pero tomamos nota para el futuro.

Terminamos casi en el último momento, a menos de media hora para el final subimos el juego, y en pocos minutos ya teníamos nuestros dos primeros comentarios. Hasta el momento la experiencia ha sido genial, hemos desarrollado un juego “curioso” en pocas horas, y yo me quedo con que trabajar con Rubén ha sido una “gozada”, su imaginación y la calidad de su trabajo es lo mejor que me llevo de esta LD.

Parece que este no será el último proyecto que desarrolle con Rubén, más bien es el primero de muchos que vendrán. Es más ya estamos pensando en un rediseño total de este juego, y planes con más gente, pero eso es otra historia, ya tendré tiempo de contarla, de momento si quieres puedes jugar un rato a Spee The Sperm!

Spee en la LD:http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=19585
Enlace directo:http://www.nazariglez.com/ld28/

Pero desde hace unos tres meses estoy más centrado, voy sintiéndome cómodo con diferentes herramientas y tecnologías a la hora de trabajar y creo que estas forman mi abanico de trabajo. Tengo muchas cosas que contar en el blog, y espero que pronto se vean los resultados de esta etapa, tengo planes para el año próximo y aún unos meses por delante para trabajar en mis ideas.

En los próximos dias trataré de actualizar el blog con algunas cosas interesantes que he descubierto, hasta entonces! Un Saludo

Su funcionalidad en sí en bastante sencilla, solo se permite una partida a la vez ya que no hago uso de “rooms” (salas), cosa que me gustaría tocar en el blog pronto. Para empezar introducimos nuestro nombre y ingresamos al chat, el tablero de juego es visible desde el comienzo, si hay jugadores en plena partida podemos observar como evoluciona ésta, si no hay jugadores podemos unirnos y esperar un contrincante. El chat nos indica quien entra o sale de la aplicación y quien gana y pierde la partida en curso.

Vamos a lo interesante, la tecnología que hay detrás de la aplicación, he tratado de comentar todo lo posible el codigo así que explicaré ligeramente solo algunos detalles.

Primero el cliente; Como verás en el código no he usado ningún sistema de plantillas, simplemente sirvo un fichero html que se encuentra en el directorio “/public”. En esta ocasión tampoco he usado el elemento canvas, sino que uso divs y los altero mediante Javascript (Jquery), mostrando así lo que el servidor le indica a través de los websockets. He usado LessCSS para el estilo, pero es todo muy minimalista, lo uso por comodidad realmente.

La aplicación no usa base de datos, por lo que para almacenar los nombres de usuarios online y no repetirlos uso un array, que se comprueba cada vez que ingresa un nuevo jugador, sobra decir que al cerrar y abrir la app perdemos todos los usuarios, además para evitar inyección de código he usado el modulo “sanitizer”.

Lo mejor de Socket.io es que la información referente al socket está en formato JSON por lo que aprovecho para guardar el nombre del usuario como parte de el, en socket.nick, y así poder identificar al usuario fácilmente. Por ejemplo es útil cuando se desconecta un usuario compruebo el nick y lo elimino del array de usuarios y anuncio su desconexión al resto de jugadores.

Otro punto que me gustaría comentar es el uso de callbacks al emitir información mediante socket.io, yo lo he usado por ejemplo para medir la latencia, pero es realmente útil. Normalmente vemos ejemplos en los que emitimos un evento mediante socket.emit y recibimos respuesta mediante socket.on, algo así:

Cliente:

socket.emit('hola', true); socket.on('hola', function(){});

Server:

socket.on('hola', function(data){ 
    if(data)socket.emit('hola', true); 
});

Pero si nuestro propósito es enviar una información y dependiendo de la respuesta realizar una determinada acción siendo siempre el mismo usuario, ¿Por que no usar un callback?, sería mucho más eficiente:

Cliente:

socket.emit('hola', true, function(data){});

Server:

socket.on('hola', function(data, callback){ 
    if(data){ 
        if(callback && typeof callback == 'function'){
            callback(data); 
        } 
    }
});

No me quiero enredar demasiado ni explicar cosas que ya estén explicadas en el código, así que os dejo un enlace a la demostración y al código alojado en github.

Github:https://github.com/Nazariglez/3enraya-nodejs-socketio
Demo:http://www.estoycreando.com/3enraya/

Por norma general el puerto por defecto para las aplicaciones web suele ser el puerto 80, supongamos entonces que tenemos una aplicación ocupando el puerto 80 bajo el dominio localhost, al entrar en http://localhost/ nos mostraría nuestra aplicación, pero si queremos usar el mismo servidor con otra aplicación simultáneamente deberemos de elegir otro puerto de escucha, el 3000 por ejemplo, en ese caso al entrar en http://localhost/ veremos la aplicación en el puerto 80, y al entrar en* http://localhost:3000/* veremos la otra.

No es muy bonito ¿no?, no me veo a una empresa dando su web en plan “http://pincelesybrochasmanolo.com:3000”. Entonces, ¿que hacemos?. Necesitamos un servidor que gestione las redirecciones de manera interna, de forma que al facilitarle una ruta en concreto el nos muestre la aplicación que definamos de una manera limpia para el usuario final dando igual el puerto que sea. Así podríamos tener un “hola mundo” en el puerto 3000, un chat en el 4000, y un blog en el 4500 de forma que usando rutas tipo http://localhost/chat/, http://localhost/hola/ o http://localhost/blog/ nos mostrara las aplicaciones correspondientes.

Tomando como sistema operativo ubuntu, voy a ir realizando los pasos necesarios para lograr esto, para ello solo necesitamos 4 cosas, NodeJS, NPM, Nginx y Screen.

Lo primero es instalar la ultima versión de NodeJS y NPM; abrimos un terminal y tecleamos:

sudo apt-get install python-software-properties 
sudo add-apt-repository ppa:chris-lea/node.js 
sudo apt-get update 
sudo apt-get install nodejs

Este repositorio nos facilita la ultima versión de node y de npm solo instalando el paquete nodejs, si estás exceptico y quieres comprobar que npm también se ha instalado solo tienes que realizar un npm -v en la terminal.

Si ahora creáramos dos aplicaciones que nos mostrara Hola mundo en la pantalla bajo diferentes puertos, y quisiéramos abrir ambas nos encontraríamos en que hemos de cerrar una para poder abrir otra, o abrir varias terminales, por lo que no es muy útil si tengo que tener abierta indefinidamente una sesión ssh con cada una de las aplicaciones. Para solucionar esto usaremos Screen.

sudo apt-get install screen

Screen es un emulador de terminales virtuales, viene a ser la soluciones perfecta a nuestro problema, puesto que nos permite abrir terminales para ejecutar nuestras aplicaciones y abandonar la sesión sin cerrar la terminal (virtual), dejándola en un segundo plano trabajando.
Su uso es realmente muy sencillo, con el comando “screen” en una terminal abriremos una nueva terminal virtual, trabajamos con ella de manera normal y cuando queramos dejarla en segundo plano pulsaremos la combinación de teclas control + A, y a continuación la tecla D en solitario, esto nos devolverá a la terminal inicial relegando la virtual a un segundo plano. Ahora podemos abandonar la sesión ssh sin miedo a cerrar la aplicación que tenemos en funcionamiento. Para recuperar está terminal virtual basta con teclear screen -r, si queremos cerrarla totalmente simplemente tecleamos exit en ésta y se cerrará. Si tenemos más de una terminal virtual abierta y usamos el comando screen -r nos informará de que hay varias terminales en segundo plano, y facilitándonos el numero de identificación de cada una, debemos usar screen -r [numero] para ver una en concreto. Podéis encontrar más información sobre los comandos de screen aquí http://www.guia-ubuntu.com/index.php?title=Screen.

Ahora que tenemos NodeJS, NPM, y Screen instalado queda el tema de redireccionar las rutas a puertos concretos de nuestro servidor.

Nginx será el encargado de ésta tarea. En resumen se trata de un servidor web/proxy, lo mejor para entender su potencial es dirigirnos a la información que nos facilita la wikipedia sobre el: http://es.wikipedia.org/wiki/Nginx.

Para instalarlo en nuestro Ubuntu introducimos lo siguiente en una terminal:

sudo add-apt-repository ppa:nginx/stable 
sudo apt-get update 
sudo apt-get install nginx

Una vez se ha instalado en nuestro sistema procedemos a configurarlo. Una buena idea es redireccionar los acceso al dominio sin www al que si las tiene, o viceversa, podemos hacerlo desde su fichero de configuración, para acceder a el:

sudo nano /etc/ngnix/ngnix.conf

Como verás al abrirlo la configuración esta organizada en un formato similar a JSON, buscamos en este http {} y añadimos lo siguiente:

server { 
    listen 80; 
    server_name midominiosinwww.com;
    return 301 $scheme://www.midominioconwww.com$uri; 
}

De está forma estamos indicando a los navegadores y bots que accedan a nuestro dominio (puerto 80 por defecto) que se ha redirigido de manera permanente al indicado en la linea return. Esto es cuestión de gustos, quizás no quieras la redirección, o quizás te guste más sin www o al revés, personaliza las lineas de forma que se adapten a lo que buscas.

Lo siguiente es indicar el fichero por defecto que se ha de mostrar al entrar a la raíz del dominio, para eso añadimos esto a nuesta configuración dentro de http {}:

server { 
    listen 80; 
    server_name www.midominioconwww.com;
    location / { 
        root /home/midominio;
        index index.html;
    }
}

Le estamos indicando que al entrar un usuario le sirva el fichero index.html que se encuentra en el directorio /home/midominio/ de nuestro servidor, esta podría ser nuestra Landing Page, seguimos con la redirección a nuestras aplicaciones NodeJS que están funcionando en segundo plano gracias a screen.

Añadimos dentro de esta configuración de server lo siguiente:

location /hola/ { 
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host; 
    proxy_set_header X-NginX-Proxy true; 
    proxy_pass http://localhost:3000/; 
    proxy_redirect off; 
}

Así por cada ruta que necesitemos, cambiando ésta en la linea location e indicando la dirección de la aplicación que ha de servir en la linea proxy_pass, la configuración final podría ser algo parecida a esto:

server { 
    listen 80; 
    server_name www.midominioconwww.com; 
    location /hola/ { 
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true; 
        proxy_pass http://localhost:3000/;
        proxy_redirect off;
    } 
    location /chat/ { 
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true; 
        proxy_pass http://localhost:4000/;
        proxy_redirect off; 
    } 
    location /blog/ { 
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true; 
        proxy_pass http://localhost:4050/;
        proxy_redirect off; 
    } 
    location / { 
        root /home/midominio index index.html; 
    } 
} 
server { 
    listen 80; 
    server_name midominiosinwww.com; 
    return 301 $scheme://www.midominioconwww.com$uri; 
}

Guardamos el documento y reinciamos nginx mediante:

sudo service nginx restart

Ya podemos acceder mediante las urls que tengamos definidas a nuestras aplicaciones Node (u otras) de una manera limpia de cara al usuario.

No busco profundizar mucho en nginx porque de momento no se mucho más de lo que he puesto aquí, si quieres seguir profundizando en su configuración (que es muy versatil) puedes echarle un ojo aquí: http://wiki.nginx.org/Configuration