I’ve begun texturing some areas so I definitely feel like my brain is satisfied with the general structure at this point. Looking forward to finishing this layout!

We’ve moved just over 700 brushes now and I think the end is in sight. As I said, this level won’t be huge or complicated – it’s just an experiment.

As an added bonus, I think I see what I want a large part of the level to be, thematically speaking. I also have a large chunk of the player path worked out in my head. Just gotta lay down the brushes.

You’ll also see some textures in the newer shots. I’ve decided that I’m going to texture any entities that are in the level. This allows me to see at a glance what is interactive in the level. This is having a cool side effect where I find myself wanting to add more entities because the area seems too static. Even if it’s busy work, it’s always cool to see something moving rather than a completely static environment.

266 Brushes

When I was a younger man, this worked out alright regardless. I would have enough energy and focus that I could detail out a map as well as develop the layout and restructure things (aka throw away work) as I needed to. I didn’t care. These days, I care.

So here’s what I’m going to do. I’m going to start with this WAD file that I created:

This is what I call my “blueprint” WAD. This contains the basic texture shapes that most Quake WAD files use (including the case where you rotate them 90 degrees, of course). My plan is as follows:

1. Lay out the level in it’s entirety using the blueprint textures, focusing on flow and monster gameplay.
2. Add a minlight and a sunlight. Tweak the sunlight until it gives the level the look that I want.
3. Add extra geometric detail and hot spot lighting sources. This will probably also be the stage where I start to apply real textures since lighting and it’s interaction with the textures becomes important.
4. Remove the minlight and add small fill lights where necessary.

This is the basic plan but things may change – we’ll see! For now, I’ll update fairly regularly with the status of the level and where I’m at with it. This is where we’re starting from:

I’ve also refactored the input code so that it’s very flexible now. I’ve changed the default controls for LevelEd to more closely match UnrealEd (which is what I use all day at work). This makes it easier on me and now I can add alternate control schemes without too much trouble since it’s all nicely abstracted.

The new input code has allowed for some nice features like allowing easy zooming in the texture browser. It works just like it does in the ortho viewports!

Remember how I said that LevelEd was broken under Snow Leopard and I wasn’t sure how to fix it? Right, well, it turns out that the problem is that I had the renderer running on a thread but there were multiple threads making calls into OpenGL. This causes major problems, including Kernel Panics (hard lock on a Mac).

So once it dawned on me that the threading was probably at fault, I put in an NSLock to control access to the OpenGL drawing routines and now the editor works again.

What I don’t understand is – How did it ever work on Leopard? Why does Snow Leopard expose this problem where Leopard didn’t? It’s either software gremlins or maybe Leopard had a much more relaxed approach to threading or something.

At any rate, work can now continue on the endless project known as the ToeTag Editing Suite.

So I blame Apple for whatever they did to break my editor. I blame myself for not being smart enough to deduce what the problem is and work around it.

Blame for everyone! But at least it’s pushed me to realize that I need a break from coding. Now to push some brushes around…

Flexibility

It’s really nice to work with something this fluid and dynamic. For example, variable length argument lists are an absolute breeze in Python. Check this out:

def myFunction( *args ):
    print len( args )

    for arg in args:
        print arg

That’s it. I can call myFunction with any number of arguments and it will “just work”. I LOVE that. Setting that up in C++ is such a pain the ass by comparison.

Memory Management

Something else I’m really digging so far is the memory management and I think it’s time that I came clean on this issue. I can now freely admit that I can’t be bothered to work in a language that doesn’t have garbage collection. I just don’t have the time or the patience. I want to write code that does productive things, not code that goes through gyrations trying to clean up after itself. It’s 2009, you need to provide garbage collection or I’m not using your language.

Learning By Doing

I learn best when I’m doing rather than reading. I started out reading a couple of books on Python and while that helped me establish a baseline of knowledge I find that I really learn best when I’m trying to write something for real. Just this morning I’ve picked up how to do static member functions, variable length argument lists, and gotten a much better understanding of how a Python program is structured.

Back to the doing and learning…