Using OpenFL Templates to Modify Functionality in Haxe Libraries

I recently had to modify some functionality in the FlxAnimationController class in HaxeFlixel 3.3.6 for our game Spacejacked.

Since the change was rather minor, and I didn't want to clone the FlxAnimationController and FlxSprite (which uses FlxAnimationController) classes, I decided to use the templating capabilities of the OpenFL project XML format.

FlxAnimationController is located under the flixel/animation directory of the Flixel project source folder. To replace the functionality, I copied FlxAnimationController.hx to templates/haxe/flixel/animation/FlxAnimationController.hx in my own project folder and made my own changes there.

To get OpenFL to use this file instead of Flixel's, I simply added this template tag to my application.xml:

<template path="templates" />

Using Adobe AIR Tools to Turn an SWF into a Native Executable

Here's a post to remind myself how to do this.

We have a strange bug in the Windows build of Spacejacked: the game hangs for long periods (usually more than a minute) at random intervals. I suspect it has to do with the audio code in the game, but haven't figured out a way to track it down.

As a temporary workaround, we're packaging the Flash version of the game into a native Windows executable via Adobe AIR.

Steps:

1. Adobe requires a code-signing certificate for digitally signing your executables. Either follow the instructions on http://help.adobe.com/en_US/air/build/WS5b3ccc516d4fbf351e63e3d118666ade46-7ff0.html and get one from a certification authority, or create your own (if you're just making a test build) like so:
   

   adt -certificate -cn ADigitalID 1024-RSA SigningCert.p12 39#wnetx3tl

   This creates a .p12 cert named "SigningCert.p12" with common name "ADigitalID" with password "39#wnetx3tl". The full command specification can be found at http://help.adobe.com/en_US/air/build/WS901d38e593cd1bac1e63e3d128fc240122-7ffc.html.
   
2. Create an application descriptor XML file, as mentioned in http://help.adobe.com/en_US/air/build/WS5b3ccc516d4fbf351e63e3d118666ade46-7ff1.html.
   For example, here's our spacejacked.xml:
   

   <?xml version="1.0" encoding="utf-8" ?>
   <application xmlns="http://ns.adobe.com/air/application/3.2">
       <id>com.rottenmage.spacejacked</id>
       <versionNumber>0.0.1</versionNumber>
       <filename>SPACEJACKED</filename>
       <name>Spacejacked</name>
        <description>
           <text xml:lang="en">SPACEJACKED</text>
       </description>
       <copyright>Copyright (c) 2014 Rotten Mage Pte Ltd</copyright>
       <initialWindow>
           <title>SPACEJACKED</title>
           <content>
               SPACEJACKED.swf
           </content>
           <visible>true</visible>
           <resizable>false</resizable>
           <maximizable>false</maximizable>
           <renderMode>direct</renderMode>
       </initialWindow>
       <icon>
           <image16x16>icons/smallIcon.png</image16x16>
           <image32x32>icons/mediumIcon.png</image32x32>
           <image48x48>icons/bigIcon.png</image48x48>
           <image128x128>icons/biggerIcon.png</image128x128>
       </icon>
       <supportedProfiles>desktop extendedDesktop</supportedProfiles>
   </application>
   

   where SPACEJACKED.swf is the name of the SWF file we are wrapping. Note that the namespace specified in xmlns in the <application> tag should be set to an appropriate version that corresponds to the SWF version you are targeting; details at http://help.adobe.com/en_US/air/extensions/WSf268776665d7970d-2e74ffb4130044f3619-8000.html.
   
3. Create a directory structure for packaging (details at http://help.adobe.com/en_US/air/build/WS901d38e593cd1bac1e63e3d128cdca935b-8000.html). For a quick-and-dirty solution, we use:
   

   /SPACEJACKED
       SPACEJACKED.swf
       spacejacked.xml 

   with the certificate just outside of this structure.
   
4. Finally, from within the root of the packaging directory, run in the command prompt (for a Windows build):
   

   adt -package -storetype pkcs12 -keystore ..\SigningCert.p12 -target bundle ..\SPACEJACKED_game spacejacked.xml SPACEJACKED.swf

   which will prompt for the certificate's password (created in step 1). This creates the executable in a directory called SPACEJACKED_game one level above the packaging directory.

That should be it. The instructions are similar for other platforms. Note that (as of writing) native bundles/builds can only be created on the same platform, i.e. Windows bundles can only be created on Windows, Mac .app bundles on Mac OS X, Linux .deb/.rpm on the appropriate Linux distros.

Weird Fullscreen Behaviour in OpenFL + HaxeFlixel

In OpenFL projects, the initial fullscreen status of the application can be specified in the project's application.xml file via the fullscreen boolean attribute of the window tag, as given in the specification.

However, I found that this attribute interacts in strange ways with HaxeFlixel's own fullscreen setting when building for desktop profiles (using OpenFL 1.4.0 and HaxeFlixel 3.2.2). Setting fullscreen to true results in the application having a window resolution that is not the one specified. In addition, the application drops out of fullscreen mode if FlxG.fullscreen is false.

On a side note, the fullscreen attribute behaves well in the mobile profile.

My solution to that is to set fullscreen to false in desktop builds, and rely on the functionality provided through HaxeFlixel's FlxG.fullscreen and the StartFullscreen parameter of FlxGame's constructor.

Visualizing Profiling Data with Google Chrome

This isn't a new feature in Chrome, but I just found out that we can use Google Chrome to visualize inline profiling data, rather than write our own visualization tool. This is done via chrome://tracing (see http://www.altdevblogaday.com/2012/08/21/using-chrometracing-to-view-your-inline-profiling-data/).

All we have to do is write the profiling data in a format that the Chrome viewer accepts (https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU) and load it up in the viewer. Awesome!

Sidequest Updated: Blast

Two posts ago, I talked about creating a mash-up of Geometry Wars and Rez. I present to you Blast, an audio toy where shooting stuff paints a tone matrix. In this initial version, you control a simple ship to blast circles in order to colour cells on the tone matrix. Coloured cells then determine what sounds are played. It's still lacking a lot of feedback, but the general idea is there. I think the audio generated is pretty interesting.

In hindsight, coding everything with EaselJS was probably a bad idea, as I had to write out a lot of stuff on my own; stuff like motion and collision detection which could have been done easily with a framework like Phaser. I'll probably be porting everything over to Phaser before adding more stuff like particles and more interesting enemies. Chiny pointed me to a sprite generation tool that could come in handy for creating enemies. I'll see what I can come up with them. Maybe exploding enemies that colour multiple tiles in one go.

Quick and Dirty Checkerboard Spritesheet

Need a checkerboard transition but don't want to code it out? Want to use a spritesheet for it instead? Don't want to have to do it by hand? Then this script is for you!

Just came up with a quick and dirty script using ImageMagick to generate a checkerboard transition spritesheet. Not the best way to do things, but at least it serves to help me remember the ImageMagick options that I tend to use.

Sidequest: Geometry Wars + Rez

What happens when you mix Geometry Wars with Rez?

Chiny suggested this: combining the gameplay of Geometry Wars with the musical elements of my musical toy, HTML5 Harmonium. Essentially, whenever an enemy gets destroyed, it colours the cell it was on. We then play through the cells as in Harmonium and see/hear what happens next. I'll be using EaselJS for this project. Expect to see more in the next few weeks (once I get my exams over and done with).

The Beginning

Hello! This is the beginning of what will be, hopefully, a series of posts to offer a glimpse of a (rather inexperienced) game developer's life. I am currently a co-founder and programmer of Rotten Mage, a recently-formed game development studio with a focus on pixel art and interesting game mechanics. We make games for the web and desktop, so please support us by playing our games!

In the weeks to come, I'll be posting technical details and updates (probably on a weekly basis) about the projects that I'm working on. I have a love for the command line, utilizing Python, bash scripts and Makefiles (all written with vim, of course!) to automate my build process, so expect to see the occasional script making its way here. Most of the time, I code in C/C++, Actionscript 3, JavaScript, and now Haxe. I dabble in Haskell once in a blue moon because I think it's a wonderful language, and hope to use it more. Check back regularly if you want to learn those programming languages along with me, or are interested in video game development in general, or just want to know what Rotten Mage is up to.

Salut,
Jon