Just a quick update: I fixed the download links for AI Wars and dm_mudanchee – due to a change in webhosts they went dead for a while.

Enjoy! :)

The last week or two I’ve been working on a 2D level editor. I can drag and drop images onto it to create free-form levels (beware, placeholder art):

It’s meant for a platformer game, but it’s fairly easy to use the output for a different kind of game. Like, say, a strategy game, or just as a title screen layout file.

On the right side, there’s the bare-bone UI: the layer selection and visibility toggle buttons, the delete-this-layer button, and of course a button for adding layers. The red lines are collision lines – I’ve experimented with that a while ago and it turned out to work pretty well, so I’m migrating parts of my collision-line editor/test program to this new editor. On the right side, you can(‘t) see a hidden layer. The blue lines are the grid – which can be toggled and it’s granularity can be fine-tuned. It’s not used for snapping yet, so it’s mostly there to give me some sense of place and size.

I’m still working on various features, but it’s already a useful tool. I wrote it in Python, using Pygame (for the rendering and input handling), pgu (for the buttons) and pywin32 (for the drag and drop support). It has taken me 4 or 5 days so far, a couple of hours each day. :)

The last few months I’ve been doing more and more with Python. While the games I work on are mostly written in C++, there’s still a lot of room for me to use Python. For example, when dealing with file conversions, data checking, automating processes, and so on.

Two weeks ago, I wrote a tool that packs smaller images into larger ones. I first prototyped the packing algorithm in Python and then translated it to C#, which I used for the tool itself.

Last week, within a few days, I was able to process, verify and preview almost 2000 files for one of our games, converting them from XML into a tight binary format, all packed into custom archive files to keep things easy for the file-system. I spent most of my time thinking about the file formats and the required checks. Writing the tools took little time.

Just today I set up a few automation scripts for one of our artists. I introduced him to SVN, but, considering he’s an artist, I decided to make things as easy as possible. I wrote a few batch files that took care of updating and committing the files he needs to work with, and another batch file for converting the art. That batch file calls a Python script that generates some information based on the new art, and another script that checks for new files, which are automatically added to SVN. All he has to do now is make art, click a few batch files and press a few Ok buttons.

I’ve also been using Python to prototype a collision system for a spare-time project and to solve some logic problems, as I recently discovered a site called Project Euler.net. Quite fun! Someone also pointed me at the Google Code Jam, that also contains some interesting problems. How about path-finding with portals?

In other words, I’ve come to like Python more and more. It’s still just one of several languages that I use and it’s not the best for every situation, but I do notice how much more productive I’ve become by embracing it.

I’ve been prototyping yet another game idea during the last few weeks. Since I’m now a full-time game programmer at Triangle Studios, I have less spare time to devote to game-development. Fortunately, less doesn’t mean nothing at all.

So here’s BulletEater. A danmaku/bullet-hell game. Except that you’re unable to fire back at turrets, so you’ll just have to survive the bullet patterns. Actually, you’re not completely defenseless: there’s an overcharge mode that allows you to eat bullets, which in turn adds to your score. It does cost you a life however, but lives slowly recharge so that’s simply a matter of surviving long enough. Eating bullets speeds up the recharge process a bit so you may want to save your lives for the really nasty situations.

These are things I’m still thinking about, as they make large bullet patterns easy score-fests instead. So I’m thinking about including laser-beams that can’t be eaten to control the difficulty and challenge some more. If you have any suggestions, feel free to share them.

Last week I finished dm_mudanchee, a map I started 2.5 years ago. I’ve probably worked on it for 6 or 9 months altogether, which means I had some big hiatus along the way. At some point I had even decided I wouldn’t do any serious level-design anymore…

Creating levels for games like Half-Life 2 can be a very labour-intensive process, especially when there’s a lot of custom content involved. But what’s especially painfull is finding out that your map just isn’t fun… after you’ve put in months of work. I’ve had that happen a lot of times, which often resulted in yet another unfinished, abandoned map.

That’s where I learned the value of planning ahead. dm_mudanchee, despite it’s irregular development process, is the result of proper planning, early playtesting and many more iterations – and sheer persistence, I suppose. When I started, I built a few style test maps: a cave filled with water, some wooden planks here and there, some more caves. I also built quite a few layout tests, that were extensively playtested by me and a few friends. After a few of these maps I settled on a design, which I then filled in, using the style test maps as a guide. 50 versions and quite a bit more playtesting later dm_mudanchee was done.

It’s actually amazing to see how many people don’t plan ahead. Keeping that in mind though, it’s not so amazing to see so many levels, mods and game projects fail.

Anyway, after finishing up that map, I got the hang of level-design again. So I started on another map. I’m still in the layout testing phase, but here’s a rough sketch that shows what I’m working towards (it’s the same tower, drawn twice): a small vtol launchpad, an outpost tower built on top of a rock, surrounded by endless swamps with occasional mountains and other outposts dotted on the horizon.