haXe preloader

2 years ago I tried to create a preloader in haXe, but whatever I tried, nothing worked. Today, I had to create a preloader for a project at work. Needless to say, I wasn’t too happy, with that first experience in mind.

I did some Googling and found various forum and blog posts, but whatever I tried, nothing seemed to work. Mindless Labs suggested using mxmlc to embed the game .swf into an Actionscript preloader, but mxmlc couldn’t digest our game .swf. Game Haxe had another approach, but apparently that one broke when haXe 2.03 got released. Using the MochiAd preloader didn’t work out of the box either, because that one would only be run after the whole .swf was loaded. So I was thinking towards creating a separate preloader .swf that would load the main game .swf – it’s a messy, multi-file solution, but at least it’s a solution.

However, I talked about it to a coworker, asking how this would be done in ActionScript. The standard approach is to move all assets to a later frame, and to put some preloader code and assets in the first frame. I decided to give it a try – mind you, the same thing had failed me 2 years ago – and suprizingly, it worked! Back then, the assets had been inaccessible, but some haXe and swfmill versions later it works like a charm.

Here’s how my swfmill .xml file looks like now:

<?xml version="1.0" encoding="iso-8859-1" ?>
<movie version="9" width="600" height="400" framerate="30">
    <background color="#FFFFFF"/>
    <frame /> <!-- add one empty frame -->
    <frame>
        <library>
            <clip id='image' import='images/image.png' />
            <font name='font' import='fonts/font.ttf' />
        </library>
    </frame>
</movie>

Line 4 is important: it adds an empty frame, into which the haXe code is compiled. The second frame contains all the heavy-duty assets, which will be available once the whole .swf has been downloaded.

My main function now looks like this:

package ;
import flash.events.Event;
import flash.Lib;
import haxe.Log;
import game.Game;

class Main
{
    static function main()
    {
        Log.trace("Starting preloader");
        Lib.current.root.addEventListener(Event.ENTER_FRAME, onEnterFrame);
    }
    
    static function onEnterFrame(event : Event)
    {
        Log.trace("Downloaded " + Lib.current.root.loaderInfo.bytesLoaded + " of " + Lib.current.root.loaderInfo.bytesTotal + " bytes");
        
        if (Lib.current.root.loaderInfo.bytesLoaded >= Lib.current.root.loaderInfo.bytesTotal)
        {
            Lib.current.root.removeEventListener(Event.ENTER_FRAME, onEnterFrame);
            Log.trace("Preloading finished");
            
            // The Game class adds images to the screen, sets up listeners, etc.
            var gameInstance : Game = new Game();
        }
    }
}

Normally, I would’ve created a Game instance immediately within the main function, but the assets only become available once the whole .swf is loaded, so it’s a smart idea to wait until the number of bytes loaded matches the total number of bytes. ;)

I hope this post is useful to those who are looking for a haXe preloader. :)

<?xml version=”1.0″ encoding=”iso-8859-1″ ?>
<movie version=”9″ width=”600″ height=”400″ framerate=”30″>
<background color=”#FFFFFF”/>
<frame /> <!– add one empty frame –>
<frame>
<library>
<clip id=’image’ import=’images/image.png’ />
<font name=’font’ import=’fonts/font.ttf’ />
</library>
</frame>
</movie>
haXe preloader

MochiAds in haXe

I’ve been using haXe at work for a current project, and while things have been working pretty well so far, one thing proved to be a little more troublesome than we expected. We tried integrating MochiAds highscore APIĀ  into the game, following hesselboom’s guide, but whatever we did, all we got was a broken game. No MochiAd pre-game ad, nothing, just a white screen. That’s not a good thing, considering that integrating it into an Actionscript project is supposedly a 5-minute job.

To give a little more insight, all game assets are packed into a .swf file using swfmill. The process is automated with a Python script, so all images, sounds and fonts are lumped together into archive.swf. When compiling the haXe code, this .swf file is passed along, so the code gets compiled into the .swf, to produce the final game .swf. Hesselboom’s guide suggested embedding the mochi library and the assets .swfs into one archive .swf. We first tried to just embed the mochi library .swf into our archive .swf, but that didn’t work. We then tried embedding both into a new .swf, but that didn’t work either.

My coworker did get MochiAds working in a new project though, just not in the actual game. So I started analyzing the swfmill output and I noticed something interesting. The fonts were giving trouble. Apparently swfmill can’t handle the case where an embedded .swf file contains already embedded fonts. However, embedding the fonts into the final .swf didn’t solve the problem…

In the end, I tried something silly: changing the embedding order of the library and the assets .swf. Guess what? It worked!

So just in case you’re working with haXe and integrating MochiAds fails – swapping two lines in your swfmill xml file might just do the trick. :)

MochiAds in haXe

Checking out Neko Media Engine

I recently stumbled across Neko Media Engine, a SDL wrapper for haXe. I decided to port one of my Flash games to NME, to make it a stand-alone application. I got it up and running after modifying my framework for a few hours. It turns out that, with relatively few changes, my framework can be used for ‘normal’ games just as well. I’m starting to like haXe more and more now, especially with such libraries around.

The developer of NME, Lee Sylvester, has recently teamed up with Hugh Sanderson to create Neash: a Neko library that provides the Flash API for Neko applications. In other words, we’ll be able to use (almost) the same haXe code for both Flash and Neko applications… That sounds interesting!

Checking out Neko Media Engine

AI Wars is looking for AI agents!

AI Wars is done

It’s finished. The Flash frontend and Neko backend are done, and my classmates have produced a nice AI client for demonstration purposes. The whole package is roughly 0.5 MB.

AI Wars - blue versus yellow

To make things a little easier, I’ve written a batch file that starts both the backend and the frontend. All that’s left then is connecting the AI clients and starting the game.

The gameplay

Continue reading “AI Wars is looking for AI agents!”

AI Wars is looking for AI agents!

AI Wars – a side project

I promised to write about that ‘other game’. It’s a school project focussed on AI. Me and a friend are writing a turn-based strategy game similar to Advanced Wars, and some other friends are writing AI applications that can connect to our game. We’ve chosen for a Flash-based front-end, connected with a Neko-based back-end that handles the connections with the other AI apps. From there, it’s simply watching those AI agents duke it out against each other.AI Wars

As for Aural Fighter, it’s slowly becoming better and more playable. I haven’t done much on it last week due to being ill, but I’ve done some things nonetheless. Most of the missile weapons are now working: the guided missiles and splash damage missiles are pretty fun to play with and they’re quite powerfull. I’ll tweak the exact values once I can playtest some of the later levels, but for now, it’s fun to blow up waves of enemies with splash damage missiles. smile.gif

The first level is nearing completion, too. I only need to do some art for it and add several more enemy waves. I’m also working on the first endboss, which is going to be component-based. I’ll probably write some more on that in a later post.

AI Wars – a side project

Who listens?

Something has bugged me for quite a while: Aural Fighter reacted slower and slower the longer I played it. I was absolutely sure it had to do with the rendering code, but even a bare-bone test game slowed down after a while. Confused, I ignored the issue for a while, but I realized I couldn’t release Aural Fighter with such an issue unresolved, so I just had to fix it.

But whatever I tried, nothing seemed to cause the problem. Finally, I decided to create a minimum piece of code that still reproduced the problem, to post on the HaXe mailing list. While doing so, I found out that the game only stopped respondeding after a lot of keypress events had happened, not just after some time. I was confused: was I handling input in a wrong way? It should be a perfectly normal method… but while stripping away unrelevant code, I finally figured it out: I had added another keyListener in a pre-loader frame, one that was never removed afterwards. This one started to intervene with the other keyListener. Removing it finally solved the problem.

On a side-note, I’ve added shadows to all enemy fighters and I’ve drawn a few new enemies and tiles. I’m also working on another game – as a school project – so Aural Fighter is proceeding slower as desired, but the experience I gain from that project should be pretty usefull for later games. I’ll write some more about that project later.

Who listens?