Author Archives: Jake

Haxe macros are amazing

Here’s a neat trick I discovered today while working on Iridescence.

Haxe has native macros that are very different from those found in C; rather than using a separate pre-processing language, Haxe macros are simply snippets of Haxe code that are run at compile time instead of run time.

In native builds, Iridescence populates its soundtrack dynamically by searching for all song files in the /assets/music folder. On more restrictive platforms like Flash, all assets have to be known at compile time so they can be embedded in the SWF, which meant I needed to create a list of files manually and update it whenever I added a new song. I wrote this little macro to iterate through the music folder at compile time and build a list of song files automatically.

Beta release – The Heroes’ Tourney

There comes a point in the life of every creative person where you create something that feels like the culmination of your craft. It’s your magnum opus, and you’ll never make anything better.

The Heroes’ Tourney felt that way for me. It’s a “couch multiplayer” game for 2-4 players in which you try to punch your friends off of platforms or into environmental hazards.


It started in a 24 hour game jam held by SNHU, a college here in New Hampshire. Chris, Mike, and I had decided to make a local multiplayer game and had the basic groundwork up and running. At some point around 12 hours in, Chris and I woke Mike up with our laughter over the absurdity of a certain bug with the physics, and we decided to build the rest of the game around that. The rest is history.

The 24 hour deadline rolled around and our game was a smash hit, despite being nowhere near finished. About a week later, we all met up again at a game jam at NHTI and somehow decided to continue work on THT instead of creating a new game from scratch. This new version included a powerup system that added a whole new dynamic to the gameplay. We had a mini tournament during the wrap up session and it was incredibly rewarding to see other people laughing and taunting each other while they played.

I’ve done some more work on the game since then and we still plan to work on it in the future, but I think it’s finally ready to be thrust out into the world to see how it fares. You can download it here. Make sure to read the readme, and yes, controllers really are required.


Here are some action shots from our post-thanksgiving dinner tournament.

And here’s my little sister playing against my cousin’s girlfriend.

Color/Shift input woes

When I released the Color/Shift demo, one of the main issues that were being reported was that dragging the pawns around was really difficult. This confused me as I had spent a lot of time painstakingly tweaking the controls so that sliding pieces felt natural and responsive, but it was obvious by watching people play that there was something seriously wrong. I made some changes to try to make it better, but the result was still pretty bad. The pawns would slide around loosely in any direction they wanted until crossing a grid line, at which point they would snap to an axis and move along it, It didn’t feel good, and it introduced all kinds of new problems including the possibility of phasing through objects or traveling in two directions at once. Worst of all, it still didn’t address the issue entirely.

Dwm 2013-11-11 10-21-38-83

Yuck. :(

I let it be and moved on to other things, planning to come back to fix it later. There was probably a little bit of hubris involved, if I’m being completely honest with myself; if I didn’t have a problem controlling the game, other people shouldn’t either, right?

A few days after leaving the issue behind, I was working on my laptop (most of Color/Shift’s development has been done on my desktop computer) and suddenly started having the same problem as my testers. Pawns were moving sideways when I wanted to move up, and sometimes they wouldn’t even move visibly before smacking into a wall to either side. What was going on?

As best as I can figure, the input issues had to do with the sensitivity of the mouse being used for control. My desktop has a high DPI gaming mouse with the sensitivity cranked way up, and my wireless mouse and laptop trackpad are much less precise. Armed with this new information, I set about making things right.


Here’s a visualization of the way I’m handling input now. When the user presses the mouse button, the pawn remembers where the pointer was when it was pressed. In the image above, it’s right in the center of the piece.

At this point, no dragging is actually done yet. The mouse must move 7px in any direction before the pawn will move at all; this is represented by the circle cutout at the center of the transparent fans.

When the mouse has moved far enough from its original position, its angle to that position is checked. If the angle is within 30° of an axial direction, the pawn is then allowed to move on that axis. If not, no movements are made.


The angle is relative to the mouse click position, so it’s possible to start the drag by clicking anywhere.,

I still need to stress-test this to make sure it works for everyone, but it feels much better with all of my mouse devices and I have yet to move a piece in a direction I didn’t intend since improving this mechanic. Feedback is important! Listen to your testers!