Phaser.js Hispano, aprende a hacer videojuegos en HTML5

Phaser.js Hispano es un sitio web, de mi propia creación, donde escribo tutoriales para aprender a usar Phaser, una de las librerías más populares para crear juegos 2D con JavaScript.

Phaser

Su éxito se basa en su simplicidad. No trata de reinventar la rueda con conceptos extraños e innovadores. Simplemente hace lo que muchas otras librerías hacen, de un modo claro, sin complicaciones. Fue creado por Richard Davey, alias photonstorm. Comenzó como una librería privada suya, pues él realiza juegos de navegador como trabajo. Con el tiempo fue mejorando, se hizo opensource y ahora cuenta con muchos usuarios aunque gran parte del desarrollo lo sigue realizando Richard. El motor ha sido usado con éxito en infinidad de juegos y a día de hoy me parece la opción más madura y efectiva de realizar un juego HTML5 con JavaScript.

Phaser usa Pixi.js como motor de renderizado, lo que permite a los juegos usar WebGL o Canvas 2D indistintamente. Además si manejas Pixi verás que algunas partes de la API de Phaser son similares. Los juegos funcionan en cualquier dispositivo que soporte HTML5, desde ordenadores de mesa (Windows/Mac/Linux) hasta televisores y consolas (WiiU, Xbox One, Chromecast,…) pasando por los omnipresentes móviles y tablets, que a día de hoy son las plataformas que prefieren los jugadores para jugar a juegos sencillos, de poca profundidad.

¿Estas listo para probar Phaser? He realizado una lista con, al menos, los elementos de los que me gustaría tratar en la web Phaser.js Hispano. La Gran Guía de Phaser en Español, úsalo como índice para tus consultas. Si tienes alguna duda no dudes en expresarla. ¿Quiéres tratar algún tema en particular? ¿Conocías la librería antes?

loading...

La Criptonovela del verano: una historia en tres capítulos (Capítulo 3)

Ya hemos lo que sucedió en el mundo Bitcoin con el tamaño de bloques y también el hard fork en Ethereum causado por la pérdida de fondos en la DAO. Ahora veremos otro robo, con un desenlace totalmente distinto, el caso de Bitfinex.

Capítulo 3: El robo de Bitfinex

Bitfinex es una casa de intercambio, donde la gente puede depositar sus bitcoins y conseguir otra moneda y viceversa. En el caso de Bitfinex el soporte al trading está muy presente.

Bitfinex

El 3 de agosto saltó a noticia, incluso la prensa generalista de hizo eco, había habido un robo en la plataforma. Al poco se aclaró que el problema no era un fallo de seguridad de Bitcoin sino de la propia plataforma de Bitfinex. La cantidad sustraída ascendió a más de 65 millones de dólares al cambio. Ese mismo día la cotización de Bitcoin cayó un 20%. A estas alturas el caso podría recordarnos al de Mt. Gox, pero aquí acaban las similitudes.

CEO de Mt. Gox en los buenos tiempos
CEO de Mt. Gox en los buenos tiempos

Bitfinex bloqueó la plataforma y decidió que quitaría el 36% a todos los que tuviesen depositado dinero en la plataforma. No importa que tuviesen dólares, Litecoins, Ethereum, … les afecta a todos. Bitfinex además tuvo una curiosa idea, compensó a sus usuarios con BFX, una moneda especial. Esta moneda representa el dinero sustraído, con valor nominal de 1$. Es decir, si por la quita del 36% perdiste 500$, Bitfinex te recompensa con 500 BFX.

Ante esta curiosa respuesta quedan dos posibilidades:

  • Cuando Bitfinex logre recuperar el dinero sustraído fruto de su actividad recompre los BFX a valor nominal. Esto implicaría que Bitfinex pagaría con sus bolsillos las pérdidas del robo y los usuarios recuperarían su dinero íntegramente.
  • Intercambiar los BFX por otra moneda, aquí uno puede asumir las pérdidas (pues el BFX siempre valdrá menos que un dólar a nivel de mercado, ya que la devolución no es algo garantizado) o comprar todavía más BFX con la esperanza de que suban.

Nada más salir BFX, su valor experimentó un descenso pronunciado, llegando a caer hasta un valor de 0,3 $.

Sin embargo esta solución no ha gustado a muchos usuarios que plantean emprender acciones legales contra la compañía.

A modo de comparación, si recordáis, con Ethereum ante un robo de una cantidad inferior se llegó al hard fork, sin embargo en este caso tal situación no se ha planteado, pues se considera que el fallo no lo tuvo en ningún caso Bitcoin sino Bitfinex.

¿Te parece correcta la solución de Bitfinex ante el robo?

Este es el último capítulo de la serie La Criptonovela del verano: una historia en 3 capítulos. Podéis dejar en los comentarios si os ha gustado o no y por qué.

La Criptonovela del verano: una historia en tres capítulos (Capítulo 2)

En el capítulo anterior vimos los intentos de tomar el control de Bitcoin por parte de Blockstream y la disputa por el tamaño de bloque con Core, Classic y Unlimited luchando por hacerse un hueco. Veamos la situación en Ethereum.

Capítulo 2: Ethereum y la DAO, o el debate de si el código es la ley

Ethereum es una plataforma basada en la cadena de bloques. Normalmente cuando se habla de cadena de bloques la gente piensa en Bitcoin y piensa que la única aplicación de esta tecnología son las criptodivisas. ¿Pero qué pasa si en vez de dinero transmitimos datos? ¿Y si esos datos tienen un procesado dentro de la propia plataforma? Pues eso es Ethereum, donde pueden funcionar aplicaciones descentralizadas en su máquina virtual, con la verificación entre nodos que nos da la cadena de bloques. Esto son los contratos inteligentes, para más información visita la entrada que escribí sobre Ethereum y Smart Contracts.

El crecimiento de Ethereum ha sido impresionante, hasta tal punto de que la moneda propia de Ethereum, el Ether tiene niveles de capitalización de mercado y volumen que cualquier criptodivisa desearía y que solo Bitcoin es capaz de lograr.

EthereumMarketCap

Los desarrolladores de Ethereum deciden crear el 30 de abril de 2016 una organización autónoma, un organismo regido por el código sin trabajadores y a la vez fondo de inversión para otras empresas y organizaciones basadas en Ethereum que repartía beneficios a sus inversores. Su nombre fue la DAO (siglas de Decentralized Autonomous Organization). Algunas de sus características eran:

  • Funcionamiento sobre la plataforma Ethereum sin jefes ni junta directiva
  • Totalmente autónoma
  • Opensource, programada en Solidity
  • Opera sin la regulación de ninguna nación del mundo

La DAO fue financiada gracias a financiación colectiva (crowdfunding) el 28 de mayo de 2016, con un éxito rotundo. La DAO batió récords y se convirtió en la campaña de crowdfunding más exitosa de la historia, recaudando 160 millones de dólares en monedas de Ethereum, Ether. Superaba así al mayor proyecto hasta la fecha que era el videojuego Star Citizen.

DAO
DAO, en chino, “el camino”

Se calculó que el 14% de todo el Ether minado en Ethereum se encontraba en la DAO. A partir del 28 de mayo las participaciones en la DAO podían ser intercambiadas como si se tratara de una criptodivisa más.

Al poco tiempo llegan los problemas, varias personas revisan el código de la DAO y encuentran vulnerabilidades graves que piden que sean corregidas.

Ya el 17 de junio, un hacker aprovechó una combinación de las vulnerabilidades descubiertas en la DAO previamente para sustraer un tercio de la cantidad depositada en la DAO. Estas vulnerabilidades no se creían explotables hast que el hacker encontró que las mismas se encontraban en otra parte del código y le dejarían replicar la DAO, pero bajo su control. Se intentó parar el ataque mandando SPAM a la red Ethereum. Al poco se lanzó un soft fork en Ethereum que limitaba la la cuenta DAO hija gastar ese dinero hasta que no hubiesen transcurrido 27 días, tiempo en el que se decidiría que hacer. Al cambio la cantidad del robo fue de 50 millones de dólares. El precio del Ether se desplomó. Esto suscitó un gran debate.

¿Era una brecha de seguridad? ¿O simplemente un método legal pero poco ético de cumplir las disposiciones del contrato inteligente? En Ethereum la norma era que el código es la ley, lo que se programa se cumple siempre sin excepción. El hacker cumplió los términos del contrato inteligente. ¿Era fallo del hacker o del desarrollador que escribió el contrato de forma pésima? ¿Se podía considerar un robo? Si recordamos, la DAO no estaba sujeta a ninguna legislación nacional.

La gente se dividió en dos bandos:

  • El primero consideraba que el hacker, aunque de forma poco ética, había cumplido los términos y disposiciones y por ello legalmente le pertenecería ese dinero.
  • Otros que consideraban que esto debía de ser considerado una excepción y que había que encontrar una forma de devolver el dinero a la gente, incumpliendo el mandato de que el código es la ley irrefutable.

DAOButton

Los desarrolladores de Ethereum, que eran también algunos de los grandes inversores de la DAO, prefirieron la segunda opción. Ethereum fue programado para añadir la característica de devolver el dinero sustraído a partir de un determinado bloque que entraría en la cadena a partir del 17 de julio. Obviamente los usuarios del primer grupo sintieron que los principios de Ethereum se estaban viendo traicionados y anunciaron sus intenciones de proseguir su trabajo en Ethereum Classic.

Empresas como Coinbase o Uphold apoyaron a Ethereum y se comprometieron a usar en sus nodos la versión que incluiría la devolución. Al igual que en Bitcoin, en Ethereum tenía que haber un consenso de la fuerza de cómputo suficiente para lograr un hard fork y dividir la cadena en dos. Se produjo el hard fork, en ese momento los nodos que no actualizaron su versión Ethereum pasaron a Classic.

Etc

Ahora ambas plataformas conviven, con cadenas de bloques separadas. En Ethereum Classic prefieren código irreversible, resistente a censuras, con los ideales de que Ethereum es ese ordenador que nunca se apaga y que siempre ejecuta tus contratos. Se calcula que un 22% de los usuarios de Ethereum apoyan las pretensiones de Classic y que lo ocurrido con la DAO sienta un terrible precedente que podría desembocar en censura.

¿Cuál triunfará? Posiblemente ambas cadenas se mantengan, pero una de las dos tendrá que ser la mayoritaria. Ethereum tiene a su favor que la fundación Ethereum va a seguir programando tal y como tenía planeado, con nuevas actualizaciones que podrían beneficiar al ecosistema. Por otra parte el cambio de un algoritmo PoW a un algoritmo PoS que quiere realizar Ethereum podría quitarle las ganas a ciertos mineros. Estos se trasladarían a Classic, aunque aquí la opinión es que sería algo temporal ya que mantener el algoritmo PoW a Classic le podría pasar factura al largo plazo. Classic tiene a su favor su reputación de realmente inmutable, ajena a cualquier situación, una libertad anárquica, algo de lo que Ethereum ya no puede presumir.

¿Cuál es tu opinión al respecto? ¿Cuál fue la decisión correcta, la de Ethereum o la de Ethereum Classic?

En el siguiente capítulo veremos otro robo, en este caso a Bitcoin, a través de Bitfinex.

La Criptonovela del verano: una historia en tres capítulos (Capítulo 1)

Este verano el mundo de las criptodivisas nos ha deleitado con tres culebrones. Cada culebrón nos expone fortalezas y debilidades de estos sistemas y lo que es seguro es que forman parte de su historia, para bien o para mal.

Capítulo 1: Bitcoin y su escalabilidad, tamaño del bloque

Esto es una auténtica guerra. Bandos muy definidos, hostilidad, el debate comenzó hace ya tiempo (abril de 2015, puede que antes) pero sigue sin finalizar. ¿Debería Bitcoin aumentar el tamaño de los bloques? Y más inquietante, ¿cómo debería hacerse?

Guerra

El protocolo actual de Bitcoin permite ejecutar un máximo de 7 transacciones por segundo (3 según otras fuentes). Este número era suficiente cuando Bitcoin surgió y solo lo usaban cuatro gatos pero ahora empieza a haber problemas que se agravarían aún más si se consigue popularizar Bitcoin. Por ello, para aumentar el número de transacciones simultáneas se hace preciso aumentar el tamaño del bloque (actualmente 1 MB) que contiene las transacciones pendientes de verificar.

TamañoDelBloque

El límite en el tamaño de los bloques fue una solución temporal creada por Satoshi Nakamoto hasta que se pudieran usar clientes ligeros, sin embargo nunca se ha modificado.

Esta cuestión no ha contado con el consenso habitual que se lograba para implementar otras características. Hay intereses en ambas direcciones. Gavin Andresen y Mike Hearn publicaron ya a finales de 2015 un fork, denominado Bitcoin XT, que implementaba la proposición BIP 101. Además añadía algunas mejoras de seguridad y usabilidad. El objetivo era lograr que el 11 de enero de 2016, al menos el 75% de los nodos de la red Bitcoin funcionasen con Bitcoin XT. Si lo conseguían, conseguirían imponer sus normas y Bitcoin Core (el Bitcoin original) se bifurcaría (un hard fork). Los mineros de cada red seguirían minando pero ya no funcionarían en la misma red, habría dos.

Gavin Andresen, fue el designado por Satoshi Nakamoto para desarrollar Bitcoin
Gavin Andresen, fue el designado por Satoshi Nakamoto para desarrollar Bitcoin

Sin embargo esto generó mucha crítica en la comunidad. Por una parte tener dos cadenas de bloques podría suponer un peligro de doble gasto y la credibilidad de Bitcoin se vería afectada por haber “dos bitcoines”. Otra crítica tuvo que ver con la privacidad. Bitcoin XT recogía las IP, también de usuarios que usaban Tor. Las críticas llegan al modelo de gobernación de Bitcoin pues en última estancia Bitcoin XT proponía cambiar la manera de tomar decisiones.

Bitcoin XT guardaba las IP de los usuarios rompiendo con la privacidad característica de Bitcoin
Bitcoin XT guardaba las IP de los usuarios rompiendo con la privacidad característica de Bitcoin

Más tarde, Satoshi Nakamoto (o alguien que se hacía pasar por él) afirmaba que él veía la necesidad de cambios en Bitcoin Core, pero que Bitcoin XT le parecía peligroso. Finalmente Bitcoin XT no logró sus objetivos.

En este punto vamos a revisar los motivos que exponen aquellos que no quieren aumentar el tamaño del bloque.

  • Las tarifas de transacción son muy bajas y no subirán hasta que el espacio en el bloque sea escaso. Necesitamos un límite de tamaño por bloque para asegurar la escasez y por lo tanto ponerle un precio a las transacciones.
  • ¿Qué pasaría si el mercado fijase un tamaño de bloque tan grande que sólo Google se pudiera permitir mantener funcionando nodos completos?
  • ¿Y si las tarifas de transacción fijadas por el mercado no pagan lo suficiente como para mantener un poder computacional que proteja a la red de otros adversarios económicamente fuertes?
  • ¿Y si la competencia resulta en que la rentabilidad del minado es tan baja que saca del juego a los pools más pequeños y la minería Bitcoin acaba siendo un monopolio?

Argumentos tomados de ElBitcoin.org

Estos argumentos son muy parecidos entre sí y tienen que ver con la minería. Las objeciones al límite del tamaño del bloque tienen que ver con las recompensas por cómputo. Si el tamaño del bloque aumenta, los mineros van a tener que realizar más trabajo para recibir la recompensa por bloque minado (25 BTC). La otra recompensa, basada en las comisiones por transacción sigue siendo tan baja que sigue siendo preferible minar para conseguir un bloque entero. Los mineros van a preferir bloques pequeños. Además se expone la posibilidad de que los bloques sean tan grandes que Bitcoin acabe centralizándose. Esto último de hecho es algo que ya ocurre. Los grandes nodos chinos copan gran parte del mercado.

Sigamos con la historia. En febrero de 2016 una encuesta a usuarios de Bitcoin revelaba que el 90% de ellos querían aumentar el tamaño del bloque hasta por lo menos 2MB. Entonces aparece Bitcoin Classic. Bitcoin Classic, también diseñado por Gavin Andresen, propone aumentar el tamaño de bloque a 2MB. No realiza ningún cambio más sobre Bitcoin Core. El anuncio de este hard fork fue eliminado de Reddit, lo que hizo pensar a muchos que cierta parte del mundo Bitcoin censuraba a Classic.

Classic obtuvo el apoyo de mucha más gente en mucho menos tiempo. Empresas como Coinbase, Bitcoin.com, Xapo, Blockchain.info,… apoyaron Classic desde el principio, algo que evidenciaba el alejamiento de los desarrolladores de Core con parte de la comunidad. Para que Classic se imponga tiene que cumplirse la misma condición que con Bitcoin XT, 75% de la potencia de la red ha de funcionar usando Classic.

BitcoinClassic

Bitcoin Core no ha sido ajena y ha propuesto sus soft forks, pequeñas modificaciones, más conservadoras, que no eliminan la compatibilidad, proponiendo un modelo de “testigos segregados”, que no aumenta el tamaño del bloque sino que reduce la información de cada transacción de manera que entran más transacciones en un bloque del mismo tamaño. La postura de Core fue apoyada por OneName, GreenAddress,…

Los testigos segregados han sido criticados ya que según parte de la comunidad solo resolverían el problema a corto plazo. Esta solución no obstante parece ser también del agrado de Classic, que añadiría ambas cosas: testigos segregados y aumento del tamaño de bloque. Este aumento primero sería fijo, subiendo a 2MB, posteriormente se trabajaría según la propuesta de Stephen Pair, CEO de BitPay, en un modelo de crecimiento dinámico. Sin embargo BitPay ya se ha adelantado y actualmente están desarrollando un fork de Bitcoin Core según sus propuestas, esta versión es BitPay Core y es experimental.

La cosa se complica más pues tenemos Bitcoin Unlimited. Se trata de un sistema donde cada nodo especificaría el tamaño de bloque que le gustase. Concretamente empezaría en un 1MB y el tamaño podría verse aumentado según el minero. Este proyecto sin embargo no ha atraído la atención suficiente y aunque sigue en activo, no cuenta con un apoyo suficiente.

Blockstream

Ya en 2015 entra en juego también Blockstream, una compañía dedicada a sidechains o cadenas laterales (una cadena lateral es un producto paralelo pero que toma referencia en Bitcoin, similar a las monedas de distintos países con un patrón oro). Aprovechan la potencia de Bitcoin con otros propósitos. Su producto principal es Liquid. Las transacciones en Liquid no son procesadas por los mineros. Para usar la red lateral Liquid es necesario pagar a Blockstream una cuota mensual. Esto no sería ningún problema si no fuera porque muchos desarrolladores de Bitcoin Core están en nómina de Blockstream. Una parte de la comunidad les acusa de querer centralizar Bitcoin y para ello llevarán Bitcoin al colapso, con el tamaño de bloque sin modificar para que la gente use soluciones mejores, en este caso las de Blockstream. Si la gente se queda sin espacio en la cadena pública deberán pasarse a la cadena de Blockstream, que si tendrá espacio para tus transacciones.

Sidechain

La desconfianza en Blockstream creció cuando firmó contratos con mineros chinos para poder sustentar Core y las cadenas laterales derivadas de él, productos de Blockstream. Estos contratos han hecho sospechar a mucha gente, que empezó a demonizar contra ellos. Estos mensajes han sido borrados sistemáticamente de ciertos foros y subreddits que se creen en control de Blockstream. Así pues Blockstream parece querer controlar Bitcoin junto con la opinión pública.

Algunos afirman que Blockstream no durará mucho, que caerá, que Classic triunfará. Otros afirman que el resto de desarrolladores de Core no dejarán que Blockstream se oponga a la modifiación del tamaño de bloque y que Core evolucionará.

Bitcache

Y ahora… Bitcache. El nuevo proyecto de Kim Dotcom (fundador de Megaupload). Todavía no ha visto la luz pero este proyecto cuenta con la aprobación de BankToTheFuture. Se trataría de un sistema que relacionaría archivos con transacciones Bitcoin y parece ser que resolvería los problemas de escalabilidad. Su salida se ha planeado para enero de 2017. Estaré atento.

Y en los siguientes capítulos

  • Ethereum y la DAO
  • El robo de Bitfinex

Suscríbete por correo electrónico para no perderte los dos episodios que vienen.

Programando para Haiku – Barras de menús – Parte III

Seguimos con los tutoriales de Haiku, hoy veremos como crear barras de menú. Partimos del código de la ventana vacía, lo tienes en la foto junto con el comando de compilación.

MiAplicacionHaikuCodigo
Haz click en la imagen para verlo en grande

Debemos saber que en la API de BeOS hay tres clases que nos van a servir.

  • BMenuBar, se trata de la barra en sí, que esta pegada a la ventana. Un BMenuBar contiene BMenus.
  • BMenu, son los menús en sí. Un menú es un elemento que contiene acciones, organizadas como si fuera una lista. Los menús no definen acciones, pero sí su organización. Así, a un BMenu le tendremos que añadir BMenuItems u otro BMenus (menús anidados).
  • BMenuItem, son las acciones de los menús. Cada BMenuItem tiene la capacidad de generar un BMessage nuevo, listo para ser procesado por nuestra aplicación.

En la imagen se puede ver perfectamente

BMenu

Vamos a crear una barra de menú con dos menús, uno de ellos simple y otro con un menú anidado y un separador.

#include <AppKit.h>
#include <InterfaceKit.h>
#include <InterfaceDefs.h>

#define NEW_FILE 3
#define EXPORT_AS 5

class VentanaPrueba : public BWindow{
	public:
		VentanaPrueba() : BWindow(BRect(100,100,900,700),"Mi ventana",B_TITLED_WINDOW,0){
			AddChild(CreateMenuBar());
		}
		bool QuitRequested(){
			be_app_messenger.SendMessage(B_QUIT_REQUESTED);
			return BWindow::QuitRequested();
		}
		void MessageReceived(BMessage* msg){
			switch(msg->what){
				default:
					BWindow::MessageReceived(msg);
			}
		}
		BMenuBar* CreateMenuBar(){
			BMenuBar* bar = new BMenuBar(BRect(0,0,100,20),"MenuBar");
			
			BMenu* file = new BMenu("File");
			BMenu* help = new BMenu("Help");
			BMenu* exportMenu = new BMenu("Export");
			
			bar->AddItem(file);
			bar->AddItem(help);
			
			/* FILE */
			BMenuItem* newFile = new BMenuItem("New file",new BMessage(NEW_FILE));
			newFile->SetShortcut('N',B_COMMAND_KEY);
			file->AddItem(newFile);
			
			file->AddItem(exportMenu);
			file->AddSeparatorItem();
			
			BMenuItem* quit = new BMenuItem("Quit",new BMessage(B_QUIT_REQUESTED));
			quit->SetShortcut('Q',B_COMMAND_KEY);
			file->AddItem(quit);
			
			/* EXPORT */
			BMenuItem* exportAs = new BMenuItem("Export as...",new BMessage(EXPORT_AS));
			exportMenu->AddItem(exportAs);
			
			/* HELP */
			BMenuItem* helpVersion = new BMenuItem("Help",NULL);
			help->AddItem(helpVersion);
			
			return bar;
		}
};

class AplicacionPrueba : public BApplication{
	public:
			VentanaPrueba* ventana;
			AplicacionPrueba() : BApplication("application/x-aplicacion-prueba"){
				ventana = new VentanaPrueba();
				ventana->Show();	
			}
};

int main(int argc, char** argv){
	AplicacionPrueba app;
	return app.Run();
}

Y el resultado es el siguiente:

BMenuBar

Como vemos, SetShortcut hace que los menús sean seleccionables con combinaciones de teclado. Hay que tener en cuenta que en BeOS, la tecla que en Windows normalmente Ctrl, es Alt. Así operaciones como copiar y pegar con Alt+C y Alt+V. Para responder al evento solo hace falta escuchar en la función MessageReceived. En el caso de B_QUIT_REQUESTED, el mensaje ya está implementado en la función QuitRequested.