OpenFL & Haxe, A Bumpy Start

Hey there, I'm Talha Kaya, one half of Kayabros. I've been making games since I was 12.

Last week I kept myself busy setting up an environment to develop Haxe/OpenFL games with. I'm a Windows user and I was already a user of FlashDevelop. When I learned I can develop with the same IDE, I chose FlashDevelop. As I've heard, IntelliJ has a good amount of fans and supporters. But I'm just happy using FlashDevelop for every flash related thing. I never even used FlashBuilder, which syncs great with Flash Professional. Anyways, FlashDevelop is great, and free.

I'm writing this to record my experience so far with OpenFL. Hopefully someone will get something out of it. Note that I'm a beginner and not a reliable source for OpenFL. But if you faced the same problems I had, there is a potential solution for you here. Talking about reliable sources, here are some:

The most reliable source for Haxe + OpenFL is (although not always up to date) the OpenFL documentation at the moment. You should actually really do the installation through this site, because as of now, the Haxe version that's used with OpenFL is not the latest Haxe version, which you might go on to Haxe's site and get the version that won't be working perfectly with OpenFL. So install Haxe and OpenFL only and only through this guide over here, thank you.

That's not what I did though, isn't it? I googled a random guide, which made me download the haxe through command line (windows button + R, then type cmd.exe and press enter); which ended up being the wrong version. But that was only one problem. Here's the process I went through:

I found a guide for installing OpenFL which I won't link you to, because I want you to use a more reliable source like I mentioned above. I started doing things through command line. I really didn't think I would install something through command line. But I did. It was weird but fluent. The Haxelib program that is working through direct commands is actually surprisingly good :) But of course I would prefer a regular installer with proper UI.

So after I was done, I could build a sample project of HaxeFlixel, which was so cool. As you might know, I have great memories with Flixel with Flash. I made two games with Flixel that were the only games I made money with. Anyways, so I was happy that I could build to Flash. I compiled a blank swf through haxe by creating a file named "compile.hxml" which went like this:

-swf test.swf
-main Test

The directory looked like this:

And when I double-clicked compile.hxml, it worked just fine. test.swf was created in the same directory.

At this point I'm thinking, "C'mon I want my proper IDE and all the tasty creamy fast food that comes with it back, what am I doing?" But they said I could still use FlashDevelop. Let's try FlashDevelop. Hey I thought there was an option for an OpenFL project on FlashDevelop? Why isn't it there? Let's google that. What? It only exists in development builds of FlashDevelop?

OK you know that you should be checking the date of the page you just googled before you actually trust it, right? And this particular page that I was looking at was from July 2013. That's like a hundred years ago in Haxe history. So when I checked the newest stable build of FlashDevelop, I saw OpenFL was indeed supported. Cool, let's update my favorite IDE.

Now I created an OpenFL project on FlashDevelop. It builds a blank SWF perfectly! Never been happier to see a blank SWF! Cool, will I be able to compile a Windows build right away? That'd be nice.

Yes, that'd be nice. That's not gonna happen. Instead I've got some errors like these, 6 to be exact:

My setup experience with OpenFL was god awful. I couldn't get anything to work, and couldn't find the solutions I needed by googling. I really needed some help.

And that help came from Joshua Granick, who goes by the nick of singmajesty. I should note that I used twitter to record most of my experience. So as I was setting up stuff, I was tweeting about it. And when I got stuck, I tweeted about that too. Apperantly singmajesty was searching tweets about OpenFL to offer help to people. What I'm getting at is, twitter is useful for game devs, you guys.

So who's this random guy? Oh, he is the founder of OpenFL. Holy cow. I'm starting using a technology and the founder of that technology comes from nowhere to help? That's awesome.

So apparently my problem was the version of Haxe I was using, as I mentioned in the installation part. So we fixed that, and I was a happy man now. I could get flash and windows builds from Haxe code, which looked a lot like ActionScript3, so I felt like this was it, and I could just make any game I want with Haxe with cross-platform support. I knew that there would be lots of minor problems, maybe performance issues. But not major ones, right? No. Wrong.

It happened after I decided to port a simple AS3 project of mine, something like a fractal based interactive tunnel animation.

The project didn't use any assets, so I thought it would be almost as easy as copying and pasting AS3 code to Haxe. I was naive. Some people told me that Haxe = AS3 syntacticly, which is not correct. Here's a guide for the syntactic differences between the two. Note the for loop syntax. That's so dumb! For complex for loops in Haxe, I'm just using while loops. Becuz dat syntax.

Here's another useful guide for some of the errors you might face when you're getting into Haxe.

So, as I was porting my game, I bumped into a curious error, that I didn't know was going to be a nightmare to deal with.

Dictionary? I don't need a dictionary right now, thanks. I'll handle this error when I actually need a dictionary. C'mon, no?.. Okay...

After some tries with some sample projects, I was able to build to Windows, but I could not build to Flash. This was a good sign that cross-platform won't be easy as if OpenFL was Unity. I worked on this error for hours, but couldn't find or come up with anything. Joshua was still helping though. He saw that I was really stuck, and it was not possible to help without actually seeing the code. So he did it. My first stupid ported code from AS3 to Haxe was checked out by the founder of OpenFL. Weird.

The problem was the casting I used. I did obey the rules of AS3 - Haxe syntax differences guide I linked earlier, only to end up using the cast function which gave me errors. Ugh. I changed the cast function to Std.Int's. It compiled very nicely with Neko. The Windows build also got compiled nicely. But it still gave the same error on Flash target.

Where the hell was this damn Dictionary?

OK, at some point, you have to look if this Dictionary guy actually exists, right? Because maybe it actually doesn't exist? I mean, what if? What if the compiler is not lying? What if there was no cake, sorry dictionary? What then? Joshua told me to check out what was there in C:\HaxeToolkit\haxe\std\flash\utils\

Not much I would say. Definitely not Dictionary.hx. Compiler was not lying. It should have looked like this:

So it should be on Linux? No no, just look at the files inside the directory, dummy.

So how to fix this nasty problem? Just reinstall it, maybe? Yeah yeah, do that. So I reinstalled Haxe's same version through auto-installer. It was fixed. What was that? How the hell did that happen? Who actually deleted the poor Dictionary.hx guy? What was going on? Funky business, I would say. But everything was fine now.

I could build to Windows and Flash and also use Neko if I wanted to. The performance of Neko blew my mind. I was playing the game with nearly 280FPS. Crazy! The performance of OpenFL Windows build? I've got bad news over there. It was terrible. Absolute garbage. I asked Joshua why that was. This engine allowed a game like Papers, Please, it should handle some basic fractal-like shapes, right? Too much Array modification might have been the problem. I would be very dissappointed if it was that. But it wasn't. The problem was the flash drawing API on OpenFL native C++ targets was working very poorly. That will hopefully be fixed in the future, as Joshua told me.

The working environment was finally completed. I will need Android in the future, but I don't want to get in that right now. I just want to make games...

So I started working on my first Haxe game. A one week project that would help me recover my creativity, hopefully. I didn't got into serious problems as of yet, but one is worth mentioning, and that is the embedding of fonts.

So, don't take it lightly when I say trust the OpenFL sample projects. You can create one of the OpenFL sample projects through command line like this:

lime create openfl:AddingText
cd AddingText
lime test flash

When embedding text in a Haxe project, you should be using the same code used in the sample project, that goes like this:

package;

import flash.display.Sprite;
import flash.text.Font;
import flash.text.TextField;
import flash.text.TextFormat;

@:font("KatamotzIkasi.ttf") class DefaultFont extends Font {}

class Main extends Sprite {

public function new () {

super ();

Font.registerFont (DefaultFont);

var format = new TextFormat ("Katamotz Ikasi", 30, 0x7A0026);
var textField = new TextField ();

textField.defaultTextFormat = format;
textField.embedFonts = true;
textField.selectable = false;

textField.x = 50;
textField.y = 50;
textField.width = 200;

textField.text = "Hello World";

addChild (textField);

}
}

You don't have to deal with XML files or anything like that. Forget what top google search pages are saying.

So the weird part is that you actually have to use the proper name of the font when you're calling it within a TextFormat constructor. It's not the same thing as the file name. How the hell do you find the proper name of a font? Where does it say that? I just figured out mine by guessing: "Victor's Pixel Font". Need some info on this subject.

Another thing to mention is that fonts don't work the same on Android and HTML as they do on other targets. Here I'm linking Android and JS solutions to those problems.

Final note: OpenFL is cool. Haxe is cool. Open source is cool. We should be friends with people who are making open source work. They are nice guys. Buy them coffee. They need it. So my impression with Haxe is that, the road is going to be bumpy, but it's still a good technology for developing for both Windows and Flash. I don't know how consistent it is on mobile targets, but I have not heard good things about that, sadly. I'll check out for myself when the time comes.

Thanks for reading.