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 layed 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 gooing 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.