Sweating the small stuff

Posted on 24 February 2009 by Jeff Ward

I have a co-worker, Darius, who is creating a game for a small game system called the Meggy Jr. Watching him work on this, I was impressed with the tools that he came up with. He’s not a (really) a programmer, but still somehow can make tools that serve his needs pretty well. I’ll let him explain:

This is the level editor I’m using for a roguelike game I’m building for my Meggy Jr. The level is just a 16×16 bitmap array. Each cell of the array is a different color, and each color is a different object. 6 is blue, and it’s a wall; 5 is purple, and it’s a door.

A level editor in Excel

I built this level editor in Excel. I set the cells to be 20×20 pixels, big enough for me to work with conveniently, and I used conditional formatting to map the background fill colors to correspond to the Meggy Jr’s color mapping. If you look to the right, you’ll see that I’m using CONCATENATE statements to pull together the numbers into the bracketed statements that I literally just copy and paste into my array declaration in code. With this system I can make a level in a minute, and drop it into my code with a couple of mouse clicks. It only took me five minutes to build this level editor.

I’m always pulling crap like this: I love using Excel to abstract things out and then generate code for me. I would never do it for a big project, but for my own hacking it saves me a ton of time.

As tools developers, I think we occasionally forget that a real, actual, useful tool can be made in minutes using something as common place as Word or Excel, given the correct understanding of the problem and its simplest solution. We’re always quick to jump to the custom solution, using some complex API, even when there’s something that would work better and faster right in front of our face.

This is especially important to understand when you’re a very small shop that can’t afford a second programmer, much less a dedicated tools team. It may feel dirty, but you should always at least think about taking advantage of the fact that Excel not only has it’s cell equation system, but an entire programming language and forms system behind it.

Now, this partially goes against my previous post about ad-hoc tools teams, which I still think are a bad idea. The key difference, for me, is a question of team use and support. I consider these tools similar to one-off scripts or small prototypes. They’re find when teams are small and everyone is on the same page. Once things get bigger, by all means, still use Excel where it makes sense, but make sure you’ve got a rock solid team supporting it.