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

Free-form level editor

The last week or two I’ve been working on a 2D level editor. I can drag and drop images onto it to create free-form levels (beware, placeholder art):

19_papernode_editor

It’s meant for a platformer game, but it’s fairly easy to use the output for a different kind of game. Like, say, a strategy game, or just as a title screen layout file.

On the right side, there’s the bare-bone UI: the layer selection and visibility toggle buttons, the delete-this-layer button, and of course a button for adding layers. The red lines are collision lines – I’ve experimented with that a while ago and it turned out to work pretty well, so I’m migrating parts of my collision-line editor/test program to this new editor. On the right side, you can(‘t) see a hidden layer. The blue lines are the grid – which can be toggled and it’s granularity can be fine-tuned. It’s not used for snapping yet, so it’s mostly there to give me some sense of place and size.

I’m still working on various features, but it’s already a useful tool. I wrote it in Python, using Pygame (for the rendering and input handling), pgu (for the buttons) and pywin32 (for the drag and drop support). It has taken me 4 or 5 days so far, a couple of hours each day. :)

Free-form level editor

Programming in Python is fun!

The last few months I’ve been doing more and more with Python. While the games I work on are mostly written in C++, there’s still a lot of room for me to use Python. For example, when dealing with file conversions, data checking, automating processes, and so on.

Two weeks ago, I wrote a tool that packs smaller images into larger ones. I first prototyped the packing algorithm in Python and then translated it to C#, which I used for the tool itself.

Last week, within a few days, I was able to process, verify and preview almost 2000 files for one of our games, converting them from XML into a tight binary format, all packed into custom archive files to keep things easy for the file-system. I spent most of my time thinking about the file formats and the required checks. Writing the tools took little time. Continue reading “Programming in Python is fun!”

Programming in Python is fun!

Bullet consumption

I’ve been prototyping yet another game idea during the last few weeks. Since I’m now a full-time game programmer at Triangle Studios, I have less spare time to devote to game-development. Fortunately, less doesn’t mean nothing at all.

So here’s BulletEater. A danmaku/bullet-hell game. Except that you’re unable to fire back at turrets, so you’ll just have to survive the bullet patterns. Actually, you’re not completely defenseless: there’s an overcharge mode that allows you to eat bullets, which in turn adds to your score. It does cost you a life however, but lives slowly recharge so that’s simply a matter of surviving long enough. Eating bullets speeds up the recharge process a bit so you may want to save your lives for the really nasty situations.

Bullet Eater - danmaku mayhem

These are things I’m still thinking about, as they make large bullet patterns easy score-fests instead. So I’m thinking about including laser-beams that can’t be eaten to control the difficulty and challenge some more. If you have any suggestions, feel free to share them.

Bullet consumption

A little more about level-design

Last week I finished dm_mudanchee, a map I started 2.5 years ago. I’ve probably worked on it for 6 or 9 months altogether, which means I had some big hiatus along the way. At some point I had even decided I wouldn’t do any serious level-design anymore…

Creating levels for games like Half-Life 2 can be a very labour-intensive process, especially when there’s a lot of custom content involved. But what’s especially painfull is finding out that your map just isn’t fun… after you’ve put in months of work. I’ve had that happen a lot of times, which often resulted in yet another unfinished, abandoned map.

That’s where I learned the value of planning ahead. dm_mudanchee, despite it’s irregular development process, is the result of proper planning, early playtesting and many more iterations – and sheer persistence, I suppose. When I started, I built a few style test maps: a cave filled with water, some wooden planks here and there, some more caves. I also built quite a few layout tests, that were extensively playtested by me and a few friends. After a few of these maps I settled on a design, which I then filled in, using the style test maps as a guide. 50 versions and quite a bit more playtesting later dm_mudanchee was done.

It’s actually amazing to see how many people don’t plan ahead. Keeping that in mind though, it’s not so amazing to see so many levels, mods and game projects fail.

Anyway, after finishing up that map, I got the hang of level-design again. So I started on another map. I’m still in the layout testing phase, but here’s a rough sketch that shows what I’m working towards (it’s the same tower, drawn twice): a small vtol launchpad, an outpost tower built on top of a rock, surrounded by endless swamps with occasional mountains and other outposts dotted on the horizon.

dm_launchpad14 concept sketch

A little more about level-design