HaxeFlixel Tip: Mind Your Assets

•August 15, 2013 • 1 Comment

As I described in my previous post, I’ve started working from the latest HaxeFlixel dev code to take advantage of the latest and greatest tools. This includes a newly revamped command-line interface to use flixel-tools to create a new project from a template. Unfortunately, I had the hardest time ever trying to get my quick demo program to work that was running just fine on the 2.0.0-alpha3 (or whatever it was).

The issue turned out to be that the new template’s project .xml file does something… helpful, I guess? with your assets directories. You see, the project will get created with an assets directory containing a variety of subdirectories for storing images, music, etc. If you wanted to load a graphic to a FlxSprite, you might think you’d use:

loadGraphic("assets/images/filename.png", true, true, 32, 32);

But you’d be wrong! That’s the relative path to the file, but your .xml file renames each individual subdirectory to remove the assets bit:

<assets path="assets/images" rename ="images" />

Thus, instead I should have been loading like so:

loadGraphic("images/filename.png", true, true, 32, 32);

I don’t know why this decision was made to obscure the file path as a default assumption for every project, but it cost me a couple hours’ frustration to save a few characters every time I load an asset. I’ll most likely be removing these aliases in my personal projects, and since I’ve sourced my Haxe flixel / flixel-tools libraries from personal repos, I can always patch my template tool to work that way from the command-line.

On a side note, if anyone knows a way to get real-time feedback on why a Haxe program crashes out, I’d love to know about it. If I could’ve seen a simple “file not found” error message on exit, I could’ve focused my efforts on that loadGraphic() command exclusively. That probably could’ve shaved half my debugging time.

Learn HaxeFlixel from Scratch (pt. 2): Running the Latest Dev Code

•August 3, 2013 • 5 Comments

Apparently HaxeFlixel is in the midst of some major rewriting.  If you simply install it using haxelib install haxeflixel, you get the latest tagged release, 2.0.0-alpha.3.  However, the various demos actually depend on the latest dev code to run.  I like to learn from demos and couldn’t handle being left in the dark, so here’s what I did to start running from “dev”, the latest versions of the code.

First, I uninstalled whatever HaxeFlixel related libraries I already had.  At the time, they were flixel and flixel-addons.  You can find yours by typing haxelib list from the command line and then haxelib remove <library> for each HaxeFlixel related library you find.

Second, I went to GitHub and forked the projects I wanted to download.  I did this so I could actually install the dev versions of the libraries from my own repositories.  This will make it easier for me to contribute back, because I’ll be able to make and test my changes locally before pushing them to my GitHub repository and submitting the changes to the main projects as pull requests.

For now, I just went with flixel and flixel-tools, and I recommend you do the same. Flixel Tools contains the command line interface tools that were previously available in the main Flixel library.  You’ll need them to create a new template for a project or convert a HaxeFlixel 2.0.0-alpha.3 project to run on dev.

Next, I installed the libraries from my Git repositories using haxelib git <library> <URL> <branch>. Run this once per library, substituting the library name (flixel or flixel-tools), the Git repository URL (copied from the GitHub page), and dev as the branch. Note that it’s perfectly fine to install from the main repositories instead of your own forks.  If you do use a fork, you’ll be responsible for pulling in changes to your forks from the main repositories before running haxelib upgrade to update your local copies to the latest dev code.

Finally, I wanted to create and test a new project from a template using the flixel-tools command line interface. First you have to instruct flixel-tools to download the template and demo files using haxelib run flixel-tools download. Then you create a new directory for the project, switch to that directory, and execute haxelib run flixel-tools template -n <name> -w <width> -h <height>.

To test this, you should be using openfl, a separate Haxe library. If you don’t have this already, there are download instructions using haxelib on the OpenFL getting started page.  Once it’s installed and setup, you can test your new project with openfl test <target>.  I’m developing on OS X, so I use “mac -neko” as the target, though I don’t think there’s a difference if you just target “neko”.

Now that I’m all setup, I’m eager to continue learning both the language and the library. Not content to just use without giving back, I’ve already submitted my first pull request to the project to rename a couple misspelled variables. Onward!

Learn HaxeFlixel from Scratch (pt. 1): The Display List and Program Entry

•August 3, 2013 • 2 Comments

And thus begins my foray into learning a new language with which to program games and mobile apps. I’ve always used FreeBASIC to fiddle with desktop games in the past, but I do all of my development on OS X these days and would love to target multiple platforms for whatever I come up with. FreeBASIC doesn’t fit the bill, but Haxe seems like a strong alternate contender… and lo and behold, there is a Haxe port of the Flash game library, Flixel, appropriately dubbed HaxeFlixel.

This blog post will be the first in a series of self-educational blog posts as I teach myself not just HaxeFlixel but Haxe and not just Haxe but ActionScript programming in general. I’m truly starting from scratch here, interpreted as “from nothing” as opposed to “from that awesome GUI based programming language for kids made by MIT.” If you’re following along, you’ll need to grab the full stack of Haxe + OpenFL + HaxeFlixel as described in the project’s Getting Started guide.

My earliest attempts to understand how HaxeFlixel worked were thwarted by my lack of general understanding of how ActionScript itself works. I saw classes being tossed around like Stage, Sprite, Event, and more with no real concept for what the program would look like from a high level. So, armed with my trusty IDE and command line grep, I started digging. And digging. And digging.

Apparently ActionScript (and by extension Haxe) programming involves classes upon classes upon classes. It’s quite common to start in a class 6 steps removed from its parent class in the hierarchy (where it typically terminates in an EventDispatcher, i.e. a class that can listen for and react to events – very handy). This makes things quite daunting, to be honest, but it gets more manageable as you start to piece together a picture of the main class families in use.

My first “aha” moment came when I finally stumbled upon an ActionScript (hereafter AS) concept known as the display list. This is basically the hierarchy of objects used in an AS / Haxe program to manage all application objects / logic / display:


It all starts with that top level Stage object and descends from there through the instance of your application’s “Main” class to the various display objects and containers used to actually show stuff to users / players.

Building on this bit of knowledge, we can actually tease out how a Haxe program gets going by examining the Main.hx generated when you create a new HaxeFlixel project (see the Hello World tutorial for an example, specifically the bit introducing “haxelib run flixel”). Stepping through the code, I see the following things happening:

  1. The Main.hx file contains the program’s entry point, the static function main(). This function simply adds an instance of our Main class to the root object container. (It does this using Lib.current, which appears to be a MovieClip object, so I’m not sure how Lib.current sits in relation to the root Stage. A worry for another day.) Note that our Main class is a child of Sprite, which can ultimately function as a Display Object or a Display Object Container in our hierarchy.
  2. Creating the new Main object involves setup through its parent constructors (done using super() in Haxe) and then a quick check to see if it has been added to the program’s global Stage object yet. If so, then we directly invoke Main’s init() function. If not, we add an EventListener to the Main object (because Sprites are ultimately children of EventDispatcher) that invokes init() once it’s been added to the Stage. This use of event listeners seems quite common and analogous to jQuery’s .ready() – i.e. wait until we’re sure everything’s in place before doing anything. Bonus reading in this Republic of Code event listener tutorial I found.
  3. init() removes that listener if it was added and then invokes initialize() to set the program’s alignment and scaling mode. I’ll have to research those later.
  4. Next, init() creates the actual FlxGame object (itself a child of the Sprite class), the heart and soul of a HaxeFlixel game. It adds this object as a child of the Main object.
  5. Finally, if the program is being compiled to C++ or neko (a language with a virtual machine that we can use for testing on OS X thanks to openfl), a simple keyboard event listener is added that exits the program if the escape key is pressed.
  6. The constructor of the program’s FlxGame object is primarily responsible for determining the dimensions and scale of the game and then invoking its parent’s constructor to set everything up, including pointing to the initial “FlxState” of the game. A State is comparable to a “view” of the game and may correspond to a menu or a game screen.
  7. The next post in this series will dig into what happens when the constructor of our program class’s parent FlxGame class executes.

That’s about all I can manage for tonight. I’ll keep trucking through learning the nature and structure of HaxeFlixel games and try to point out any tips I pick up along the way. HaxeFlixel still comes across to me as a work in progress, but it’s an open source project hosted on GitHub (whose community portal is Drupal powered, yay!), which just screams to me “fork me and fix things.”

I intend to oblige.

The 2012 7DRL Competition has begun!

•March 11, 2012 • 3 Comments

I won’t be participating because of work commitments, but I will be following along.  A 7DRL competition is a “7 Day Roguelike” compteition, in which a bunch of crazy people set about to make finished games in a mere 7 days.  The most expansive roguelike projects have been in development for years, and of course many are never-ending projects.  This competition, on the other hand, is designed to give developers a hard limit within which to work.  They really can’t develop end-all be-all games, just vignettes that play with a particular theme or game mechanic.  This makes the resulting games somewhat experimental, but often still thoroughly enjoyable.

I’ve reviewed 7DRL games in the past and hope to do the same this year.  I’ll be at a conference for the entire week after the competition, but I’ll be going on vacation shortly after I return.  This should give me plenty good playing time.  🙂

For more information, check out:

  1. The roguelike radio episode introducing the competition.
  2. The various game threads in r.g.r.d.
  3. The list of entries at the Roguebasin.

I’m looking forward to entries from Slashie, Darren Gray, and Nolithius and the DuneRL built on a still-in-production RL library.  Good luck to everyone who’s joined the competition!

Roguelikes at TIGSource

•February 4, 2011 • Leave a Comment

I’ve been wanting to write about the roguelike discussions and developments centered around the TIGSource forums and competitions for some time.  Unfortunately, I don’t have the time now to really do the topic justice.  However, there’s a hot topic building right now that I wanted to link to introducing a roguelike newbie to various hallmarks of the genre.  See it here: http://forums.tigsource.com/index.php?topic=17629.0

I was quick to recommend Brogue of course, and I also recommended 100 Rogues, my favorite iPhone roguelike.  There are some familiar names coming up in the discussions and some unfamiliar as well.  Looks like I’ve found some new games to check out!

Another reason for you to follow the roguelike discussions at TIGSource is the regularity of roguelike games that come up.  Last year, their Assemblee competition resulted in the famous “Oryx tileset”, a set of lo-fi roguelike assets that have been used in many games since then.  My favorite is Realm of the Mad God, a Flash based massively multiplayer co-op shooter that introduces procedurally generated dungeons after random monster kills.  I like it so much I built the game a community website that’s turned into the most trafficked website I’ve ever built.  😛

Support Slash, a Roguelike Developer

•January 11, 2011 • 1 Comment

Slash, a very prolific and experimental roguelike developer, has just announced a supporter license program for his games.  I’ve blogged about one of his games here in the past (Ruler, his 2010 7DRL).  He’s the creator of various video game Roguelike adaptations, including CastlevaniaRL, ZeldaRL, MetroidRL, not to mention his custom games that range in size and scope from small to epic.  Slash also maintains Temple of the Roguelike, the entry point for a lot of roguelike players and a discussion place for many developers.

The support license brings with it a few perks, but the main benefit of course is that it gives you an opportunity to reward a prolific developer for the great free games he’s made for years.  It can then further encourage him and support him as he develops his various titles further and expands his efforts in other areas, like Pixal.

So… what are you waiting for?  It’s as easy as a click of the PayPal button… 😉


CRPG Addict on Roguelikes

•January 5, 2011 • Leave a Comment

Through a tweet from Slashie I found out about the CRPG Addict blog.  If you haven’t read it before, I’ve linked to it in the sidebar and highly encourage you visit and follow along.  The blog is one man’s journey through every computer role-playing game ever published for the PC, starting primarily with Rogue (though he does provide a quickie review of Akalabeth that was nothing special).

I’ve enjoyed his musings on game design, especially regarding open ended gameplay, game world economies, and particularly Roguelikes.  The link below will get you to the Roguelike related posts, which include some humorous stories of his adventures in Rogue and Nethack thus far.