next »

[Triplefox]

This is a thread for those of you interested in using haXe for game development. I've been using it since mid-2007. Briefly, what haXe has to offer, the downsides and missing features, and resources to learn. I'll focus mainly on Flash since I know that a lot of people here are going to be comparing haXe against Flex for Flash development.

Brief history
HaXe is a product of Motion-Twin, a French company which is responsible for insipidly popular browser games MyMiniCity and MyBrute. It emerged from the efforts of language designer Nicolas Cannasse to develop a language that could be reused over the entirity of a webapp, and since then it has progressively expanded from its original goals. JS, Neko, and Flash were the original targets of haXe, as these three targets can form a complete web stack - Neko can serve pages and run batch scripts, while JS and Flash provide the end-user experience.

Today, Neko's role has expanded to include most desktop code, and two new targets are officially supported, C++ and PHP. The C++ target produces GCC-compatible source using Neko-equivalent bindings; performance improvements are quite good. The PHP target feels similar to Neko's server code, which makes it very un-PHP-like. There have been proposals and work towards more and more targets lately, and it is likely that we will see haXe on Java and .Net in the next year or so.

Feature List

• Multi-platform compilation and data exchange. As of this date(July 27 '09) the platforms officially offered are Javascript, NekoVM, C++, PHP, Flash 6-8, and Flash 9-10. Using the haXe-native serialization you can reliably pass data back and forth between any target; additionally, a remoting API is available for networked applications, so you can do not only data exchange, but method calls between different platforms.
• ECMAscript style syntax. You won't have too much trouble going from C/C++/JS/AS to haXe.
• Class-based OO, prototypes, reflection, closures, functional programming features.
• Built in data structures: Hashes of strings and integers, arrays, lists. More available in libraries.
• A brilliant and surprisingly clean type system that combines elements of strong-static-implicit systems with dynamic ones. You can write the bulk of your code implicitly with a sprinkling of type signatures where necessary, and in the few areas where dynamism is needed, it's easy to access. For me, this is the #1 time saver and the biggest reason to switch away from other languages.
• Fast compiler written in O'Caml. For those of you working in Flash, it's much faster than the Adobe compiler, and gives better errors most of the time.
• Built-in package manager, haxelib.
• Supported by the Flashdevelop IDE.
• HaXe is an optimizing compiler, but more importantly, it now offers two major features for hand-optimization that go beyond AS3: inline definitions, and a Memory API that uses the opcodes made for Adobe Alchemy. Benchmarks consistently show that haXe Flash performance is the equal or better of the AS3 equivalents.

What's missing, or things you might gripe about:

• Compatibility with AS3 APIs is not as easy as in AS3 itself. This has improved greatly and multiple options are available both to access AS3 code, or to compile haXe code to be accessable from AS3. If working with the standard toolchain is essential(and if you're doing contracting work or working with a lot of external code it might) then haXe will be quite a bit harder to use than Flex.
• Importing data into SWFs is still a pain because it depends on swfmill, which has been without a regular maintainer for about two years, resulting in tons of people using unsupported builds. There are hopeful signs that this will change as maintainership officially changed hands in the last month. DON'T DOWNLOAD THE OFFICIAL RELEASE, IT'S ANCIENT AND IS MISSING FEATURES. If you want a recent Windows build of swfmill, for now, go to this page. For other platforms, you will probably have to get the source code off of SVN and compile it yourself.
  
  Fortunately, once you have a working build, the rest isn't so bad. swfmill uses a fairly simple XML format, and it can do pretty much everything you want for game-making purposes: importing bitmap and SVG assets, sounds, fonts, binary data. The last piece of the puzzle is preloaders, and Flash 9 preloaders have been particularly hard to get working from haXe. Fortunately, several preloader techniques have been implemented; they work, but are pretty hackish, so I encourage you to look on Google if you *really* want to implement a preloader. At the moment the most convenient method available is to upload the raw SWF to MochiAds and use their version control system, which automatically attaches a preloader with ads.
• Libraries are still thin. Documentation is also thin. For Flash, library support doesn't matter as much because your I/O options are hugely constrained by what Flash provides.
• Multiplatformness has the downside of causing certain limitations; behavior may change slightly between platforms because of differences in the VM's type system, the compiler isn't self-hosting or able to compile new code at runtime(but an "hscript" library exists that compiles a subset), and library bindings are dependent on the underlying platform. Does it matter? Depends on what you're doing!
• If coming from a wholly-dynamic type system like Python, you may find the type system a bit annoying to get used to at first because the implicit typing is based on first use, so certain things you could get away with in a dynamic environment(mainly to do with initializing variables or arguments to function calls) will confuse the compiler and require type signatures.
• One of the conventions of haXe is that all code is part of a package and a class. In practice this doesn't actually pose many limitations on code structure - it even helps organization in most cases - but the boilerplate makes small projects less breezy than, say, Python.

Learning resources
If you're new to programming, I have a hard time recommending haXe because it doesn't have enough documentation and hand-holding tutorials yet. But if you've already done projects in other languages and you're at least a bit familiar with class-based OO, the transition won't be too bad. If you want to use Flash and haven't before, there will be an additional struggle because of all the nuances of the Flash API, but the haXe wiki already documents a lot of the toughest concepts, and the remainder can be gleaned from Adobe's docs.

• Professional haXe and Neko book. It's already become outdated, but it is the only published book available, and the single most comprehensive guide.
• haXe language reference. This is the primary document I used to get started years ago. It is written in an informal style and demonstrates most of the big concepts by example. This is one you can "play" with.
• Flash getting started guide. This was one of the other documents I got started with. It's a simple tutorial and doesn't really go into much detail about Flash's nuances.
• A newer Flash tutorial. Covers swfmill in more detail.
• Flash Security.You should read this so that you can learn all about how Adobe makes stupid decisions. More seriously, if you're doing anything with either the network or local file system you should read this or you will get mysterious failures for no obvious reason.
• Haxelib reference.
• haXe wiki. This is a great resource and over the time I've been using haXe has grown to contain most of the "gotchas" and FAQs, but it's in need of basic usability improvements. We get tons of threads on the list or forums that have answers buried somewhere in the wiki where the submitter just wasn't able to find it.
• haXe compiler list. This is currently the central place for discussion. Most questions will be promptly answered by a long-time user or Nicholas Cannasse himself. Also, most major topics have been discussed at least once in the past, so try searching the archives!
• haXe official forum. This forum is a new development. I haven't really looked at it, but it seems to be getting a decent amount of traffic.

[Hima]

Funny I was just trying out Haxe yesterday! This is just what I need Thanks!

[John Nesky]

So far I've been in the "Isn't haXe just fracturing the Flash developer community?" side of the fence. I'll probably continue to use AS3 for various reasons, but this post was enlightening. (and I'm a huge fan of open source software in general)

[jotapeh]

Felt the need to bump this, my apologies..

It's been two years since this was posted but recently I've seen (a little) buzz about haXe. How does haXe now compare to haXe then?

Personally I'm consistently intrigued by haXe, but I can't bring myself to try it since it seems the community for it is tiny.

[Richard Kain]

I'm using HaXe for my personal project at the moment. I'm in the process of creating a basic game framework using HaXe. At the moment I have resource loading and pre-loading running for the Flash and C++ targets. I still need to do testing in the iPhone simulator. Basic scene management is next on my list, with basic camera control after that. So far everything seems to be going well.

[Triplefox]

Two years, I can't believe it.

I'm still doing well over here. The worst issues in Flash have been paved over now - all the asset stuff can be solved with appropriate use of SamHaXe, and I made a Python script/project template to simplify its use for typical games/media apps. Sometimes APIs lag behind a little bit, sometimes they're a little ahead, but I think we're up to date right now - there are some Molehill demos floating around. So on that platform it's mostly a matter of finding the docs and adjusting to the workflow.

Java and C# are still "in progress." (ha ha) But C++/neko have shaped up and there are some iPhone projects using those targets. JS remains about the same - it worked fine, still does(but will always be a bit bulkier than raw JS). Don't know about PHP.

[Hima]

I didn't do much with it , mainly because the frustration in the learning process as well as not wanting to create a framework. So I went with flixel instead if my memoty serve. It's still bug me though since I still want to understand it. 

[Richard Kain]

Enough with the talking. This is a tutorial thread, let's get with the tutorializing!

Here's how to set up a basic Haxe program that targets the Flash Player and C++...

buildFlash.hxml

Code:

-swf9 cpp/HaxeTrial.swf
-main HaxeTrial
-swf-version 10
-swf-header 480:320:60:F0F0F0

This is the code for a file called "buildFlash.hxml" HXML files are what you feed the Haxe compiler to customize your build, as well as specify your base class. The first line here tells the compiler what target I'm going to be compiling to, where I want the created file placed, and what I want it called. The second line specifies the name of the class where the main function is found. (that is to say, the base class) The third line specifies that I'm targeting the Flash Player version 10. The last line incorporates some basic flash header tags. In this case, it tells the compiler that I want the generated flash file to have a default resolution of 480x320, I want it to run at 60 fps, and I want the background color to be "F0F0F0." (a very light grey)

Of course, before I can actually use the HXML file I first need to create the Haxe source file that it is pointing to...

HaxeTrial.hx

Code:

package ;

import flash.display.Sprite;

#if flash9
	import flash.Lib;
#elseif cpp
	import nme.Lib;
#end

class HaxeTrial extends Sprite
{
	public function new()
	{
		super();
		Lib.current.addChild(this);
	}
	
	public static function main()
	{
		var gameWidth:Int = 480;
		var gameHeight:Int = 320;
		var gameTitle:String = "Haxe Trial";
		
		#if flash9
			new HaxeTrial();
		#elseif cpp
			Lib.create(function() { new HaxeTrial(); }, gameWidth, gameHeight, 60, 0xFFF0F0F0, (1 * Lib.HARDWARE | Lib.BORDERLESS | Lib.VSYNC), gameTitle);
		#end
	}
}

This is a very basic Haxe program designed to work with the Flash target. At the top you'll notice the "package" reference. Packages are the standard way of organizing your source files in AS3, and they work similarly in Haxe. In this case, the HaxeTrial.hx file is in the root of my project folder, so no extra package declaration is necessary. Since this is targeting Flash, I'm making this class extend the Sprite class. (standard practice for root classes in Flash)

The new function is the constructor for the class. In traditional AS3, the constructor for a class is named the same as the class. In Haxe, all constructors are "new". Since this class extends an existing class, I have to call the "super();" function from within the new function. In AS3 this is optional, in Haxe it is required. The "Lib.current.addChild(this);" is how you add the HaxeTrial class to the flash display list. If you don't call that line, nothing you draw within your root Sprite class will show up.

The static main function is what really makes this the root class of the program. If the compiler didn't see this function in the class it had been told was the main class it would have thrown an error. Sub classes don't need to have static main functions, only your root class requires it. This is a good time to discuss target conditionals.

You'll note the "#if", "#elseif" and "#end" statements. None of these are AS3, they are target conditionals that are specific to Haxe. They let you separate out code that should only be compiled for specific platforms. In this case, we are passing in the flash9 and cpp platforms as conditions. If you are going to use one of these, you always have to remember to include an #end statement when you are finished.

For the static main function, we need to handle the statements differently for the Flash target and the CPP target. The Flash target is simple, we just create an instance of the class. For CPP we have to use the Lib.create() function, and we have to feed it a number of variables to specify how we want the CPP application to be built. These are analogous to the flash header variables that specified the size and background color of the window.

Once you have all this, you would type the following command into the command line. (or terminal, depending on platform)

Code:

haxe buildFlash.hxml

For constructing the C++ version, you would first have to create an HXML file specific to it.

buildCPP.hxml

Code:

-main HaxeTrial
-lib nme
-lib hxcpp
--remap flash:nme
--remap neko:cpp
-cpp cpp
-cp src

This is similar to the Flash file, but with a few remapping-calls and library includes.

[Richard Kain]

The worst issues in Flash have been paved over now - all the asset stuff can be solved with appropriate use of SamHaXe, and I made a Python script/project template to simplify its use for typical games/media apps.

Using SamHaXe and SWFMill are solutions for asset loading. Personally, I prefer the more direct approach to getting resources into my HaXe programs. Here's an example of a image-loading class that I wrote...

Code: (HaxeImage.hx)

package ;

#if flash9
	import flash.Lib;
#elseif cpp
	import nme.Lib;
#end

import flash.display.Loader;
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.net.URLRequest;
import flash.events.Event;

class HaxeImage extends Bitmap
{
	private var picturePath:String;
	
	public function new(sourcePath:String) 
	{
		picturePath = sourcePath;
		#if flash9
			super();
			var picRequest:URLRequest = new URLRequest(picturePath);
			var picLoader:Loader = new Loader();
			picLoader.contentLoaderInfo.addEventListener(Event.INIT, picLoadFinished);
			picLoader.load(picRequest);
		#elseif cpp
			super(BitmapData.load(picturePath));
		#end
	}
	
	#if flash9
		private function picLoadFinished(picEvent:Event):Void
		{
			this.bitmapData = cast(picEvent.target.content, Bitmap).bitmapData;
		}
	#end
}

This is a bare-bones class for abstracting the resource loading differences between the Flash and C++ targets. This class will load in images that are external to the compiled SWF or EXE files. You can use it within another class in this fashion...

Code:

var freshPicture:HaxeImage = new HaxeImage("yourImage.png");
addChild(freshPicture);

[jotapeh]

Thanks for that, Richard. Without that I wouldn't have rolled up my sleeves and started wading into haXe.

So far I'm not sure I'd have a use for it over regular AS3, but it's certainly intriguing.

[Player 3]

I heard HaXe has C++ exporting. Does that mean there needs to be manual optimization like expected?

[Richard Kain]

I heard HaXe has C++ exporting. Does that mean there needs to be manual optimization like expected?

You occasionally need to use target-specific code. There are instances of this in the examples posted above. But generally speaking, you don't have to do any actual C++ coding or optimization. The abstraction layer that the compiler provides handles conversion of HaXe to C++.

That said, the compiler actually creates the C++ code before it compiles it. So if you really felt like it, you can go back inside the C++ code to make whatever changes you wanted to, and re-compile it from there.

[Richard Kain]

Last weekend, I was able to get some testing done on my Mac Mini. Specifically, I tested HaXe and some of the HaXe classes that I had built with the iPhone emulator. I ran into some issues, and I had to go back and change up some of my code to cover them.

For anyone interested in iOS development, here's a revised version of the HaxeImage class that I posted above. This new version has been optimized slightly and has the conditionals necessary to work properly on iOS.

Code:

package ;

#if flash9
	import flash.display.Loader;
	import flash.net.URLRequest;
	import flash.events.Event;
#end

import flash.display.Bitmap;
import flash.display.BitmapData;

class HaxeImage extends Bitmap
{
	private var picturePath:String;
	
	public function new(sourcePath:String) 
	{
		
		#if flash9
			super();
			picturePath = sourcePath;
			var picRequest:URLRequest = new URLRequest(picturePath);
			var picLoader:Loader = new Loader();
			picLoader.contentLoaderInfo.addEventListener(Event.INIT, picLoadFinished);
			picLoader.load(picRequest);
			
		#elseif cpp
			picturePath = sourcePath;
			super(BitmapData.load(picturePath));
		#elseif iphone
			picturePath = sourcePath;
			var pathProcess:Array<String> = picturePath.split("/");
			picturePath = pathProcess[cast(pathProcess.length - 1, Int)];
			super(BitmapData.load(picturePath));
		#end
	}
	
	#if flash9
		private function picLoadFinished(picEvent:Event):Void
		{
			this.bitmapData = cast(picEvent.target.content, Bitmap).bitmapData;
		}
	#end
}

When you compile a project for the iOS, any and all folders and subfolder structures get ignored. So providing a path to a graphical image asset would work on any other platform, but wouldn't mean jack to the iOS. I added some quick parsing code here to remove everything except the file reference from the path that you feed into the class. Using this method it is possible to compile the code identically on the iOS as you would on any other platform.

[randomnine]

I've been using HaXe for Flash games for a few months now. I've never used straight AS3 - I just saw "HaXe is faster" and went for it instead. I'm a C++ programmer

I didn't realise it can target iPhone. Pretty cool. Don't Apple have a thing against cross-compiled code though?

Only real problem I've had on the Flash side was setting up a preloader. HaXe's SWF linker appears to have changed in a recent version, making lots of the old methods of setting up a preloader fail - I tried a few of them - so I worked through it and put up a tutorial myself. Hope it's helpful.

[Hima]

All of these legal semantics and AIR runtime installations are exactly why I chose to go the Haxe route instead.

Everyone keeps saying that, but there's no haXe display api for C++, and if there was it wouldn't be compatible with the flash one anyway. So unless I'm mistaken, creating a game in haXe to work around runtime issues is basically akin to saying "rewrite it completely in a different language".

This is incorrect. Look up the NME project(Neko Media Engine). It's an SDL wrapper plus a Flash compatibility layer, and it's been built, off-and-on, since 2008.

http://haxe.org/doc/start/cpp
http://code.google.com/p/nekonme/
http://gamehaxe.com/

While it's quite likely to forever have imperfect Flash compatibility, it's a viable starting place for Flash-to-C++ ports, and it's gradually becoming more proven.

The obvious next step, of course, is to write a Molehill/GL compatibility layer. Then you REALLY won't care what you're running on, graphics-wise.

Found this in the other thread and I think it's quite useful since it clarify some of the myth or belief about Haxe, as well as providing somewhere to start with NME, so might as well put it here.

[Triplefox]

I should advertise the build script I use for SWF projects here:

http://lib.haxe.org/p/sambuild

It's written in Python and uses SamHaXe; it will give you "easier" embedding and preloader capabilities.