10 August 06 · On the other side

I hadn't really touched an editor since February until the last couple of weeks. Since then I've been mapping a fair bit, finishing off some stuff for the next Urban Terror release.

Most of the stuff I'm doing is just fixing minor details and small bugs. For me this is generally a process of making a small change then compiling and evaluating how the change went. A classic feedback loop. But this feedback loop has a pretty major problem. The compile stage takes way too damn long. In fact I'm writing this blog post in the middle of a compile, that's how long it takes.

This whole waiting thing eats up a lot more time than simply the compile time. While the computer is doing its thing I tend to surf the web or find another activity to fill in the time. That's fine by itself, but what generally happens is that I'll get engrossed in this other activity and not come back to what I was doing until well after what I was waiting for had finished. Worse than that, I'll forget what I was doing in the first place.

I was thinking about this at work the other day in regards to the program we're building. Lets say there is a search that takes between 10 and 20 seconds to perform. That 10 second difference may not seem like a great deal, but if that's the amount of time it takes for someone to decide to do something else, like get a coffee, then that's a huge amount of time that's going to be wasted.

Apart from simply wasted time I think there's probably a larger issue at stake. An idea that's floating around the software development community is that long processes seriously inhibit creativity and innovation. The basic idea is that if a small change is going to take a long while to take effect then we as developers become very adverse to making changes that could potentially break or upset things. So instead of trying to come up with creative and interesting ideas we become more concerned with breaking existing things. That's a very bad state to be in. Especially in a creative endeavour such as mapping.

Some new level editors have improved in this regard with near instantaneous feedback, but the majority still have horribly long compile times. I don't expect that to change overnight, but it would be nice if editors included features to make it easier in testing small parts of the map. For instance I think it would be damn nifty if I could tell the editor to clip the map to a certain size and only compile what is inside of that (using a box as the map bounds). Or maybe it wouldn't clip the map, but just ignore the entities outside of the box.

There's a lot of work that our tools should be doing, that we end up having to do ourselves. Anyway, my map finished compiling some time ago. Time to do some more testing.