Arbor’s Rocky Start

Arbor’s development began in January 2013. I had just finished my second and third games in November and December, Push/Pull Factory for the 2012 GitHub Game-Off and Tobetl for the TIGSource Advent Calendar. I was excited about having actually finished two games. It was a big accomplishment for me. It’s a year later and I still look at those two months as being the most productive time of my life.

Sometime in late January, as I was just beginning a new job at a web development company, I got the urge to work on an idea I had come up with back in November. I wish I could remember where the idea for a tree game came from. What I do remember is that I had the basic concept figured out in about 5 minutes. I had drawn a quick mockup and wrote rules all over it. I rediscovered that mockup in January.

I thought, for a little while, that I’d be able to use Arbor for the February 1 Game A Month Challenge. Looking back on that now it seems so silly. I was going to invent brand new game mechanics and do all kinds of programming I’d never done before in 1 month? Yeah, right!

Anyway, some months went by and I spent some time learning PHP to get settled into my new job. In the summer, I finally started working on Arbor.

Hidden deep in some Bit Bucket server is a pre-pre-pre-alpha version of Arbor written in Haxe 2.something and NME (both of which are now very out of date). It was basically just a Game class and a Branch class and all it did was draw 1 little twig sticking out of the bottom of the screen. It was a start, at least. Arbor’s development had picked up a little bit of momentum.

That momentum didn’t last though. Business and trouble popped up at work and I had to focus on that for a few months. It was a omen for things to come. In the beginning of August I was laid off. It felt terrible, of course, but I can look at it now as a huge blessing for my family. That job wasn’t paying enough for us to keep our house so I was going to have to quit eventually anyway.

That period between jobs marked a phase in Arbor’s development which turned out to be misguided. I’m glad I took the path I did though. I learned more about what I could accomplish and I learned about the limitations of the graphics framework I was trying to use.

Here’s what happened.

In September, I scrapped the NME code, installed Haxe 3 and OpenFL (NME had morphed into OpenFL during my time away from the project) and also a wonderful framework meant specifically for games, HaxeFlixel. As you can probably guess, it’s a Haxe version of the ActionScript library called Flixel.

Haxe Flixel has some great features which can really ease the process of 2D game programming. Unfortunately, at the time, I didn’t realize that it was the complete wrong choice for my game. HaxeFlixel is great at moving lots of bitmap sprites around on the screen and animating them. It is not great at drawing procedural graphics, which is what Arbor is all about. I made the first interactive Arbor prototype in HaxeFlixel. As soon as I dragged that first branch up out of the ground, I knew I’d made a mistake.

First of all, the branches looked truly awful. They looked badly aliased at the default zoom level. When I zoomed in they looked even chunkier. When I zoomed out, HaxeFlixel did it’s best to approximate what the lines should look like at a smaller scale, but that just isn’t what it’s made for. They ended up all deformed and jerky.

The next problem is that as soon as I drew more than, say, 5 branches on the screen, the game slowed to a crawl on my laptop. Now, my laptop isn’t the greatest, but it should be able to handle this simple thing with black and white graphics. The slowness was clearly my fault. Problem was, there wasn’t much room for me to optimize, seeing as there wasn’t much code yet, and it was only going to get more complex, graphically.

I was pretty disheartened at first. The next few days were spent in a kind of half-excited, half-frustrated daze as I considered my options.

What I ended up doing was throwing all the HaxeFlixel code away and going with pure OpenFL. Arbor is now much prettier and faster with its current anti-aliased bitmap rendering scheme. I’m pretty happy with it, and it has opened up a new set of options for me regarding the over-all look of the game.

And, of course, I’ll be keeping HaxeFlixel and all of its goodies in mind for the next (sprite based) game.


Anodyne is an pixelly Zelda-like for Linux, Android, Windows, iOS and Mac, which presents a compelling world and decent gameplay but falls into some typical bad RPG storytelling traps. This review is for the Android version, so if there are any differences between versions I won’t be mentioning them.

The first thing that happens in the game is straight out of RPG 101 class. You wake up, walk down a hallway, then some nutty wizard/elder, tells you the world is depending on you to rescue it. YAWN…

One of the things I like the most about Anodyne is the on-screen controller. In portrait mode it takes up about a third of the screen. It has a D-pad, an X button, a C button, and an Enter button. The enter button seems like a hold over from the PC versions, which makes the game feel a little bit like it’s running in an emulator. It doesn’t effect the game in any negative way, but sometimes emulated games run poorly. I think it would be better if Anodyne on Android tried to avoid that emulated feeling.

When you put your finger on the D-pad and move around, the pad “rocks” in the direction you are pressing. Also, a white glow appears under your finger. It’s a nice effect, and combined with the “aiming-dot” that appears in front of Young when he walk, you almost get the sense that you are actually using a physical controller.

There was a great moment near the beginning where you walk under a highway bridge and the screen gets very dark. I walked to the middle of the screen and I saw a dim figure coming up behind me. I moved around a little and the figure disappeared. I applaud the game for giving me the creeps in such a small amount of pixels. That is quite a feat. I’m sure it was mostly due to a lot of the game being slightly off kilter. I love those kind of unexpected moments.

Unfortunately, this off kilter feeling does not last. The game turns into a really fiddly puzzle.  You have to place dust in front of flying energy balls to stop them from hitting you. It’s not interesting at all. I beat the first boss and quit. There was no sense of  progression after that.

I’d like to say I played through the game, but at this point it feels like it would be a waste of my time. I’m sure there are much better Zelda-likes out there. Don’t be fooled by the interesting concept art and title, I would not recommend Anodyne.