Before I start talking about my first “HTML5” experience, let me say something: after 15 years of c++ game development today I make games at the company where I work and I experiment at home using ActionScript 3, C# (Unity) and Haxe.
Do I miss the C++ times? Not really, actually what I love about the aforementioned languages is that they allow me to focus on code design instead of lower level problems and you know what? I turned out to be a code design freak.
In fact I love following the SOLID principles, recognize patterns in my code, develop frameworks, solve issues related to modularity, encapsulation, uncoupling, communication, dependency injection and such; all stuff that can be properly managed with concepts introduced with such high level languages.
I also currently do not care much about learning how CSS 3 and the HTML DOM work. So consider this article a solution to be able to work in HTML5 without be forced to know the technology behind it.
While I have the intention to test them in the future, this article focuses only on the experiment I made with Haxe.
how Haxe code looks like:
class Explosion extends Bitmap
public function new(worldPos:Vector2D)
_stripe = nme.Assets.getBitmapData ("assets/images/explosion.png");
bitmapData = new BitmapData(48, 48);
bitmapData.copyPixels(_stripe, new Rectangle(0, 0, 48, 48), new Point(0, 0));
_worldPos = worldPos;
x = mod(_worldPos.x - (Camera.bound.x)) - 24;
y = mod(_worldPos.y - (Camera.bound.y)) - 24;
this.addEventListener(Event.ENTER_FRAME, onEnterFrame); //I was lazy and I did this ,but it should be avoided to improve the performance
_lastTime = flash.Lib.getTimer();
_index = 0;
However the real question could be: is Haxe good enough to be used for a professional project? Well this question is harder to answer and I searched for the answer developing a simple project.
Haxe is the fruit of Nicolas Cannasse’s mind, who must be a sort of genius. I say this because I do not see how otherwise he can successfully manage so many projects! Surely he is helped by another bunch of guys, but not many.
So can such a project have enough support to guarantee a smooth professional development? Well, one consequence of the fact that Nicolas cannot control time is that the documentation is not very detailed. Although it is good enough to understand most of the language paradigms, sometime it is frustrating to find information even if the Haxe group is full of users willing to help.
I must add that there are also several libraries developed by third party authors already available, but most of them are not really multiplatform, so they must be chosen carefully.
The nice thing is that the most supported and useful libraries can be easily installed using the command line Haxelib that makes everything very straightforward.
Enough talk, let’s get started:
First you need an IDE. Although a good number of IDEs support Haxe, my favourite currently is Flashdevelop, also because I do not know the other ones. Nevertheless it is a great IDE, light and fast. Grab it and install it and remember that it works only on windows. If you use linux or mac-os, a free alternative seems coming soon based on monodevelop.
Now it is the time to install Haxe and its libraries, however I suggest to use the NME installer in place of the Haxe one, I will explain you why in a bit. It is available here (leave everything ticked when you install it).
Keep in mind that this article is based on my development experience on windows 7 platform and it assumes that the reader knows already Flash framework, if not it will probably be not enough to start developing with Haxe.
Once installed, you pretty much have everything needed to start. All the Haxe files and libs will be under the folder c:Motion-Twin
Let me now introduce NME. Haxe on its own includes the language, the compiler and a framework. Some subsets of this framework are platform dependent. Haxe can target many platforms and it is possible to find specific classes for c++, Flash, js, neko and php as you can see here: http://Haxe.org/api.
However only Flash and js related libraries are able to render graphic on the screen. They do it in two complete different ways.
The former using an approach identical to the original Flash, that means using the display list structure, the latter using the HTML DOM. HaxeJS focuses on the second approach. Talking about HaxeJS is beyond the purposes of this article, but I say I would personally use it in place of JS even to create simple projects/web pages.
NME is a multiplatform graphical library written in Haxe and created by Hugh Sanderson, Joshua Granick (please follow his blog) and Niel Drummond (Jeash creator). It is an almost total Haxe porting of Flash framework and it just works with all the Haxe targets available! Using NME makes a multiplatform game development a piece of cake.
Let’s now setup our first HaxeNME project.
From the FlashDevelop IDE choose Project->New Project and then Haxe -> NME Project. FD will create the project folder structure for us together with the application.nmml file.
NMML file is an xml file which describes parameters and dependencies of our project. It is pretty simple to understand, but more explanations can be found here. Just remember that this file gives the directives to the compiler, so, for example, every time a new library is used, it must be added in this file.
If you want to test an already made project, you can download the experiment I made. Of course it is a shoot’em’up (what else? 🙂 ) and it is nothing special too, but enough to test the performances and let me understand how good the HaxeNME development flow can be. By the way, if you play it, remind that it is not needed to click to shoot, the ship shoots automatically while it decelerates.
the demo can be downloaded, together with the code repository, including the haxe project, at https://bitbucket.org/sebas77/Haxe-demo.
This means that every time a problem is found, HaxeNME gives us the option to debug the Flash version, which most of the time is enough to find easily and conveniently the problem.
Where there is written “Test Project”, click on the Edit button and in place of “flash” write “html5” (or the other way around if you started with my project so you can test the flash version).
The current version of Jeash (0.8.7) has some bugs that I helped to catch. So if you want to see my demo running properly, please download the latest trunk from this page: https://github.com/grumpytoad/jeash and copy the code in the folder c:Motion-Twinhaxelibjeash,8,7. The author pretty much updates the trunk almost everyday and most of the time he fixed the bugs before I could even had the chance to report them. So I think that Niel is doing a great job.
Once started coding, it is possible to notice some details that could make one confused. The first I noticed is that the intellisense shows you up to three options for each Flash class one wants to import.
In fact, if for example we type import Sprite we can see the following options available: flash.display.Sprite, nme.display.Sprite and jeash.display.Sprite.
Theoretically the NME one should be used because it is the multiplatform version of the Flash library porting. However I chose the Flash version to help the FD intellisense and it should work as well.
If instead you have troubles compiling, you could add the following line to the compiler options: –remap Flash:jeash -lib jeash
In any case, I suggest to add the folder c:Motion-TwinHaxelib to the FD Global classpath so that the intellisense can properly work in every occasion (and so you can use NME package if you wish).
It is important to notice that there is difference between the Debug and Release version of the output even targeting html5. In debug mode a sort of stack structure is added to trace the functions stack and so the code generated is bigger and slower.
Another important aspect about HaxeNME development is how simple managing asset can be, in fact there are several options available. The one I chose is to import my png files using the nme.Assets.getBitmapData function and the NMML tag.
Thetag allows to choose the folders where the assets are located and tell the compiler to embed them. The getBitmapData will be able to return the BitmapData from the embedded image. To be honest I did not understand how the images are embedded in the html5 version yet, for me it is just important that it works.
HaxeNME even supports SWF assets (no bytecode) for most of the platforms (no html5 yet 🙁 ) as well as asynchronous loading (no embedding).
So now that the game runs both as Flash and as html5 project, I want to share my final impressions:
As already said, every time I found a bug I needed to debug, I just switched to the flash version so that I could easily use breakpoints, stack, local and watch variables. It is true that Google chrome has a pretty good debugger and the code generated by Haxe is quite readable as well, so if one wants to make some experience with Google Chrome debugger, it could be used as well, but flash develop is surely faster and easier to use.
Although Jeash library did not reach version 1.0 and some NME features are not implemented yet, I had everything I needed to create my demo, so I have nothing to complain about it.
Using the amazing Google Chrome profile it is simple to see that the graphical rendering is the biggest bottleneck even if the rotation is disabled, so more attention should be put on it.
Another consideration to make is that the display list is not the best structure to be used in an HTML5 context in my opinion, but Jeash (like the flash framework) allows us to get rid of it. In fact we could simulate the old school bitmap blitting, without any hierarchical structure, using the Bitmapdata blitting operations.
The resulting file dimension is another point to be considered. My simple demo already generates a js script file bigger than 400 kb. However this big dimension is due to the fact that the entire NME project is injected in the js file, so the overhead size is not dependent by the size of the haxe project itself. Personally, if I have to develop a game, I would not probably care about this size, although very likely I would use an obfuscator which could save some kilobytes.
Last thing I want to talk about is the difference of performance between browsers and mobile/desktop versions.
First it must be taken in consideration that soon all the browsers will support hardware accelerated canvas rendering, although IE will be the last one to support it with the new version 10 (available only on windows 8).
My demo runs quite well under Opera, Chrome and Safari, while I had some troubles with firefox, maybe due to drivers incompatibility. Internet explorer 9, while is able to run it, does not perform well in terms of frame rate. In every case it is important to highlight how haxe and jeash are able to guarantee an exceptional inter browser compatibility, since all the demo features are working on all the browsers.
Quite disappointing is the performance on mobile. Apple, which pushes so much html5, did a great job optimizing safari for iOS (the iOS 5 version runs up to 8x faster than the iOS 4 version), but iPhone 4 is not able to render the game at more than 30 fps.
So, is Haxe ready to be used to develop web social/casual game in HTML5? If the performance is not a critical issue for the game, in my opinion yes. Haxe can be used successfully to develop web based social/casual game in HTML5. Would I develop HTML5 games? Even if this question is not related to the article purposes, I would say no, I do not see the reason to do it unless, maybe, I want a web experience to be completely uniform across all the platforms, but this, because of performance issues, cannot happen today.
If you are interested in an alternative I talked about Jangaroo on this post: http://blog.sebaslab.com/develop-html5-games-without-js-and-dom-for-flash-developers-part-2-jangaroo/