Go to content Go to navigation Go to search

Level Design By Tub

Recent Articles


26 February 07 · Turnpike in a week

I've just recently had an interesting little project fall into my lap. Well I volunteered for it in part but due to project time constraints I've taken over the whole thing. Not that I have much time myself. A bit over a week.

Before anyone asks: No, that doesn't mean that urban terror will be released in a week. It's not that close. Yet.

So anyway all this week I'll try and post about how the update for one of the communities most loved maps is going. Turnpike.

I've always wanted to do a diary thing, but it's hard to do one over a long period with a lot of changes. Even harder to do one when your still trying to work out what direction you want to take. This has a short timespan and fairly obvious direction so it should work well I hope.

Comments [4]

10 January 07 · Village Dropped

Yes you heard right. Village. The last map to survive from the very first day of urban terror is getting dropped from the next release.

I've never been entirely happy with village2. It gave up good TS gameplay for some average ctf and bomb mode play. Not exactly the greatest of trades I could have wished for. The map also had the problem of being too open, and the lack of tactical features made it dull to play.

All of those deficiencies could be fixed with a rebuild, but that's not something I've had the time too do recently. I've been waiting for a couple of years for the villageish map, Austria to finally get released. I'd really like to see how the community responds to Austria, and 4.0 before committing to the kind of work village would take.

But, if 4.0 does turn into the kind of release we all want it to be (and by all appearances it's going to be great) then I'll try and find time to get it done for a later release.

Comments [4]

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.

Comments [1]

30 July 06 · City of Delusion

There are a lot of “best practices” in level design that simply aren't documented anywhere. In retrospect most of them are dead obvious, but all too often I'm busy working on other things and don't notice the forest for the trees.

I mean most level designers realise that it's quite important for lights to appear as though they are coming from a real light source instead of just floating in space. But something I've only just come to realise myself is how jarring it is when a sound originates from the middle of nowhere.

So yeah, I was messing around adding sounds to Algiers today and it struck me how wrong things sounded. Up to now I have been placing most of the sounds in the centre of an area so that sound would carry to the edges of the space; but in retrospect that's a pretty poor way to do it. Sounds should really be placed in much the same way as that lights are: Either coming from a particular source inside the map, or seeming to originate from somewhere outside of the playable area.

So I've started going back through Algiers, fixing all the sounds following a simple rule: Players should never be able to touch a sound entity. For things like music I've placed the sounds above the buildings so that it seems as though the sound is coming over the building from the next area. The other sounds, like the rustling of palm trees I've placed where they would occur, among the leaves of the palms.

As I said it's something that seems like a pretty basic idea. Until now it's an idea that I've been completely oblivious to.

Comments [1]

11 July 06 · BspShoe

BspShoe ScreenshotThis is an application that lets you look at a .bsp file and shows you all the assets it uses. It displays all the sounds, scripts, textures and farboxes used in a map. Works for Quake3 and ET.

Download - BspShoe 1.0.1

If you find any bugs or have any feature suggestions please let me know.

Also: This requires Microsoft .Net 1.1 or 2.0


A month or so ago I was chatting with some of the SID/FS team on IRC and BladeKiller mentioned how much of a pain it was to get maps ready for a release. The maps have stacks of assets and unless you load every map and spend a while playing it it's very hard to tell if everything is together correctly.

I was also interested in using the application to look at what files other maps used. In a few cases I've been playing a map and seen a shader affect I like, but when I've gone to look for the script I've found it almost imposible to find. The shader could be in any of 180 shader files. So this app would make that much easier as well.

So with a few pointers from Twentyseven I started working on what is now BspShoe.

Comments [1]

24 February 06 · Starting Points pt. 3

This series was only supposed to be a single article, but I couldn't fit everything I wanted into it. So it sort of expanded into two. Well now that I've done the second article I don't really want to stop. I think what has happened is that once I set down where I started, the rest of the process came into my mind just, begging to be written down. So as long as it lasts, that's what I'm going to do.

Originally I wanted to run through the various major starts that people generally use. I mean there's a great deal of equally good approaches for constructing a map. Probably as many approaches as there are mappers and different situations. But yeah, once I got fixated on trying to turn what works for me into a process I sort of gave up that original idea :)

So for the rest of these articles I'm going to do sort of a personal “best practices”. My main hope is that while it's going to be far from a mapping bible, it can help people get past those, “so what do I do now” moments. And if nobody reads it, well that's ok. Maybe it can help me get past my own, “so what do I do now” moments :)


9 February 06 · Starting Points Pt. 2

As a case study lets say my grand idea was a train station in the middle of an industrial area. Sure it's been done before, but hey, it's my vision, don't knock it.

So the absolute first thing I do is try and picture the scene in my head. Ok, so there's a couple of rail tracks with a large crane laying down steal I-beams onto a flat car. On one side of the tracks is an old waste management centre. It has a couple of large cylindrical reservoirs on one side with pipes leading into the building. The thing is to imagine a place that you would want to play in.

Things to consider:

Things to avoid:

The important thing is that the place leaps out at you as fun. You should be chomping at the bit to see how this thing looks and plays in-game. If it doesn't pass that test then there's no point starting to build it in an editor.

At this stage it's quite easy to get fixated on an idea which goes nowhere. It can be quite hard to move on to something else. Still, it's easier to change things at this point than had you actually built it in an editor. And often good ideas will simply come at you from nowhere. It could be while your laying in bed or travelling to work.

Now being able to picture something in your head is quite a talent, not one I'm particularly good at, but it does seem to get easier with practice. To alleviate any form of 'mappers-block' I try to gather as much media as possible to get ideas from. That means photos of course; but I also try to go back and play games and levels that feature similar areas. As I'm doing all this I also attempt to sketch parts of what I'm imagining. I'm horrible at drawing but it does help to nail down details and serves to jog my memory latter.

Only once I've got a solid image of the first area is it's time to plonk myself down in front of the editor and start hammering out a level. Note that at this stage I couldn't give a toss about the layout. All I want now is to build an area that matches my original idea.


22 January 06 · Starting Points Pt. 1

There are a lot of ways to start a map. A lot of them bad. In fact it seems the most naïve way of starting a map is often the best. The naïve way being where you just come up with a single good idea, be it a image or game play element, and run with it. Throwing brushes and textures at the editor until you reach a stage where the map matches your vision.

That's how I started Abbey. With a simple idea. Only a single movie scene; but the feeling and image of the scene was easy to expand into an entire map. That's why I like the naïve way. It generally starts with a strong feeling for what would make a good map.

I find if I start the map from a layout design it becomes too easy to concentrate only on the technical aspects. I concentrate on getting the layout into the editor instead of making an exciting map. I spend my time ticking off tasks while ignoring aesthetics. That's never a good thing.

I guess what I'm trying to say in a round about way is that to create a really good map you need a strong vision. I know that sounds obvious but often I start maps with the idea that it would be cool to do a certain map. It is never enough. I need to get a feel for how it would be to be inside the map so that I can evoke that feeling in players. Otherwise the map just becomes bland and its hard to come up with ideas. Unfortunately, I've seen a lot of people with cool layouts get stuck in that same quagmire, and often the map just becomes a hodgepodge of random ideas.


19 January 06 · Turn A Square

I seem to have a problem putting my mapping thoughts down onto paper. Albeit papper of the digital kind. It's not that I have an issue coming up with ideas for articles. In fact I have quite a backlog of ideas I need to write down. It just seems that when I sit down in front of a computer everything seems to leave me. I think partially it's because when I sit down in front of my screen there are so many other things to divert my attention: software projects, mapping projects, weblogs, games, socialising etc. Sometimes I'm amazed anything gets done by anyone connected to the net. What with several million people pursing m4d l3wt on WoW.

Anyway one of the things I have been thinking of while not sitting in front of a screen is the nature of design methodologies in level design, or the lack thereof. I'm not talking of technical tutorials so much. That side of things is well covered. But more so the kind of articles that explain the aesthetic and gameplay options and patterns. It seems strange that in a community as well connected and multi-skilled is our own that there isn't more information on these topics. At the moment most knowledge is gained through imitation and trial and error.

Fortunately weblogs have the opportunity to be a major influence on the direction of level design literature. Unfortunately most designers seem to comment on what they are doing, and not how they are doing things. That's quite unlike other communities such as the software industry which takes entierly the opposite direction. Still the area has seen a lot of growth recently. Especially in the HL2 arena, and I have a feeling that the current trickle of articles will expand into a flood very soon.

Of course all the blogs in the world can't replace creativity, nor would I want them too, but I think more and more, the discussion will prove to be an important base for the current community.


5 January 06 · Climbing up the walls

The long awaited site update is finally here. Commenting is enabled, the design has been tweaked and I have some much needed admin capabilities.

It all started a few months ago. I felt a growing need for comments and a better way to manage the site. At that stage I started looking at weblog/CMS software. Most of the stuff available either offered restrictive design templates, or was so complicated it required a masters degree in on-line collaboration software. In either case the software expected the user to conform to the way it thought sites should be designed. Not the other way around.

What I wanted was something where I could take my current site design, html and css. Then with a few definitions tell the CMS software where I wanted the articles and how to format them without having to make major design changes.

Not finding anything capable I started writing my own simple CMS. After a few weeks I had the basics going: mainly comments with some admin. I then managed to stumble upon TextPattern. I can't remember where I found out about it, but I think a button for it was lying inconspicuously at the bottom of some random blog. The name just jumped out at me and I had to have a look.

Anyway TextPattern was exactly what I was looking for. It was for all intents exactly what I was in the middle of writing! So I dropped the code I'd currently written and converted the site to use TextPattern.

Comments [2]

Previous Next

Level Image