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.

Planning a Prototype

I found this nice article about prototyping:

I think I’ll start this Arbor game by making a prototype. I’ll just try to make one branch with a leaf that you can click and drag. You draw a curvy line while you’re dragging. After you release the drag, the branch will grow to the shape of your line.

That bit is the only part of the design that seems difficult. If I can get that done, the rest won’t be too much of a challenge, besides making it look nice, of course. That’s always the most frustrating part.

Game Designing: Arbor

It has to do with trees.

Sorry for the blurrified picture. I don’t have a scanner handy.

In case you cant read it, the important text says:


  • Collect nutrients
  • Use a lot of water
  • Use little nutrients



  • Collect water
  • Use a lot of nutrients
  • Use little water.


The main goal in the game is to grow a tree.

On a micro level, you grow the roots and branches by pulling on leaves (on the branches) or little nubbins (on the roots). The longer a branch is, the more nutrients it collects, and the more water it uses. The longer a root is, the more water it collects, and the more nutrients it uses.

There are two ways to lose:

  1. The tree runs out of either nutrients or water. Go too long without nutrients or water and the tree dies.
  2. The tree falls over. Does a tree falling make a sound if no one is there too hear it? If you put too many branches or roots on one side, you’ll find out.


You have a score that is based solely on how big the tree is. Just try to grow the biggest tree you can. You win by getting a high score and then bragging about it on a social network of your choice 😉

The game will be very slow paced, but hopefully still challenging.  I imagine it being kind of like Eufloria.

You can grow the tree any way you like. Make it tall, make it wide, make it gnarled and twisty, make it look like a Squirtle, whatever. Once you have something cool, you can take a nice picture of it and share it.

I might make something bad happen if you have more nutrient or water than your tree can handle, not sure yet. I kind of like how simple it is now.

Change or Tween a Sprite’s Color on Haxe NME HTML5 Target

Haxe is a write once compile everywhere (some might say “debug everywhere”) language and NME is a Flash-like library for drawing graphics with Haxe. I’ve been using it for a few weeks and I like it. The language has some nice features that make it very familiar to me.

For my 2012 Github Game-Off game I’m using Haxe and NME. I ran into a problem while trying to fade a rectangle from one color to another. After asking a quick question on haxelang got an answer. Here’s how to fix it.

If you’re using the HTML5 target, you might notice that you can’t use Actuate.transform() to change the color of a sprite. That’s because the canvas renderer that NME uses, Jeash, hasn’t implemented it yet, dang. Here’s what I did instead.

public function new(itemInBox:Resource) 
  resource = itemInBox;
  boxWidth = Lib.current.stage.stageWidth * .08;
public function changeBoxColor():Void 
  var boxColor:Int = 0;
    case ResourceType.Lithium:
      boxColor = lithiumColor;
    case ResourceType.Plutonium:
      boxColor = plutoniumColor;
    case ResourceType.Uranium:
      boxColor = uraniumColor;
  fadeBoxIn(.5, 0);
private function drawBox(fillColor:Int):Void 
{, 1);
    (boxWidth / 2) * -1,
    (boxWidth / 2) * -1,
  this.alpha = 0;
private function fadeBoxIn(speed:Float, delay:Float = 0):Void
  Actuate.tween(this, speed, { alpha: 1 } ).delay(delay);


  • First, I draw a box, “drawBox(defaultColor)”.
  • Next, I fade it in, “fadeBoxIn(7)”.
  • A bunch of stuff happens outside of this class.
  • “changeBoxColor()” is called from outside.
  • I pick a color based on “ResourceType”
  • Then, I redraw the box and fade it in again.


You may notice that I never graphics.clear()’d the original box. That is so the new box color will fade in smoothly over the old box color. If I cleared the old box first, you’d see it disappear and then the new box would fade in.

Yes, now I have two rectangles instead of one. Unfortunately, that takes memory. I hope Jeash implements Actuate.transform() soon.

Host your high scores on

Check out this example: was apparently just released this morning. It looks pretty awesome. Basically, you write a script in Lua, put it on their server, and they give you a nice friendly URL to access the script. It could be very useful.

If you go the free route your script and data get wiped after 7 days. To have them host it indefinitely it’s about $5 a month.