02.24Sweating the small stuff - 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.
When working on a 2d gameplay prototype engine at EA (one that was planned to be used for at least a few months, so it was worth investing a bit in a bell/whistle feature like this), we set it up so that we could use Photoshop as the level creation tool.
Each layer or color could be assigned meaning in an accompanying text file — you could say that a red pixel on layer 2 was an enemy, and a green pixel on layer 5 was a poison trap, for example.
I’m a big fan of leveraging existing tools, especially for quick and dirty solutions. It turns out that Photoshop is already a really polished, stable program that most game developers already know how to use. Some relatively simple image parsing code, and we didn’t have to worry about bugs in the tool, teaching designers a new program, etc. Saved a bunch of time and let us focus on actually making levels and learning about our game.
February 24th, 2009 at 9:24 am
I agree that when you’re a small company and are rushing out a product made by a small team tools such as those can be real life savers. I wouldn’t recommend hacking up things like that though for a full scale big money making game engine, else you may end up with a bunch of non-scalable tools for your current and future needs and end up having to rewrite them all from scratch instead of iterating on them.
February 24th, 2009 at 6:11 pm
Another cool Excel trick:
http://www.acdcrocks.com/excel
I read an article about 12-18 months ago where someone built a 2D, possibly 3D rendering engine in Excel. All the math to do it was done with Excel formulas, and the rendering was done in 2 different ways. You could shrink the cells to 1 pixel in size and color them, or use VBA to create the needed graphics objects. I can’t find it on Google now but there was a video of it and it looked pretty neat.
February 25th, 2009 at 4:42 am
Great!
Send us a link once your level is ready!
February 25th, 2009 at 4:46 am
I will give it a 5/5 for creativity. If you are not a programmer and are trying to make a game, use whatever you can to make it happen. Then a programmer can pick up and make a tool so more people can use it. Already I can see the C++ data structure and the UI for this tool…
February 25th, 2009 at 6:12 am
I think the key thing to consider is this: how likely is is that your level designs will become complicated enough to outgrow a simple tool like this?
In Darius’ case, it’s extremely unlikely, as Meggy Jr. development is likely to make increased design *complexity* a bad path to go down, if only for reasons of memory management, as we’re already finding out.
Of course, the other, similar, question, is: is this game really a prototype? Is it just-for-fun or just a proof-of-concept or is it likely to turn into a full-scale game, with multiple editors, etc? That, of course, can influence the decision as well.
February 25th, 2009 at 6:19 am
For something like that, Tiled would be perfect.
Quite stable, reactive community and output in xml.
February 25th, 2009 at 7:04 am
Lionel: problem is, Tiled is too complicated for my needs. It would have taken me ten minutes to download and learn how to use, as opposed to five minutes of making this spreadsheet. Plus, Tiled generates XML — my tool generates the data structure for my code directly. I could always write a converter, but again, now we’re talking ~30 minutes of setup for Tiled versus 5 for Excel.
I’d actually never heard of Tiled and looking at it, I might use it for future projects, but as Jeff said, for this project Tiled is just overthinking things.
February 25th, 2009 at 7:36 am
Cudos to your friend!
I especially like doing the formatting of the array as an equation in Excel too. As a long time coder, I probably would have just dragged the .csv file into emacs or something.
February 25th, 2009 at 8:28 am
I did just that for a 2D Videogames class I was taking. It saved me a lot of time.
February 25th, 2009 at 8:35 am
Working with a real tool chain for data structures intended to be used in a Windows (or any sufficiently sophisticated programming environment) is much different than designing something for a micro environment.
I’ve spent the last 4 years programming 8-bit micros in assembler. I’ve used Excel to create all sorts of pre-baked data tables. Most of it only has to be done once, and the data has to be formatted in such a way that it can then be popped right into the code. It doesn’t change, it doesn’t need to be dynamic, and writing a tool just to do it would take longer than needed.
The smaller you constraints are, and the tighter the data, the less you need fancy tools to create it.
February 25th, 2009 at 8:59 am
i’ve always been fairly impressed with what you can whack together with the ms office suite. you can knock together something that ties in with an office’s workflow fairly easily. and with the forms it can look like ‘a real app’.
February 25th, 2009 at 9:08 am
It is also frighteningly simple to over-think tools sometimes. Once I had a massive CSV file that I needed to convert into XML for importing into a database. At first I started writing a little command line tool to do it. As I was staring at the file in Excel to make sure I was doing it right, it dawned on me to just generate the XML tags using formulas. Even selectively excluding tags when data wasn’t present. What was going to take me a bit was done in less than 30 minutes.
What I like about it is that I’m sure just talking about how Darius is using Excel here will give all of us ideas about where we might simplify tools in addition to how we might make better tools. I’m actually impressed to see the conversation between this blog and what Darius has been doing over with his Meggy Jr on Tinysubversions.
Great post.
February 25th, 2009 at 10:52 am
My current level editor is Inkscape. Vectors for the win!
February 25th, 2009 at 11:57 am
I believe the text needs editing. 5 is blue and 6 is purple.
February 25th, 2009 at 12:29 pm
This is also useful for sys/ net admin work… changing a range of cisco vlans or enabling/ disabling many ports is done quickly with “=CONCATONATE”…
February 25th, 2009 at 1:11 pm
doi: Gamasutra article about excel as a 3d engine.
http://www.gamasutra.com/view/feature/3563/microsoft_excel_revolutionary_3d_.php
February 25th, 2009 at 1:12 pm
@terr: talk about fools with too much time on their hands.
February 25th, 2009 at 2:08 pm
it could have been done even faster – in 0 minutes. In other words, no need to modify excel to build a bitmap when you already have a bitmap editor. Just read the bitmap in directly.
February 25th, 2009 at 2:46 pm
Lol, you noted that it may look dirty, but to me it looks incredibly elegant. The simplest solution is best, not the most “correct” one. After all some dude working in Java or something would define the correct one as generating it using some kind of complex SWING app generating everything from XML.
February 25th, 2009 at 4:02 pm
Careful, Darius. A few more tools like this and Jeff might pressure you into becoming a contributor to the blog.
Seriously, though… now I’m just torn on whether I should learn Tiles or Excel next… Tiles is probably faster and more effective for 2d level-design purposes since I don’t know Excel, but Excel is useful for so many things, as this post and in particular the comments have made clear. (good point about Bradan about sys/net admin work)
February 25th, 2009 at 5:57 pm
Ok but the array already looks like the level… only difference is that it isn’t coloured in.
February 25th, 2009 at 7:15 pm
Great article. A lot of people overlook the creativity of programmers. One day history will show the artistry involved in solving complex computer programming challenges and coming up with more efficient ways of doing it.
February 26th, 2009 at 10:36 am
[...] Sweating the small stuff I have a co-worker, Darius, who is creating a game for a small game system called the Meggy Jr. Watching him work on t [...] [...]
February 26th, 2009 at 4:03 pm
[...] can go even simpler, using a spreadsheet as a level editor. The Toolsmith blog has two different posts on using Excel for this purpose. Over at Coderhump Ben Garney talks about using [...]
May 24th, 2009 at 1:32 am