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.


Level-less Gameplay and Player Stats

•November 16, 2010 • 8 Comments

In thinking about translating the creatures and heroes of the Legend of Drizzt series into a roguelike, the thought comes to mind that it won’t easily translate into a typical level based system of character progression.  Characters’ physical abilities are primarily determined by their race and age, while various skills may be honed to give the different characters and creatures an edge over others.  While there is variation among the races (Belwar seems to be a particularly sturdy svirfneblin, and Drizzt is more agile and aware than his fellow drow), you don’t see any particular creature or character standing out in strength too much above his or her peers.

Thus if I were to make a game based on this underworld, I think I would pursue a system of relative stats instead of absolute stats.  A player would have stats relative to members of their own race, and each race would have stats relative to other races.  When you’re a drow facing a hook horror, it’s really academic to wonder how many points of strength greater the creature is than the player… any single blow could crush your bone and send body parts flying.  You just need to be faster and have knowledge of the creature’s weaknesses.  When facing an illithid, one of the dreaded mind flayers at the top of the Underdark food chain, strength will avail you little while an element of surprise and a strong will are really what you need to survive a mental attack.

I think that players should still be able to boost their stats through use and perhaps lose others through disuse, but I don’t really see many players transcending their racial norms to be able to trade blow for blow with a basilisk, for example.  Statistics that seem to matter in the books are strength (how hard you can hit), agility (how fast you can move), constitution (how long you can run / fight), spirit (your devotion to principles and endurance in spite of opposition), intelligence (your aptitude to learn and grow in your skills), and charisma (your ability to lead others).  I’m sure I’m missing some that are present in the stories…

What really differentiates characters are their specialties, not necessarily their stats.  Drizzt was by all means a very intelligent drow and was destined to become a wizard of the Academy before Zaknafein intervened to make him a weapon master.  His intelligence honed his combat ability, putting his agility to better use and allowing him to gauge his constitution in the midst of a battle.  I’d like to see a game where you don’t necessarily reroll statistics to suit a particular character but where every statistic is meaningful in some way to every type of character.  As I mentioned in the previous post, I still would like players to specialize in a class, but I think your statistics should affect how well you play that class not which class you choose to play.

I think, too, that there should be a set of character traits that transcend specialties, statistics, and skills.  These are things that give different types of characters and creatures an edge in different situations.  The illithid are very communal and thus have an edge in open warfare (aside from the fact that they can incapacitate almost anyone from long range and then suck out their brains).  Drizzt has this hunter aspect that pops up to heighten his awareness and increase his ferocity and agility in combat.  Belwar is incredibly tough and can enchant his weapon-hands in combat.  Clacker’s rage makes him impervious to almost any pain.  Matron Malice is obviously guided by her ambition, allowing her to make great (if not foolhardy) sacrifices in pursuit of her goals.  Perhaps characters have to choose some particular trait that shapes their growth and goals.

I’ll have to think about this more… It’s all about providing a different game experience that remains true to the spirit of the books and doesn’t require mere leveling to be powerful.  To that end, I’d also like to see characters being blessed with some item, artifact, or piece of knowledge at the start of a game – Drizzt has his scimitars, Belwar his weapon-hands, Masoj his astral figurine, Matrons their deadly whips, and so on.

Brainstorming an Underdark Roguelike

•November 16, 2010 • 20 Comments

I’m not sure what planet I’ve been living on that has not heretofore involved R.A. Salvatore books in my hands, but that has recently been settled.  A friend loaned me the first seven Drizzt books, and I’ve been blown away.  I love them – I love the pace, the cultures, the various types of conflict, and all the fun creatures Drizzt and company encounter.

As I read through these, I can’t help but think they have the foundations of a very fun Roguelike.  I’ve been giving it a little bit of thought and will brainstorm more before actually calling it a project, but I would love to see a Roguelike that takes place in the Underdark as presented in Salvatore’s books.  Searching around, I found one Roguelike from 8 years ago that started out with this foundation and then departed.   I honestly can’t figure out why you’d ever need to depart from the story and setting.

So, here’s what I’m thinking…

  1. Start simple by only allowing Drow classes based on gender: Commoner, Rogue (nobles without a home), Weaponmaster, Wizard, and Priestess (the last three being noble classes). Noble females are physically and magically more intimidating, but males are given to different types of training and so gain advantages in hunting, combat technique, and survival.  I don’t know enough about commoners so might have to make things up.  Expansion races can include svirfneblin, duergar, human, and other higher races that might wander the Underdark.
  2. Focus on the darkness.  I really like this aspect of Salvatore’s stories… he does some clever things with the pervading darkness.  I’d love to see infrared trails on the ground I could use to track enemies.  Light bombs could blind your adversaries, while orbs of darkness can render even infravision useless.  Light might also be a benefit, as with Belwar’s magically list brooch.
  3. Include all the fun critters… the giant rats, goblins, cave fishers, hook horrors, corbies, myconids, basilisks, illithids, and more.  There is plenty of fodder in here for dual wielding drow weaponmasters imbued with the spirit of the hunter. 😀
  4. Keep the major cities, though they don’t necessarily need to be static.  Allow the player to wander around Menzoberranzan, train in the Academy, head out into the randomized cave areas to seek refuge in Blingdenstone.
  5. Tell a story upon death of a player’s origins, major feats, and ignominious end.  To that end, I’d like to see some quests baked into the gameplay so the player would have opportunities to lead raids (slaughtering elves, anyone?), battle wizards in their magical towers, rescue mining svirfneblin (or conquer their earth elementals), attain high priestess status and summon yochlol to fight, etc.  I’m obviously wanting to see a game where a player could actually live out a story like Drizzt’s, but I wouldn’t be opposed to someone choosing the darker path and seeking their house’s supremacy.

Will post more ideas as they come, but I’m interested to know if anyone else has given this some thought.  I haven’t played any roguelikes focusing on darkness, although I’ve played some that deal with stealth.  Anyone know of similar projects?

Dance of Death is a Roguelike to watch!

•November 1, 2010 • 1 Comment

I just spent a little bit of time with the ARRP release v0.6.136 of Dance of Death by Nolithius and am thoroughly impressed.  I’ve had Ebyan’s site bookmarked for a while but forgot about keeping up with his progress until I revisited the site to play through his 4DRL project, Chronophase.

Both of Ebyan’s games are somewhat unique as Flash Roguelikes with good ol’ ASCII interfaces and traditional controls.  Chronophase is a simple little space shooter Roguelike and is fun to play but presents little challenge.  Dance of Death, however, is a much deeper and more satisfying experience… imagine that, more depth in a long term project than a 4DRL.  😉

I highly recommend you give Dance of Death a try and follow its development closely.  It already has an epic feel and a satisfying level of difficulty that is sure to keep me coming back for more.  The game drops you in the middle of nowhere with no memories except a quest to go dungeon diving in pursuit of some unknown quarry.  Where it goes from there remains to be seen, as the game ended after I escaped the first dungeon.

What’s unique or interesting about Dance of Death?

Dance of Death: Character Creation

The character creation lets you customize your character without feeling cumbersome, including a few different races, 8 attributes, and a categorical list of skills to boost.

Dance of Death: Gameplay Screen

Gameplay itself plays out in a large Flash window with three panels: a main play area with a large ASCII map, a character stats summary, and a message area that shows combat messages, journal notes, inventory, and more.

Dance of Death: World Map

You start somewhere on a large island with the goal of finding a dungeon entrance in the highest peak of the mountains.  Ebyan has blogged about the world map generation routine, a worthy read for developers and Roguelike enthusiasts.  All the maps I’ve seen look quite nice, and the ASCII map for each tile on the world map is adjusted to match the terrain on the world map.  Ultimately you’ll travel through the mountains and find the dungeon entrance to descend in search of your prey.

As you wander around and enter combat, you’ll inevitably take a fair amount of damage.  At its present state, there’s no magic to speak of, so spend your points buffing your HP / stamina/ sustenance.  HP does not automatically regenerate until you eat some food (one of the many monster corpses – don’t pass them up!) that will refill your stamina and “revitalize” you, causing you to regenerate HP for an amount of turns determined by the type of corpse you ate (I believe).

The controls are also simple; press H when you get in for the full listing.  I found it quite easy to play with my left hand in its natural typing position and my right hand on the numpad.  Most everything should be in reach with the exception of the map key, but you really only need to refer to that to find out which direction to head to find the cave.

Ebyan has plans to increase the amount of content along with new features in future releases in his comments on the latest version’s release post, leaving me looking forward to seeing what comes next. 🙂