Découvrez Hutch, le meilleur ami de Starxi !

Salut à tous, aujourd’hui je suis ravi de vous présenter Hutch. Cet article fait suite à mes réflexions d’un précédent billet. Je cherchais la prochaine techno pour proposer des jeux mobiles, desktop et web. Starling est génial, mais comme Flash Player est de nouveau mort, son avenir est moins radieux. J’ai utilisé Flambe par le passé, et j’en étais plutôt content, mais aujourd’hui il n’est plus maintenu (même si une mise à jour est annoncée depuis longtemps !).

À la recherche d’un bon moteur 2D multiplateforme J’ai regardé l’intéressante série d’articles de Prime31 qui cherchait le meilleur moteur/plateforme de jeu 2D. Il a finalement choisi MonoGame, mais malheureusement pour moi ça n’exporte pas vers le web. Dans son évaluation, il croise de nombreux frameworks Haxe et LibGDX. N’étant pas très familier avec Java et avec la mort de RoboVM, je n’ai pas considéré LibGDX comme une option. Concernant les librairies Haxe, mon problème reste le même : il n’y a pas assez d’extensions natives (sauf pour Flambe qui cible AIR), et le js minifié avoisine 1 Mo.

D’un autre côté, j’ai adoré travailler avec Pixi.js et Haxe grâce à ces externs extrêmement bien maintenus. Malheureusement, cibler une application mobile avec du HTML5 est un cauchemar. Les performances de Cordova ne sont pas terribles et Cocoon n’est qu’une boîte noire coûteuse…

Alors quelle était la solution ?

Un mix de Starling et de Pixi ! Le meilleur des deux mondes : - Starling : un framework sympa qui fonctionne bien sur mobile et desktop avec toutes les ANE dont j’ai besoin. - Pixi.js : le moteur 2D HTML5 le plus rapide !

NextGenActionScript L’idée est venue en essayant NextGenActionScript. On peut coder en AS3 tout en utilisant Pixi.js, c’est cool ! J’ai donc commencé le framework Hutch en AS3 avec de la compilation conditionnelle, mais rapidement un problème m’est venu à l’esprit : « ok, j’aurai une display list gérant les deux frameworks, mais ce sera compliqué d’utiliser d’autres librairies externes. Par exemple, si j’utilise le moteur physique Box2D, si l’implémentation JS n’est pas la même que l’implémentation AS3, je devrai non seulement créer une API proxy mais aussi gérer les différences ! » Pas question !

Haxe Je suis un grand fan de Haxe et de sa formidable communauté. D’ailleurs, aujourd’hui commence la WWX (super programme, mais malheureusement je ne peux pas y participer cette année), c’est pour ça que cet article sort aujourd’hui. Hutch est loin d’être stable ! Une librairie codée avec le langage Haxe fonctionnera sur toutes les plateformes supportées par Haxe, et croyez-moi, il y en a beaucoup ! Donc sans aucun doute, Haxe est la solution plutôt qu’AS3.

Hutch Hutch est un framework Haxe qui exporte vers le web via WebGL (grâce à Pixi.js), et vers desktop et mobile via AIR (grâce à Starling). Hutch offre une jolie couche d’abstraction puisque (le plus souvent) on n’a pas à se soucier de cibler Pixi ou Starling. Starling & Pixi partagent une architecture proche puisqu’ils s’appuient tous deux sur l’architecture traditionnelle de display list de Flash. Hutch respecte cette architecture. Il est plus proche de celle de Starling car il en est lui-même un portage pour Stage3D, tandis que Pixi a surtout emprunté l’architecture de display list pour aider les développeurs Flash à passer au HTML5.

Objectif Hutch est tout neuf, il reste beaucoup à faire ! À terme, seuls les assets bruts dépendront de la plateforme ciblée. L’objectif est d’avoir exactement le même comportement quelle que soit la plateforme visée. Il ne prétend pas être la prochaine grande révolution, juste un bon framework multiplateforme pour faire des (petits) jeux HTML5 et mobiles.

Mais assez parlé, passons à la démo : démo HTML5. démo Flash.

Vous pouvez cliquer sur l’oiseau. J’ai utilisé la librairie Actuate pour le tweening. Le code de la démo :

package;

import hutch.display.Image;
import hutch.display.MovieClip;
import hutch.display.Sprite;
import hutch.text.TextField;
import hutch.textures.Texture;
import hutch.utils.AssetManager;

import motion.Actuate;

class Game extends Sprite {

	var bunny:Image;

	public function new() {
		super();

		#if starling
			touchable = true;
		#end

		var text = new TextField("Welcome to Hutch :)", "Arial", 24, 0xFF0000);
		addChild(text);

		text.y = 150;

		var assetManager = new AssetManager();
		assetManager.add("bunny.png");
		assetManager.add("starling.png");

		#if starling
			assetManager.add("explosion_starling.png");
			assetManager.add("explosion_starling.xml");
		#elseif pixi
			assetManager.add("explosion_pixi.json");
		#end

		assetManager.load(function() {

			bunny = new Image(assetManager.getTexture("bunny.png"));
			bunny.pivotX = bunny.width / 2;
			bunny.pivotY = bunny.height / 2;

			bunny.y = 50;
			addChild(bunny);

			var bird = new Image(assetManager.getTexture("starling.png"));
			bird.x = bird.y = 300;
			addChild(bird);

			bird.buttonMode = true;
			bird.touchable = true;

			bird.addTouchBeganListener();
			bird.onTouchBegan.add(function() {

				bird.scaleX = bird.scaleY += 0.1;
			});

			var mc = new MovieClip(assetManager.getTextures("explosion_"));
			mc.x = 400;
			addChild(mc);

			mc.play();

			Actuate.tween(bird, 1, {alpha:0.2}).repeat().reflect();

        	Actuate.tween(bunny, 1, {alpha:0.3, x:205});
		});
	}

	public function onUpdate(elapsedTime:Float) {

		if (bunny != null) {
			bunny.rotation += 0.01;
		}
	}
}

Hutch utilise, et abuse même, du pattern Proxy. Le but est de n’avoir presque aucun flag de compilation de votre côté. Je suis persuadé que beaucoup de choses peuvent être améliorées grâce aux macros Haxe, mais je ne les maîtrise pas encore…

Bref, le voyage ne fait que commencer, il reste encore beaucoup à faire. Si vous êtes intéressé, n’hésitez pas à me contacter ! Encore une fois, Hutch est encore assez brut ; pour le moment c’est davantage une preuve de concept qu’un véritable framework, la WWX était une occasion à ne pas manquer pour donner à Haxe le hype qu’il mérite.

Oh et j’espère que vous avez saisi la blague du titre ;)