Browsing Category: Software Development

There are a few fundamental truths when selling things online. The first is that you need visitors to your website. The second is that you need those visitors to buy something. Anything else they do, such as blog or tweet about you, is just a bonus.

A lot of times people concentrate on getting traffic, instead of on obtaining quality traffic.

This article contains most of the traffic generation techniques I’ve used in the last few years, along with some statistics on how well they perform. Naturally, your results may differ from these, but they’re a good starting point for evaluating different methods.

All statistics are taken from an 18 month period (September 2007 – February 2009) to give as large a sample size as possible. There are nearly 1,000 different referrers for this period, so these statistics are certainly not 100% accurate. They do give a good picture of what works, which is the important thing.

Anyway, enough with the disclaimers. Each table contains four columns:

Pages Per Visit

This is the average number of pages a visitor looks at. A higher number means they look around your site more, so keep an eye on this number.

Adding relevant links to the bottom of pages, or sprinkling them throughout your content can help. Be careful not to add too many links though, so you don’t distract visitors from downloading or buying your product.

Time on Site

The average amount of time a visitor spends on your site. Again, higher numbers are better, as it generally means they’re reading and not just skimming.

Bounce Rate

The bounce rate is the percentage of visitors that leave your site after a single page. For example, a visitor who enters your homepage and then types another link in the address bar without following your links has “bounced”. The lower this number, the better.

Download Rate

This is from a goal I set up in Google Analytics to track downloads. A lot of my sales come from people who buy from within the demo, so the higher this number the better. If a source of traffic doesn’t produce any downloads, it’s a sign that I’m advertising to the wrong people.

As you’ll see, there’s a big difference between the best traffic sources and the worst. The most traffic to sodaware.net comes from search engines, but search engine optimisation is a big topic that I wanted to avoid, so this article concentrates on sources that are easier to control.

Paid Advertising

Google AdWords

This is one of the easiest ways to buy traffic. All you have to do is write a short textual advert about your product or website, and then target keywords that people search for. It’s quick to set up, and you know visitors are looking for what you’re offering because they searched for it.

On the flipside, there’s a lot of depth to AdWords, and it takes a long time to get really great results. Throwing down a few dollars is only the start, and you’ll lot of your time will be spent on optimising your campaigns and weeding out underperformers.

Project Wonderful

Project Wonderful is even easier to use than Google AdWords. Create a graphical button or banner, select the criteria for sites you want to advertise on and you’re away.

Project Wonderful has the advantage that ads are extremely cheap, as you pay per day, not per click or impression. It’s a good way of getting lots of hits, and the campaign option makes things even easier. However, it’s quite easy to spend a lot of money and end up with little to show if you’re not careful.

Manual bids that are tailored to each site you’re bidding on seem to work the best. They takes more work, but the responses are generally higher.

Below are stats for the top three bids I ran.

Text Link Ads

According to Text Link Ads, the real power of this method comes from the increase in search engine ranking for your site. They recommend you leave your ad running for several months to evaluate it, as search engines take a while to update.

Over a five month period, I saw no change in my ranking. Having said that, I was trying to rank on very competitive terms, so it may be better for niche phrases instead.

These are statistics from the sites that ads were placed on. As you can see, the links themselves didn’t bring particularly good traffic compared to other methods.

Free Advertising

StumbleUpon

Although you can pay for Stumbles, I’m putting it in the free category as you can get good results without paying. Stumblers generally fall into two categories: People who will stay and read, and people who will leave within a few seconds. This dramatically skews the visit time down and bounce rate.

StumbleUpon brings in a big spike of traffic at the beginning, and quickly tales off after a few days. It continues to bring in visitors over time, and sometimes you’ll get secondary spikes. There’s also the chance that visitors will stumble your other content, leading to more spikes.

For the main page, the were quite poor, but for articles and resources it works much better. Your best option is to add tips, hints or guides to your site and have them stumbled.

Articles about unique qualities of your product will perform better, as long as you go easy on the sales talk and concentrate on writing something of value.

Article Marketing

This is a simple technique, but it can have good results. The process involves writing articles that target certain keywords. Each article will contain a link to your site in the article footer. This article is then submitted to article directories, which generally rank high in the search engines. For example, if you’re selling a solitaire game you could write about tips for playing the game and include a link at the bottom of the article.

It may sound a little bit spammy, but it isn’t if you provide value to your readers.

So far this has been one of the best methods of traffic generation I’ve used. It takes effort to research and write your article, but the traffic quality is extremely high. An article I wrote over a year ago still sends a good amount of traffic which converts extremely well into downloads and sales.

Article marketing is a topic I’ll be writing more about in the future.

Blog Commenting

Find a blog that relates to your topic, and make a relevant comment that contains a link to your website. As long as your comment is useful and the blog gets a reasonable amount of traffic, you’ll get visits. Depending on your contribution, you may also develop a relationship with the blogger which can bring more traffic.

The first result in the table below is the result of a single trackback I made three years ago. It’s brought several hundred visits (and still brings in a dozen or so a week), but the traffic doesn’t convert. This technique works much better for getting blog readers rather than customers.

Forum Posting

This is similar to blog commenting, but the link to your site goes in your forum signature. Again, the benefit here comes from generating an online presence, rather than raw traffic power.

These are the top three forum referrals to sodaware.net.

"How To" blog articles

Think of a problem you face daily, and write a blog article about solving it. Its simple, quick, and if you get the title (and problem) right you can get a lot of exposure and links.

I get a lot of traffic to one "how to" in particular, but the vast majority of visitors don’t stay for anything else. This makes sense, seeing as they’re searching for a solution to a problem and not for games.

The best advice I can give is to treat this method like writing a recipe with one of your products as the ingredient. This way you’re providing something valuable, and also encouraging downloads and sales.

Link directories

I tried an automated submission programme a while ago, but I’m yet to see a single visitor from any directory.

dmoz.org is worth submitting to, but as it’s human edited it can take a while to get added.

Blog Carnivals

I’ve entered blog carnivals as well as hosted them, and the results have been a little mixed. Hosting brings in a decent amount of short term traffic, but I suspect it’s mainly people who submitted articles that visit.

It’s a good way of getting a few more readers for your blog, and be good for spreading your site around.

Game Buttons

I tried these out in my $19.95 experiment and absolutely hated them. I think they cheapened the look of the site, and most of the banners contained images I didn’t really want to see. The other problem is you have to make a lot of impressions to generate any decent amount of traffic.

Free Developer Resources

The "For Developers" section is where I put articles, source code and tools for other developers to use. It didn’t bring in much traffic to begin with, but posting about some of the resources on forums helped.

WikiPedia

This is a five minute method that works well, but if done incorrectly you’ll end up looking like a spammer, so use it wisely.

Find an article on WikiPedia that relates to something on your site, and add a link to it in the "External Links" section of the page. Remember that WikiPedia monitors links that are added, so if you don’t add value to the topic you’ll find your link nuked (and you could also be banned). For example, my interview with Hanako Games is on the Hanako Games WikiPedia page.

As with text link ads, the real benefit here is getting links and increasing your search engine ranking.

Traffic Exchanges

This one is a little hit and miss, although it’s not as bad as some of the other methods. You add your link to a directory, and its position is dependent on how many other sites you visit. For example, visiting 30 sites may put you on the first page, which will get you more visitors.

The downside is that most people are only visiting your page to increase their own rank, but the traffic isn’t as bad as I expected.

Conclusion

This is just a small sample of the various method of traffic generation techniques out there. If you’re trying to increase your site’s traffic, just remember to measure what your visitors are doing, not just how many you’re getting. Sure, it’s nice to see big numbers in your hit counter, but that means nothing if they don’t stay and buy from you.

In my previous post, I wrote about Silver Bullets, and how they’re a dangerous thing to strive for when writing software. Naturally I’m not the first person to write about them

Jeff Atwood’s “Quantity Always Trumps Quality” deals with the underlying cause of Silver Bullet Syndrome – trying to design the perfect system. When I first read the headline, I was already getting ready to disagree, but it makes a very valid point. If you’re not writing code, you’re no learning. Theorizing about best practices and architecture is all well and good, but you can only see things go wrong when you actually code them and see how they work.

“I’ll get to your application in a minute – First, we need to build the framework” by Jeffrey Palermo looks at the problem from a web developer’s point of view. The environment may be different, but the problem remains the same. Well worth a read.

Legend has it that the way to kill a werewolf is to shoot it through the heart with a silver bullet.

Software is not a werewolf.

That might seem like an obvious statement, but how many times do developers approach a task with the mentality that there’s only one "perfect" way of doing it?

A good illustration of this is to give ten programmers a single, small problem to solve. Chances are, they will all do something slightly different. Even simple algorithms can be done in a dozen different ways. And remember, this is just small stuff here. Once you get to developing full pieces of software, the choice of solutions explodes. Just look at how many RSS readers are out there. Each one solves the same basic problem in a different way.

Games are just as likely to fall prey to the "perfect" way of thinking. Perhaps even more likely, because of there’s always the thought of "we can use this framework for every other game, so it has to be good". This type of thinking sounds smart in principle. After all, re-using code saves money and time. The only problem is that too much time gets wasted on tweaking engines instead of creating the actual product.

Start small, and concentrate on what needs doing. Don’t get caught up in trying to develop an engine that can do everything, because it’s a waste of time. Always remember that what you’re creating can be done in a million different ways, and none of them are perfect.

There is no silver bullet.

What is BlitzBuild?

BlitzBuild is a command line tool for compiling BlitzPlus and Blitz3D applications, although it can be used to automate other tasks in a similar fashion to Windows batch files. BlitzBuild’s primary aim is to make it easier to build software with the Blitz series of languages, to remove the IDE from the build process and to combine several key build steps (such as documentation creation and testing) into a single step. This saves time and can also improve the quality of the finished article.

For the latest updates to this project, see the BlitzBuild project homepage.

Important Note: This release is very much a “preview”, and as such isn’t really recommended for a production environment.

License

BlitzBuild is freeware and may be used without restrictions.

Quick Links

Donations & Support

If you find this library helpful in your projects, please consider donating. Donations of any size are always welcome!

If you have any comments, please feel free to leave them here. You can also send an email or leave them as a feature request on the bug tracker.

Download

This is a simple change that can make using the Windows command line much easier. Adding a directory to the Windows PATH will mean Windows will search the directory when a command is entered. The main reason for doing this is that it acts as a shortcut for common applications you may run.

For example, instead of typing : "C:\Program Files\SomeProgram\Bin\MyProg.exe" --some-arg to launch an application, you can type MyProg.exe –some-arg. This has three main advantages:

1. Looks Neater – This can be important if you’re using batch files. Long lines are hard to read, so shortening things is a good idea.
2. Less Typing – Speaks for itself. If you use the command line or batch files for any amount of time, you’ll appreciate how much easier it is to use if you’re not typing full paths for your tools.
3. Portable – Perhaps the most important detail. Not using hard-coded paths makes it easier to port your batch files to other machines.

Note: Be careful when editing your path variable, as you could render some programs unusable if you make a mistake. Also remember that changes won’t take effect until you restart the console.

Editing the Windows Path Variable

1) Right click “My Computer” and select “Properties” OR goto Control Panel and select “System”. This will open the “System Properties” window.

2) Switch to the “Advanced” tab, and select “Environment Variables”.

3) There are now two options. You can modify the global path variable, or add your own to your personal profile. If you want all users on the machine to have the same shortcut, add it to the global path, otherwise use the local one. 

Modifying the Path Using the Command Line

If you’d like to do this using the command line, you can use the “setx” command included with Windows XP service pack two. To add the directory “c:\program files\SomeProgram\Bin” to your path, use the following:

setx path "%PATH%;C:\Program Files\SomeProgram\Bin"

Remember to include the %PATH% variable at the start of your setx command so that you’ll keep existing path names.

Creating software is a time consuming business, and it’s important to always be on the lookout for ways to reduce the amount of time spent on less important tasks. The process of actually building software (creating the finished distributable binary) is one such area that can be optimised. Opening up your IDE and hitting “compile” might not seem particularly time consuming, but it’s only one part of the build process.

To get you started, here’s a short list of tasks that can be automated:

• Compiling the executables and dependent libraries
• Packing media
• Creating an installer
• Uploading files to an FTP site
• Checking out files from a repository to be built
• Sending an email about a finished build to other developers
• Creating the application documentation / Converting it to HTML
• Testing the software

The benefits of using an automated build system include:

• Saves time – Run a build and leave the computer to do the work whilst you take care of other tasks.
• Documents the build process – If a build requires several steps before being completed, a build file will document this process for you. This is useful if templates need to be generated or options need to be set before a build is ready.
• Improves quality – As well as automating the creation of a binary package, tests can be automated. This saves a lot of time on the development end, as tests can be constantly run so you’ll quickly find out if the software’s behaviour has changed.

Simple Automation – Batch Files

The simplest way to automate many of these tasks is to use batch files. A batch file is a list of tasks to be run, usually in the form of a list of applications with some command line parameters. Using a few simple commands it’s possible to run many tasks in succession without any user input, leaving you to do more important things. Microsoft.com has a is a simple guide to batch files which is a good place to start.

As useful as batch files are, there is only so much they can accomplish, and there may come a time when something more complex is required for your project. Thankfully there are many build systems available

Build Tools

There are plenty of build systems available, and several of them are targeted at certain platforms or languages. It may take a while to become comfortable with a platform, but the savings are worth it.

• GNU make – A standard system used by many Linux projects. It consists of a plain text file that lists targets and dependencies, and features many advanced features such as automatically determining which files require rebuilding.
• Apache Ant – Ant is designed as a replacement for make, and uses XML files to describe the build process instead of text files. It’s written in JAVA, and is completely portable.
• nAnt – nAnt is a .NET based version of Ant, and although it is not exclusively for .NET developers it has many features that make it useful for building .NET apps.
• A-A-P – A-A-P is a portable build tool that uses text-based “recipes” to compile and distribute software, but it can also be used for other tasks such as publishing websites and generating files from templates.
• Visual Build Professional – VBP is a commercial build tool that takes a more visual approach to creating build scripts. It integrates well into many Microsoft IDEs, but also supports other languages such as Delphi and Java.
• BlitzBuild – A free build tool aimed at BlitzPlus and Blitz3D developers.

Breaking the Task Down

Most build scripts will contain more than a single command, so it is useful to break the build script into different groups or “targets” that can be executed individually. This is particularly useful if building of data files is included, as it can be used for art or music to be built independently of the main application. Many build platforms also allow targets to be called from other targets, which effectively breaks a build script into a set of functions that can be executed in any order.

Common targets include compilation, installation and cleanup, but the choice is entirely up to the developer. It may also prove beneficial to include a separate target for generating debug versions of the application which can be distributed as a troubleshooting option.

Zip files are one of the most common compression formats around, and are a great way of storing files. Using the userlib functionality of BlitzPlus and Blitz3D, it’s now possible to access and manipulate zip files from within your Blitz applications. This can be useful for packing your media, as well as compressing network data.

This article will show you the following:

• What files you need to use zip files in Blitz, and how to install them.
• How to open an archive file and find out what files it contains.
• How to extract a file from an archive.
• How to create a new zip file and add files to it.
• How to compress and uncompress Blitz banks.

What will you need?

Blitz.ZipApi — A free library that you can include in your Blitz project. It comes with everything you need to use zip functionality within Blitz.

Installing the files

Once you’ve downloaded the library, you’ll need to copy “zlibwapi.dll” and “zlibwapi.decls” to the appropriate “userlibs” folder so that you can use the userlib functions in your application. This will be something similar to “c:\program files\blitzplus\userlibs\”. The userlib file is fully documented and has XML comments for use with Protean IDE.

You’re now able to use simple zip functions, but if you’d like to get easier access to some of the more common functions, you should include the following into your project:

• Blitz_File_ZipApi.bb — Helper functions for using zip files in Blitz.
• Blitz_File_FileName.bb — A few functions for manipulating file names. Use them to get a directory name, file name and extensions from a string.
• Blitz_Basic_Bank.bb — PeekString and PokeString functions.

All of these files are included in the Blitz.ZipApi distribution, along with full documentation in HTML format.

How it works

The zip library works in a similar fashion to the standard Blitz file functions. Before a file can be read from it should be opened with ZipApi_Open, and once finished with it should be closed with ZipApi_Close. Files to be written to should be opened with ZipApi_CreateZip and closed with ZipApi_CloseZip.

Fully documented examples are included with the library, and are also available online.

Subversion is an open-source version control system. That doesn’t sound particularly interesting, and at face value it isn’t, but you only need it to save your skin once to realise how useful it can be.

Version control is a method of storing different revisions of the same file, usually source code or documents. This allows developers to see when changes to a file have been made, which can be useful for isolating bugs, and can also be used to “roll-back” a file to a time before a bug was introduced.

Along with these features, version control allows developers to merge two versions of a file, which is very useful for projects with more than one person.

This article covers the following:

1. What software you need
2. Creating a new repository
3. How to set up a Subversion server
4. Adding password protection to a Subversion repository
5. Laying out your repository and importing files
6. Checking out and checking in
7. Using tags and branches

What you’ll need

Subversion – The primary download is source code, but there are binary versions available for different operating systems, including Windows, Mac OS and most common flavours of Linux.

If you intend to use Subversion mostly from the command line, you might want to add the Subversion binaries directory to your Windows PATH variable.

Optional Downloads

TortoiseSVN – If you’re using Subversion with Windows, I highly recommend installing TortoiseSVN. It integrates with the Windows explorer shell, so you can see an icon if a file has been changed. You can and also check in items, commit changes and perform other common operations with a few clicks of the mouse instead of using the command line.

I use the “Sociable” WordPress plugin to add social bookmarking links to the bottom of every post. There are a tonne of social bookmarking sites around, so I’ve kept things light to avoid the icon overload that can be seen on some blogs. I’ve made two updates over the last few days, one was adding devbump and the other was adding CSS image rollovers.

If you’re not sure about adding a few bookmarking buttons, you might want to check out the traffic increase at webloghits.com. That’s the kind of increase that is worth a few minutes of your time.

Adding devbump.com

There are a lot of digg style sites out there, but devbump caught my eye because it’s aimed squarely at game developers. Submitting your posts to places that are actually interested in the subject is always more useful, so devbump was a natural choice. 

To add new sites to sociable, open up “sociable.php” and find the following line:

Once you’d found it, add the following after the “Del.irio.us” definition:

You’ll have rebuild the list of available sites by logging in to your blog, and selecting “Restore Built-in Defaults” from the sociable page (Options -> Sociable). “devbump” should now be available to use on your site.

Adding CSS image rollovers

Now for the fun part. I used some code from Present Tense (Hacking the Sociable WordPress Plugin for Image Rollovers), but it didn’t quite hit the spot so I did quite a lot of tweaking to get things looking nice. I’ve stuck it all in a zip at the end of this post.

Before you skip ahead to the freebies, there are a few important things to note.

Tweaked “sociable.php” — I made two main tweaks to sociable.php. One was because some sites have “.” characters in their name, so it wouldn’t work with CSS class names. The other tweak was to change the way that the HTML was generated. Instead of standard images, it’s a list.

Internet Explorer — Naturally IE messes things up a little bit, so you might have to experiment a little bit to get things looking the way you want them. Removing the CSS tooltip may help.

16 x 16 Images — I like to have text next to my images, so each one has a different width. If you open “sociable.css”, you’ll see I’ve defined each networking site with a pair of definitions:

If you’re using 16 x 16 images, you can move the width statement into the “.sociable li” definition.

Adding New Rollovers

To add a new image, you need to add a class with the name of the site, and then set its image. It’s really just a matter of copying an existing class definition and changing the names. I’ll add new sites as time goes on, but at the moment I’ve only defined: del.icio.us, digg, devbump, Reddit and Furl.

Free Stuff!

Everyone likes free stuff, so I’ve zipped up all of the files I modified for your downloading pleasure. There are still a few bugs to iron out, so I’ll be modifying this post as and when things change.

To install the changes, just copy the files into your “wp-content/plugins/sociable” directory — you’ll need to have sociable already installed (download here).

What is Blitz.ZipApi?

Blitz.ZipApi is a userlib and set of helper functions for BlitzPlus and Blitz3D that allow you to use ZIP functionality, such as compression and decompression of data. The helper functions take care of the most common operations, such as adding data (either from a file or a bank) to an archive or extracting a file.

Using Blitz.ZipApi, you can compress Blitz banks, read the contents of ZIP files and create your own archives.

For the latest updates to this project, please see the Blitz.ZipApi page.

License

ZlibWapi.dll is released under the zlib license. More information can be found at the Zlib homepage.

The userlib declarations and wrapper functions are free to use and modify without restriction. If you modify the code, please consider letting me know what was changed and why so it can be improved. If you do use this library in a project, I’d appreciate a mention but it isn’t required.

Quick Links

Donations & Support

If you find this library helpful in your projects, please consider donating. Donations of any size are always welcome!

This library has been tested, but some bugs may still be present. If you find any, please submit them to the bug tracker. I can’t promise they’ll be fixed right away, but I’ll do my best to sort out urgent problems.

If you have any comments, please feel free to leave them here. You can also send an email or leave them as a feature request on the bug tracker.

Download

Let’s face it, most of what I’ve been working on over the past few weeks has not been particularly exciting. In fact, it’s been downright boring. Unfortunately, game development is not all fast cars and multi-coloured particles. A lot of it is dull, tedious and less exciting than watching a race between paint drying and grass growing.

As if things weren’t bad enough, skipping over the dull bits to work on exciting things will always come back to haunt you. Talk about kicking a man when he’s down.

The Slightly Boring Bits

The blank canvas

It’s more intimidating than boring, but starting out with an empty project is boring in itself. Although there’s the initial rush of starting something new, it’s quickly followed by the realisation of how much work needs to be done. Creating the initial skeleton is a lot of work, and you’ll probably end up rewriting it at least once. That’s something to look forward to.

Setting up tools

It’s easy to waste days, even weeks, on setting up your build environment. Choosing a language, setting up working directories, version control, customising your IDE and creating build scripts are all part of the initial fun. You might even write a set of coding standards if you really want to put yourself off the project before it’s started. Remember to spend at least a page debating over how many spaces a tab should contain.

The Really Boring Bits

Testing

Hopefully most people realise that being a game tester is not the same as playing games for a living. Testing your own game is much worse, because by the time you’re ready to test you’ll be sick of the sight of it. To make matters worse, you have to wade through all your code and fix all the bugs that crop up. It’s bad enough having to test something you hate, but being reminded that you make mistakes (and lots of them) adds insult to injury.

Documentation

Need I say more?

Anything that involves accessing files

Ever been excited when a game reads something from the hard-drive? Thought not. Spare a thought for the soul that coded it.

The “glue”

Games are lots of fun things stuck together by lots of boring bits. Error checking, file manipulation (as mentioned), resource management and all the bits that glue the main components together are all parts of the job you’d rather never see.

It’s fun to watch things fly around the screen, but there’s a lot of work to be done behind the scenes before anything can start flying. It should come as no surprise to realise that coding all of this is no fun at all.

Planning

It’s not much fun.

The Good News

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

As many of you will know, hot weather and software development do not go together. The last few weeks have seen temperatures in Britain hit the high 90s, which wouldn’t be so bad if I had air conditioning. Suffice to say, my productivity hasn’t been as high as I’d like it. Still, at least I have a mild sun-tan.

Here’s what’s been cooking (almost literally) over the last few weeks:

Flexible Resource System

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.

Debugging System

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.

Debug Console

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.

An Object / Entity System

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.

Some Flexible Tools

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 Bits and Pieces

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.

I’ve been programming since I was able to use a keyboard, and it’s one of the best skills I ever learnt. Like any skill, it has to be constantly fine-tuned, and I’m always on the lookout for ways to improve. Here’s a few important things I’ve learnt over the years, most of them from my (very) early days.

1. “Funny” comments aren’t funny at all

The first large game I wrote was a text adventure for the Atari ST. Instead of commenting each section of code with something useful, they had “funny” comments instead. For example, the code that handled eating had a comment saying “Bite me” above it. How witty.

2. I suffer from Premature Optimisation

I always find it satisfying to squeeze a bit more speed out of any routine, but sometimes it’s difficult to wait until the code is actually functioning how it’s supposed to. Some of these optimisations can leave code very difficult to read, especially if they’re using functions I wouldn’t normally touch.

Naturally, I’d leave these obscure changes uncommented as a challenge to my future self.

3. The compiler doesn’t care how my code looks

Source code is for people to read, and compilers to translate. It really doesn’t care if my braces start on a new line or not, so I don’t worry about it. If the formatting of the code is a problem for me when I’m reading it, then I’ll change it.

Incidentally, I once read someone else’s source code that controlled a ball, and they’d arranged the code to look like a ball. I thought that was awesome, especially because it wasn’t an entry for the code obfuscation competition.

One of the few things I managed to get right in my early code is indentation. It’s one of the simplest changes you can make to any source file, and it really affects how readable things are.

4. Languages support comments for a reason

Somewhat similar to number 1. The only thing worse than looking at a source file and thinking “Why didn’t this idiot comment their code?” is realising that it’s yours.

Good commenting is an art form in itself, but it’s a highly valuable skill. Good comments explain why something is happening, not what is happening. Nowadays I use PDL as often as I can, and I find it makes code much more readable. Not only does it mean code is commented well, but it means I have to think about things before I start typing.

5. Use decent variable names

In BASIC, “$” often represents a string. I used to think it was funny to use the variable name G$. If I’d already used it, I might call it G2$, or even GG$. As you can probably imagine, anything that used more than about five variables turned into a completely unreadable mess.

I know I was young and reckless, but it’s no excuse for such horrible, horrible variable names.

Oh dear

So there we have it – a collection of some of the scariest code ever written. There’s plenty of other lessons I’ve learnt, such as “Use functions instead of copying and pasting code” and “Use good function names instead of ‘print2′ and ‘print3′ “, but these are the pick of the bunch. Sometimes you only realise how important some of these things are when you do them badly.

One of the things I did with the old design of this blog was to change the header image every month, and it’s something I use on my other website (philnewton.net). I could have done this by uploading a new image every month, but being a programmer I decided to do it a different way.

Using mod_rewrite to change the image

If you’re using an Apache server, you can use something called mod_rewrite to rewrite URLs and do other nifty tricks. I used this to change the image the user saw every month.

I keep all the images in my images folder, and name them according to the month I want them to show. For example, the March image will be called “03-header.jpg”, and the December image “12-header.jpg”. I then use a little mod_rewrite trickery to redirect requests to the correct location. The code looks something like the following:

This code is placed in a “.htaccess” file that resides in the html root folder on the server. This is the folder where all the other folders and files are kept. I put it here instead of in the blog folder because WordPress has its own “.htaccess” file which sometimes changed and removed my tweaks.

Using it in the template

You don’t have to make any changes to your html templates, just make sure you link to the image as “header.jpg” and not something like “12-header.jpg”. The server will take care of all the redirection all on its own, and it won’t disturb anyone’s browsing experience.

Microsoft released Beta 2 of Office 2007 on Tuesday, and I decided to give it a try. I’ve not been using it long enough to make a real judgement about it, but my initial impressions are quite positive. It’s still quite rough in some places, but the overall experience is pleasant enough.

Installation

Probably the biggest problem I had was getting the thing installed. Installing the Professional Suite took quite a long time, and I had to fiddle around to get everything working properly. Outlook in particular was a pain, because the installer didn’t uninstall the previous version despite me selecting the option. None of the problems I encountered were catastrophic, but they all added up to make me quite annoyed.

The other main problem I’ve had is with Windows Desktop Search. I’ve had no luck getting it to work, so I’ve decided to give it a miss. I’m a bit annoyed that Outlook requires it for the Instant Search, but search folders still work so I can live without it for now.

I’ve not had time to give everything a thorough going over, so I’ll stick to what I’ve spent the most time with.

OneNote

Unfortunately I’ve not had a great experience with OneNote so far, but I’m putting it down to a hardware / driver problem on my machine. The mouse has a habit of jumping around the screen, and then the app crashes. This has happened to me with other apps, so I’m not blaming OneNote. It’s a shame though because it looks like a really cool app.

When it has worked, I’ve had chance to play with copying text from images and jotting down notes about various subjects. I have a feeling it would be a great tool for organising blog posts, so I’ll definitely be giving it another shot when I get a new computer.

Excel

The first thing you notice with Excel is the Ribbon. Seeing as it’s in a few apps, I’ll talk about it in detail later, but for Excel it really makes you feel like you’re getting more. You can see a lot more functionality without digging around too much, and the new tooltips explain features a lot better.

I mostly use Excel for scheduling time on projects, so I haven’t seen most of what the product has to offer. I’m sure I’ll have a better idea of what it can do over the coming weeks, but for now it does it’s job and that’s all I can ask.

Outlook

I use Outlook every day, so I was a little anxious about replacing the original with the Beta. It’s been a mixed bag so far, and I’m not completely convinced.

The new To-Do bar is a nice addition, and it gives you a good overview of upcoming tasks and appointments. I’ve found it much more useful than “Outlook Today”.

There seem to be a few tweaks email wise. You can quickly assign a category to emails, and flagged emails show up in the To-Do bar. The task and calendar sections have also been improved. None of the improvements really stand out yet, but they all add up to a more pleasant, tighter experience.

Performance wise, I’m a little disappointed. I don’t exactly have a powerhouse of a PC, but for me Outlook is the most sluggish of all the new Office tools. It freezes for a few seconds whilst switching emails, and can freeze for quite a long time for no apparent reason.

The interface for composing emails benefits from the new Ribbon, but it’s not so useful if you’re a fan of sending plain text emails. If you want to get a little fancy though, it looks like it will be a big help.

Word

The first thing that really struck me about the new Word is that it looks, well, nice. I realise it’s only a word processor, and that looks are secondary to functionality, but it’s always nice to enjoy using a piece of software. My first impressions were definitely positive.

Of all the programs out of the new Office that I’ve used, Word certainly feels the most improved. It’s still a little bit ropey in places however, particularly in some of the older dialog boxes. The overall experience is very slick though, and I’ve found that the new appearance and interface alone makes me feel more productive.

Styling the document is a breeze, and the “live preview” feature is more useful than I imagined it would be. Simply hovering over styles in the gallery will change the selected text. This is nice because you can see how the style will look without having to worry about ruining the document if you don’t like it.

Not all the improvements are as big as the ribbon. The status bar at the bottom lets you change the view and zoom level quickly, and also displays the current word count. Nothing spectacular, but it’s a welcome improvement.

It’s not all good though, and one feature I was disappointed with was the blogging support. From what I gather it was only recently added, but as it stands it’s not very useful at all. It can’t use categories in WordPress, and it also gives the wrong posting date. Oh dear. Here’s hoping it will be much improved before the final release.

Overall

I’ll be honest, I’ve never been as interested in any of Microsoft’s products as I am about Office 2007. Public betas, blogs such as Jensen Harris’s and a fresh interface really seem to have moved the product forward.

The Ribbon isn’t as obtrusive as it may look, and it can be collapsed to give even more space to the document. It didn’t really take any getting used to, and I have a feeling that once you’ve used it for a few days you won’t want to go back to the land of toolbars.

The biggest complaint I have is the lack of consistency in usability. The Ribbon makes using most features much, much easier, but it’s a shame that there are still poorly designed dialogs present.

I realise I haven’t dug too deep into the products, but for general use they’ve been a pleasure to use. Word is certainly a big improvement, and I don’t think I’ll be switching back to Office 2003 any time soon.