Desde hace un par años tengo la intencion de meterme de lleno a Javascript, las razones de porque se analizan en este post:
http://nilclass.blogspot.com.ar/2014/01/vuelta-el-blog.html
Considere que una buena manera de empezar, es con un proyecto "real", o sea que tenga como proposito desarrollar algo que sea utilizado (jugado) por un usuario final.
Podria crear algo nuevo o no, pero lo mas importante para mi es que el desafio sea tecnico: CSS, HTML, WebGL, Social Buttons, backend (o no), etc.... Por eso mismo decidi hacer un remake de un juego que me gustaba mucho, que se llamaba
QUADNET
Quadnet
Es un juego original, sencillo, y al mismo tiempo muy bueno justamente por su sencillez. Es el proyecto perfecto como desafio introductorio al desarrollo de juegos en alguna plataforma.
El desarrollo
Como la mayoria de las cosas que hice las tuve que aprender, me plantie resolver solo un problema a la vez, en este orden:
- Como y donde hostear el juego: en una pagina de github
- Hacer objetos graficos del juego en una version rudimentaria (por ej: los asteriodes eran simples esferas)
- Desarrollar la logica basica del juego
- Completar el aspecto grafico de los objetos
- Efectos de explosiones similar al original
- Sonidos
- Musica :), tampoco me dedique a crear nada nuevo en este aspecto, pero si re-edite la musica del juego original de 1998
- Optimizar las explosiones, porque hasta en un dual core se laggeaba :(
- Menu y pantallas de presentacion del juego, incluyendo instrucciones de como jugarlo
- Pantalla de "Leaderboard" que muestra los puntajes mas altos
- Botones de redes sociales
- Hacer que el Leaderboard sea online
Lecciones Aprendidas
Como ya mencione, el objetivo mas importantes que me plantie con este proyecto es aprender
javascript "haciendo algo", y con este primer proyecto si que tuve que aprender varias cosas nuevas
Three.js
Por los visto, es
LA libreria JS para hacer graficos 3D con
WebGL en el browser, el API provisto por los browsers es apenas la minima necesaria para poder acceder a la funcionalidad (casi un calco de lo que es el API que se usaria en C) por lo que no tienen ninguna clase, patrones, funcionalidades accesorias, recursos (por ej shaders) que si agrega una libreria como
three.js. Sin duda es preferible utilizar three.js a programar directamente sobre WebGL, al menos para empezar, y fue el caso con este proyecto.
Para mas informacion, vean los ejemplos de lo que esa libreria esa capaz de hacer de manera bastante sencilla:
http://threejs.org/examples/
Promises
Promises es un patron muy util en javascript que se implemento como respuesta al tan temido
callback hell, "callback hell" es lo que sucede cuando en javascript, se necesita realizar muchas operaciones asincronicas en secuencia (practicamente todo lo que puede demorar es asi en javascript) y aparentemente la mejor opcion si tenemos que hacer 1,2 y 3, llamemos a 2 en el callback de 1, a 3 en el callback de 2, y asi:
// hago tres request, una atras de otra
$.get('/url1/resource1', function(data1) {
// hacer cosas con data1
$.get('/url2/resource2', function(data2) {
// hacer cosas con data1
$.get('/url3/resource3', function(data3) {
// hacer cosas con data3
});
});
});
Pero en lugar de eso...
$.get('/url1/resource1')
.then(function(data1){
// hacer cosas con data1
return $.get('/url2/resource2');
})
.then(function(data2){
// hacer cosas con data2
return $.get('/url3/resource3');
})
.then(function(data3){
// hacer cosas con data3
});
Realmente hay que ejecutar esos request en secuencia?, si el resultado de uno no influye en como hacer los otros, se podria hacer asi para ejecutarlos en paralelo
$.when(
$.get('/url1/resource1').done(function(data1){
// hacer cosas con data1
}),
$.get('/url2/resource2').done(function(data2){
// hacer cosas con data2
}),
$.get('/url3/resource3').done(function(data3){
// hacer cosas con data3
})
);
Pero, "necesito combinar data1, data2 y data3 para hacer algo con los tres". Entonces:
var data1, data2, data3;
$.when(
$.get('/url1/resource1').done(function(result){
data1 = result;
}),
$.get('/url1/resource2').done(function(result){
data2 = result;
}),
$.get('/url1/resource3').done(function(result){
data3 = result;
})
).done(function() {
// termino de ejecutar las tres peticiones
// puedo hacer algo con data1, data2 y data3
});
En estos ejemplos utilize
deferred, la implementacion de Promises que viene con
jQuery, en mi proyecto utilize
Promise que es otra alternativa, ambas son muy similares y el usar una u otra depende de la situacion (por ej, si ya estas usando jQuery tenes a mano deferred, pero talvez te interese Promise por el hecho de que implementa un API mas similar a la que aparentemente se estandarizara)
Memory Leaks
El entorno del browser (o node) donde corre javascript se encarga de gestionar la memoria mediante un Garbage Collector, tal como ocurre en Ruby, Python, Java, #NET y muchos otros, sin embargo esto no lo deja exento de problemas relacionados con Memory Leaks
En C o en C++ se debe utilizar la funcion free o la palabra reservada delete siempre para liberar la memoria que ocupa un objeto, en Javascript como ya se menciono esto ocurre automaticamente, pero el riesgo del memory leak ocurre cuando inadvertidamente se crean colecciones muy grandes de referencias a objetos, que nunca seran liberados de la memoria porq el garbage collector los considerada "reachables"
En C y en C++ la pesadilla de los memory leaks si mitiga con herramientas como
Valgrind que detecta elementos en el heap no liberados.
En Javascript la primer herramienta que tuve a mano es el potente
Heap Snapshot de Chrome, creo que el titulo lo dice todo: captura el estado actual del heap con todos sus objetos, y ademas muestra quien tiene referencia a quien, y la razon por la cual el GC no decidio borrarlo (que otros objetos o funciones-scope tienen referencais a el)
Por supuesto que al uso de esta herramienta se complementa las buenas practicas de la gestion de memoria dinamica, en el caso de C++ era asegurarse de borrar cosas en el destructor y usar la palabra new lo menos posible, o al menos encapsular toda esa gestion de memoria en una clase estructura (Arboles, listas, etc...)
En el caso de Javascript por el momento solo conozco una tres cosas (me faltaria averiguar si hay mas)
- Setear a null las referencias que no se usaran mas, esto nos asegura que esas referencias no van a retener la liberacion de los objetos, no conviene usar delete porque acarrea problemas de performance
- Evitar los closures innecesarios, ya que cuando se crean los closures estos matienen referencia a los scopes con sus variables y todos los objetos
- Evitar tener arrays de objetos que crecen constantemente y sin ningun tipo de control
CSS Transitions and Transforms
No puedo creer lo sencillo que es setearlas, y las posibilidades que tiene, para dar un ejemplo, pasen el puntero por esta imagen:
Que paso?, la imagen tiene una class "escalando", entonces con este CSS:
img.escalando:hover {
transform:scale(5,5);
-ms-transform:scale(5,5); /* IE 9 */
-webkit-transform:scale(5,5); /* Opera, Chrome, and Safari */
transition: all 1s ease-out;
}
Se logra.
- Que cuando se pase el puntero por el elemento img, con class escalando, le aplique una transformacion de escalado a 5 veces su tamaño, y
- Que utilice una transition que aplica a todos sus atributos de estilos (incluyendo al width y al height), esta transition en este caso dura un segundo (1s) y la hace con efecto de desaceleracion (ease-out)
Local Storage
Una nueva feature de HTML5, me sirvio para almacenar los highscores, la idea sencillamente es almacenar datos en la maquina donde se esta ejecutando la pagina, seria similar a lo que son las cookies, pero con la diferencia que no expiran y hay un espacio mas amplio (alrededor de 5MB por dominio en Chrome, en otros browsers anda mas o menos por lo mismo)
Se estructura como un hash clave-valor y su uso es tan sencillo como hacer esto:
window.localStorage.setItem("keyname", value)
Firebase (y el no-backend)
Mas tarde, muchos me dijeron o plantearon que seria interesante que la tabla de
highscores no sea algo local a la maquina donde corre el juego, que sea algo centralizado para todas las instancias del juego, eso haria que el juego se convierte facilmente en algo competitivo, y casi "social".
De una imagine la solucion clasica: un aplicacion
backend desarrollada posiblemente con Ruby con algun framework sencillo como sinatra, o desarrollada con Node.js, talvez hosteada en Heroku con su DB (algo simple, solo una tabla con los puntajes mas altos), y por supuesto el juego mandando los request a ese server
Pero alguien con una problematica similar en un proyecto muy groso para celulares, me recomendo que le de una mirada a
Firebase. Que es Firebase?, a grandes rasgos una solucion "generica" de base de datos
+ backend, con la filosofia del
"no-backend", que seria desarrollar apps distribuidas "sin backend" (bueno, en realidad usaria un servicio como Firebase, ellos cumplirian el rol de "backend") pero el punto es que con eso pude desarrollar el Leaderboard centralizado sin tener que preocuparme por hostear absolutamente nada ni programar algo server side, si quieren conocer mas detalles les recomendaria que se pasen por el sitio de Firebase:
https://www.firebase.com/
Links
