Font embedding in Haxe/ OpenFL

Many hours and a few days later, I’ve just about tackled another Haxe bugbear – font embedding. Basically, it didn’t work in html5 at all with the old backend for reasons I never did figure out, but does work in the new, bleeding edge html5 backend released just 9 days ago.. so that’s what I’m having to use. Real canary-in-the-coal-mine territory here.

Only small snag is that the approach used to embed fonts in html5 crashes the flash build. Luckily, you can work around that thanks to the tags that Haxe has for compiling or ignoring code based on target platform.

So, without further waffling, here’s some code that works, for everything. I spent ages figuring this out with basically no documentation and a frustrating AddingText sample that didn’t want to work when I threw my own font file at it. So, if you’re having similar problems, here’s a no-nonsense guide on how to work around it and get on with making your app or game.

 

Put this  in your Main class, after your imports:

#if js
@:font("Assets/fonts/nameofyourcrazyfont.ttf") class DefaultFont extends Font {}
#end

And then, this in your Main constructor:

#if js
Font.registerFont(DefaultFont);
#end

 

That will embed the font properly on html5 targets (not required at all for all other targets and causes problems with them, hence the #if js wrapper).

And, for the second part, here’s the code for creating a TextFormat, which of course, you can then apply to a TextField:

 

public static var name_of_your_crazy_font:Font = Assets.getFont("assets/fonts/nameofyourcrazyfont.ttf");

#if js
var body_text_format = new TextFormat ("nameofyourcrazyfont");
#else
var body_text_format = new TextFormat (name_of_your_crazy_font.fontName);
#end

And that’s it sorted! Font embedded on all platforms, including the new pixi.js-based one which is currently in an serious state of beta, but hopefully will be worked on a lot and fixed up over the next month or two. Note that this code might not work on the old backend with your font. It didn’t with mine, which is why I had to figure all this out in the first place.

 

I’m hoping this will be the last cross-platform problem I have to deal with for a while.. after a week with Haxe I’d like to get on with making the game rather than wrestling with the platform!

Progress! (and limitations)

A few days in, and I’m busy with prototyping a mining puzzle game, unfortunately starting to realise that haxe isn’t quite the magic everything-on-all-platforms solution that I was hoping for, so you have to work around a lot of little quirks and differences.. the first snag I’ve hit is blend modes, and a complete lack of consistency between targets.

Here’s what a purple gradient overlay looks like when exporting to flash (looks great, and is what I want, to add a dark purple tint to the bottom of the screen)

And, exactly the same code, with an html5 or android export (some sort of overlay effect is attempted, but looks horrible)

 

 

I really can’t think of an easy workaround for this, short of a complete redesign to pre-render the overlay effect in photoshop on all of the tiles and have them gradually get darker as things get deeper. But that won’t look as good as the flash export and will take a massively longer amount of time. Bit of a snag.

On the bright side, I have my test project working successfully in flash, html5 (all browsers!) and on my android device as an apk file, and on mobile browsers. I can tap or click to dig away at the squares super-quick. Which really is quite wonderful, writing the code just once and having it pop up on everything and work great. I’m particularly impressed with the .apk android file, testing it on 2 year-old cheap hardware (nexus 7) resulted in performance just as good as flash on a powerful desktop. Having native C code as the core of it rather than AIR or any kind of SWF wrapper is just so much better, my first mobile port (of Eclipse) had horrible performance issues and this is just so much better.

So, good and bad so far, and I think I might change my first choice of test project into something a little less visually complex and “premium game” and instead aim to create something very simple and very fun, perhaps a little rpg with no real complexity and lots of jokes instead. More of a proper test game than anything else, rather than the month-long effort I had planned.

Getting started with Haxe

First blog post for a while! Unfortunately I badly broke a toe three months ago (rushed to answer the door in socks, hit a doorframe at the wrong angle and *crack*, middle toe snapped off at an angle over the top of the one next to it) and effectively had to learn to walk again after it took ages to heal, so the physio there has been taking up a lot of time. I’m back to something resembling a recovery now and have dived straight back into development.

Recently I’ve noticed a trend towards multi-platform development, releasing for flash, mobile and html5 working out far better than simply releasing for flash alone (I know others will disagree with me on this point, but in my personal experience there’s simply not much money in flash anymore).

So, with that in mind, I started looking for a solution, and an immediate one that cropped up was Haxe and OpenFL. I dived into the documentation and got stuck right in, copy+pasting some existing as3 code I had straight into haxe files just to see what would break and what would work and fixing what was broken. About as haphazard an approach to porting as you can get, but with the large similarities between as3 and haxe, I actually got on okay with it after some initial confusion (it’s a steep but quick learning curve to get used to the command line builds and syntax changes while figuring out what the limitations are).

This is a big change for me, not using the flash IDE, not using vector graphics or the easy animation workflow that it offers. Everything has to be manually coded, even animation has to be manually advanced frame-by-frame via code (as far as I can tell, there isn’t a library that offers this, only tweens?) and simple stuff like placing a clickable button on the screen is a little more involved than simply throwing a flash simplebutton on the stage.

The end result of a day’s head-scratching? Not bad actually, I was able to re-create my screen-handling framework successfully (without transitions for now, but I know how to add them back in) and feel like I have a good grasp of the syntax and what I can and can’t do. Next step is trying to figure out animation and other basic stuff… the docs explain how to use actuate to tween stuff, but frame-by-frame animation seems to be totally undocumented and I’m really hoping that doesn’t mean I’m stuck with bitmapdata.draw() as my only option for animating anything. That’s going to be tricky if so.

Here’s a link to what I managed to cobble together, fairly unimpressive looking as an example, but the code behind it is very solid, allowing me to switch screens and have them clean up their eventlisteners and choose a transition for them properly all with a single line of code:

http://www.newgrounds.com/dump/item/2f1c32e21ca21db0d55007223deb72a9

Lots of work ahead, but I’m hoping it’ll be worth it. It is certainly really fun to test a project and have an instant html5/ android game in front of me despite the fact that I know precisely nothing about js or C++. The end result I’m hoping for is to be able to make three times as much as I normally would from just making a flash game alone and not touching the other stuff and hopefully get some sort of reasonable regular income going. I plan to get a new game together over the next month or two and take it from there. Exciting times! 🙂

Buccaneer released!

Buccaneer was released today on the Turbonuke website:

http://www.turbonuke.com/games.php?game=buccaneer

The game is essentially a narrative RPG with multiple endings and a strong “choose your own adventure” style of gameplay, similar to the gamebooks of old and browser games such as Kingdom of Loathing.

To liven things up, it also includes lots of fights including 4 different extremely hard boss battles at the end of each of the game’s four different endings (lots of replay value with this one!), as well as lots of little jokes and things to do scattered around the game.. you can spend the entire game getting drunk in taverns if you want, or you can try to complete all the miniquests, find all the items, or unlock all the endings. Since it is an open-ended exploration game, it’s a kind of sandbox for the player to explore and have fun with, and hopefully everyone will have fun going through the game multiple times to dig up all the little secrets and easter eggs that are hidden in the game.

Another feature I’m quite happy with is the choices you can make… you can be a mass murdering tyrant, slaughtering crews of ships, sacking cities, or you can play benevolently, showing mercy and only attacking the more evil characters in the game. This affects your reputation score, which is used for your final ranking once the game is complete and for *one* in-game reason only.. which I will keep a secret for the player to run into themselves!

I put a lot of effort into every aspect of the game, with hand-sketched artwork throughout as well as all the animation and code, as well as extensive playtesting of the gameplay with a gaming group and the excellent feedback exchange group on FGL. While it might not be to everyone’s taste, the people who do like it should hopefully *really* like it.

Anyway, have a play through the game and let me know what you think in the comments below!

Cheers,

– pepper 🙂

New blog!

Retired my old blogspot blog after it stopped working. WordPress seems better anyway.

I’ll move some of my old content over, but this blog will mostly focus on my new work.