OK, so maybe it is, but if you're a programmer you'll know there's a certain satisfaction you can only get by automating some part of the development process. As Steve McConnell puts it in "Code Complete", if a programmer can do a job comfortably in five hours, or spend four hours and 45 minutes writing a tool to do it in 15 minutes, they'll choose to write the tool every time.

My tools directory is littered with quick, one off scripts I've written to get a job done, or other small applications I've downloaded. Today we'll be taking a brief look at my setup.

The language I use most frequently is Blitz Plus, so my development environment is tuned to making me more productive in it. My IDE of choice is Protean, which became a free product earlier this year.

The main reason I chose Protean was the excellent code completion support, as well as the project support. These two features alone have probably saved me hours worth of work. The standard Blitz IDE is a little clumsy for larger projects, and it was quite a hindrance.

I keep the Windows taskbar auto-minimised on the left of the screen. This helps when I have several windows open, and also maximises the amount of space the IDE gets. It's not a huge gain, but every little helps.

I also like the colour green.

My tools directory contains dozens of applications, ranging in size and complexity. There are far too many to list in detail here, so I'll stick to the ones I use most often.

• PHP – I use PHP for a lot of "glue" scripts, because it's quite easy to knock up a simple script to do something useful. My original build scripts were written in PHP, but I'm slowly migrating them to BlitzBuild. I've used PHP for all kinds of things, from generating code distributions to parsing source files for variables. I considered using Python for these tasks, but I felt more comfortable using PHP. It's not just for websites!
• pngcrush – A simple tool to compress png files a little further. Not really essential, but I'm still stuck in "this has to fit on a floppy" world so every saved byte counts.
• ResHacker – Blitz doesn't add much information to executables, so I use ResHacker to add a fancy exe icon, as well as resource information. It can be used from the command line, so it's part of my post-build script.
• Subversion – I run a Subversion server on another machine, and it's saved my bacon on several occasions. I use TortoiseSVN for the front end, because it makes life so much simpler.
• xsltproc – I've recently started using DocBook for documentation, and I use xsltproc to convert it into something pretty. I prefer running it on Linux, as it seems to run much faster.
• Kate – I use this for editing DocBook XML files, and it supports code completion and code folding. I sometimes dabble with XXE for DocBook work, but I find it to be overkill for most of the documents I work on.

As powerful as these tools are on their own, they really shine when joined together in a build script. At the moment, my Blitz projects have three batch files: "pre-build", "post-build" and "build-resources". The pre-build script is for auto-generating source files, and the post-build script takes care of adding resources to the exe and compressing it. The resource builder compresses sounds and graphics, processes any extra files (such as XML files that need converting) and creates all of the data files.

In the future, I want to move all of this into a single BlitzBuild script, as I feel the three batch files are a weak link in the build chain. I'd much rather run a single command and have the whole process work automatically, than run different batch files. I also want to add support for different configurations. This will allow for quick builds that don't create resources, as well as special debug builds that add extra information to the exe.

What tools do you use in your development process? Do you have any novel uses for existing tools? What single application saves you the most development time?

That brings us to the end of our journey through my childhood dreams. Will any of these ideas ever see the light of day? Let's hope not.

Do you have any ideas from your childhood you'd like to share? What ideas are you proud of, and which ones make you cringe?

You could have to clean up this kind of thing for a living.

So far this has turned out to be a huge time saver. Instead of altering code every time a new resource should be loaded, the application will scan the resource directory and load resources as required.

The current system uses XML to define which resources should be loaded. XML makes the whole system nice and flexible, and it's easy to read and modify. Every resource used by the game can be loaded using this system, and each resource file has a namespace to avoid naming collisions.

Future improvements will add a "load on demand" system and a resource cache to help lower memory consumption.

The standard Blitz debugging system is somewhat lacking. It does the trick if you're running your program from the IDE, but once it's in the wild it's useless. Naturally, I had to write my own system.

The logging component is quite simple, uses XML for storage and XSL to make it look pretty. It's not particularly powerful, but it's useful for getting system information and tracking function execution times. So far it's saved me from a few problems, and helped me to smooth down a couple of time consuming functions, so it's powerful enough.

I created a Doom style console that allows the user to manipulate game objects using a command line. It can also display internal information that can be useful for debugging purposes. It's the sort of component that isn't vital, but is super handy when it's there. Just the ability to spawn objects manually is worth the time it took to create.

This is easily the most time consuming thing I've worked on, and it's also the most complex and frustrating. It's still not finished, but it's usable.

The main idea is to have a "pluggable" object that will be given different behaviours. At the moment, each object is made up of States, and each State is made up of Triggers. These triggers fire "Actions" when they are activated. For example, a treasure chest would have two states ("Opened" and "Closed"). A chest with the "Closed" state would have an "onInspect" trigger, which would run several actions when the character inspected it. These actions could include giving an item to the character, as well as playing sounds, animations and changing the state of the chest to "Opened".

BlitzPlus doesn't support true Object Orientation, so the whole system has been a bit of a battle. I've been using the "Blitz Virtual Machine" to script behaviour, and it's working nicely so far.

To save time, I created an automatic build script that will build resources using a simple script. At the moment it's a series of batch files and smaller tools, but I've started writing a Blitz builder that's loosely based on nAnt.

The Blitz Builder uses an XML script to build the application and its resources, and each script can have various configurations. It's quite simple at the moment, but it's being built in a flexible way so new commands can be added easily using plugins. It also has much better output, so the full build process can be built and timed. No prizes for guessing what file format the output logs use…

Other tasks I've been working on include designing a nice website for the project, trying out various project management tools and cleaning up some of my code libraries so they can be released at a later date.

First of all, you need to open the "Services" manager. You can do this either by selecting "run" in the start menu and typing "services.msc", or going to "Control Panel", then "Administrative Tools" and selecting "Services".

You should see a window similar to the following:

Select the item named "DCOM Server Process Launcher", right click and select "Properties". This should bring up the following dialog:

Select "Automatic" from the "Startup type" drop down, and then select "OK". Close the service manager, and then you'll need to reboot.

Once you've rebooted, you should be able to repair your Office installation. Go to the control panel, select "Add or Remove Programs" and select the entry named "Microsoft Office Professional Plus 2007 (Beta)". Click the button called "change", and then select "repair" from the options. This should then start the repair process. It took quite a while for me, so you might want to make a cup of tea or knit a jumper whilst you're waiting. Once it's finished, it'll ask you to reset. Once you're reset your machine, everything should be back to normal. Phew!

Update: Jack and Mike have both found that giving the document file a shorter name can solve this problem too. Cheers!

Updated 2: Al Simon also encountered this problem, which was caused by a corrupted file. You can view his solution in the comments below.